Re: <video> readyState oddities

I think more important than the HAVE_METADATA state is the event
"onloadedmetadata". As long as we don't remove the event with the
state, I - speaking as a Web author - would not find it a problem when
the state was removed.

Cheers,
Silvia.

On Fri, Feb 18, 2011 at 3:55 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> 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 Friday, 18 February 2011 02:52:17 UTC