[Bug 18592] How much is "enough data to ensure uninterrupted playback"

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

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #1 from Mark Watson <watsonm@netflix.com> 2012-08-16 15:38:36 UTC ---
You could ask this question of the media element in the general case. Does
HAVE_ENOUGH mean the UA has enough to be *sure*, 100%, that playback will be
uninterrupted? This is only possible if it has the entire content item. It
would be better named HAVE_ALL... in that case.

If, on the other hand, the difference between these states is just a hint to
the application, giving a UA-specific assessment of whether the rebuffer
probability is low or high, then this is irrelevant in the Media Source case:
the application knows better than the Media Element. In particular the
application knows how much data it has downloaded and not yet passed to the
media element.

I don't think the Media Element should make any measurements of the append
rate, because it has no knowledge of what is causing the append rate to be what
it is: there are many things the application could be doing and possibly
actions it could take to avoid a rebuffer about which the media element has no
idea. For example switching to a different bitrate which could dramatically
change the append rate.

If we wanted to strictly follow the model that player code dealing with UI,
controls etc. should not care whether media source is used or not, then the
state change from FUTURE to ENOUGH should be triggered by the application
through the Media Source API.

Alternatively, the application UI code will need to make its decision on when
to start playback based on indications from the application download/append
code, not on the Media Element state.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 16 August 2012 15:38:41 UTC