What are the benefits and drawbacks of using SRT for low latency live streaming?

SRT is designed for one specific reason. Transport video over a lossy network (like the internet) without losing quality. It does this by setting a buffer and retransmitting and part of the video that does not make it to the receiver in time. The way SRT handles this retransmission is what makes it work. Also, being open source has sped up it's adoption.

SRT also contains 2 other features that can really help. Socket Groups, or what Haivision released as Path Redundancy, allows you to create multiple network paths to achieve hitless failover in your connections. SRT also supports StreamID, a method that enables multiple sources to hit a common destination with a single port/IP. Thanks Anthony for pointing out the very well used caller/listener. Haivision is very proud of bringing SRT to the market and appreciate your comments and experiences.

One aspect of SRT is the Caller and listener modes of SRT, This means that you can try and get through firewalls. If you were to fire UDP video data at a firewall it would just block it. But with SRT you can call out, Like you would to a website address to create that link of asking for data at the Listener's side and allow that video data back. Thus creating the link through the firewall. For this to work the listener side would need to either be on a public IP address or have port forwarding on. Perfect to have your equipment back at base on listener mode and your encoders and decoders on listener mode out in the field.

Not much talked about here, is that we can also embed live captions into SRT streams, and they play beautifully in a player. We were also able to include dubbed audio (AI generated) into live SRT. Really happy with the low latency and stability of SRT. We hope this will speed up the global adoption of SRT. Thanks Haivision to bring SRT to the industry. Game-changer.

Greetings does anypne has a tip for an 4K stream SRT PTZ zoom camera, at least 30fps. Better if weatherproof to use outside (local temp from 5C to 45C).

Some 650 manufacturers are now members of the SRT alliance, this means that you can encode using Haivision encoders but send it to so many different equipment, Like GV Amp or Grabyo for live production. Avid for editing or maybe direct to Youtube. The other protocols do not have such a huge amount of interoperability.

Besonders weil es Open-Source ermöglicht SRT nun auch gute Übertragungen bezahlbar zu machen. So gibt es bereits sehr gute Encoder & Decoder unter 1000$.

Greetings, when mentioned 100Ms end to end, tou mean from ingestion to user end distribution? I runned tests via 5G and ingested avarage 725ms, but on CDN distribution it was higher. Can any one give me an advice for a ISP, better if MS Azure service

SRT can achieve end-to-end latency as low as 20 milliseconds, but this is dependent on the round-trip time (RTT). The SRT latency should typically be set at least 3 to 4 times higher than the RTT to allow for retransmissions within the required time. A major advantage of SRT is its content-agnostic nature, allowing free choice of audio and video codecs. The protocol does not limit the video resolution or number of audio channels.

SRT cannot be used by the end user in most cases, and doesn’t play natively in a web browser. It also needs to be configured manually for maximum performance. SRT is meant for point to point connections, another not for mass distribution to a large audience of concurrent viewers. SRT can be combined with other protocol for a robust delivery system.

You are correct, SRT was not designed for broad scale distribution like HLS, DASH, etc. But if you want to serve power users that need the highest quality and lowest latency it's prefect. Often broadcasters will combine a Haivision SRT Gateway in the cloud (PAYG on AWS, or other) with the Play Pro mobile app for internal and return feeds. To Anthony's point, the gateway can be set up as a "listener" and serve many viewer "callers".

You should consider the use case and kind of application you want to achieve. SRT is an open protocol for professional grade broadcast/streaming originally for Haivision products, more and more available on software products like OBS. Point to point with dedicated equipment or one-to-many as a contribution (ingest) protocol like in nanoStream Cloud. Delivery/distribution for one-to-many is then usually done with other protocols available in browsers such as HLS, DASH, H5Live, and WebRTC (which was designed as a browser based communication system covering a lot complexity under the hood). In stable networks, even TCP based ingest with RTMP still works well. For unstable or remote networks, UDP protocols like SRT work better.

SRT is not directly usable in web browsers, because modern web browsers limit UDP communication to WebRTC/RTP traffic. Workarounds however are possible.

Never have seen SRT used for end user consumption. Its used for back-haul contribution streams to a core video switching studio. The SRT protocol and supporting solutions allow a producer to send an outbound stream to a cloud handshake with a receiving decoder that has reached out to the cloud service also. This lets a producer easily send large high bit-rate low latency contribution streams across enterprise security firewalls in an appropriate fashion without IT getting involved. This is an important feature. We use SRT regularly on global hybrid events with executives streaming in from remote enterprise studios around the globe.

I think SRT is actually fantastic. Aside from its Forward error correction, and connection modes it creates a high quality reliable connection. These are all qualities that NDI lack, and even SRT has its place for routing and play out on local networks. HLS and others are HTTP based and thus have advantages that allow them to be routed and load balanced at scale more efficiently. For most people though this benefit isn’t important unless you have tremendous scale. WHIP and RIST are a bit more interesting as they try to blend transport reliability and routability of both HLS/HTTP and SRT. Their adoption right now is still too low so it’s too early to tell. WebRTC will always be there and for distribution, but not broadcast backhaul.

Je nachdem, wofür man Streamingprotokolle braucht gibt es viele Alternativen. Wenn man jedoch die Idee und Nutzung von Latenz, Qualität, Verlässlichkeit über ein öffentliches Netz einschränkt, dann gibt es hier primär nur noch die proprietären Alternativen: Zixi und LRT (LiveU) Dabei sind die offensichtlichen Vorteile von SRT klar, dass es offen ist und daher eine viel breitere Unterstützung bietet. Wenn man die Nutzung auf internes Netzwerk einschränkt, da gibt es z.B: NDI. (Theoretisch & Praktisch funktioniert NDI auch übers Internet, jedoch mit Vorsicht!)

If you're operating in a local network, or you have a stable connection between multiple sites, you could try to use Network Device Interface (NDI) as an alternative to SRT. Many devices that support SRT also support NDI, which is used in a lot of live broadcast and event productions. While older, RTMP and RTSP have been around for a long time and are supported by a lot of services. Those tend to have more delay and limitations than SRT.

In terms of price a WebRTC 4K enconder compair with an SRT, has higher cost and fewer options? Can you please point me a some options?

Reliable Internet Stream Transport (RIST) is covering a lot of comparable use case, but also provides compatibility with ST2110 and allows secure tunneling of traffic.

Another aspect of choosing the right protocol for low-latency live streaming is scalability. SRT is perfect for both point-to-point and multi-point scenarios. If you want to serve thousands or even millions of concurrent viewers, MPEG-DASH, LL-HLS, or WebRTC are better choices.

SRT allows for flexible connection setup. In Listener mode, SRT waits for a call on a UDP port from the opposite side acting as a Caller. The stream direction is irrelevant; a sender can function as either Caller or Listener, provided the receiver is configured oppositely. Listeners should enable port opening in the firewall, which is beneficial when the stream origin and destination are uncertain. Only the 'caller' requires knowledge of the address and port. What if something goes wrong? SRT offers a comprehensive range of real-time statistics, allowing operators to quickly diagnose connection issues. This can even be used to control the encoder's bitrate, as Haivision does with Network Adaptive Encoding.

At our cloud gaming platform, Arium, we initially used RTSP for real-time streaming based on TCP/UDP. However, we experienced significant screen tearing on high latency P2P connections, around 170ms. Consequently, we started migrating to SRT. Although we still use WebRTC for web browses, SRT has replaced RTSP for native clients. SRT has provided excellent video quality, eliminated screen tearing, and its forward error correction has been very beneficial. Additionally, it can achieve end-to-end latency as low as 20 milliseconds, which is perfect. On Arium, while users are playing game on the cloud, they can broadcast/record their gaming experience from the backend. This capability allowed us to successfully replace RTMP with SRT as well.