Re: <video> readyState oddities

On Wed, 16 Feb 2011 22:35:30 +0100, Chris Pearce <chris@pearce.org.nz>  
wrote:

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

Makes sense, the spec does suggest that the first frame is decoded for  
preload=metadata. This is at odds with the definition of HAVE_METADATA,  
but I guess not many authors will notice this.

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

Makes sense to me. It would be good if the spec were more explicit about  
this, to define that "current playback position" would pause at the latest  
buffered position, not just beyond it. For consistency, I think that  
readyState should end up in HAVE_CURRENT_DATA at the resource end as well.  
That means that the definition of  
<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#ended-playback>  
should be changed to check readyState >= HAVE_CURRENT_DATA, not  
HAVE_METADATA as it now does.

>> 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 is a bit odd. Do you intend to change this to fall all the way back  
to HAVE_METADATA? I don't see what good it would do, but if HAVE_METADATA  
is never used by implementations, it would be good if the spec changed  
accordingly.

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

Indeed, but most state transitions have associated events, so we still  
need consistency. In the seeking case, it's a question of whether or not  
the loadeddata event should fire.

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

I think this is dangerous. With preload=none, I expect browsers to not  
even look at the cache to see if there's data, just staying in  
HAVE_NOTHING regardless. For consistency, I would expect them to stay in  
HAVE_CURRENT_DATA for preload=metadata and not fire a bunch of events just  
because more happened to be in cache. That would lead to a situation where  
pages that use preload=metadata and listen to e.g. the canplaythrough  
event will behave differently depending on what's in cache.

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

Thanks for sharing, I'm curious to know if any other browser is actually  
setting readyState to HAVE_METADATA for long enough for it to be seen by  
scripts?

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 17 February 2011 16:55:41 UTC