8 Common SRT Myths Busted

Since its initial creation and subsequent open source release four years ago, the Secure Reliable Transport (SRT) protocol has been steadily gathering momentum within the broadcast and video streaming industries. Designed to enable secure and reliable transport of data across unpredictable networks, SRT is particularly optimized for live video streaming and is shaping the future when it comes to easing the transition to IP-based solutions. In this post we set out to debunk some of the most common myths that continue to surround SRT. In no particular order, here they are:  

SRT Myth #1: SRT Is Not Widely Adopted

Fact: From broadcast heavyweights Sky News, Fox News and NBC Sports to industry giants such as Sony, AWS, Avid, MediaKind, and Microsoft, SRT is everywhere. Endorsed by growing user and developer communities along with adoption by open source initiatives VLC, GStreamer, Wireshark, and OBS Studio, SRT has become the de facto low latency video streaming standard for the broadcast and streaming industries. There are well over 550 active members (and growing) of the SRT Alliance along with hundreds of SRT–ready solutions – from cameras, encoders and decoders to gateways, OTT transcoding services and CDNs. SRT is currently deployed by thousands of organizations globally in a number of applications and markets. Don’t just take our word for it, read more about how SRT has been making waves in the industry since its public launch at NAB in 2017. 

SRT Myth #2: I Need to Buy a License to Use SRT

Fact: Not to be confused with other expensive and closed proprietary protocols, SRT can be implemented using a free, open source code base, keeping costs low for all parties. There are no royalties, long-term contracts or monthly subscription fees required. Being open source encourages SRT’s widespread adoption and helps to ensure both interoperability and longevity for end users while avoiding vendor “lock-in”. It’s collaboration at its finest. 

SRT Myth #3: SRT Doesn’t Support All Video Codecs

Fact: Unlike some other protocols that only support specific video and audio formats, SRT does not limit you to a specific container or codec, since it is media or content agnostic. SRT operates at the network transport level, acting as a wrapper around your content. This means it can transport any type of codec, resolution or frame rate. This is important because it can future proof workflows by working transparently with MPEG-2, H.264, and HEVC for example. 

SRT Myth #4: SRT Can’t Stream 4K Video Over the Internet

Fact: See myth #3. SRT is content agnostic and can fully support 4K UHD and HD video, in standard or high dynamic range color. For example, Haivision’s Makito X4 video encoder designed for ultra-low latency 4K and HD video (in SDR or HDR color) includes native support for the SRT protocol. This makes it ideal for streaming over unpredictable networks such as the public internet. With built-in AES 128/256-bit encryption, SRT allows Maktio X4 users to keep their valuable 4k content safe and secure.                   

SRT Myth #5: SRT Can Only Be Used Over the Internet

Fact: While it’s true that SRT was originally designed to address the main challenges of streaming video content over the internet, once it was open sourced, developers began implementing SRT on their own hardware and software stacks for all types of networks. Beyond the public internet, SRT can also be used over managed networks such as MPLS as well as satellite, SD-WANs and cellular networks. You can read more about just how versatile SRT is in this blog post: Using SRT to Live Stream Over the Internet and Other Networks. 

SRT Myth #6: SRT Isn’t Interoperable With RTP

Fact: SRT allows you to transmit RTP payload reliably and securely, so you can absolutely leverage SRT while maintaining your existing RTP-based broadcast infrastructure. 

SRT Myth #7: SRT Only Supports up to 30 MBit/s Bitrates

Fact: Since SRT version (1.3.3) the default max bitrate limit value has been set to 1 gigabit per second. This is a default setting to prevent an SRT stream from congesting an IP network. Though it could be set to an even higher value, typically users will lower the max bitrate to amount equivalent to double the bitrate of the SRT stream. For example, if the SRT stream is transporting HD content at 10 Mbps, the max bitrate might be set to 20 Mbps. For lightly compressed primary contribution content or 4K video at 50 Mbps, the max bitrate can be 100 Mbps, while for highly compressed streams over a bandwidth constrained network, the max bitrate should be set much lower. 

SRT Myth #8: SRT Does Not Perform Well at Higher Packet Loss Rates

Fact: In order to accommodate different packet loss scenarios, SRT includes bandwidth overhead and latency buffer settings. Bandwidth overhead is the extra bandwidth needed to resend packets in the event of packet loss. The latency buffer can also be adjusted for packet loss by taking into account the total round-trip time (RTT) of the network connection as well as the amount of packet loss present at a given time. 

When streaming over a network connection with low packet loss and a short RTT, the SRT latency buffer setting should be kept as low as possible with the bandwidth header used for packet retransmission. If packet loss is high, at 30% for example, then the bandwidth overhead should be lowered to prevent congestion and the latency buffer increased for more robust packet loss recovery. By correctly adjusting the bandwidth overhead and latency buffer settings, SRT can reliably stream even over networks with extreme levels of packet loss.