What is SRT protocol? Secure Reliable Transport for live video

Quick answer: what is SRT protocol?

Key benefits of SRT

Why SRT became important in live video

SRT became important because it solved a real production problem: how to move live video over the public internet with better reliability, security, and timing control than older transport choices could provide.

The protocol was originally developed by Haivision and later made available as open-source technology. Haivision opened SRT at the 2017 NAB Show and formed the SRT Alliance to support broad adoption and collaborative development.

SRT also received strong industry recognition. Haivision received a Technology & Engineering Emmy Award for SRT, recognized for pioneering reliable transmission methods for live contribution and distribution TV links.

The ecosystem around SRT is now large. The SRT Alliance states that more than 700 broadcasters, cloud platforms, device manufacturers, and streaming providers rely on SRT for secure, low-latency video transport. Haivision has also listed major ecosystem names including AWS, Cloudflare, Google Cloud, Microsoft, NVIDIA, Paramount, SK Telecom, Sony, and YouTube among SRT Alliance participants.

Adoption data points in the same direction. Haivision’s 2025 Broadcast Transformation Report reported that SRT usage grew from 68% in 2024 to 77% in 2025, making it the most widely used transport protocol among that year’s respondents.

Industry signal: SRT has moved from “interesting open-source protocol” to a practical default for many live contribution workflows where reliability, security, and low latency matter at the same time.

“A pressing demand for efficient remote communication, content production, and distance learning.”

Bruce Tanaka, Sony Imaging Products & Solutions, on joining the SRT Alliance.

What SRT actually does

SRT transports already encoded media between endpoints. It is not a video codec, not a player format, and not a full streaming platform by itself. It is the transport layer that helps move a live signal from one place to another with more control than raw UDP and often more resilience than older live contribution workflows.

A practical SRT workflow often looks like this:

SRT is most useful at the contribution and transport stage. After the SRT feed reaches the server, the workflow usually continues into recording, routing, transcoding, RTMP/RTMPS restreaming, HLS packaging, WebRTC playback, or another delivery layer.

What SRT helps with

• Packet loss recovery: SRT can request missing packets again if there is enough time to use them.
• Jitter tolerance: SRT gives the receiver a controlled timing buffer instead of assuming every packet arrives exactly on time.
• Latency tuning: operators can choose how much delay to allow for recovery.
• Encryption: SRT supports encrypted transport between endpoints.
• Runtime statistics: SRT exposes useful signals such as RTT, packet loss, retransmissions, bitrate, and connection state.
• Firewall-friendly connection modes: caller, listener, and rendezvous modes help adapt to different network environments.

What SRT does not do by itself

• It does not encode the video.
• It does not create a browser player by itself.
• It does not automatically create adaptive bitrate playback.
• It does not replace HLS or WebRTC for viewer delivery.
• It does not fix an overloaded uplink, wrong bitrate, bad timestamps, or broken encoder setup.

How SRT works

SRT runs over UDP. UDP gives the protocol a real-time transport base, but raw UDP alone does not provide reliable delivery. SRT adds reliability and control mechanisms on top.

When packets arrive late or go missing, SRT can request retransmission. The receiver can still use the recovered packet only if it arrives inside the configured latency window. This is why latency tuning is central to SRT. The protocol needs enough time to recover from network problems, but too much latency may be unacceptable for the workflow.

That is the core tradeoff:

• Lower latency: faster interaction and lower delay, but less room for packet recovery.
• Higher latency: more resilience against packet loss and jitter, but more delay in the contribution path.

For real production use, SRT should be tuned against measured RTT, packet loss, jitter, bitrate, and the actual stability of the route. Guessing a low number because it looks good in a settings panel is one of the fastest ways to make SRT unstable.

Caller, listener, and rendezvous modes

SRT has three practical connection modes. This is not just protocol trivia. The mode determines whether the connection can work through firewalls, NAT, venue networks, and cloud security rules.

The safest production pattern is usually simple: make the controlled cloud or data center endpoint the listener, and make the remote encoder or production tool the caller. Use rendezvous only when the network environment forces it and you have tested the exact path before the event.

SRT latency, RTT, and packet recovery

SRT latency is not the same thing as total live streaming latency. SRT latency is the transport recovery budget. Total latency also includes encoding, buffering, decoding, playback, and delivery format behavior.

Simple latency rule

If RTT rises, jitter increases, or packet loss appears in bursts, an SRT latency value that used to be safe can become too aggressive. The result often looks like random video breakup, short freezes, retransmission spikes, or periodic instability.

Practical tuning model

1. Measure RTT on the real path.
2. Watch packet loss and retransmissions during real traffic, not just an empty test.
3. Set latency high enough for recovery under the actual route conditions.
4. Lower latency gradually only after stability is proven.
5. Keep a fallback setting for venues, Wi-Fi, cellular, or long-distance paths.

The right SRT latency is not the lowest possible value. The right value is the lowest value that still gives the stream enough recovery room on the real network.

SRT vs RTMP, WebRTC, HLS, UDP, and RIST

SRT is often compared with other protocols, but the cleanest comparison is by job.

A common production pattern is:

That pattern keeps SRT where it is strongest: controlled transport into the system.

When should you use SRT?

Use SRT when the contribution path matters and you control the receiving side.

SRT is a strong fit for:

• remote production,
• venue-to-cloud streaming,
• studio-to-cloud contribution,
• OBS or vMix contribution to a cloud server,
• mobile contribution from field teams,
• backup contribution feeds,
• partner feed handoff,
• long-distance contribution paths,
• server-to-server stream routing,
• live event workflows that need monitoring and recovery controls.

The key condition is control. SRT works best when you can configure both the sender and the receiver, choose connection mode, open UDP ports, tune latency, and inspect statistics during the event.

When SRT is not enough

SRT is useful, but it is not the full streaming system.

SRT does not automatically:

• make the video playable in a browser,
• create a web player,
• transcode the input into multiple qualities,
• record the stream,
• package the stream into HLS or DASH,
• deliver video to thousands of viewers,
• fix wrong bitrate, bad encoder settings, or overloaded CPU,
• solve downstream CDN or player problems.

This is why production teams usually place SRT inside a larger workflow. SRT brings the live feed into a controlled system. The platform then handles routing, recording, transcoding, restreaming, playback, or distribution.

What to monitor in SRT

A connected SRT session is not the same thing as a healthy stream. You need to monitor both transport health and media health.

Transport signals

• Incoming bitrate: confirms whether media is still arriving.
• RTT: shows timing pressure on the path.
• Packet loss: shows how much the path is damaging the stream.
• Retransmissions: shows how much recovery work SRT is doing.
• Jitter: shows packet timing variation.
• Connection state: connected, reconnecting, disconnected, failed.
• Receiver buffer pressure: shows whether the stream is close to instability.

Media signals

• black video,
• frozen video,
• missing audio,
• silent audio,
• wrong codec,
• bad timestamps,
• wrong resolution or frame rate,
• downstream playback errors.

This distinction matters because SRT can transport a technically connected stream while the media payload is still wrong for the next stage.

Production gotchas teams miss with SRT

UDP buffer limits can break a good SRT configuration

One practical problem is Linux UDP buffer limits. Your SRT configuration may request a large receive buffer, but the kernel can silently cap the effective socket buffer if net.core.rmem_max and net.core.wmem_max are too low. Under bursty traffic, this can cause UDP packet drops before SRT even has a fair chance to recover.

For production ingest servers, check and tune the operating system limits instead of only tuning the SRT application settings.

sysctl net.core.rmem_max
sysctl net.core.wmem_max

sudo sysctl -w net.core.rmem_max=67108864
sudo sysctl -w net.core.wmem_max=67108864

Permanent configuration should go into a sysctl file managed by your deployment process. This is especially important for high-bitrate streams, multi-feed ingest, bursty encoders, and cloud instances receiving several SRT sessions at the same time.

Stream ID should be standardized

SRT Stream ID is useful for routing, tenant separation, and feed identification. But free-form stream IDs become hard to operate. Use a predictable format, log it on connection, and keep it tied to the correct feed or customer workflow.

Encryption is not the whole security model

SRT encryption protects transport between endpoints, but it does not replace access control, firewall policy, credential rotation, source allowlists, or user-level authorization in the application layer.

Common SRT problems and fixes

The SRT connection does not start

Likely causes: wrong caller/listener mode, blocked UDP port, wrong host, wrong port, passphrase mismatch, stream ID mismatch, firewall or cloud security group problem.

Fast checks: confirm mode on both sides, verify public IP and UDP port, check cloud security group rules, confirm encryption settings, and test from the real sender network.

The stream connects but video breaks up

Likely causes: latency too low, packet loss bursts, jitter, overloaded uplink, bitrate too high, CPU or NIC pressure, insufficient UDP buffers.

Fast checks: compare RTT during good and bad periods, watch retransmissions, lower bitrate, increase SRT latency, and inspect server packet drops.

The SRT stats look good but viewers still have issues

If SRT ingest is stable, move downstream. The problem may be transcoding, recording, HLS packaging, CDN, player behavior, or platform restreaming.

The stream has video but no audio

SRT can carry audio, but it cannot fix audio that was never sent correctly. Check encoder audio source, audio codec, mute state, channel mapping, and downstream audio routing.

The stream works in a test but fails during the event

Short tests often miss real congestion, venue traffic, cellular instability, or bitrate peaks. Rehearse with real duration, real overlays, real audio, real network path, and realistic event load.

Where Callaba fits in SRT workflows

Callaba uses SRT as an ingest and routing layer for live video workflows. The goal is not just to accept an SRT connection. The goal is to turn that incoming feed into something operators can route, monitor, record, restream, and deliver.

Common Callaba workflows include:

• receive SRT from OBS, vMix, hardware encoders, mobile apps, or remote locations,
• create controlled SRT ingest endpoints,
• route one SRT input to many outputs,
• record incoming SRT streams,
• restream SRT input to RTMP/RTMPS destinations,
• create browser playback from a live input,
• monitor bitrate, RTT, packet loss, and connection state,
• run the workflow in cloud or self-hosted infrastructure.

If your team needs hands-on setup, continue with these practical guides:

• What is an SRT server?
• How to start SRT streaming in OBS Studio
• How to receive an SRT stream in OBS Studio
• Sending and receiving SRT stream via vMix
• Find the perfect latency for your SRT setup
• Multi-streaming with Callaba
• Video API for live workflows

SRT implementation checklist

1. Define the job. Contribution, remote production, relay, backup feed, recording, or restreaming.
2. Choose connection mode. Usually listener on the controlled ingest side and caller on the sender side.
3. Open the right UDP ports. Check cloud security groups, host firewalls, and upstream network policy.
4. Set stream ID and access rules. Keep names predictable and log them for support.
5. Set encryption if needed. Manage passphrases like production credentials.
6. Tune latency from real measurements. Use RTT, jitter, packet loss, and route stability.
7. Check OS UDP buffers. Make sure the system can actually accept the buffer size your SRT settings request.
8. Monitor transport and media health. A connected session is not enough.
9. Test failover before the event. Do not discover backup behavior during the live window.

Official SRT resources

• SRT Alliance — official ecosystem and adoption resources.
• SRT Alliance members — member directory and ecosystem overview.
• SRT GitHub repository — open-source implementation and releases.
• SRT protocol draft documentation — technical protocol details.
• Haivision SRT guide — official background from the original developer.

FAQ

What does SRT stand for?

SRT stands for Secure Reliable Transport. It is a transport protocol used to send live video and audio across unpredictable networks with packet recovery, encryption, and latency control.

Who created SRT?

SRT was originally developed by Haivision and later released as open-source technology. The SRT Alliance was formed to support adoption and collaborative development across the media industry.

Is SRT a video codec?

No. SRT is not a codec. It transports already encoded media. The video may be encoded with H.264, HEVC, or another codec, but SRT itself is the transport layer.

Does SRT use UDP?

Yes. SRT runs over UDP and adds reliability, timing, encryption, and statistics on top of it.

Is SRT better than RTMP?

SRT is usually better for contribution over unstable or long-distance networks. RTMP is still useful for simple platform publishing and legacy ingest. Many workflows use SRT for contribution and RTMP or RTMPS for final delivery to social platforms.

Can browsers play SRT directly?

In normal web workflows, browsers do not play SRT directly. An SRT server receives the stream first, then the platform converts or packages it into HLS, WebRTC, or another viewer format.

What latency should I use for SRT?

Use a latency value that matches the real network path. Lower latency gives less delay but less recovery time. Mobile networks, Wi-Fi, public internet routes, and long-distance links usually need more latency than clean local networks.

Does SRT remove packet loss?

No. SRT does not remove packet loss from the network. It can recover from some loss through retransmission if the latency window gives enough time for recovery.

Is SRT secure?

SRT supports encrypted transport, including AES-based encryption. But encryption is only one part of security. Production workflows still need firewall rules, access control, credential rotation, and operational logging.

What are SRT caller and listener modes?

Listener waits for inbound connections on a UDP port. Caller initiates the connection to the listener. A common production pattern is cloud ingest as listener and the remote encoder as caller.

When should I not use SRT?

SRT is not the best final viewer format for broad browser playback. It is also less useful when the destination only accepts RTMP or when you cannot control the receiving side.

Final practical rule

Use SRT when you need controlled live contribution over imperfect networks, but treat it as one layer in the workflow. Tune latency from real RTT and packet loss, monitor both transport and media health, check UDP buffer limits on the server, and convert the stream into the right delivery format after ingest.

Need help with SRT contribution?

If you need to receive SRT from OBS, vMix, hardware encoders, mobile apps, remote venues, or partner facilities, Callaba can help you create a controlled SRT ingest workflow with monitoring, routing, recording, restreaming, and browser playback.

Contact Callaba support