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

On Thu, Jan 20, 2011 at 3:14 AM, Philip J?genstedt <philipj at opera.com>wrote:

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

I think that pausing shouldn't affect read-ahead buffering behavior.  I'd
suggest another preload value, preload=buffer, sitting between "metadata"
and "auto".  In addition to everything loaded by "metadata", it also fills
the read-ahead buffer (whether the video is playing or not).

- If a page wants prebuffering only (not full preloading), it sets
preload=buffer.  This can be done even when the video is paused, so when the
user presses play, the video starts instantly without pausing for a server
round-trip like preload=metadata.
- If a page wants prebuffering while playing, but unlimited buffering when
paused (per Zachary's suggestion), it sets preload=buffer when playing and
preload=auto when paused.
- As a more complex example, a page might use preload=metadata (or none) on
an initially paused video, changing it to preload=buffer when playing, and
to preload=auto if paused after playing.  This minimizes bandwidth use if
the video is never played (especially important if you have lots of videos
on the same page), allows selecting whether the initially-paused state is
"metadata" or "none" (depending on how much bandwidth you want to save), and
uses Zachary's preload-only-when-paused only after the video has been played
at least once and then paused again (eg. because the user noticed it was
underrunning).

-- 
Glenn Maynard

Received on Thursday, 20 January 2011 01:19:03 UTC