<p>--------- Original Message --------<br /> Da: "Eric Carlson" <eric.carlson@apple.com><br /> To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com><br /> Cc: "WHAT Working Group" <whatwg@lists.whatwg.org>, "Maik Merten" <maikmerten@googlemail.com><br /> Oggetto: Re: [whatwg] media elements: Relative seeking<br /> Data: 24/11/08 03:17</p>
<p>> Silvia -<br />><br />> On Nov 23, 2008, at 1:40 PM, Silvia Pfeiffer wrote:<br />><br />>> I don't see addition of a duration attribute as much of a problem. We<br />>> have width and height for images, and sizes for fonts, too, and web<br />>> developers have learnt how to deal with these in various entities (px,<br />>> em, pt). I would not have a problem giving web developers the<br />>> opportunity to report the real duration of a video in an attribute in<br />>> either bytes or seconds (might be better called: length), which would<br />>> allow a renderer to display an accurate timeline. It is help for a<br />>> display mechanism just as width and height are.<br />><br />> Those attributes are different because they change the presentation<br />> of the element: image width and height are the rendered width and<br />> height, font-size controls fond rendering size, etc. In order for a<br />> d
uration
attribute to be equivalent we would need for it to limit the<br />> amount of the file played (like the now-removed 'end' attribute did).<br />><br /><br />Well, the length attribute could be an indication about such limit and could accept a generic value, such as 'unknown' (or '0', with the same meaning - just to have only numerical values) to indicate an endless stream (i.e. a realtime iptv): in such a case, any seeking operation could be either prohibited or just related to the amount of yet played content which is eventually present in a local cache.<br /><br />>> In case of contradiction between the attribute and the actual decoded<br />>> length, a renderer can still override the length attribute at the time<br />>> the real length is known. In case of contradiction between the<br />>> attribute and the estimated length of a video, the renderer should<br />>> make a call based on the probability of the estimate being correct.<br />>
;<br
/>> In the case of a file with video or VBR audio the true duration<br />> literally isn't actually known until *every* frame has been examined.<br />><br />> When would you have the UA decide to switch from the attribute to<br />> the to the real duration?<br /><br />I guess the U.A. could avail of an external codec, which could provide facilities to estimate the real duration: in this case everything would be as easy as just demanding the averaging an estimation to the codec, and getting the real/estimated duration as the result of a callback.<br /><br />> What would you have the UA do if the user seeks to time 90 seconds when<br />> attribute says a file is 100 seconds long, but the file actually has a<br />> duration of 80?<br />><br />>eric<br /><br />Nothing special, according to me. Just update any visual time indicator, both for total and current time, and convert the previous seek value to a relative, percentage one, to normalize the req
uested
position in respect to the real duration. That is, let's just switch from absolute to relative seeking as needed, it shouldn't be so difficoult, after all.<br />Regards,<br /><br />Alex</p><br><p><font face=Verdana,Arial size=2>----<br>
Email.it, the professional e-mail, gratis per te: <a href="http://www.email.it/cgi-bin/start?sid=3"
target="_blank" >clicca qui</a> <br>
<br>
Sponsor:<br>
CheBanca! La prima banca che ti dà gli interessi in anticipo.
Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!<br>
<a href="http://adv.email.it/cgi-bin/foclick.cgi?mid=7916&d=20081124" target="_blank" >Clicca qui</a> </font><br>