Re: <video> readyState oddities

On 16/02/2011 10:39 p.m., Philip Jägenstedt wrote:
> It seems to me that the HAVE_METADATA and HAVE_CURRENT_DATA are mostly 
> redundant and that differentiating between them isn't very useful.
>
> Specifically:
>
> 1. For <video preload=metadata>, one would reasonably expect 
> readyState to go no further than HAVE_METADATA. Yet, by decoding the 
> first frame, one would be able to go to HAVE_CURRENT_DATA. Should a UA 
> do so, or pretend to still be in HAVE_METADATA to match the reasonable 
> expectation that preload=metadata will stop at HAVE_METADATA?

Firefox decodes and displays the first frame, which causes it to go to 
HAVE_CURRENT_DATA.

>
> 2. When you run out of buffered data when playing normally, should 
> readyState revert to HAVE_CURRENT_DATA or HAVE_METADATA? The answer 
> depends on what currentTime is at that point, it seems.

Firefox won't drop below HAVE_CURRENT_DATA once it's passed it, the 
logic being that we're still able to display the frame which we're 
currently displaying. So we drop back to HAVE_CURRENT_DATA in this case.

>
> 3. When seeking, HAVE_METADATA means that nothing has been decoded at 
> the new currentTime and HAVE_CURRENT_DATA means that one has at least 
> decoded one frame. 

Firefox switches to HAVE_CURRENT_DATA while seeking. We continue to 
display the frame which was the "current frame" when the seek operation 
started, until the seek completes. I guess this is a relic from before 
the seek algorithm changed to set the currentTime synchronously when the 
seek is initiated.

> This makes sense, but scripts can't do anything useful with this, 
> since the related events are fired asynchronously and any checking of 
> readyState is going to be a race condition.

Because of asynchronous state change events, I'm not sure how useful 
readyState is anyway. You don't really want to poll for readyState 
changes, so you want to rely on the asynchronous events anyway.

>
> It's too late to change the readyState enum, but I'd be interested to 
> hear how other browser vendors have approached this issue.
>
> Related to case 1 above: If the network is really fast or the resource 
> was already in cache one could have enough data to go immediately to 
> HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA. In these cases, should we 
> pretend to still be in HAVE_METADATA/HAVE_CURRENT_DATA, or tell the 
> truth and have scripts break if they assume that the network is slow 
> or that the resource isn't in cache?

The UA should probably just go to HAVE_ENOUGH_DATA in if it can play 
through the resource; preload is only a "hint" anyway...

When polling readyState at my preload test at 
http://pearce.org.nz/video/preload-video.html I never saw Firefox4 pass 
through HAVE_METADATA. It seems a pretty redundant state really.


Chris P.

Received on Wednesday, 16 February 2011 22:09:50 UTC