Re: media element seek algorithm: don't throw

I've changed seeking to work asynchronously, based on the feedback on this 
thread.

On Wed, 10 Feb 2010, Robert O'Callahan wrote:
> On Wed, Feb 10, 2010 at 3:50 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Wed, 3 Feb 2010, Robert O'Callahan wrote:
> > > In Gecko, we avoid that kind of problem by being very careful to 
> > > ensure that asynchronous cache and codec state changes aren't 
> > > visible to scripts. (We haven't implemented 'seekable' yet, but my 
> > > plan is, when a script reads 'seekable' we compute the result, store 
> > > it, and pin the element's cache entries until the script runs to 
> > > completion, so subsequent reads of 'seekable' return the same result 
> > > and seeking to times in 'seekable' can't fail.) I think this is 
> > > critical to make the media API usable in a robust manner. Maybe the 
> > > spec should say something about that.
> >
> > I don't really understand how .seekable can change dynamically anyway, 
> > short of the moving window affecting it, but in that particular case 
> > the position is clamped, so it won't throw.
> 
> In our case, if the server doesn't support HTTP byte-range requests (or 
> uses a non-HTTP protocol such as FTP) then we can only allow seeking 
> within regions of media data which are in cache. Media resources all 
> share the same cache, which has a limited size, and the caching policy 
> depends on the current playback position of the media resources (among 
> other things), so in principle cache evictions could occur during script 
> execution, especially the media resources aren't all attached to the 
> same event loop.

Can you ever evict past the current playback position? If so, what happens 
when you reach that point during playback?

(Permanently evicting content from the earliest possible position to some 
point before the current playback position is fine, that just causes the 
earliest possible position to move to that second point.)


On Wed, 10 Feb 2010, Simon Pieters wrote:
> > 
> > I don't really understand how .seekable can change dynamically anyway, 
> > short of the moving window affecting it, but in that particular case 
> > the position is clamped, so it won't throw.
> 
> It's only clamped if currentTime is set past duration -- not past 
> buffered. So it would still throw when trying to seek past buffered for 
> servers that don't support range requests.

If you seek to a point past the previous "current playback position", and 
you're still playing such that you would eventually play that frame 
anyway, then by definition, it's seekable. It's just that the speed of 
seeking is very slow (and bound to either network bandwidth or the speed 
that the server is willing to send the bits).

The clamping I was referring to is clamping to the "earliest possible 
position" when content at or before the current playback position is 
permanently and irrecoverably evicted from the cache.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 25 March 2010 09:30:40 UTC