Re: media element seek algorithm: don't throw

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]