Levandor

TV Camwall "Blue Glare" — Frigate Birdseye NVENC Encoder Corruption

3 min read

The LG TV camwall’s two live panes showed blocky blue/purple/green chroma corruption (“blue glare”). Root cause was a wedged NVENC encoder session on the RTX 3080 corrupting Frigate’s birdseye restream — a different layer than the previously-fixed NVDEC decode corruption. Cleared with docker compose restart frigate. See also SESSION-HANDOVER, telep-mainframe.

Symptom

  • The camwall’s two live panes (labelled “Fix lencse” / “PTZ lencse”) showed blocky blue/purple/green chroma corruption.
  • The static “TOP KÉPEK” JPEG panes below them were clean.
  • Distinct from the earlier magenta/green wall corruption: that was NVDEC decode on the 3080 under GPU load, fixed with camwall-mpv.sh --hwdec=no. The camwall was already on software decode here — this corruption lived in the source stream, not the decode.

Root cause (confirmed, not guessed)

  • The camwall mpv plays rtsp://127.0.0.1:8554/birdseye. birdseye is Frigate’s own birdseye view (config: enabled, restream: true, mode: continuous, 3840x1080, quality 8), which Frigate composites from detect frames and re-encodes via ffmpeg.
  • Frigate encodes birdseye with -c:v h264_nvenc (hardware NVENC on the 3080) because the global ffmpeg.hwaccel_args: preset-nvidia is set. In Frigate 0.17 birdseye has no per-stream encoder override — it inherits the global hwaccel preset.
  • The NVENC encoder session had wedged and was emitting persistent chroma corruption even at GPU idle (~4% util). Same GPU video-engine fault family as the old NVDEC magenta issue, on the encode side this time.

Isolation method (reusable — this is the valuable part)

Diagnostic: pinpoint the corrupting stage

Grab a still at each layer of the pipeline. The one stage that transforms a clean input into a corrupt output is the culprit.

  1. TV framebuffer — sudo DISPLAY=:0 ffmpeg -f x11grab -video_size 3840x2160 -i :0.0 -frames:v 1 out.png (root can access :0; XAUTHORITY not needed).
  2. birdseye, independent of mpv — ffmpeg -rtsp_transport tcp -i rtsp://127.0.0.1:8554/birdseye -frames:v 1 out.jpg → corrupt ⇒ rules out mpv / TV decode.
  3. source cam streams — ffmpeg -rtsp_transport tcp -i rtsp://127.0.0.1:8554/cam1_main -frames:v 1 out.jpg (also cam2 etc.) → clean ⇒ rules out the cameras.
  4. live Frigate detect-path frame — curl http://127.0.0.1:5000/api/telep_cam1/latest.jpg → clean ⇒ rules out the NVDEC decode / scale_cuda path, proving the composited raw input to the encoder is clean.
  5. inspect the actual encoder cmd — docker exec frigate sh -c "ps aux | grep birdseye" → showed -c:v h264_nvenc. Only remaining transform ⇒ NVENC is the culprit.

Conclusion rule: source clean + latest.jpg clean + snapshots clean + birdseye corrupt = the h264_nvenc encode is the sole corrupting stage.

Fix applied

cd ~/nvr && docker compose restart frigate

This cleared the wedged NVENC session. birdseye and the whole TV wall verified clean afterward (re-grabbed the framebuffer). Still on NVENC — this was a restart-first fix, not a config change.

Durable fix if it recurs (not yet applied)

  • Blank / remove ffmpeg.hwaccel_args in ~/nvr/frigate/config.yml → birdseye encodes with libx264 on the 12900K. Per Frigate docs: an unrecognized value or empty string for hwaccel_args falls back to software encoding.
  • YOLO detection inference stays on the GPU — CUDA is a different engine than NVENC/NVDEC. Only ffmpeg decode/encode moves to CPU, a negligible cost on a 12900K.
  • This matches the rig’s established “software over the flaky GPU video engine” philosophy (same call as camwall --hwdec=no).
  • Caveat: hwaccel_args is global — blanking it also moves the two detect-substream decodes to CPU, because Frigate 0.17 exposes no birdseye-only encoder override.

Graph View

Backlinks