New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: WontFix
Closed: Aug 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Issue 516114: MP4 video with gaps in sequence_numbers fail to play via MSE

Reported by, Aug 1 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2471.0 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Append video content to the sourcebuffer that has the first moof/mfhd segment starting with a sequence_number above 1. 

What is the expected behavior?
Video should play, ignoring the gap in sequence numbers.

What went wrong?
A white screen for the video.  No errors, chunks continue to be accepted via appendbuffer().  The metadata load event fires, but no data loaded event fires.

Even though the sourceBuffer.updating is false in this broken state, trying to change the  sourceBuffer.timestampOffset raises a "PARSING_MEDIA_SEGMENT" exception.

chrome://media-internals/ shows the video as playing and reports no errors.

Did this work before? N/A 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? No Firefox Developer Edition 41.0a2 (2015-07-31), Safari 8.0.6 (10600.6.3)

Chrome version: 46.0.2471.0  Channel: canary
OS Version: OS X 10.10.3
Flash Version: Shockwave Flash 19.0 r0

I have posted the same code referencing a second video where all of the sequence numbers are accounted for starting at 1.  That video plays fine through MSE.  The only difference is the gap of sequence numbers.

In the video that does not work, the starting sequence number of the first moof/mfhd is 283.

Source video is from a webcam with the following ffmpeg options: 
-an \
-f mp4 \
-g 25 \
-reset_timestamps 1 \
-movflags empty_moov+default_base_moof+frag_keyframe \
-profile:v main \
-level 30 \
-pix_fmt yuv420p \
-tune zerolatency 

You can download the video and play it directly in chrome no problem.  It is just when injected through the MSE api that there is a problem.

Comment 1 by, Aug 1 2015

Just noticed that the stream-lined example I added raises an error in the console when trying to append to the buffer due to not checking the buffer state.  If needed, I'll tweak the example to handle that case, but it's a false alarm.  Compare the two different URLs and the example with the gap in sequence numbers is clearly having issues.

Comment 2 by, Aug 3 2015

Labels: -OS-Mac OS-All M-46
Status: Untriaged
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.10.4 using chrome version 44.0.2403.125 with the below steps

1. Go to URL
2.Observe the video not playing

This is observed on ALL OS and is non regression issue since from version M25.

Marking it as Untriaged to get more inputs from dev team.

Comment 3 by, Aug 3 2015

Labels: -Cr-Internals-Media Cr-Internals-Media-Source

Comment 4 by, Aug 3 2015

Status: WontFix
I believe this is working as intended:

When I go to URL and inspect the result frame's video tag's buffered, it shows:
> $('video').buffered.start(0)
< 679.16129
> $('video').buffered.end(0)
< 682.16129

Yet the video element's currentTime is 0 (also seen by inspection).
Since the app has appended media that begins later in time than time 0, seeking to the start of the buffered range is required to begin playback.

Indeed, if I set $('video').currentTime=679.16129 using dev console on the result frame's context, a few seconds of video plays.

Resolving as WontFix due to working as intended.
If indeed you expect this particular fragment of video to be appended into the timeline at time 0, and the media conforms accordingly (with encoded frame buffer timestamps that begin at time 0), then please re-activate this bug. Otherwise, if buffered ranges begin later than time 0, the web app will need to seek to a buffered range to be able to play the media.

Comment 5 by, Aug 3 2015

Also note that if the app is aware that it is appending media that begins at time X (say, 679.16129 seconds), then it could set sourceBuffer's timestampOffset to be -X prior to appending that media to the sourceBuffer to have the media moved into the timeline beginning at time 0. Care needs to be taken though, to prevent media from being moved to before time 0, in which case it will be front-truncated to the first keyframe.

Finally, note that Chrome loosens the requirement that buffered ranges begin at time 0 to allow playback from time 0 to commence. It allows the begin to occur up to 1 second, since there is lots of media in the wild that doesn't begin with timestamps at exactly 0 on both audio and video streams.

Sign in to add a comment