Live streaming has transformed how we connect, communicate, and consume content. From virtual conferences to live sports and entertainment, the underlying technology has come a long way. Among the key players in this evolution are RTMP (Real-Time Messaging Protocol) and HLS (HTTP Live Streaming). While RTMP dominated the early days of live streaming, HLS has become the standard for playback across devices. This article explores the journey from RTMP to HLS, highlighting the strengths, limitations, and ongoing relevance of these technologies.
A Brief History of RTMP
RTMP was developed by Macromedia (later acquired by Adobe) as a protocol for streaming audio, video, and data over the internet. It gained popularity with the rise of Flash Player, which supported RTMP seamlessly. During its heyday, RTMP was the go-to solution for live streaming because of its low latency and real-time interaction capabilities.
One memorable anecdote involves a small wedding in Portugal where a videographer used RTMP via Red5 to stream the ceremony to distant relatives. The simplicity of RTMP allowed the setup to be completed in under an hour, ensuring the family could witness the joyous occasion in real time. However, as browsers phased out Flash Player, RTMP faced a major hurdle: its incompatibility with modern browsers.
The Transition to HLS
HLS was introduced by Apple to address the growing demand for adaptive streaming. Unlike RTMP, HLS works seamlessly across modern devices, including smartphones, tablets, and desktops. It achieves this by breaking the video into small chunks delivered via HTTP, making it highly scalable and reliable.
However, HLS comes with a trade-off: latency. The process of creating and buffering video segments introduces delays, which can range from 6 to 30 seconds. For most applications, such as live TV broadcasts or corporate events, this latency is acceptable. But for time-sensitive scenarios like live betting, HLS’s latency can be a dealbreaker.
RTMP’s Role in Today’s Streaming Workflows
Despite its limitations, RTMP has not disappeared. Instead, it’s found a new role in modern workflows. RTMP is often used as the input protocol for streaming servers like NGINX or Wowza, which then convert the feed into HLS for playback. This combination leverages RTMP’s low latency for ingestion and HLS’s compatibility for delivery.
A broadcaster in East Africa once shared their story of upgrading from a Red5-based RTMP setup to an NGINX server. The new system allowed them to stream local sports events with greater reliability, reaching a wider audience via HLS.
NGINX vs. Wowza: A Comparison
Both NGINX and Wowza are popular choices for handling RTMP to HLS workflows. Here’s how they compare:
Feature
Red5 RTMP
NGINX RTMP
Wowza RTMP
HLS
Cost
Free
Free
Paid
Free after setup
Scalability
Moderate
High
High
High
Latency
Low
Low
Low
High
Browser Support
No
No
No
Yes
NGINX is favored for its lightweight and open-source nature, making it ideal for cost-conscious users. Wowza, on the other hand, offers robust features and professional-grade support, which justify its premium pricing for enterprise users.
HLS: The Present and the Future
HLS has cemented its place as the standard for live streaming playback. Its adaptability to different network conditions and support for multiple devices make it indispensable. Innovations like low-latency HLS (LL-HLS) aim to address the delay issue, bringing it closer to real-time performance.
Why RTMP and HLS Work Well Together
The synergy between RTMP and HLS is what makes them invaluable in modern streaming workflows. RTMP’s low-latency ingestion ensures that live feeds reach the server promptly, while HLS’s adaptive delivery ensures seamless playback for viewers. For broadcasters, this combination strikes the perfect balance between performance and accessibility.
Final Thoughts
Live streaming continues to evolve, but the core principles of reliability, scalability, and user experience remain unchanged. While RTMP’s browser incompatibility limits its direct use, its role as an input protocol keeps it relevant. HLS, with its widespread compatibility, bridges the gap between content creators and audiences. Together, they form the backbone of modern broadcasting.
As we look ahead, advancements in low-latency technologies and protocol optimizations will further enhance live streaming’s potential. Whether you’re a broadcaster, a developer, or a viewer, understanding the evolution of these technologies provides valuable insights into the future of live streaming.
Android can not play RTMP directly using the default Chrome mobile browser, as Flash plugin is required to play RTMP in browser (available only on PC).
Transcode and deliver stream using a format that plays in Chrome mobile browser, like MPEG DASH or WebRTC.
RTMP is still used quite a bit by broadcasting application and hardware, such as Wirecast and OBS.
It’s not widely used for end delivery anymore, though. As viewing RTMP streams pretty much requires a flash plugin, and most modern browsers have (or are) dropping support for it, other solutions are the norm today.
HTTP live streaming is widely used because it uses existing CDN:s for delivery, and plays natively on smartphones – which is a huge selling point today. In 2018 52% of all web traffic was through mobile phones.
Transcoding and MPEG DASH, WebRTC delivery is possible with Broadcast Live Video solution.
RTMP stream can be published with an external encoder (including mobile apps like Wowza GoCoder) and played back over MPEG DASH or WebRTC in Android
Red5 is a media server created with Java language. It is a free open source software but recently a new version Red5 Pro came out developed by the same people, this new version supports streaming to mobiles, Android or iOS, which red5 does not. The Red5 Pro is commercial product and costs $55 per server.
A media server allows Flash based applications connect to it using Real Time Messaging Protocol (RTMP). The server can send and receive data to and from the connected users who have a flash player installed. The server also allows users to receive and publish streams. This permits video chat applications, live streaming and even ondemand video streaming.
Most common Video chat software’s are:
1- Avchat
2- Videowhisper
3- Prochatrooms
4- Gchats
For live streaming the necessary tool if you already have a server with red5 installed is an encoder, an encoder is the software that will connect your computer to the red5 server using the RTMP, which your server provider will give you.
1- FMLE, it is an free Adobe product and does a good job.
2- Wirecast, it is an expensive commercial product of very high quality, absolutely necessary if you starting a TV station.
Although red5 is a free product many people prefer to use Wowza Streaming Engine or Adobe Flash Media Server which are commercial software’s and can be quite expensive, the FMS costs $4500 per server. The reason is that the developers of red5 although have created a wonderful system did not spend much time with tutorials and instructions on how to install and manage a red5 server, for this reason if you searching for a red5 server we suggest you pick a web host which specializes on red5 servers and red5 shared hosting.
1- Red5 Servers relatively cheap red5 servers starting at $15 a month.
2- Red5 Hosting, Hosting Marketers, a web host for experienced webmasters, it is the oldest hosting company specialized on Video and media servers, they also offer Wowza Streaming Engine on its shared plans. They have a very experienced customer support and a reputation for going out of their way to help customers. They starting plan with Red5 enabled costs $9.95 a month. Most other red5 hosting companies are resellers of Hosting Marketers.
Red5 is a formidable media server, extremely flexible and has the advantage of being a free product with with many people working on developing it, for now the main version does not yet work with mobiles, if that is what you need we suggest that instead of using the Red5 Pro version to use the Wowza instead. Hosting Marketers also offers Wowza, in fact they even offer a 3 days free trial.
Recently we had to setup a re-broadcast a live Darshan from Shree Ranchhodraiji Maharaj Temple, Dakor, Gujarat, India. They gave us a RTSP, something like this:
this rtsp included a username and password, the rtsp was from IP camera, from this we had to re-broadcast using wowza media server.
On the application.xml for StreamType we used live, other then that we didnt change anything. We created a file camera.stream which we upload to the /wowza-installation/content/
Recent Comments