Issue metadata
Sign in to add a comment
|
White screen after 40 seconds of playing an mp4
Reported by
dd...@brightcove.com,
Apr 21 2016
|
||||||||||||||||||||||||
Issue descriptionChrome Version : 49.0.2623.112 (Official Build) (64-bit) URLs (if applicable) : https://jsbin.com/jinuriwuho/1/edit?html,output https://github.com/tenacex/stream Other browsers tested: Safari 9.1: OK Firefox 45.0.2: OK Chromium : FAIL What steps will reproduce the problem? (1) Create an html5 video element. (2) Set the source attribute to "https://github.com/tenacex/stream/raw/master/broken.mp4" (3) Attempt to play video. What is the expected result? The expected result would be for the video to play through the entire video successfully. What happens instead? After 42 seconds, the video screen turns white and the player crashes. Please provide any additional information below. Attach a screenshot if possible. I created the failing mp4 by first combining all of the ts segments in my linked repo by running: 'cat 92.ts 93.ts 94.ts 95.ts 96.ts 97.ts 98.ts 99.ts > all.ts' I then muxed this ts segment into an mp4 by running: 'ffmpeg -i all.ts -bsf:a aac_adtstoasc -acodec copy -vcodec copy broken.mp4' I noticed that this video was failing to play in chrome (just like my ts segments) I then retranscoded the video by running: 'ffmpeg -i broken.mp4 -vcodec h264 -acodec aac -strict -2 fixed.mp4' I noticed that retranscoding the file fixed playback in chrome. Still, all programs on my computer, and browsers(excluding firefox) can successfully play the broken.mp4 file.
,
May 5 2016
I'm dubious of the suspected CL because the root cause is actually a gap in the frame_num value between frames; this would have been a problem before the suspected CL as well. Specifically, at around 40 seconds, broken.mp4 skips from frame_num 19 to frame_num 21. This usually means that a frame was lost somewhere in the encoding process, and recovering from lost frames is not implemented in Chrome's Mac hardware decoding path. In this case we can go one step further; the H.264 stream is in fact invalid because, in the SPS, gaps_in_frame_num_value_allowed_flag is not set. This is expected to result in a decode error on ChromeOS as well, even though gaps in frame_nums are implemented there. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ajha@chromium.org
, May 5 2016Components: Internals>Media>Source
Labels: -Type-Bug -Pri-3 M-52 hasbisect OS-Mac Pri-1 Type-Bug-Regression
Owner: sande...@chromium.org
Status: Assigned (was: Unconfirmed)