The Outputs tab is where you define how a control room delivers live content out of the platform. Each output combines the content you want to send, the transport method you want to use, and the connection settings required by the destination. This is where you configure SRT and RTMP deliveries for primary streams, backup paths, partner feeds, language variants, clean outputs, and test destinations.
Video walkthrough
This walkthrough covers the Outputs tab, the supported protocols and modes, and how output settings are reviewed before an event.
Video link: https://vimeo.com/1221481774
What outputs are used for
An output represents one live delivery path from the control room to an external receiver, platform, or downstream workflow. You can create multiple outputs in the same control room when you need to send the same production to more than one destination, or when different destinations need different encoder combinations or transport settings.
Main programme delivery to a distribution partner or downstream broadcast workflow.
Backup or redundant delivery path alongside a primary output.
Clean feed delivery without certain graphics or presentation elements.
Language-specific delivery using different audio encoders.
Technical testing before an event goes live.
Supported protocols and modes
Outputs support both SRT in Listener or Caller mode, and RTMP in Client or Server mode.
Protocol | Mode | How the connection works | Typical use |
SRT | Listener | The control room waits for the remote system to connect in. | Useful when the receiving system is responsible for initiating the connection to your output. |
SRT | Caller | The control room actively connects out to the remote destination. | Useful when the destination provides a host and port that your output should dial. |
RTMP | Client | The control room pushes the stream to an RTMP or RTMPS endpoint. | Common for publishing to streaming platforms and managed ingest endpoints. |
RTMP | Server | The control room exposes an endpoint so an external system can publish or connect using a server-mode workflow. | Useful when the external workflow expects the platform to present the receiving endpoint details. |
What an output includes
The exact fields shown depend on the selected protocol and mode, but an output is made up of the following core settings.
Field | What it is used for | Applies to |
Name | The label used to identify the output in the control room. Use a clear operational name so operators can immediately recognise the destination and purpose. | All outputs |
Enabled | Controls whether the output is active and available for use. This is helpful when keeping a destination configured but not currently in service. | All outputs |
Protocol | Defines the transport family used for delivery. The supported options are SRT and RTMP. | All outputs |
Mode | Defines how the connection is established within the selected protocol. SRT uses Listener or Caller. RTMP uses Client or Server. | All outputs |
Video encoders | Selects the video encoder or encoders that will be included in the output. This determines which version of the video leaves the control room. | All outputs |
Audio encoders | Selects the audio encoder or encoders included in the output. This is important for language versions, programme audio, commentary variants, or alternate mixes. | All outputs |
Muxing profile | Determines how the selected video and audio encoders are packaged together for delivery. | All outputs |
Minimum latency | Sets the minimum latency value used by the output where applicable. This helps balance responsiveness and resilience depending on the network path. | SRT outputs |
IP allow list | Restricts which remote IP addresses can connect when the output is configured to accept inbound connections. | SRT Listener, RTMP Server where applicable |
Port | Defines the port used for the connection or listening endpoint. | SRT and RTMP modes where a port is required |
Encrypted | Enables encryption for SRT delivery when required by the receiving workflow. | SRT outputs |
Server | The hostname or server address used for RTMP delivery or presented for RTMP server workflows. | RTMP outputs |
Stream key | The destination-specific stream identifier used by RTMP workflows. | RTMP outputs |
Enable SSL | Enables secure RTMP delivery using RTMPS where required by the destination. | RTMP outputs |
How to add an output
Outputs are added from the Outputs tab of the control room. The walkthrough below shows the full flow, and the steps summarise it for quick reference.
Video link: https://vimeo.com/1221516400
Open the control room and select the OUTPUTS tab
Select ADD OUTPUT to create a new delivery path
Enter the NAME used to identify the destination and purpose, and set whether the output is ENABLED
Choose the PROTOCOL and the MODE required by the destination
Select the VIDEO ENCODERS and AUDIO ENCODERS to include, then confirm the MUXING PROFILE
Complete the transport settings for the selected mode — PORT, MINIMUM LATENCY, ENCRYPTED, and IP ALLOW LIST for SRT, or SERVER, STREAM KEY, and ENABLE SSL for RTMP
Select SAVE to apply the output, then verify it against the destination’s ingest requirements before going live
How SRT outputs work
SRT outputs are typically used when you need reliable live delivery over unpredictable networks with better resilience and latency control than legacy transport methods. In the Outputs tab, SRT can be configured in either Listener or Caller mode.
SRT Listener
In Listener mode, the control room exposes an SRT endpoint and waits for the remote receiver to initiate the connection. This is useful when the downstream system is designed to call into your workflow.
Use Listener mode when the receiving partner or decoder will connect to you.
Check the port carefully so the remote side knows exactly where to connect.
Use an IP allow list when you want to restrict inbound connections to approved addresses.
Confirm minimum latency based on the quality and stability of the network path.
Enable encryption if the workflow requires protected transport.
SRT Caller
In Caller mode, the control room actively dials out to the destination. This is useful when the receiving endpoint provides a known address and port and expects your output to establish the session.
Use Caller mode when the destination gives you connection details to dial.
Confirm the remote server and port before going live.
Set an appropriate minimum latency for the route rather than using an unnecessarily aggressive value.
Match encryption settings with the receiver so the handshake succeeds.
How RTMP outputs work
RTMP outputs are commonly used for distribution to platforms and services that accept RTMP or RTMPS publishing. In the Outputs tab, RTMP can be configured in Client or Server mode.
RTMP Client
In Client mode, the control room pushes the stream to the destination. This is the most familiar RTMP workflow and is commonly used for social, digital, or managed streaming endpoints.
Use Client mode when the destination provides a server URL and stream key.
Verify the server value exactly as provided by the destination.
Verify the stream key carefully because even a small mismatch can prevent publishing.
Enable SSL when the destination requires RTMPS rather than standard RTMP.
RTMP Server
In Server mode, the control room presents the RTMP-side connection details needed by the external workflow. This is useful when the connected system expects the control room environment to expose the server endpoint rather than pushing to a third-party URL.
Use Server mode when the external workflow is designed to connect to a server endpoint presented by the platform.
Confirm the exposed server and port details with the external team.
Use access restrictions where applicable to reduce the risk of unintended connections.
Clarify whether SSL is required for the specific integration.
How t
Common output patterns
Pattern | How it is typically used | Why it helps |
Single destination | One output carrying the main programme to one receiver or platform. | Simple to operate and easy to validate. |
Primary and backup | Two outputs carrying the same content to separate destinations or paths. | Improves resilience if one path fails. |
Programme and clean feed | Separate outputs using different encoder combinations for branded and unbranded delivery. | Supports different rights, partner, or editorial needs. |
Multilingual delivery | Multiple outputs with different audio encoders for separate language versions. | Allows targeted distribution without rebuilding the whole production. |
Test output | A separate output reserved for rehearsal or pre-flight verification. | Reduces risk before taking the main destination live. |
Best practices
Use output names that include both the destination and the purpose, such as programme, backup, clean, or language version.
Keep transport settings aligned with the destination’s published ingest requirements.
Do not assume the same latency or security settings are appropriate for every destination.
Use separate outputs instead of reusing one output for multiple operational purposes.
Test high-priority outputs before transmission windows open.
Document which team owns the far end of each connection so troubleshooting is faster during live operations.