[Bug 27548] [MSE] Unspecified behavior when clients call endOfStream("decode').

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27548

Bartlomiej Gajda <b.gajda@samsung.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b.gajda@samsung.com

--- Comment #2 from Bartlomiej Gajda <b.gajda@samsung.com> ---
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.

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

Received on Wednesday, 10 December 2014 02:36:38 UTC