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

On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer <zach at longtailvideo.com> wrote:
> On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard <glenn at zewt.org> wrote:
>> 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).
>
> Would the read-ahead buffer length be a configurable property?
...
> * Adding the "downloadTargetBuffer" property, which can be updated at any time

I don't think we've seen any use cases for directly configuring the
read-ahead buffer size (downloadTargetBuffer).  The closest to one
that was mentioned is essentially to work around browser bugs: if a
browser selects too small of a buffer, you can increase it.

If this is configurable, then a default value (eg. null) should mean
"browser-determined", and people should be strongly encouraged to use
it for prebuffering, not setting a specific number.

> * Once the user has indicated they want to play a video, the browser
> ?will go into state3 and buffer at least "downloadTargetBuffer" seconds
> ?of video before playing

Be careful here: this greys the line between "minimum prebuffer" and
"maximum buffer size".  That is, you may want to buffer up to 30
seconds of video, but to start playing after 5 seconds of video is
buffered.  The above means that if you set downloadTargetBuffer="30",
the video won't start playing for a long time, since
downloadTargetBuffer is doubling as both the minimum and maximum
values.

> ?> If the buffer < "downloadTargetBuffer" seconds:
> ? - The browser will set preload = "auto"

This is odd: you can't reset preload=auto to preload=state3 if less
than downloadTargetBuffer is currently buffered.  For example, if the
user is implementing "preload=auto only when paused", and
downloadTargetBuffer is effectively 30 seconds, then pausing (and
setting preload=auto) then unpausing (and resetting to preload=buffer)
could cause preload to get stuck in auto.

I think the approach of making preload a state variable is a bit odd.
Here's an rough alternative proposal, which is based on leaving
preload as a simple hint as it is now, and deriving
downloadTargetBuffer from it:

- downloadTargetBuffer is a derived (read-only) property that tells
the browser the minimum amount it should attempt to prebuffer.  This
applies independently of any other state.
- If preload=auto, downloadTargetBuffer value is infinity.
- If preload=none or meta AND the video is paused, downloadTargetBuffer is zero.
- In all other cases,
    downloadTargetBuffer is browser-determined as the amount necessary
to play the video without underruns, and may change over time.
    If the browser determines that there's insufficient bandwidth to
stream the video, downloadTargetBuffer is forced to infinity.  (This
is actually redundant with the previous line.)

The minimum amount to buffer before playback can begin (eg. the
transition from HAVE_CURRENT_DATA to HAVE_FUTURE_DATA) is unrelated to
this proposal.  We're only talking about maximum buffering, not
minimum.

If we want to allow the user to further influence
downloadTargetBuffer, do so with separate non-derived properties (eg.
"minimumReadAhead").

> What if my bandwidth situation improves (moving from 3g to WiFi, for example)?
> At that point, perhaps I should go from auto to invoked?

The above also addresses this.  The browser's determination of whether
you have enough bandwidth or not is reflected only in the value of
downloadTargetBuffer.  It can be increased or decreased however the
implementation sees fit, eg. in response to having more bandwidth
available (switching to WiFi), or in response to the server adjusting
the bitrate of your stream.

It's not clear to me that unclamping prebuffering is actually a
meaningful response to having insufficient bandwidth, but this leaves
that decision up to the implementation.

-- 
Glenn Maynard

Received on Thursday, 20 January 2011 18:12:40 UTC