Repository navigation
fix(engine): h265 renders no longer fail on hosts with more than 16 cores - #6193
Conversation
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head 214459ff
The libx265 cap itself is right, and both engine call sites pass the encoder.
Blocker: packages/producer/src/services/distributed/assemble.ts:288 (cfrEncodeArgs) still calls appendSoftwareEncoderThreadsArg(args) with one argument. The new required encoder parameter means the producer no longer typechecks: tsc --noEmit -p packages/producer reports assemble.ts(288,3): error TS2554: Expected 2-3 arguments, but got 1. That encode is libx264, so the fix is appendSoftwareEncoderThreadsArg(args, "libx264").
CI: the Comments workflow already fails at this head. softwareEncoderThreads.ts goes from 10.0% to 13.3% comment share because of the new doc line on X265_MAX_THREADS, and the ratchet asks for it to move into a name or be cut. CI (Typecheck) was still running when I posted.
Edit accuracy: accurate 271 (base branch 271), smooth 148 of thoseThe gate passes. Quarantined, measured but not gated (0) Unstable (1)
|
…ores libx265 rejects more than 16 frame threads, so the thread count taken from the CPU quota is now capped at 16 for x265. x264 is unchanged.
214459f to
5f51d2d
Compare
There was a problem hiding this comment.
Verdict: APPROVE · 1 resolved, 0 open, 0 new · 214459ff → 5f51d2d3
The assemble.ts:288 caller now passes libx264, and the Comments ratchet passes. Locally, tsc for the producer and the engine is clean, and softwareEncoderThreads.test.ts passes (6 tests, including the real-ffmpeg 17-versus-16 case). CI and Windows render verification were still running when I posted.
Every h265 render failed on a host with more than 16 cores: ffmpeg exited 183 with
frameNumThreads (--frame-threads) must be [0 .. X265_MAX_FRAME_THREADS). The thread count introduced for stable bitstreams passed the CPU quota straight to libx265, which accepts at most 16.The one place that sets the count now caps libx265 at 16 (
X265_MAX_THREADS) and leaves libx264 as it was. Output stays the same on every host above 16 cores.Tests:
-c:v libx265 -threads 17exits non-zero,-threads 16encodes.