The Most Popular Streaming Protocols for 2021 Compared

Jan 11, 2021 | Multi-site, Web Platform, Web Streaming

Streaming Protocols 2021 Compared Featured Image

With all of the different streaming protocols out there, and new ones being developed constantly, it can be a bit difficult to figure out which one makes the most sense to go with for your live stream. In this post we will dive deep into the differences between the top streaming protocols that currently exist for streaming video.

By the way, did you know that 70% of viewers will abandon a live stream after the second buffering wheel? Whether you are looking to stream sports, education, business meetings, or live events and church services – knowing the difference between streaming provider’s protocols is vital if you want to ensure a quality stream with no buffering.

 

Table of Contents:

 

Definitions Every Streamer Needs to Know

 

Streaming Codec Definition

 

A codec is a term referring to the device or program helping run and compress data for transport over a network for streaming. Codecs are compression technologies and have two component:, an encoder to compress the files and a decoder to decompress. There are two types of codecs as well, video codecs and audio codecs, which work in different ways but essentially do the same thing. They take large files and compress them into an appropriate format for a decoder to decompress. 

Different streaming protocols support different types of codecs, so it is vital to understand the supported codecs of a streaming protocol before making a decision on which protocol to use. Supported codecs range from industry standards like H.264/HEVC for video and AAC/MP3 for audio to custom made codecs that are only supported by certain devices (Opus, Vorbis).

 

Bitrate

Bitrate is a measurement of bits traveling between devices. Bits being basic units of information in computing and digital communications almost always measured in bits per second (bps). For streaming, bitrate refers to the amount of data being sent by the broadcaster (upload) and then to the viewer (download). Streaming protocols with higher bitrates contain higher image quality. For example, if you tried to stream a 4k stream with a bitrate of 1(Mbps) you would not have a watchable stream, as your bitrate would not be large enough to support 4K video. 

It’s important to know that a “bit” is not the same thing as a “byte.” 8 bits are equal to 1 byte. For example, a 4Mbps video stream would be using approximately .5 megabytes per second.

 

Bandwidth

 

Bandwidth, on the other hand, refers to the amount of data you can send through your internet provider. Consider bitrate like water, and bandwidth like a pipe. You can only send so much water through a small pipe, so even if you have access to a streaming service that has an extremely high bitrate, you will still be throttled in the amount of bits you can send/receive by your internet provider’s bandwidth. Most internet providers currently support around 100(Mbps) download speeds, and around 10-15(Mbps) upload speeds. If you are using your phone, however, those numbers will typically be even lower as most cellular connections have less bandwidth than WiFi or ethernet networks.  

 

Packet Loss

 

Packet loss describes packaged data failing to reach its end destination (such as bits). This can refer to a single bit or group of bits failing to reach the desired endpoint. When streaming with low-latency streaming protocols, even a 1-2 second disruption of your internet connection will result in packet loss. Generally there are two reasons for packet loss; internet outages and network congestion. 

That means that even if your internet connection remains stable throughout your live stream, if there is any network congestion (where the total bitrate exceeds the network bandwidth) it will result in packet loss, buffering, frame drops and ultimately stream failure if streaming with a low-latency protocol. There is currently only one streaming protocol that intentionally increases latency to avoid packet loss and buffering, but we’ll discuss that soon 🙂

Buffering

Buffering occurs on the viewer’s device when they either do not have enough bandwidth to download the size of the video file in realtime, or when the broadcaster’s live stream goes down due to packet loss, network congestion, or network failure. 

While it is important to plan reliable network infrastructure and pick a streaming provider and method that will support reliable streaming from a broadcast perspective, viewers’ bandwidth can still be unpredictable. 

Use a streaming provider that converts your stream into multiple bitrates through cloud transcoding. This enables viewers to watch in lower quality through adaptive bitrate streaming depending on their bandwidth and device processing power.

What is a streaming protocol?

What is a Video Streaming Protocol? 

The term “Streaming Protocol” refers to the standardized method of delivering multimedia (audio and video) to destinations using the internet. Video streaming protocols take source video and audio and chop them up into smaller pieces of data so that they can be sent successfully over the internet. While that is the end goal of any protocol, not all are equal. 

Whether or not a protocol will work for you depends on the codecs supported for video and audio, playback compatibility, latency, and platforms supported. Not all video protocols are built the same. Some are on the rise in popularity due to their features and successful implementation of those features, and some are on the decline in popularity due to their outdated design and playback support.

Different Streaming Protocols Compared

RTMP (Real-Time Messaging Protocol)

RTMP was released to the public by Adobe back in 2012. It was designed to work exclusively with Adobe’s Flash player, which at the time powered nearly 98% of internet browsers back in the day. As such, RTMP became the most widespread and popular streaming protocol due to its compatibility with Flash. 

Times have changed, however, and Flash Player has been officially unsupported by Adobe as of the end of 2020. With the invention of HTML5 and the advancement of internet browsers, there is simply no longer a legitimate reason for someone to use Flash. 

This doesn’t mean that you can no longer stream with RTMP. You could theoretically use it for ingestion and the last mile (the data transfer between the ISP and the viewer) could be powered by a separate streaming protocol. This, in our opinion, wouldn’t be a great option due to the longstanding issues of buffering and packet loss known to plague streams using RTMP

The internet isn’t perfect, and this streaming protocol was designed as if it was. There is no protection for network failures or congestion, and because those two issues arise on practically an hourly basis with most internet providers, using RTMP for live streaming would be a very unreliable route to take.

 

RSP (Resilient Streaming Protocol)

The Resilient Streaming Protocol (RSP) is the first live streaming technology that fully protects against audio and video quality loss during transmission regardless of network interruptions. It is intended to be used in any application which requires that live multimedia be free of imperfections caused by transmission problems and where the viewing experience cannot be interrupted by missing or lost content. Because RSP guarantees to deliver video and audio complete and error-free, it can confidently be used for live streaming over unpredictable networks such as wireless cellular hotspots.

Other streaming protocols such as RTMP and any of those that use forward error correction techniques (MPEG-TS, Zixi, SRT, etc.) all have the potential to lose data during video delivery to a cloud server, so streaming with any of these protocols over an unpredictable network is likely to result in the cloud server having incomplete video data for media processing and distribution.

Broadcasters who use RSP for streaming live video to Resi’s Web Platform can be certain that their multi-bitrate video has been created from a perfect and complete audio/video source. 
RSP also uses the standard internet ports 80 and 443 to upload live video and the same ports to receive feedback from the destination which means no firewall modifications are needed at any location. It supports AAC audio and playback is compatible with all DASH and HLS capable devices, (including devices like Roku and Apple TV), YouTube & Facebook, and any modern web browser. RSP uses a short, pre-defined delay to ensure zero buffering or packet loss due to network issues at the broadcast site. Learn more about RSP.

RTSP (Real-Time Streaming Protocol)

 

 

RTSP (Real-Time Streaming Protocol)

RTSP is a very low-latency protocol designed to have nearly instantaneous playback from the source. This makes it a great protocol for certain applications such as surveillance video, drone control, loT devices or mobile SDKs.

RTSP is not very popular as its native browser support is very limited. It can be used with Quicktime Player (and other RTSP/RTP-Compliant players), Video LAN VLC Media Player, and 3GPP-Compatible Devices. This makes it less appealing for most people streaming events, and better for software developers to use internally for system communication purposes. It is a dependent protocol as it relies on Real-Time Transport Protocol (RTP) and Real-Time Control Protocol (RTCP) to function.

 

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) Protocol

MPEG-DASH, short for Dynamic Adaptive Streaming over HTTP (DASH) is becoming more and more popular everyday. It uses standard HTTP web servers and uses adaptive bitrate technology to automatically adjust the quality of the stream based on the last-mile (end-user) bitrate. If someone is watching a stream and their internet speed drops, the video playback will automatically transition to a lower quality stream to avoid buffering. This is known as the ABR protocol, which MPEG-DASH uses by default.

Video codecs supported by MPEG-DASH include H.264 (the most common codec), H.265 / HEVC (the next-generation successor), WebM, VP9/10, and any other codec. It supports AAC, MP3 or any other audio codec as well. It also features native playback compatibility on Android, Chromecast, and most social streaming platforms like Facebook and YouTube.

As great as MPEG-DASH is for minimizing buffering for the end user, it does not protect against the broadcaster’s potential network issues. If the source of the stream loses internet, or experiences network congestion or throttling, the stream will be interrupted and the viewers will experience buffering. This is what happens when streaming providers use RTMP for the streaming source protocol and MPEG-DASH for the last-mile. While it certainly will help to reduce the risk of buffering if the user experiences network problems, that combination of protocols still does nothing to protect against the potential network issues at the broadcast location.

The best of both worlds, is to use a resilient streaming protocol such as RSP for upload to the cloud, and MPEG-DASH for social streaming on Facebook and YouTube to avoid network issues that could occur at both the destination and the source. Resi’s web platform, which we briefly mentioned in the RSP section, does exactly that. It uses RSP to ensure resiliency from source to the cloud, and MPEG-DASH for the last mile when streaming to social channels.

MPEG-DASH Streaming to Facebook and Youtube

Streaming Protocol Comparison Chart

 The ultimate video streaming protocol comparison chart! Compare all of the protocols we discussed above, as well as HDS and HLS protocols. Quickly compare protocol codec support, playback compatibility and latency to help you easily see which protocol is best for your stream.

 

Streaming Protocol

RSP: Resilient Streaming Protocol

Supported Video Codecs

H264, HEVC

Supported Audio Codecs

AAC

Playback Compatibility

All DASH and HLS Play capable devices, Roku Apple TV, Web Players, YouTube & Facebook, Web (Chrome, Safari, Edge)

Latency

Short pre-defined delay (Ensures Zero Buffering)

Streaming Protocol

RTMP: Real-Time Messaging Protocol

Supported Video Codecs

H.264, VP8, VP6, Sorenson Spark®, Screen, Video v1 & v2

Supported Audio Codecs

AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis

Playback Compatibility

Flash Player, Adobe AIR, RTMP-Compatible Players

Latency

Low-Latency (under 5 sec)

Streaming Protocol

RTSP: Real-Time Streaming Protocol

Supported Video Codecs

AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis

Supported Audio Codecs

H.265, H.264, VP9, VP8

Playback Compatibility

Quicktime Player (and other RTSP/RTP-Compliant players), Video LAN, VLC Media Player, 3GPP-Compatible Devices

Latency

Low-Latency (under 2 sec)

Streaming Protocol

SRT

Supported Video Codecs

Any (Codec-Agnostic)

Supported Audio Codecs

Any (Codec-Agnostic)

Playback Compatibility

Limited

Latency

Low-Latency (3 seconds or less)

Streaming Protocol

MPEG-DASH

Supported Video Codecs

Any (Codec-Agnostic)

Supported Audio Codecs

Any (Codec-Agnostic)

Playback Compatibility

Native Support on All Android Devices Post-2012 Samsung, Philips, Sony, and Panasonic TVs, YouTube and Netflix, Firefox, and Chrome Browsers, *No Safari or IOS Support

Latency

Mid-latency (6–30 sec)

Streaming Protocol

HDS

Supported Video Codecs

AAC, AAC-LC, HE-AAC+ v1 & v2, MP3

Supported Audio Codecs

H.264, VP6

Playback Compatibility

Flash Player, Adobe AIR

Latency

Low-Latency (between 6-8 seconds)

Streaming Protocol

HLS

Supported Video Codecs

AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC

Supported Audio Codecs

H.265, H.264

Playback Compatibility

iOS and macOS Devices, Firefox, Edge, Safari & Chrome Browsers Most Online Video Platforms

Latency

High-Latency (around 10 seconds) but without the benefit of DVR functionality

Streaming Protocol

WebRTC

Supported Video Codecs

H.264, VP8, VP9

Supported Audio Codecs

Opus, iSAC, iLBC

Playback Compatibility

Chrome, Firefox, and Safari support WebRTC without any plugin

Latency

Low-Latency (under 500 ms)

See what it's all about.

Resilient streaming starts here.