VID-7: Playback failed on Android

Issue Information

Issue Type: Bug
 
Priority: Major
Status: Closed

Reported By:
Ben Tasker
Assigned To:
Ben Tasker
Project: Videos.bentasker.co.uk (VID)
Resolution: Invalid (2019-03-29 00:00:09)
Affects Version: v0.12, v0.13,
Target version: v0.13,
Components: Embed Code ,

Created: 2019-03-28 23:20:56
Time Spent Working


Description
This probably isn't going to prove to be an issue with the code, but a couple of the videos published today do not play back on Android (in Firefox mobile or chrome).

Those are the videos embedded in the following pages

- https://snippets.bentasker.co.uk/page-1707191143-Getting-connection-speed-metrics-from-curl-BASH.html
- https://snippets.bentasker.co.uk/page-1705141234-Simple-Reverse-Shell-BASH.html

However, the following videos do work on the same device

- https://www.bentasker.co.uk/documentation/vehicles/322-volvo-s60-alternator-replacement
- https://www.bentasker.co.uk/documentation/vehicles/386-performance-power-1kva-generator-has-no-output

All play correctly on my desktop browser.

The former two are screen recordings made with kazam, whilst the latter two are recordings from a camera (on my phone) so I suspect the answer is probably going to be codec related (although HLS-Stream-Creator should pass through libx264 anyway?).

Either way, need to look at finding the cause. If it can be addressed in the embed code then that'd be ideal, but either way need to the cause documented and recorded


Toggle State Changes

Activity


2019-03-28 23:25:22
OK, a segment of a breaky one 
ben@milleniumfalcon:/tmp$ ffprobe -hide_banner -i 201705_14_simple_reverse_shell.mp4_1000_00000.ts 
Input #0, mpegts, from '201705_14_simple_reverse_shell.mp4_1000_00000.ts':
  Duration: 00:00:16.67, start: 1.533333, bitrate: 219 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High 4:4:4 Predictive) ([27][0][0][0] / 0x001B), yuv444p, 1366x744 [SAR 1:1 DAR 683:372], 15 fps, 15 tbr, 90k tbn, 30 tbc


vs a segment of a working one 
ben@milleniumfalcon:/tmp$ ffprobe -hide_banner -i VID_20190327_145341.mp4_1000_00000.ts 
Input #0, mpegts, from 'VID_20190327_145341.mp4_1000_00000.ts':
  Duration: 00:00:08.35, start: 1.445333, bitrate: 1026 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuvj420p(pc), 800x600 [SAR 4:3 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc
    Stream #0:1[0x101](eng): Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 75 kb/s


Both are h264 but the profiles are different. The screencast also (unsurprisingly) lacks an audio track.

Seems more likely that Android doesn't support the Predictive profile, or perhaps doesn't support YUV4:4:4 (that was certainly the case for ONXPlayer a while back - https://github.com/raspberrypi/firmware/issues/549 - as the pi uses hardware sometimes found in phones, there could be a correlation here).

2019-03-28 23:45:35
Have pre-processed the kazam MP4 with the following command. 
ffmpeg -i 201705_14_simple_reverse_shell.mp4 -acodec copy -qscale 0 -y -pix_fmt yuv420p 201705_14_simple_reverse_shell.iframed.mp4


(The important bit being the pix_fmt section)

Android phone can now play back the following page - https://videos.bentasker.co.uk/resources/tests/vid_7_android_fix_reencode_test.html - which seems to prove that it's yuv444 that's the issue. A little frustrating, but there you go.

Will need to look at re-encoding and uploading the other video. Clearly not an issue with the codebase though.

2019-03-28 23:48:21
Repo: videos.bentasker.co.uk
Host:Rimmer

commit 375ad51bcfb3ff7c5f33c41b54bfb20f55298570
Author: B Tasker <github@<Domain Hidden>>
Date: Thu Mar 28 23:47:01 2019 +0000

Commit Message: Add test page for VID-7

.../tests/vid_7_android_fix_reencode_test.html | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)


View Commit | View Changes

2019-03-29 00:00:00
Re-encoded versions load fine.

Clearly my phone doesn't like yuv444, will need to see if there's a setting in kazam to adjust that. In any case, not an issue with the platform itself, so I'm going to close as Invalid

2019-03-29 00:00:10
btasker changed status from 'Open' to 'Resolved'

2019-03-29 00:00:10
btasker added 'Invalid' to resolution

2019-03-29 00:00:13
btasker changed status from 'Resolved' to 'Closed'

2019-03-29 00:06:54
For the sake of completeness, here's the output of ffprobe on one of the newly encoded segments 
 ffprobe -hide_banner -i 20170719_conn_speed_metrics_2/20170719_conn_speed_metrics.iframed.mp4_1000_00000.ts 
Input #0, mpegts, from '20170719_conn_speed_metrics_2/20170719_conn_speed_metrics.iframed.mp4_1000_00000.ts':
  Duration: 00:00:09.67, start: 1.533333, bitrate: 117 kb/s
  Program 1 
    Metadata:
      service_name    : Service01
      service_provider: FFmpeg
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1366x744 [SAR 1:1 DAR 683:372], 15 fps, 15 tbr, 90k tbn, 30 tbc