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
