Historical recipe — not current setup guidance. Measurements and implementation links below belong to their original workload and revision. Deployment labels and defaults may be obsolete. Use the reviewed performance recipes; browse historical evidence.

AVPlumber · Mixer optimization cookbook

One reference frame for monitor encoders

Implementation links are pinned to develop at c20464a5 (2026-10-09). The mixer has changed since; this page was checked against develop at 8fa15c92 on 2026-10-13. Measurements retain their original workload and scope. Watch the current 192-input L4 demo.

Current scope. AUX rendition defaults use dpb_size: 1, including additional buses. The two-monitor memory example below is historical; it is not the saving for every possible output count. Program and clean-feed settings are separate.

The monitor encoders, one per AUX bus, keep one reference frame instead of the several NVENC reserves by default, because without B-frames each frame is predicted from the previous one. Measured on an NVIDIA L4 on 2026-10-14: an H.264 1080p p3 encoder with the AUX settings holds about 48 MiB with NVENC's own choice and about 34 MiB with dpb_size 1.

The idea

An H.264 frame is coded as the difference from earlier frames. The encoder keeps those earlier frames, reconstructed, in its decoded picture buffer (DPB). With dpb_size 0 (automatic), NVENC reserves room for several of them. The mixer's streams use no B-frames and no lookahead (ultra-low-latency tune), so each frame references the previous one. The other slots sit in VRAM.

At a glance

• WhatThe FFmpeg nvenc option dpb_size: 1 on AUX encoders, including Program preview and Multiviewer. It comes from the rendition field dpb_size, which aux buses default to 1. Program and clean encoders are untouched.
• WhyWith no B-frames and no lookahead, each frame references the previous one. The extra DPB slots NVENC reserves under dpb_size 0 hold VRAM for references the monitors do not need.
• Latency

  Program output: none (0 frames, 0 ms). Its encoder is not changed.

  Monitors and command-to-screen: none. The DPB size changes no encode order and adds no buffering.

• Side effectsThe encoder has less choice when content returns after an occlusion, such as a background reappearing after something passes in front of it. At the same bitrate a monitor picture can be marginally softer in such moments. Viewers' streams are not affected.
• Cost0 nodes, 0 queues, 0 threads, no extra GPU or CPU work. About 20 lines (counted in the code): one encoder option, one rendition field with a 0–16 range check, the aux default. VRAM: about 14 MiB per 1080p H.264 AUX encoder (measured on the L4, 2026-10-14); for the 22 AUX buses of the 192-source show about 0.3 GB, if its two HEVC monitors save the same (not measured). The program and clean-feed encoders keep NVENC's choice.
• RiskLow. It touches only the monitors, whose pictures operators watch but viewers never receive. The worst case is a slightly softer monitor frame after an occlusion.
• Switch it offSet "dpb_size": 0 on the monitor's rendition in aux_buses. NVENC then chooses again.

Where in the code

• pyplumber/mixer/janus.py: dpb_options turns the field into the nvenc option, or nothing for 0; source adds it to the Janus encoder options.
• pyplumber/mixer/aux.py: aux renditions default to dpb_size 1; source passes it to the monitor encoder.
• pyplumber/mixer/config.py: the rendition field (default 0); source check the 0–16 range (source).
• pyplumber/mixer/application.py: program Janus outputs pass the field through (0 unless set); source does the same for file outputs.
• Tests: tests/mixer/test_backend.py (monitor 1, program unset), tests/mixer/test_aux.py, tests/mixer/test_graph.py.
• Docs: config.md · renditions (the dpb_size row).

Source links identify the reviewed code, independently of deployment state.