docs(26.04): port SME video encoder docs (VP9 + BYO H.264)

[lbliii]

Summary

Ports SME-authored doc edits for the video transcoding encoder rework into the latest 26.04 fern pages.

Origin: the SME work landed across two PRs targeting r1.2.0:

• fix: drop libopenh264 and libx264, keep h264_nvenc only #1918 — original "drop libopenh264/libx264, keep h264_nvenc only" — closed.
• Remove libopenh&libx264 and Add vp9 #1930 — superseded fix: drop libopenh264 and libx264, keep h264_nvenc only #1918 with a richer three-encoder model — merged.

This PR mirrors #1930's docs delta into fern/versions/v26.04/pages/.

What's in #1930 that we ported

• Adds libvpx-vp9 as a built-in CPU fallback encoder for non-NVENC GPUs (A100/H100). VP9-in-MP4, BSD-licensed.
• Restores libopenh264 as an opt-in BYO encoder accepted by ClipTranscodingStage when a user-installed FFmpeg provides it. The stage probes at setup and raises with a docs link if missing.
• New "Bring-Your-Own H.264 Software Encoder (Advanced)" section in installation docs with system-FFmpeg path, custom-build path, SUPPORTED_ENCODERS extension instructions, and GPL caveat for libx264.
• A100/H100 NVENC-less callouts in get-started and tutorial pages.

Files changed

docs/ in #1930	fern/versions/v26.04/pages/ in this PR
admin/installation.md	get-started/installation.mdx
get-started/video.md	get-started/video.mdx
curate-video/index.md	curate-video/index.mdx
curate-video/process-data/index.md	curate-video/process-data/index.mdx
curate-video/process-data/transcoding.md	curate-video/process-data/transcoding.mdx
curate-video/tutorials/beginner.md	curate-video/tutorials/beginner.mdx
curate-video/tutorials/split-dedup.md	curate-video/tutorials/split-dedup.mdx

Scope

This PR is docs-only. The companion code changes from #1930 (SUPPORTED_ENCODERS validator, libopenh264 setup probe, libvpx-vp9 routing in ClipTranscodingStage) and the install_ffmpeg.sh script update live on r1.2.0 and need to be forward-ported to main separately. Until that lands, these docs describe behavior the code on main does not yet have.

Test plan

• Fern preview renders without errors
• Encoder tables, code examples, and CLI flag references list h264_nvenc, libvpx-vp9, and libopenh264 (BYO) with correct hwaccel guidance
• BYO H.264 section is reachable via in-page anchors from transcoding.mdx and video.mdx

🤖 Generated with Claude Code

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[greptile-apps]

Greptile Summary

This PR ports the SME-authored encoder rework docs from r1.2.0 into the v26.04 Fern pages, replacing libopenh264/libx264 as default encoders with h264_nvenc (GPU) and libvpx-vp9 (CPU fallback), and adding a new "Bring-Your-Own H.264 Software Encoder" section in the installation guide. The beginner.mdx tutorial correctly fixes use_hwaccel=False → use_hwaccel=True to match the h264_nvenc encoder.

• Encoder table overhaul: transcoding.mdx replaces the libx264/libopenh264 rows with libvpx-vp9 and repositions libopenh264 as an opt-in BYO encoder, with A100/H100 callouts throughout.
• New BYO H.264 section in installation.mdx documents three paths (bundled script, system FFmpeg, image rebuild) for adding software H.264 codec support, referencing install_h264_support.sh and install_ffmpeg.sh.
• Quickstart commands across video.mdx, split-dedup.mdx, and transcoding.mdx switch from libopenh264 to h264_nvenc but several are missing the required --transcode-use-hwaccel / use_hwaccel=True flag that NVENC requires.

Confidence Score: 3/5

Multiple quickstart examples across video.mdx, split-dedup.mdx, and transcoding.mdx switch to h264_nvenc but omit the required hwaccel flag/parameter, leaving users with a broken NVENC configuration. The installation.mdx BYO H.264 section references install_h264_support.sh, a script that does not yet exist in the repository.

Several command and code examples now specify h264_nvenc without the accompanying use_hwaccel=True / --transcode-use-hwaccel flag that NVENC requires to engage hardware encoding. A user copying any of those quickstarts will get a silently wrong pipeline. On top of that, the recommended BYO H.264 fix points to a script that has not been forward-ported to main, so the Recommended path errors out immediately. These issues are spread across three files and the installation guide, making the PR's primary user-facing guidance unreliable until the companion code lands.

installation.mdx (references non-existent install_h264_support.sh and mismatches the actual install_ffmpeg.sh behaviour), video.mdx and split-dedup.mdx (h264_nvenc quickstarts missing --transcode-use-hwaccel), transcoding.mdx (Pipeline Stage quickstart missing use_hwaccel=True)

Important Files Changed

Filename	Overview
fern/versions/v26.04/pages/curate-video/tutorials/beginner.mdx	Encoder updated from libopenh264 to h264_nvenc and use_hwaccel correctly set to True; A100/H100 guidance added.
fern/versions/v26.04/pages/curate-video/index.mdx	Removed libopenh264 and libx264 card tags; card description still reads 'Encode clips to H.264' though libvpx-vp9 (VP9) is now a supported encoder — minor inaccuracy.
fern/versions/v26.04/pages/curate-video/process-data/index.mdx	Removed libopenh264 card tag; same minor H.264-only description inaccuracy as index.mdx.
fern/versions/v26.04/pages/curate-video/process-data/transcoding.mdx	Encoder table and BYO H.264 Notes are well-structured, but the Pipeline Stage quickstart still omits use_hwaccel=True for h264_nvenc, and two Note blocks reference install_h264_support.sh which does not yet exist in the repo.
fern/versions/v26.04/pages/curate-video/tutorials/split-dedup.mdx	Encoder switched to h264_nvenc but --transcode-use-hwaccel flag was not added; NVENC path will be silently misconfigured.
fern/versions/v26.04/pages/get-started/installation.mdx	New BYO H.264 section is thorough, but references install_h264_support.sh (not yet in repo), the script description mismatches the actual install_ffmpeg.sh still building libopenh264, and Option 2/3 libopenh264 instructions may be redundant with what the existing script already does.
fern/versions/v26.04/pages/get-started/video.mdx	FFmpeg dependency section and encoder CLI flag table are improved, but the quickstart command and saved-config Tip block both switch to h264_nvenc without adding --transcode-use-hwaccel, and the script description has the same mismatch as installation.mdx.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User runs ClipTranscodingStage] --> B{GPU has NVENC silicon?}
    B -- Yes --> C["encoder='h264_nvenc'\nuse_hwaccel=True"]
    B -- No A100/H100 --> D["encoder='libvpx-vp9'\nuse_hwaccel=False\nOutputs VP9 in .mp4"]
    B -- Need H.264 SW --> E{install_h264_support.sh available?}
    E -- Yes --> F["Run: bash install_h264_support.sh --with-libopenh264\nThen encoder='libopenh264'"]
    E -- No --> G[Script not yet ported to main — blocked]
    C --> H[NVENC high-throughput H.264]
    D --> I[CPU VP9 encode]
    F --> J[CPU H.264 via OpenH264]
    style G fill:#f66,color:#fff
    style E fill:#fa0,color:#000

Loading

_{Reviews (6): Last reviewed commit: "Merge branch 'main' into lbliii/port-sme..." | Re-trigger Greptile}

[greptile-apps]

Script description no longer matches the actual script contents

docker/common/install_ffmpeg.sh still installs libopenh264-dev via apt and passes --enable-libopenh264 to the FFmpeg configure step. The updated prose saying the script "enables --enable-cuda-nvcc and --enable-libnpp" is now inaccurate — it omits --enable-libopenh264, which the script still sets. Until the script itself is updated (noted as out-of-scope here), the old description is more accurate.

Suggested change

	Use the maintained script in the repository to build and install `FFmpeg` with NVIDIA NVENC support. The script enables `--enable-cuda-nvcc` and `--enable-libnpp`.
	Use the maintained script in the repository to build and install `FFmpeg` with `libopenh264` and NVIDIA NVENC support. The script enables `--enable-libopenh264`, `--enable-cuda-nvcc`, and `--enable-libnpp`.

[greptile-apps]

Same script description mismatch as in installation.mdx

The install_ffmpeg.sh script still includes libopenh264-dev and --enable-libopenh264 in the build. Describing it as only enabling --enable-cuda-nvcc and --enable-libnpp is incorrect until that script is actually updated.

Suggested change

	Use the maintained script in the repository to build and install `FFmpeg` with NVIDIA NVENC support. The script enables `--enable-cuda-nvcc` and `--enable-libnpp`.
	Use the maintained script in the repository to build and install `FFmpeg` with `libopenh264` and NVIDIA NVENC support. The script enables `--enable-libopenh264`, `--enable-cuda-nvcc`, and `--enable-libnpp`.

[greptile-apps]

The quickstart Pipeline Stage example was updated to h264_nvenc but omits use_hwaccel=True. The Configure section directly below and the beginner.mdx tutorial both pair h264_nvenc with use_hwaccel=True, and the parameter table explicitly notes "Enable when using GPU encoders like h264_nvenc." A reader copying this quickstart will get a silently misconfigured pipeline that may fail to engage NVENC.

Suggested change

	pipe.add_stage(ClipTranscodingStage(encoder="h264_nvenc", encode_batch_size=16, encoder_threads=1, verbose=True))
	pipe.add_stage(ClipTranscodingStage(encoder="h264_nvenc", use_hwaccel=True, encode_batch_size=16, encoder_threads=1, verbose=True))

[greptile-apps]

The new BYO H.264 section opens with a claim that contradicts the actual script. docker/common/install_ffmpeg.sh already installs libopenh264-dev via apt and passes --enable-libopenh264 to the configure step — so libopenh264 is bundled in the default Curator FFmpeg build. The "Option 2" instructions that follow ("add libopenh264-dev to the apt list and --enable-libopenh264 to the configure flags") would be adding flags that are already present, misleading users into thinking a rebuild is required when the encoder is already available out of the box.

Suggested change

	Curator's default FFmpeg build deliberately excludes software H.264 encoders (`libopenh264`, `libx264`, `libx265`). If your environment permits these encoders and you want H.264 software encoding (for example, on GPUs without an NVENC encoder block such as A100 or H100), you can install them yourself.
	Curator's default FFmpeg build includes `libopenh264` but excludes `libx264` and `libx265`. If your environment requires `libx264` or `libx265`, or you want to use a different system-installed FFmpeg, you can configure them yourself.

[greptile-apps]

The encoder was changed from libopenh264 (CPU, no hwaccel needed) to h264_nvenc (GPU/NVENC), but --transcode-use-hwaccel was not added. Without this flag the CLI defaults to use_hwaccel=False, which disables the hardware acceleration path that NVENC requires — the same pairing issue that was fixed in beginner.mdx for the Python API. The transcoding.mdx Script Flags quickstart correctly includes --transcode-use-hwaccel alongside h264_nvenc.

Suggested change

	--transcode-encoder h264_nvenc \
	--verbose
	--transcode-encoder h264_nvenc \
	--transcode-use-hwaccel \
	--verbose

[suiyoubi]

LGTM! Thanks for helping with the docs change

[greptile-apps]

install_h264_support.sh referenced but does not exist in the repository

docker/common/install_h264_support.sh is cited as the "Recommended" fix in three separate pages (installation.mdx, video.mdx, transcoding.mdx), but git ls-files docker/common/ confirms only install_ffmpeg.sh, install_etcd_nats.sh, and install_haproxy.sh exist. A user following the recommended path will immediately hit bash: /opt/Curator/docker/common/install_h264_support.sh: No such file or directory. The PR description acknowledges companion code from r1.2.0 needs forward-porting but names only install_ffmpeg.sh — install_h264_support.sh appears to be a net-new script that hasn't been ported yet.

[ayushdg]

/ok to test f6410d9