STR: 1. Set media.mediasource.webm.enabled and media.mediasource.format-reader.webm = true 2. Load http://simpl.info/mse/ 3. Play the test video if it doesn't start automatically. RESULT: In Aurora 42, the video plays for two seconds then stops. In Nightly 43, the video plays for only one second.

That test does not wait for sourceBuffer 'updateend' before calling sourceBuffer.appendBuffer again. This also fails with mp4. Works ok if readChunk_(++i); is called on updateend.

Sam, it looks like this Firefox MSE stall is a bug in your simpl.info/mse demo. https://github.com/samdutton/simpl/blob/master/mse/js/main.js

(In reply to Jan Gerber from comment #1) > That test does not wait for sourceBuffer 'updateend' before calling > sourceBuffer.appendBuffer again. > This also fails with mp4. Works ok if readChunk_(++i); is called on > updateend. Jan, do you know how Chrome is able to play this test video? Does Chrome not care if appendBuffer again is called before updateend? Is that case permitted in the MSE spec?

Since this appears to be a test bug, I filed a bug report on the author's GitHub repo: https://github.com/samdutton/simpl/issues/67

(In reply to Chris Peterson [:cpeterson] from comment #3) > Jan, do you know how Chrome is able to play this test video? Does Chrome not > care if appendBuffer again is called before updateend? Is that case > permitted in the MSE spec? Looking at the spec http://www.w3.org/TR/media-source/#sourcebuffer-prepare-append > If the updating attribute equals true, then throw an InvalidStateError exception and abort these steps. So ether Chrome somehow manages to parse the chunks before the next appendBuffer is called or it does not throw an exception here.

Jean-Yves says we're more async than chrome's implementation, which could explain the stall. We were synchronous in ff 41 and earlier, so this might look like a regression. Closing as not a Firefox bug.