[whatwg] media elements: Relative seeking

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

Received on Sunday, 23 November 2008 08:08:32 UTC