Re: media element seek algorithm: don't throw

On Feb 2, 2010, at 11:01 AM, Robert O'Callahan wrote:

> On Wed, Feb 3, 2010 at 2:14 AM, Simon Pieters <simonp@opera.com> wrote:
> It's annoying to use try/catch every time you set currentTime. It's nicer to check seekable and then set currentTime. However, even if you check seekable there's no guarentee that currentTime won't throw because the cache might be cleared between the check and the setting. Therefore we think it's better to silently abort the algorithm instead of throwing.
> 
> 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.
> 
  This isn't possible lock the element's cache with all media engines, but even it is was I don't think it would be good to spec that behavior. Loading and buffering may happen on another thread, or in another process, and the loader may have a hard limit on what it can buffer. For example the "live" buffer on my DRV that is limited to the previous 30 minutes, and the wall clock doesn't stop just because a script is running.

eric