Quote:Your source isn't really "38.870 fps". It's an iPhone ReplayKit capture on a 60 Hz grid. Each frame stays on screen for 1, 2 or 3 display refreshes, so the video switches between 60, 30 and 20 fps depending on how much is moving. 38.87 is just the average (12,434 frames ÷ 319.8 s). No frame in the file actually lasts 1/38.87 s.

There are three separate problems. One is in how Hybrid calls ffmpeg, not in ffmpeg itself, and the other two are Hybrid logic choices:

1. The 19,173-line timecode file. Hybrid runs ffmpeg without -fps_mode passthrough. The mkvtimestamp_v2 muxer is a raw-video output that doesn't declare variable-frame-rate support, so ffmpeg's default auto mode switches to CFR. It then fills a 59.94 fps grid by duplicating 6,739 frames (12,434 + 6,739 = 19,173 timestamps + header). ffmpeg logs this openly: dup=6739, "More than 1000 frames duplicated". That's documented, intended ffmpeg behaviour, not an ffmpeg bug.
   
   
2. The VFR encode (8,065 frames, 3:27). Hybrid noticed the timecode count didn't match the frame count, then changed the frame count to fit the bad timecodes instead of rejecting them. On top of that, its frameserver pipe uses -fps_mode auto -r 3887/100, which drops frames. Only 8,065 frames got to x264, and they were timed with the first 8,065 entries of the bogus 59.94 grid.
   
   
3. The CFR encode (choppy, frame numbers off). That one is working as designed, but 38.87 is the wrong target. L-SMASH (fpsnum=3887, fpsden=100) resamples 60/30/20 fps material onto a 38.87 grid. My simulation using your ffprobe timestamps: 2,133 frames dropped and 2,133 duplicated, unevenly spread. That's the judder on pans.
   

Quote:Hybrid 2026.10.10.1 (64-bit), Windows 10 22H2. VFR source (iPhone ReplayKit HEVC .mov, 12,434 frames, avg 38.87 fps, actual 60 Hz cadence with 1/2/3-refresh frame durations, tbn 19200, ffmpeg-reported tbr 59.94). ffmpeg N-126512-gf7fbb1260e.

1. Timecode extraction produces CFR-padded timecodes.
   Call: ffmpeg.exe -y -i "X.mov" -map 0:0 -f mkvtimestamp_v2 "X.txt" (log line 1180).
   Because no -fps_mode is given, ffmpeg's auto mode chooses CFR for the mkvtimestamp_v2 (rawvideo-style) muxer and pads to the stream tbr (59.94): ffmpeg reports frame=19173 ... dup=6739 drop=0 and "More than 1000 frames duplicated" (lines 1248/1266). The resulting file is a pure 59.94 grid (16/17 ms deltas only) with 19,173 entries instead of 12,434.
   
   Fix: add -fps_mode passthrough (-vsync 0 / -vsync passthrough for older builds), and preferably -an -sn and -map 0:v:0. Alternatives: ffprobe -show_entries frame=pts_time (sorted) or mkvmerge + mkvextract timestamps_v2.
   
   
2. Frame count is adjusted to a mismatching timecode count instead of rejecting the timecodes.
   Log lines 20451–20453: Adjusting frame count (12434) to time code entry count (19173). then Current frame rate: 59.946 differs from average time code frame rate: 38.87. This will be ignored since 'Check average fps of mkv/mp4 files' is disabled.
   A timecode count that differs from the decoder's frame count by 54 % should be treated as an error: warn, then fall back to a different extraction method or CFR. The job carries 19172/38.87 from then on (e.g. line 32289).
   
   
3. VFR (non-CFR) jobs resample in the frameserver pipe.
   Decode call (line 147489): ffmpeg ... -i script.avs -an -sn -pix_fmt yuv420p -fps_mode auto -r 3887/100 -f rawvideo - | x264 ..., with a script using LWLibavVideoSource(...) without fpsnum (12,434 frames 1:1).
   -r + -fps_mode auto on rawvideo makes ffmpeg CFR-convert (nominal ~59.94 → 38.87), so only 8,065 of 12,434 frames reach x264. mp4fpsmod then applies the first 8,065 timecodes (video source duration 2:14.551 in MediaInfo; container 3:27.485).
   
   Fix: when timecodes will be applied, the pipe must use -fps_mode passthrough and no -r, so every frameserver frame reaches the encoder 1:1.
   
   
4. Suggestion: CFR conversion target for VFR sources.
   With "CFR Output" checked, Hybrid uses fpsnum=3887,fpsden=100 (the average rate). For sources on a fixed refresh grid (screen recordings, phone captures: 60 Hz base, 19200 tbn), the average is the worst possible target: 2,133 drops + 2,133 dups here, visible judder, and frame indices drift (src 300 → dst ~380, src 3000 → dst ~2703). Using the base rate (60/1, derived from the timestamp GCD / timebase rather than the rounded 59.94 tbr), or at least offering it as an option, gives judder-free CFR output.
   

Debug logs (variable and constant runs), MediaInfo, ffprobe CSV and the bad/good timecode files are available.

  Hybrid_Variable_Framerate_Issue.zip (Size: 946,94 KB / Downloads: 4)

Contents of attachment:

• MediaInfo_Source.txt - MediaInfo output (advanced) for source file.
  
  
• MediaInfo_Destination_Variable.txt - MediaInfo output (advanced) for destination file encoded with Hybrid and variable bitrate using Test_vid_source.tc timecode v2 file with incorrect number of frames (19,173); number of frames (8,065) and duration (00:03:27.485) in output file are incorrect.
  
  
• MediaInfo_Destination_Constant.txt - MediaInfo output (advanced) for destination file encoded with Hybrid and constant bitrate; number of frames (12,434) and duration (00:05:19.887) are correct in output file, audio is synced, but playback is choppy and video frame captures don't line up between source and destination matching frame numbers (checked using VirtualDub2).
  
  
• Test_vid_source.tc - Output from ffmpeg.exe -y -i "Test_vid_source.mov" -map 0:0 -f mkvtimestamp_v2 "Test_vid_source.txt" (this is what Hybrid currently uses); incorrect number of frames (19,173).
  
  
• Test_vid_source.csv - Output from ffprobe -v error -select_streams v:0 -show_entries frame=coded_picture_number,pts_time -of csv "Test_vid_source.mov" > "Test_vid_source.csv"; this takes longer to run than Hybrid's FFmpeg command above but is much more accurate, and in this case has the correct number of frames (12,434). You may want to consider using this instead of FFmpeg with -fps_mode passthrough.
  
  
• HybridDebugOutput_variable.zip - Hybrid's highest level debug output file for re-encoding the source file with Hybrid and variable bitrate using Test_vid_source.tc timecode v2 file with incorrect number of frames (19,173); number of frames (8,065) and duration (00:03:27.485) in output file are incorrect.
  
  
• HybridDebugOutput_constant.zip - Hybrid's highest level debug output file for re-encoding the source file with Hybrid and constant bitrate; number of frames (12,434) and duration (00:05:19.887) are correct in output file, audio is synced, but playback is choppy and video frame captures don't line up between source and destination matching frame numbers.
  
  AI Output Files
  
  
• abacus_ai_chat_llm_agent_max.md - Full output from Abacus AI ChatLLM Agent/Max.
  
  
• Test_vid_source_correct_v2.tc - "The corrected timecode v2 file built from your ffprobe CSV: 12,434 timestamps in ms, presentation order, starting at 0."
  
  
• csv_to_tcv2.py - "Converts any ffprobe pts_time CSV into a v2 timecode file (run: python csv_to_tcv2.py in.csv out.tc)."
  

• by enabling "Config->Input->Decoding->CFR output" you tell Hybrid to decode the source to CFR (with the detected average frame rate)
  
• if the target frame rate is not detected correctly or should be something else "Filtering->Misc->Overwrite Input->Frame rate" allows to set the frame rate that should be assumed
  

Quote:The container timebase is 19200 Hz (a multiple of 60, i.e. 320 ticks per refresh). ffmpeg shows 38.87 fps, 59.94 tbr, 19200 tbn. "tbr" is only ffmpeg's guess at the base rate, and it rounds to the nearest standard value, 59.94. The real base is 60.000. That 59.94-vs-60 mismatch is part of why the bad timecode file is a pure 16/17 ms grid (13,101 × 17 ms, 6,071 × 16 ms): it's a 59.94 CFR grid and has nothing in common with the real timestamps. 10,527 of the 12,434 real timestamps don't appear in it at all.