Tuning for maximum performance

The defaults Composer ships with target a development workstation. A production host running 24/7 with several scenes, multi-channel audio, and live encoders needs deliberate hardware and OS tuning.

Hardware

CPU. Composer is single-threaded for many critical paths (input demuxing, render-tick orchestration); single-core throughput matters more than core count. The recommended floor is 8 cores / 16 threads with a PassMark single-thread score of 3000+ and a multi-thread score of 19000+. Server-grade Intel Xeon parts hit both targets reliably.

Memory. Distribute capacity across all memory channels — 4 × 8 GB beats 2 × 16 GB on the same platform because the memory controller can stripe across more banks. DDR5 / DDR6 with single-rank modules is preferred. RAM bandwidth is consumed heavily by capture-card DMA and by Composer's render pipeline; under-populating channels caps your usable throughput regardless of clock speed.

GPU. Composer requires an NVIDIA GPU with CUDA 13.0 or newer. The minimum production part is the RTX A4000; the recommended parts are RTX 4000 / 4500 / 5000 / 6000 from the Ada or Blackwell generations. Higher-VRAM parts let you run more concurrent encoders, more AI operators, and higher-resolution scenes without spilling.

Display GPU. Don't drive the desktop from the same GPU that runs Composer. Use the CPU's integrated graphics for display, or fit a second low-power GPU (an AMD RX 6400 is a common choice) to drive monitors. Sharing one GPU between the Windows desktop compositor and Composer's render pipeline costs frame-budget and creates contention spikes.

Capture cards. Mount Decklink and similar capture cards on PCIe slots with at least x4 lanes — x1 and x2 slots throttle high-bitrate capture. Verify with nvidia-smi (for NVENC encoders) and the manufacturer's diagnostic tool that lanes haven't dropped during boot.

Encoder offloading. Use NVENC for RTMP / SRT / file recording targets and NVDEC for video file decoding. Both run on dedicated silicon and free the GPU's main shader cores for compositing.

BIOS and OS

  • Disable Hyper-V in BIOS / Windows Features. The Hyper-V hypervisor inserts a thin layer that can cost a few percent of GPU throughput, sometimes more under encoder load.
  • Lock GPU clocks. Either via Composer's settings or via nvidia-smi -lgc <min>,<max>. The default GPU power-state machine drops clocks during low-load periods, then takes 100s of milliseconds to ramp back up — long enough to drop a frame on a 60 fps target.
  • NVIDIA Control Panel → set Power management mode to Prefer maximum performance. (Composer's own clock-locking is preferred when available; this setting is the alternative path.)
  • Windows power plan: High Performance. Don't trust the default Balanced plan in production.
  • Disable screen savers and any sleep / hibernate timers — except on single-GPU Windows hosts, where enabling the screen saver is actually the right call: it forces Windows to stop compositing the desktop after inactivity, freeing up GPU cycles for Composer.
  • Don't run remote-access tools (TeamViewer, RDP, AnyDesk) during a live show. They periodically grab framebuffers, which costs measurable GPU and CPU time.

Project-level practices

  • Match media frame rate to project frame rate. A 60 fps project ingesting 30 fps clips spends extra CPU on frame doubling; pre-converting media costs less than doing it on every render tick.
  • Pre-rescale media files to your output resolution rather than relying on Composer to scale at runtime. The high-quality scaler costs frame budget you'd rather spend elsewhere.
  • Avoid CAV files unless you specifically need the alpha-channel animation they support — they decode at higher cost than other formats.
  • Use still images, not video clips, for static graphics. A PNG logo costs almost nothing; the same logo encoded as a one-second looping video costs a lot more.
  • Use LUT operators instead of stacking per-pixel colour-correction operators. A 3D LUT is a single GPU lookup; chained colour curves are several passes through the framebuffer.
  • Disable per-input audio processing on the Audio tab (Enable input audio processing) when none of your inputs need their per-input effects chain (trim, stereo remap, delay, low-cut, gate, EQ, compressor, limiter). Raw decoded audio still flows through the mixer; the per-input DSP and meters are simply skipped. Frees measurable CPU on projects with many audio-capable inputs.
  • Disable VU-meters on the Audio tab if you don't need them. If you do need them, turn Use RMS VU-meters off — peak meters are cheaper than RMS. Both toggles cut audio-metering UI render cost on hosts with many audio inputs.
  • Enable parallel audio processing on the Audio tab for projects with many audio-capable inputs — per-input effect chains then run across CPU cores instead of serially on a single thread.
  • Always prefer NVDEC for inputs and NVENC for targets when the component supports it. Hardware decode/encode runs on dedicated GPU silicon and leaves the shader cores free for compositing. For example, the Video File Input uses NVDEC for H.264 / HEVC / AV1 playback, and the RTMP Target uses NVENC for H.264 / HEVC encoding — both fall back to CPU codecs only when the GPU can't accelerate the chosen format.
  • Disable Live Preview when authoring in Composer Desktop on a production host. The Vindral-CDN preview runs an extra encoder pass on every frame and costs measurable CPU / GPU. Headless Composer Runtime hosts aren't affected — Live Preview is a Desktop-only feature.
  • Switch Composer Desktop to Performance Mode during live operation. It hides every UI element except the program preview and disables thumbnail rendering, freeing GPU cycles for the rendering pipeline. Desktop-only; Runtime hosts have no UI to begin with.
  • Disable Composer Desktop's video and audio preview when you don't need them on the operator station — both toggles live under the application menu. Video preview is a per-frame Desktop render; audio preview is the local-monitoring path. Disabling either frees CPU / GPU without affecting what the targets output. Desktop-only.
  • Enable Render Tuning for projects with many inputs that aren't all on-air at once. Composer skips decode / capture / processing for inputs no active scene currently uses, recomputed per frame with no warmup gap — often the single biggest free performance gain in a project with a deep input list. It pairs naturally with the Batch Processor: hide-by-batch packages keep their off-air layers' inputs paused, so a heavy graphics package costs nothing until you bring it on.

Linux for production

Linux runtime hosts are typically more efficient than Windows runtime hosts on identical hardware — fewer background services, no desktop compositor, lower overhead for the .NET 10 runtime. If your deployment doesn't need Composer Desktop on the production box, consider running the Linux runtime instead. The authoring workflow stays on Windows; the runtime host doesn't need a GUI at all.