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