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

[Glenn Maynard]

On Wed, Jan 19, 2011 at 11:14 AM, Zachary Ozer <zach at longtailvideo.com>wrote:

> Two ideas just struck me:
>
> == Network API calls ==
>
> What if, instead of trying to solve this problem, we leave it up to
> the publishers. The current behavior would be unchanged, but we could
> add explicit bandwidth management API calls, ie startBuffer() and
> stopBuffer(). This would let developers / site publishers control how
> much to buffer and when.
>

This is a lot to push onto developers; the browser should be handling this.
If it's too hard for browsers to get right, then it's going to be even
harder to get it right from Javascript.

== User Behavior ==
> We might also consider leaning on users a bit to tell us what they
> want. For example, I think people are pretty used to hitting play and
> then pause to buffer until the end of the video. What if we just used
> our bandwidth heuristics while in the play state, and buffered blindly
> when a pause occurs less than X seconds into a video? I won't argue
> that this is a wonderful solution (or a habit we should encourage),
> but I figured I'd throw a random idea out there…
>

My first impression is that this is strange, but my second is that it may be
the only way available.  In particular, we need to know *when* we're short
on bandwidth, and thus need to pause and download most of the video before
continuing.  I don't think any auto-detection mechanism will be reliable,
and having the user tell us makes sense, but regular users won't understand
a context menu "[x] preload whole video".  Doing a full preload when paused
seems discoverable--after all, that's exactly what users do on YouTube when
a video isn't buffering fast enough.

However, I think this should be implemented by scripts, not the browser.  If
a downloadBufferTarget property is exposed, that's easy to do: when the user
pauses, set downloadBufferTarget to its "unlimited" value, and set it back
when the video is unpaused.

The reason for this is interactions with other features.  For example, a
video may default to being paused; that shouldn't disable prebuffer limits.
Also, video players often leave the video paused if the tab is loaded in the
background, so open-in-background-tab and browser session restoring don't
cause videos to start playing[1].  (www.ted.com does this.)  This shouldn't
have the side-effect of removing preload limits.  If it's controlled by
scripts, these interactions can be managed properly.



[1] I'm not sure if this is actually possible right now, and it's
important--there's little more annoying than loading a browser session and
having a video start playing somewhere.  This is probably a significant use
case for the "tab visibility" proposal.

-- 
Glenn Maynard