[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 #4 from Qin Jiajia <jiajia.qin@intel.com> ---
(In reply to Aaron Colwell from comment #3)
> (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?
I think if MediaSource doesn't close, it means this MediaSource is still
workable. Assume that let appendBuffer/appendStream throws an
InvalidStateException when HTMLMediaElement.error is non-null. So, in what kind
of situation, the SourceBuffer can apppendBuffer/appendstream again when having
met the 'decode' error? It seems there is no such kind of situation. Then, it
becomes meaningless not to close MediaSource when there is 'decode' error.

But in another side, if we meet 'decode' error, maybe we only need to call '
reset parser state algorithm', wait for new data and don't need to notify
HTMLMediaElement. So the media pipeline is still active. Then, the UA can use
appendBuffer/appendStream for new data.

In sum, We need to figure out whether MediaSource/SourceBuffer can still use
when appendBuffer/appendStream faild (via end of stream algorithm with
parameter 'decode').

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

Received on Wednesday, 19 November 2014 10:38:12 UTC