SRT video streaming: how it works over bad networks
SRT video streaming is a way to send live video over real networks where packet loss, jitter, changing bandwidth, and long-distance routes can affect the stream.
SRT means Secure Reliable Transport. It is commonly used for live video contribution: sending a feed from a camera, encoder, remote venue, mobile device, studio, or cloud server into a controlled production workflow.
The main value of SRT is not magic “perfect quality.” The value is control. SRT gives live teams a better way to handle unstable networks through packet recovery, encryption, latency tuning, and runtime statistics.
A practical SRT workflow often looks like this:
camera or encoder → SRT stream → SRT server → recording / transcoding / restreaming / playback workflow
What is SRT video streaming?
SRT video streaming means transporting encoded live video and audio over the SRT protocol.
SRT is usually used on the contribution side of a workflow. That means it helps move the live signal from the source to the platform that will process it.
Examples:
- a remote camera sends SRT to a cloud server
- OBS sends an SRT stream to Callaba
- vMix sends a program output over SRT
- a mobile phone sends SRT from Larix to a production system
- a venue sends a contribution feed to a studio
- one cloud server relays an SRT stream to another workflow
SRT is not usually the final viewer format in a browser. After the SRT stream arrives at the server, it is often converted or packaged into HLS, WebRTC, RTMP, DASH, or another output format.
What is the SRT streaming protocol?
The SRT streaming protocol is a UDP-based transport protocol for live audio and video. It adds features that raw UDP does not provide, including packet recovery, encryption, latency control, and connection statistics.
SRT is useful when the network path is not perfect but the stream still needs to stay usable in real time.
In simple terms:
- UDP gives SRT a real-time transport base.
- Packet recovery helps recover missing packets when there is still enough time to use them.
- Latency settings define how much recovery time the receiver has.
- Encryption can protect the stream between endpoints.
- Statistics help operators see bitrate, RTT, packet loss, retransmissions, and connection state.
This is why SRT is popular for contribution workflows over public internet, remote production links, venue networks, and mobile contribution paths.
See live SRT stats as a moving chart
This demo shows the kind of live statistics you can watch during a real contribution: bitrate, buffer delay, packet flow, receive capacity, and active streams. It is connected to the public demo endpoint at demo.callaba.io and updates from the same live event stream used by the product.
The live widget above focuses on two signals that matter in real SRT workflows: incoming bitrate and network RTT. Bitrate tells you whether media is still flowing. RTT shows timing pressure on the path. If RTT rises while the stream keeps pushing the same bitrate, your current latency setting may become too aggressive.
SRT networking: why packet loss, RTT, and jitter matter
SRT does not remove network problems. It gives the stream a better chance to survive them.
For SRT networking, these signals matter most:
- Packet loss: missing packets that may need retransmission.
- RTT: round-trip time between sender and receiver.
- Jitter: variation in packet timing.
- Latency: the recovery window available before packets become too late to use.
- Bitrate: the amount of media data the network must carry.
- Retransmissions: how often SRT has to recover missing data.
If the stream bitrate is too high for the uplink, SRT cannot fix that. If latency is set too low for the real RTT and jitter, SRT may not have enough time to recover lost packets. If the path has severe packet loss, the video may still break up.
The practical rule is simple: SRT works best when bitrate, latency, and network capacity are tuned together.
Does SRT give the best video quality over bad networks?
SRT can help keep better video quality over bad networks, but it does not guarantee perfect quality.
Video quality depends on the whole chain:
- camera or source quality
- encoder settings
- video codec
- bitrate
- resolution and frame rate
- keyframe interval
- network upload capacity
- SRT latency
- server performance
- downstream transcoding and playback
SRT helps on the transport layer. It can recover from packet loss when the latency window is large enough. It can encrypt the stream. It can expose useful statistics. But it cannot turn an overloaded network into a clean path, and it cannot fix a bad encoder setup.
How SRT keeps live video more stable
SRT improves live video transport in several practical ways.
Packet recovery
If packets are lost or delayed, SRT can request retransmission. This helps when the loss is moderate and the latency window gives the receiver enough time to use the recovered packets.
Latency tuning
SRT lets you choose a latency value. Lower latency gives less delay but less recovery time. Higher latency gives SRT more room to recover packets, but it adds delay to the live path.
The best latency is not always the lowest value. The best latency is the value that keeps the feed stable on the real network path.
Encryption
SRT can encrypt the stream between endpoints. This is useful when contribution crosses public or shared networks.
Encryption is important, but it is not the whole security model. You still need access control, firewall rules, credential management, and clear ownership of endpoints.
Live statistics
SRT gives operators transport-level signals. These signals help explain whether a problem comes from the sender, the network, the SRT path, or the downstream workflow.
Useful SRT statistics include bitrate, RTT, packet loss, retransmissions, connection state, and buffer behavior.
SRT is not a codec
SRT is often confused with encoding. This is a common mistake.
SRT is transport. It carries an already encoded stream over the network.
Codecs compress the video and audio. Examples include H.264, H.265/HEVC, AAC, and other media formats.
For example, you can encode video as H.264, encode audio as AAC, and send that stream over SRT to Callaba.
So when people say “SRT video,” they usually mean video transported over SRT, not video encoded by SRT.
SRT video vs RTMP video
SRT and RTMP are both used in live streaming, but they are usually better for different parts of the workflow.
- SRT is usually better for contribution over unstable, long-distance, or public internet paths.
- RTMP is still common for simple publishing and compatibility with many social platforms and legacy ingest systems.
A common workflow is:
SRT for contribution → server processing → RTMP or RTMPS for social platform delivery
For example, OBS, vMix, Larix, or an encoder can send SRT to Callaba. Then Callaba can restream the signal to Twitch, YouTube, Facebook, or another RTMP/RTMPS destination.
If you need a deeper comparison, read SRT vs RTMP.
When should you use SRT video streaming?
Use SRT when the contribution path matters and you control the receiving side.
SRT is a strong fit for:
- remote production
- field contribution
- venue-to-cloud streaming
- studio-to-cloud transport
- mobile contribution
- backup live feeds
- long-distance contribution paths
- partner feed handoff
- cloud ingest workflows
SRT is less useful when the destination only accepts RTMP, when you do not control the receiving side, or when the workflow only needs simple platform publishing.
When SRT is not enough
SRT is useful, but it is not the full streaming system.
SRT does not automatically:
- create a web player
- record the stream
- transcode the video
- create adaptive bitrate playback
- deliver video to thousands of viewers
- fix a bitrate that is too high for the network
- make bad audio or video settings correct
That is why production teams usually place SRT inside a larger workflow. SRT brings the feed into the system. Then the server handles recording, transcoding, routing, packaging, restreaming, or playback.
How Callaba uses SRT video streams
Callaba uses SRT as an ingest and routing layer for live video workflows.
Common Callaba workflows include:
- receive an SRT stream from OBS
- receive an SRT stream from vMix
- receive a mobile SRT stream from Larix
- record an incoming SRT stream
- restream SRT input to RTMP destinations
- route SRT streams between servers
- convert SRT contribution into browser playback workflows
- monitor SRT bitrate, RTT, loss, and connection status
This makes Callaba useful when you want SRT to be part of a controlled production workflow, not just a point-to-point test.
Best practices for SRT video quality
To keep SRT video stable, tune the whole path, not only the protocol setting.
- Choose a realistic bitrate. Leave upload headroom for retransmissions and network variation.
- Use a practical resolution. Do not force 1080p or 4K if the network cannot hold it.
- Set latency based on the real path. Mobile networks and long-distance routes usually need more buffer.
- Watch RTT and retransmissions. Rising RTT and retransmissions usually mean the path is under pressure.
- Check audio and video separately. A connected SRT session does not guarantee valid media.
- Test before the event. A clean office test does not prove that a venue or mobile network will behave the same way.
- Keep a backup path. Important events should not depend on one encoder, one uplink, or one region.
What to monitor during SRT streaming
Monitor both transport health and media health.
Transport health
- connection state
- incoming bitrate
- RTT
- packet loss
- retransmissions
- jitter
- latency
- buffer pressure
Media health
- black video
- frozen video
- missing audio
- silent audio
- wrong codec
- bad timestamps
- wrong resolution or frame rate
- downstream playback errors
This matters because an SRT session can be connected while the actual video or audio payload is still wrong.
Common SRT streaming problems
The SRT stream connects but video breaks up
Check packet loss, RTT, retransmissions, latency, and bitrate. The bitrate may be too high, the latency may be too low, or the network may not have enough headroom.
The stream has video but no audio
Check the encoder audio source, microphone permissions, audio codec, mute state, and downstream audio routing. SRT can carry audio, but it cannot fix audio that was never sent correctly.
The stream works for a while, then fails
This often happens on mobile networks, Wi-Fi, venue internet, or oversubscribed uplinks. Lower bitrate, increase latency, check packet loss, and watch whether RTT changes during the stream.
The SRT stats look good but viewers still have issues
If SRT ingest is stable, check the downstream chain: transcoder, recording, packaging, origin, CDN, player, or RTMP output.
FAQ
What is SRT video?
SRT video usually means live video transported over the SRT protocol. SRT carries encoded video and audio across the network. It is not a video codec by itself.
What is SRT video streaming?
SRT video streaming is live video transport over Secure Reliable Transport. It is commonly used for contribution workflows where a live feed must travel over public internet, mobile networks, venue networks, or long-distance paths.
Is SRT a streaming protocol?
Yes. SRT is a streaming transport protocol. It is used to move live video and audio between encoders, servers, gateways, production tools, and cloud workflows.
Does SRT improve video quality?
SRT can help preserve video quality on unstable networks by recovering packets when there is enough latency budget. It does not guarantee perfect quality. Bitrate, codec, network capacity, latency, encoder settings, and downstream processing still matter.
Does SRT remove packet loss?
No. SRT does not remove packet loss from the network. It can recover from some packet loss through retransmission if the latency window gives enough time for recovery.
Is SRT better than RTMP for video streaming?
SRT is usually better for contribution over unstable or long-distance networks. RTMP is still common for simple publishing and compatibility with social platforms. Many workflows use SRT for ingest and RTMP or RTMPS for final platform delivery.
Can SRT stream audio and video?
Yes. SRT can carry streams that include audio and video. If audio is missing, check the encoder, audio source, audio codec, and receiving workflow.
Does SRT use UDP?
Yes. SRT runs over UDP and adds recovery, encryption, timing control, and statistics on top. Because SRT uses UDP, the correct UDP ports must be open between sender and receiver.
Can browsers play SRT directly?
In normal web workflows, browsers do not play SRT directly. An SRT server receives the stream first, and then the platform converts or packages it into HLS, WebRTC, or another viewer format.
What latency should I use for SRT streaming?
Use a latency value that matches the real network path. Lower latency gives less delay but less recovery time. Unstable mobile networks, Wi-Fi, and long-distance routes usually need more latency than clean local networks.