W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

[whatwg] media elements: Relative seeking

From: Eric Carlson <eric.carlson@apple.com>
Date: Sun, 23 Nov 2008 18:17:47 -0800
Message-ID: <C37D0663-4A1B-4F7B-8789-85E17C786065@apple.com>
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).

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

   When would you have the UA decide to switch from the attribute to  
the to the real duration? 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?

eric
Received on Sunday, 23 November 2008 18:17:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC