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

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

--- Comment #8 from Aaron Colwell <acolwell@google.com> ---
(In reply to Jer Noble from comment #7)
> (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:

Ok. I'll do this then.

> 
> > - 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.

I'm pretty sure the "SourceBuffer Monitoring" algorithm needs to be updated. It
hasn't gotten much love in a long time and I wouldn't be surprised if there are
bugs lurking in there. readyState transitions should definitely be driven of
HTMLMediaElement.buffered ranges and not individual SourceBuffer.buffered since
during non-endOfStream playback the intersection used should make sure that we
don't try to play unbuffered regions. I'll take a look at the algorithm and
file a bugs for any problems with the algorithm I see.

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

Received on Thursday, 24 July 2014 20:24:43 UTC