Re: HTMLMediaElement readyState

Basically, this is reverting the states to the old names, but I am
sympathetic to changing them one last (?) time simply because these
names are better -- more to the point and easy to understand.

Philip

On Wed, 2008-11-19 at 20:52 -0800, Eric Carlson wrote:
> 
>    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
-- 
Philip Jägenstedt
Opera Software

Received on Thursday, 20 November 2008 22:35:36 UTC