Seeking in Microsoft's "Contoso Video" MSE demo stops playback with error




4 years ago
4 years ago


(Reporter: cpeterson, Assigned: jya)


(Blocks: 1 bug, {regression})

Dependency tree / graph

Firefox Tracking Flags

(firefox41 unaffected, firefox42 affected)





4 years ago
@ Jean-Yves, this looks like a regression in the new MSE stack.

1. Play video at
2. Try to seek ahead of the buffered video.

The player stops and displays the error "Video can't be played because the file is corrupt." Seeking works correctly in Firefox 41 (mostly), Chrome, IE11, and Edge.

The following errors are logged in the web console:

Media resource mediasource: could not be decoded.
TypeError: a.srcElement is undefined hasplayer.min.js:26:4376
Flags: needinfo?(jyavenard)

Comment 1

4 years ago
I bisected this regression to this pushlog, which includes these MSE changesets:

d3228c82badd	Jean-Yves Avenard — Bug 1171379: P1. Enable MediaSourceDemuxer by default. r=kentuckyfriedtakahe a=bustage 
fedceb06f2e2	Jean-Yves Avenard — Bug 1183888: Report empty buffered ranges unless we have a start time. r=bholley


4 years ago
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)

Comment 2

4 years ago
The error I'm getting is:
audio/mp4a-latm frame(pts:276758639 end:276781859, dts:276758639, duration:23220, kf:1)
944680960[130d6c3f0]: AppleVideoDecoder PlatformCallback status -8969 flags 16777473

-8969 is kVTVideoDecoderBadDataErr

This is typically happening when the init segment the decoder was created with doesn't match the data being added for decode (e.g. the SPS/PPS NALs do not match)

Comment 3

4 years ago
The previous MSE would have created a new decoder when such big discontinuity occurred. While the new MSE re-use the same decoder as only the timestamp have changed.

Maybe the Apple Video Toolbox choke on this particular video and we'll need to re-create a decoder when a discontinuity is detected ...

Comment 4

4 years ago
This does seem to be an OS X specific problem. Seeking in this video works fine with Nightly 42 on Windows.
status-firefox42: fixed → affected
Keywords: regression
OS: Unspecified → Mac OS X
Priority: -- → P1

Comment 5

4 years ago
Getting the exact same error with Safari.

The data being appended following the seek isn't part of the same stream as before the seek.

As expected. the SPS/PPS do not match.. You can't decode that.

If there's a stream quality change , an init segment must be appended.

I can get to sometimes work when the video being appended during the seek is the same as from before the seek, and in which case if there's then a change of quality an init segment is properly appended first.

It will work on windows because the data contains AVC3 like NALs (SPS and PPS before the video keyframe).
The mac decoder doesn't support annexB/AVC3. The WMF decoder does. Try with Nightly on windows and it will decode.

I can also reproduce the issue with the old MSE. This stream is invalid.

(there are more issues at play, when seeking I see gap of 2 seconds happening)
Last Resolved: 4 years ago
Resolution: --- → INVALID

Comment 6

4 years ago
Chris, this stream is wrongly encoded and the HTML5 player isn't per spec.

it's pure luck it works on windows or chrome (they use ffmpeg for decoding)

Comment 7

4 years ago
I could make it work on mac / android by ignoring the SPS/PPS found in the init segment ; and instead always search within the video raw data if there are SPS/PPS present.

It would add a rather big overhead however just to get around a bad html5 player
You need to log in before you can comment on or make changes to this bug.