The codecs changed. The job didn’t.
Every once in a while someone suggests we should get rid of RTMP; yet it long outlived its reputation for a simple reason: it still works. The ingest job never went away. What changed was what people wanted to push through it: newer codecs, HDR, multiple audio tracks. Plain RTMP couldn’t carry any of that. Enhanced RTMP can/will.
What E-RTMP changes
Plain RTMP could carry H.264 and AAC (plus a couple of others that are now defunct/irrelevant). That was enough for a decade. It’s not anymore.
E-RTMP adds modern codecs (HEVC, AV1, VP9 for video; Opus, AC-3, FLAC for audio) and HDR metadata, all signaled natively in the container. No hacks, no sidecar.
It also adds multitrack support: multiple video and audio tracks in one RTMP connection, so one encode pass can carry the full ABR ladder to the server. Timestamp precision is higher too, which matters for sync-sensitive workflows.
The transport underneath is the same. One TCP connection, one port. Same plumbing. Scotch and soda are welcome now too.
Why it matters now
The spec has been around since 2023. For a while, that’s all it was. Then tools started shipping it.
- OBS Studio: HEVC and AV1 over RTMP since v29.1. Multitrack streaming over Enhanced FLV since v30.2.
- Twitch: Enhanced Broadcasting built on E-RTMP multitrack. Encoder sends multiple quality tracks in one connection, Twitch serves ABR without transcoding.
- YouTube: Accepts HEVC and AV1 over Enhanced RTMP. Beta, still recommends H.264.
- Amazon IVS: Supports Enhanced RTMP ingest.
- OvenMediaEngine: Supports Enhanced RTMP on the server side.
- FFmpeg: Enhanced FLV branch exists. Not mainlined yet.
- GStreamer: Partial multitrack support, audio only.
Where it fits
vs plain RTMP: Backward compatible. Same connection, same port. Old clients keep working. New features need both ends to support them, but the migration is smooth: upgrade one side at a time.
vs WHIP: Different problem. WHIP replaces the transport for sub-second latency and built-in encryption. E-RTMP keeps the transport and modernizes what it carries. If latency isn’t the bottleneck, E-RTMP changes less.
vs SRT: Different layer. SRT is a transport protocol: UDP, packet retransmission, AES encryption, built for unreliable networks. E-RTMP is a container upgrade over the same TCP connection. SRT solves bad networks. E-RTMP solves old containers.
Where it gets messy (for now)
“Supports E-RTMP” doesn’t mean the same thing everywhere.
Tool support is uneven. OBS ships HEVC, AV1, and multitrack. FFmpeg has a branch, not a release. GStreamer has audio multitrack only. Most hardware encoders haven’t touched it. Check back in 2030.
Platform support varies by feature. Twitch uses multitrack for Enhanced Broadcasting but limits AV1 and HEVC to beta. YouTube accepts the codecs but ignores multitrack. Amazon IVS supports ingest but the feature set differs from Twitch’s.
Interoperability is the real gap. Two implementations can both claim E-RTMP support and still not understand each other’s multitrack layout or HDR metadata. The spec is stable. The interpretations aren’t, yet.
Meh, why bother?
Because extending what works is cheaper than replacing it. RTMP ingest is everywhere: every encoder speaks it, every platform accepts it, every ops team knows how to debug it. E-RTMP doesn’t ask you to throw that away. It’s a container spec update, not a migration project.
The rough edges are real. But the spec is shipping in production tools, and the gap is closing. If your workflow already runs on RTMP, this is the least disruptive path to modern codecs.
Try it yourself
Hey, I wanted to put together a multitrack demo. Turns out, multitrack over E-RTMP out of OBS works great if your destination is Twitch. For everything else, it’s experimental at best 🙂
Until that changes, here’s a more boring demo: streaming HEVC over E-RTMP from OBS to OvenMediaEngine. Repo here. I was hoping AV1 would also work but not yet 🙁