[whatwg] media elements: Relative seeking

[Eric Carlson]

On Nov 23, 2008, at 10:51 AM, Maik Merten wrote:

> Eric Carlson schrieb:
>>
>>  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.
>
> Well, at least the "zero-timestamp has offset" problem can be  
> corrected.
> Whenever possible a "corrected" time should be reported - whatever  
> that
> may be.
>
>>  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.
>
> Personally I don't think extrapolating the duration will work at all.
> Yes, it gets better the more has been seen, but I assume we'll see a  
> lot
> of position indicators in the UI bouncing back and forth if durations
> are to be extrapolated.
>
   QuickTime has used this method this since it started supporting VBR  
mp3 in 2000, and in practice it works quite well. I am sure that there  
are degenerate cases where the initial estimate is way off, but  
generally it is accurate enough that it isn't a problem. An initial  
estimate is more likely to be wrong for a very long file, but each  
pixel represents a larger amount of time in the time slider with a  
long duration so changes less noticeable.

eric