For inbound contribution, use Wowza Streaming Engine’s SRT listener workflow when your installed version supports it: configure the listener, then have your source call its address and port with the correct publishing stream ID. The listener is on the Wowza side; the encoder or software publisher is the caller.
That is different from an outbound SRT Stream Target, where Wowza calls a remote destination. Confirm your version and intended direction first, because the setup steps, connection roles and latency options vary by workflow.
Confirm your Wowza version and SRT support
Start with the installed Wowza Streaming Engine version and the operating system on the machine running it. Wowza’s current SRT ingest guide says that Streaming Engine 4.7.3 and later supports ingesting MPEG-TS-packaged SRT streams, and identifies SRT 1.5.0 or later. Those are the guide’s stated requirements; do not assume that an older installation exposes the same listener workflow or configuration options.
Check the documentation for your installed release as well as the general guide. Configuration screens, available workflows and supported options can differ between releases. In particular, Wowza notes that some new Windows installations of Engine 4.8.0 or later may need the current Microsoft Visual C++ Redistributable for certain SRT workflows. If SRT is unavailable or a connection fails before you start tuning, check the applicable release notes and operating-system requirements rather than compensating with unrelated stream settings.
For a first inbound feed, Wowza recommends listener mode in its current ingest guide because it simplifies configuration and network port management. It uses a server-side listener configuration rather than a separate .stream file and UDP port for every incoming feed. Legacy MediaCaster remains a possible workflow for cases such as multiple alternative tracks, but it has different per-source configuration needs.
Keep the basic media format in view. The ingest workflow described by Wowza expects SRT carrying MPEG-TS. A successful network handshake alone does not mean Wowza can publish the media: if the source sends a different container or packaging, confirm the encoder’s output format before changing listener settings.
Choose inbound listener mode or outbound Stream Target
First decide where the video is going. If an encoder or software publisher is sending a feed into Wowza, you are configuring inbound ingest. With listener mode, Wowza listens and the source connects to it as caller. If Wowza is sending a stream to another system, you are configuring an outbound SRT Stream Target; Wowza takes the caller role for that connection.
| Workflow | Connection roles | Per-source setup | When it fits |
|---|---|---|---|
| Inbound SRT listener | Wowza listens; source calls | Configure the listener once; multiple incoming connections can use its configured SRT port | A straightforward contribution feed into a live application |
| Legacy inbound MediaCaster | The source connects to the MediaCaster workflow configured for the feed | A .stream file and separate UDP port for each SRT stream |
A more complex ingest arrangement, such as alternative tracks |
| Outbound SRT Stream Target | Wowza calls; the remote destination listens | Add and configure a target for the outgoing stream | Sending a Wowza stream to a remote SRT endpoint |
The second row is an alternative, not a prerequisite for listener mode. Do not create a .stream file and reserve a unique port for each feed simply because an older tutorial uses that design. Conversely, do not try to use inbound listener instructions to configure an outbound target: the party that calls, the destination address and the target options are different.
For an outbound target, Wowza’s SRT Stream Target documentation describes adding an SRT target under Generic Target Destinations in a Live application. You select the source stream, destination host and port, and transport options. That guidance is for delivery out of Wowza, not for an encoder calling an inbound listener.
Configure the server, virtual host and application
For listener mode, make the configuration at the levels Wowza specifies: Server.xml, VHost.xml and Application.xml. Treat this as a one-time listener setup for the relevant server, virtual host and application, not as a set of per-feed files. Use Wowza’s current ingest procedure for the exact configuration elements and location in the release you have installed; do not copy XML fragments from a different Engine version without checking their context.
Create or identify a live application to receive the feed. Be clear about the application name and instance that the source will publish into. If you use the default instance, reflect that choice consistently in the publishing stream ID. A mismatch between a valid listener and the intended application path can produce a connection that appears established but does not create the expected incoming stream.
The listener port is configured in the virtual host configuration. Before testing, allow that UDP port through the host firewall and any network firewall or security group between the source and Wowza. Listener mode reduces the number of ports you have to manage compared with one-port-per-source legacy setups, but it does not remove the need to permit the configured port.
Write down the listener address, port, application, instance and intended stream name before entering settings on the encoder. This small hand-off note prevents common copy-and-paste mistakes when someone else operates the source. Avoid placing a real encryption passphrase in a shared runbook, screenshot, or publicly visible configuration example.
If your broader channel uses fixed video or audio segments, format compatibility still matters after ingest. For a pre-recorded channel, this guide to preparing a YouTube live playlist with subtitles covers a different part of the chain: preparing the content that will be encoded and sent. It does not replace the SRT listener configuration.
Set the listener port and publishing stream ID
The caller URI needs to identify the Wowza listener’s public address and configured SRT UDP port. It also needs a stream ID that tells Wowza the publishing mode and the target application, instance and stream path. Use the syntax in the current Wowza guide and substitute your own values; the following is a shape only, not a URI to paste unchanged:
srt://<listener-public-address>:<listener-port>?passphrase=<secret>&pbkeylen=32&mode=caller&streamid=#.::m=publish,r=<application>/<instance>/<stream>
The example reflects the caller connecting to a listener and includes a publish stream ID. Replace every placeholder, including the address, port, application, instance, stream name and secret. Do not publish a working passphrase in documentation or logs. The passphrase and key length are optional if you are not using encryption; if you are using it, ensure both ends agree.
For the stream path, use the names configured in Wowza rather than a display title or YouTube channel name. Check for spelling, letter case where relevant, extra slashes and an unintended instance name. If you target the wrong application or stream, the network connection may succeed while the stream remains absent from the application you are watching.
Listener mode can accept multiple incoming connections on the same configured SRT port. Each connection still needs the correct publishing destination, so use distinct stream names or paths where your application design requires them. The point is not that every source is interchangeable, but that listener mode does not require a separate .stream file and port for every inbound feed.
Connect the SRT source with matching UDP and encryption settings
On the encoder or software publisher, configure an SRT caller aimed at Wowza’s reachable public hostname or IP address and the listener port. Use UDP transport, the publish-mode stream ID and the application/instance/stream path you checked above. The source and server must agree about whether encryption is enabled and, if it is, about the credentials and key length.
Wowza’s example uses pbkeylen=32. Its guide lists 0/default, 16, 24 and 32-byte key-length values. Do not assume that choosing a value on one side automatically configures the other side. For global passphrase encryption, use the same configured passphrase at the publisher. For per-user encryption, use the identity and credentials configured on the server. Follow the version-specific Wowza instructions for the mode you choose.
A passphrase mismatch or an incompatible key length can prevent the encryption handshake. Treat a secret as a credential: share it only through an appropriate channel, keep it out of public screenshots and redact it from logs before sending diagnostics. Do not add a passphrase merely because it appears in a sample URI; encryption settings have to be deliberately configured on both ends.
SRT uses UDP and can request retransmission of missing packets. That can help a contribution feed cope with packet loss, but recovery takes time and network capacity. The receiving buffer has to allow a retransmitted packet to arrive before its delivery deadline. This is why a very small latency setting can make a lossy or jittery route less reliable rather than making the full programme path instant.
For related reliability work on a long-running YouTube channel, see the practical checks for audio crackling in a 24/7 rain stream. SRT transport is only one part of the chain; it cannot correct clipping, a noisy source or an audio issue already present in the encoded programme.
Tune latency without confusing it with end-to-end delay
SRT latency is a transport buffer setting, not a measurement of camera-to-display delay. The complete path may also include capture, encoder buffering or lookahead, multiplexing, network and application processing, decoding, player buffering and display delay. A low SRT value therefore does not establish that a viewer will see the picture with equally low overall delay.
For an outbound Stream Target, Wowza documents a latency field for Engine 4.8.5 and later, with a stated minimum of 120 ms and a default of 400 ms when no value is specified. Wowza recommends setting it to 2.5 times network round-trip time (RTT); when peers request different values, the higher one applies to both. These documented target details concern outbound delivery. Confirm whether the inbound workflow and installed version expose the settings you need before applying them to listener ingest.
For either direction, start with the documented workflow guidance, not an arbitrary ultra-low value. Measure RTT on the actual route and observe packet loss and jitter under realistic load. Lower latency gradually while watching for late-packet drops, visible artefacts and reconnects. If interruptions appear, increase the buffer in controlled steps and test again. A value that behaves well on a quiet office network may not behave the same on a busy mobile or broadband path.
When you record a latency result, say what you measured. A measured SRT transport delay is not a glass-to-glass figure, and an end-to-end measurement needs a defined starting and ending point. If the SRT transport looks healthy but viewers still see a long delay, inspect encoder buffering, any transcoding, the output protocol, player buffer, decoding and display behaviour rather than assuming the listener latency field controls all of them.
For MPEG-TS in the outbound Stream Target workflow, Wowza says to use its default payload size of 1500. That is a workflow-specific instruction, not a reason to adjust packet size for inbound listener mode without checking its documentation. Keep outbound target settings separate from the source-to-Wowza ingest configuration.
Check the connection and troubleshoot version-specific differences
After the source calls the listener, check Wowza’s Incoming Streams view for an active stream in the expected application. Then verify playback through the output protocol configured for that application. A connected SRT session and a visible, playable published stream are separate checks; confirm both before treating the ingest path as ready.
If there is no connection, check the caller/listener roles first, then the public address, the listener’s configured UDP port and firewall or security-group rules. Confirm that the source is reaching the intended Wowza host and that the installed version and operating system support the workflow. For outbound delivery, the inverse role check applies: Wowza should call the remote destination, which must be ready to receive it.
If the connection exists but the stream does not appear, check that the source is sending MPEG-TS, that the stream ID uses publish mode, and that its application, instance and stream path match the live application. Then check the application’s Incoming Streams view rather than relying only on an encoder’s “connected” status. A stream ID copied from a different application is a common reason that transport and publishing outcomes differ.
If the encryption handshake fails, compare whether encryption is enabled on each side, the passphrase, the key length and whether the server expects global or per-user credentials. Do not troubleshoot by sharing the secret in an open ticket. Redact it and report the selected mode and key-length setting instead.
If the feed stutters or late packets are dropped, measure RTT, jitter and loss along the source-to-server route. Increase the available SRT latency buffer in controlled steps and retest under realistic load; also confirm sender and receiver buffer behaviour for the installed software. No one setting suits every route. If the SRT connection is stable but programme delay remains high, inspect the other stages in the media path rather than treating SRT latency as the entire delay budget.
Legacy tutorials may describe a MediaCaster .stream file and a port per feed. That is not a missing step in listener mode. Use the legacy workflow only if its particular capabilities, such as alternative-track handling, fit your requirements and the installed version’s documentation supports it. For a separate always-on video workflow that does use FFmpeg, the Debian VPS setup guide is relevant to that alternative, but it is not a Wowza SRT listener procedure.
Once the incoming feed is published in Wowza, the later path to YouTube still needs its own configuration and monitoring. If the goal is a pre-recorded, persistent channel rather than contribution ingest into a Wowza workflow, StreamNeo removes the need to keep your own computer running to maintain the YouTube broadcast: upload the file, provide the YouTube stream key, and the broadcast continues with monitoring and automatic restarts if it drops. It is a YouTube-only service, so it is not a replacement for the SRT connection into Wowza.
Choose the workflow that matches the direction of your feed and test with the actual source, route and playback destination before relying on it unattended.
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
How do I set up SRT in Wowza Streaming Engine?
Confirm that your installed version supports the workflow, create or select a live application, and configure listener mode in Server.xml, VHost.xml and Application.xml using Wowza’s current guide. Open the configured UDP port and have the source call the listener with the correct publish stream ID and matching encryption settings. Verify the published stream in Incoming Streams and test playback.
How do I send an SRT stream to Wowza?
For inbound listener mode, configure Wowza as the listener and set the encoder or software publisher to caller. Point it at the listener’s reachable address and configured port, then supply the publish-mode stream ID for the right application, instance and stream. Do not reverse the roles unless you are setting up an outbound target.
What SRT latency should I use?
There is no universal value for every route. Start from the guidance for your specific Wowza workflow, measure RTT and watch loss and jitter, then adjust gradually while checking for late drops and interruption. Remember that the SRT buffer does not include encoder, player, decoder or display delay.
Why does my SRT stream connect but not appear in Wowza?
Check that the source is sending MPEG-TS and that the stream ID specifies publish mode and the correct application, instance and stream path. Confirm the stream in the application’s Incoming Streams view rather than treating the transport connection as proof of publishing. If encryption is involved, a credential or key-length mismatch may also stop the stream from being accepted.