[whatwg] <video> feedback

[Ian Hickson]

On Tue, 2 Oct 2012, Jer Noble wrote:
> On Sep 17, 2012, at 12:43 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 9 Jul 2012, adam k wrote:
> >>
> >> i'm aware that crooked framerates (i.e. the notorious 29.97) were not 
> >> supported when frame accuracy was implemented.  in my tests, 29.97DF 
> >> timecodes were incorrect by 1 to 3 frames at any given point.
> >> 
> >> will there ever be support for crooked framerate accuracy?  i would 
> >> be more than happy to contribute whatever i can to help test it and 
> >> make it possible.  can someone comment on this?
> > 
> > This is a Quality of Implementation issue, basically. I believe 
> > there's nothing inherently in the API that would make accuracy to such 
> > timecodes impossible.
> 
> The nature of floating point math makes precise frame navigation 
> difficult, if not impossible.  Rob's test is especially hairy, given 
> that each frame has a timing bound of [startTime, endTime), and his test 
> attempts to navigate directly to the startTime of a given frame, a value 
> which gives approximately zero room for error.
> 
> I'm most familiar with MPEG containers, but I believe the following is 
> also true of the WebM container: times are represented by a rational 
> number, timeValue / timeScale, where both numerator and denominator are 
> unsigned integers.  To seek to a particular media time, we must convert 
> a floating-point time value into this rational time format (e.g. when 
> calculating the 4th frame's start time, from "3 * 1/29.97" to "3 * 
> 1001/30000").  If there is a floating-point error in the wrong direction 
> (e.g., as above, a numerator of 3002 vs 3003), the end result will not 
> be the frame's startTime, but one timeScale before it.
> 
> We've fixed some frame accuracy bugs in WebKit (and Chromium) by 
> carefully rounding the incoming floating point time value, taking into 
> account the media's time scale, and rounding to the nearest 1/timeScale 
> value.  This fixes Rob's precision test, but at the expense of 
> precision. (I.e. in a 30 fps movie, "currentTime = 0.999999 / 30" will 
> navigate to the second frame, not the first, due to rounding, which is 
> technically incorrect.)
> 
> This is a common problem, and Apple media frameworks (for example) 
> therefore provide rational time classes which provide enough accuracy 
> for precise navigation (e.g. QTTime, CMTime). Using a floating point 
> number to represent time with any precision is not generally accepted as 
> good practice when these rational time classes are available.

That makes sense.

Should we add a preciseSeek() method with two arguments that does a seek 
using the given rational time?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'