[whatwg] media elements: Relative seeking

[Silvia Pfeiffer]

On Mon, Nov 24, 2008 at 7:17 AM, Eric Carlson <eric.carlson at apple.com> wrote:
>
> 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.

I've now heard a need for such an attribute from more than on implementer.

I don't see addition of a duration attribute as much of a problem. We
have width and height for images, and sizes for fonts, too, and web
developers have learnt how to deal with these in various entities (px,
em, pt). I would not have a problem giving web developers the
opportunity to report the real duration of a video in an attribute in
either bytes or seconds (might be better called: length), which would
allow a renderer to display an accurate timeline. It is help for a
display mechanism just as width and height are.

In case of contradiction between the attribute and the actual decoded
length, a renderer can still override the length attribute at the time
the real length is known. In case of contradiction between the
attribute and the estimated length of a video, the renderer should
make a call based on the probability of the estimate being correct.

In may in fact be rather confusing to users if a video player keeps
changing the duration of a video file as it plays it back.

I think such an attribute can help get this right earlier.

Regards,
Silvia.

I think it will lead to more videos having the correct timeline
displayed right from the start, and less changes in the display of a
video's duration (which in fact may be rather confusing to users if
the durat