When the EndOfStream algorithm runs, error should be thrown to media element

RESOLVED FIXED in Firefox 42

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: jya, Assigned: jya)

Tracking

(Blocks: 1 bug)

Trunk
mozilla43
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 fixed, firefox43 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
If any error happened during an append buffer, the Append Error Algorithm is to be run.
Typically "run the append error algorithm with the decode error parameter set to true and abort these steps."

append error algorithm:
https://w3c.github.io/media-source/#sourcebuffer-append-error

which "5. If decode error is true, then run the end of stream algorithm with the error parameter set to "decode".
the End Of Stream algorithm (https://w3c.github.io/media-source/#end-of-stream-algorithm) states that is the decoder error parameter is set to true then:

"3c: if error is set to "decode"

    If the HTMLMediaElement.readyState attribute equals HAVE_NOTHING
        Run the "If the media data can be fetched but is found by inspection to be in an unsupported format, or can otherwise not be rendered at all" steps of the resource fetch algorithm.
    If the HTMLMediaElement.readyState attribute is greater than HAVE_NOTHING
        Run the media data is corrupted steps of the resource fetch algorithm.

"

We currently do nothing ; the error is ignored

This is the core reason on why we have so many bugs being opened about playback stalling with MSE.

The sourcebuffer does produce the errors as per spec ; but the parent mediasource never tells the html media element that an error occured ; so instead of giving a visual clue that an error occurred ; we have the spinner going on forever.
(Assignee)

Comment 1

3 years ago
JW, what would be the easiest way to test the readyState ; or propagate the error to the HTML Media Element?

The MediaSource End Of Stream Algorithm code (MediaSource::EndOfStream) runs on the main thread.

Would simply calling  MediaDecoder::DecodeError() sufficient? 
The HTMLMediaElement seems to only take care of a single type of MEDIA_ERR_DECODE and doesn't distinguish  things between the various readyState cases.
(Assignee)

Updated

3 years ago
Flags: needinfo?(jwwang)
We should uplift this fix to Aurora 42 because it will reduce false positive bug reports for 42's new MSE code. This error will help testers differentiate between Firefox bugs and corrupted media files.
status-firefox42: --- → affected
Priority: -- → P1
(Assignee)

Updated

3 years ago
Assignee: nobody → jyavenard
(Assignee)

Comment 3

3 years ago
Created attachment 8647839 [details] [diff] [review]
[MSE] Properly propagate decoding and network errors to media element.

This is not 100% per spec, however neither is our handling of those errors in the media element.
Attachment #8647839 - Flags: review?(cpearce)
Attachment #8647839 - Flags: review?(cpearce) → review+
I think the End Of Stream algorithm should just report the network or decode error to the media element and let the element figure out what to do according to its readyState. It is strange for the algorithm to care about the readyState and tell the element what to do about the error which might contradict the original spec.
Flags: needinfo?(jwwang)
(Assignee)

Comment 5

3 years ago
Thanks.. This is what I did in the patch.

I'm going to remove the comments about TODO because there's nothing more we can do
https://hg.mozilla.org/mozilla-central/rev/c2a85adcd4c0
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox43: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(Assignee)

Updated

3 years ago
Blocks: 1197083
Backed out for a youtube playback regression. See Bug 1199573.
https://hg.mozilla.org/releases/mozilla-aurora/rev/5bb661db5c6c
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
status-firefox42: fixed → affected
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.