It’s been a long time coming. Flash is well on its way out with 2020 marking the last official year for support.

Flash was a cornerstone of the live-streaming technology sector and, with the use of the underlying RTMP protocol, lay the groundwork for where we are today. The general-purpose streaming platform Justin TV was powered by Flash before it turned into the game streaming platform Twitch. As demand for live video grew, Flash's limitations (plugin-in dependent, proprietary technology, performance issues, etc.) proved an impediment to the advancement of live-streaming.

It is worth mentioning that Flash also served as a default solution for VOD and prerecorded content as well. In fact, YouTube at one time depended upon Flash. While there are VOD replacements to Flash as well, this post shall focus mostly on discussing live streaming.

As many browser-based applications have depended upon Flash, the fact that it is going away could be a major source of concern. Fortunately, there is a fully functioning (in many ways, better functioning) solution: WebRTC.


As an HTML5 specification, WebRTC creates peer-to-peer, real-time media communications directly between browsers and devices via a simple API. WebRTC, an open-source project, also enjoys wide support from major players Apple, Google, Microsoft, Mozilla, and Opera. That support ensures that the WebRTC standard remains up to date and functional for the foreseeable future.

By using a secure and efficient UDP based transport known as SRTP, WebRTC is able to transport video with the lowest latency currently possible. It can also still maintain a high-quality video, even in less than ideal network conditions.

To conduct the actual process of live streaming, WebRTC implements the following APIs:

MediaStream (aka getUserMedia): gain access to data streams, such as from the user's camera, screen, and microphone.

RTCPeerConnection: audio or video streaming, with facilities for encryption and bandwidth management.

RTCDataChannel: peer-to-peer communication of generic data.

The following part is a deeper dive into the nitty-gritty of how WebRTC works. Those not interested in the technical explanation can skip to the end of this section.

For direct access and encoding of an attached or built-in webcam and microphone, WebRTC uses the MediaStream API usually invoking the GetUserMedia method. This creates the MediaStream object which contains the video stream parameters and constraints (resolution, aspect, bit rate, etc.). This replicates the mic and camera access originally provided by Flash.  

The MediaStream object is then sent through the RTCPeerConnection. Essentially the RTCPeerConnection contains all the procedures for maintaining an efficient connection. This includes:

  • packet loss concealment
  • echo cancellation
  • bandwidth adaptivity (allowing for ABR support)
  • dynamic jitter buffering
  • automatic gain control
  • noise reduction and suppression
  • image 'cleaning'

Please note that the signaling process identifying where each client can be found (IP address, port and connection parameters) is not directly specified by the WebRTC API. More on that can be found in this blog article.  

The RTCDataChannel API enables peer-to-peer exchange of arbitrary data, with low latency and high throughput. There are many potential use cases for the API, including:

  • Gaming
  • Remote desktop applications
  • Real-time text chat
  • File transfer
  • Decentralized networks

A full breakdown of how this all works can be found on the archived HTML5 Rocks page.

Technically HTTP based protocols such as HLS, CMAF, or MPEG-DASH could be considered a replacement for live streaming, but their lackluster performance and high latency does not make them a viable alternative to Flash video for real-time delivery. However, HTTP protocols have become the standard for VOD. Those protocols serve that use case incredibly well powering all the major streaming providers like Netflix, Disney Plus, etc.


There is a common misconception that WebRTC is not scalable due to how it establishes a peer-to-peer connection. Under traditional modes of thinking this was technically true. However, some creative reconfiguration of scaling infrastructure resulted in the cloud-based Red5 Pro Autoscaling Solution supporting millions of concurrent connections all with under 500 milliseconds of latency.

Red5 Pro reimagined the entire architecture from back-end server to front-end browser and mobile app integration.

By leveraging cloud infrastructure, Red5 Pro’s Autoscaling Solution automatically scales the system up or down in response to current conditions. Under the operating logic of a Stream Manager– a Red5 Pro Server Application that manages traffic and monitors server usage– clusters or NodeGroups– a group of one or more active server nodes– are established in the geographic regions where the streaming will be happening.

What Does This All Mean?

Flash is done and WebRTC is the way forward. Working directly in the browser without a plugin, WebRTC allows access to a webcam and microphone to establish a real-time latency live streaming video connection. This makes WebRTC the only real alternative to Flash video. Using Red5 Pro, it’s fully scalable to millions of concurrent connections, all with a latency of under 500 milliseconds.

For more information on Red5 Pro’s WebRTC solution or any other live streaming questions, please send an email to or schedule a call.

  • Share: