[MEncoder-users] V210 Codec

[Reimar Döffinger]

On Wed, Feb 18, 2009 at 11:01:29AM -0800, Larry Reznick wrote:
> Looking inside the MOV reveals that the time scale is 2997, the duration 
> is 219125, which works out to 73.114781 seconds, and the number of 
> frames is 1753. Thus, 1753/(219125/2997) = 23.976, or 2997/125. Despite 
> any internal single-precision rounding error the YUV4MPEG2 header should 
> have got the 2997:125 value because 1753*2997 = 5253741, which fits into 
> 32 bits, and 5253741/219125 reduces to 2991/125. The rational fraction 
> routine MPlayer uses is a problem. Creeping sync errors bit me too many 
> times in the past.

Ah, I missed your source was a mov file. The problem with that format is
that it is inherently variable-framerate. libavformat guesses a fps
value based on the time-stamps of the first few frames, so it is
unlikely it's the same value as you just calculated.

> >> Mathematically, this fraction works out to 
> >> 23.97599983 instead of 23.976. In fact, 23.976 should have been 
> >> expressed as 2997/125.
> >
> > 23.976 is a rounded value for display, not exact.
> >   
> 
> I understand, but, as I showed above, the metadata in the MOV works out 
> to that number number, while single-precision error delivered the number 
> that went into the YUV4MPEG2 file header. While it may or may not be 
> accurate to put 24000:1001 in the file when 2997:125 comes out of the 
> MOV data, it is certainly inaccurate to put 12570329:524288 into the file.

The value 2997:125 is nowhere in the metadata though. Your guess may be
more precise, but requires knowing the full length of the video and the
number of frames (not so hard for mov) and works very badly if you have
a few frames with excessive duration (e.g. multiple seconds) somewhere
in the file.
You could try if -demuxer mov guesses better than libavformat though.

> >> However, one could argue that the rate is 
> >> supposed to be 24000/1001, which is 23.976023976 (repeating the last six 
> >> digits). Thus, while 23.976 is theoretically inaccurate enough, the 
> >> bizarre fraction MPlayer comes up with causes even more error.
> >
> > Well, it's not the one I get, mine corresponds to
> > 23.97602462768554687500.
> > Nevertheless, since the calculation method was already changed in
> > mencoder I saw no fault in using the same in that code, which works for
> > all common frame rates (though I notice it might cause issues for frame
> > rates < 0), e.g. I now get F24000:1001
> 
> It's an interesting problem. As you can see, I'm using an SVN version 
> from this week and I don't get the number you got.

Well, IMO this is simply because your source is in a format with
variable frame-rate and non-exact timestamps. Still, you can check if it
is any better with very latest SVN. I don't think so, but at least if
you specify explicitly -fps 24000/1001 it should write the right
numbers, which is simpler than editing it afterwards (and works with
fifos).