Flash Streaming Dying Out, Many CDNs Shutting Down Support For RTMP

fms4-0-mnemonicI’ve gotten a few inquiries lately from content owners asking which CDNs still support Adobe’s proprietary Flash streaming format (RTMP). Over the past 12 months, many, but not all, of the major CDNs have announced to their customers that they will soon end support for Flash streaming. Industry wide, we have seen declining requirements for RTMP for some time and with most of the major CDNs no longer investing in Flash delivery, it has allowed them to reduce a significant third-party software component from their network. Flash Media Server (FMS) been a thorn in the CDN service providers’ sides for many years operationally and killing it off is a good thing for the industry. HLS/DASH/Smooth and other HTTP streaming variants are the future.

Since it’s confusing to know which CDN may still support Flash Streaming, or for how much longer, I reached out to all the major CDNs and got details from them directly. Here’s what I was told:

  • Akamai: Akamai still supports RTMP streaming and said while they are not actively promoting the product, they have not announced an end-of-life date. Akamai said they are investing in RTMP streaming but that their investment is focused on ensuring continued reliability and efficiency for current customers.
  • Amazon: Amazon continues to support RTMP delivery via CloudFront streaming distributions, but the company has seen a consistent decrease in RTMP traffic on CloudFront over the past few years. The company doesn’t have a firm date for ending RTMP support, but Amazon is encouraging customers to move to modern, HTTP-based streaming protocols. 
  • Comcast: Comcast does not support RTMP on their CDN and chooses to support HTTP-based media and all formats of that (HLS, HDS, Smooth, etc.) The only principal requirement they see in the market that involves RTMP is for the acquisition of live mezz streams which then get transcoded into various bit-variants and HTTP-based formats.
  • Fastly: Fastly has never supported RTMP to the edge/end-user. Their stack is pure HTTP/S and while they use to support RTMP ingest, the company retired that product in favor of partnering with Anvato, Wowza, JWPlayer and others.
  • Highwinds: Highwinds made the decision to stop supporting RTMP back in 2012 in favor of HTTP and HTTPS streaming protocols and have since helped a number of customers transition away from RTMP delivery to an HTTP focus.
  • Level 3: Level 3 stopped taking on new Flash streaming customers a year ago and will be shutting down existing customers by the end of this year.
  • Limelight Networks: Limelight still supports RTMP streaming globally across their CDN. The company said their current investment focus for video delivery is in their Multi Device Media Delivery (MMD) platform which can be used to ingest live RTMP feeds and deliver RTMP, RTSP, HLS, HDS, SS and DASH output formats. Limelight is encouraging customers to move away from RTMP and to HTTP formats for stream delivery.
  • Verizon Digital Media Services: Verizon announced plans to no longer support Flash streaming come June of 2017. They are actively working to decommission the RTMP playout infrastructure based on FMS 4.5. Verizon has written their own engine to continue to support RTMP ingest and re-packaging for HLS/DASH playout that is more natively integrated with their CDN, but they will no longer support RTMP playout after that time. Verizon is no longer actively onboarding new RTMP playout customers (since June 2016).

While many of the major CDNs will discontinue support for RTMP, a lot of smaller regional CDNs still support Flash streaming, so options do exist in the market for content owners. But the writing is on the wall and content owners should take note that at some point soon, RTMP will no longer be a viable option. It’s time to start making the transition away from RTMP as a delivery platform.

  • Total Webcasting

    We have made the changes to deliver with HLS, but the latency is horrible for live Webcasting. Even with all of the tuning recommended we still have 20 to 30 seconds where rtmp had 6 seconds. Our customers are going to flip when this starts to become apparent. How can you do a live interactive Webcast with 25 seconds of latency. By the time a viewer can submit a question the presenters will have moved on to a new topic. To the average viewer this will be a step back not forward.

    • Alexander Leschinsky

      Hi Toptal Webcasting,

      I totally agree with you that 20 to 30 seconds are not sufficient for live interactive webcasts. However, as an Akamai partner we have very made very good experience with their low latency settings that allow us to achieve 8 – 10 seconds, which is much more in the range of RTMP.
      Let me know if you are interested in this.

    • The latency in HLS really has a lot to do with your segment size, you don’t have to use the Apple suggested default of 10 seconds, or was is 5 seconds? I forget. We default to 4 seconds at in our implementation at https://red5pro.com/

  • Stephan James

    My experience dealing with thousands of customer requirements over the years is that customers in the live betting industry require extra low latency encoding – so RTMP Is their only solution. There are a number of smaller CDN’s that specialise in extra Low Latency Streaming who support RTMP. The demand for RTMP is small and the throughput volume is very small but for high rolling gamblers the value is high and it is one niche in the CDN world that has not become a commodity and still requires a highly specialised service. With such a high overhead on encoding for live streaming using HLS it means that we are much further away than we could be for real live streaming and the actual use case scenarios that Live Streaming can be used for. Luckily many Digital Content Rights require a built in delay before content can be viewed to support the Broadcasters prefered rights, but as we move to delivery over the Internet this issue is going to become more of an obstacle to User Experience of the Live Event particularly where Real Time interaction in involved such as betting on a live roulette table while viewing on a webcam, or commenting in realtime on a real event being streamed – if there is a delay then it spoils the experience. Humans experience Latency at the speed of light and the speed of sound, not the speed of HLS encoding.

  • Richard Blakely

    The demand for RTMP has gone up dramatically for us at Influxis as the CDNs continue to shake out those customers who depend on the protocol. As a result we continue to offer RTMP ingest and large-scale global delivery. We also provide extremely low latency with sub-second RTMP and 3-5 second HLS streaming. We’re happy to help anyone who wants an expert supported service for your RTMP streams, feel free to give us a shout!


  • So you cover 8 providers, 2 of which never supported RTMP and out of the remaining 6 only 2 stopped accepting new customers or discontinued support. So your examples don’t support your sensationalist post title. This is typical of anti-flash blog posts and its been going on like this for years…

    • danrayburn

      You don’t have to like it, but it’s a fact. My title says “many” CDNs, I didn’t say “all”. And the 8 CDNs I highlighted have the most number of customers, the largest customers, the most volume of traffic, and the most revenue. They are the best representation of the market.

      It’s not “anti-Flash”, it’s reality. Yahoo just did a whole post about getting rid of Flash. http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Moving-Beyond-Flash-The-Yahoo-HTML5-Video-Player-113635.aspx

      • Its not about like or dislike, its about your title supporting your post. 2 out of 6 isn’t “many”, its a “couple”. The “facts” are that when a media provider wants mass acceptance and low latency with proven technology, they select RTMP streaming.

        • Don’t get me wrong, I look forward to the new tech and I love some of the new stuff out here, but for the browser providers to force tech down our throats like this is just self serving bs imho.

  • Chris Allen

    My thoughts on the subject. https://blog.red5pro.com/cdns-rtmp-and-the-future-of-low-latency-streaming/. Basically latency matters, and the move towards HTTP based protocols breaks the very type of live interaction that’s emerging in live streaming.

  • Although Flash will be discontinued, RTMP is still very much alive and being used as a primary live ingest format for many use cases like user generated content. Youtube, Facebook live and Periscope are using it. We embrace it and connect our H5Live plugin-free HTML5 playout technology to it with end-to-end latencies of 1-2s on any browser, including Safari on iOS10. https://www.nanocosmos.de/blog/2016/09/h5live-player-low-latency-replaces-flash-player-plugin-low-latency-browser-playout-guaranteed/

    • Matthew

      So the player falls back to HLS/DASH so It isn’t low latency HLS, is it RTMP or something else? I’m guessing it’s WebRTC, can it scale out say easy too for gambling, auction, etc?

      • It is not WebRTC, which we can use for broadcast and is only working on WebRTC-enabled browsers. H5Live server takes an incoming stream which can be RTMP and transmits it to HTML5 with Javascript working on all browsers. It can scale well, and auctions are a great use case. Please get directly in touch with us for a personal demo: sales@nanocosmos.de, Oliver Lietz

        • Matthew

          Well that’s what I was curious about, since “HTML5” isn’t a streaming protocol.

  • Shelly Chang

    As a manufacture of hardware encoders here at ZyCast, our customers continue to ask us for RTMP. For them, it seems to be a must have.

    However, we are providing HLS encoders as well to satisfy any need that may arise.

  • Julius Thomas

    In my opinion, rtmp is the preferred protocol for ingesting livestreams. For
    delivering streams to end-users – in fact, that we have streaming
    formats like hls, hds or dash for a long time – rtmp it is no longer
    needed for streaming to end users. And with modified settings, e.g. chunklists, gop sizes, webrtc etc. – streaming with a short delay is possible with listed formats above.

    • Ken Long

      “rtmp is the preferred protocol for ingesting livestreams” I’m curious why you prefer RTMP for ingesting livestreams. Not knowing much about the details of the protocol, it’s confusing to me that a CDN can continue to ingest RTMP streams, but a player can’t support them.

  • Laurent Gros

    As also a manufacturer of OTT encoders. I would say 90% of DIGIGRAM customers in Europe still use RTMP as an ingest protocol, the overs mainly use HLS for ingest. But on user side more and more player collect HLS and some DASH. Dailymotion CDN as suddenly stopped delivered RTMP for more than one year now (only HLS), with the discontents of some customers that faced latency issues for gambling, live gaming and on-line betting applications.