Why This Matters
If you are a product manager, founder, or operations lead picking the playback side of a live product, you will still meet RTMP in 2026 — in vendor documentation, in legacy ladder diagrams, in proposals from contractors who learned the field a decade ago, and in any architecture that touches a 2015-era media server. You need to know two things: that RTMP for output is genuinely deprecated and not just unfashionable, and that picking it for greenfield delivery is a one-way trip to a dead end. This article is the canonical Block 4 reference on RTMP-as-distribution: what "distribution" means in this context, when and how RTMP died on the playback leg, why the modern web platform cannot resurrect it, where it still flickers in 2026, and what to ship in its place. The sister article — RTMP in 2026: Dead Protocol, Undying Default — covers the contribution side, where RTMP is alive and well; this article covers the egress side, where RTMP is finished.
Contribution Versus Distribution — Why The Word "RTMP" Has Two Lives
The Real-Time Messaging Protocol, abbreviated RTMP, is a TCP-based application-layer protocol that Macromedia designed in 2002 and Adobe published as an open specification in December 2012. The protocol does two jobs that look similar but are completely different at the system level. Knowing the difference is the entire point of this article.
The first job is contribution, also called ingest: an encoder running in a venue, a studio, or a phone pushes its live video stream up to a media server. This is the upstream leg. RTMP is the dominant 2026 default here — OBS Studio, Wirecast, FFmpeg, every hardware encoder from Teradek to Blackmagic Web Presenter, and every social platform from YouTube Live to TikTok still rely on RTMP for the encoder-to-server hop. Contribution is covered in detail in our RTMP in 2026 article.
The second job is distribution, also called egress or delivery: a media server hands the live stream to every viewer's player on the public internet. This is the downstream leg. RTMP used to handle this job too, when Adobe Flash Player was installed in 98 percent of browsers and Flash plus an RTMP socket was the canonical way a webpage played live video. That world ended in stages between 2010 and 2021 and is not coming back. RTMP for distribution is what this article is about.
Same protocol on the wire. Two completely different jobs on either side of the media server. Contribution lives; distribution dies. If anyone tells you "RTMP is dead", ask them which leg they mean — they are almost always right about distribution and almost always wrong about contribution.
A 19-Year Death March — How RTMP-As-Distribution Actually Died
The death of RTMP as a distribution protocol was not a single event. It was a 14-year process that started before most current streaming engineers had finished university, played out across browser vendors, hardware vendors, CDN operators, and standards bodies, and only completed in January 2021. The timeline below is the canonical version.
Figure 1. The death of RTMP-as-distribution is a 14-year arc, not a single event. Each inflection on the timeline removed one more reason a playback path could still rely on RTMP; by January 2021 none were left.
A few of these inflection points deserve a paragraph each, because they explain why the death was inevitable.
2007 — the iPhone ships without Flash. Apple's decision to omit Flash from iOS was the first event that made RTMP playback impossible on a mass-market consumer device. Steve Jobs's 2010 letter Thoughts on Flash made the rejection permanent and public. Every iPhone, iPad, and Apple TV from 2007 onwards required an alternative playback path; Apple's own answer was HTTP Live Streaming, published in 2009 and standardised as IETF RFC 8216 in 2017.
2009–2012 — HTTP-based ABR arrives. Apple shipped HLS in 2009, Microsoft shipped Smooth Streaming in 2008, Adobe shipped HTTP Dynamic Streaming in 2010, and ISO published the Dynamic Adaptive Streaming over HTTP standard — MPEG-DASH, ISO/IEC 23009-1 — in 2012. Each of these protocols delivered video over plain HTTP using a manifest plus short segments. None of them needed a plugin, all of them ran on commodity CDNs, and all of them could adapt the bitrate to the viewer's network in real time. The technical superiority over RTMP was decisive: cheaper CDN economics, no plugin, no head-of-line blocking, free adaptive bitrate, and easy cache reuse. Once the alternatives shipped, the only reason to keep RTMP on the playback side was the installed base of Flash players — and that installed base was already shrinking.
2015 — Media Source Extensions become Candidate Recommendation. W3C's Media Source Extensions, abbreviated MSE, gave JavaScript the ability to feed a sequence of media segments directly into an HTML5 element. This is the technical foundation that lets hls.js, Shaka Player, dash.js, and Video.js play HLS and DASH inside any modern browser without a plugin. MSE made plugin-based playback fundamentally obsolete; an element plus MSE plus a 200 KB JavaScript library could do everything Flash + RTMP did, on every device, with no install.
July 2017 — Adobe announces Flash EOL. Adobe, in coordination with Apple, Microsoft, Google, Facebook, and Mozilla, publicly committed to ending Flash Player on 31 December 2020. The announcement gave the entire ecosystem a three-and-a-half-year window to migrate.
December 2019 — AWS announces CloudFront RTMP shutdown. Amazon CloudFront, the largest CDN by far, told customers that all CloudFront RTMP streaming distributions would be deleted on 31 December 2020 and that requests to those endpoints would be denied. This event, more than any other, ended RTMP-as-distribution in commercial reality: if AWS will not deliver your RTMP stream to viewers, you do not have a delivery path. Akamai and Wowza issued matching guidance the same year.
26 January 2021 — Firefox 85 and Chrome 88 remove Flash support. With the last major browsers stripping the Flash plugin out of their binary, no consumer device in the Western web ecosystem could play RTMP natively. The few remaining RTMP playback paths in 2021 were inside native apps that bundled their own RTMP client; the public web was finished.
Why The Modern Web Platform Cannot Resurrect RTMP
A reader who has never written browser code might ask the reasonable question: if RTMP is technically a good protocol for live video and the browsers used to support it via Flash, why can't they just add native support today? The answer has three layers and is worth getting straight.
The browser's media stack is HTTP-shaped, not socket-shaped. A modern browser plays video by either pointing the HTML5 element at a URL (the src attribute) or by feeding bytes to a element through Media Source Extensions. Both paths assume the bytes arrive over HTTP — HTTP/1.1, HTTP/2, or HTTP/3. RTMP rides on a long-lived custom TCP socket on port 1935 with a binary handshake and a session model nothing like HTTP. Wiring that into the browser's media stack would require a parallel transport layer, a parallel session manager, a parallel codec wiring, and a parallel security model. No browser vendor has the engineering budget for this and there is no user-facing benefit that would justify it.
The codec story is wrong. RTMP, as Adobe published it in 2012, formally supports H.264 video and AAC audio and almost nothing else. The Enhanced RTMP extensions, finalised by Veovera in 2024, add HEVC, AV1, VP9, and HDR signalling, but those are codec-extension flags for ingest pipelines — every E-RTMP deployment in 2026 is contribution, not distribution. Modern browsers and televisions decode HEVC, AV1, and Dolby Vision in hardware; they expect those codecs to arrive in fMP4 segments referenced by HLS or DASH manifests, not in a custom binary container.
The security and operations model is wrong. RTMP was designed for an era of trusted Flash applications inside walled gardens. It has no native concept of certificate pinning, no native concept of fine-grained content protection, no native concept of edge caching with HTTP-style cache keys, and no native integration with the modern CDN observability stack — log analytics, real-time mid-stream switching, content steering, tokenised URLs, and so on. HLS and DASH inherit all of this for free from HTTP; RTMP would have to reinvent it.
The summary is uncomfortable for the protocol's fans: even if a browser vendor wanted to bring RTMP back, every layer of the modern web platform — transport, codec, security, observability, economics — points the wrong way. The web has moved on and is not waiting.
Where RTMP-As-Distribution Still Flickers In 2026
Honesty about the long tail: RTMP egress is not at zero in 2026. It just is not anywhere a 2026-greenfield product should plan to use. The remaining pockets are worth naming so you can recognise them in vendor diagrams.
| Where it survives | What's happening | Time horizon |
|---|---|---|
| Legacy desktop apps (pre-2015 corporate video apps, old monitoring tools, niche radio clients) | Native RTMP client embedded; the app still works, the platform behind it still serves an RTMP egress endpoint | Whatever fits its life-cycle — typically retired during the next refresh |
| Internal-network broadcast tooling | Inside a closed-network OB van or a studio LAN, RTMP is sometimes used end-to-end because every device on the LAN is controlled and the public internet does not enter the picture | Stable inside the studio; never reaches an end-user player |
| Vendor compatibility bridges | A handful of media servers expose an RTMP playback endpoint for "compatibility with old clients" — these are documented as legacy and deprecation-tracked | Removed over the next 1–3 product cycles |
| Pirated-content distribution chains | Some pirate streaming sites still use RTMP because their toolchain dates from 2010 and no legitimate CDN polices it for them | Not our problem; not a product strategy |
| Cardboard surveillance and IP-camera viewers | Cheap IP camera firmware sometimes streams RTMP to a small private viewer app; the firmware predates HLS support | Replaced as cameras are refreshed |
A Worked Example — What Replaces RTMP When You Modernise
Make the comparison concrete. Suppose you inherit a 2014-vintage live-video product that ingests RTMP from a hardware encoder and also delivers RTMP to a browser-embedded Flash player on the viewer side. Flash is gone, browsers refuse the protocol, and your viewer numbers have been falling for years. What do you actually ship?
The contribution side stays. The hardware encoder keeps pushing RTMPS — the TLS-secured variant of RTMP on port 443 — to your origin server. Nothing about that hop needs to change in 2026.
The distribution side replaces. At the origin server, you transcode the RTMP-arriving stream into fragmented MP4 segments and a Common Media Application Format (CMAF) packaging. The origin then exposes two parallel delivery surfaces: an HLS manifest for browsers and Apple devices, and a DASH manifest for Android and smart TV stacks. If the product needs sub-second latency, you add a WHEP endpoint that serves the same stream over WebRTC.
The economics improve. RTMP egress required a stateful TCP socket per viewer for as long as that viewer watched. HLS / DASH egress requires a sequence of stateless HTTP GETs that any CDN caches for free. A live audience of one million viewers on RTMP would have demanded one million concurrent socket connections to your origin or to an RTMP-aware edge fleet; the same audience on HLS requires the edge to serve a 4–6 second segment file roughly 250,000 times over the course of a minute, and every edge POP can serve that file from cache. The cost gap between the two architectures is an order of magnitude in favour of HTTP — which is the actual reason the industry migrated, not the death of Flash.
The reach improves. Once you ship HLS plus DASH, your stream plays in every browser on every operating system on every device since roughly 2016 with no install. The RTMP-via-Flash audience was the audience that still had Flash; in 2026 that is zero.
The arithmetic, out loud, for a typical 1080p stream:
RTMP egress : 1 socket per viewer × 10,000 viewers = 10,000 open TCP sockets
at the origin or in an RTMP-aware edge tier.
HLS egress : 4 s segment × 15 segments/min = 1 file written to the CDN edge per
4-second chunk, served from cache to every viewer requesting it.
Origin requests: ~15 per minute, not 10,000.
Bandwidth : both deliver 6 Mbps to each viewer = 60 Gbps aggregate. CDN
commodity HTTP delivery: ~$0.005–0.020 per GB on tier-1 contracts.
RTMP-aware edge delivery: usually quoted at 3–10× the price, when
quoted at all, because the vendor has to keep a stateful tier.
You ship HLS plus DASH. You keep RTMPS on the ingest side. You retire RTMP from the egress surface entirely. That is the canonical 2026 modernisation pattern.
Common Mistake — "We'll Keep RTMP As A Fallback"
Engineers occasionally argue for keeping RTMP-as-distribution alive as a fallback path "in case HLS fails" or "for low-latency viewers". This is the wrong instinct and worth naming.
Browsers cannot play RTMP. There is no fallback path through RTMP for a viewer who already lost their HLS feed — they cannot connect to your RTMP endpoint with the player they have. The "fallback" only exists if you ship a native app that bundles an RTMP client, at which point you have built a parallel native stack to support a protocol that the open web has already replaced. The economics never work. If you actually need lower latency than HLS gives you, the correct answer in 2026 is LL-HLS, LL-DASH, or WebRTC delivery — each of them runs in a modern browser without a plugin.
Where Fora Soft Fits In
We build live-video products across video streaming, video conferencing, OTT, e-learning, telemedicine, surveillance, and AR/VR. The RTMP-distribution-retirement work shows up in our practice mainly as modernisation projects: we inherit a 2013–2016 stack that ingests RTMP and delivers it to a Flash player or a custom RTMP-aware mobile client, and we re-platform the delivery side onto HLS plus DASH, often with a WHEP endpoint for the latency-sensitive viewers. The ingest pipeline usually stays on RTMPS; only the egress changes. If you are looking at a product that still ships RTMP on the viewer side and you want a second opinion on the migration plan, talk to us.
What To Read Next
- RTMP in 2026: Dead Protocol, Undying Default — the contribution-side companion to this article.
- HLS in Depth — the canonical replacement for RTMP egress, in detail.
- The Delivery Protocol Family Tree — where every modern distribution protocol fits in the 2026 landscape.
Talk To Us / See Our Work / Download
- Talk to a streaming engineer — we will scope the migration from your current RTMP-egress stack to a 2026-ready HLS / DASH / WHEP delivery surface in a 30-minute call.
- See our case studies — live-video products we have shipped across OTT, conferencing, surveillance, and e-learning.
- Download the migration playbook — RTMP-Egress Retirement Checklist (PDF). One page, scannable, covers what to audit on the origin, the CDN, the player, and the analytics layer before you cut RTMP egress.
References
- Adobe Systems, Real-Time Messaging Protocol (RTMP) Specification 1.0, published 21 December 2012. Canonical archived copy: rtmp.veriskope.com.
- Adobe Systems, Flash & The Future of Interactive Content, end-of-life announcement, 25 July 2017.
- Adobe Systems, Adobe Flash Player EOL General Information Page, dated 31 December 2020.
- Microsoft, Adobe Flash end of support on December 31, 2020, Microsoft Lifecycle announcement.
- Amazon Web Services, Important: CloudFront RTMP Distributions will be discontinued on December 31, 2020, AWS service announcement dated 17 December 2019; deletion effective 31 December 2020.
- Mozilla Foundation, Firefox 85 release notes, 26 January 2021 (Flash plugin removed).
- Google, Chrome 88 release notes, 19 January 2021 (Flash plugin removed).
- Apple Inc., HTTP Live Streaming, original draft 2009, formalised as IETF RFC 8216, August 2017.
- ISO/IEC, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats, ISO/IEC 23009-1:2022 (current edition).
- ISO/IEC, Common Media Application Format (CMAF) for segmented media, ISO/IEC 23000-19:2020.
- W3C, Media Source Extensions, Candidate Recommendation Snapshot 2024-11-05.
- W3C, HTML — The video element, HTML Living Standard, current.
- Veovera Software Organization, Enhanced RTMP v2 Release Version, 2024.
- Steve Jobs, Thoughts on Flash, public letter, April 2010.
(References 1–7 establish the cancellation timeline and are the primary sources for §"A 19-Year Death March"; references 8–13 establish the technical replacement stack and ground §"Why The Modern Web Platform Cannot Resurrect RTMP". The standards documents (RFC 8216, ISO/IEC 23009-1, ISO/IEC 23000-19, W3C MSE, W3C HTML video) are the controlling sources. Vendor blogs cited in the body — Mux, Wowza, Dacast — are referenced only as confirmation of industry behaviour and never override the standards.)
