wifibroadcast: write noiseLevel where majestic now reads it

[widgetii]

Problem

majestic is moving its per-channel VENC knobs off the global fpv section onto video0/video1, with no migration. .fpv.noiseLevel is one of them, and video_settings() in this script is the only place in this tree that sets any of them.

Losing it is not cosmetic. 0 is a value, not an absence: it turns 3DNR off, which is the point of setting it in an FPV profile. Once majestic reads the key from its new location the old one goes unread, the setting reads as "leave the encoder alone", the SigmaStar path returns early, and the ISP default noise reduction comes back on. Nothing in the log says the setting was dropped.

.fpv.enabled on the line above is unaffected — it stays where it is, being the switch for the SigmaStar pipeline rather than an encoder setting.

Hardware tested on

SSC30KQ (ipcinfo --chip-name → ssc33x, sensor imx335), running a majestic build that has the rename.

Evidence

Before — only the old key, exactly what the script writes today:

# cli -s .fpv.noiseLevel 0

# grep -n -A2 '^fpv:' /etc/majestic.yaml
136:fpv:
137-  roiRect: []
138-  noiseLevel: 0

# killall -1 majestic
# curl -s /api/v1/config.json   (video0)
  video0.noiseLevel: ABSENT  <-- setting lost, 3DNR left at ISP default

After — both keys, as this PR writes them:

# cli -s .fpv.noiseLevel 0
# cli -s .video0.noiseLevel 0

# grep -nE 'noiseLevel' /etc/majestic.yaml
38:  noiseLevel: 0
139:  noiseLevel: 0

# awk 'NR>=37 && NR<=39'        # 38 sits under video0
37:   roiRect: []
38:   noiseLevel: 0
39: video1:

# awk 'NR>=137 && NR<=139'      # 139 still under fpv, for older majestic
137: fpv:
138:   roiRect: []
139:   noiseLevel: 0

# killall -1 majestic
# curl -s /api/v1/config.json
  video0.noiseLevel: 0

# fpv path applied with no SDK errors
grep -cE 'Cannot set channel parameters|Cannot set reference|Cannot set intra|Cannot set venc roi'  ->  0

Why both keys

majestic.mk fetches majestic.$(FAMILY).$(VARIANT).master.tar.bz2 — unpinned master — so an image can be built against either side of the rename and there is no version to gate on. majestic ignores a key it does not know, so writing both is correct on both, and this can land before or after the majestic side in either order.

The .fpv line can be dropped once no supported build still reads it.

Checked

grep over this repo for all eight moved key names: this is the only occurrence. sh -n clean, and the file stays pure ASCII.

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

PR Summary by Qodo

Write Majestic noise level to video0 with legacy fallback

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Writes noise reduction to video0 for Majestic’s channel-scoped encoder settings.
• Retains the legacy fpv key for builds consuming unpinned Majestic versions.
• Preserves explicit 3DNR disablement and low-latency FPV behavior.

Diagram

graph TD
  A["FPV startup"] --> B["video_settings"] --> C["Write both keys"] --> D{"Config schema"}
  D --> E["Legacy fpv key"] --> G["Disable 3DNR"]
  D --> F["video0 key"] --> G

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin Majestic and use only video0

• ➕ Eliminates duplicate transitional configuration.
• ➕ Makes the expected Majestic schema deterministic.
• ➕ Allows immediate removal of the deprecated key.
• ➖ Requires changing artifact versioning and release practices.
• ➖ Could break supported images still using the legacy schema.
• ➖ Expands this focused compatibility fix into dependency management.

Recommendation: Keep the dual-write approach while Majestic is fetched from unpinned master. Unknown keys are safely ignored, so this provides compatibility across both schemas without runtime detection; remove the legacy key once all supported builds consume the channel-scoped setting.

Files changed (1) +8 / -0

Bug fix (1) +8 / -0

wifibroadcastWrite noiseLevel to both legacy and video0 paths +8/-0

Write noiseLevel to both legacy and video0 paths

• The FPV video setup now sets '.video0.noiseLevel' to zero while retaining '.fpv.noiseLevel' for older Majestic builds. An explanatory comment documents why zero must remain explicit and why both schema locations are temporarily required.

general/package/wifibroadcast-ng/files/wifibroadcast

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

Code Review by Qodo

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

1. Missing hardware streaming evidence 📘 Rule violation ☼ Reliability

Description

This behavior-changing PR changes the noise-reduction configuration but provides no affected board,
symptom, before/after output, or checked hardware-verification checkbox. The checklist requires
real-camera evidence for such changes.

Code

general/package/wifibroadcast-ng/files/wifibroadcast[R189-190]

	cli -s .fpv.noiseLevel 0
+	cli -s .video0.noiseLevel 0

Evidence

The changed lines alter the runtime noiseLevel settings, making this a behavior-changing PR. The
supplied PR description contains no hardware output or checked verification checkbox, which fails
the required evidence criteria.

Rule 1: Hardware evidence is present and honest
general/package/wifibroadcast-ng/files/wifibroadcast[189-190]

Agent prompt

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

## Issue description
The PR changes the runtime encoder noise-level configuration without documenting hardware verification.

## Issue Context
The compliance checklist requires the affected board, observed symptom, and before/after logs, dmesg, stream behavior, or measurements from a real camera, with any test or verification checkbox checked.

## Fix Focus Areas
- general/package/wifibroadcast-ng/files/wifibroadcast[189-190]

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

---

Context sources

Review mode: 🚀 Fast: This is a localized, single-file configuration write adding one channel-specific key; it has limited scope and no security, schema, concurrency, or broad cross-cutting risk.

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗