RTMP Server in the era of HTTP video streaming

Given the growing popularity and support of HTTP video streaming, it may be tempting to consider Real Time Messaging Protocol (RTMP) streaming obsolete. But in many cases, working with RTMP server is still very meaningful. As soon as Macromedia first pronounced RTMP with Flash Player 6 in 2002, the brand new Macromedia Flash Communication Server MX (FCS) required to stream the evolving Flash Video (FLV) format, stream was live or VOD.

However, for FCS, licensing costs were high (up to $5,000 per server), and as a result, CDN costs were high than other proprietary streaming formats. Some manufacturers in the industry have called RTMP streaming costs a “Flash tax”. But Flash Player has been a ubiquitous introduction to desktop browsers for well over a decade, much larger than other plug-ins. Though, streaming server technology has traditionally been harder for web developers to implement, and simpler HTTP delivery has mostly been easier and more cost-effective. In 2003, Macromedia enabled Flash Player 7 to support HTTP delivery of FLV files, allowing integrators to use standard web server technology to deploy online video.

So in many ways, RTMP as a VOD transport delivery has not been a requirement for web video for more than a decade. As a video solution architect, I think of business requirements as the leader in most audio video decisions. And still, in 2014, RTMP is the de facto standard for the following use cases:

Publishing live streams from software/hardware encoders: Almost all streaming devices support RTMP to publish to CDN providers and streaming servers. Some native mobile applications also use RTMP libraries to publish live video from their mobile camera.

Near-instant search/playback: One of the benefits of RTMP streaming is its enhanced search capability. With real-time streaming, the player can search anywhere in the video with less buffering than HTTP delivery. However, to enjoy this feature, you need a Flash Player on your desktop and as such, it is not possible in mobile browsers. HTML5 browsers use HTTP domain requests to facilitate faster searching of VOD files.

Content Protection: RTMP Server can facilitate different levels of content protection, from obfuscation to true DRM. RTMP streams are not stored for playback on a desktop browser.

Adaptive Streaming: One of the preferred uses of RTMP is adaptive streaming playback, where we provide the video player with more bitrates and content resolutions, providing the best resolution at the current network speed. Some HTTP adaptive streaming technologies, such as HLS and MPEG-DASH, allow similar delivery, but RTMP may be more responsive to switching one bitrate to another. Unfortunately, there is no standard for HTTP adaptive streaming between HTML5 video-enabled browsers. As such, the Flash-based display of adaptive streaming is still a requirement for adaptive streaming.

Live Streaming Playback: While live streams do not need to be adaptive, compressed video segments apply the same principle to all live streaming playback. For desktop playback within the browser, virtually every live streaming event requires a video player that supports Flash-based rendering and RTMP playback. Apple Safari on iOS natively supports HLS, and luckily, all modern streaming servers, including the Wowza Streaming Engine, support RTMP and HLS compression.

rtmp live streaming

The requirement for a Live Streaming Flash Player will only change if MPEG-DASH appears everywhere as Flash currently. If Internet Explorer 8, 9 and 10 support is required to install live streaming, then RTMP streaming is still required. Also, if you need a delay close to zero in a live stream, then HTTP streaming will almost certainly not meet your needs while RTMP is capable; HTTP mechanisms require that multiple packets be collected on the server before being sent to the video player.

In summary, if your video workflow involves live streaming or any kind of packaged video installation, RTMP is the key to a successful video experience. HTTP delivery has already replaced most Flash VOD installs on video, but HTTP video can’t handle all RTMP video use cases.

Another important setup on Red5 Server is the Python Hosting offered to all hosting customers, with python cpanel hosting the advantage is cheaper and easier to install and run python scripts on a normal hosting. With Python Hosting and rtmp server the customer can really start a webmasters and increase a number of usages to host python scripts or even video chat or live streaming.

As my university professor used to say the computers language for the next 50 years will be python, fast, easier with multiple modules which allow any developer to start an application running python is a few short hours.

What’s better for non-peer-to-peer live streaming, WebRTC or RTMP?

It depends on your needs but the industry is moving towards to WebRTC.

RTMP is a widely used TCP based streaming solution. WebRTC is a new solution and usually works over UDP (unless TCP/TLS TURN relay is needed).

If you need streaming to browsers, then WebRTC is a clear winner in 2018 since Flash is fading out from browsers.

Regarding quality: I don’t think that there is a clear winner at this moment. Both of them has some advantages and disadvantages, however WebRTC is an emerging technology and becomes better each year, especially by introducing better codec and eliminating early bugs in browser implementations. WebRTC usually has better quality while RTMP tends to be more stable.

HLS and RTMP are well known protocols for streaming media contents over. HLS stands for HTTP live streaming and it is the application layer protocol. … The idea of HLS is to stream media over the HTTP protocol, whereas RTMP streams media over TCP or UDP protocols.

Regarding costs: WebRTC is a bit more complicated because it need proper TURN server setup to be able to stream to networks behind firewalls and it’s stack is a bit more complex (mandatory DTLS/SRTP encryption)

If you need to build a future proof solution to stream also to browsers then the definitive answer is WebRTC.