Historical evidence, superseded guidance. This is the earlier article, preserved with its original workload, measurements and revision links. Its defaults, branch/deployment labels and recommendations are not current. Read the current recipe.

Source limits by mode and frame rate

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. Admission lives in instance_profiles.py and is GPU/profile-specific. The T4 section below is historical T4 data, not L4 ceilings. L4 CUarray SDR admits 192 total sources including four browser keys (188 catalogue sources) at 25 and at 30 fps: 120 NVDEC, 32 raw and 40 browser inputs at 25 fps, 105 NVDEC, 47 raw and 40 browser at 30. The 30 fps limit was 170 until browser frames went back one per new frame. Current SDR output ceilings are 26 at 25/30 fps and 22 at 50/60 fps. No cap was raised for the latest node reductions.

How many unique 1080p sources the setup admits, by GPU profile, canvas mode and frame rate. Downstream-key pages count as sources. A request above a limit is scaled down to it, and switching back to a larger mode restores the total. Every limit comes from a measured instance profile; another machine needs its own.

Profile-specific limits

Current L4 CUarray profile

The 2026-10-09 recording observed 192 total inputs at 1080p25 SDR: 120 NVDEC decoders, 32 raw NV12 inputs, 36 browser scene sources and four browser keys. Setup shows 188 catalogue sources; the main interface includes the four keys in its total. The show has 256 scenes and 26 encoded outputs: Program, clean Program and 24 AUX buses. The 2026-10-12 recording is the same 192 inputs at 1080p30: 105 NVDEC decoders, 47 raw NV12 inputs, 36 browser scene sources and four keys, with 24 encoded outputs.

SDR rate	Total inputs, keys included	Output admission ceiling
25 fps	192	26
30 fps	192	26
50 fps	110	22
60 fps	99	22

These are nvidia_l4_cuarray admission limits, not a new qualification of every combination. Encoder preset, source type and HDR mode also constrain the allowed mix. The capacity reference lists the measured shows and the admission limits; the 30 fps show ran with 24 outputs. On 14 October, with the CPU changes on branches, the whole 30 fps stack also ran seven minutes confined to 8 of the host's 16 vCPUs without a missed deadline (Input, decode and wake-ups); no limit was changed for it. The UI recording is not a throughput benchmark.

Historical T4 totals, keys included

Frame rate	SDR · 8-bit 4:2:0	HDR · HLG 10-bit 4:2:0	HDR · HLG 10-bit 4:2:2
25 fps	110covered by 30 fps	90covered by 30 fps	81covered by 30 fps
30 fps	110measured baseline	90measured	810.74 share; 90 passed
50 fps	82measured; engine caps	73measured	66measured
60 fps	75measured	61measured	55measured

Every limit passed the cut-spam gate on the test host with 0 missed program deadlines, or is covered by a heavier show that did: 25 fps moves fewer frames per second than 30 fps on every engine, and HLG 4:2:2 at 30 fps passed at 90.

How the T4 profile was built, in short. Each limit is min(base × share, NVDEC + browser + raw caps), each term a value of the profile: a base of 110 at 25 and 30 fps and 75 at 60, a share of 1 for SDR, 0.82 for HLG 4:2:0 and 0.74 for HLG 4:2:2, and caps of about 1,100 decoded frames a second (at most 40 streams), 40 browser windows and 30 to 34 raw upload units at 25 and 30 fps. What ran out first: NVDEC at SDR 25 and 30 fps, host CPU at SDR 60 fps, CUDA compute at HDR 60 fps, and at preset p5 the T4's single NVENC with three 1080p60 HDR encodes (the profile uses p3). The per-type caps, the Balanced mix the setup page allocates at each limit and the runs behind them are in capacity.md. Conditions: T4 16 GiB, 16 vCPU, portrait 1080×1920 canvas from 1920×1080 sources, program with clean feed and two multiviews; each limit passed the cut-spam gate (cuts, fades and wipes at 4 per second) with 0 missed program deadlines.

The T4 figures predate every CPU change of 13 and 14 October; nothing on the T4 was measured again.

Where in the code

demos/mixer/instance_profiles.py: INSTANCE_PROFILES[InstanceType.TESLA_T4], the T4 limits; the L4 table is InstanceType.NVIDIA_L4_CUARRAY. webui.py --instance-type tesla_t4 selects it; Compose passes MIXER_INSTANCE_TYPE, default tesla_t4.
demos/mixer/setup_runtime.py: source_limit and source_counts apply the profile.
demos/mixer/setup.html: the same rules on the setup page, with the profile served in the setup status.
capacity.md: every measurement behind these numbers.