[whatwg] Media protocols and state

[Ian Hickson]

On Mon, 2 Apr 2007, Kevin Calhoun wrote:
>
> I've been evaluating the behavior of the HTMLMediaElement in the current 
> working draft in light of the various network protocols and player 
> behaviors that I'm familiar with, and I think the current specification 
> of loading behavior and the definitions of the buffering, buffered, and 
> bufferingRate attributes are too restrictive.
> 
> Players can be divided roughly into two classes according to their 
> handling of data transfer:
> 
> 1. Data availability precedes playability, seekability, etc.
> 
> Typical case: the client requests a media resource via a transfer 
> protocol such as http and caches the data it receives. It defers 
> playback until enough of the resource is cached for playback to proceed 
> without interruption. Seeking is limited to the range of the media 
> that's available locally.
> 
> 2. Data is loaded on demand in response to a request to perform an 
> operation, e.g. play or seek
> 
> Typical case: in response to a request to play a media resource, the 
> client negotiates with a server to initiate a streaming session, such as 
> an rtp session. Playback proceeds as soon as a minimal amount of data is 
> buffered. Seeking may occur within the full range of the media; when it 
> occurs the client asks the server to stream from the new media time.
> 
> Of course many variants and elaborations of these two strategies are 
> possible. In particular I don't mean to suggest that file transfer 
> protocols are suitable only for the former category or that streaming 
> protocols are suitable only for the latter.
> 
> In the discussions that led to Apple's proposal for media states we made 
> an effort to accommodate a variety of media access protocols. For 
> example, in order to permit appropriate restrictions on seeking 
> operations we expose the notion of the range of media that's available, 
> not the range of media that's buffered, and leave the definition of 
> "availability" up to the UA to accord with the transfer protocol and 
> caching scheme in use. We also tried to stay away from the term 
> "download", as it implies a file transfer.
> 
> Clearly the two broad classes I mention above are very general; would it 
> be helpful to discuss player behaviors in more depth? How well does the 
> current proposal succeed in allowing custom controllers to be 
> implemented that work with a variety of protocols?

As far as I can tell, both of the cases above are in fact handled by the 
current specification. Could you elaborate on how you think the current 
spec is too restrictive?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'