perf(ltx23): cap PyAV libx264 encode threads at 12#20
Merged
Johan-de-R merged 1 commit intoJul 9, 2026
Conversation
…> x264-tuning) The PyAV single-pass save path (the one we actually run on B200 — no ffmpeg on PATH) set no `threads` option, so libx264 auto-detected all ~288 node cores and thrashed. PR #8's -threads cap only ever applied to the dead ffmpeg-pipe path. Isolated encode-only sweep (di-slc-46 B200, 121f 1080p, conversion excluded, 6 reps median): threads=1 1.020s threads=10 0.419s <- sweet spot threads=4 0.530s threads=12 0.445s threads=8 0.439s threads=16 0.637s <- worse past here threads=default(288) 1.65s total (thrash) threads=32 0.674s More threads do NOT help: x264 slice-threading on a single 1080p stream saturates ~10-12, then slice/sync overhead makes it slower. 12 = fastest AND well under a fair share (no noisy-neighbor tradeoff). Extends the existing PyAV scenecut patch (renamed pyav-scenecut -> pyav-x264-tuning since it now does both). Env-configurable via FASTVIDEO_X264_THREADS_PYAV (no rebuild to change). Verified: applies --fuzz=0 to pristine fastvideo source. Deploys with the next image rebuild. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Johan-de-R
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The PyAV single-pass save path (
_save_video_with_audio_single_pass) — the one we actually run on B200 (no ffmpeg on PATH → the ffmpeg-pipe path never executes) — set nothreadsoption, so libx264 auto-detected all ~288 node cores and thrashed. PR #8's-threads 32cap only ever applied to the dead ffmpeg-pipe path.This adds a thread cap (default 12, env
FASTVIDEO_X264_THREADS_PYAV) to the PyAV libx264 stream, by extending the existing PyAV scenecut patch (renamedpyav-scenecut.patch→pyav-x264-tuning.patchsince it now tunes both).Data (isolated encode-only sweep, di-slc-46 B200, 121f 1080p, conversion excluded, 6 reps, median)
More threads do not help: x264 slice-threading on a single 1080p stream saturates ~10–12, then slice/sync overhead makes it slower. 12 is fastest AND well under a fair share — no noisy-neighbor tradeoff (going higher is strictly dominated). Even the ffmpeg-path's
32is past the knee.Net effect on the save is modest (~0.1s in the interleaved total; the ~1.5s color conversion still dominates — separate, bigger fix coming), but it's free and correct.
Verification
patch --fuzz=0re-verified against pristine fastvideo source (reversed the old scenecut patch, dry-ran + applied the new one): applies clean, produces bothFASTVIDEO_X264_SCENECUTandFASTVIDEO_X264_THREADS_PYAV. Deploys with the next image rebuild.🤖 Generated with Claude Code