A Wowza Streaming Engine stream source is the incoming feed, identified by its URI. A .stream file gives that URI a usable name, and MediaCaster uses the file to connect the source to a live application for playback.
The important choice is not simply whether a feed is video or audio. Match the MediaCaster type to the source protocol and its mode: an RTSP camera, an SRT feed, and an RTMP pull do not necessarily use the same connection method. This guide follows that choice from source identification through playback checks.
What a Wowza Stream Source Is
A source is the live input that Wowza is to receive: for example, an IP camera publishing through RTSP/RTP, an encoder sending MPEG-TS, an audio stream from SHOUTcast or Icecast, or an SRT feed. The URI identifies where and how to reach that input. It may include a protocol, host, port, path, and, where applicable, authentication details.
That makes the URI the starting point for configuration, but it is not the whole setup. You also need a live application to host the stream and a MediaCaster type that understands the source family. A correctly copied address paired with an unsuitable MediaCaster type can leave a source waiting rather than connected.
It helps to separate the pieces:
| Piece | What it identifies or does | What it is not |
|---|---|---|
| Source URI | Address and protocol for the upstream feed | A player-facing stream by itself |
.stream file |
Named reference to the URI | The live media feed |
| MediaCaster | Connection method used to pull a supported source | A universal connector for every protocol |
| Live application | The Wowza application in which the source is made available | The upstream source |
This distinction is useful whether your source is a camera at a place of worship, an encoder in a small studio, or a remote contribution feed. Before opening the manager, find out which protocol the device is actually sending. A product description saying “supports streaming” is not enough; check its output mode and the URI format it provides.
If the destination is YouTube rather than a viewer on your own site, there are further stages after Wowza ingest: the application must make the feed available, and a downstream workflow must deliver it to the YouTube live event. This article is about the Wowza source leg, not a claim that adding a .stream file creates a YouTube broadcast. For YouTube-side encoder checks, see the guide to checking RTMP bitrate fluctuations on Airtel Xstream Fiber.
How a .stream File Identifies a Source
A .stream file is a small named configuration entry that points to an incoming source URI. Think of it as an alias: instead of repeatedly using a long source address, you refer to the named stream file in the Wowza workflow and, where supported, in playback URLs. The media still comes from the address in the file; the file does not contain or generate the live content.
For instance, an operator might create a file called temple-camera.stream whose contents or configured value identify the camera's URI. The name is for the operator's workflow. It does not change the camera protocol, repair a bad network route, or make an RTSP source behave like SRT.
Wowza's Stream Files guide describes adding a stream file with a name and source URI, and advises using the IP address of the server hosting the stream as the Stream URI. Follow the current instructions for the installed Engine release and your deployment: an address that works from a workstation may not be reachable from the Engine host.
Treat the source URI as configuration information. If it contains credentials or access tokens, limit who can view or share the file and avoid pasting the full value into public troubleshooting posts. When asking for help, redact secrets while preserving enough of the scheme, host and path structure to identify the protocol.
The alias also helps keep the viewer-facing name stable if you later need to revise the source address. That convenience does not remove the need to test the revised URI. The source must still be available and compatible with the selected connection method.
What MediaCaster Does
MediaCaster is the part of this workflow that connects to a source represented by a stream file and makes it available through a live application. The selected MediaCaster type determines how Wowza attempts that connection. It must fit the protocol or source family; choosing a familiar-looking option is not a substitute for confirming what the upstream device sends.
In the documented stream-file workflow, the source is on demand. Wowza's guide explains that the first player request for a stream file makes its referenced source available. After the last viewer leaves, MediaCaster waits through a timeout and can stop the source if another request does not arrive. That behaviour affects how you interpret an apparently idle source: a pull may not begin until the playback path is requested.
Do not confuse this documented on-demand behaviour with a promise that every deployment will start or stop in exactly the same way under every configuration. Check the relevant application and source settings in the current product documentation, then test with a player request. If you need a source to remain active for a particular operational reason, verify how that requirement should be configured for the Engine version and source type you use.
Per-stream settings can override application-level settings where those settings apply to the relevant stream type. They are useful when one source needs a different configuration from the rest of the application, but they are not a universal fix. Consult Wowza's per-stream settings reference for supported properties and protocol scope before adding overrides.
Choose a Source Type for the Feed
Start with the source device or upstream service, not the menu of MediaCaster values. Confirm both the protocol and its mode: MPEG-TS sent over TCP/IP is a different case from an encoder emitting MPEG-TS by another transport. Likewise, an RTMP pull from another Wowza instance calls for a different selection than an RTSP/RTP camera.
The mappings below summarise the source families in Wowza's stream-file guide. Use them as a selection aid, then check the current documentation and installed release for your case.
| Incoming source family or mode | MediaCaster selection | Check before connecting |
|---|---|---|
| RTSP/RTP IP camera, native RTP encoder, or MPEG-TS encoder in the documented RTP group | rtp |
Confirm the device's actual output mode and URI |
| SHOUTcast or Icecast | shoutcast |
Confirm that the URI is for that audio-stream source |
| RTMP or WOWZ pulled from another Wowza Streaming Engine instance | liverepeater |
Confirm the upstream is the appropriate Wowza/RTMP source and that it is reachable |
| Apple HLS live source | applehls |
Check the current release documentation for version support |
| MPEG-TS over TCP/IP | mpegtstcp |
Confirm the transport is TCP/IP, not only the media format |
| SRT source | srt |
Confirm source-side SRT mode, addressing, reachability and Engine support |
These are not interchangeable labels. For example, if an RTMP source remains in a waiting state after you selected rtp, check whether it is a pull from another Wowza Engine and whether liverepeater is the applicable type. That is a useful diagnostic, not proof that every waiting RTMP source has the same cause. Verify the URI, any credentials, upstream availability and network path as well.
Version support can change. The stream-file guide includes historical minimums for some types, including applehls, mpegtstcp and srt; do not rely on an old minimum as a guarantee for a new installation. Compare the current release documentation with the installed version before planning a migration or building a production workflow.
Create and Configure the .stream File
The general process is to create the live application, add the named file and URI, then connect the file to that application with a matching MediaCaster type. The exact labels in Streaming Engine Manager can vary by release, so use the current Wowza stream-file setup instructions alongside these checks.
- Create or choose a live application. Decide which application should expose this source. Keep the name and purpose clear if the Engine hosts multiple inputs; that makes it easier to diagnose the right stream later.
- Open Stream Files in Manager and add a file. Give it a descriptive name ending in
.stream, then enter the source URI. Follow Wowza's guidance about using the IP address of the host serving the feed. Check for copied spaces, incomplete paths and incorrect schemes. - Decide whether the stream needs per-stream settings. If the source can use the application's settings, avoid adding overrides simply because the option exists. If it needs different properties, confirm those properties are supported for that source type and set only what is needed.
- Connect the file to the live application. Select the application that should host it and choose the MediaCaster type matching the source family and transport. Do not infer the type from the file extension or content alone.
- Request playback to test the on-demand source. Use the appropriate playback URL for the application and named file, then observe whether the source connects. A request is part of the documented on-demand workflow, not merely a final viewer check.
A careful naming scheme can save time when several inputs are involved. hall-rtsp-camera.stream is more informative to an operator than stream1.stream, but naming conventions are just for clarity; they do not affect protocol compatibility. Keep a separate, controlled record of any credentials and operational details rather than embedding sensitive notes in a name.
A .stream file that exists in Manager is not evidence that a source is connected. Check the connection state and logs, and verify that a player can receive the resulting stream. When a continuous YouTube channel is the end goal, also plan the outgoing encoding and delivery separately; a Wowza source configuration alone does not establish that full chain. The practical considerations in planning upload bandwidth for a nonstop worship stream can help with the outbound side.
Pull an SRT Stream into a Live Application
For an SRT source, use the SRT source type in the Stream Files workflow, then connect that file to the live application. Wowza's documented example URI is srt://0.0.0.0:[port]. Treat it as an example form rather than a value to copy without checking: the correct address, port and connection arrangement depend on the actual deployment and source-side mode.
Before entering the URI, establish which side is initiating or listening and what address the source is configured to reach. Confirm that the chosen port is reachable between the source and the Engine host, and that any intervening firewall or network rules allow the intended connection. Do not infer those details solely from an SRT URL shown for a different Wowza product.
In particular, Wowza Video and self-hosted Wowza Streaming Engine are distinct products. The Wowza Video SRT encoder guide gives instructions specific to Wowza Video, including its service connection information. Its URL pattern and port guidance should not be transplanted into a Streaming Engine .stream file. For Engine, follow the Engine stream-file guide and release-specific documentation.
After creating the URI, select srt as the MediaCaster type, associate the stream file with the intended live application, and request playback to trigger the on-demand workflow. If it does not connect, check the SRT mode, address and port first, then confirm that the installed Engine release supports the needed type. A source being labelled “SRT” does not by itself establish that both ends are configured for compatible connection behaviour.
Check the Source and Playback Path
Troubleshoot in layers so that you can tell whether a failure is at ingest or downstream. First confirm the source is running and that its URI is correct from the Engine host's point of view. Then check that the file is associated with the right live application and that the selected MediaCaster matches the protocol and transport.
Next, issue a player request using the appropriate playback path for the application and stream file. Since stream-file sources are on demand in the documented workflow, an idle source before a request does not necessarily indicate a broken feed. If it remains unavailable after the request, note the state or error shown in Manager and consult the logs for a specific connection failure.
Check these points in order:
- Address: Is the URI complete, and does it use an address the Engine host can reach?
- Protocol and mode: Does the URI and actual sender output match the MediaCaster selection?
- Application association: Is the stream file connected to the live application you are testing?
- Access details: Are any required credentials correct and still valid?
- Network path: Can the Engine host reach the source on the required route and port?
- Playback request: Have you tested with a player using the right application and stream name?
If ingest works but viewer playback does not, do not keep changing the source type at random. Separate the incoming-source check from the application playback check and the final delivery path. A camera feed reaching Wowza is not proof that a downstream YouTube encoder or broadcast is configured correctly. For a prerecorded continuous YouTube workflow, the choices and limits differ; see the discussion of Wowza Streaming Cloud versus OBS for looping videos.
When documenting a failure, record the source family, non-secret URI structure, MediaCaster type, application name and the stage where it stops. That information is more useful than reporting only “stream not working”, and it avoids sharing credentials. Change one relevant setting at a time so that a successful connection tells you what resolved the issue.
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
Is a .stream file the live stream?
No. It is a named reference to the source URI, while the live feed comes from the upstream device or service. MediaCaster uses the file as part of connecting that source to an application.
Which MediaCaster type should I use?
Match it to the source protocol and mode shown in Wowza's current guide. For example, the guide maps SHOUTcast or Icecast to shoutcast, SRT to srt, and RTMP or WOWZ pulled from another Wowza Streaming Engine instance to liverepeater.
Why does a stream file appear idle before a viewer connects?
The documented workflow is on demand: a player request makes the referenced source available. If it remains unavailable after a request, verify the URI, application association, source availability, network path and MediaCaster selection.
Can I use Wowza Video's SRT URL in Streaming Engine?
Do not assume so. Wowza Video and self-hosted Streaming Engine have separate instructions; use the current Engine documentation for its .stream URI and confirm addressing, port reachability and source-side mode for your deployment.