Skip to content

test(engine): cover h265 NVENC in preset-mapping regression tests#443

Merged
jrusso1020 merged 1 commit intoheygen-com:mainfrom
roiizchak:test/nvenc-h265-preset-mapping
Apr 23, 2026
Merged

test(engine): cover h265 NVENC in preset-mapping regression tests#443
jrusso1020 merged 1 commit intoheygen-com:mainfrom
roiizchak:test/nvenc-h265-preset-mapping

Conversation

@roiizchak
Copy link
Copy Markdown
Contributor

What

Adds codec: "h265" regression cases to the NVENC preset-mapping test block added in #442.

Why

Follow-up to #442 per review comment from @jrusso1020:

hevc_nvenc also uses p1..p7 and the fix correctly applies to both H.264 and H.265 NVENC paths — but the integration tests only cover codec: "h264". NVENC's preset vocabulary is codec-agnostic so the mapping is correct for both, but one codec: "h265" case in chunkEncoder.test.ts would lock in "both codecs share the mapping" against a future refactor.

Locks in "both H.264 and H.265 NVENC share the preset mapping" so a future refactor that splits the codec paths can't silently regress one of them.

How

Three-case table-driven block (ultrafast → p1, medium → p4, veryslow → p7) under codec: "h265", added to both buildEncoderArgs (chunkEncoder.test.ts) and buildStreamingArgs (streamingEncoder.test.ts). Each case also asserts -c:v hevc_nvenc lands in the arg vector so the test fails loudly if the codec plumbing breaks, not just the preset translation.

No production-code changes — pure test additions.

Test plan

  • Unit tests added/updated — 2 new cases (one per encoder file); each case loops over 3 preset/codec combos
  • bun run --filter @hyperframes/engine test src/services/chunkEncoder.test.ts src/services/streamingEncoder.test.ts → 68/68 pass (was 66, +2)
  • oxfmt --check clean on both files
  • Documentation updated (if applicable) — test-only, no docs.

hevc_nvenc uses the same p1..p7 preset vocabulary as h264_nvenc, so the
mapping in `mapPresetForGpuEncoder` applies to both codecs. The initial
regression suite only covered `codec: "h264"`, which left a gap: a
future refactor that split the H.264 and H.265 NVENC paths could
silently regress one codec without any test catching it.

Add three-case loops (ultrafast → p1, medium → p4, veryslow → p7) under
`codec: "h265"` to both `buildEncoderArgs` and `buildStreamingArgs`
test blocks. Each case also asserts that `-c:v hevc_nvenc` is selected
so the test fails loudly if the codec plumbing is broken, not just the
preset translation.

Follow-up to heygen-com#442 per review comment from @jrusso1020.
Copy link
Copy Markdown
Collaborator

@jrusso1020 jrusso1020 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: approve

Exactly lands the h265 NVENC coverage gap I flagged in #442 — both buildEncoderArgs and buildStreamingArgs get a parametrized 3-case block (ultrafast → p1, medium → p4, veryslow → p7) under codec: "h265". Endpoints + middle of the mapping table is the right sample set.

Bonus: each case also asserts -c:v hevc_nvenc lands in the arg vector, not just the preset. That's stronger than what I asked for — locks in the H.265 codec plumbing too, so a future refactor that accidentally routes codec: "h265" to libx265 under useGpu: true would fail loudly at test time rather than silently falling back to CPU.

Pure test additions, zero production code changes, all unit/lint/typecheck/windows checks green on this head. Tight followup.


Review by hyperframes

@jrusso1020 jrusso1020 merged commit c11a332 into heygen-com:main Apr 23, 2026
27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants