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

[Zachary Ozer]

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.

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

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

Best,

Zach
--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com • e: zach at longtailvideo.com • p: 212.244.0140 •
f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution



On Tue, Jan 18, 2011 at 1:40 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 1/18/11 6:09 AM, Glenn Maynard wrote:
>>
>> I'm confused--how is the required buffer size a function of the length of
>> the video?  Once the buffer is large enough to smooth out network
>> fluctuations, either you have the bandwidth to stream the video or you
>> don't; the length of the video doesn't enter into it.
>
> The point is that many users _don't_ have enough bandwidth to stream the
> video.  At that point, the size of the buffer that puts you in
> HAVE_ENOUGH_DATA depends on the length of the video.
>
> -Boris
>
>