Single bitrate RTMP workflows have been a cornerstone of live streaming for over a decade. They are simple and effective for delivering fixed-resolution and fixed-bitrate streams, but in a world where streaming needs to adapt to diverse devices and fluctuating network conditions, their limitations have become increasingly evident. This is particularly true in the real-time… Continue reading Single Bitrate RTMP: Legacy Workflows in a Modern Streaming World
Single bitrate RTMP workflows have been a cornerstone of live streaming for over a decade. They are simple and effective for delivering fixed-resolution and fixed-bitrate streams, but in a world where streaming needs to adapt to diverse devices and fluctuating network conditions, their limitations have become increasingly evident. This is particularly true in the real-time live video space where adapting to users’ network conditions needs to happen in mere milliseconds. In this article, we’ll explore single bitrate RTMP workflows, the evolution toward Adaptive Bitrate (ABR) streaming in real-time video, and the varying approaches taken by platforms such as Phenix RTS, Dolby Millicast, Agora, Vonage, and Red5 Pro.
We should also note that while we are discussing single bitrate streaming as it relates to RTMP, other ingest protocols such as RTSP, WHIP, SRT, Zixi also can take a single bitrate approach. The learnings from single bitrate RTMP can easily be applied to any of these other protocols.
What is Single Bitrate RTMP?
Single bitrate RTMP delivers video at a fixed quality to all viewers, regardless of their device capabilities or network conditions. While this approach simplifies the streaming process and is compatible with older systems, it introduces significant drawbacks:
- Buffering: Viewers on slower networks experience interruptions because the stream cannot scale down.
- Underutilized Bandwidth: Viewers with faster connections are stuck with lower-quality streams.
- Limited Scalability: Fixed quality limits audience engagement across diverse regions and connection types.
Despite these drawbacks, some platforms continue to rely on single bitrate RTMP workflows as a fallback (sometimes as the primary approach), particularly when faced with challenges in implementing scalable Adaptive Bitrate solutions.
Adaptive Bitrate (ABR) Streaming: A Modern Solution
ABR streaming overcomes the limitations of single bitrate RTMP by dynamically adjusting video quality based on a viewer’s bandwidth and device. This is achieved through the creation of an ABR ladder, which provides multiple renditions of the stream at varying resolutions and bitrates (e.g., 1080p, 720p, 480p).
Two Main Approaches to ABR Creation
- Multicast ABR (Encoder-Based)
- The encoder generates multiple quality levels simultaneously and sends them to a media server.
- Advantages: Minimal server-side processing.
- Disadvantages: Places significant load on the encoder, requiring high-performance hardware.
- Server-Side Transcoding
- A single high-quality stream is sent to the media server, where transcoding nodes generate ABR renditions.
- Advantages: Lightens the load on client devices and allows centralized control over quality settings.
- Disadvantages: Higher server infrastructure requirements.
ABR streaming has a long history of usage in high latency video streaming protocols like HLS and DASH, and the more recent approaches in real-time protocols, in particular WebRTC are reinventing how ABR works. While others in the space, which we will get to next, are making strides in supporting ABR, Red5 Pro and Red5 Cloud excel in server-side ABR transcoding, supporting both HLS and WebRTC workflows for seamless, adaptive streaming at scale.
How Real-time Streaming Vendors Handle ABR and Single Bitrate RTMP
Phenix RTS
Phenix emphasizes edge-based transcoding, where ABR renditions are created at the edge server upon viewer request. While this enables low latency, it comes with high computational costs at the edge and challenges in scaling globally. This increase in overhead translates into higher costs to the customer.
Red5’s XDN approach addresses these inefficiencies by creating the ABR ladder at the origin server. These pre-transcoded streams are distributed across the cluster, reducing edge server load and ensuring scalability with lower infrastructure costs. This is one of the many reasons that Red5 Cloud costs are so much lower than other competitive real-time streaming solutions.
Dolby Millicast
Dolby Millicast has historically depended on single bitrate RTMP but recently introduced a limited transcoding feature to support ABR. While this addition is a step forward, early users report scalability and quality consistency issues. This development signals Dolby’s recognition of the inadequacy of single bitrate workflows but also highlights the complexities of implementing ABR effectively.
Agora, Vonage and other CPASS focused Solutions
Agora and Vonage are primarily focused on real-time communication and small-scale peer-to-peer applications. Their streaming workflows often rely on single bitrate RTMP ingestion, which suffices for their use cases but lacks the adaptability and scalability required for large-scale live streaming. We see the same patterns with reliance on single bitrate streaming with others in this category like Twilio Video as well.
The Scalability Equation: Edge vs. Origin
The choice between edge-based transcoding (Phenix) and origin-based ABR ladder creation (Red5 Pro) has significant implications for scalability:
- Edge Transcoding: While it minimizes latency, it demands substantial computational power and infrastructure at the edge, making it costlier to scale.
- Origin-Based ABR Creation: By generating ABR renditions upfront, origin-based systems reduce edge server load, improve resource allocation, and enable more cost-effective scaling.
Platforms like Red5 Pro and Red5 Cloud leverage origin-based transcoding to achieve high scalability while maintaining competitive pricing structures.
Single Bitrate with Other Protocols
While RTMP has long been synonymous with single bitrate workflows, other protocols like RTSP, SRT, Zixi, and WHIP can also operate in single bitrate modes, depending on the use case. Here’s a quick overview of how these protocols handle single bitrate streaming and where they are commonly applied:
RTSP (Real-Time Streaming Protocol)
RTSP is widely used in IP cameras and surveillance systems. In many cases, these devices deliver single bitrate streams due to hardware limitations or the low complexity of their workflows. While effective for closed-loop monitoring or low-latency streams, RTSP’s single bitrate approach can lead to quality challenges when bandwidth fluctuates.
SRT (Secure Reliable Transport)
SRT is designed for reliable transport over unreliable networks and is often employed in contribution workflows. In single bitrate configurations, SRT ensures low latency and robust delivery, but it does not inherently support adaptive streaming. Broadcasters often combine SRT with server-side transcoding to generate ABR ladders for end-user delivery.
Zixi Protocol
Zixi specializes in high-quality, low-latency transport for professional video workflows. Single bitrate Zixi streams are common in contribution scenarios where the network is managed and stable. However, Zixi’s platform also supports server-side transcoding to enable ABR workflows, making it more flexible than single bitrate-only approaches.
WHIP (WebRTC-HTTP Ingestion Protocol)
WHIP is a newer protocol optimized for WebRTC ingestion. It typically operates as a single bitrate stream from the broadcaster’s encoder to a media server. While ideal for ultra-low latency use cases, WHIP is usually integrated with transcoding solutions on the server side to support ABR for large-scale distribution.
Just like RTMP, single bitrate workflows with other protocols are often the starting point for contribution or ingestion due to their simplicity and low latency. However, regardless of the ingest protocol used, they all face the same fundamental limitation: the inability to dynamically adapt to diverse viewer bandwidths. As with RTMP, pairing these protocols with server-side transcoding or ABR ladders is essential for delivering a modern, scalable streaming experience.
Red5 Cloud and Red5 Pro both handle all of these ingest protocols and leverage server side transcoding to generate ABR ladders out of all of these for WebRTC delivery. The other competitors in the space often are limited ingest protocol options, and typically have a hard time generating ABR for real-time delivery.
The Future: Moving Beyond Single Bitrate RTMP
Single bitrate RTMP workflows remain viable for basic use cases or legacy systems. However, they are ill-suited for modern streaming demands, where scalability, adaptability, and quality are paramount.
Competitors such as Phenix RTS and Dolby Millicast are evolving their offerings, but their approaches come with limitations. In contrast, Red5 Pro and Red5 Cloud provide flexible, scalable solutions that balance low latency, high quality, and cost-efficiency.
For broadcasters and developers seeking to deliver cutting-edge real-time streaming experiences, the move to ABR workflows is no longer optional—it’s essential. Whether you’re exploring solutions for low latency HLS, WebRTC, or a hybrid environment, adaptive streaming platforms like Red5 Pro and Red5 Cloud offer the tools to stay ahead in a competitive market.