Re: <video> readyState oddities

On Feb 26, 2011, at 5:46 AM, Philip Jägenstedt wrote:

> 
> I'll try to clarify a bit on the problems with readyState and the related events by comparing what I *think* you are trying to say in the spec with what I think actually makes sense and want to implement. Please correct me where I've misunderstood the spec or your arguments in this thread.
> 
> 1. initial loading of a resource
> 
> Hixie/spec: Initially, readyState is HAVE_NOTHING. When the duration and the intrinsic size of the video is determined, readyState changes to HAVE_METADATA. When the first frame has been decoded, readyState changes to HAVE_CURRENT_DATA. When the second frame has been decoded, readyState changes to HAVE_FUTURE_DATA. When the buffered data and buffering speed is such that one could probably play through to the end without pausing, readyState changes to HAVE_ENOUGH_DATA.
> 
> Me: Here, the difference between HAVE_METADATA, HAVE_CURRENT_DATA and HAVE_FUTURE_DATA is clear, but extremely narrow. Since the events are fired asynchronously, by the time the loadedmetadata event handler is run it's very likely that at least one frame has been decoded and readyState > HAVE_METADATA. Since scripts that try to paint the first frame of the video to <canvas> in the loadedmetadata event handler will work most of the time and only fail if the network is very slow, implementations would do best to pin readyState to HAVE_NOTHING until the first frame is decoded, then skipping directly to HAVE_CURRENT_DATA, firing the loadedmetadata and loadeddata events.
> 
  Pinning readyState to HAVE_NOTHING until the first frame is decoded doesn't make sense at least when preload=metadata. For media formats with a "table of contents" chunk it is certainly possible to download the metadata and no media samples, so HAVE_METADATA is the appropriate state in some situations.


> 2. playback stops due to reaching the end of resource
> 
> Hixie/spec: readyState is HAVE_ENOUGH_DATA when approaching the end. As the last frame is reached readyState drops to HAVE_CURRENT_DATA.
> 
> Me: I agree with this, if I've interpreted the spec correctly.
> 
  I missed that readyState should drop to HAVE_CURRENT_DATA when playback has ended until now, so WebKit doesn't currently do the right thing (https://bugs.webkit.org/show_bug.cgi?id=55299), but I agree that the spec logic makes sense.


> 3. playback stops due to waiting for the network
> 
> Hixie/spec: Before the buffered data runs out, readyState is HAVE_FUTURE_DATA (or possibly HAVE_ENOUGH_DATA if the original guess for when to transition to HAVE_ENOUGH_DATA was wrong). 

  How can readyState be HAVE_ENOUGH_DATA when buffered data runs out? Even if the initial guess about when to transition was wrong or if network throughput drops after reaching HAVE_ENOUGH_DATA, the UA should revert to HAVE_FUTURE_DATA at the point that it determines that play-through won't succeed.


> When the last available frames is displayed, readyState drops to HAVE_CURRENT_DATA. Then, currentTime increases by epsilon beyond the last frame so that readyState drops to HAVE_METADATA, but the difference can not be seen in currentTime. When data again becomes available over the network, one will again transition through HAVE_CURRENT_DATA and HAVE_FUTURE_DATA like for the intial loading of a resource, with only one frame setting them apart.
> 
> Me: Again, the difference between HAVE_CURRENT_DATA and HAVE_METADATA is extremely narrow and hardly useful. I'd like readyState to stay at HAVE_FUTURE_DATA until the end of the last available frame is reached, at which point it drops to HAVE_CURRENT_DATA and stays there.
> 

  I agree.


> 4. seeking
> 
> Hixie/spec: When seeking to an unbuffered position, readyState drops to HAVE_METADATA. Then, one transitions through HAVE_CURRENT_DATA and HAVE_FUTURE_DATA as data becomes available, much like for an initial load.
> 
> Me: This seems mostly sensible. It's useful that scripts can wait for the loadeddata event (fired in the HAVE_METADATA => HAVE_CURRENT_DATA transition) to know that the current frame is available. The canplay event is quite useless though, see the bug I filed.
> 
  I agree.

eric

Received on Saturday, 26 February 2011 16:37:25 UTC