Re: waiting and seeking events in media element seek algorithm

On Fri, 26 Mar 2010 06:05:42 +0800, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 10 Feb 2010, Simon Pieters wrote:
>> On Wed, 10 Feb 2010 03:45:26 +0100, Ian Hickson <ian@hixie.ch> wrote:
>> > On Mon, 1 Feb 2010, Simon Pieters wrote:
>> > >
>> > > 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.
>
> Is the new algorithm ok? (It doesn't quite change what you suggested, but
> it does it mostly all async.)
>

Looks better, but the way the seeking event is fired is a bit strange.

First, why the condition "the user agent has still not established whether  
or not the media data for the new playback position is available"? This  
has to do with buffering, and is already indicated by the waiting event.

The second condition, that "the user agent has still not [...] decoded  
enough data to play back that position" is strange. It seems that the only  
way seeking could *not* be fired is if the seek is to the current  
position. If that's the intention, why not state so explicitly? However,  
unless the audio/video is paused, it's impossible to intentionally seek to  
the current position, so I think we should simply *always* fire the  
seeking event. This is what Opera 10.50 does.

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 29 March 2010 04:00:10 UTC