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.
