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
{
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel