[whatwg] media elements: Relative seeking

[Philip Jägenstedt]

Relative seeking is always possible: currentTime+=10. Proportional
seeking is possible as long as the duration is known and finite.

I would avoid as far as possible any use of byte positions as this
information isn't exactly trivial to get given all the buffering and
asynchronous decoding involved in typical media frameworks.

Philip

On Tue, 2008-11-25 at 08:58 +0100, Maik Merten wrote:
> Dave Singer schrieb:
> > I don't think you mean 'relative' here, which I would take to be "go 
> > forward 10 seconds", but 'proportional', "please go to 60% of the way 
> > through".
> 
> Right, "proportional" for sure is the correct word for what I had in 
> mind. Thanks.
> 
> 
> > IF we are to do this, I would have thought it would be by adding units 
> > to the "where to seek to" argument:
> > 
> > * go to this time in NPT (normal play time, which runs from 0 to media 
> > duration)
> > * go to this SMPTE time code
> > * go by this relative distance in NPT times
> > 
> > * go to this proportional time
> > * go to this proportional byte distance
> > * go by this relative byte distance
> 
> Hmmm... I'm in favor of of making implementations more simple (and thus 
> more robust in this case), so I think inflating the number of ways of 
> how one can seek may be going into the wrong direction.
> 
> 
> > Note that proportional distances are not well defined for some streams 
> > (e.g. indefinite ones).
> 
> Okay, this use case basically rules out just seeking by values between 
> zero and one. Even with indefinite streams the user may want to e.g. 
> jump to second 20 of the stream, which won't work with the proportional 
> seeking I asked for.
> 
> 
> > We'd have to define what bytes are counted and what aren't, especially 
> > if a URL offers a set of sub-streams only some of which a client would 
> > normally choose to have sent to it for playing.
> 
> Oh my, that's true and it isn't pretty.
> 
> I'm currently slamming a subset of the HTML5 media API onto a Java 
> applet (to offer a fallback for browsers without audio/video).
> 
> http://people.xiph.org/~maikmerten/demos/bigbuckbunny-applet-javascript.html
> 
> Estimating the duration *does* work - poorly in this case, but still. 
> Currently this applet uses the byte-position of the last byte fetched 
> from the server, which isn't the correct *playback* byte-position due to 
> not accounting for the bytes in the buffer (which, in this case, is 4 
> megabytes big - so this is severe). I assume that once this is corrected 
> a reasonable-enough (for a status bar position slider) estimate may 
> actually be possible, meaning things could just stay the way they are.
> 
> 
> Maik
-- 
Philip Jägenstedt
Opera Software