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

[Glenn Maynard]

On Sat, Jan 22, 2011 at 5:57 AM, Philip Jägenstedt <philipj at opera.com> wrote:
> I agree that there must exist a buffering strategy between strategy=metadata
> and strategy=auto, but it's not clear that this must be exposed as a preload
> state. The only difference between preload=metadata and preload=state3 would
> be that preload=state3 would expect the user to start playing soon and start
> buffering in anticipation of that. Firefox has supported preload=metadata
> (and earlier, lack of autobuffer attribute) for a long time. Is it a problem
> in Firefox that playback is slow to start because too little was buffered
> before suspending?

I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than waiting for a round-trip to begin playing.

Another use case is the background of a game, where you want the video
ready to start when gameplay begins.

> Much work is needed to improve the buffering behavior of <video>, but mostly
> it's an implementation issue at this point. I'm quite open to extensions to
> the API, but we must be careful to not make assumptions about buffering
> strategies. Specifically, an exact downloadTargetBuffer doesn't work very
> well when buffering is done in larger chunks using HTTP byte range requests
> rather than some kind of TCP rate control.

This is why my approach doesn't give direct control over the buffer
size.  You can request that it be limited (preload=buffer) or
unlimited (preload=auto), but the exact buffer size is always up to
the browser.  The actual size should be abstract and not exposed to
scripts; in practice it's probably not even a single number but a
high- and low-watermark.

-- 
Glenn Maynard