[Bug 27342] Clarify if the source buffer is still valid when appendBuffer/appendStream meets 'decode' error

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27342

--- Comment #3 from Aaron Colwell <acolwell@google.com> ---
(In reply to Qin Jiajia from comment #2)
> (In reply to Aaron Colwell from comment #1)
> > If you look at the "If the media data is corrupted" step in the HTML5 spec
> > (http://www.w3.org/TR/html5/embedded-content-0.html#fatal-decode-error) you
> > will see that there is a step that causes networkState to get set to
> > NETWORK_EMPTY. This causes the "Detaching from a media element" algorithm
> > (https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-
> > source.html#mediasource-detach) to run. That is why there is a transition to
> > "closed".
> You are right if media element is going to transition to NETWORK_EMPTY. But,
> if it changes to NETWORK_IDLE, what will happen to MediaSource? Does it
> still work?

Ok. Now I see what you are saying. My eyes were playing tricks on me and I was
actually reading step 4 of the "If the media data is corrupted" algorithm in
the opposite sense. Based on my current understanding, the condition in the
"end of stream algorithm" actually guarantees that networkState will always
transition to NETWORK_IDLE instead of NETWORK_EMPTY so I see your point now.

I'll need to think about this a little more because I had always intended for
this path to result in the MediaSource closing. If we decide to change this to
allow further appending, at a minimum we'll need to call the "reset parser
state" algorithm to recover from the corrupted data and put the parser in a
known state. I'll need to look at the HTML5 spec a little closer to get a sense
of what is still allowed if the "resource selection algorithm" is aborted. It
isn't clear to me right now whether allowing appends to proceed after this
makes sense or is consistent with "normal non-MSE" playback. 

In the non-MSE case, I believe the UA doesn't try to download any more data
once the "resource selection algorithm" gets aborted. This seems like it would
be equivalent to preventing further appends until the "resource selection
algorithm" is initiated again. Perhaps the MediaSource shouldn't close, but
instead appendBuffer/appendStream should throw an InvalidStateException if
HTMLMediaElement.error is non-null? What do you think?

> 
> > Based on this, I don't believe there is a conflict in the MSE spec. A
> > compliant implementation should transition readyState to "ended" as a result
> > of running the end of stream algorithm, and then transition readyState to
> > "closed" as a result of the detaching from a media element algorithm being
> > run because networkState got transitioned to NETWORK_EMPTY.
> > 
> > I can add a note under the "Run the media data is corrupt steps of the
> > resource fetch algorithm." saying something like "This step can cause the
> > 'detaching from a media element algorithm' to run."
> Only transition to NETWORK_EMPTY will call "Detaching from a media element"
> or NETWORK_EMPTY and NETWORK_IDLE both can call this algorithm?

As specified right now only the transition to NETWORK_EMPTY. I would not be
surprised if Chrome currently doesn't make this distinction and always closes
the MediaSource. If this is happening, this is technically a bug in Chrome
right now.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 18 November 2014 19:14:58 UTC