- From: Jer Noble <jer.noble@apple.com>
- Date: Thu, 20 Dec 2012 22:55:18 -0800
- To: Mark Callow <callow.mark@artspark.co.jp>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Dec 20, 2012, at 7:27 PM, Mark Callow <callow.mark@artspark.co.jp> wrote: > On 2012/12/21 2:54, Ian Hickson wrote: >> On Thu, 20 Dec 2012, Mark Callow wrote: >>> I draw your attention to "Don't Store that in a float >>> <http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/>" >>> and its suggestion to use a double starting at 2^32 to avoid the issue >>> around precision changing with magnitude as the time increases. >> Everything in the Web platform already uses doubles. > Yes, except as noted by Boris. The important point is the idea of using 2^32 as zero time which means the precision barely changes across the range of time values of interest to games, videos, etc. I don't believe the "frame accuracy" problem in question had to do with precision instability, per se. Many of Rob Coenen's frame accuracy issues were found within the first second of video. Admittedly, this is where the avaliable precision is changing most rapidly, but it is also where available precision is greatest by far. An integral rational number has a benefit over even the "2^32 zero time" suggestion: for common time scale values[1], it is intrinsically stable over the range of time t=[0..2^43). It has the added benefit of being exactly the representation used by the underlying media engine. On Dec 17, 2012, at 4:01 PM, Ian Hickson <ian@hixie.ch> wrote: > Should we add a preciseSeek() method with two arguments that does a seek > using the given rational time? This method would be more useful if there were a way to retrieve the media's time scale. Otherwise, the script would have to pick an arbitrary scale value, or provide the correct media scale through other means (such as querying the server hosting the media). Additionally, authors like Rob are going to want to retrieve this precise representation of the currentTime. If rational time values were encapsulated into their own interface, a "preciseCurrentTime" (or similar) read-write attribute could be used instead. -Jer [i] E.g., 1001 is a common time scale for 29.997 and 23.976 FPS video.
Received on Friday, 21 December 2012 06:55:07 UTC