<video> readyState oddities

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?

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.

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. 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.

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?

Some clarification in the spec would also be most welcome, except in case  
3 which I think is already quite clear.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Wednesday, 16 February 2011 09:39:47 UTC