majestic-encoder-tuning: document the reference structure and the fpv block - #480
majestic-encoder-tuning: document the reference structure and the fpv block#480widgetii wants to merge 1 commit into
Conversation
… block None of this was documented anywhere. The `fpv:` section had no coverage at all — not one of its nine keys, despite two dozen FPV pages in the wiki — and `video0.svct` was equally absent, so anyone finding these settings in a config dump had nothing to read. The page leads with the reference structure, because that is the setting with a real decision behind it. `refEnhance: 0` with `refPred: false` makes every P frame reference the keyframe, so a lost frame costs exactly one frame instead of corrupting everything up to the next keyframe. What it costs is prediction efficiency, and that decays as the keyframe ages — which makes `gopSize` the knob that decides whether this is cheap or ruinous. Bitrate against keyframe interval turns out to be U-shaped, with the minimum moving as the scene moves, so the page gives the measured curve and says to start at 1.0 and shorten under motion. That is the opposite of the usual longer-GOP-saves-bitrate advice, which is exactly why it needs writing down. Two warnings that cost real debugging time: `refEnhance` must be 0 and not 1 (with 1 only half the frames reference the keyframe and the rest still propagate), and this is not a licence to drop FEC — every P frame depends on one keyframe, and losing it is silent, because the decoder resolves against a stale reference and reports nothing. Also documents the remaining fpv keys, `svct` and its per-session `?thin=1`, the per-vendor support matrix, and the fact that a reload does not apply any of it. The measurements are all HiSilicon and the page says so, since SigmaStar takes the same parameters through the same call but has not been confirmed on hardware. The example config gains commented `svct` and `fpv:` blocks pointing here.
PR Summary by QodoDocument Majestic encoder tuning (reference structure, fpv, svct)
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTo customize comments, go to the Qodo configuration screen, or learn more in the docs. |
Closes a documentation gap that turned out to be wider than one setting.
What was missing
fpv.refEnhance/fpv.refPredfpv:section — all nine keysvideo0.svctThere are two dozen FPV pages in the wiki and not one documented a single
fpv.*config key. Anyone who found these in a config dump had nothing to read.What this adds
A new page, Majestic encoder tuning, plus commented
svctandfpv:blocksin the example config and a table-of-contents entry.
The page leads with the reference structure, because that is the setting with a
real decision behind it.
refEnhance: 0withrefPred: falsemakes every Pframe reference the keyframe, so a lost frame costs exactly one frame rather
than corrupting everything up to the next keyframe — measured on a Hi3516CV500,
the frame after a dropped NAL is bit-exact.
What it costs is prediction efficiency, and that decays as the keyframe ages,
which makes
gopSizethe knob that decides whether this is cheap or ruinous.Bitrate against keyframe interval is U-shaped, and the minimum moves with
scene motion:
gopSizeSo the page says to start at
1.0and shorten under motion — the opposite ofthe usual "longer GOP saves bitrate" advice, which is exactly why it needed
writing down.
Two warnings that cost real debugging time are called out explicitly:
refEnhancemust be 0, not 1. With1only half the frames reference thekeyframe and the rest still propagate errors to the end of the GOP.
which is ~90 packets at a 1400-byte MTU; with no FEC this loses 67% of frames
at 1% packet loss. And losing that keyframe is silent — the decoder resolves
against a stale reference and reports no error.
Also covered: the remaining
fpvkeys (including thatfpv.enableddisablesuserspace 3A as a side effect),
svctand its per-session?thin=1, aper-vendor support matrix, and the fact that a config reload does not apply any
of it — the SDK only accepts these between channel creation and encoding start.
Accuracy note
Every measurement on the page is HiSilicon, and the page says so. SigmaStar
takes the identical parameters through the identical vendor call, but the
behaviour of
refEnhance: 0withrefPred: falsehas not been confirmed thereon hardware, so the page gives readers a self-check (raise
gopSize; with thismode active the bitrate goes up) before relying on it.
HiSilicon support for these two keys lands with widgetii/majestic#283; SigmaStar
has shipped them since the fpv work.
🤖 Generated with Claude Code