Re: media element seek algorithm: don't throw

On Wed, 10 Feb 2010 03:50:27 +0100, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 2 Feb 2010, Simon Pieters wrote:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#seeking
>>
>> "4. If the (possibly now changed) new playback position is not in one of
>> the ranges given in the seekable attribute, then the user agent must
>> raise an INDEX_SIZE_ERR exception (if the seek was in response to a DOM
>> method call or setting of an IDL attribute), and abort these steps."
>>
>> 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.
>
> How is .seekable affected by the cache?

See below.


> On Tue, 2 Feb 2010, Eric Carlson wrote:
>>
>> I agree, throwing for an out-of-range seek is unexpected if the
>> questions we have gotten from developers is any indication. I think it
>> makes more sense to clamp the time value to the maximum seekable time.
>
> On Tue, 2 Feb 2010, Simon Pieters wrote:
>>
>> Hmm, good point. It seems better to seek to the closest seekable time
>> than to do nothing.
>
> 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.

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.


On Wed, 10 Feb 2010 04:42:49 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> 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.

Indeed. I can also imagine that seeking is just possible for the cached  
bits while being offline.


> On Tue, 2 Feb 2010, Eric Carlson wrote:
>>
>> 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 DVR that is limited to the previous 30
>> minutes, and the wall clock doesn't stop just because a script is
>> running.
>
> Indeed.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 10 February 2010 12:01:28 UTC