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

[Philip Jägenstedt]

On Wed, 19 Jan 2011 10:42:01 +0100, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
> <jeroen at longtailvideo.com> wrote:
>> We are getting some questions from JW Player users that HTML5 video is  
>> quite wasteful on bandwidth for longer videos (think 10min+). This  
>> because browsers download the entire movie once playback starts,  
>> regardless of whether a user pauses the player. If throttling is used,  
>> it seems very conservative, which means a lot of unwatched video is in  
>> the buffer when a user unloads a video.
>
> A lot of people are complaining about this right now, and it needs to
> be addressed, but nothing I've seen makes it clear that it's a spec
> issue rather than QoI.  I.e., will this still be a problem once all
> browsers reliably implement preload="" and iron our their video fetch
> behavior a bit more?  Are non-Mozilla browsers working on preload=""?

I'm working on <video preload> right now, so have had reason to think a  
lot about this recently. At first sight exposing something like  
downloadBufferTarget seems quite reasonable, but things are complicated,  
as usual...

== Preload States ==

The 3 preload states imply 3 simple buffering strategies:

none: don't touch the network at all
preload: buffer as little as possible while still reaching readyState  
HAVE_METADATA
auto: buffer as fast and much as possible

However, the state we're discussing is when the user has begun playing the  
video. The spec doesn't talk about it, but I call it:

invoked: buffer as little as possible without readyState dropping below  
HAVE_FUTURE_DATA (in other words: being able to play from currentTime to  
duration at playbackRate without waiting for the network)

== Bandwidth Management ==

If the available bandwidth exceeds the bandwidth of the resource, some  
kind of throttling must eventually be used. There are mainly 2 options for  
doing this:

1. Throttle at the TCP level by not reading data from the socket (not at  
all to suspend, or at a controlled rate to buffer ahead)
2. Use HTTP byte ranges, making many smaller requests with any kind of  
throttling at the TCP level

After much deliberation, I've tentatively concluded that option 2 is best  
on balance, for the following reasons:

* Browsers already have the infrastructure to do byte range requests for  
<video>
* More requests gives the server more opportunities to do load balancing
* Servers may limit the number of concurrent requests, and the long-lived  
requests caused by TCP throttling add to the total
* Using HTTP byte range requests, connections don't live longer than  
necessary and it's possible to interleave fetching of many resources from  
the same server
* Smooth reverse playback (playbackRate < 0) is only possible using byte  
range requests (or waiting for the whole resource to buffer, which could  
be impossible with a limited cache size)
* HTTP pipelining should ensure that a new connection doesn't need to be  
established if the requests are not too far apart

(Since there is some overhead with each HTTP request, one must make sure  
that they are not unreasonably small.)

When HTTP byte ranges are used to achieve bandwidth management, it's hard  
to talk about a single downloadBufferTarget that is the number of seconds  
buffered ahead. Rather, there might be an upper and lower limit within  
which the browser tries to stay, so that each request can be of a  
reasonable size. Neither an author-provided minumum or maximum value can  
be followed particularly closely, but could possibly be taken as a hint of  
some sort.

== User Expectations ==

The above buffering strategies are still not enough, because users seem to  
expect that in a low-bandwidth situation, the video will keep buffering  
until they can watch it through to the end. These seem to be the options  
for solving the problem:

* Make sites that want this behavior set .preload='auto' in the 'paused'  
event handler
* Add an option in the context menu to "Preload Video" or some such
* Cause an invoked (see dfn above) but paused video to behave like  
preload=auto
* As above, but only when the available bandwidth is limited

I don't think any of these solutions are particularly good, so any input  
on other options is very welcome!

-- 
Philip Jägenstedt
Core Developer
Opera Software