[whatwg] media elements: Relative seeking

[Dave Singer]

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

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

Note that proportional distances are not well defined for some 
streams (e.g. indefinite ones).

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.


At 17:08  +0100 23/11/08, Maik Merten wrote:
>Hello,
>
>currently seeking in the media elements is done by manipulating the
>currentTime attribute. This expects an absolute time offset in seconds.
>This works fine as long as the duration (in absolute time) of the media
>file is known and doesn't work at all in other cases.
>
>Some media formats don't store the duration of the media file anywhere.
>A client can only determine the duration of the media file by
>byte-seeking near the end of the file and finding a timestamp near/at
>the end. This isn't a problem whatsoever on local files, but in remote
>setups this puts additional load on the server and the connection. If
>one would like to avoid this, meaning no duration is known, seeking in
>absolute time cannot work.
>
>While getting the absolute duration is often a problem retrieving the
>length of the media file is is no problem. I propose seeking with
>relative positions, e.g. values between zero and one. This way the
>client can determine if to seek in absolute time (if the duration is
>known) or to just jump into to a position of the bytestream (if the
>length in bytes is known).
>
>
>  - make currentTime readonly, still have it report playback position in
>absolute time. This information should be available in all media formats
>due to timestamps in the stream.
>
>  - introduce a seek() method, taking a relative value ranging from zero
>to one. This allows both accurate seeking if the duration is known and
>less precise seeking otherwise if only the length of the file is known
>in storage units. This is still way better than not being able to seek
>at all.
>
>  - make duration report either the duration in absolute time (if known)
>or the length of the file in storage units. This enables computation of
>a relative playback position even when no duration is known, if the byte
>position of the stream is known (low precision fallback - still better
>than nothing at all).
>
>  - introduce a readonly storagePosition attribute. Meant to compute a
>relative position if the duration is only known in storage units.
>
>
>Maik


-- 
David Singer
Multimedia Standards, Apple Inc.