This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27548 - [MSE] Unspecified behavior when clients call endOfStream("decode').
Summary: [MSE] Unspecified behavior when clients call endOfStream("decode').
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: CR
Assignee: Aaron Colwell
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-09 17:05 UTC by Jer Noble
Modified: 2014-12-12 16:33 UTC (History)
4 users (show)

See Also:


Attachments

Description Jer Noble 2014-12-09 17:05:49 UTC
"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
Comment 1 Jer Noble 2014-12-09 17:06:38 UTC
This refers to "2.4.7 End of stream algorithm".
Comment 2 Bartlomiej Gajda 2014-12-10 02:36:37 UTC
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.
Comment 3 Bartlomiej Gajda 2014-12-10 02:43:47 UTC
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.
Comment 4 Aaron Colwell 2014-12-11 00:40:50 UTC
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."
Comment 6 Bartlomiej Gajda 2014-12-12 02:57:11 UTC
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".
Comment 7 Aaron Colwell 2014-12-12 16:33:16 UTC
(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