- From: Kevin Calhoun <kcalhoun@apple.com>
- Date: Mon, 2 Apr 2007 14:34:19 -0700
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?
Received on Monday, 2 April 2007 14:34:19 UTC