RTMP input

RTMP input properties for Script Engine. Receives a live video and audio stream over RTMP / RTMPS. Supports two modes: Client (pulls from an existing RTMP server — the same protocol used by most streaming services and many encoders for contribution feeds) and Server (binds to a local port and accepts an incoming push from an external RTMP sender). Includes auto-connect on load, automatic reconnect / re-listen on signal loss, configurable buffer length, and a delayed-start option for staggering multiple inputs. Optional NVIDIA NVDEC hardware decoding for H.264, HEVC, and AV1 (AV1 only on GPUs that support it — Ada Lovelace / RTX 40-series and newer); other codecs and GPUs fall back to software decoding.

Property	Type	Access	Description
`ShowAdvancedOptions`	`bool`	`get/set`	Show or hide the input's advanced settings in the editor UI. [default=false].
`Mode`	`RtmpMode`	`get/set`	Whether the input pulls from a remote RTMP server or listens locally for an incoming push. [default=Client]. `Client` connects out to an existing RTMP server and pulls the stream — use this for CDNs, restream services, and any source that exposes a public ingest URL. `Server` binds the URL's host/port locally and waits for an external RTMP sender (OBS, vMix, hardware encoder, FFmpeg push, etc.) to connect to it — useful for direct contribution feeds without a separate RTMP server in between. Note: `Server` mode has no protocol-level authentication and no `rtmps://` support. Any sender that can reach the port can publish. For per-stream auth, transport encryption, recording or multi-publisher fan-out, front Composer with nginx-rtmp / MediaMTX and pull from it in `Client` mode.
`RemoteServerAddress`	`string`	`get/set`	RTMP / RTMPS URL the input uses. In `Client` mode this is the URL of the existing RTMP source to pull from, e.g. `rtmp://host/app/streamkey`. Both `rtmp://` and `rtmps://` are supported in client mode. In `Server` mode this is the local `rtmp://` bind address the input listens on, e.g. `rtmp://0.0.0.0:1935/live` (use `0.0.0.0` to accept on all interfaces — narrow it to a specific NIC to restrict access). Server mode does not support `rtmps://`. Supports the `@@HostName()` macro, replaced with the machine's hostname at connect time (note the parentheses — bare `@@HOSTNAME` is not recognised here). Security: RTMP listen mode has no protocol-level authentication — any sender that can reach the port can publish. For real auth (per-stream keys, IP allow-lists, recording, transcoding) front Composer with a dedicated RTMP server such as nginx-rtmp or MediaMTX and pull from it in `Client` mode.
`AutoConnect`	`bool`	`get/set`	Whether the input starts automatically as soon as the project loads. [default=true]. When true, the input invokes its connect logic immediately on load (equivalent to running `ConnectCommand`) — connecting out in Client mode, starting to listen in Server mode. Disable to require an explicit start, useful when the input should only come live on operator action or via a script trigger.
`AutoReconnect`	`bool`	`get/set`	Whether the input automatically recovers after the stream ends. [default=true]. In Client mode: keeps retrying the source every `ReconnectInterval` until it comes back. In Server mode: re-binds and listens for a new sender after the current one disconnects. Useful for long-running productions where the stream may briefly drop. Disable for one-shot sessions that should not auto-recover.
`ReconnectInterval`	`int`	`get/set`	Delay between automatic reconnect or re-listen attempts, in milliseconds. [min=1000, max=10000, default=5000]. Only used when `AutoReconnect` is true. Shorter intervals recover faster from transient blips at the cost of more retry churn; longer intervals reduce the retry rate. Applies equally to Client-mode reconnects and Server-mode re-listens.
`RtmpBufferLength`	`RtmpBufferLength`	`get/set`	How much video and audio is buffered ahead of playback. [default=Medium]. Choose between `Short`, `Medium`, and `Long`. A longer buffer absorbs more network jitter and keeps playback steady on bumpy links, at the cost of more added latency. A shorter buffer is tighter on latency but more sensitive to network hiccups.
`DelayedInitialConnect`	`int`	`get/set`	Wait this long before the input first starts, in milliseconds. [min=0, max=10000, default=0]. In Client mode: staggers several inputs so they don't all hit the source server at the same instant when the project loads. In Server mode: delays opening the listen socket on load — useful if you also need to stagger port binding. Only affects the very first attempt — subsequent reconnects / re-listens use `ReconnectInterval`.
`UseNvdec`	`bool`	`get/set`	Whether to use NVIDIA's NVDEC GPU decoder instead of the libavcodec CPU decoder. [default=false]. NVDEC offloads H.264, HEVC, and AV1 decoding to dedicated silicon on the GPU, freeing CPU and typically sustaining higher resolutions and frame counts than software decoding. Applies only to incoming H.264, HEVC, and AV1 streams — other codecs always fall back to software decoding regardless of this setting. AV1 hardware decode requires a GPU that supports it (Ada Lovelace / RTX 40-series and newer); on older GPUs the connect will fail for AV1 streams while NVDEC is enabled. Requires a CUDA-capable NVIDIA GPU. The change takes effect on the next connect.
`ConnectionStatus`	`ConnectionStatus`	`get`	Current connection state of the input (read-only). Reflects whether the input is `Disconnected`, `Connecting`, `Connected`, `Reconnecting`, or in an error state. Driven indirectly by `ConnectCommand`, `DisconnectCommand`, and `AutoConnect` at load time. Read this from a script to decide whether the stream is live; the value also drives the running indicator and the enabled state of the connect buttons.
`ConnectCommand`	`Command`	`get`	Start the input — connect to the configured RTMP source (Client mode) or begin listening for an incoming push (Server mode).
`DisconnectCommand`	`Command`	`get`	Stop the input — disconnect from the source (Client mode) or stop listening / drop the current sender (Server mode).
`ComponentLog`	`ComponentLog`	`get`	Recent log lines from the input — connect, disconnect, reconnect, and error events (read-only). A short history of the most recent RTMP events, useful for diagnosing why a connection failed or why the input reconnected.
`StreamTime`	`TimeCode`	`get`	Time elapsed since the stream started, as a time code (read-only). Counts up from 0:00:00:00 when the connection becomes live and resets on each new connection. Useful for displaying the stream's running duration.
`Width`	`int`	`get`	Width of the video frames currently being received, in pixels (read-only).
`Height`	`int`	`get`	Height of the video frames currently being received, in pixels (read-only).
`NumAutoReconnectsPerformed`	`int`	`get`	Total number of automatic reconnects performed since the input was started (read-only). A rapidly growing counter is a strong signal that the network path or source is unstable. Resets only on full input dispose / re-create.
`RtmpBufferState`	`NetworkBufferingState`	`get`	Whether the input is currently filling its receive buffer (read-only). `Buffering` means the input is waiting for enough data before it starts producing frames; `Streaming` means it's running normally. Sustained buffering states indicate the network can't keep up with the configured `RtmpBufferLength`.
`NumFlushesPerformed`	`int`	`get`	Number of times the input has dropped its accumulated buffer to recover from drift (read-only). Buffer flushes happen when the input falls too far behind the source and needs to resync. A non-zero value usually indicates network jitter or a slow downstream consumer.
`SourceCamera`	`string`	`get`	The camera whose picture is in the frames arriving now, as the sender named it (read-only). Empty when the stream carries no identity. A Vindral Multicam Encoder stamps every coded frame with the camera that produced it, and this is that record joined to the frame it describes rather than to the newest one. What reads it inside the render pass is `CameraBackgroundSelector`, through `CudaBgraImage.SourceTag`; this property is for a person watching, and for a test.
`SourceCameraIndex`	`int`	`get`	The index the current frame's identity carries, or -1 when it carries none (read-only). The index alone is not an identity — the same index means a different camera the moment somebody reorders a rig — which is why `Source camera uid` travels beside it and is the field anything downstream should match on.
`SourceCameraUid`	`string`	`get`	The stable uid the current frame's identity carries (read-only).
`FrameTagFraming`	`string`	`get`	How this track's NAL units are framed, and whether that was read from the track or assumed (read-only, debug). Worth surfacing rather than only logging. Reading an access unit with the wrong framing or the wrong length-prefix width finds nothing rather than failing, so "assumed" beside an empty `Source camera` is the single most useful thing to know when a stream that should carry identities appears not to.
`FrameTagAccounting`	`string`	`get`	Frames that arrived carrying an identity, frames that did not, and tags that no frame ever claimed, for the current connection (read-only, debug). Three numbers because they answer different questions. The third is the one that separates "this stream carries no identities" from "the join is not working" — indistinguishable from `Source camera` alone, and calling for opposite responses.
`FrameTagCutKeyframes`	`string`	`get`	How the cuts in the incoming stream arrived: how many came in on an IDR, how many did not, and how many IDRs arrived that started no cut, for the current connection (read-only, debug). Read as `N on an IDR, M without, K IDR within shots`. A cut is the tag's generation changing between two received packets, and it is judged by the first packet of the new generation — read off the coded bytes, with the framing the track declared, not the packet's key flag. A sender that forces a keyframe on every cut should show nought without; one that does not will show most cuts without one, which is ordinary. The sender counts the same thing on its way out, so the two can be compared. The third count is IDRs that started no cut — the GOP's own keyframes inside a shot. It is what gives the first its meaning: a stream of nothing but IDRs puts every cut on one, so "every cut on an IDR" says the sender forced them only while this stays near the number of GOP boundaries the connection has crossed.
`ObserveFrameIdentity`	`bool`	`get/set`	Record each decoded frame's dominant colour alongside the camera identity attached to that same frame, readable from `FrameIdentitySamples`. Off by default. For proving that the picture changes on the same frame as the identity. Reading the camera property and a rendered image separately cannot answer it: those are two moments, and the question is about one frame. Costs a hue histogram over each frame while it is on, so leave it off in production unless that is the question being asked.
`FrameIdentitySamples`	`string`	`get`	The frames observed while `ObserveFrameIdentity` is on, oldest first, as `index:pts:camera:uid:hue:saturation:value` separated by `;` (read-only). Emptied whenever the diagnostic is switched either way. `index` counts every frame observed since that window began, so a reader can tell a complete run from one with holes in it — the distinction the diagnostic exists for, since a run missing its post-cut frames agrees with itself while still being wrong. `hue` is in degrees, `saturation` and `value` in percent; all three zero means no pixel had a stable hue, which is not the same as red. `uid` escapes `%`, `:` and `;` as `%25`, `%3A`, `%3B`. Reading does not consume the buffer — each record carries its own index and PTS, so a reader polling repeatedly de-duplicates on those instead.
`VideoBufferSizeFrames`	`int`	`get`	Number of video frames currently buffered ahead of playback (read-only, debug).
`VideoBufferSizeMs`	`int`	`get`	How much video is currently buffered ahead of playback, in milliseconds (read-only, debug). Includes pictures retained inside the video decoder as well as decoded pictures in the jitter queue; the frame count above describes the queue only. A persistently low or zero value while connected suggests the network can't keep up with real-time playback and may produce visible stalls.
`VideoDecoderBufferSizeMs`	`int`	`get`	How much of the video buffer is currently retained inside the decoder, in milliseconds (read-only, debug). This duration is included in `VideoBufferSizeMs`.
`AudioBufferSizeMs`	`int`	`get`	How much audio is currently buffered ahead of playback, in milliseconds (read-only, debug). A persistently low or zero value may produce audible drop-outs.
`PlaybackTime`	`AVRational64`	`get`	Timestamp of the most recently rendered frame, relative to stream start (read-only, debug).
`VideoTimeStamp`	`TimeStamp`	`get`	Timestamp of the most recently rendered video frame (read-only, debug).
`AudioTimeStamp`	`TimeStamp`	`get`	Timestamp of the most recently rendered audio frame (read-only, debug).
`VideoPacketTimeStamp`	`TimeSpan`	`get`	Timestamp of the most recently received video packet, before decoding (read-only, debug).
`AudioPacketTimeStamp`	`TimeSpan`	`get`	Timestamp of the most recently received audio packet, before decoding (read-only, debug).
`PacketTimeStampDiff`	`int`	`get`	Difference between the most recent video and audio packet timestamps (read-only, debug). A small steady value is normal; a value that grows or oscillates indicates A/V drift in the incoming stream.
`ExpectedVideoPtsDelta`	`double`	`get`	Expected time between consecutive video frames at the source's frame rate, in milliseconds (read-only, debug). Useful for diagnosing pacing problems — if actual deltas drift far from this expected value, the upstream encoder isn't producing frames at a steady rate.
`VideoTrackInfo`	`Dictionary<string, object>`	`get`	Metadata about the incoming video stream (read-only). A dictionary with technical details about the video — codec, resolution, frame rate, bit rate, and so on. Available once the source has been negotiated.
`AudioTrackInfo`	`Dictionary<string, object>`	`get`	Metadata about the incoming audio stream (read-only). A dictionary with technical details about the audio — codec, sample rate, channel count, bit rate, and so on. Available once the source has been negotiated.

Inherits from: AbstractInput, AbstractAudioProcessing, AbstractAudioMetering, NamedModel.

See also: RTMP input in Inputs — user-facing introduction, screenshots, and section summaries.