On Wed, Oct 3, 2012 at 6:41 AM, Jer Noble <jer.no...@apple.com> wrote:
> On Sep 17, 2012, at 12:43 PM, Ian Hickson <i...@hixie.ch> wrote:
>
>> On Mon, 9 Jul 2012, adam k wrote:
>>>
>>> i have a 25fps video, h264, with a burned in timecode.  it seems to be
>>> off by 1 frame when i compare the burned in timecode to the calculated
>>> timecode.  i'm using rob coenen's test app at
>>> http://www.massive-interactive.nl/html5_video/smpte_test_universal.html
>>> to load my own video.
>>>
>>> what's the process here to report issues?  please let me know whatever
>>> formal or informal steps are required and i'll gladly follow them.
>>
>> Depends on the browser. Which browser?
>>
>>
>>> 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.
>
> TLDR; for precise navigation, you need to use a a rational time class, rather 
> than a float value.
>
> 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.


FYI: the Ogg container also uses rational numbers to represent time.


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

Reply via email to