- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 20 Nov 2008 23:34:46 +0100
- To: Eric Carlson <eric.carlson@apple.com>
- Cc: HTML WG <public-html@w3.org>
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