[whatwg] Limiting the amount of downloaded but not watched video
glenn at zewt.org
Wed Jan 19 16:14:12 PST 2011
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
> 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? 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.
> (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
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).
More information about the whatwg