- From: Eric Carlson <eric.carlson@apple.com>
- Date: Sun, 23 Nov 2008 18:17:47 -0800
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