[Bug 27242] Clarify how track buffer ranges are updated.

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

--- Comment #2 from Aaron Colwell <acolwell@google.com> ---
(In reply to Mark Watson from comment #1)
> I think the principle should be that if the playback would stall at some
> point, then this would be indicated as a gap in the buffer ranges, but if
> playback would continue then there should be no gap.

Agreed.

> 
> Whether playback stalls or continues through a group of missing B-frames
> could be implementation dependent, but the buffered ranges should correctly
> indicate what the implementation is going to do if no more data is appended.

Agreed. 

If an implementation chooses to stall though it seems like the P-frame should
not be included in the buffered ranges until the B-frames arrive since exposing
the P-frame portion would imply that we could transition to HAVE_CURRENT_DATA
if you seek to the P-frame. It isn't clear to me that systems that need the
B-frames to arrive would actually return the P-frame for display. Allowing the
P-frame to be visible in the buffered ranges could be very confusing to
application developers especially if the SourceBuffer has tons of data after
the P-frame. They might not understand why the media element doesn't transition
to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA if it appears like there is more than
enough data to proceed. 

By keeping the P-frame out of the ranges util the B-frames arrive, I think it
would be clearer to app developers that the SourceBuffer is still waiting for
more data even though the P-frame was appended. WDYT?

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

Received on Wednesday, 4 February 2015 02:00:35 UTC