RE: [Openexr-devel] Re: New framesPerSecond Attribute?

[Luc-Eric Rousseau]

It's normal imho to store the frame rate as a rational. It's that way in AAF 
and OMF.  struct aafRational_t {   aafInt32 numerator;   aafInt32 denominator;  
};

In QuickTime if I'm not mistaken they're using fixed point which is also exact 
(it's two shorts in a long value).  Given this, who are these people who need 
help dividing two ints together? :D  There is no drawback to having frame rate 
stored as a rational, but stored as a double doesn't work for video because 
that's not what the frame rate is.  As you mention, NTSC is not 29.97, it's 
exactly 30000/1001. There are also two other common HD frame rates 23.976 and 
59.94. 

It's painful to deal with code that doesn't understand the origin of frame 
rates and how floating point numbers work, we have to hack around, rounding and 
fudging to get the true values.  The focus should be for these values to be 
easy to load, not necessarily easy to store.

So what I would suggest is to force the user of the library to actually store 
the frame rate correctly as a rational (two ints or two shorts), so that it's 
his burden to do what's appropriate for the host.  This is not suposed to be 
hard!  If it is, the user should not attempt saving the frame rate, it's 
probably not essential.

Otherwise the rounding errors just end up in the next tool up until someone 
must round these values and guess that what's stored is 'pretty much NTSC' 
therefore it 'must be NTSC'.  The convenience of using doubles is causing 
trouble for people who are most likely to care about that field.

Now, it's been mentionned that DPX stores the frame rate as float in its 
header, which is disapointing.  However DPX also contains a number of other 
fields that together define the image, including the synch rate.  It's a also a 
spec with very inconsistent implementation so probably no one is looking at 
that frame rate.  For video frame rate, I would suggest considering OMF and AAF 
over DPX.


> -----Original Message-----
> From: Florian Kainz
> 
> I got a some of votes for "quotient" and some for "double".
> A compromise might be to represent the frame rate as a Rational
> object, were class Rational is defined as shown below.  The
> Rational object would support conversion to and from double.
> This would allow you to store NTSC frame rates exactly and
> to extract them as doubles when needed.  Unfortunately the
> conversion from double to Rational does not always preserve
> the double's value exactly; Rational(double(30000.0/1001.0))
> to Rational introduces a relative error of 1.7e-10.
> 
> Rational(30000,1001), Rational(24.0) and Rational(30.0) do
> represent the corresponding frame rates exactly.
> 
> Florian
> 
> 
> class Rational
> {