[whatwg] Media protocols and state

[Kevin Calhoun]

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?