This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently SourceBuffer.append() doesn't allow calls in the "ended" readyState. It was brought to my attention that it may be useful to allow appending after endOfStream() is called because the application may want to increase the quality of a region in the presentation. If people think this would be useful, I propose that calling append() while in the "ended" readyState will: 1. Cause MediaSource.readyState to transition to "open" and fire a "sourceopen" on the media source object. 2. Allow the append() to act like it would if it had been called in the "open" state.
Couldn't the application simply not call endOfStream() in this situation?
(In reply to comment #1) > Couldn't the application simply not call endOfStream() in this situation? If you don't call endOfStream(), then you are not guaranteed playback will reach duration if the streams happen to be different lengths. Without end of stream the user agent can't diffentiate missing data at the end of one of the tracks from tracks that have slightly different durations. Admittedly this is an edge case but it is one of the main reasons why the endOfStream() call exists. If we don't allow this, then the application would have to monitor when the playback position is approaching duration and then call endOfStream() right before the end so that all the normal end of playback algorithms will run. Allowing appends to trigger a transition from "ended" back to "open" seemed like a simply way to allow the application to change its mind about being done.
Yeah, I suppose this makes sense if the user has watched the end of the video but then seeks to a part which isn't buffered at all or buffered at a lower bitrate than can currently be achieved.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/7bab66368f2c