[whatwg] media elements: Relative seeking

[Eric Carlson]

   Reporting the absolute time of the current sample won't help when  
the first sample of the file doesn't have a timestamp of zero. It will  
be even more confusing for files with portions removed or added  
without fixing time stamps - for example a movie created by  
concatenating different files.

   As I noted when this subject came up a few weeks ago, the right way  
to deal with media formats that don't store duration is to estimate  
the duration of the whole file by extrapolating from the known, exact,  
duration of the portion(s) that have been processed. While the initial  
estimate won't always be correct for variable bit-rate formats, the  
estimate will become more and more accurate as it is iteratively  
refined by processing more media data. The spec defines the  
"durationchange" for just exactly this scenario.

   I don't think it makes *any* sense at all to push this problem up  
so the user has to deal with . It is a hard problem, but it is a  
problem for the User Agent

eric


On Nov 23, 2008, at 8:08 AM, Maik Merten wrote:

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