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

[Philip Jägenstedt]

On Thu, 20 Jan 2011 01:14:12 +0100, Glenn Maynard <glenn at zewt.org> wrote:

> On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt  
> <philipj at opera.com>wrote:
>
>> If the available bandwidth exceeds the bandwidth of the resource, some  
>> kind
>> of throttling must eventually be used. There are mainly 2 options for  
>> doing
>> this:
>>
>
>> 1. Throttle at the TCP level by not reading data from the socket (not at
>> all to suspend, or at a controlled rate to buffer ahead)
>> 2. Use HTTP byte ranges, making many smaller requests with any kind of
>> throttling at the TCP level
>>
>
> You're talking about Opera's implementation and not in spec, right?

Yes, I'm just sharing my reasoning and conclusions.

> This is
> something UA's should have a lot of freedom with, and I assume this
> low-level detail about how to use HTTP is out of scope for the HTML spec.

While I hope other implementors will take a similar approach (wildly  
different behavior between browsers would like result in worse  
interoperability), the spec shouldn't talk about HTTP or TCP, at least not  
normatively.

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

-- 
Philip Jägenstedt
Core Developer
Opera Software