feat(venc): expose video0.maxIpProp, the RC I-to-P size cap the firmware honours

[vertexodessa]

Summary

Exposes video0.maxIpProp (canonical video0.max_ip_prop): the u32MaxIPProp field of MI_VENC_RcParam_t (stParamH265Cbr / stParamH264Cbr), the CBR rate controller's cap on I-frame size as a proportion of P frames.

Motivation: the per-frame byte caps maxIBytes/maxPBytes are inert on Star6E firmware. Probed live 2026-08-22 under H.265 CBR at 10 Mbps, IDRs measured an identical 42-44 KB with the caps at 2000, 26000, and 8, and switching RC priority changed nothing. qpDelta barely moves IDR size either (43 KB at 0 and at -6) because the CBR RC owns the I/P QP relationship. u32MaxIPProp is the parameter the SigmaStar CBR RC actually honours; waybeam never set it, so the permissive SDK default is why recovery IDRs land at ~3x the P-frame budget and occupy ~60 ms of air at 10 Mbps.

Behaviour

• Live on Star6E and Maruko via /set and /live/set, through a new LIVE_GROUP_MAX_IP_PROP. Applied at boot when persisted.
• Range 0..100, CBR only. Validated in validate_field_cfg() like minQp/maxQp: values above 100 and a non-zero value under a non-CBR rc_mode are rejected with 409 on /set, /live/set, and at config load, so the backend apply never sees them (and a negative JSON value, which the loader wraps large, is caught the same way).
• 0 = SDK default. The first apply captures the driver's value so 0 can restore it live, mirroring the minQp/maxQp pattern. The captured default lives in each backend's existing control context struct, not a new file-scope global.
• CV610 reports the field unsupported.
• Contract 0.18.2 -> 0.18.3 (additive): table row + changelog entry in HTTP_API_CONTRACT.md, /api/v1/version string bumped.
• config/waybeam.default.json gains "maxIpProp": 0 so the save-layout byte-equal test keeps policing the printer.
• VERSION 0.65.2 -> 0.66.0, HISTORY.md entry.

Verification

• make test: 2491 passed, 0 failed (adds a loader validation table for maxIpProp)
• make build SOC_BUILD=star6e and SOC_BUILD=maruko: clean
• Star6E apply path exercised live on the bench link (the same session that established the byte caps are dead). Maruko apply is the same RC-param read-modify-write as Star6E but was not run on a Maruko device; please treat that backend as compile-tested only.

Independent of #110; whichever merges second needs a trivial VERSION/HISTORY.md rebase.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Expose video0.maxIpProp (u32MaxIPProp) as live CBR I/P size cap

✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add video0.maxIpProp/video0.max_ip_prop as a live-applied CBR RC control.
• Implement Star6E/Maruko RC-param read/modify/write with driver-default restore via 0.
• Bump contract/app versions and document backend support/limitations.

Diagram

graph TD
  A["Client: /set or /live/set"] --> B["venc_api.c: live apply groups"] --> C["VencApplyCallbacks.apply_max_ip_prop"] --> D["star6e_controls.c / maruko_controls.c"] --> E["MI_VENC Get/Set RC param"]
  F[("config JSON") ] --> G["*_runtime.c: startup apply"] --> C

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Expose a backend-agnostic “RC params” endpoint (generic struct patching)

• ➕ Avoids adding one-off fields and live groups per RC knob
• ➕ Scales better if more MI_VENC_RcParam_t fields become needed
• ➖ Much larger API surface and validation burden
• ➖ Harder to keep stable across backends/SDK versions
• ➖ More footguns (users can set inconsistent param combinations)

2. Capture driver default at encoder init (instead of first apply)

• ➕ Makes the meaning of 0 deterministic immediately after startup
• ➕ Avoids relying on “first write” lifecycle behavior
• ➖ Requires extra init-time driver queries even if the feature is unused
• ➖ More wiring between init and control paths (per-channel state management)

3. Fold `maxIpProp` into existing max-frame-size live group

• ➕ Fewer live groups to reason about
• ➕ One apply path for I-frame sizing-related knobs
• ➖ Conflates independent semantics (byte caps vs ratio cap) and mode restrictions
• ➖ Harder to return accurate per-field support/errors (CBR-only vs general)

Recommendation: The PR’s approach (a dedicated video0.maxIpProp field, its own live group, and backend callbacks that are NULL when unsupported) is the best tradeoff: it keeps the API narrow, validates behavior cleanly (CBR-only), and preserves the existing “0 restores driver default” pattern used for QP bounds. If follow-up work is planned to expose more RC knobs, consider the generic RC-param patching approach, but it’s overkill for a single proven-effective control.

Files changed (12) +175 / -3

Enhancement (8) +149 / -1

venc_api.hAdd apply_max_ip_prop callback to VencApplyCallbacks +5/-0

Add apply_max_ip_prop callback to VencApplyCallbacks

• Introduces a new backend hook for live-updating 'u32MaxIPProp', including the '0' restore-to-driver-default behavior and support expectations (NULL when unsupported).

include/venc_api.h

venc_config.hAdd max_ip_prop to video config struct +6/-0

Add max_ip_prop to video config struct

• Extends 'VencConfigVideo' with 'max_ip_prop' and documents its purpose and observed firmware behavior motivating the control.

include/venc_config.h

maruko_controls.cImplement Maruko apply_max_ip_prop via RC param update +51/-0

Implement Maruko apply_max_ip_prop via RC param update

• Adds a CBR-only RC-param update function that captures the driver default on first use and allows restoring it by writing '0'. Wires the implementation into Maruko’s apply callback table.

src/maruko_controls.c

maruko_runtime.cApply max_ip_prop at Maruko startup when configured +5/-0

Apply max_ip_prop at Maruko startup when configured

• Applies a persisted non-zero 'video0.max_ip_prop' during runner initialization when the backend supports the callback.

src/maruko_runtime.c

star6e_controls.cImplement Star6E apply_max_ip_prop via MI_VENC RcParam +48/-0

Implement Star6E apply_max_ip_prop via MI_VENC RcParam

• Adds a CBR-only 'u32MaxIPProp' update path with driver-default capture/restore semantics and wires it into Star6E’s apply callbacks.

src/star6e_controls.c

star6e_runtime.cApply max_ip_prop at Star6E startup when configured +5/-0

Apply max_ip_prop at Star6E startup when configured

• Extends startup control application to set 'video0.max_ip_prop' when non-zero and the backend callback exists.

src/star6e_runtime.c

venc_api.cExpose max_ip_prop as live field with UI/aliasing and support checks +26/-1

Expose max_ip_prop as live field with UI/aliasing and support checks

• Adds field UI metadata, a camelCase alias ('video0.maxIpProp'), introduces a dedicated live-apply group, and routes live apply to the new backend callback. Also bumps the reported contract version to 0.18.3.

src/venc_api.c

venc_config.cParse/render/serialize maxIpProp in config +3/-0

Parse/render/serialize maxIpProp in config

• Adds JSON parsing from 'maxIpProp', includes the field in pretty-print rendering, and serializes it into the config JSON output.

src/venc_config.c

Documentation (2) +24 / -1

HISTORY.mdAdd 0.66.0 release notes for maxIpProp control +14/-0

Add 0.66.0 release notes for maxIpProp control

• Documents the new 'video0.maxIpProp' control, its motivation (byte caps inert on Star6E), backend support, and contract bump.

HISTORY.md

HTTP_API_CONTRACT.mdBump contract to 0.18.3 and document video0.max_ip_prop +10/-1

Bump contract to 0.18.3 and document video0.max_ip_prop

• Increments contract version, adds the new field to the backend divergence table, and records an additive changelog entry describing semantics, mode restrictions (CBR-only), and backend support.

documentation/HTTP_API_CONTRACT.md

Other (2) +2 / -1

VERSIONBump app version to 0.66.0 +1/-1

Bump app version to 0.66.0

• Updates the application version to reflect the new encoder control feature release.

VERSION

waybeam.default.jsonAdd default video0.maxIpProp field +1/-0

Add default video0.maxIpProp field

• Extends the default config with 'maxIpProp: 0' to keep the serialized layout stable and to default to SDK/driver behavior.

config/waybeam.default.json

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📜 Skill insights (0)

1. Non-CBR returns 500 🐞 Bug ≡ Correctness

Description

apply_max_ip_prop() returns -1 when the channel isn’t CBR, and the live-set pipeline converts any
apply failure into HTTP 500, contradicting the contract’s promised 409 for non-CBR rate modes. This
makes an expected user error look like an internal failure and breaks clients relying on 409
semantics.

Code

src/star6e_controls.c[R522-523]

+	default:
+		return -1;

Evidence

The new backend apply returns -1 on non-CBR, while the live apply pipeline converts any apply
failure into a 500. The contract text states non-CBR should be a 409, and the API validation path
only emits 409 when validate_field_cfg()/validate_backend_config() rejects the config (which
currently has no rule for video0.max_ip_prop).

src/star6e_controls.c[512-524]
src/venc_api.c[2369-2402]
src/venc_api.c[2306-2337]
documentation/HTTP_API_CONTRACT.md[1697-1708]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
When `video0.max_ip_prop` is set while the encoder is in a non-CBR mode, `apply_max_ip_prop()` returns `-1`, which the live apply pipeline converts to HTTP 500. The contract explicitly states this should be a 409 validation failure.

## Issue Context
- Contract: non-CBR rate modes should answer `409` for `video0.maxIpProp` applies.
- Current code path: `apply_max_ip_prop()` returns `-1` on non-CBR, and `apply_live_group_sequence_locked()` treats any non-zero apply result as a 500.

## Fix Focus Areas
- src/venc_api.c[1074-1307]
- src/venc_api.c[2306-2337]
- src/venc_api.c[2369-2402]

## Proposed fix
1. Add a `validate_field_cfg()` rule for `video0.max_ip_prop`:
  - If `cfg->video0.max_ip_prop != 0` and `strcmp(cfg->video0.rc_mode, "cbr") != 0`, return a static error string like: `"video0.max_ip_prop requires video0.rcMode=cbr"`.
  - Also enforce bounds (see separate finding) so invalid values never reach the backend.
2. Ensure `video0.max_ip_prop` is included in the loaded-config validation set (so persisted configs get rejected early too).

This routes non-CBR attempts through the existing 409 validation path (`stage_params_into_cfg()`), matching the documented contract and avoiding 500s for expected user errors.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. New global g_ip_prop_default 📘 Rule violation ⚙ Maintainability Coding Conventions

Description

The PR introduces new file-scope mutable globals (g_ip_prop_default and
g_maruko_ip_prop_default) to cache the driver default, increasing hidden coupling and reducing
testability.

Code

src/star6e_controls.c[R494-497]

+static struct {
+	int      captured;
+	uint32_t prop;
+} g_ip_prop_default;

Evidence

PR Compliance ID 9 prohibits introducing new global mutable state. The added `static struct { ... }
g_ip_prop_default; in src/star6e_controls.c and the analogous g_maruko_ip_prop_default` in
src/maruko_controls.c are new mutable globals introduced by this PR.

Rule Coding Conventions: Avoid New Global Mutable State
src/star6e_controls.c[492-531]
src/maruko_controls.c[390-431]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New global mutable state was added (`g_ip_prop_default` / `g_maruko_ip_prop_default`) to store the captured driver default for `max_ip_prop`.

## Issue Context
Compliance requires avoiding new global mutable variables/state when possible; this cache can typically live in an existing per-backend context struct instead of file-scope globals.

## Fix Focus Areas
- src/star6e_controls.c[492-531]
- src/maruko_controls.c[390-431]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Signed parse wraps unsigned 🐞 Bug ☼ Reliability

Description

The config loader reads maxIpProp via json_get_int() (signed int) and casts to uint32_t, so
negative JSON values (e.g. -1) become huge values (e.g. 4294967295) and will be applied at
startup because the startup guard is > 0. This can push nonsensical values into
MI_VENC_SetRcParam and create hard-to-debug startup misconfiguration.

Code

src/venc_config.c[630]

+	v->max_ip_prop = (uint32_t)json_get_int(obj, "maxIpProp", (int)v->max_ip_prop);

Evidence

The loader’s json_get_int() returns a signed int, but the new maxIpProp field stores into
uint32_t via a cast; the startup runtime then applies any non-zero value, so wrapped negatives
become huge and are eligible to be pushed into the driver.

src/venc_config.c[42-48]
src/venc_config.c[623-633]
src/star6e_runtime.c[850-860]
src/maruko_runtime.c[143-154]
src/venc_api.c[1309-1344]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`maxIpProp` is loaded from JSON as an `int` (`cJSON`’s `valueint`) and then cast to `uint32_t`. Negative values wrap to very large unsigned values, and the runtime startup path applies any `>0` value.

## Issue Context
- `json_get_int()` returns `item->valueint` (signed).
- `load_video0()` assigns `v->max_ip_prop = (uint32_t)json_get_int(...)`.
- Startup calls `apply_max_ip_prop()` when `max_ip_prop > 0`.

## Fix Focus Areas
- src/venc_config.c[42-48]
- src/venc_config.c[623-633]
- src/venc_api.c[1309-1344]
- src/star6e_runtime.c[850-860]
- src/maruko_runtime.c[143-154]

## Proposed fix
1. Change `load_video0()` parsing of `maxIpProp` to avoid signed-to-unsigned wrap, e.g.:
  - Parse into a temporary `int tmp = json_get_int(obj, "maxIpProp", (int)v->max_ip_prop);`
  - If `tmp < 0`, set to 0.
  - Assign `v->max_ip_prop = (uint32_t)tmp;`
2. Add a validator in `validate_field_cfg()` enforcing a safe range (consistent with UI metadata: 0..100).
3. Add `"video0.max_ip_prop"` to `venc_api_validate_loaded_config()`’s `keys[]` list so persisted configs are rejected at load time.

This prevents wrapped values from being persisted/applied and makes bad configs fail loudly instead of silently misapplying at boot.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[snokvist]

Adversarial review at e151a37b — one code blocker remains, plus targeted test gaps.

Blocking defect: the CBR dependency is validated only when the changed key is video0.max_ip_prop. Starting from a valid CBR config with maxIpProp=2, /api/v1/set?video0.rcMode=vbr validates only video0.rc_mode, is accepted and persisted, then requests a restart. The next config load iterates video0.max_ip_prop and rejects that same persisted config. This lets the API create a configuration that can prevent the daemon from returning after respawn. Please run the cross-field rule when either video0.max_ip_prop or video0.rc_mode changes, and add the reverse-direction API regression test (maxIpProp=2, then set rcMode=vbr -> 409 with no mutation/persist/reinit).

The current tests cover loader validation only. Please also cover:

• /set and /live/set: 0, 1, 100 accepted; 101, negative, and non-CBR rejected with 409;
• the reverse rcMode transition above;
• callback invocation/argument, failure rollback, camelCase alias, capabilities true on Star6E/Maruko and false on CV610;
• 0 restoring the captured default after a non-zero live apply (backend mock or a factored helper is sufficient for host coverage).

The PR text is accurate that Star6E and Maruko are wired through RC-param read/modify/write, CV610 is capability-gated, persisted validation catches wrapped negatives, and Maruko is compile-tested only. The statements that u32MaxIPProp is honoured and byte caps are inert are hardware-measurement claims, not established by this code or CI. The Star6E result is plausible but the PR currently has no raw procedure/log showing repeated IDR samples, RC-param readback, scene control, or restoration to default. Maruko still needs on-device verification before we call that backend confirmed; we can provide that hardware pass after the code/test blocker is fixed.

I reproduced make test = 2491/0 and make verify passing on this head.

[snokvist]

Maruko device test report (device observations only)

• PR head tested: e151a37b20c283e951a07fb1e7d3ed8f6726146a
• Built binary SHA-256: 41edf95ac13e721e5fa09f145a2bcabb3183931406286f31590623db81990712
• Device: SSC378QE/Maruko, IMX335. /api/v1/version: app 0.66.0, contract 0.18.3, backend maruko.
• /api/v1/capabilities advertised video0.max_ip_prop as supported/live, range 0..100.
• Transport/measurement: isolated H.265 RTP host port plus rtp_timing_probe sidecar frame_size_bytes/frame_type; all captures and TSVs were stored on the host.

Live/API checks under H.265 CBR, 1280x720@30, 10000 kbps, one-second GOP, qpDelta=-4, ROI/OSD off, and maxIBytes=maxPBytes=0:

• Values 2, 4, 100, and restored 0 each returned HTTP 200, read back immediately, and left the daemon PID unchanged.
• Each 16-second sample received 480 RTP frames at 30.0 fps with 0 RTP gaps.
• Matched sidecar/RTP frame-size samples were:

maxIpProp	P median / P95 (bytes)	IDR median / P95 (bytes)	matched P / IDR samples
0 baseline	47236 / 50144	27511 / 28057	314 / 13
2	47225 / 49644	27396 / 28031	280 / 8
4	47393 / 50133	27930 / 28241	293 / 12
100	47252 / 50146	27693 / 28041	307 / 9
0 restored	47172 / 49831	18494 / 27672	281 / 9

The probe received 480 sidecar FRAME datagrams per run; the size table includes only frames for which the probe matched RTP and sidecar metadata. In this scene, IDRs were already smaller than median P frames, and the tested values did not produce a monotonic/reproducible decrease. This test therefore verifies API/apply stability but does not demonstrate a binding maxIpProp hardware effect.

A second matrix used 3000 kbps, qpDelta=-12, five-second GOP, and 12 accepted /request/idr calls at 1.2-second spacing:

• maxIpProp=0: P median/P95 12860/13658 bytes (n=276); IDR 12195/12532 (n=11).
• maxIpProp=2: P median/P95 12763/13907 bytes (n=279); IDR 12200/12256 (n=9).
• Both runs remained about 29.3 fps with 0 RTP gaps. IDRs again were not larger than P frames, so this also did not establish a binding cap.

Validation/persistence observations:

• Values 101 and -1 each returned HTTP 409 with the documented 0..100 validation message; readback stayed 0 and PID was unchanged.
• Persistent /api/v1/set?video0.maxIpProp=20 returned 200, applied without a PID change, wrote 20 to /etc/waybeam.json, survived a normal service restart, read back as 20, and logged maxIpProp changed to 20 (0 = driver default 0). Persistent restore to 0 returned 200 and wrote/read back 0.

Existing byte-field comparison on the same device/config family, using forced IDRs:

• Baseline maxIBytes=maxPBytes=0: IDR range 12063..12532 bytes, median 12195 (n=11).
• maxIBytes=2000,maxPBytes=0: IDR range 4748..5918 bytes, median 5866 (n=3). No sampled IDR met a 2000-byte ceiling.
• maxIBytes=0,maxPBytes=2000: P median 2057, P95 2440, range 1238..5122 bytes (n=372). The field changed the distribution but did not impose a 2000-byte ceiling.
• Both capped samples continued about 29.3 fps with 0 RTP gaps.

Not tested here: Star6E, non-CBR modes, H.264, or a scene/config where IDRs exceed P frames enough to demonstrate whether maxIpProp binds. Post-test dmesg had no fault/timeout/watchdog match. The device was restored to its original binary and config; both pre-test hashes matched after restoration, and the original stream restarted.

[snokvist]

Star6E high-bitrate device test report (device observations only)

• PR head tested: e151a37b20c283e951a07fb1e7d3ed8f6726146a
• Built binary SHA-256: 27a04e2934e7e495d6ff559263f24b20a86105b46582000dcbfc6002d39f4463
• Device: SSC338Q/Star6E, IMX335 mode 1 (2560x1920@60 capture), H.265 1920x1080@60. /api/v1/version: app 0.66.0, contract 0.18.3, backend star6e.
• Test stream: isolated host UDP port; captures and TSVs were stored off-device.

Isolation correction: the first run was excluded after /api/v1/config showed the running waybeam_hub controller had rewritten maxIBytes/maxPBytes from 0 to 38728/5993. The controller was stopped through its init script; after that, bitrate, minQp, maxIBytes, maxPBytes, and maxIpProp remained unchanged for the test windows. The controller was restarted after testing.

Common isolated config: CBR, one-second GOP, qpDelta=-12, minQp=1, maxQp=0, maxIBytes=maxPBytes=0, resilience off, ROI/OSD off. minQp=1 was required for the encoder to spend the requested high bitrate; with the driver default it produced about 5.75 Mbps despite a 25 Mbps target.

At an achieved 24.7..25.5 Mbps, a continuous-motion paired sidecar sample produced:

maxIpProp	RTP result	P median / P95 bytes	IDR median / P95 bytes	matched P / IDR
0	1082 frames / 18 s, 60.1 fps, 0 gaps	54366 / 87414	5205 / 5352	681 / 18
2	1081 frames / 18 s, 60.1 fps, 0 gaps	53361 / 82072	4554 / 4734	693 / 7

Direct off-device H.265 access-unit measurements (ffprobe -show_packets, key flag checked against an Annex-B NAL walk showing one IDR_W_RADL per key AU) at the same achieved 25 Mbps:

maxIpProp	key AUs	mean key bytes	mean non-key bytes
0, first run	12	5306.8	54214.3
1	8	3711.5	54093.6
2	12	4673.2	54157.4
4	8	5352.0	54114.8
100	8	5355.9	54120.3
0, repeat	8	5390.2	54340.8

At an achieved 38.1..40.8 Mbps, direct six-second captures produced:

maxIpProp	key AUs	mean key bytes	mean non-key bytes
0	6	5877.5	86599.3
1	6	4181.0	86659.2
2	6	5819.2	86710.2

In these 25/40 Mbps configurations, value 1 reproducibly reduced key-AU size; value 2 reduced it in the 25 Mbps samples but not the 40 Mbps sample; values 4 and 100 matched the default-sized key AUs. Key AUs were already much smaller than ordinary AUs in every sample. Full-frame motion did not create the 42–44 KB IDR population described in the PR text on this device/config.

Existing byte-field comparison at achieved 25 Mbps:

• maxIBytes=2000,maxPBytes=0: 8 key AUs, mean 5283.0 bytes; 473 non-key AUs, mean 54216.9 bytes.
• maxIBytes=0,maxPBytes=2000: 8 key AUs, mean 5413.4 bytes; 472 non-key AUs, mean 54152.9 bytes.
• Uncapped repeat: mean key 5390.2 bytes and mean non-key 54340.8 bytes. Neither byte field imposed the requested 2000-byte ceiling or materially changed the direct-AU means in this Star6E run.

Not tested here: H.264, non-CBR rate modes, IMX415, or another Star6E firmware build. After testing, the original binary and config SHA-256 hashes matched their pre-test values, the original frame-SHM configuration was active, and waybeam_hub plus its supervisor were running again.

[snokvist]

Setup details for the Star6E measurements above

The encoder binary under test was the PR-head Star6E build already identified above:

• source: e151a37b20c283e951a07fb1e7d3ed8f6726146a
• /usr/bin/waybeam SHA-256 while testing: 27a04e2934e7e495d6ff559263f24b20a86105b46582000dcbfc6002d39f4463

Sensor/IQ environment:

• loaded module: sensor_imx335_star6e; module file /lib/modules/4.9.84/sigmastar/sensor_imx335_mipi.ko, SHA-256 ea6412c83faead6f3cc3b3de4686a50c7fb0de4564d176946282bcb59ad73eb4
• sensor.index=-1, sensor.mode=1; runtime selected pad 0, 2560x1920@60
• isp.sensorBin=/etc/sensors/imx335_spike5_colortrans.bin (configured, not auto-selected)
• the startup log records Loading ISP file followed by ISP file loaded successfully for that exact path
• IQ bin size: 88738 bytes; SHA-256 cbccca59740ba9bb6049865709f1223e9d900b1ed1d5247a68f983a6d7f5fe73
• isp.aeEngine=sdk, aeFps=15, awbFps=15, gainMax=0, shutterMaxUs=4000, awbMode=auto, awbCt=5000, keepAspect=true, shutterRule180=false
• runtime precrop: 2560x1440 @ 0,240

Encoder/test options after stopping the interfering waybeam_hub controller:

• system.overclockLevel=2, system.verbose=true
• H.265 CBR, video0.size=1920x1080, fps=60, gopSize=1, qpDelta=-12
• requested/achieved bitrate pairs: 25000 kbps / approximately 24700..25500 kbps, and 40000 kbps / approximately 38100..40800 kbps
• minQp=1, maxQp=0; minQp=1 was applied live so CBR actually spent the high target
• maxIBytes=0, maxPBytes=0 except during the explicitly labelled byte-cap controls
• maxIpProp=0/1/2/4/100 as labelled in each sample
• resilience=off, fpv.roiEnabled=false, debug.showOsd=false
• image mirror/flip disabled, rotation 0
• isolated RTP output to the test workstation on UDP port 15600; maxPayloadSize=1400, unconnected UDP, sidecar port 5602
• the paired 25 Mbps sidecar samples used continuous full-frame motion; the direct-AU repetitions used a fixed scene while CBR was already filling the requested bitrate

No recording path was enabled and no capture was written on the device.

[snokvist]

Heads-up: #114 (parity sync v0.65.2 → v0.67.1, 54 commits) is open and will conflict with this one.

This PR claims VERSION 0.66.0, which #114 already uses for the Star6E multi-slice release. After it lands the next free version is 0.67.2, and the next free contract version is 0.18.7 (#114 takes the contract to 0.18.6) — so VERSION, the HISTORY.md entry, and the contract bump will each need re-cutting.

Code overlap is real but small: #114 touches src/venc_api.c and src/venc_config.c (adding video0.sliceCount plumbing and the data.routes object), so the video0.maxIpProp field registration will land next to those rather than on top of them. maruko_controls.c/star6e_controls.c are untouched by #114.

Sorry for the churn — happy to help with the rebase if useful.

[snokvist]

#114 is merged, so this now shows as conflicting. Nine files overlap: VERSION, HISTORY.md, documentation/HTTP_API_CONTRACT.md, config/waybeam.default.json, include/venc_config.h, src/venc_config.c, src/venc_api.c, src/star6e_runtime.c, tests/test_venc_config.c.

Most of it is mechanical — the sync added video0.sliceCount plumbing along exactly the path a new video0.maxIpProp field takes, so your additions land next to the new ones rather than on top of them: a field in venc_config.h, a parse/default in venc_config.c, a config-file default, a capabilities/mutability entry in venc_api.c, and a test. Expect adjacent-line conflicts rather than semantic ones. maruko_controls.c / star6e_controls.c are untouched by the sync.

Bookkeeping to re-cut: VERSION → 0.67.2 (0.66.0 is now the Star6E multi-slice release), HISTORY.md entry to the top as ## [0.67.2], and the contract to 0.18.7 — four sites: the header near line 21, the example body, the divergence note, and the string in venc_api.c.

[vertexodessa]

Closing this.

Thanks for the two device reports, and for the isolation work behind them (catching waybeam_hub rewriting maxIBytes/maxPBytes mid-run, in particular). That was more careful testing than the PR deserved.

Your code blocker is real and I have not fixed it: the CBR rule runs only when the changed key is video0.max_ip_prop, so setting rcMode=vbr afterwards is accepted and persisted, and the loader then rejects that same file on restart. An API path that can leave the daemon unable to come back is not something to leave sitting in an open PR.

On the evidence, one note for whoever picks this up. u32MaxIPProp caps I-frame size as a proportion of P, so it can only bind when I is larger than P. In your Maruko runs IDRs were about 0.6x the P median, and in the Star6E runs key AUs were roughly a tenth of the non-key ones, so values of 2, 4 and 100 had no room to act — which I think explains the flat results rather than the parameter being inert. The regime where it should bite is the one that motivated the PR: 720p120 at ~11 Mbps, where IDRs ran 46-70 KB against much smaller P frames. I never ran that sweep, so this stays a hypothesis, not a finding.

I would rather withdraw the PR than leave an unverified claim and a known validation hole open, and I can't commit the bench time to finish it properly. The branch stays up if anyone wants it. Also worth flagging that #116 points at maxIBytes/maxPBytes under RC_PRIORITY_FRAMEBITS_FIRST as an IDR-free rate lever, which may be the more useful direction anyway.

One correction to my own PR text while I'm here: it called the byte caps inert, and your Maruko data disproves that — maxIBytes=2000 moved the IDR median from 12195 to 5866 bytes. They do not impose the requested ceiling, which is a weaker claim than the one I made.