Today’s Alternatives to RTMP for Getting Your Streams to the Internet
We all know that Flash is virtually dead for stream distribution to desktop players, however, RTMP, the basis of video distribution for Flash, still remains very much in use for stream delivery to the cloud.
Let’s take a look at some of the challenges that RTMP presents for contribution streaming in “the first mile” – getting your stream from the live event to the cloud where they will then be distributed via CDN – and a few alternative protocols you should consider.
Let’s face it, RTMP isn’t scaling towards today’s challenges for contribution and here’s why you should consider different alternatives:
- Support for RTMP is waning, and CDNs like Akamai are decommissioning RTMP entry points in favour of HLS and MPEG-DASH.
- RTMP does not support HEVC encoded streams.
- RTMP does not elegantly support advanced resolutions, in part due to lack of HEVC support but also because RTMP cannot be used at high bitrates due to bandwidth limitations.
- RTMP has historically been difficult to provision through firewalls.
- RTMP has historically had issues with security, multiple language support, and ad insertion support.
If RTMP has so many challenges, what alternative protocol can you use to get your streams to your CDN? Your choice is really now between HTTP based protocols such as HTTP Live Streaming (HLS) or MPEG-DASH or using the open source SRT protocol (originally developed by Haivision).
First a quick note for those who may not be as familiar. SRT (Secure Reliable Transport) is a new open source standard that is being used in many applications within the video streaming market, including live video transport workflows for broadcast, enterprise webcasting, and internet streaming applications. Through the SRT Alliance initiative, SRT is being adopted by over 70 companies including encoder developers, CDNs, and OVPs as a high performance streaming alternative.
Let’s take a look at some of the fundamental differences between RTMP, HTTP based protocols and SRT.
Continuous vs. Fragmented Streaming
RTMP is a continuous streaming technology. Packets containing the fundamental stream structure of MPEG I-frames and P-frames are sent from the source to the destination as they are created. HTTP-based protocols (HLS and MPEG-DASH) rely on those streams being packaged as fragments (or segments or chunks) and then sent across the network as file segments. Before leaving an encoding platform, a number of sequence of I-frames and P-frames are collected and packaged together as a file for transmission. This packaging process, although accommodating the ubiquity of file transfers, slow down your stream and dramatically increase end to end latency. SRT, like RTMP, is a continuous streaming protocol designed for high performance transmission and bandwidth optimization.
Like RTMP, the HTTP based protocols (including HLS and MPEG-DASH) rely on TCP/IP for handshaking and for identifying and replacing packets that are lost in transmission. TCP/IP demands a very tight sender-receiver relationship so that regardless of network conditions all lost packets are detected and retransmitted. Large buffers at either end of the stream workflow hold packets that may need to be retransmitted when faced with packet loss.
However, the main problem with TCP/IP based transmission for video streaming is that the re-transmission of packets takes a very long time, adding dramatically to the latency of the video. Here’s how it works. The receiver acknowledges every packet, the sender maintains the large buffer of all packets sent, just in case, and then retransmits packets that do not somehow arrive within a particular time window.
A second major problem with TCP/IP is that because of all of the TCP/IP handshaking (and related congestion control algorithms that tend to throttle down bandwidth), RTMP and HTTP streaming has a very difficult time with bandwidth utilization. OK for lower bandwidth transmission over a few hops, TCP/IP based transmission reaches a maximum bandwidth very quickly (sometimes in the 1.5 to 2 Mbps range), and once there the bandwidth starts to choke.
So both TCP/IP and stream fragments are your enemy when trying to establish a high performance video stream.
UDP (User Datagram Protocol) is a IP transmission protocol with no sender / receiver relationship. The source spits out packets and doesn’t really care about the receiver. If a packet is lost, oh well. UDP is a great protocol for streaming over pristine networks, like the LAN or dedicated private network WAN connections such as MPLS.
Haivision invented SRT to deliver the performance of UDP over lossy networks with a high performance sender / receiver module – one that does not choke the network with useless acknowledgements so it can scale and maximize the available bandwidth. With SRT, we also focused on timing. With video, timing is everything. SRT guarantees that the packet cadence (compressed video signal) that enters the network is identical to the one that is received at the decoder, dramatically simplifying the decode process. SRT is designed for low latency video stream delivery over dirty networks.
SRT adds in some other neat features specifically designed for the video streamer. It natively provides for independent AES encryption so stream security is managed on a link level. It also allows users to easily travers firewalls throughout the workflow by supporting both sender and receive modes (in contrast to both RTMP and HTTP that only support a single mode). In addition, SRT can bring together multiple video, audio, and data streams within a single SRT stream to support highly complex workflows without burdening the network administrators.
Finally, within the sender / receiver module, we incorporated the ability to detect the network performance with regard to latency, packet loss, jitter, and available bandwidth. Advanced SRT integrations can use this information to guide stream initiation, or even to adapt the endpoints to changing network conditions such as we have done on Haivision’s Makito X encoder with Network Adaptive Encoding.
Finally, the best is that SRT is payload agnostic, open source and royalty free. So with RTMP going away, and as DASH or HLS may be acceptable for stream distribution from your CDN to desktops and mobile devices, SRT is the clear winner for “first mile” contribution streaming.
See for yourself – go ahead and learn more here and sign up for a demo.