1. Start an encoding job in Hybrid.
   
2. Enable the automatic shutdown action after job completion.
   
3. Wait until the encoding job finishes.
   
4. Observe the shutdown countdown.
   

Plugin	Namespace	Functionality	Notes
VS-AudioTools	atools	Convert, Crossfade, Delay, FadeIn, FadeOut, FindPeak, Mix, Normalize, SineTone	Most comprehensive dedicated audio utility plugin found
AudioBoost	ab	Soft clipping, saturation, nonlinear amplification	WIP, VapourSynth compatibility need to be tested
AudioResample	Historical	Sample-rate and sample-format conversion	Functionality now available natively through Vapoursynth
Faveworm	fw	Visualization	Analog oscilloscope emulation, waveform rendering, trigger mode, scrolling mode, X-Y mode
BestSource	bs	Audio/video source using FFmpeg	Source plugin, sample-accurate audio access

Function	Category	Functionality
AssumeSampleRate	Format	Assume a different sample rate
AudioGain	Gain	Linear amplification, per-channel gain
AudioLoop	Editing	Repeat audio samples
AudioMix	Mixing	Arbitrary channel mixing matrix, multiple input clips
AudioResample	Conversion	Sample-rate, sample-type, bit-depth and channel-layout conversion
AudioReverse	Editing	Reverse audio samples
AudioSplice	Editing	Concatenate audio clips
AudioTrim	Editing	Sample-accurate trimming
BlankAudio	Generation	Generate silence, sine, square, triangle or sawtooth signals
SetAudioCache	Infrastructure	Configure audio-node caching
ShuffleChannels	Channels	Extract, reorder and combine channels
SplitChannels	Channels	Split multichannel audio into mono clips

Feature	Native	External
Gain adjustment	Yes	atools
Peak normalization	No	atools
Loudness normalization	No	None identified
Soft clipping	No	AudioBoost
Dynamic compression	No	No conventional compressor identified
Equalization	No	None identified
Noise reduction	No	None identified
Time stretching	No	None identified
Pitch shifting	No	None identified
Reverb / convolution	No	None identified
Fades / crossfades	No dedicated filter	atools
Delay	No dedicated DSP filter	atools
Mixing / downmixing	Yes	atools
Resampling	Yes	Native
Dithering	Yes	Native

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: 17)

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)."
  

• OS: Linux Mint 22.3 (64-bit)
  
• Hybrid version: 2026.10.24.1
  
• Input: Blu-ray playlist (MPLS)
  

• SVT-AV1 4.0.1
  
• CRF 24, preset/speed 6
  
• Source: Blu-ray playlist
  
  00101.mpls
• Intended output:
  
  see debug log file

1. Open a Blu-ray folder in Hybrid.
   
2. Select playlist
   
   01768.mpls
   (duration approximately 00:08:33).
   
3. Select the AC-3 audio track and enable audio passthrough.
   
4. Start the processing job.
   
5. Inspect the resulting audio duration.
   

• Hybrid's bundled FFmpeg version: 8.0.1
  
• The problem is reproducible without audio or video re-encoding.
  
• The Blu-ray source files have not been modified.
  

• Format: PAL 576i, Interlaced TFF, ProRes 422