[whatwg] media elements: Relative seeking

[Calogero Alex Baldacchino]

 


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

 Da: "Maik Merten" <maikmerten at googlemail.com>

 To: "WHATWG Proposals" <whatwg at lists.whatwg.org>

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

 Data: 24/11/08 08:45




 

> Eric Carlson schrieb:

 >> QuickTime has used this method this since it started supporting
VBR 

 >> mp3 in 2000, and in practice it works quite well. I am sure that
there 

 >> are degenerate cases where the initial estimate is way off, but 

 >> generally it is accurate enough that it isn't a problem. An
initial 

 >> estimate is more likely to be wrong for a very long file, but each
pixel 

 >> represents a larger amount of time in the time slider with a long 

 >> duration so changes less noticeable.

 >

 > Well, I do believe this works fine for audio (which usually hasn't a 

 > wildly fluctuating bitrate if you e.g. average over a second or two), 

 > I'm mostly concerned about video. An example for an outrageously off 

 > estimate would be the trailer for "Generic space-pirate movie".

 >

 > The first few seconds would be mostly a static
green/red/yellow/whatever 

 > screen ("This pirate movie has been rated ARRRRRR!") - this part would


 > be coded with like 100 kbit/s or less. The next few scenes (this is a 

 > trailer, after all) would mostly show exploding ships, genetically 

 > engineered mutant parrots attacking space-adventurers and a few cuts 

 > into random love scenes - so this part can be multi-megabit/s. After 

 > this the bitrate would dramatically decrease again as the last few 

 > seconds will just show "Summer 2010". >




> Does QuickTime also handle such content gracefully (e.g. display a 

 > position slider that doesn't jump around wildly)? Am I overestimating 

 > the problem?

 

> Maik


The slider should just indicate a relative position (i.e. a percentage)
between 0 and the (currently known) duration of the content, which may be
estimated with a variable average time, perhaps retarded at the beginning,
and varied according to the bitrate variation with some euristic, to make
the computation more accurate (or maybe a few consecutive evaluation, at
fixed and rapid intervals, could be averaged to get a better value, before
updating anything), so no "crazy horse jumping" should happen. Silvia
Pfeiffer has proposed a 'length' attribute to indicate the overall duration
in the markup, and I think its value could help to improve accuracy, even
when wrong.


 
 --
 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=7919&d=20081124

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