New issue
Advanced search Search tips

Issue 605537 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 550854
Owner:
Closed: May 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

White screen after 40 seconds of playing an mp4

Reported by dd...@brightcove.com, Apr 21 2016

Issue description

Chrome 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.
 

Comment 1 by ajha@chromium.org, May 5 2016

Cc: ajha@chromium.org
Components: 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)
Able to reproduce this on the latest canary(52.0.2725.0) and the latest stable(50.0.2661.94) on Mac OS 10.11.4. Works fine on Windows-7 and Linux Ubuntu 14.04.

This is a regression issue broken in M-48.

Last good build: 48.0.2564.15
First bad build: 48.0.2564.16

Changelog:
==========
https://chromium.googlesource.com/chromium/src/+log/48.0.2564.15..48.0.2564.16?pretty=fuller&n=10000

Suspecting: https://codereview.chromium.org/1481633002

sandersd@: Could you please take a look at this.

Thank you!
Mergedinto: 550854
Status: Duplicate (was: Assigned)
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