Picture processing and UI configuration

Pixop Prime separates what the GPU does to pixels from how the encoder packages the transport stream. Picture processing—restoration, scaling, inverse tone mapping (ITM), grain, and look controls—runs inside the Pixop LIVE filter and is tuned through the management UI or REST API. Encoded output resolution, chroma subsampling, bitrate, GOP, and HEVC VUI signalling (SDR vs HLG vs PQ) live in /etc/pixop-live/nvencc.args and require pixopctl restart when changed. See Configuration and Live output and encoding for the encoder plane; this page covers the picture plane only.

Version caveat: This guide may describe UI and REST capabilities not present on every AMI recipe. Confirm :8080 fields, Save behaviour, REST endpoints, and optional auth with pixop-version and live probing on your appliance—some images expose a smaller UI and API surface, and not every parameter hot-applies at runtime.

Two configuration planes

When Pixop LIVE restarts, it loads previously saved picture settings, if any. These settings take precedence over the corresponding appliance defaults. On a new deployment, no user customizations may have been saved yet.

Important: Adjusting picture processing does not automatically change encoder VUI metadata or HEVC HDR signalling. If the enhanced image looks correct on a reference display but downstream reports wrong HDR/SDR flags, align nvencc.args with the workflow—picture-side ITM and encoder-side signalling are related but not the same knob.

What the pipeline does (conceptual)

Incoming MPEG-TS is decoded, optionally passed through pre-Pixop YADIF when enabled in nvencc.args (--vpp-yadif mode=bob), then through --vpp-resize pixop-live. The Pixop stage can include:

Not every field in the OpenAPI document is exposed in every shipped remote-control UI build, and licenses can gate IO or feature sets. Consult the API reference for your installed appliance version—do not assume fields from a newer engineering doc exist on an older AMI.

Avoid pasting full saved parameter exports, license paths, or internal preset identifiers into public tickets. pixop-pack-config produces a sanitized tarball of /etc/pixop-live only—it does not include saved picture-processing settings. Keep private parameter backups in your change-control process; sanitized packs help support compare host config, not substitute picture rollback.

Runtime vs persisted parameters

The REST surface (default base http://<appliance>:8080/v1) distinguishes live filter state, runtime patches, and disk persistence:

Saving configuration: Picture adjustments made in the UI take effect on the running stream. Select Save to disk to retain approved changes across restarts. Before an appliance upgrade or rollback, back up your saved settings and follow Configuration change control to verify compatibility.

Some picture settings apply immediately, whereas startup-only settings take effect after a controlled Pixop restart. The UI and REST API expose only the controls supported by your installed build.

What the UI does

• On connect, loads current effective settings from the device (GET /v1/params) into the controls.
• Slider and checkbox changes send runtime updates (PUT /v1/params/runtime) so you can preview adjustments on air.
• Save to disk persists configured intent (POST /v1/params/save); Load from disk reads the saved snapshot (GET /v1/params/persisted) into the UI only—it does not replace live output until you apply or adjust controls.

If a startup field (e.g. restoration depth) is not on your build’s page, it stays at values from nvencc.args or your last saved on-disk settings until you change it through support workflows or PUT /v1/params/persisted with a validated full document.

Safe image review and commissioning

Broadcast commissioning should be signal-aware, not “turn on HDR and hope.”

1. Document the chain: source mastering (SDR gamma vs PQ vs HLG), whether the encoder VUI in nvencc.args matches the plant, and how the mastering monitor is calibrated (SDR reference vs HDR display with correct EOTF).
2. Use repeatable content: fixed test clips or known on-air scenes with skin tones, speculars, and shadows—not one-off sliders judged on a single frame.
3. Separate stages: judge pre-Pixop deinterlace (if any), DNN restoration, ITM, and PostFX in isolation where possible; change one control at a time in the secured UI.
4. Do not over-promise: SDR→HDR and ITM improve appearance when input assumptions and output signalling align; mismatched input metadata or wrong monitor path can look worse than conservative SDR passthrough.
5. Capture baseline before changes: UI screenshots if your process allows, a private backup of /var/lib/pixop-live/parameters/params.json, and optionally pixop-pack-config (sanitized /etc/pixop-live only) for host-side comparison.

Operator workflow (on-air discipline)

1. Open http://<appliance-ip>:8080 only from management networks (not the public internet).
2. Confirm ingest is healthy (pixopctl health, frame counters in monitoring and health signals).
3. Capture baseline (pixop-pack-config or documented screenshots).
4. Adjust one runtime control; watch program output and GPU/frame metrics; for SDR→HDR enable/disable, pause the pipeline first if the API requires it.
5. When the look is approved, click Save to disk; record the save in your change log (include a backup of /var/lib/pixop-live/parameters/params.json when your process requires it).
6. Avoid unplanned pixopctl restart during critical air time; restarts are for nvencc.args and image updates, not routine grain tweaks.
7. Rollback: restore a known-good /var/lib/pixop-live/parameters/params.json from backup; ensure ownership allows the container user (host checks use UID 1001 write probes under /var/lib/pixop-live/parameters). Restart Pixop LIVE if startup fields changed or the process must reload file state. Do not hand-edit JSON on production without a maintenance window and a verified backup.

For encoder bitrate, resolution, or HLG/PQ signalling changes, follow Configuration change control and pixopctl restart—outside this page’s runtime PUT path.

GUI vs REST and security

HTTP on port 8080 is plaintext unless you terminate TLS on a customer-operated reverse proxy. Restrict the port to trusted management CIDRs. Optional REST Basic and/or Bearer authentication may be configured in NVEnc restapi.yaml; when enabled, anonymous scrapes of /v1/metrics or params may fail—supply credentials to monitors. Do not document or assume a universal default login; configure auth per your security policy.

Troubleshooting picture issues

If filters look wrong but metadata is “correct,” remember encoder VUI is independent of ITM—fix signalling in live output and encoding.

Related documentation

• Configuration — file layout and nvencc.args vs params.json
• Configuration change control — promotion, backups, change windows
• Monitoring and health signals — metrics and preflight probes
• Supported GPUs FAQ — hardware headroom and chroma limits
• pixopctl — restart and health without transport tear-down