bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

RESOLVED INVALID

Status

()

Core
Audio/Video: Playback
P2
normal
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: cpeterson, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox40 disabled, firefox41 disabled, firefox42 affected, firefox43 affected)

Details

(Whiteboard: parity-chrome, URL)

(Reporter)

Description

3 years ago
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.
(Reporter)

Updated

3 years ago
Summary: simpl.info WebM MSE test → simpl.info WebM MSE video stalls after one second (in Nightly 43 and two seconds in Aurora 42)

Comment 1

3 years ago
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.
(Reporter)

Comment 2

3 years ago
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
Whiteboard: parity-chrome
(Reporter)

Comment 3

3 years ago
(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?
(Reporter)

Comment 4

3 years ago
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

3 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Priority: -- → P2
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.