[Bug 26316] [MSE] End of stream algorithm closes, re-opens MediaSource

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

--- Comment #7 from Jer Noble <jer.noble@apple.com> ---
(In reply to Aaron Colwell from comment #6)
> Jer: I don't think your proposed fix is quite right since deferring the
> readyState transition causes SourceBuffer.buffered to return a different
> value than it currently does.
> 
> I can think of 2 possible alternate solutions:
> - Replace step 4 in the "duration change algorithm" with steps 7-13 from
> remove().

I think this is the right way to go, because:

> - Change step 4 of "duration change algorithm" to only call remove() if any
> SourceBuffer.buffered contains one or more ranges that intersect with [new
> duration, old duration). I believe in the case of endOfStream() this should
> always be false since we are using the end ranges to determine the new
> duration.

Well, that's a different issue, which I haven't written up yet.  But if you use
the highest buffered end time across all MediaSource.sourceBuffers, you'll end
up stalling (dropping to HAVE_METADATA) if you try to play to the (new)
duration, as the currentTime enters into the unbuffered range of the
shorter-buffered SourceBuffer.  And given that the general use case is to have
a separate SourceBuffer for each audio and video stream, and given that each
will have very slightly different durations, due to the irreconcilable
differences in sample durations between the two media types.

Also, the HTMLMediaElement.buffered attribute is also defined to inflate
shorter SourceBuffer.buffered values to the highest end time across all
MediaSource.sourceBuffers.

So either the "SourceBuffer Monitoring" state algorithm has to be amended to
account for these "virtual buffered ranges", or the endOfStream() behavior has
to be changed to truncate the SourceBuffers to the least highest buffered end
time.

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

Received on Thursday, 24 July 2014 18:31:56 UTC