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

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.

== 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?

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 Wed, Jan 19, 2011 at 8:22 AM, Philip J?genstedt <philipj at opera.com> wrote:
> 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
>

Received on Wednesday, 19 January 2011 08:14:23 UTC