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

Status: RESOLVED INVALID

(Core :: Audio/Video: Playback, defect, P1)

Description

[Chris Peterson [:cpeterson]]

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

STR:
1. Play video at http://contosovideo.azurewebsites.net/
2. Try to seek ahead of the buffered video.

RESULT:
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:http://contosovideo.azurewebsites.net/836ff693-9ae2-4847-a15e-b9a1cf0d734f could not be decoded. contosovideo.azurewebsites.net
TypeError: a.srcElement is undefined hasplayer.min.js:26:4376

Comment 1

[Chris Peterson [:cpeterson]]

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 

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0b3dcfa5557&tochange=d3228c82badd

Comment 2

[Jean-Yves Avenard [:jya]]

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

[Jean-Yves Avenard [:jya]]

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

[Chris Peterson [:cpeterson]]

This does seem to be an OS X specific problem. Seeking in this video works fine with Nightly 42 on Windows.

Comment 5

[Jean-Yves Avenard [:jya]]

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)

Comment 6

[Jean-Yves Avenard [:jya]]

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

[Jean-Yves Avenard [:jya]]

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