This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"If error is set to "decode" If updating equals true, then run the append error algorithm." If the client calls `mediaSource.endStream("decode");`, it is unspecified against which SourceBuffer should the algorithm run the Append Error Algorithm. (And in other cases, leads to weird implementation requirements, like the SourceBuffer having to tell the MediaSource which SourceBuffer is triggering the stream ended algorithm.) I propose the following changes: * The Append Error Algorithm will itself call the End Of Stream Algorithm. * The End of Stream Algorithm will no longer call the Append Error Algorithm. * The "run the end of stream algorithm" step be replaced by "run the append error algorithm" in the following places: * Byte Stream Formats * Segment Parser Loop * Initialization Segment Received * Coded Frame Processing
This refers to "2.4.7 End of stream algorithm".
As I wrote in discussion on webkit bugzilla (https://bugs.webkit.org/show_bug.cgi?id=139439) 1. MediaSource.endOfStream('decode') does not need to know which SB calls it, because if any SB is updating it will return early; (and if it's not, it won't call 'append error' as a part of `end of stream algorithm`) 2. There are places in "3.5.6 Stream Append Loop" which calls AppendError, but not endOfStream, so reversing order of execution (from eos->appenderror to appenderrror->eos) would make them call it, which would perhaps change intention of how stream parsing works. I do agree however that this might not be the best design, and adding : "2.4.7. 3.3.1 : If updating equals true, then run the append error algorithm." Seems a little like rushed decision to save typing. If i'm correct every other algorithm in MediaSource operates on 'all SB', or on 'all activeSB', not 'some particular SB' that called it'. I propose redundancy option - all places in SB which calls eos(`decode`), would call appendError before, which would make it's implementation elegant, and clean, as SB would call his own method, not ask MS to call a method on himself. Of course it can still be implemented this way, as effectively, `append Error Algorithm` is first thing in `end of stream "decode"` code path, but wording could be improved I guess.
Oh, actually it's not "the first thing", as there is schedule event 'ended' so calling from SB first `append error`, then `end of stream` would change events order from: (MS) sourceended, (SB) error, (SB) updateend to : (SB) error, (SB) updateend, (MS) sourceended which might not be intended decision.
I agree w/ Jer's assessment. I think this was unintended behavior that snuck in when I was addressing Bug 25846. I am also fine with changing the event order since it seems more natural to me for the SourceBuffer events to fire before the MediaSource events. The current order is just because I wasn't paying attention to this when I added the step to the "End of stream algorithm."
Change committed.. https://github.com/w3c/media-source/commit/ec922867d95aef04e2ed2b7c2276e19c1acb7f6e
There is an omission after this change in 3.5.3: "This algorithm is called an error occurs during an append. T" should be "__when__ an error".
(In reply to Bartlomiej Gajda from comment #6) > There is an omission after this change in 3.5.3: > > "This algorithm is called an error occurs during an append. T" > > should be "__when__ an error". Oops. Just committed the fix. https://github.com/w3c/media-source/commit/27f9df918a89df69deced4033204c7f7bcc7720c