[whatwg] media elements: Relative seeking

[Silvia Pfeiffer]

Eric,

On Mon, Nov 24, 2008 at 1:17 PM, Eric Carlson <eric.carlson at apple.com> wrote:
> Silvia -
>
> On Nov 23, 2008, at 1:40 PM, Silvia Pfeiffer wrote:
>
>> 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.
>>
>  Those attributes are different because they change the presentation of the
> element: image width and height are the rendered width and height, font-size
> controls fond rendering size, etc. In order for a duration attribute to be
> equivalent we would need for it to limit the amount of the file played (like
> the now-removed 'end' attribute did).

I see the length attribute as rendering help for the timeline, not the
video. It would not relate to changing the actual video or the video's
playback time.


>> 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 the case of a file with video or VBR audio the true duration literally
> isn't actually known until *every* frame has been examined.

So the length attribute is used for the timeline until we reach the
end of the file or go past the given length. Not much of a problem,
I'd say.


>  When would you have the UA decide to switch from the attribute to the to
> the real duration?

The browser would need to have it's own estimate of reliability of the
length attribute. If there is a high probability that the length
attribute is wrong, e.g. we have already played beyond the given
length, or we have obviously too much data to decode for the given
length, it would ignore the length attribute. I would however hope
that web developers generally test their pages and the length
attribute to make sure the display is correct. If that data is
provided through a CMS, then the information should be correct anyway.

> What would you have the UA do if the user seeks to time
> 90 seconds when attribute says a file is 100 seconds long, but the file
> actually has a duration of 80?

Realize that we have hit 80, that 100 cannot be right, update our
knowledge of the actual length, update the timeline display and place
the play pointer at the end, displaying a length of 80. That is the
same problem as you get when you make a wrong estimate of length.

length is only meant as a well-informed user hint. I think it solves
more problems than it creates. But we won't know unless we implement
and test it, I guess. :-)

Regards,
Silvia.