To watch an SRT stream, check the connection and the media
Use a native player when you need to see the contribution feed itself. Use browser playback only after the feed has been made into a browser-compatible output. In either case, a successful SRT connection and a playable picture are separate results: mode, host, UDP port, latency, Stream ID and passphrase open the session; the container, tracks, timestamps and codecs decide whether it decodes.
If the job is to create, protect or operate the receiving endpoint, go to Callaba SRT Server. This guide starts at the receiver.
Live SRT player demo
Test an SRT player connection
Create a temporary connection for one hour. Send an SRT stream to the publisher address in Caller mode, leaving Stream ID empty. After the publisher connects, watch it in Multiview below or connect a native player to the receiver address in Caller mode.
Pick the player that matches the task
ffplay is a quick command-line check when the installed FFmpeg build includes SRT. OBS Media Source is useful when you want a graphical preview and can set its SRT input details. VLC may be useful for a local view when the installed version supports the required SRT mode; check the application’s current documentation and test the exact build. None of those choices makes an unknown payload decodable.
The demo above creates a one-hour Callaba SRT pair. After an incoming publisher connects, it creates a Multiview preview. Use the supplied values to test the pair and inspect the resulting picture and audio. It is a real, temporary Callaba path, not a player for arbitrary external SRT URLs.
Try ffplay first
For a receiver calling a known listener, replace the placeholders with an endpoint you are allowed to use:
ffplay "srt://LISTENER_HOST:PORT?mode=caller"For a receiver waiting for a caller:
ffplay "srt://0.0.0.0:PORT?mode=listener"Do not paste a passphrase into tickets, chat or a shell history you do not control. FFmpeg documents its SRT URL options; OBS documents its SRT input workflow.
Match Caller and Listener before changing player settings
The common arrangement is simple: a Listener waits on a UDP port and a Caller connects to its reachable address. Write both roles down, verify the host and port from the sender network, then start the player. Two listeners wait; a Caller aimed at an unreachable address will not be fixed by a codec setting. Rendezvous is a separate configuration that both endpoints must support.
When encryption is enabled, use the same passphrase and compatible key settings at both ends. If a service uses a Stream ID to select a stream, preserve its syntax and escaping. Treat both as connection data: keep secrets out of screenshots and reports, and compare a denied session with the available endpoint logs.
Set latency for recovery, not appearance
SRT latency gives late packets and retransmissions time to arrive. It is not the whole glass-to-glass delay; encoding, decoder buffers, packaging and viewer buffers add their own delay. Start with the measured route, then compare clean and impaired conditions while watching loss, retransmissions, drops and decoded continuity.
In FFmpeg-style SRT URLs, latency=200000 means 200 ms because the value is in microseconds. It is only an example. Record the effective value at both endpoints and tune for the actual contribution path.
Probe the stream when it connects but will not play
SRT carries packets, not a promise about the video codec, audio codec or container. MPEG-TS is common for contribution, but it still needs valid programme information, timestamps and streams the chosen player can decode. Probe the same endpoint before changing latency again:
ffprobe -v error -show_format -show_streams "srt://LISTENER_HOST:PORT?mode=caller"Look for the container, video and audio codecs, profiles, tracks and timestamps. Compare those facts with the player’s documented support.
If bitrate is present but the screen is black
| What you see | Check next |
|---|---|
| No connection | Roles, reachable host, UDP port, firewall and access data. |
| Connected, no picture or audio | Run the probe; check programme information, codecs, tracks and timestamps. |
| Picture breaks under loss | Compare route measurements and recovery latency before changing the player. |
That separation prevents a payload problem from becoming an endless sequence of connection changes.
Use native SRT for contribution; use a browser output for viewers
Standard browser media elements do not natively open an srt:// URL. Receive the contribution first, then publish a browser-compatible output and test it on the device and network that will view it. Use Multiview for an operator’s shared confidence view and Web Player for browser delivery.
Keep a short receiver check
- Record the endpoint roles, host, port, latency, Stream ID policy and encryption state.
- Confirm the real sender network can reach the receiver.
- Check transport during a clean interval and the impaired condition that matters for the event.
- Confirm a decoded picture and programme audio on the intended player.
- Restart one side in a planned test and check the final operator or viewer surface again.
For protocol detail, see the SRT live-transmit documentation and the Callaba SRT protocol guide.
SRT player FAQ
Can a browser play an SRT URL directly?
Not through the standard HTML media element. Receive SRT first and publish a browser-compatible output.
Why can an SRT connection show bitrate without video?
The session may work while the player cannot decode the container, tracks, timestamps or codec profile.
Should the player use Caller or Listener mode?
Use the role that complements the agreed peer and its network reachability.
Does more SRT latency always fix packet loss?
No. It gives retransmissions more time, but it cannot open blocked UDP, repair sustained capacity loss or decode an unsupported payload.
