1202580 - simpl.info WebM MSE video stalls after one second (in Nightly 43 and two seconds in Aurora 42)

Status: RESOLVED INVALID

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

Description

[Chris Peterson [:cpeterson]]

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.

Comment 1

[Jan Gerber]

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.

Comment 2

[Chris Peterson [:cpeterson]]

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

Comment 3

[Chris Peterson [:cpeterson]]

(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?

Comment 4

[Chris Peterson [:cpeterson]]

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

Comment 5

[Jan Gerber]

(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.

Comment 6

[Ralph Giles (:rillian)]

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.