[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 #6 from Qin Jiajia <jiajia.qin@intel.com> ---
(In reply to Aaron Colwell from comment #5)
> (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.
> 
Agree. Thanks for your explanation.

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

Received on Thursday, 20 November 2014 07:02:01 UTC