如果说 RTSP 是安防、IPC、NVR 和行业视频设备里绕不开的一条协议，那么 RTMP 更像是互联网直播时代留下的一条"主干道"。Flash 早已退出历史舞台，但 RTMP 并没有随之消失，OBS 推流、直播平台接入、云端转码、视频网关以及大量行业级推流 SDK 至今仍在广泛使用它。更值得关注的是，RTMP 这几年并没有停留在 H.264+AAC 的传统体系里，Enhanced RTMP 正在重新扩展它的能力边界：从 HEVC、AV1、VP9、HDR，到多音视频轨、高精度时间戳、新音频编码和 Reconnect Request，RTMP 正经历一次非常值得关注的现代化改造。
对于大牛直播SDK（SmartMediaKit）而言，RTMP 从来不只是"把 H.264 发到服务器"这么简单。推流端、播放端、多路转发、录像、软硬编解码、音视频同步、网络状态处理和跨平台适配共同组成了一条完整的媒体链路。尤其是在低延迟场景中，真正影响体验的并不只是协议名称，而是 RTMP Chunk、TCP 写入、发送队列、GOP、播放器缓冲、解码和渲染之间能不能形成一套足够精细的控制体系。
一、先说清楚：RTMP 本身并不是一个 IETF RFC
和 RTSP 不同，RTMP 并不存在一个类似 RFC 2326 或 RFC 7826 的 IETF 核心规范。我们今天所说的传统 RTMP，主要依据 Adobe 2012 年公开的 Real-Time Messaging Protocol Specification 1.0，以及配套的 AMF0、AMF3、FLV File Format 等规范。Enhanced RTMP 则由 Veovera Software Organization 推动，Adobe、Google、Twitch、OBS、FFmpeg、VideoLAN、Intel 等参与了规范讨论和实现生态建设。
但这并不意味着 RTMP 和 RFC 没有关系。RTMP 通常运行在 TCP 之上，而今天 TCP 的基础标准已经由 RFC 9293 统一整理，它取代了早期 RFC 793；如果采用 RTMPS，则安全层还涉及 TLS，目前 TLS 1.3 的最新规范已经是 RFC 9846，它在 2026 年 7 月取代 RFC 8446。换句话说，可以把 RTMP 的协议栈简单理解为：
RTMP / Enhanced RTMP
│
AMF / Audio / Video
│
RTMP Message
│
RTMP Chunk
│
┌─────────┴─────────┐
│ │
TCP TLS
RFC 9293 RFC 9846
│ │
└─────────┬─────────┘
│
IP这也是理解 RTMP 的第一步：RTMP 是应用层实时媒体协议，TCP 提供可靠、有序的字节流，TLS 可以进一步解决链路安全问题。
这样的设计带来了 RTMP 最重要的工程特点之一------它天然拥有可靠、有序传输能力，应用层不需要像 RTP/UDP 那样重新设计一整套丢包恢复机制。但反过来，TCP 在网络出现丢包时也可能因为重传和队头阻塞造成延迟累积。所以"RTMP 使用 TCP"既不是绝对优势，也不是天然缺陷，真正的问题仍然是场景和实现。
二、Handshake、Chunk Stream 和 Message：RTMP 真正的协议骨架
RTMP 建立连接后，并不是直接开始发送 FLV 视频数据，而是首先经过 Handshake。传统 RTMP 定义了 C0、C1、C2 和 S0、S1、S2 的握手流程，双方完成握手后才正式进入消息交换阶段。之后 RTMP 的核心机制便是 Chunk Stream：上层的音频、视频、命令和控制消息被切分成一个个 Chunk，然后通过同一条 TCP 连接复用发送。Adobe RTMP 规范明确指出，Chunking 的目的之一就是避免一个体积很大的低优先级消息长期阻塞音频或控制消息，同时通过压缩 Chunk Header 减少重复头部开销。
整个结构可以理解为：
TCP Connection
│
▼
RTMP Handshake
│
▼
Chunk Stream
┌────┼───────────────┐
│ │ │
▼ ▼ ▼
控制 Command Audio / Video
│ │ │
│ └── AMF0/AMF3 │
│ │
└──────── RTMP MessageRTMP Chunk Header 本身又包括 Basic Header、Message Header 和可能出现的 Extended Timestamp。Chunk Stream ID 用于区分不同逻辑数据流，Message Stream ID 则进一步关联具体消息流。由于 Chunk Size 可以动态调整，因此它实际上是 RTMP 性能调优中一个经常被忽视的参数：Chunk 太小意味着协议处理和系统调用次数增加，Chunk 太大又可能增加其他消息等待的机会。Adobe 规范也明确说明，大 Chunk 可以降低 CPU 开销，但在低带宽网络上可能延迟其他内容，而过小的 Chunk 又不适合高码率直播。
这也解释了为什么两个都声称"支持 RTMP"的 SDK，实际 CPU 消耗、首屏速度、音频连续性和弱网下的延迟可能完全不同。协议只是规则，Chunk 如何组织、什么时候发送、发送队列如何调度、TCP Buffer 如何控制，才是工程实现真正开始拉开差距的地方。
三、从 connect 到 publish/play：一条 RTMP 流到底是怎么建立的？
RTMP 不仅传输音视频，它还包含一套建立在 AMF 之上的 Command Message 机制。客户端首先通过 connect 建立 NetConnection，之后通常调用 createStream 创建逻辑流，再根据用途进入 publish 或 play。
典型的推流流程可以抽象成：
Publisher RTMP Server
│ │
│──── Handshake ─────────────────────>│
│<──────── Handshake ─────────────────│
│ │
│──── connect ────────────────────────>│
│<─── _result / onStatus ─────────────│
│ │
│──── createStream ──────────────────>│
│<─── Stream ID ──────────────────────│
│ │
│──── publish ────────────────────────>│
│<─── NetStream.Publish.Start ────────│
│ │
│════ Audio / Video / Metadata ══════>│播放端则把 publish 换成 play，随后服务器持续向客户端发送音频、视频和数据消息。RTMP 中的这些命令通常使用 AMF0 或 AMF3 编码，因此一个完整 RTMP 实现不只是"解析几个视频包"，还需要处理 NetConnection、NetStream、Transaction ID、onStatus、Metadata、Acknowledgement、Window Acknowledgement Size、Set Peer Bandwidth 等一整套状态和控制逻辑。
这也是 SmartMediaKit 一直强调模块化设计的重要原因。RTMP 信令层应该负责连接、状态和媒体消息封装，而 H.264/H.265/AAC 解码、音视频同步、录像、快照和渲染应该尽可能进入统一媒体体系。协议和媒体能力解耦之后，RTMP、RTSP、SRT、WHEP 等不同输入才能真正共享成熟的底层音视频能力，而不是每增加一个协议就重新造一套播放器。
四、传统 RTMP 最大的问题，并不是协议老，而是媒体封装老了
经典 RTMP/FLV 诞生的年代，H.264+AAC 几乎就是互联网视频的标准组合，因此传统 FLV Video Tag 使用有限的 CodecID 描述视频编码，整个生态自然围绕 AVC/H.264 构建。后来行业开始大量采用 H.265/HEVC，不同厂商曾通过扩展 CodecID 等方式解决 HEVC over RTMP，这些方案能够工作，却缺乏真正统一的产业规范。
当 AV1、VP9、HDR 以及新的音频编码进入直播领域后，继续不断占用传统 CodecID 显然不是一个优雅且可持续的方法，这正是 Enhanced RTMP 出现的重要背景。
2023 年推出的 Enhanced RTMP V1 首先解决了这个问题：通过新的增强型 Video Packet 结构和 FourCC 信令，让 hvc1、av01、vp09 等现代编码能够在 RTMP/FLV 中得到清晰表达，同时加入 HDR 等相关信息，并尽量保持对传统 RTMP 基础设施的向后兼容。OBS Studio 29.1 在 2023 年已经加入通过 Enhanced RTMP 推送 AV1/HEVC 的能力，YouTube 也是这一轮产业落地中的早期平台之一。
这里真正重要的并不只是"RTMP终于支持H.265"。
Enhanced RTMP 的思路实际上是：
传统 RTMP
H.264 / AAC
│
▼
Enhanced RTMP V1
HEVC / AV1 / VP9 / HDR
│
▼
Enhanced RTMP V2
更多视频编码
更多音频编码
FourCC
Multitrack
高精度时间戳
Metadata
Reconnect Request
能力协商它没有重新发明一条完全不同的传输协议，而是在尽可能保护现有 RTMP 生态的情况下，让媒体描述能力完成一次现代化升级。
Android平台RTMP直播播放器功能与时延测试
五、Enhanced RTMP：RTMP 的升级已经不只是"支持新编码"
截至目前，Veovera 发布的 Enhanced RTMP V2 文档版本已经达到 v2-2026-01-31-r2，并明确标记为 Release / General Availability，而不再是早期 Alpha 或 Beta 阶段。V2 的目标之一仍然是避免破坏传统 RTMP 生态，因此传统 RTMP/FLV 规范仍然是整个 E-RTMP 体系的重要组成部分。
编码扩展只是其中一部分。V2 将现代视频编码范围扩展到 VP8、VP9、HEVC、AV1、VVC 等，并进一步加入 Opus、FLAC、AC-3、E-AC-3 等音频编码，同时支持多声道音频、视频 Metadata、FourCC 信令以及音视频 Multitrack。它还进一步完善了高精度时间戳能力，在保持 RTMP 原有时间戳体系的同时，可以提供纳秒级 Offset，用于解决不同媒体容器和现代播放链路中的高精度时序问题。
另一个很值得注意的变化是 Reconnect Request 。传统直播发生服务器升级、负载迁移或节点调度时，客户端通常只能依靠断线后的被动重连；Enhanced RTMP V2 增加了由服务端通过 NetConnection.Connect.ReconnectRequest 主动要求客户端重新连接的机制，这实际上已经开始触及直播平台集群调度层面的能力。
Multitrack 则可能对未来直播架构产生更大的影响。过去典型直播链路是推流端上传一路高质量视频，服务器进行 1080P、720P、480P 等多档转码；Enhanced RTMP V2 可以让编码端直接在一条连接里发送多个视频 Track。Amazon IVS 已经在实际业务中使用 E-RTMP Multitrack，并明确支持在一个 RTMP 流中发送多个视频质量，进而降低部分服务器侧实时转码压力。
这意味着未来 RTMP 的角色有可能从：
"一路编码流的上传协议"
逐渐演变成：
"能够携带多编码、多轨道、丰富 Metadata 和现代媒体能力的直播 Ingest 总线"。
六、SmartMediaKit 如何看传统 RTMP 与 Enhanced RTMP 的兼容
大牛直播SDK（SmartMediaKit）长期以来已经形成了比较完整的 RTMP 工程体系，包括跨平台 RTMP 推流、RTMP 低延迟播放、多路 RTSP/RTMP 转 RTMP、录像、快照、音视频数据回调以及多实例能力。RTMP 播放体系不仅兼容传统 H.264，还已经覆盖 RTMP 扩展 H.265 以及 Enhanced RTMP H.265，这使得传统 RTMP 生态和新一代 HEVC 封装之间能够保持比较好的连续性。
更重要的是，SmartMediaKit 在架构上并没有把"RTMP=H.264+AAC"写死在媒体核心里，而是尽可能把协议封装和媒体处理分开：
SmartMediaKit
┌──────────────────────────────────────────┐
│ Application API │
├──────────────────────────────────────────┤
│ RTMP Publisher │ Player │ Relay │
├──────────────────────────────────────────┤
│ RTMP / Enhanced RTMP │
├──────────────────────────────────────────┤
│ Handshake │ Chunk │ Message │ AMF │
├──────────────────────────────────────────┤
│ H.264 │ H.265 │ AAC │ Enhanced HEVC ... │
├──────────────────────────────────────────┤
│ Encode / Decode │ A/V Sync │ Record │
├──────────────────────────────────────────┤
│ Windows │ Linux │ Android │ iOS │ ... │
└──────────────────────────────────────────┘这种架构对于 Enhanced RTMP 尤其重要。FourCC、Enhanced Video Header、Metadata、Multitrack 本质上应该首先是协议层和媒体描述层的扩展，而不应该迫使整个编码、解码、录像和渲染体系重新设计。对于 AV1、VVC、Enhanced Audio、完整 Multitrack 等后续能力，也更适合在统一媒体框架上逐步演进，而不是为了追逐规范一次性重构整个 SDK。
这也是一个成熟商业 SDK 与简单 Demo 的差异：Demo 关注的是"能不能发出一个 AV1 RTMP 包"，产业级 SDK 更关注的是老服务器怎么办、旧版 H.264 流怎么办、H.265 两套封装如何识别、连接能力如何协商、录像怎么保存、解码器是否存在、硬件是否支持，以及升级之后会不会破坏已有客户链路。
Enhanced RTMP 自身也非常强调这一点。V2 并没有要求修改传统 RTMP Handshake 的版本号，也没有要求改变 FLV Header Version，而是通过新增 Bitstream 结构以及 connect 中的能力信息完成自描述和协商。这种"向前增加能力、向后保留生态"的思想，与商业级 SDK 的兼容性设计实际上非常一致。
七、为什么 RTMP 依然可以做到很低的延迟？
很多开发者会形成一个简单印象：WebRTC 是低延迟，RTMP 是高延迟。这个判断如果放到最终公网直播分发链路里有一定现实基础，但如果单独看 RTMP 协议和一个经过优化的点到点播放链路，并不准确。Veovera 在整理 RTMP 旧规范时同样指出，RTMP 从设计之初就是面向低延迟实时交互和音视频传输的协议。
RTMP 最终延迟实际上来自整条链路：
Camera
↓
Capture
↓
Encoder / GOP
↓
RTMP Packetization
↓
Chunk / Send Queue
↓
TCP
↓
RTMP Receive Buffer
↓
Demux
↓
Decoder
↓
A/V Sync
↓
RenderRTMP 使用 TCP，因此网络出现严重丢包时确实可能受到重传和队头阻塞影响，这一点不能回避。但在局域网、专网、较稳定公网或者质量较好的 4G/5G 链路中，如果编码 GOP、Chunk Size、Socket Buffer、发送队列、接收缓冲、解码和渲染策略控制得足够合理，RTMP 完全可以实现非常好的实时体验。
SmartMediaKit 的低延迟设计正是从整条链路而不是单一协议参数入手。在合适的网络与编码条件下，RTMP 播放常规可以做到百毫秒级体验，典型优化场景可达到约 100～200ms 级端到端延迟。这里需要特别强调，这不是简单把播放器缓存改成 0，而是在稳定性和实时性之间寻找平衡：过大的 Buffer 会累积延迟，过小又会放大网络抖动；无限追赶时间戳可能造成花屏和音画跳变，而完全不追赶又会导致延迟持续增长。
与此同时，SmartMediaKit 的优势并不只是延迟数字。软硬解码切换、多实例播放、H.264/H.265、录像、快照、原始音视频回调、多路转发以及跨平台一致性，使 RTMP 可以真正成为业务系统里的一个模块，而不是只能打开一个 URL 的播放器。对于工业视觉、智慧安防、机器人、无人机、远程操控和行业视频汇聚而言，这种"协议能力+媒体能力+SDK 可嵌入能力"往往比单纯比较协议名称更有意义。
结语：RTMP 没有消失，而是在重新进入现代媒体体系
如果只看年龄，RTMP 的确是一条非常老的协议；如果只看浏览器播放，它甚至早已让出了舞台。但如果观察今天的直播 Ingest 生态，会发现它仍然拥有极强的生命力。OBS、云直播、推流编码器和大量媒体服务器已经形成非常庞大的 RTMP 基础设施，而 Enhanced RTMP 选择的并不是推翻这些基础设施，而是在它们之上继续演进。
从传统 RTMP 的 Handshake、Chunk Stream、AMF、NetConnection，到 Enhanced RTMP V1 的 HEVC、AV1、VP9 和 HDR，再到 Enhanced RTMP V2 的现代音频编码、FourCC、高精度时间戳、Reconnect Request 和 Multitrack，RTMP 的发展路径其实越来越清晰：保留成熟的传输和接入生态，同时解决传统 FLV 媒体模型已经跟不上现代编码技术的问题。
这对 SmartMediaKit 同样具有启发意义。RTMP 推流和播放并不会因为 WHIP/WHEP、SRT 等新协议出现而失去价值，它们解决的是不同的网络环境和产业需求。真正合理的技术路线，也不是用一个新协议否定已有协议，而是在统一的音视频内核上，让 RTMP、Enhanced RTMP、RTSP、SRT、WHIP/WHEP 等协议各自发挥最适合自己的价值。
因此，今天再理解 RTMP，已经不能只停留在：
"RTMP = TCP + H.264 + AAC"。
更准确的理解应该是：
RTMP 是一个成熟的实时媒体接入框架，而 Enhanced RTMP 正在把这个二十多年前建立的框架，重新带入 HEVC、AV1、VVC、多轨道和现代直播基础设施时代。
对于真正做实时音视频 SDK 的团队而言，协议是否流行只是表层问题。能否兼容存量生态，又能承接下一代媒体能力；能否保持低延迟，同时兼顾稳定性、性能与跨平台一致性，才是更长期的技术竞争力。
📎 CSDN官方博客：音视频牛哥-CSDN博客