Re: <video> readyState oddities

On Sat, 26 Feb 2011 17:36:50 +0100, Eric Carlson <eric.carlson@apple.com>  
wrote:

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

The definition of preload=metadata suggests also fetching (decoding) the  
first frame, which implies moving to at least readyState  
HAVE_CURRENT_DATA. This is rather confusing, but I intend to implement it  
this way, as not decoding the first frame doesn't seem very useful.  
(Additionally, I think that readyState should be pinned at  
HAVE_CURRENT_DATA after that, see the "<video> readyState/networkState  
coupling and event order" thread.)

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

You're right, readyState should revert to HAVE_FUTURE_DATA before the  
buffered data runs out.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Saturday, 26 February 2011 18:10:55 UTC