STR: 1. Load http://shaka-player-demo.appspot.com/demo/ 2. Play the first video: "Angel One (multicodec, multilingual)". RESULT: Firefox 48 will intermittently stall at time 0:12. You can tell right away whether the video will stall because the player's progress bar shows only the first segment is buffered. about:media shows: HTMLMediaElement debug data http://shaka-player-demo.appspot.com/demo/ mediasource:http://shaka-player-demo.appspot.com/04c27601-da7c-b645-b7ad-37f22cecb575 currentTime: 11.969895 Quality: 100% (total:450 dropped:0 corrupted:0) Buffered ranges: [(0, 12)] SourceBuffer 0 start=0 end=50.026666 SourceBuffer 1 start=0 end=12 Internal Data: audio decoder: apple CoreMedia decoder audio frames decoded: 658 video decoder: ffvpx video decoder hardware video decoding: disabled video frames decoded: 450 (skipped:0) Dumping data for demuxer 1a4c57000: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 14.037333 NumSamples:2345 Size:1356499 NextGetSampleIndex:658 NextInsertionIndex:2345 Buffered: ranges=[(0.000000, 50.026666)] Dumping Video Track Buffer(video/webm; codecs=vp9) - mLastVideoTime: 12.000000 NumSamples:300 Size:454332 NextGetSampleIndex:300 NextInsertionIndex:300 Buffered: ranges=[(0.000000, 12.000000)]

The "Sintel (multicodec)" video also stalls. It plays until 0:09, "hiccups" for half a second, resumes playing, and finally stalls at at 0:10. This "Sintel (multicodec)" stall appears to be 100% reproducible in Firefox 45–48. Neither video stalls in Chrome, Edge, or IE11. about:media says: HTMLMediaElement debug data http://shaka-player-demo.appspot.com/demo/ mediasource:http://shaka-player-demo.appspot.com/3b243440-9648-be4b-b877-321b7dd92fb2 currentTime: 10.004666 Quality: 100% (total:255 dropped:0 corrupted:0) Buffered ranges: [(0, 10.004)] SourceBuffer 0 start=0 end=10.004 SourceBuffer 1 start=0 end=11.999 start=168 end=179.999 start=288 end=299.999 Internal Data: audio decoder: vorbis audio decoder audio frames decoded: 472 video decoder: ffvpx video decoder hardware video decoding: disabled video frames decoded: 254 (skipped:0) Dumping data for demuxer 11a075c00: Dumping Audio Track Buffer(audio/webm; codecs=vorbis): - mLastAudioTime: 10.004000 NumSamples:472 Size:239932 NextGetSampleIndex:472 NextInsertionIndex:472 Buffered: ranges=[(0.000000, 10.004000)] Dumping Video Track Buffer(video/webm; codecs=vp9) - mLastVideoTime: 10.625000 NumSamples:864 Size:15890029 NextGetSampleIndex:255 NextInsertionIndex:864 Buffered: ranges=[(0.000000, 11.999000), (168.000000, 179.999000), (288.000000, 299.999000)]

Jean-Yves, does this look like a regression in Firefox or the Shaka Player? All these Shaka videos used to work in Firefox with the old Shaka demo page, but the page has been updated to Shaka v2.0.0-beta-debug.

If it was 48, it could be related to bug 1257699. That fix will almost certainly introduce regressions in the webm MSE. We also have bug 1261900 that could result in issues depending on how vp9 is muxed. Seeing that it was reported by Google/Shaka people it may very well be the reason.

This is not a (recent?) regression. I can reproduce both the "Sintel (multicodec)" and "Angel One (multicodec, multilingual)" stalls in Firefox 45 and 48.

Can you build with the patch attached to bug 1261900 (this isn't a recent regression, but was made worse by bug 1257699) and see if that plays better?

Correction: the nestegg fix in bug 1261900 *does* fix these stalls.

Chris -- I realize this is a P2 and a carry-over regression. Does it make sense for this to track fx47 and/or fx48? (Right now both are marked.)

FWIW, I can't repro this bug on Windows 10 in Nightly. As I understand it from conversations with Anthony, the fix for this was bug 1261900, and that is considered too risky to uplift to beta. So we should WONTFIX this for 47, and consider uplifting bug 1261900 to 48 once we have some certainty that it's not going to break anything.

(In reply to Chris Pearce (:cpearce) from comment #9) > FWIW, I can't repro this bug on Windows 10 in Nightly. > > As I understand it from conversations with Anthony, the fix for this was bug > 1261900, and that is considered too risky to uplift to beta. So we should > WONTFIX this for 47, and consider uplifting bug 1261900 to 48 once we have > some certainty that it's not going to break anything. Not quite; the reason it stalls is when you have mse/webm active shaka serves webm content which has BlockDuration bit not handled properly and we end up with big gap in the buffered range. See bug 1261900. I would mark this bug as a dupe of bug 1261900.

Spoke with jya on IRC. The summary is, the fix in bug 1261900 fixes another issue that incidentally fixes this issue. The shaka player here that doesn't work never did anyway, so this is not really a regression. So I'm removing the regression keyword. This issue is not know to affect YouTube, so we should be able to WONTFIX this for 47. We'd like to uplift the fix for bug 1261900 to 48 (which we'll do in that bug at a later date), and this can be fixed in 48 when that happens. Liz: Is that ok with you?

Sounds ok to me, if we do it pretty soon in aurora. Putting that big of a change into the last few days of aurora would be less good. (Also up to Sylvestre, I am just filling in for him, here)

Hi Chirs, this bug is assigned to nobody and we need someone to work on this. Since it seems that you are involved in this, feel free to reassign it to someone else if you disagree.