[whatwg] media elements: Relative seeking

[Maik Merten]

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