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 9 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.