HTMLMediaElement readyState

   We believe the media element readyState states [1] need a bit more  
refinement.

   First, HAVE_SOME_DATA is unnecessary because it describes the same  
state as HAVE_METADATA - the UA doesn't have enough media to render  
anything. It is true that HAVE_SOME_DATA tells you there is data  
*somewhere* that can be displayed, but that isn't terribly useful.

   The second, and more important, problem is that the states are  
written (a) from the point of view of how the resource feels about  
itself instead of how it can be used, and (b) they are quite download- 
centric.  For example the spec says a media resource can be played  
when it is in the HAVE_FUTURE_DATA state, but a 'playable' streaming  
resource may have *zero* future data when it is as playable as it will  
ever be - it just has a network connection over which it can request  
the server to begin playing.

   The state descriptions have been rewritten below to accommodate  
streamed media resources, and we have changed the state prefixes from  
"HAVE_" to "CAN_" to emphasize that the states describe what can be  
done with the element. The first state doesn't really work with that  
prefix so it is called EMPTY, suggestions for another name are welcome.

EMPTY (numeric value 0)
	No information regardig the media resource is available. No media  
data is available. Media elements whose networkState attribute is  
NETWORK_EMPTY are always in the EMPTY state.

CAN_QUERY_METADATA (numeric value 1)
	Enough of the resource has been obtained that the metadata attributes  
are initialized (e.g. the duration is known, etc). The API will no  
longer raise an exception when seeking.

CAN_DISPLAY (numeric value 2)
	Enough of the resource is available to display at the current  
playback position,but nothing more. For a downloadable video this  
corresponds to the user agent having data for the current frame, but  
not the next frame.

CAN_PLAY (numeric value 3)
	Data for the current playback position is available, as well as  
enough data for the user agent to advance the current playback  
position at least a little without immediately reverting to the  
CAN_DISPLAY state. For example, in a downloadable video this  
corresponds to the user agent having data for at least the current  
frame and the next frame. The user agent does not have any future data  
for streaming resource in this state, but it has enough information to  
request that the stream begin playing.

CAN_PLAY_THROUGH (numeric value 4)
	Data for the current playback position is available, as well as  
enough data for the user agent to advance the current playback  
position at least a little without immediately reverting to the  
CAN_PLAY state. In addition, the user agent estimates that data is  
being fetched at a rate where the current playback position, if it  
were to advance at the rate given by the defaultPlaybackRate  
attribute, would not have to pause to re-buffer before playback  
reaches the end of the media resource. This state may never be reached  
if the network bandwidth is insufficient and the resource cannot be  
cached, either because of cache limitations or because it is a  
streaming service.

eric
>


[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#the-ready-states

Received on Thursday, 20 November 2008 04:53:13 UTC