- January 5, 2021
- 3 minute read
Today we open another Posts Mini-Series, this time around we’ll focus on Streaming. As you may know , we are Streaming enthusiasts and most part of our daily business revolves around assisting and consulting on Streaming Solutions. Now that we think of it, this introductory Streaming Posts Mini Series should have come way earlier in our Blog, but given that we’re into so many Projects, and given that we wanted to first close the circle around what we’d be going to cover into it we’ve preferred waiting until today.
Today’s Post opens the arena talking about RTMP Streaming, that is , Streaming over RTMP as a Protocol: RTMP is the second most largely used Streaming Protocol , and although considered “Legacy” by many CDNs nowadays, it still represents the only way to overcome some technical challenges with Streaming, not to mention the fact that it’s highly adaptable, especially to simpler Devices.
Without any further ado, let’s dive into it and have a closer look into what RTMP Streaming is on a high level.
Streaming has become an extremely popular way to deliver audio and video content today; just think about the Internet panorama not any longer than 5 years ago. There are several reasons for this popularity: for instance, if you want to deliver either Audio or Video to your Customers on a subscription basis, you have no other option but to use a Streaming Technology. When a Video is streamed to your Customer via a Media Player, the content simply plays instead of downloading. If this Customer opts out of his/her subscription, he or she can no longer access the Video. In short, you cannot download a streaming Video. Moreover, you can transmit Live content, in the form of Audio or Video, only by using a Streaming Technology.
Streaming means transmitting data over a Network using a Streaming Media Server, directly to a Media Player. The User or Viewer can start watching the content immediately, without having to wait for the entire Video file to download. For Streaming data you require a Media Server instead of a Web Server. The data or Video is compressed at the Media Server end and decoded by the Media Player. There are many Vendors and Protocols for Streaming media. Real Networks and Microsoft Windows media are two (not so popular anymore) formats. Streaming can be either from a file which is stored on a Media Server (On Demand Streaming) or transmitted Live. Webcasts and Podcasts can only be enabled using a Streaming Technology.
Many of us are quite confused by what constitutes Streaming and how it’s different from downloading. Before proceeding into all technicalities pertaining to Streaming Technologies, it’s critical to know the difference.
Let’s examine the process of downloading and playing back a Video file. This process (downloading) makes use of the HTTP Protocol and data or Video is stored on a Web Server. Whenever a request is made for the Video file, the Web Server simply transmits data to the End User. The End User can start viewing the Video only after the entire file has downloaded. Note that the file is downloaded completely, without any loss of data (in the form of dropped frames). The TCP protocol ensures that all data packets are received.
On the other hand, Streaming media is (almost) instantly available for playback on the End User’s Media Player. The media is compressed at the Server and decompressed at the End User end. Users can access interactive applications and create playlists. Streaming Media Providers can monitor usage of their service and bill Customers accordingly. Since Streaming Media cannot be downloaded, it is suitable for subscription based Services. It protects all Copyrights since users cannot store and distribute media files (well they do, but that is a different Post than today’s); Streaming Technologies can likewise be used for Live broadcasts.
Walking in a Web Server’s shoes, media downloading is a one way process. As soon as the media file on the Web Server receives a request, it (the Web Server) simply begins the process and ensures that the file is downloaded to the hard disk of the End User. When you use a Streaming Server, the media download is a two way process consisting of the actual download and another process which communicates and exchanges information between the Player and the Server. Due to this communication which consists of control messages, the Streaming Server can (amongst the very whole rest) modulate and adjust the Streaming speed according to Network conditions and Media Player. For example, if the speed of transmission (for whatever good or bad reason) drops from 300 to 200 kbps, the streaming is adjusted to cater to this lower speed or rate, which leads to better User experience. When the Network speed improves, the Server once again increases the transmission rate. Needless to say, this is just one of the many Features and this is not the only way to handle Adaptive Bitrates; the latter was more of a sample to mention what the constant flow of communication between Server and Clients allows to help with.
RTMP is an Adobe Proprietary Protocol and stands for Real Time Messaging Protocol. Originally it was developed by Macromedia Inc. which was later purchased by Adobe; if you still remember Macromedia you can guess how old RTMP as a Protocol is. Let’s face it: the Adobe Flash Player has been in use for long and is still used widely, though it’s Legacy nowadays if you go and ask most CDN Vendors for example. RTMP can be used for streaming Video in MP4 and the popular FLV formats. It can also stream Audio in AAC and MP3. RTMP can be used for Live as well as On Demand Streaming. There are many types of RTMP Servers, such as the Adobe Flash Media Servers or Wowza Servers (the most popular among them).
RTMP is based on TCP (Transmission Control Protocol). In a sample scenario, the communication is established between the Adobe Flash Media Server (FMS) and the Client Flash Player. RTMP protocol is versatile and can deliver Video and Audio (and TEXT! Don’t forget it allows for a separate text track to send along) in numerous formats and to various Devices like Mobiles (but, generally, iDevices which don’t “understand” Flash) and Web Applications. The advantage of RTMP is that all Video and Audio files are sent to a swf file which can be played in a Flash Player, which in turn can be embedded in a Web Page or even Mobile Devices.
In a homely setup for the enthusiast, the Adobe Flash Media Server has to be installed first to facilitate transmission of Video or Audio data. When a Flash Player installed at the End User end makes a call to the FMS, it (the FMS) sends a swf file, which resides on the Server, back to the Player. The Video and Audio files are inserted in this swf file and therefore you can send Video or Audio in any convenient format and still playback in the same Flash Player.
RTMP Streaming, at least in a homely setup, can be achieved with relative ease. The process of installing and setting up a Flash Media Server is simple and the technology is mature (it’s been around for 10+ years now). You can transmit Video and Audio in many formats and renditions, as well as apply Security Features such as Player Verification.
Not only that: one of the most important advantages of RTMP, when it comes to Live Broadcasts, is the very low latency/delay from real time in transmission: as we’ll see into later Posts, HTTP based Technologies introduce very high delays (10+ seconds wouldn’t be surprising) and that just cannot work with really, really Live transmissions such as Sport Events, Betting Systems, Trading related Applications.
There’s more to the pack of RTMP advantages over HTTP: for as sad as it may sound, not all Devices on Earth today are cutting edge Technology. Let’s talk Set Top Boxes for example: let alone a few remarkable exceptions, we are talking about dumb boxes packed with stone age old Hardware and Firmware. These do “understand” RTMP and not many of the most recent, next Posts related , HTTP based Streaming Technologies.
On the disadvantages side of the moon, my Dear Reader, you must bear in mind that RTMP is an old Technology and therefore does not work in some environments. For example, it does not work in HTML5. This is because RTMP differs from the HTTP Protocol. Also, it doesn’t work with all iDevices as you may have discovered already if you have (more than) one like we do: Apple doesn’t like Flash for some obvious reasons.
Add to that, that RTMP may prevent users from accessing files due to blocking by Firewalls (it generally works over Ports 1935 and 443, instead of famous HTTP Port 80). Always on the Network side of things, bandwidth limitations may lead to dropped frames or jitter in video and audio: as you may discover if you have a look at RTMP’s own RFC, RTMP – unlike HTTP – lacks lots of the error checking capabilities when it comes to dropped packets.
Last but not least, and especially for us dealing with the world of CDNs on a daily basis, RTMP is always more of a no-go when applying for Streaming CDN Services: most renowned CDNs don’t support it anymore, many others have stopped increasing their own RTMP Servers footprint worldwide, and many others are slowly de-constructing their RTMP Capacity as we’re speaking. In other words, when it comes to Big Streaming capabilities, you may find yourself alone in the CDN Space – though hope is still there to date.
RTMP is an old and proven Streaming Technology. The Flash Player which is used to view Video and Audio streamed via RTMP Protocol is popular and used extensively. However, this Technology suffers from limitations. Many of these have been overcome with modified versions of the Flash, but it wouldn’t be daring to say that RTMP is nearing what CDNs love to call “End of Life” as a Streaming Technology.
The latest Adobe Flash Media Server 4.5 has actually done away with the proprietary flv format and provides HTTP Dynamic streaming and HTTP Live streaming technology. We will discuss these streaming technologies in future Posts, as well as many more others, not Adobe proprietary ones.
We hope to have shed some decent light on RTMP at an introductory level and would love to hear from you now.