[whatwg] Limiting the amount of downloaded but not watched video

[Jeroen Wijering]

On Jan 20, 2011, at 9:14 AM, Philip Jägenstedt wrote:

>>> 
>>> (Since there is some overhead with each HTTP request, one must make sure
>>> that they are not unreasonably small.)
>>> 
>>> When HTTP byte ranges are used to achieve bandwidth management, it's hard
>>> to talk about a single downloadBufferTarget that is the number of seconds
>>> buffered ahead. Rather, there might be an upper and lower limit within which
>>> the browser tries to stay, so that each request can be of a reasonable size.
>>> Neither an author-provided minumum or maximum value can be followed
>>> particularly closely, but could possibly be taken as a hint of some sort.
>> 
>> Does it actually make sense to specify the read-ahead size, or should it
>> simply be a flag (eg. "unlimited", "small buffer" and "don't care")?  Is
>> there really a case for setting the actual read-ahead value directly?  In a
>> sense, that seems akin to allowing web pages to control the TCP buffer sizes
>> used by the client's browser--it's lower level than people usually care
>> about.
>> 
>> In particular, I'm thinking that most of the time all people care about is
>> "read ahead a little" vs. "read ahead a lot", and publishers shouldn't need
>> to figure out the right buffer size to use for the former (and very likely
>> getting it wrong).
> 
> I'm inclined to agree, and we already have a way to say "a little" (preload=none/metadata) and "a lot" (preload=auto).
> 
> However, it'd be great if all implementors could agree on the same interpretation of states. Specifically, this isn't required by the spec but would still be helpful to have consistency in:
> 
> * effective state can only increase to higher states, never go from e.g. metadata to none (it makes no sense)
> * there is a state - invoked - between metadata and auto for when the video is playing
> * there could be a state between invoked and auto for autoplay, but if not autoplay implies preload=auto
> * in the invoked state, a conservative buffering strategy is used by default
> * when paused in the invoked state, we need to agree on what should happen
> 
> If we could agree, then of course it should be documented somewhere, even if it seems somewhat restrictive of the spec to mandate an exact behavior.

Perhaps the conservative buffering strategy should be client-side throttling after all. The pause-to-buffer argument several people put forward is a strong one - a big use case (perhaps more people pause b/c of this than b/c of all other reasons combined). Something like a downloadBufferTarget would be confusing and break this. Client-side throttling won't. 

- Jeroen