Topaz Video Enhance AI

I don't have the Topaz software, but from reading their site, it appears that Chronos is, as you say, about slow or fast motion — exclusively. It's an interpolated frame-generation algorithm more than a rate-control one. While it's possible it would be able to correct frame rate issues as a side-effect of what it does, if nothing else it's likely overkill for the purpose, and probably not entirely necessary anyway.

That 24.999875 you're seeing is an average frame rate — the number of frames, divided by the runtime. Quite literally, frames ÷ seconds == frames/seconds == fps. But that doesn't mean your video's timing is bad. At least, not 99.9% of it.

With just an average rate, there's no way to tell a video with inconsistent timing throughout, from one with mostly perfect timing, but one or two short/long frames... usually at either the start or the end. Fortunately, the second scenario is both much more common, and easier to correct. (And it does need be corrected. As you've discovered, software can do amazingly stupid things if there are issues with a video's average frame rate. Too often, computations are based on it that lead to processing or playback issues with the entire file.)

I went through my video files to find one with "weird" timing, and came up with one I'll use as an example. It's an old Sorenson-encoded MOV file, and here's how MediaInfo reports the timing:

Duration                                 : 00:01:06.865 (00:01:06:14)
Frame rate mode                          : Variable
Frame rate                               : 15.015 FPS
Minimum frame rate                       : 15.000 FPS
Maximum frame rate                       : 600.000 FPS
Frame count                              : 1004

(Sure enough, 1004 / 66.865 = 15.015329. It's just a dumb average.) Now, that's gonna throw things off, especially the "maximum" frame rate of 600 FPS. But in reality that's nonsense.

There's a great open-source program called QCTools, developed a few years ago by MediaArea (who also wrote MediaInfo) in partnership with the Bay Area Video Coalition, a group of archivists and preservationists. The GUI uses ffmpeg to collect statistical metrics of a video encoding's quality in all sorts of ways I don't really understand, but one of the display options is a graph of a video's packet durations (which, in simplified terms, translate to frame durations). When I fed the video above into it, this is what I got:

That black line is actually the graph (I was hoping I could change the plot color to something other than black, but... I can't figure it out. QCtools can graph in multiple colors, but... ¯\_(ツ)_/¯ What it's showing, though, is that the video's timing is perfectly steady for almost the entire runtime... until it falls off right at the very end. Which we can see if I zoom way in:

Clicking around the graph, I find that the duration is exactly 0.06667s for EVERY frame except the last two. It starts to fall off in frame 1002, and frame 1003 has a duration of only 0.00167 seconds... which is the source of that "600 FPS" "maximum" frame rate.

Knowing that it's only the last two frames causing problems, though, I can simply slice them off using ffmpeg. I'll actually keep 1001 frames (0 - 1000) and slice off the last three, since 1000 × 0.06667 is 66.67 seconds. (It'll tack on the duration of the last frame automatically.)

$ ffmpeg -t 66.67 -i bad_timing.mov corrected.mov
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bad_timing.mov':
  Metadata:
    creation_time   : 2000-01-06T22:31:42.000000Z
  Duration: 00:01:06.87, start: 0.000000, bitrate: 163 kb/s
  Stream #0:0(eng): Video: svq1 (SVQ1 / 0x31515653), yuv410p, 256x192, 162 kb/s, 15.02 fps, 15 tbr, 600 tbn, 600 tbc (default)
    Metadata:
      creation_time   : 2000-01-06T22:31:42.000000Z
      handler_name    : Apple Video Media Handler
      vendor_id       : SVis
      encoder         : Sorenson Video
  Stream #0:1(eng): Data: none, 60 kb/s (default)
    Metadata:
      creation_time   : 2000-01-06T22:31:42.000000Z
      handler_name    : Sprite Animation Media Handler
Stream mapping:
  Stream #0:0 -> #0:0 (svq1 (native) -> h264 (libx264))
Output #0, mov, to 'corrected.mov':
  Metadata:
    encoder         : Lavf58.76.100
  Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), yuv420p(tv, progressive), 256x192, q=2-31, 15 fps, 15360 tbn (default)
    Metadata:
      creation_time   : 2000-01-06T22:31:42.000000Z
      handler_name    : Apple Video Media Handler
      vendor_id       : SVis
      encoder         : Lavc58.134.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame=    1 fps=0.0 q=0.0 size=       0kB time=00:00:00.00 bitrate=N/A speed=N/Aframe=  258 fps=0.0 q=27.0 size=     256kB time=00:00:13.66 bitrate= 153.5kbits/frame=  488 fps=486 q=27.0 size=     512kB time=00:00:29.00 bitrate= 144.6kbits/frame=  721 fps=479 q=27.0 size=     768kB time=00:00:44.53 bitrate= 141.3kbits/frame=  950 fps=474 q=27.0 size=    1024kB time=00:00:59.80 bitrate= 140.3kbits/frame= 1001 fps=454 q=-1.0 Lsize=    1360kB time=00:01:06.53 bitrate= 167.5kbits/s speed=30.2x    
video:1350kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.771125%

After processing, ffmpeg and MediaInfo agree: A file with perfect 15 FPS, constant-rate encoding.

$ ffprobe -i corrected.mov
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'corrected.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    encoder         : Lavf58.76.100
  Duration: 00:01:06.73, start: 0.000000, bitrate: 166 kb/s
  Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 256x192, 165 kb/s, 15 fps, 15 tbr, 15360 tbn, 30 tbc (default)

$ mediainfo -full corrected.mov
Duration                                 : 00:01:06.734 (00:01:06:11)
Frame rate mode                          : Constant
FrameRate_Mode_Original                  : VFR
Frame rate                               : 15.000 FPS
Frame count                              : 1001

No more "maximum" frame rate from MediaInfo, either. It still shows the video was originally variable-rate, supposedly, but that shouldn't matter. And if I load the processed video into QCTools, the timing graph now goes straight across from start to finish.

It's worth trimming off problem frames before doing any other sort of processing, since you can never be sure what calculations they're foul

I cannot answer that question, as I started with 2.6.2.

I tested 2.4 a while back and was not impressed.

Tested 2.6.2 and was impressed. Black Friday came along and bought the program.