[whatwg] media elements: Relative seeking

Mon Nov 24 14:21:56 PST 2008

--------- Original Message --------

 Da: "Eric Carlson" <eric.carlson at apple.com>

 To: "Silvia Pfeiffer" <silviapfeiffer1 at gmail.com>

 Cc: "WHAT Working Group" <whatwg at lists.whatwg.org>, "Maik Merten"
<maikmerten at googlemail.com>

 Oggetto: Re: [whatwg] media elements: Relative seeking

 Data: 24/11/08 03:17

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

>

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.

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

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.

> 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

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

Regards,

Alex

 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 CheBanca! La prima banca che ti dà gli interessi in anticipo.
Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7916&d=20081124

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081124/673521dd/attachment-0001.htm>