This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1338 [details] Proposed patch In general, the append error algorithm should be used for errors from which it is expected that an app can recover from. Errors where the equivalent behavior in a progressive download would not be recoverable should call endOfStream. The attached patch proposes three changes where the append error algorithm is called but where we think endOfStream makes more sense.
I'm fine with the first two changes since they basically trigger playback to error out if the web application passes in invalid data. The third change that calls endOfStream("network") I'm not so sure about. I would prefer it if the application was able to make this call instead because it may not want to terminate playback if this occurs. I'm assuming this is the case where the HTTP connection closes unexpectedly for some reason. If so then I would prefer the application to be able to handle this without triggering playback to halt because it may want to retry the request or may have alternate backup URLs that it could try (ie different bitrates or alternate CDNs).
The problem is that you don't know what state the buffer is in after a partial append. If we don't halt at this point then we need to somehow get the buffer into a "known good" state.
(In reply to comment #2) > The problem is that you don't know what state the buffer is in after a > partial append. If we don't halt at this point then we need to somehow get > the buffer into a "known good" state. I figured that this was roughly equivalent to abort() being called since the "reset parser state algorithm" is run to put the parser into a known state. The application can look at the buffered attribute to assess what likely got successfully appended in the buffer. It can then choose to retry the append or it could select a different media segment to cover the unbuffered range that would have been covered by the failed append.
(In reply to comment #3) > I figured that this was roughly equivalent to abort() being called since the > "reset parser state algorithm" is run to put the parser into a known state. > The application can look at the buffered attribute to assess what likely got > successfully appended in the buffer. It can then choose to retry the append > or it could select a different media segment to cover the unbuffered range > that would have been covered by the failed append. We agree that we can make this work dropping the third endOfStream("network") change.
Changes committed. https://dvcs.w3.org/hg/html-media/rev/1e6898152c5b The two endOfStream("decode") changes were applied. The endOfStream("network") was left out.