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

[Andy Berkheimer]

On Tue, Jan 18, 2011 at 5:11 PM, Zachary Ozer <zach at longtailvideo.com> wrote:
> I've heard from some people that they're a bit lost, so I wanted to
> take a moment to summarize.
>
> We have two competing interests here:
>  * Viewers want a smooth playback experience regardless of their
> bandwidth or device. Some viewers may also want to limit the amount
> they download because they're paying for bandwidth. Additionally,
> devices may have memory limitations in terms of how much they're able
> to buffer.
>  * Content providers are worried about bandwidth costs. While they
> want a great experience for viewers, a lot of people click play and
> then watch just a small fraction of their video.

In the case where the viewer does not have enough bandwidth to stream
the video in realtime, there are two basic options for the experience:
- buffer the majority of the video (per Glenn and Boris' discussion)
- switch to a lower bitrate that can be streamed in realtime

This thread has focused primarily of the first option and this is an
experience that we see quite a bit.  This is the option favored
amongst enthusiasts and power users, and also makes sense when a
viewer has made a purchase with an expectation of quality.  And
there's always the possibility that the user does not have enough
bandwidth for even the lowest available bitrate.

But the second option is the experience that the majority of our viewers expect.

The ideal interface would have a reasonable default behavior but give
an application the ability to implement either experience depending on
user preference (or lack thereof), viewing context, etc.  More on that
below.

> Currently, there's no way to stop / limit the browser from buffering -
> once you hit play, you start downloading and don't stop until the
> resource is completely loaded. This is largely the same as Flash, save
> the fact that some browsers don't respect the preload attribute. (Side
> note: I also haven't found a browser that stops loading the resource
> even if you destroy the video tag.)

As an example, I believe Chrome's current implementation _does_ stall
the HTTP connection (stop reading from the socket interface but keep
it open) after some amount of readahead - a magic hardcoded constant.
We've run into issues there - their browser readahead buffer is too
small and causing a lot of underruns.

> There have been a few suggestions for how to deal with this, but most
> have revolved around using downloadBufferTarget - a settable property
> that determines how much video to buffer ahead in seconds. Originally,
> it was suggested that the content producers should have control over
> this, but most seem to favor the client retaining some control since
> they are the most likely to be in low bandwidth situations.
> (Publishers who want strict bandwidth control could use a more
> advanced server and communication layer ala YouTube).

The advanced layer you speak of is naive server-side throttling with
no feedback from the client, and a few tricks to kill the current
progressive download and open a new one for out-of-buffer seeks.  This
has a lot of bad behaviors that we'd like to fix - which comes to the
crux of the issue.

No matter how much data you pass between client and server, there's
always some useful playback state that the client knows and the server
does not - or the server's view of the state is stale.  This is
particularly true if there's an HTTP proxy between the user agent and
the server.  Any behavior that could be implemented through an
advanced server/communication layer can be achieved in a simpler, more
robust fashion with a solid buffer management implementation that
provides "advanced" control through javascript and attributes.


> The simplest enhancement would be to honor the downloadBufferTarget
> only when readyState=HAVE_ENOUGH_DATA and playback is paused, as this
> would imply that there is not a low bandwidth situation.
>
> As an enhancement to this, the browser could always respect the
> downloadBufferTarget until the buffer underruns
> (networkState=NETWORK_LOADING and readyState=HAVE_CURRENT_DATA). At
> this point, the browser could either:
>  * Ignore downloadBufferTarget and load as fast as possible
>  * Double the size of downloadBufferTarget
>
> As a further enhancement, the browser could store these values per
> site so that they are not recalculated on each playback. Finally, if
> there is a playback with no underruns, the browser would reduce
> downloadBufferTarget by some factor to ensure that it is not over
> buffering.
>
> Separately, there has been some discussion about how much buffer needs
> to be retained / when the buffer should be cleared. (I think this
> should be moved off to a separate discussion.)
>
> ==
>
> Personally, I really like the idea of allowing the content provider to
> specify a downloadBufferTarget, but allowing the browser to override
> this based on historical data / current network conditions. I'm not
> sure how much work each of the proposed solutions would be, I think
> that respecting downloadBufferTarget until the buffer underruns and
> then downloading as fast as possible would be fairly straight forward,
> and a big improvement on what's available today.

downloadBufferTarget is a target for how to behave when the network
can keep up with video.  When that is not true, you are in an
exceptional state.

Automatic buffer growth in this situation as a default behavior with
no user or application input seems ill-advised, as this could harm
both the application and the user.

At the very least, the application should be able to override this
behavior if it can do something more appropriate.  For something like
YouTube, there's no one default that's right in every context.  Here's
a more concrete example, though by no means exhaustive or precise:

- be able to determine when the clients network connection can't keep
up using something in the spirit of mozDownloadRate (ok to leave it up
to application to know what fast enough is - remember this is
"advanced")
- be able to set downloadBufferTarget to something large in this
situation if appropriate for the context and our guess at user intent
- be able to observe if the browser could not accept this large
downloadBufferTarget value due to some browser setting (e.g. the
browser has a more explicit signal of user intent)

-Andy