[Webkit-unassigned] [Bug 139439] [MSE] Sending media segment without any init segment should call endOfStream.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=139439

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

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

--- Comment #3 from Bartlomiej Gajda <b.gajda at samsung.com> ---
> Doesn't this look like a spec bug, that MediaSource.endOfStream() is
> supposed to call the Append Error Algorithm (on SourceBuffer) without
> stating explicitly /which/ SourceBuffer is supposed to run the algorithm? 

> After all, what if someone calls "endOfStream('decode')"?

While it's certainly not as clear as possible, I think this particular scenario - with calling endOfStream('decode') is well guarded by :

"2.2 Methods / endOfStream
If the updating attribute equals true on any SourceBuffer in sourceBuffers, then throw an INVALID_STATE_ERR exception and abort these steps."

So in such case, we won't go into Append Error Algorithm, as we return early. 
And when SourceBuffer is not updating, then we won't go there as well, due to: 

"2.4.7 If error is set to "decode"
   If updating equals true, then run the append error algorithm."

So it seems the only way to actually call it, is by manually calling end of stream algorithm(streamEndedWithError (not the best name anymore)) - which happens only if SourceBuffer calls it - hence this change.

I do agree however that this is a litle confusing. 

> It's a little weird to pass in a SourceBuffer to MediaSource.streamEndedWithError().  

For now I could change it to, SourceBuffer calling :

(new) MediaSource::sourceBufferEndOfStreamDecodeError(SB* sb) {
 if (sb->updating()) // or ASSERT actually as it would be weird if called in different context
  sb->appendError()
 streamEndedWithError("decode");
}

So we would discard the default parameter. 
I think we could go with this hardcoded "decode" error design, as there is no "network" eos() inside SB.

This would work for now, as order of event would be the same from outside I guess, since "decode" endOfStream() path start with this "append error" check anyway.
Would that look better to You?

Also other places in SB which do streamEndedWithError(decode) shall use this new approach but in this patch I had not yet figured layout tests for each of those, so I thought I'll add them later.

> Wouldn't it make more sense for the 3.5.1 - 6.1 step to call the Append
> Error Algorithm, which in turn calls the Stream Ended Algorithm (rather than
> vice versa)?

The easiest way would be if 3.5.1 6.1 would call both directly, as in 3.5.6 for example even though there is AppendError there is no `end of stream: decode`.

> There was a bug <https://bugs.webkit.org/show_bug.cgi?id=138394> about
> events from different GenericEventQueues being fired out of order. Is that
> change in your tree?

It should be, but I'll check it out later. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141210/5eef880a/attachment-0002.html>