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

[David Singer]

On Jan 18, 2011, at 16:16 , Glenn Maynard wrote:

> On Tue, Jan 18, 2011 at 6:54 PM, David Singer <singer at apple.com> wrote:
> 
>> I feel like we are asking this question at the wrong protocol level.
>> 
>> If you use the HTML5 video tag, you indicate the resource and the protocol
>> used to get it, in a URL.
>> 
>> If you indicate a download protocol, you can hardly be surprised if, well,
>> download happens.
>> 
> 
> HTTP isn't a "download protocol"--I'm not really sure what that means--it's
> a transfer protocol.  Nothing about HTTP prevents capping prebuffering, and
> nothing about an HTTP URL implies that the entire resource needs to be
> downloaded.
> 
> This setting is relevant for any protocol, whether it's a generic one like
> HTTP or one designed for streaming video.  This isn't a discussion about
> HTTP; it's one about an interface to control prebuffering, regardless of the
> underlying protocol.  I havn't seen it suggested that any difficulty of
> doing this is due to HTTP.  If you think it is, it'd be helpful to explain
> further.


I'm sorry, perhaps that was a shorthand.

In RTSP-controlled RTP, there is a tight relationship between the play point, and play state, the protocol state (delivering data or paused) and the data delivered (it is delivered in precisely real-time, and played and discarded shortly after playing).  The server delivers very little more data than is actually watched.

In HTTP, however, the entire resource is offered to the client, and there is no protocol to convey play/paused back to the server, and the typical behavior when offered a resource in HTTP is to make a simple binary decision to either load it (all) or not load it (at all).  So, by providing a media resource over HTTP, the server should kinda be expecting this 'download' behavior.

Not only that, but if my client downloads as much as possible as soon as possible and caches as much as possible, and yours downloads as little as possible as late as possible, you may get brownie points from the server owner, but I get brownie points from my local user -- the person I want to please if I am a browser vendor.  There is every incentive to be resilient and 'burn' bandwidth to achieve a better user experience.

Servers are at liberty to apply a 'throttle' to the supply, of course ("download as fast as you like at first, but after a while I'll only supply at roughly the media rate").  They can suggest that the client be a little less aggressive in buffering, but it's easily ignored and the incentive is to ignore it.

So I tend to return to "if you want more tightly-coupled behavior, use a more tightly-coupled protocol"...

David Singer
Multimedia and Software Standards, Apple Inc.