流媒体系统的标准分层架构

前言

很多人学流媒体时，最容易出现一种状态：单个名词都认识，但一旦把它们放进同一条系统链路里，就开始混。

比如：

• H.264 是编码标准
• FLV、MP4 是封装格式
• RTP 是媒体传输协议
• RTCP 是质量控制协议
• RTSP 是信令协议
• RTMP 和 WebRTC 又像是“整套方案”

如果这些概念不做分层，工程里很容易出现几种典型混乱：

• 把封装和传输混成一层
• 把 RTSP 误当成真正发视频的协议
• 把 RTP、RTCP、RTSP 三者混为一谈
• 把 WebRTC 简化成“一个推流协议”

所以这篇文章不只想画一张流程图，而是想把整条流媒体系统按更专业的方式拆开：

输入层、解码层、图像处理层、编码层、封装层、信令层、媒体传输与质量控制层。

只有把这些职责真正分开，后面再看 FFmpeg、RTSP、RTP、RTCP、RTMP、WebRTC，脑子里才会有一张稳定的系统地图。

---

一、先说结论，流媒体系统为什么必须分层

流媒体系统不是单一模块，而是一条由多个阶段串起来的数据与控制链路。

这里至少同时存在几类完全不同的职责：

• 从哪里拿到原始数据
• 如何把压缩码流还原成图像帧
• 如何在图像域做增强和滤镜
• 如何把图像重新编码成压缩码流
• 如何把码流打包成适合文件或网络传输的格式
• 如何握手、建连、协商参数
• 如何真正把媒体数据发出去，以及如何反馈网络质量

这些职责如果不分层，系统设计和问题排查都会非常痛苦。

所以更专业的方式不是只画“从输入到推流”的流水线，而是要明确：

哪一层处理媒体内容，哪一层组织媒体格式，哪一层负责控制，哪一层负责真正传输。

---

二、流媒体系统的标准七层架构

下面这张图就是比较严谨、也最适合工程和面试使用的一版。

flowchart TD
    subgraph L1[1 Input layer]
        A1[Camera YUV]
        A2[Local H264 MP4]
        A3[RTSP source]
        A4[RTMP source]
    end

    subgraph L2[2 Decode parse layer]
        B1[Decoder H264 H265 AV1]
        B2[NALU parser]
    end

    subgraph L3[3 Image process layer]
        C1[Scale crop rotate]
        C2[Denoise sharpen enhance]
        C3[OSD watermark color]
    end

    subgraph L4[4 Encode layer]
        D1[H264 H265 encoder]
        D2[GOP rate control]
        D3[Output bitstream]
    end

    subgraph L5[5 Packaging payload layer]
        E1[AnnexB AVCC convert]
        E2[FLV mux]
        E3[RTP payload]
        E4[MP4 mux]
    end

    subgraph L6[6 Signaling layer]
        F1[RTSP signaling]
        F2[WebRTC signaling]
        F3[RTMP built in session]
    end

    subgraph L7[7 Transport and control layer]
        G1[RTP media]
        G2[RTCP feedback]
        G3[RTMP over TCP]
        G4[SRTP for WebRTC]
    end

    A1 --> B1
    A2 --> B1
    A3 --> B1
    A4 --> B1
    A2 --> B2

    B1 --> C1
    B1 --> C2
    B1 --> C3
    B2 --> C1
    B2 --> C2
    B2 --> C3

    C1 --> D1
    C2 --> D1
    C3 --> D1
    D1 --> D2 --> D3

    D3 --> E1
    D3 --> E2
    D3 --> E3
    D3 --> E4

    E2 --> F3 --> G3
    E3 --> F1 --> G1
    E3 --> F2 --> G4
    G1 --> G2
    G4 --> G2

这张图最重要的价值，不是节点多，而是把三件事分清了：

• 媒体内容怎么处理
• 媒体数据怎么组织
• 连接和传输怎么完成

后面所有协议和模块，基本都能被这张图归位。

---

三、第一层，多源输入层

这一层只回答一个问题：

数据从哪里来。

常见输入源包括：

• 摄像头实时采集的原始 YUV 帧
• 本地 H.264 / H.265 裸码流文件
• 本地 MP4 / MKV 文件
• 网络 RTSP 拉流源
• 网络 RTMP 拉流源
• USB 采集卡、车载视频输入等外部设备

这一层的特点是来源多样，但职责单一。它只负责把外部媒体数据引入系统，不负责解码、不负责增强、不负责编码。

从工程角度看，这一层经常对应：

• camera capture
• demux 输入源
• network input
• file input

也就是说，输入层是整条链路的入口，但不是“处理层”。

---

四、第二层，码流解析与解码层

这一层负责把压缩态媒体转换成后续可处理的数据形态。

如果输入已经是压缩码流，比如 H.264 / H.265 / AV1，那么这里会做两类事情：

1. 码流解析

   • NALU 边界解析
   • 参数集识别
   • 裸码流结构识别

2. 视频解码

   • 软解码
   • 硬件解码
   • 输出原始图像帧

这一层的最终目标是：

把压缩码流还原成原始图像帧，通常是 YUV。

这点特别重要，因为后面的滤镜、增强、缩放、水印、低照度处理，本质上都不能直接对压缩码流做。

可以把这一层的输出记成一句话：

第二层输出的是可供图像处理的裸帧，不是压缩码流。

---

五、第三层，图像预处理与画质增强滤镜层

这是很多实际工程里最有价值、也最容易被忽视的一层。

只有到了这层，媒体数据才真正变成“图像”。

因此这里可以做的事情包括：

• 缩放
• 裁剪
• 旋转
• 降噪
• 去块效应修正
• 锐化
• 暗部提亮
• 低照度增强
• 水印叠加
• OSD 文字时间戳
• 色彩校正
• 像素格式转换

flowchart LR
    A[Decoded YUV frame] --> B[Scale crop rotate]
    B --> C[Denoise enhance sharpen]
    C --> D[OSD watermark color convert]
    D --> E[Processed YUV frame]

这里最值得强调的一个原则是：

滤镜和增强通常工作在图像域，而不是压缩码流域。

也就是说，如果你拿到的是 H.264 码流，通常要先解码成 YUV，再做画质增强，最后重新编码。

这也是为什么很多人学 FFmpeg 时会发现：

• filter graph 基本都在 frame 层工作
• 编码前处理远比码流后处理常见

---

六、第四层，视频编码器层

这一层负责把经过处理的原始图像帧重新压缩成标准视频码流。

输出常见包括：

• H.264 Annex B 裸码流
• H.265 HEVC 裸码流
• AV1 压缩码流

在这一层中，编码器会完成：

• 帧类型组织
• GOP 管理
• I / P / B 帧控制
• 运动估计与预测
• 残差压缩
• 码率控制
• CABAC / CAVLC 等熵编码过程

这一层输出的核心结果可以简单记成：

重新编码后的压缩视频裸码流。

这也是后面封装层真正消费的输入。

---

七、第五层，媒体封装与载荷打包层

这一层经常被误解，但它其实非常关键。

编码层输出的是裸码流，而裸码流并不一定能直接用于文件存储或网络传输。因此这里要做的是：

把编码器输出的裸码流转换成适合目标场景的数据组织格式。

常见工作包括：

• Annex B 和 AVCC 之间的格式转换
• FLV 封装
• MP4 封装
• RTP 载荷打包

flowchart LR
    A[Encoded bitstream] --> B[AnnexB AVCC convert]
    B --> C1[FLV mux]
    B --> C2[RTP payload]
    B --> C3[MP4 mux]

这层要特别注意两个点。

1. 封装不是传输

FLV、MP4 这些是数据组织方式，不是传输协议。

2. RTP 载荷打包和 RTSP 不是一回事

RTP 这里更多体现的是媒体数据如何装进 RTP packet 的载荷结构中，而 RTSP 在职责上属于信令控制，不属于这一层。

这也是很多人第一次接触流媒体时最容易混淆的地方。

---

八、第六层，信令控制交互层

这一层不负责“发视频内容”，而负责：

• 建立会话
• 协商参数
• 控制开始和停止
• 通知对端播放哪一路流
• 协商 SDP、ICE 等连接信息

如果用最直白的话说，这一层做的是：

问路、握手、协商、控制。

1. RTSP 在这一层

RTSP 的职责是控制会话，例如：

• 请求拉流
• 请求播放
• 请求暂停
• 请求停止

它本身不是媒体数据通道。也就是说：

RTSP 负责说“我要看哪路流”，不负责把视频像 RTP 那样一包一包发出来。

2. WebRTC 信令也在这一层

WebRTC 不是单个协议，它是一个体系。建立 WebRTC 会话时，通常还需要：

• SDP 协商
• ICE 候选交换
• NAT 穿透相关协商

这些内容都属于更偏信令和连接准备的工作。

3. RTMP 在工程上常被视为集成方案

RTMP 相比 RTSP + RTP 体系，更像是把连接管理、媒体组织和 TCP 传输耦合在一起的一体化协议方案。因此在分层图里，常常会把它作为一条较紧耦合的独立链路来画。

---

九、第七层，媒体传输与质量控制层

真正把媒体数据送出去的，是这一层。

这一层应该和信令层严格分开，因为“协商连接”和“实际发送媒体”不是一回事。

1. RTP 属于媒体传输层

RTP 负责承载真正的音视频媒体数据。比如 H.264 视频经过 RTP payload 打包后，会通过 RTP 发送出去。

所以一句话区分就是：

RTP 真正发媒体数据。

2. RTCP 属于质量控制层

RTCP 和 RTP 往往配套出现，但它不负责发视频，而负责：

• 丢包率统计
• 抖动统计
• 往返时延估计
• 同步与反馈
• 发送端和接收端质量信息交换

也就是说：

RTCP 发的是控制和统计信息，不是媒体内容。

3. RTMP 在这一层通常走 TCP 可靠传输

RTMP 的媒体数据一般通过 TCP 长连接发送，因此它在传输层上和 RTP over UDP 的风格完全不同。

4. WebRTC 的媒体层常体现为 SRTP + RTP + RTCP

WebRTC 实际媒体发送时，常见可以理解成：

• RTP 负责媒体承载
• SRTP 负责安全加密传输
• RTCP 负责反馈与控制

所以它绝不是“一个简单推流协议名词”能概括完的。

---

十、RTSP、RTP、RTCP 到底应该怎么区分

这三个名词几乎是流媒体初学者最容易混的地方。

可以直接记下面这张表。

名词	本质职责	是否承载媒体数据	所属分层
RTSP	会话控制、握手、播放控制	否	信令层
RTP	承载真实音视频数据	是	媒体传输层
RTCP	统计、反馈、同步、质量控制	否	传输控制层

如果一定要压缩成一句面试答案，那就是：

• RTSP 是信令
• RTP 是发媒体数据
• RTCP 是做反馈控制

这三者一定不能混成一个概念。

---

十一、RTMP 和 WebRTC 为什么又不太一样

相比 RTSP / RTP / RTCP 这套职责拆分比较清晰的体系，RTMP 和 WebRTC 更像两套“打包好的方案”。

1. RTMP

RTMP 往往可以理解成：

• 会话管理
• FLV 风格媒体组织
• TCP 可靠传输

相对集中在一条链路里完成。

所以它在很多工程图里会被看成“更一体化”的推流方案。

2. WebRTC

WebRTC 更复杂，它不是单一协议，而是一整套实时通信体系，包括：

• 信令协商
• ICE 连通性建立
• RTP / SRTP 媒体承载
• RTCP 反馈控制

所以 WebRTC 不能简单等价于“一个推流协议”，它本质上是一个实时音视频通信框架。

---

十二、把常见名词重新归位，一次彻底理顺

下面这张表适合建立全局认知。

名词	本质	更适合放在哪一层
H.264 / H.265 / AV1	编码标准	编码层
YUV	原始图像数据	解码输出 / 图像处理输入
Annex B / AVCC	码流组织格式	封装与格式转换层
FLV / MP4	封装格式	封装层
RTSP	信令协议	信令层
RTP	媒体传输协议	传输层
RTCP	反馈控制协议	传输控制层
RTMP	一体化流媒体传输方案	信令 + 封装 + 传输链路
WebRTC	实时音视频通信体系	信令 + 传输 + 控制

有了这张表，再回头看前面的架构图，很多概念就不会再打架。

---

十三、三条典型链路，最适合拿来理解整套分层

抽象架构图要真正变成工程认知，最好看三条具体链路。

1. 摄像头到 RTMP 推流

flowchart LR
    A[Camera frame] --> B[Image process]
    B --> C[H264 encode]
    C --> D[FLV mux]
    D --> E[RTMP over TCP]

这条链路的特点是：

• 编码后直接做 FLV 封装
• 最后通过 RTMP over TCP 发送
• 常用于传统直播推流场景

2. 摄像头到 RTSP / RTP 推流

flowchart LR
    A[Camera frame] --> B[Image process]
    B --> C[H264 encode]
    C --> D[RTP payload]
    D --> E[RTSP signaling]
    E --> F[RTP media send]
    F --> G[RTCP feedback]

这条链路最能体现分层价值：

• RTSP 负责会话控制
• RTP 负责发媒体
• RTCP 负责反馈

3. 摄像头到 WebRTC 发送

flowchart LR
    A[Camera frame] --> B[Image process]
    B --> C[H264 encode]
    C --> D[RTP payload]
    D --> E[WebRTC signaling]
    E --> F[SRTP media]
    F --> G[RTCP feedback]

这条链路说明：

• WebRTC 不是只做一件事
• 它同时牵涉信令、媒体承载和反馈控制
• 实时性更强，但整体复杂度也更高

---

十四、为什么这套七层分法更适合工程实践

它最大的价值在于三点。

1. 职责边界清晰

每一层只做自己该做的事：

• 输入层不关心编码
• 解码层不关心网络传输
• 图像处理层不关心信令
• 封装层不关心会话控制
• 信令层不直接承载媒体数据
• 传输层不决定图像增强策略

这种分层会让系统设计、模块拆分、问题排查都更清楚。

2. 更符合 FFmpeg 和主流流媒体系统的实际实现思路

虽然具体工程不会总是严格按“七层文件夹”来写代码，但从职责分工上看，主流系统大体都遵循这类边界。

3. 更适合解释多协议并存场景

比如一路 H.264 码流，同时输出：

• RTMP 推流
• WebRTC 实时发送
• MP4 本地录制

这在工程上完全合理，因为：

• 编码层只产生一路统一裸码流
• 封装层可以针对不同目标做不同封装或载荷打包
• 后续分别走不同信令和传输链路

这也是很多媒体服务器和边缘设备常见的实现方式。

---

十五、一段最适合背诵的总结

如果要把这篇文章压缩成一段非常短的答案，可以这样说：

流媒体系统更合理的理解方式，不是简单的“采集、编码、推流”，而是输入层、解码层、图像处理层、编码层、封装层、信令层、媒体传输与质量控制层的分层体系。H.264/H.265 属于编码层，FLV/MP4 属于封装层，RTSP 属于信令层，RTP 负责媒体传输，RTCP 负责质量反馈，而 RTMP 和 WebRTC 更像集成度更高的流媒体方案。

---

十六、最后把整件事真正想明白

一条视频流从输入到发送，真正发生的不是“一个协议把所有事都做完”，而是多种机制协作：

• 有人负责把内容压缩成码流
• 有人负责把码流组织成适合文件或网络的格式
• 有人负责和对端协商连接
• 有人负责把媒体包真正发出去
• 还有人专门负责反馈质量和网络状态

只要你把这几种职责分开，很多以前看起来混乱的名词就会自动归位。

这也是学习流媒体最关键的一步：

先建立系统地图，再逐个深入模块。