Re: waiting and seeking events in media element seek algorithm

On Wed, 10 Feb 2010 03:45:26 +0100, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 1 Feb 2010, Simon Pieters wrote:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking
>>
>> "8. If the media element was potentially playing immediately before it
>> started seeking, but seeking caused its readyState attribute to change
>> to a value lower than HAVE_FUTURE_DATA, the user agent must queue a task
>> to fire a simple event named waiting at the element."
>>
>> We don't want to do this sync in the seek algorithm, because we can't
>> easily tell whether readyState will change at this point. Instead we
>> suggest that waiting be fired as part of this requirement:
>>
>> "When a media element that is potentially playing stops playing because
>> its readyState attribute changes to a value lower than HAVE_FUTURE_DATA,
>> without the element having ended playback, or playback having stopped
>> due to errors, or playback having paused for user interaction, or the
>> seeking algorithm being invoked, the user agent must queue a task to
>> fire a simple event named timeupdate at the element, and queue a task to
>> fire a simple event named waiting at the element."
>>
>> (which needs modification to cover the seeking case)
>>
>> "9. If, when it reaches this step, the user agent has still not
>> established whether or not the media data for the new playback position
>> is available, and, if it is, decoded enough data to play back that
>> position, the user agent must queue a task to fire a simple event named
>> seeking at the element."
>>
>> We think it's better to always fire seeking, because we won't easily be
>> able to tell whether the new position is available.
>
> If you implement .buffered, surely you have all the information you need
> to know how readyState will change and whether the new position is
> available? Why would you not have that information?

.buffered is not updated sync in the seek algorithm. Seeking in Opera  
happens on a different thread. The seek algorithm requires to sync decide  
whether to fire waiting and seeking (and get them in the right order). We  
don't want to lock threads just this. It seems better to always fire  
seeking when seeking and fire waiting later when the playback is actually  
waiting.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 10 February 2010 11:50:18 UTC