An SRT output in AWS Elemental Live sends a transport stream to a receiver over a connection whose address, role, latency, encryption and network path must be agreed in advance. Configure the sender to match the receiving system; there is no universal endpoint value or setting that can substitute for that coordination.
This guide separates the choices made in the Elemental Live event from the information the receiver’s administrator must supply. It also explains when to use the dedicated AWS Elemental MediaConnect output option instead of generic SRT.
Confirm the receiver’s requirements first
Before opening the event configuration, ask the receiving-system administrator for its connection role, destination IP address and port, latency target, encryption requirement and network access requirements. These are deployment-specific values. Do not copy a sample address or port from documentation into a live configuration and assume it identifies your receiver.
Establish which side will be the SRT caller and which will be the listener. A caller initiates the connection handshake; a listener waits for and accepts or rejects it. The receiver’s role determines the Elemental Live mode to select, even though Elemental Live remains the sender of the programme content in either arrangement.
Agree a latency value with the receiver. SRT uses latency to allow time for packet recovery when network delivery is disrupted, so the receiving system’s expectations and the sender’s setting need to be close. AWS does not prescribe a universal value for this output. Ask the receiver what it supports and what it will configure, then record the agreed value rather than guessing.
If encryption is required, ask whether the receiver expects AES 128, AES 192 or AES 256, and arrange the passphrase through an appropriate secure channel. The selected encryption level and passphrase must match at both ends. If the receiver requires no encryption, confirm that explicitly and select None rather than relying on an assumption.
Also decide whether the delivery is a single stream or redundant pair. A second destination is only useful when the receiver can accept two streams and switch to the alternate if needed, and when the provider can supply two completely identical source copies. If either condition is missing, configure one destination. For help thinking through the broader shape of an always-on setup, see how a prerecorded YouTube live loop can be run, but do not confuse a YouTube ingest workflow with this separate SRT receiver configuration.
Finally, confirm which network path is available. The caller must be able to reach the listener, and the relevant firewalls, security controls and routing must permit the agreed traffic. Ask the people responsible for both endpoints to validate the path before treating the output as ready.
Choose the event output type
For generic SRT delivery to a non-MediaConnect destination, use the Reliable TS output group in the Elemental Live event. Within that group, add an output and set its Delivery Protocol to SRT. AWS documents this as the path for delivering a live transport stream over SRT; consult the AWS Elemental Live SRT output guide for the current product workflow and terminology.
Check the software version installed on your Elemental Live system before you begin. AWS’s output types table lists SRT in Reliable TS and identifies version 2.22.2 as its introduction point. That is a historical version fact, not a guarantee that a particular appliance has the feature enabled or that its interface matches every current guide. Verify your installation and consult the documentation applicable to it.
The output group selection is not the same as choosing a destination. Reliable TS provides the container for this type of output; the SRT delivery protocol identifies how that output is transported; and the destination details identify the receiving system. Keep these separate when reviewing an event so a correct protocol selection does not create false confidence about an unverified endpoint.
AWS also makes a specific distinction for its own MediaConnect service. If the destination is an SRT flow on AWS Elemental MediaConnect, the recommended path is still the Reliable TS group, but with the AWS Elemental MediaConnect option rather than the generic SRT choice. The decision point is therefore the receiving service, not a preference for one label over another.
Configure a Reliable TS SRT output
In the event, open Output Groups, select Reliable TS, and choose Add Output. Set Delivery Protocol to SRT for a generic non-MediaConnect receiver. The exact display and available fields can depend on the installed version, so use the controls and help text present in your system rather than inferring an interface or network setting.
For the primary destination, enter the receiver’s IP address and port exactly as supplied by its administrator. AWS documentation includes an illustrative endpoint, but it is only an example and must not be reused as a real destination. Confirm both fields with the receiver, including whether the address is reachable from the Elemental Live system and whether it is the correct address for this specific output.
Select the interface only if your deployment requires it, and obtain the correct choice from the person who manages that Elemental Live installation and its network. Do not assume an interface name or value from another site. If you are uncertain which interface carries the traffic, stop and verify the routing rather than testing arbitrary choices against a production receiver.
Set the SRT connection mode to match the receiver’s role, then enter the coordinated latency. Choose None or the agreed AES encryption level. When encryption is enabled, enter the passphrase provided for this connection, taking care to use the same value at the receiver. A mismatch can prevent a successful connection even when the address and mode are otherwise correct.
Add a secondary destination only when the redundancy decision has been confirmed with both sides. The receiver must be able to handle the second stream, and the content provider must be able to deliver two completely identical copies. Confirm the address, port and any other connection settings for the secondary path separately; do not assume that the primary values automatically apply.
AWS notes that Elemental Live does not use an SRT stream ID when delivering output. Do not add a stream ID as an invented requirement to this procedure. For official preparation details, use AWS’s SRT output preparation page, and verify any installation-specific fields against the interface in front of you.
Before saving or starting the event, review the destination, connection mode, latency, encryption and passphrase against the written agreement. A useful review is a field-by-field read-back with the receiver’s administrator. That catches transcription mistakes without treating a successful save in the encoder as proof that the other end is ready.
Match caller or listener mode to the receiver
Elemental Live’s connection mode is the inverse of the downstream endpoint’s mode. If the receiver is a listener, configure Elemental Live as caller. If the receiver is a caller, configure Elemental Live as listener. Confirm the receiver’s configured role rather than asking vaguely whether it “supports SRT”; support for the protocol alone does not tell you which side initiates the handshake.
| Downstream endpoint role | Elemental Live mode | Handshake initiator | What to confirm |
|---|---|---|---|
| Listener | Caller | Elemental Live | The caller can reach the receiver’s listening address and port |
| Caller | Listener | Downstream endpoint | The receiver can reach and initiate to the Elemental Live listener |
This pairing does not reverse the direction of the programme. Elemental Live sends the output content in both cases; the roles govern who starts the connection. If the handshake does not begin, check the role and path before changing unrelated video or audio settings.
The network may determine which pairing is workable. A receiver behind a restrictive firewall might be unable to initiate towards Elemental Live, while an outbound caller from Elemental Live might be allowed, or the reverse may be true in another environment. These are local network facts, not general SRT guarantees. Ask the network administrators to identify the permitted direction, then coordinate the role pair with the receiver.
Do not select a mode merely because it is the default or because it worked for a different output. The mode must match the endpoint that will participate in this connection. If the receiving platform changes role between environments, treat each environment as a distinct configuration and validate the chosen pairing for each one.
Coordinate latency and encryption
Latency is a shared operational setting, not a number to choose by feel. It gives SRT room to recover packets, but a value that differs materially from what the receiver expects can undermine the intended recovery behaviour or prevent an agreed setup from working as planned. Agree the value with the receiving administrator, configure it in Elemental Live, and ask the other side to confirm its corresponding setting.
There is no value in this guide that can be safely copied to every deployment. The path, receiver and operating requirements differ. If the receiver cannot provide a target, ask its vendor or administrator for a supported setting and a way to test it. Record the agreed value with the event’s runbook so a later operator does not replace it with a guess during troubleshooting.
Encryption is likewise a joint choice. Elemental Live offers None, AES 128, AES 192 or AES 256 for this output workflow. If AES is used, both sides must agree on the level and passphrase; entering a passphrase in only one system, or choosing different levels, does not create a compatible encrypted connection. Share the passphrase through a secure method rather than embedding it in an ordinary support ticket or broadly shared notes.
If you change encryption after a connection has been tested, coordinate the change with the receiver and retest both sides. A mismatch can look like a network or connection-mode issue, so include the encryption level and passphrase confirmation in a controlled checklist. Do not weaken or disable encryption simply to make a test pass unless the receiver’s owner has agreed to that temporary configuration and the consequences are understood.
Check firewall and network access
A correctly configured output still needs a usable network path. The Elemental Live system and the receiver must be able to communicate in the direction implied by the caller/listener arrangement. Confirm that routing, firewalls and any other network controls permit that traffic, using the receiver’s supplied address and port and the actual interface selected on the Elemental Live installation.
The receiver’s administrator may need to allow traffic from Elemental Live’s public IP address or open access on the destination side. Which change is required depends on the deployment. Have the relevant network owners verify the permitted path rather than inferring it from a successful event configuration screen. AWS’s SRT output creation instructions describe the product fields, but your administrators must determine the addresses and access rules for your network.
When a connection fails, work through the agreed fields in a deliberate order: confirm the address and port, verify caller/listener pairing, check that the path is permitted in the handshake direction, and then compare latency and encryption settings. Ask the receiving side whether it sees an incoming attempt or a rejection. That observation can help separate a reachability problem from a settings mismatch, although it does not by itself prove where a fault lies.
For operators maintaining a separate YouTube broadcast over a home or office connection, the practical network questions can differ. This Airtel broadband troubleshooting guide covers a YouTube live stream dropping on that access network; it is not a substitute for verifying the SRT path between Elemental Live and its receiver.
Keep a record of the receiver contact, confirmed endpoint details, interface decision, permitted traffic direction and encryption coordination alongside the event notes. Restrict access to sensitive values such as passphrases. This makes a later handover more useful than a screenshot alone and helps prevent an operator from silently changing a working configuration to match an unrelated example.
Use the MediaConnect output when the receiver is a MediaConnect flow
If the destination is an SRT flow on AWS Elemental MediaConnect, AWS recommends choosing the AWS Elemental MediaConnect option in the Reliable TS output group rather than configuring it as a generic SRT output. If the receiver is another SRT-capable system, use the generic SRT path. Confirm which service and flow actually receive the stream before selecting the output option.
This distinction is about the destination and the supported integration path, not a change to the need for coordination. You still need the correct receiving flow and its required settings, compatible network access, and agreement between the systems. Do not invent an endpoint address, port, key or flow detail from a generic SRT example. Obtain those values from the MediaConnect setup and its responsible administrator.
Use the AWS documentation for delivering TS over SRT alongside the current MediaConnect and Elemental Live documentation for your deployment. The names and workflow in the interface should be checked against the installed software and current service configuration. If you are not sending to a MediaConnect SRT flow, the dedicated option is not a reason to route a generic endpoint through an unrelated service.
A MediaConnect destination can make sense when that AWS service is the receiving system in the planned workflow. For an independently managed receiver, the generic SRT output is the direct choice described here. In either case, confirm ownership of the receiving endpoint, network path and operational hand-off before you schedule a production output.
For a separate YouTube channel workflow, the SRT destination is not the same as YouTube’s ingest endpoint or stream key. If your broader work also involves a channel encoder, this guide to configuring YouTube encoder settings for Indian music streams addresses a different link in the chain. StreamNeo removes the need to keep a local computer running for a file-based 24/7 YouTube broadcast, but it does not configure or replace an Elemental Live SRT connection to a separate receiver.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does Elemental Live send the content when it is set to listener?
Yes. Elemental Live remains the sender of the programme output in both connection modes. Listener mode means the downstream caller initiates the connection handshake to Elemental Live; it does not mean the receiver sends the programme content.
Can I use an SRT example address and port from AWS documentation?
No. An example is illustrative and is not a destination for your event. Ask the receiving administrator for the actual IP address and port, then confirm that the network permits the required connection direction.
Do both systems need the same encryption settings?
Yes. If you enable AES encryption, agree the AES level and passphrase with the receiving administrator and configure matching values at both ends. If encryption is not required, confirm that choice and use None.
Should I add a secondary destination for redundancy?
Only if the receiver can handle two streams and switch to the alternate, and the provider can supply two completely identical source copies. Coordinate and verify the secondary endpoint independently; otherwise keep the output to one destination.