RTMP Target
Introduction
The RTMP Target is a generic RTMP/RTMPS encoder and sender that takes the composited scene and pushes it as a live video and audio stream to any RTMP-compatible ingest — whether that's the Vindral Cloud, a CDN, a third-party live platform (YouTube, Facebook, Twitch, etc.), or your own RTMP origin.
Overview
The component is built on top of the libraries from the FFmpeg application family for the RTMP transport, the H.264 / AV1 / AAC encoders, and the muxer, plus NVIDIA's NVENC library for GPU-accelerated video encoding.
Two video-encoding paths are available:
- X264 (CPU encoding) — the well-known software H.264 encoder. Highly tunable, available on every machine, but uses CPU cycles that scale with resolution and frame rate.
- NVENC (GPU encoding) — H.264 encoding on dedicated NVIDIA encoder silicon. NVENC offloads work from the CPU and runs on a separate, dedicated chipset that does not steal cycles from the GPU's general compute units, so it is an excellent way to free up resources for the rest of the pipeline.
Audio is always encoded with AAC at a configurable bitrate.
Using NVENC requires an NVENC-compatible NVIDIA GPU such as the RTX A4000, P2200, P4000, or T40. Most NVIDIA GPUs support NVENC, but the capabilities differ between models. The official compatibility matrix is a useful reference when choosing or validating a card:
https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new
When running multiple instances of the RTMP Target in the same project, you can freely mix X264 (CPU) and NVENC (GPU) encoders across instances — for example, NVENC for the main programme output and X264 for a low-resolution preview feed.
Common use cases
- Live broadcasting to platforms such as Vindral, YouTube Live, Facebook Live, Twitch, and other RTMP/RTMPS ingest endpoints.
- Contribution feeds from a production location into a remote broadcast facility or cloud workflow.
- Multi-bitrate / multi-destination delivery — running several RTMP Targets in parallel, each configured for a different bitrate, codec, or destination.
- Backup and failover streaming — pushing the same content to a primary and backup ingest URL, with automatic failover.
- Encoder offloading — using NVENC to keep CPU load down on busy production machines, freeing CPU for input decoding, mixing, and other components.
- Stream monitoring and diagnostics — leveraging the built-in bitrate, queue, and reconnect statistics to troubleshoot live deliveries.
RTMP Target - Settings
| Property | Description |
|---|---|
Show advanced options |
Show or hide the target's advanced settings in the editor UI. [default=false]. |
Autostart when application starts |
Whether the RTMP stream connects automatically as soon as the component is initialised. [default=false]. When true, the target invokes its connect logic immediately on load (equivalent to running StartCommand) and will use the auto-reconnect logic on failures. Make sure RtmpServerAddress (and ideally RtmpBackupServerAddress) are valid, the encoder settings are correct, and the target license seat is available — otherwise the stream will fail and keep retrying until disconnected manually. |
Addresses
Addresses — where the stream is sent and where it can be played.
| Property | Description |
|---|---|
Rtmp server address |
Primary RTMP/RTMPS ingest URL (e.g. rtmp://host/app/streamkey). The address Composer connects to first. Both rtmp:// and rtmps:// are supported. The special token @@randomid in the URL is substituted with a per-instance random GUID stream key on connect, useful for unique stream identifiers per session. The value is trimmed on set, and changing it updates the enabled state of the connect/disconnect commands. |
Backup address |
(advanced) Optional backup RTMP/RTMPS ingest URL used if the primary fails. When set and the primary connection drops or repeatedly fails, the target falls over to this URL on the next reconnect attempt. The same @@randomid substitution applies (with an independent random GUID from the primary). Leave empty to disable backup. The value is trimmed on set. |
Player URL |
(advanced) Optional public playback URL for the stream produced by this target. Pure metadata — Composer never connects to it. Used in the UI as a clickable link so an operator can preview the live stream from inside Composer without copying the URL elsewhere. Leave empty if you don't have a player endpoint. |
Encoder configuration
Encoder configuration — video codec, bitrate, profile, and rate-control settings.
| Property | Description |
|---|---|
Video resolution |
Output video resolution sent to the RTMP server. [default=Unchanged]. Unchanged passes the scene's native resolution through to the encoder; the other values scale the frame to a standard preset (e.g. 1920x1080, 1280x720) before encoding. Pick a preset when the destination expects a specific resolution or to bring the bitrate-per-pixel budget into a sensible range; pick Unchanged to avoid a scaling pass on the GPU. |
Video bit rate |
Target video bitrate the encoder aims for. [default=3 Mbit/s]. The nominal bitrate the encoder is configured with — the actual outgoing bitrate is also shaped by MaxVideoRateMultiplier, MinVideoRateMultiplier, and BufferSizeMultiplier (when CBR is enabled). Pick to match the destination's expectations and the chosen ImageOutputResolution: ~2–4 Mbit/s for 720p, ~4–6 Mbit/s for 1080p, ~10–20 Mbit/s for 4K. |
Audio bit rate |
(advanced) AAC audio bitrate for the encoded stream. [default=128 kbit/s]. Selects the constant bitrate used by the AAC encoder. Higher values give better audio fidelity at the cost of more bandwidth — 128 kbit/s is a safe default for stereo speech and most music; 192–256 kbit/s is appropriate for music-heavy content. Lower values (64/96 kbit/s) save bandwidth at the cost of audible artefacts, especially on transients. |
H264 B frame distance |
(advanced) Maximum number of B-frames between reference frames in the H.264 GOP. [default=Zero]. B-frames improve compression efficiency but introduce decoder/display delay and can confuse strict low-latency consumers. Keep at Zero for live/low-latency RTMP delivery (the default). Increase only when your downstream decoder explicitly supports B-frames and the slight efficiency gain outweighs the added latency. Ignored when UseNvenc is true and the NVENC preset disables B-frames. |
H264 Gop size |
(advanced) GOP (Group of Pictures) length, expressed as a multiple of the source frame rate. [default=GopFps2]. Sets the keyframe (I-frame) interval. GopFps1 produces a keyframe every second (= one frame rate's worth of frames), GopFps2 every two seconds, etc. Shorter GOPs improve seek/error recovery on the player side and are required by some HLS/DASH packagers; longer GOPs improve compression efficiency. For live streams a 2-second GOP is the standard compromise. |
H264 profile |
(advanced) H.264 codec profile to encode with. [default=baseline]. Determines which encoder tools are used and which decoders the stream is compatible with. baseline is the most widely supported (older mobile devices, many embedded decoders) but the least efficient; main adds CABAC and B-frames; high adds 8x8 transforms and quantiser matrices for the best quality at a given bitrate. Pick baseline for the broadest playback compatibility; pick high when you control the player and want the best quality per bit. Only applies to the libx264 path — NVENC has its own profile selection through NvencAdvancedOptions. |
Audio/Video synchronization |
(advanced) How aggressively the target reconnects when audio and video PTS drift apart. Selects the threshold at which an excessive video-vs-audio PTS difference forces an automatic reconnect, in an attempt to re-sync the two streams. Tighter thresholds catch sync drift earlier but trigger more reconnects on jittery networks; looser thresholds tolerate more drift before acting. Disable entirely when reconnects are more disruptive than minor sync drift in your delivery pipeline. Changing this updates the enabled state of the connect commands. |
Use CBR configuration |
(advanced) Whether to enforce constant-bitrate (CBR) rate control via the multipliers below. [default=true]. When true, the encoder is configured so that the target bitrate is held flat using MaxVideoRateMultiplier, MinVideoRateMultiplier, and BufferSizeMultiplier to bound rate excursions and the VBV buffer. CBR is the safest choice for live RTMP delivery — most ingest servers and CDNs assume a near-flat bitrate. Disable to let the encoder run in default (effectively VBR) mode when bandwidth is plentiful and quality matters more than predictability. Changing this updates the enabled state of the connect commands. |
Max video rate (multiplier) |
(advanced) Upper bitrate cap as a multiplier of the configured video bitrate. [default=1.0]. Only used when UseAdvanceCbrConfiguration is true. The CBR maximum bitrate is set to OutputVideoBitrate × MaxVideoRateMultiplier. 1.0 holds a strict CBR ceiling; values slightly above 1.0 (e.g. 1.1) allow brief overshoots on busy frames; very high values effectively behave like VBR. Keep at or near 1.0 for live RTMP unless your CDN explicitly tolerates excursions. |
Min video rate (multiplier) |
(advanced) Lower bitrate floor as a multiplier of the configured video bitrate. [default=1.0]. Only used when UseAdvanceCbrConfiguration is true. The CBR minimum bitrate is set to OutputVideoBitrate × MinVideoRateMultiplier. 1.0 holds a strict CBR floor (the encoder is not allowed to drop below the target on quiet frames); lower values let the encoder coast when content is easy to compress. Keep at or near 1.0 for delivery pipelines that assume a flat outgoing bitrate. |
Buffer size (multiplier) |
(advanced) VBV buffer size as a multiplier of the configured video bitrate. [default=1.0]. Only used when UseAdvanceCbrConfiguration is true. The encoder's VBV (Video Buffering Verifier) buffer is set to OutputVideoBitrate × BufferSizeMultiplier bits. Smaller buffers (≤1.0) hold the bitrate more strictly to the target and reduce latency, but can hurt quality on hard-to-encode frames. Larger buffers (≥1.5) absorb spikes for higher-quality output at the cost of more end-to-end delay. 1.0 (a one-second VBV) is a balanced live default. |
Quality/Speed control |
(advanced) libx264 preset trading encoding speed for compression efficiency. [default=veryfast]. Maps to the standard x264 --preset knob: ultrafast/superfast/veryfast/faster/fast/ medium/slow/… Faster presets use less CPU per frame and are required to keep up with live frame rates, at the cost of larger files / lower quality at the same bitrate. veryfast is a balanced live default; pick something slower only if your CPU has budget left and you need the extra compression efficiency. Only applies when UseNvenc is false. |
Tune |
(advanced) libx264 tuning preset for the content type / latency profile. [default=zerolatency]. Maps to the standard x264 --tune flag. zerolatency disables look-ahead and B-frames for lowest latency (the right choice for live RTMP). film, animation, grain, stillimage bias the encoder for that kind of content. psnr/ssim optimise for the named objective metric. Only applies when UseNvenc is false. Stick with zerolatency for live unless you know your delivery pipeline can absorb the extra delay. |
H264 threads |
(advanced) Number of CPU threads dedicated to libx264 encoding. [default=Two]. Higher thread counts speed up encoding but introduce slice boundaries that slightly hurt compression efficiency and can add latency. Two threads is a good balance for one HD stream; scale up only if a single target falls behind on frame rate, or if you're running multiple RTMP targets and need to bound total CPU. Only applies when UseNvenc is false (NVENC runs on the GPU and ignores this). |
Use NVENC as video encoder |
(advanced) Whether to use NVIDIA's NVENC GPU encoder instead of the libx264 CPU encoder. [default=true]. NVENC offloads H.264 encoding to dedicated silicon on the GPU, freeing CPU and typically hitting frame rate at high resolutions with low latency. Quality at low bitrates is generally slightly behind tuned libx264 but the gap closes at typical streaming bitrates. When true, the H264EncodingQualitySpeed, H264Tune, H264Profile, and H264EncodingThreads knobs are ignored — NVENC is configured via NvencAdvancedOptions. Requires a CUDA-capable NVIDIA GPU. Changing this updates the enabled state of the connect commands. |
Use AV1 as video codec |
(advanced) Use AV1 instead of H.264 as the video codec. [default=false]. AV1 offers significantly better compression efficiency than H.264 (typically 30–50% bitrate reduction at the same perceptual quality) but requires both ingest and player to support AV1 in RTMP — many traditional CDNs and players still do not. Only enable when you know the receiving end accepts AV1 over RTMP. When false, the H.264 settings above apply. Changing this updates the enabled state of the connect commands. |
Advanced options (json) |
(advanced) NVENC encoder options as a JSON object of FFmpeg -x264opts-style key/value pairs. Only used when UseNvenc is true. Each key/value is forwarded to NVENC as a private encoder option. The default covers low-latency live streaming (zerolatency=1, rc=cbr, preset=p4, rc-lookahead=0, surfaces=1, delay=0, gpu=any, no-scenecut=1, strict_gop=0). Adjust to override individual options — for example, raise preset to p5/p6/p7 for better quality at higher CPU/GPU cost, or change rc to vbr for variable bitrate. Invalid JSON is ignored. Changing this updates the enabled state of the connect commands. |
Metadata injection
Metadata injection — optional onFI metadata embedded in the RTMP stream.
| Property | Description |
|---|---|
Send OnFI metadata on interval |
(advanced) Whether to inject onFI (Frame Info) metadata into the RTMP stream periodically. [default=false]. onFI is an AMF script-data tag that lets the target embed timing/identification information inline with the video stream — useful for downstream consumers that need to reconstruct frame-accurate timing or correlate the live stream with an external system. When enabled, metadata is sent every MetaDataInterval frames. Leave off if your downstream pipeline does not consume onFI; some RTMP servers will simply ignore it, but a few may reject unknown tags. |
Send interval (every n video frames) |
(advanced) How often (in video frames) onFI metadata is injected. [default=EveryTwentyFrames]. Only used when SendOnFiOnInterval is true. Lower values give downstream consumers more frequent timing/identification samples at the cost of slightly more bandwidth and a small amount of CPU per insertion; higher values minimise overhead but make the metadata arrive less often. Match this to the granularity your downstream pipeline expects. |
Connection
Connection — current connection state and the connect/reconnect/disconnect commands.
| Property | Description |
|---|---|
ConnectionStatus |
Current connection state of the target (read-only). Reflects the live RTMP connection: typically Disconnected, Connecting, Connected, Reconnecting, or an error variant. Set internally as the connect/reconnect/disconnect threads progress. Scripts should read this to decide whether the stream is live before emitting follow-up commands; a state change also triggers OnConnectionStateChanged and updates the enabled state of StartCommand/StopCommand/ReconnectCommand. |
StopCommand |
Connects to the RTMP server and begins streaming. Invokable command. Spins up the configured video encoder (libx264 or NVENC) and audio encoder (AAC), opens the RTMP/RTMPS connection to RtmpServerAddress (or the backup if configured and primary fails), and starts pushing encoded frames. No-op if the target is already connecting or connected. Failures auto-retry per ReconnectInterval until disconnected. |
Disconnect |
Stops the RTMP stream and tears down the encoder. Invokable command. Cancels any in-flight reconnect attempts, closes the RTMP/RTMPS connection, drains the send queue, and disposes the active video/audio encoder. Also clears the running server address. After this returns, the target is fully idle until StartCommand is invoked again. |
Reconnect |
Forces a reconnect cycle on the RTMP stream. Invokable command. Closes the current connection (if any) and immediately starts a new connect attempt, bypassing the normal ReconnectInterval delay. Useful after a server-side configuration change, when failing over between primary and backup, or to recover from a stalled session that has not yet been detected as disconnected. Increments NumAutoReconnectsperformed. |
Rtmp message |
Most recent status/info/warning/error message emitted by the target (read-only). The target writes here when its state changes, when a reconnect happens, when the encoder flags a problem, or when bandwidth/queue thresholds trip a warning. The message carries a FormattedMessageType (Info/Warning/Error). Setting this also updates MinilogTime. Read from a script to mirror target health into a dashboard or trigger downstream alerts. |
Rtmp message time |
(advanced) Timestamp of the most recent Minilog message (read-only). Updated automatically every time Minilog is set, with the local system time at the moment of update. Pair with Minilog when surfacing the latest target event to the operator or to detect stale status (e.g. "no message in N minutes" suggests the target is quiet, not that something is wrong). |
Options
Options — reconnect behaviour, send-queue limits, and bitrate warnings.
| Property | Description |
|---|---|
Warn on low average bit rate (<10%) |
(advanced) Whether to emit a warning when the outgoing bitrate drops far below the configured target. [default=true]. When true, the target raises a Minilog warning if the rolling average outgoing bitrate falls below ~10% of the configured OutputVideoBitrate — a strong signal that the upstream encoder is starved or the network is dropping frames silently. Disable on intermittent links where transient dips are expected and you don't want them flagged. |
Reconnect Interval |
(advanced) Delay between automatic reconnect attempts after a connection failure. [default=FiveSeconds]. Sets the back-off used by the auto-reconnect logic when the RTMP connection drops or refuses to come up. Shorter intervals recover faster from transient blips but generate more load on the ingest server during sustained outages; longer intervals reduce server pressure but extend downtime. The user-invoked ReconnectCommand bypasses this interval and attempts immediately. |
Max output queue size (packets) |
(advanced) Maximum number of encoded packets buffered for the network sender. [min=150, max=500, default=150]. The send queue smooths out short bursts where the encoder runs ahead of the network. When the queue exceeds MaxOutputQueueSize − 50, a "queue size" warning is raised; if it stays full the connection is treated as too slow and either reconnects or, if OutputBufferAllowFrameSkipping is true, drops frames. Larger queues absorb more jitter at the cost of latency; smaller queues keep latency tight but trip warnings sooner on flaky links. Values outside 150–500 are clamped on set. |
Allow frame skipping |
(advanced) Whether the target may drop video frames when the send queue fills up. [default=false]. When false (default), the target reconnects if the send queue stays at capacity — frames are never silently dropped. When true, frames are skipped instead so the stream keeps moving even on a slow uplink, at the cost of visible glitches/freezes on the player. Enable when stream continuity is more important than visual smoothness; leave off when you'd rather the stream reset than show artefacts. |
Log
Log — recent info, warning and error messages emitted by the target.
| Property | Description |
|---|---|
ComponentLog |
Per-component log buffer — recent info / warning / error messages emitted by the target (connection state changes, errors, reconnects). Mirrors the relevant Logger entries so users can read recent diagnostics without opening the application log file. |
Performance and properties
Performance and properties — runtime stats from the live stream.
| Property | Description |
|---|---|
Running server address |
RTMP server address the target is currently connected to (read-only). Reflects the URL in active use, including any @@randomid substitution. Useful in scripts to distinguish whether the primary or backup endpoint is in use after a failover, since both RtmpServerAddress and RtmpBackupServerAddress are user configuration but only one is live at any moment. Empty when disconnected. |
Uptime since start |
Time elapsed since the current connection became active, formatted as a string (read-only). Resets on every successful (re)connect, not on StartCommand. Use UpTimeSinceStartTimeSpan (internal) for arithmetic; this property is the human-readable presentation surfaced in the UI and to scripts. Empty / 0 while disconnected. |
Outgoing bitrate |
Current outgoing bitrate as a formatted string (e.g. "3.0 Mbit/s"), read-only. Sampled per second from the actual bytes pushed to the RTMP socket — i.e. what the network sees, not the encoder's nominal target. Use OutgoingBitRateMbitPerSecond (internal) for numeric comparisons in scripts; this property is the display string. A persistent gap between this value and OutputVideoBitrate + AacBitRate indicates a starved encoder or a slow uplink, and (when enabled) trips the low-bitrate warning. |
Number of reconnects |
Total number of automatic reconnect attempts performed since the target started (read-only). Counts every reconnect cycle the target has run, whether triggered by a dropped connection, a high audio/video PTS divergence (AutoReconnectOnHighPtsDiff), a full send queue, or an explicit ReconnectCommand. A rapidly growing counter is a strong signal that the network path or ingest server is unstable. Resets only on full target dispose / re-create. |
Current rtmp endpoint |
Resolved RTMP endpoint (host[:port]/app) the target last connected to (read-only). The URL after parsing — typically just the host/port/app portion of RunningServerAddress, without the stream key. Useful for displaying or logging a sanitised endpoint without leaking the stream key into logs or operator-visible UI. |
Error counter |
Total number of errors raised by the target since startup (read-only). Incremented every time the target logs an error-level event (connect failure, encoder failure, fatal write error, etc.). Setting this also stamps LastErrorDateTime. Pair with LastErrorDateTime to detect "errors are happening right now" vs. "errors happened a while ago and have stopped." The textual error itself is in the internal LastErrorMessage. |
Last Error DateTime |
Local timestamp of the most recent error (read-only). Updated automatically every time ErrorCount is incremented. DateTime.MinValue (or default) until the first error occurs. Use the freshness of this timestamp to decide whether the most recent issue is still relevant or has aged out. |
Warning counter |
Total number of warnings raised by the target since startup (read-only). Incremented every time the target logs a warning-level event (low average bitrate, send queue near capacity, audio/video PTS divergence, etc.). Setting this also stamps LastWarningDateTime. Warnings are non-fatal — the stream keeps running — but a steadily rising counter indicates the target is operating outside its comfort zone. The textual warning itself is in the internal LastWarningMessage. |
Last Warning DateTime |
Local timestamp of the most recent warning (read-only). Updated automatically every time WarningCount is incremented. DateTime.MinValue (or default) until the first warning occurs. Compare against DateTime.Now to gate alerting logic — e.g. only escalate if the most recent warning is within the last minute. |
Inherits from: AbstractTarget.
See also: RTMP Target in Script Engine Objects.
Related components
- RTMP input — the receiver-side counterpart. Use it when Composer consumes an RTMP stream rather than producing one.
- RTMP Target (Multi scaler) — variant that re-scales the same scene to several output resolutions and pushes them as parallel ladder rungs in a single component; the standard fit for ABR ingest.
- SRT Target — pick this for sending out over unmanaged networks where RTMP's loss model is too fragile; SRT layers retransmission, FEC and bounded latency on top of UDP.
- SRT input — the SRT receiver-side for incoming contribution over unmanaged networks.
- MoQ Target — pick this for publishing a Composer scene into the Vindral CDN over MoQ rather than to an RTMP ingest; QUIC-based, sub-second latency.
- MoQ input — the MoQ receiver-side for ingesting from a Vindral CDN channel.
- NDI Target — for publishing a Composer scene to other NDI-aware tools on the same studio LAN; mDNS auto-discovery, very low latency, not internet-traversable.
- NDI input — the NDI receiver-side for studio-LAN contribution.