SRT Target 16 channel audio

Introduction

The SRT Target streams the composed scene out over SRT (Secure Reliable Transport) — the broadcast-industry standard for delivering live video and audio over unmanaged IP networks. SRT layers packet-loss recovery, retransmission, and accurate timestamping on top of UDP, so a feed survives the kind of packet drop and jitter that would simply collapse an RTMP stream. It's the right pick for any link that crosses the public internet, a 4G / 5G uplink, or any other network you don't fully control.

The target supports both connection directions, multi-program audio for multi-language broadcasts, the same x264 / NVENC encoder paths as the RTMP Target, and a deep set of resilience and diagnostic controls. To consume an SRT stream produced by another Composer (or any third party), pair this target with the SRT Input.

Why SRT (and when to reach for it)

SRT is purpose-built for live contribution over networks Composer doesn't own. Pick it over RTMP when any of these apply:

The link crosses the public internet — bonded mobile modems, hotel WiFi, distant VPN tunnels. SRT's loss recovery keeps the feed up where RTMP would drop within seconds.
You need low, bounded latency. SRT lets you configure a fixed end-to-end latency budget (typically 120–500 ms); the receiver waits exactly that long for retransmits before delivering the frame, so the glass-to-glass delay stays predictable even when the network gets noisy.
Encryption is required. SRT supports AES-128 / AES-256 encryption out of the box via a passphrase URL parameter — no TLS terminator or VPN required.
You need multiple language programs in one stream. SRT carries up to four parallel AAC audio programs in a single MPEG-TS payload; downstream players pick the program by language tag.

For a stable studio-LAN delivery to a CDN ingest, RTMP is still simpler. For everything else outside the studio, SRT is the safer bet.

Common use cases

Studio-to-cloud contribution — push a composed programme feed from a production facility into a cloud encoder / decoder for further distribution.
Remote venue uplinks — a stand at a sports venue, conference, or outside-broadcast truck pushing back to base over a public network or 4G/5G bond.
Point-to-point links between facilities — two Composer instances (or a Composer and a hardware decoder) glued together over the open internet without provisioning dedicated lines.
Multi-language broadcasts — encode the source plus multiple commentary tracks as separate AAC programs so a single SRT stream covers every audience.
Resilient backup feeds — run the SRT Target in parallel with an RTMP Target so a network blip doesn't take the whole programme off air.

What you can control

Connection — caller, listener, and encryption

Server address — base SRT URL in srt://host:port form. The host is the remote endpoint when running in caller mode, or the local listening interface when running in listener mode.
Connection options — query string appended after ?. Common keys:
- mode=caller (Composer dials the receiver) or mode=listener (Composer waits for the receiver to dial in).
- latency=200000 (microseconds — typical 120–500 ms; raise on noisy links).
- pkt_size=1316 (default; aligns with the standard MPEG-TS-over-UDP MTU).
- passphrase=... (turns on AES encryption).
- streamid=... (stream identifier — many cloud SRT ingests require this).
Stream id — the same streamid value can be entered in its own field for ingest endpoints that prefer a separate parameter.
Connection string — read-only readout of the fully resolved SRT URL Composer is dialling, useful for verifying that base + options + stream id assembled into the URL the receiver expects.
Autostart — when enabled, the target connects (or starts listening) automatically when the project loads.

Video encoding

The SRT Target shares its video-encoder pipeline with the RTMP Target — two paths, mix-and-match across multiple instances:

x264 (CPU) — software H.264 with the standard set of speed/quality presets, tuning profiles, and thread-count control. zerolatency tune is the right default for SRT contribution.
NVENC (GPU) — hardware H.264 on dedicated NVIDIA encoder silicon. Doesn't compete with the GPU's general compute (so the rest of the pipeline keeps its budget) and substantially lowers CPU load. The full advanced NVENC parameter block is editable as a JSON object for power users.
Bitrate, GOP, B-frames, profile — every standard H.264 knob is exposed, with sensible SRT-friendly defaults (CBR, baseline profile, GOP at 2× framerate, no B-frames).
CBR rate-control with min/max multipliers — SRT receivers prefer constant bitrate; the multipliers let you cap how far above or below the target the encoder is allowed to wander when pure CBR is too restrictive.

Multi-program audio (up to four AAC programs)

This is where the SRT Target goes beyond RTMP. The target encodes up to four parallel AAC programs into a single SRT stream, each independently configured:

Encoder mode per program — Mono, Stereo, or Unused. Set the slot to Unused to disable that program entirely.
Channel mapping per program — pick which pair of the 8-channel scene audio bus feeds this program (channels 1/2, 3/4, 5/6, or 7/8). Lets you carry, e.g., the international feed on channels 1/2 and a per-language commentary mix on each remaining pair.
AAC bitrate per program — typical 128 kbit/s for stereo, 64 kbit/s for mono.
Language tag per program — ISO 639 language code (e.g. eng, spa, fra, deu) embedded in the MPEG-TS so a downstream player can offer language selection.

The result is a single SRT contribution stream that carries the programme video plus a multi-language audio bouquet, ready for separate downstream distribution.

Resilience and diagnostics

Auto-reconnect — configurable retry interval after a dropped connection. Keeps the target trying through transient outages without operator intervention.
Output queue size cap — bounds how many encoded packets are queued for the network. A persistently full queue indicates the uplink can't keep up with the encoder.
Frame-skipping policy — when on, lets Composer drop frames when the queue overflows rather than letting end-to-end latency grow unbounded.
Per-second bitrate logging — optional CSV trace of outgoing bitrate samples for after-the-fact analysis of network behaviour.
Live diagnostics — outgoing bitrate, video encode time (last/avg/max), network write time, video frame size statistics, output queue depth, reconnect count, error/warning counters with timestamps. All surfaced as readable properties; useful in both the property panel and over the HTTP API / WebSockets.
Low-bitrate warning — fires automatically if the actual outgoing bitrate falls below 10% of the configured target, catching a network collapse before the operator notices visually.

Listener-mode workflow

When mode=listener is set, Composer binds to the configured port and waits for an SRT receiver to dial in (the inverse of the more common caller-mode pattern). Useful when:

The receiver lives behind a firewall that doesn't allow inbound connections from Composer's network, but Composer's network does allow inbound connections.
A floating set of receivers needs to pull from a single Composer source on demand.
You want to validate a stream locally with ffplay or srt-live-transmit before hooking up the real receiver.