[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 #5 from Aaron Colwell <acolwell@google.com> ---
(In reply to Qin Jiajia from comment #4)
> (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.

I think we should make the MediaSource case consistent with what would happen
in the non-MediaSource case. I believe in the non-MediaSource case playback of
the buffered data and seeking is allowed to continue eventhough more data is
not fetched anymore. This is why I was suggesting simply throwing an exception
when error is non-null instead of closing the MediaSource. It keeps the
buffered data around, but doesn't allow any more to be added.

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

This feels less consistent with the non-MediaSource case to me. This is
essentially equivalent to the "resource fetch algorithm" continuing to run even
though step 1 of the "If the media data is corrupted" sequence explicitly says
"The user agent should cancel the fetching process." Since the UA isn't in
direct control of fetching in the MediaSource case, it seems like preventing
appends, and possibly removes, achieves a good approximation of that intent.

> 
> 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').

At this point, I believe the answer is no. Appends should not be allowed.

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

Received on Wednesday, 19 November 2014 17:16:54 UTC