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.
HEVC (H.265) via NVENC — enable Use HEVC (H.265) via NVENC for better quality per bit than H.264. HEVC here always uses NVENC. It's also required if you embed timecode as video SEI, though the SMPTE ST 2038 timecode option works with any codec (see Timecode below).
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.

Timecode

The SRT Target can embed an SMPTE timecode in the outgoing stream so a downstream SRT Input — or any receiver that understands stream timecode — can read it back frame-accurately. Turn on Embed timecode, then choose how it travels with Timecode transport:

Video SEI (HEVC only) — the timecode rides inside the H.265 video as SMPTE S12M SEI. This requires Use HEVC (H.265) via NVENC, and the receiver has to decode the video to recover it.
SMPTE ST 2038 ancillary — the timecode travels as a separate ancillary-data stream alongside the video. It's codec-agnostic (works with H.264 as well as HEVC), it's the broadcast-standard carriage that third-party SRT decoders expect, and the receiver can read it back without software-decoding the video — so the SRT Input keeps hardware decoding on.

Timecode start sets where counting begins:

00:00:00:00 — the timecode starts at zero when the stream connects.
Time of day — the timecode is seeded from the wall-clock time of day at connect, then counts up frame by frame from there. It is not re-read from the clock on later frames.

How closely Time of day keeps up with the clock after that depends on the project frame rate, and the difference is large enough to matter on a long stream:

Project frame rate	How well the timecode tracks the clock
24, 25, 30, 50, 60	Exact, indefinitely.
29.97, 59.94	Correct to within about 70 ms. Drop-frame counting corrects in two-frame steps once a minute, so the reading sits slightly either side of true between corrections.
23.98	Does not track the clock. It runs about 0.1 % slow — roughly 43 seconds behind by midday and 86 seconds by the end of the day.

At 23.98 this is inherent to SMPTE timecode, not a setting you can change: timecode labels 24 frames for every second of 23.98 material, and there is no drop-frame scheme defined for that rate to make up the difference. Treat a Time of day timecode at 23.98 as a running counter rather than a clock reading — the target says as much in its log when the stream starts — and pick an integer project frame rate if downstream equipment needs the timecode to agree with the clock.

If Embed timecode is on with Video SEI selected but a non-HEVC codec is in use, the target logs a warning on connect and streams without timecode — switch Timecode transport to SMPTE ST 2038 or enable HEVC.

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.