[FFmpeg-user] How can I force a 360kHz time base?

[Mark Filipak (ffmpeg)]

On 2021-02-26 20:42, Jim DeLaHunt wrote:
> On 2021-02-26 17:24, Mark Filipak (ffmpeg) wrote:
> 
>> On 2021-02-26 20:05, Jim DeLaHunt wrote:
>>> Does input1.mkv in fact have a constant frame rate of 24/1.001 frames/second?
>>
>> No, it has a constant frame rate of 30/1.001 frames/second.
> 
> Sorry, my mistake.  I should have said, "Does input1.mkv in fact have a constant frame rate of 
> 30/1.001 frames/second?"
> 
> 
>> 'ffmpeg -i input.mkv -vf "showinfo" -codec:a copy -codec:s copy -dn output.mkv'
>>
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   1 pts:     33 pts_time:0.033   pos:    10052 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:B checksum:3CF10BFE plane_checksum:[64208370 
>> 00B13226 C5775659] mean:[25 126 131 ] stdev:[12.8 6.1 1.6 ]
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   2 pts:     67 pts_time:0.067   pos:     9213 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:B checksum:23A8A65F plane_checksum:[90DC2AA6 
>> 37E908C8 779972F1] mean:[27 125 132 ] stdev:[14.8 7.1 1.9 ]
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:   3 pts:    100 pts_time:0.1     pos:    11086 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:B checksum:1CDF7A80 plane_checksum:[089DE80E 
>> C537F4C0 8C4E9D94] mean:[29 125 132 ] stdev:[15.2 6.6 2.3 ]
>> …[elided for brevity]…
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  28 pts:    934 pts_time:0.934   pos:    45167 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:B checksum:8D724A43 plane_checksum:[CD1CE198 
>> DC377EA5 3D51E9E8] mean:[70 113 148 ] stdev:[46.3 11.6 11.5 ]
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  29 pts:    968 pts_time:0.968   pos:    40163 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:P checksum:8F6C0D42 plane_checksum:[385DA9F1 
>> 7EA37D5A AD78E5D9] mean:[70 113 148 ] stdev:[46.6 11.6 11.5 ]
>> [Parsed_showinfo_0 @ 0000013c877124c0] n:  30 pts:   1001 pts_time:1.001   pos:    50467 
>> fmt:yuv420p sar:32/27 s:240x236 i:P iskey:0 type:B checksum:B511B7BA plane_checksum:[9C9A49A0 
>> B1D583BA FA0EEA51] mean:[70 113 148 ] stdev:[46.5 11.4 11.6 ]
> 
> 
> This output shows a stream which has a varying frame rate. The change in pts_time is not constant 
> from frame to frame.

That's exactly the point. It is not constant because ffmpeg calculates frame times in integer 
milliseconds, and thereby truncates or rounds. That produces errors. The PTSs should be constant.

Example: With a 90000kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be 
'3003' (=0.0333[6..] milliseconds). The actual resolution depends on milliseconds (0.033) vs. 
microseconds (0.033366) vs. nanoseconds (0.033366666) etc.

Example: With a 360000kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be 
'12012' (=0.0333[6..] milliseconds).

Example: With a 1kHz time base and a 30/1.001fps video, frame-to-frame (deltaPTS) should be 
'33.3[6..]', but 33.3[6..] is not an integer, so it gets rounded down to 33. That produces errors, 
and the appearance that the video is variable frame rate when it's really constant frame rate.

> Can you get some output which shows the timebase value, or the frame times, of input1.mkv, showing 
> that there is a timebase which is a multiple of 1.001/30, or showing that the time value of each 
> frame increments by a constant amount?

The ffmpeg report shows "29.97 tbr". I haven't put an oscilloscope on it, but it's from a commercial 
DVD and I'd be incredibly surprised if it wasn't constant frame rate.

> So far, the output you show is consistent with an input1.mkv which has a varying frame rate that is 
> 30/1.001 fps, distorted to fit a 1/1000 timebase. Can you show a diagnostic which eliminates that 
> possibility?

No, I can't except by measuring frames with a physical oscilloscope or logic analyzer. But you know, 
that shouldn't matter. If ffmpeg quantizes frame times to 1ms resolution, it's going to produce errors.

A 360000Hz time base is convenient because, for just about all possible video frame rates, it will 
produce PTSs that are purely integers (exact, no rounding). Those exact PTSs can then be used 
directly when determining frame-to-frame sequencing, even from differing streams, even if they are 
differing frame rates. It would be Valhalla.