W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: waiting and seeking events in media element seek algorithm

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 25 Mar 2010 22:05:42 +0000 (UTC)
To: Simon Pieters <simonp@opera.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1003252205070.29348@ps20323.dreamhostps.com>
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.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 25 March 2010 22:06:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC