On Jan 18, 2011, at 16:16 , Glenn Maynard wrote:
> On Tue, Jan 18, 2011 at 6:54 PM, David Singer <sin...@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.
