Re: media element seek algorithm: don't throw

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?


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.


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.

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

Received on Wednesday, 10 February 2010 02:50:55 UTC