[音视频]基于h264的直播与点播技术栈整理

学习资料

acc

h264

音乐编码

视频编码

H264

简介

系统论

系统连接

核心思想：H.264是一个**「像素→比特流」的转换系统**，每个环节都在消除特定冗余。

阶段	输入	输出	系统作用
YUV色彩转换	RGB像素（摄像头/屏幕）	YUV分量（亮度+色度）	分离人眼敏感/不敏感信息
IBP帧决策	原始帧序列	帧类型标记（I/P/B）	构建时间依赖结构
预测编码	当前块+参考数据	预测残差	消除空间/时间冗余
DCT+量化	残差数据	量化后的频域系数	集中能量+舍弃高频细节
熵编码	量化系数	压缩比特流	用最短码表示高频符号

YUV

• Y：Luminance（亮度）
• U/Cb：Chrominance Blue（蓝色色度）
• V/Cr：Chrominance Red（红色色度）

YUV采样比例

采样格式	亮度（Y）	色度（U/V）	存储占比	适用场景
YUV444	全采样	全采样	1:1:1	高端影视后期
YUV422	全采样	水平减半	1:0.5:0.5	专业视频采集
YUV420	全采样	水平垂直均减半	1:0.25:0.25	主流应用（H.264/网络视频）

IBP

• I帧（关键帧, Intra-coded frame）：自包含完整图像，像书本章节开头
• P帧（预测帧, Predictive-coded frame）：参考前一帧，像「根据上页修改」的笔记
• B帧（双向帧, Bidirectionally-predictive frame）：参考前后帧，像「结合前后文推理」的填空

I帧生成策略

每个GOP(Group of Pictures,图像组)必须以I帧开头,分片则是将连续的GOP打包为单独的传输单元

触发方式	原理	应用场景
定时生成	固定间隔（如每2秒）强制插入I帧	直播（低延迟要求）
场景变化	检测到画面突变（如镜头切换、亮度骤变）时生成	影视剧（节省码率）
GOP结构控制	编码参数设定（如-g 48表示每48帧一个I帧）	点播（平衡seek与压缩率）
手动强制	推流端或编码器主动发送I帧请求（如WebRTC的PLI报文）	视频会议（修复丢包）

---

控制论

核心思想：预测是**「用历史数据减少未来不确定性」**的反馈控制过程。

帧内预测（空间预测）

• 思想：利用相邻像素的相关性，像「根据周围瓷砖猜缺失花纹」,将I帧进行压缩
• 预测模式：
  • DC模式：取周围像素平均值（适合平坦区域）
  • 水平/垂直模式：复制相邻行/列像素（适合边缘）
  • 角度模式：按特定方向延伸像素（适合渐变纹理）

帧间预测（时间预测）

• 思想：通过运动估计找到「当前块在参考帧中的位置」，像「在两页相似绘本中找相同角色」,预测出来BP帧
• 关键技术：
  • 运动矢量（MV）：描述块位移的(x,y)坐标
  • 运动补偿：根据MV从参考帧复制像素，计算残差
  • 参考帧选择：P帧用前一帧，B帧可双向参考

控制论本质：

• 帧内预测是**「空间PID」**（用邻近像素反馈修正当前块）
• 帧间预测是**「时间PID」**（用历史帧运动矢量预测未来帧）

---

信息论

核心思想：通过频域变换+量化，「保留重要信息，抛弃人类不敏感的细节」。

DCT变换（能量集中）

• 作用：将图像块从空间域转到频域，类似「把杂乱声音分解为不同频率的音符」

• 原理: 将宏块（如8×8像素）分解为64个余弦基函数的加权组合

• 特性：

  • 左上角系数代表低频（能量集中区）
  • 右下角系数代表高频（细节/噪声）

量化（信息筛选）

• 原理: 人眼对低频亮度变化敏感（如天空渐变）,对高频色度变化迟钝（如树叶纹理）

• 思想：对DCT系数「取整」，像「四舍五入购物金额」
  • 低频系数：少量化（保留多细节）
  • 高频系数：多量化（甚至归零）
• 控制参数：
  • QP（量化参数）：QP越大，量化越狠，压缩率越高，画质越差

信息论本质：

• DCT是**「信息重组」**（让数据更利于压缩）
• 量化是**「有损丢弃」**（基于人眼视觉特性）

---

CABAC压缩

使用类似哈夫曼的动态压缩算法CABAC进行动态压缩

动态压缩策略

1. 上下文建模：根据相邻块的非零系数分布，预测当前系数概率
   例：若上方块有3个非零系数，当前块大概率也有2-4个
2. 算术编码：将符号序列映射到[0,1)区间的小数，用最短比特表示高频事件
   例：连续0用0.001表示，非零系数用0.110表示

协同

理论	对应技术	核心贡献
系统论	IBP帧结构/YUV转换	定义数据流动的拓扑关系
控制论	帧内/帧间预测	通过反馈机制减少不确定性
信息论	DCT+量化+熵编码	按信息价值分配比特资源

典型案例：

• 直播场景（控制论主导）：
  • 优先P帧（低延迟），禁用B帧（减少参考依赖）
  • 大QP（高压缩），快速帧内预测（保实时性）
• 点播场景（信息论主导）：
  • 多用B帧（高压缩率），精细量化（保画质）
  • CABAC熵编码（极致比特节省）

关键参数

参数类型	常见选项/范围	作用	适用场景
码率控制模式	CBR / VBR / CRF	- CBR（恒定码率）：直播/实时通信 - VBR（可变码率）：点播/存储 - CRF（恒定质量）：平衡质量与码率	直播用CBR，点播用VBR/CRF
量化参数（QP）	0-51（越小质量越高）	直接控制量化步长，QP↑ → 码率↓ → 画质↓	CRF模式常用（如CRF 23）
GOP长度	1-250帧	I帧间隔：GOP↑ → 压缩率↑，但随机访问延迟↑	直播GOP=1-2，点播GOP=250+
帧类型决策	I / P / B帧比例	- I帧：自包含关键帧 - P帧：前向预测 - B帧：双向预测（压缩率最高但延迟高）	直播禁用B帧，点播多用B帧
预设（preset）	ultrafast → placebo	编码速度与压缩率的权衡（越慢压缩率越高）	直播用ultrafast，点播用slow
Profile	Baseline / Main / High	功能集限制：Baseline兼容性最好，High支持B帧/CABAC等高级特性	移动端用Baseline，其他用High

关键参数与画质/码率的博弈关系

调整目标	应调节参数	副作用
降低码率	QP↑ / GOP↑ / 禁用B帧	画质↓ / 随机访问延迟↑
提高画质	QP↓ / 启用B帧 / preset=slow	码率↑ / 编码速度↓
降低延迟	GOP=1 / 禁用B帧 / CBR	压缩率↓ / 带宽波动敏感
兼容旧设备	Profile=Baseline	禁用高级特性（CABAC/B帧等）

ACC

简介

AAC（Advanced Audio Coding，高级音频编码）是MPEG-4标准中的音频压缩算法，比MP3效率高30%，广泛应用于视频封装（如MP4/HLS）和流媒体（如Spotify、Netflix）。

核心目标：

• 剔除人耳听不到的频段（类似视频编码丢弃高频细节）
• 用数学模型代替原始波形（类似DCT变换）

系统论

输入输出拓扑：

模块	系统作用	视频编码对照
分帧	将音频切成1024/960样本块	视频的宏块划分（16x16）
心理声学模型	计算人耳可闻阈值+掩蔽效应	DCT量化矩阵的人眼版本
MDCT	时域→频域变换，能量集中	视频的DCT变换
TNS	时域噪声整形，抑制量化噪声	视频的去块效应滤波

系统级创新：

• 长短块切换：稳态信号用长块（1024点，高频率分辨率），瞬态信号用短块（128点，防预回声）。

---

控制论

核心思想：通过FFT分析实时调整比特分配，类似视频的码率控制。

反馈回路设计

[当前音频帧] → [FFT频谱分析] → [计算掩蔽阈值] → [动态比特分配] → [量化/编码]↑_____________纠错反馈_____________↓

• 比例控制（P）：根据频带能量分配基础比特（能量越高，比特越多）。
• 积分控制（I）：累计历史帧的掩蔽效应，平滑比特波动（如持续高频段多分配）。
• 微分控制（D）：检测瞬态信号（如鼓点），立即切换短块减少预回声。

实战参数

掩蔽阈值计

# 伪代码：计算某频带的可用比特
if (频带能量 > 绝对听阈) and (频带能量 > 邻近频带掩蔽阈值):分配比特 = base_bits * (频带能量 / 全局能量)
else:丢弃该频带

---

信息论

MDCT

• FFT的改进版：

  • 普通FFT有频谱泄漏（边界不连续），MDCT通过50%重叠窗解决此问题。
  • 公式对比：
    • FFT：X[k] = Σ x[n] * e^(-j2πkn/N) （复数输出，有正负频率）
    • MDCT：X[k] = Σ x[n] * cos[(n+0.5+N/2)(k+0.5)(2π/N)] （实数输出，无冗余）

• 能量集中示例：

  频带类型	原始能量	MDCT系数	量化后
  低频（0-200Hz）	100	95	94
  高频（10kHz+）	30	5	0

听觉哈夫曼

• 哈夫曼编码：对高频区的长串零用短码（如00）。
• 联合立体声：左/右声道相似时，只编码差值（类似视频的帧间预测）。

信息压缩率：

• 原始CD音质（1411kbps）→ AAC 128kbps，压缩比11:1，听感接近无损。

---

协同

阶段	系统论（流程）	控制论（动态）	信息论（压缩）
分帧	划分1024样本块	检测瞬态信号切换长短块	减少块间冗余
心理声学	计算掩蔽阈值	FFT反馈调节比特分配	标记可删频段
MDCT	时域→频域转换	重叠窗消除边界效应	能量集中到低频
量化/编码	输出比特流	TNS抑制量化噪声	哈夫曼+参数立体声

典型案例：

直播场景 : AAC-LC @ 64kbps，禁用长块（防延迟），控制论优先保证实时性。

音乐点播 : AAC-HE @ 128kbps，启用全频段分析，信息论最大化压缩率。

音视频同步

音视频同步是多媒体系统的核心挑战，本质是对齐两个独立的时间轴（音频流+视频流）。以下从技术原理、同步策略、常见问题三方面深入解析：

---

时间戳体系

音视频同步依赖三大时间轴：

时间轴	定义	测量单位	示例（30fps视频）
PTS	呈现时间戳（Presentation Time Stamp）	毫秒/秒	视频帧PTS=33ms, 66ms, 100ms
DTS	解码时间戳（Decoding Time Stamp）	毫秒/秒	B帧DTS可能早于PTS（需重排序）
采样时钟	音频采样点的理论播放时间	样本数/采样率	48kHz音频每样本≈20.8μs

关键概念：

• PTS > DTS：存在B帧时，需先解码后呈现（如DTS=1,2,3 → PTS=3,1,2）。
• 时间基（time_base）：将时间戳转为秒的除数（如HLS的time_base=1/90000）。

---

同步策略

基于参考时钟的同步（主流方案）

原理：主流方案,所有流参考统一时钟（如系统时钟或首个流的PTS）。

• 音频主导：
  • 音频按采样率严格播放，视频帧根据音频PTS调整渲染时机。
  • 适用场景：视频会议（Zoom）、直播推流（RTMP）。
• 视频主导：
  • 视频按帧率播放，音频重采样对齐视频PTS。
  • 适用场景：本地播放器（VLC）、点播（MP4）。
• 外部时钟：
  • 使用NTP或PTP同步多设备（如演播室多机位切换）。

基于缓冲的同步

原理：通过缓冲队列吸收抖动，动态调整播放速度。

• Jitter Buffer：
  • 音频缓冲2-5个包（抗网络抖动）。
  • 视频缓冲3-10帧（防掉帧）。

基于反馈的同步（如RTCP）

原理：接收端定期发送延迟报告，发送端动态调整。

• RTP/RTCP协议：

  • SR（Sender Report）包携带参考时钟。
  • RR（Receiver Report）包反馈延迟差。

• 调整逻辑

  接收端计算：
  delay = (当前时间 - SR发送时间) - (音频PTS - 视频PTS)
  若delay > 阈值，触发同步补偿
  

---

常见问题

问题现象	根本原因	解决方案
音画逐渐不同步	时钟漂移（如音频采样率偏差）	动态重采样音频（如FFmpeg的aresample）
视频卡顿但音频正常	视频解码性能不足或GOP过长	降低视频分辨率/帧率，或缩短GOP
口型对不上	采集端音视频时钟未对齐	硬件同步采集（如HDMI嵌入音频时间戳）
直播延迟突增	网络拥塞导致B帧堆积	禁用B帧（-bf 0），或启用低延迟模式

调试工具：

• FFmpeg：ffplay -vf "showinfo" -af "asetnsamples=44100" 显示时间戳。
• Wireshark：分析RTP/RTCP包的NTP时间戳。

总结

• 同步本质：让音频的采样时钟与视频的帧间隔在时间轴上对齐。
• 黄金法则：
  • 直播：音频主导 + 低延迟GOP（1-2帧）。
  • 点播：视频主导 + 动态重采样。
  • 容错：允许±80ms偏差（人耳敏感阈值）。

封装格式

MP4

简介
MP4 （MPEG-4 Part 14）是一种基于 ISO 标准的容器格式，广泛用于存储视频、音频、字幕和元数据。它采用“盒子（Box/Atom）”结构，支持多种编码格式（如 H.264、H.265、AAC）。

核心特点

1. 文件结构
   • moov Box：存储元数据（视频/音频的索引、时长、编码信息等）。
   • mdat Box：存储实际的音视频数据。
   • ftyp Box：标识文件兼容性（如 isom 表示标准 MP4）。
2. 优势
   • 随机访问：通过 stss（关键帧索引）实现精准拖动进度条。
   • 多轨支持：可封装视频、音频、字幕、章节等多条轨道。
   • 扩展性强：支持 3D 视频、VR 内容、DRM 加密等。
3. 典型应用
   • 视频点播（如 Netflix、YouTube 的下载文件）。
   • 本地存储（手机拍摄的视频通常是 MP4）。

示例：MP4 文件结构

[ftyp] → [moov] → [mdat]
moov 包含：→ mvhd（全局信息）→ trak（视频轨）→ tkhd（轨道头）→ mdia（媒体信息）→ stbl（采样表，含关键帧索引）→ trak（音频轨）

---

FLV

简介
FLV （Flash Video）是 Adobe 为 Flash 播放器设计的流媒体容器格式，主要用于实时传输。它采用“标签（Tag）”结构，每个 Tag 包含音视频数据或元数据。

核心特点

1. 文件结构
   • Header：文件标识（FLV 三个字符 + 版本号）。
   • Body：由连续的 Tag 组成，包括：
     • Script Tag：存储元数据（如分辨率、码率）。
     • Video Tag：H.264/VP6 视频数据。
     • Audio Tag：AAC/MP3 音频数据。
2. 优势
   • 低延迟：适合直播推流（如 RTMP 协议通常封装为 FLV）。
   • 流式传输：无需完整文件即可播放（适合网络直播）。
   • 简单解析：Tag 线性排列，解码器实现简单。
3. 局限性
   • 无内置索引：拖动进度条需外部工具生成关键帧列表。
   • 格式支持少：仅支持 H.264、VP6 视频和 AAC/MP3 音频。

典型应用

• 直播推流（如 OBS 推流到 B 站/斗鱼）。
• 早期 Flash 网页视频（现已逐步被淘汰）。

示例：FLV 文件结构

[Header] → [Script Tag] → [Video Tag] → [Audio Tag] → [Video Tag] → ...

---

对比总结

特性	MP4	FLV
结构	盒子（Box）嵌套	线性标签（Tag）
随机访问	支持（关键帧索引）	不支持（需外部索引）
多轨支持	是（视频/音频/字幕）	否（仅基础音视频）
延迟	高（适合点播）	低（适合直播）
编码支持	H.264/H.265/AV1/AAC/Opus	H.264/VP6/AAC/MP3
典型用途	电影下载、手机录像	直播推流、Flash 时代网页视频

如何选择？

• 需要 高兼容性/本地存储？选 MP4。
• 需要 低延迟直播？选 FLV。

点播

简介

编码组合：

• 视频：H.264（High Profile）

  • 启用B帧（-bf 3），GOP=250，CRF控制质量（如CRF 23）。

• 音频：AAC-HE（高效编码）

  • 码率48-192kbps，支持多声道。

分发协议：

• HLS（苹果系）：切片为TS文件（如B站、Netflix）。
• DASH（安卓/Web）：自适应码率切换（如YouTube）。

HLS

HLS（HTTP Live Streaming） 是苹果提出的基于HTTP的流媒体协议，尤其适合点播场景。

核心组件

组件	作用	示例
m3u8	播放列表文件，记录分片索引和码率信息	#EXT-X-STREAM-INF:BANDWIDTH=800000
TS分片	实际媒体数据（视频+音频），通常每2~10秒一个文件	segment_1.ts
Keyframe	关键帧（I帧）起始的分片，支持精准seek	#EXT-X-I-FRAME-STREAM-INF

工作流程

优化技术

• 分片策略 : 固定时长分片（如4秒） vs 动态分片（按GOP切割）
• 多码率适配（ABR）: 根据网络状况切换不同码率的m3u8（如720p↔1080p）
• Byte Range请求 : 通过HTTP Range头部精准拉取部分TS文件（节省带宽）

直播

简介

编码组合：

• 视频：H.264（Baseline Profile）

  • 禁用B帧（-bf 0），GOP=1~2，确保低延迟。
  • 使用CBR（恒定码率）抗网络波动。

• 音频：AAC-LC（低复杂度）

  • 采样率44.1kHz，码率64-128kbps。

推流协议：

• RTMP（基于TCP）：兼容传统CDN（如斗鱼、虎牙）。
• WebRTC（基于UDP）：超低延迟（如腾讯会议）。

RTMP

简介

RTMP（Real-Time Messaging Protocol） 是Adobe开发的基于TCP的应用层协议，专为流媒体传输设计，核心特性包括：

• 低延迟：1~3秒级传输（优于传统HTTP流）
• 双向通信：支持推流（Publish）与拉流（Play）
• 流式封装：默认传输FLV格式的音视频数据
• 协议灵活：可走明文（1935端口）或加密（RTMPS的443端口）

历史地位：Flash时代的主流直播协议，现仍用于推流到CDN或兼容旧系统。

---

协议栈

1. 传输层（TCP）

• 可靠传输：依赖TCP的重传机制保证数据完整
• 长连接：一次握手后持续传输数据（无HTTP的短连接开销）
• 缺点：拥塞控制导致高延迟（对比WebRTC的UDP）

2. 分块层（Chunk）

• 数据分块：将消息拆分为128B~64KB的Chunk（通过Set Chunk Size动态调整）
• 多路复用：同一连接可混合传输音视频/控制消息（通过Chunk Stream ID区分）

3. 消息层（Message）

消息类型	ID	作用
音频消息	0x08	传输AAC/MP3音频数据
视频消息	0x09	传输H.264/VP6视频数据
控制消息	0x04~0x07	设置带宽、分块大小、流控制指令
元数据	0x12	携带分辨率、码率等参数（onMetadata）

4. 封装层（FLV Tag）

• 视频Tag：H.264 NALU + AVCPacketType（区分关键帧/非关键帧）
• 音频Tag：AAC/MP3数据 + SoundFormat标识编码类型
• 时间戳：基于Epoch（1970年）的毫秒级绝对时间

---

传输流程

握手

• 固定3次交互：验证协议版本和网络可达性
• 无加密：明文传输（RTMPS则在此层启用TLS）

连接控制

1. 建立连接（Connect） : 发送应用名（如live）和推流密钥（可选）
2. 创建流（createStream） : 分配逻辑流ID（多流可并行）
3. 发布/播放（publish/play） : 推流端发送publish，拉流端发送play

数据传输

• 推流端：持续发送FLV Tag格式的音视频数据
• 服务器：转发流或录制为FLV文件
• 拉流端：从最近关键帧开始解码播放

---

推拉流

推流

• 编码要求
  • 视频：H.264 Baseline Profile（兼容性最佳）
  • 音频：AAC-LC（44.1kHz/48kHz）
• 关键帧间隔：建议2秒（-g 60对应60帧@30fps）
• 元数据：必须包含width/height/framerate

FFmpeg推流示例：

ffmpeg -i input.mp4 -c:v libx264 -g 60 -c:a aac -f flv rtmp://server/app/stream

拉流

• 初始缓冲：通常缓存1~2秒数据抗抖动
• 追帧策略：若延迟过高，丢弃非关键帧追赶
• 协议兼容：需支持rtmp://或http-flv（如VLC/FFplay）

---

应用场景

1. 直播推流：OBS推流到CDN（如斗鱼/B站）
2. 流媒体录制：服务器保存为FLV/MP4文件
3. 低延迟监控：摄像头RTMP推流到NVR

---

局限性

1. TCP固有缺陷：拥塞控制导致高延迟（对比WebRTC）
2. 编码限制：仅支持H.264/VP6视频和AAC/MP3音频
3. 浏览器兼容：需JavaScript转协议（如flv.js）

现代替代方案：

• 超低延迟：WebRTC（UDP+P2P）
• 高兼容性：LL-HLS（基于HTTP/2）

---

抓包分析（Wireshark）

• 过滤条件：tcp.port == 1935
• 关键字段：
  • Message Type ID：区分音视频/控制消息
  • Timestamp：同步音视频的重要依据
  • Stream ID：多流并行时的逻辑通道标识

WebRTC

---

简介

WebRTC（Web Real-Time Communication）是一套开源实时通信框架，允许浏览器、移动端和设备之间直接传输音视频和数据流，核心设计目标是：

• 无插件：原生支持浏览器（Chrome/Firefox/Safari/Edge）
• 端到端（P2P）优先：尽可能减少服务器中转
• 强加密：所有流量默认使用SRTP（AES-256）加密

---

协议栈

WebRTC 并非单一协议，而是多层协议协同工作的体系：

信令层

• 作用：协商通信参数（如IP地址、编解码格式、分辨率等）。
• 协议自由：不限定具体协议，常用：
  • WebSocket（浏览器最常用）
  • SIP（传统VoIP协议）
  • 自定义HTTP（移动端App常用）
• 数据格式：SDP（Session Description Protocol），描述媒体能力。

网络穿透层

• ICE（Interactive Connectivity Establishment）：
  自动选择最佳传输路径（P2P→STUN→TURN）。
• STUN（Session Traversal Utilities for NAT）：
  通过公网服务器获取设备的真实IP和端口，解决NAT穿透问题。
• TURN（Traversal Using Relays around NAT）：
  当P2P不可行时，通过中继服务器转发流量（牺牲性能保连通性）。

媒体传输层

• SRTP（Secure RTP）：
  加密传输音视频数据，防止窃听。
• RTCP（RTP Control Protocol）：
  反馈网络质量（丢包率、延迟、抖动），用于动态调整码率。

数据通道

• SCTP（Stream Control Transmission Protocol）：
  支持可靠/不可靠的数据传输（如文件共享、游戏指令）。
• DTLS（Datagram Transport Layer Security）：
  为SCTP提供加密，类似TLS但基于UDP。

编解码层

• 视频：VP8（默认）、H.264（Safari强制）、AV1（未来趋势）。
• 音频：Opus（自适应码率）、G.711（传统电话兼容）。

---

传输流程

建立连接

1. 信令交换 : 双方通过信令服务器交换SDP Offer和Answer，协商媒体参数。
2. ICE候选交换：收集本地网络候选（局域网IP、公网IP、TURN服务器地址），通过信令通道交换。
3. 连通性检查：ICE框架尝试所有可能的候选对（P2P优先），建立连接。
4. 媒体传输：成功连接后，直接通过SRTP传输加密音视频，或通过SCTP传输数据。

关键概念：候选（Candidate）类型

候选类型	来源	优先级
Host	本地局域网IP	最高
Server Reflexive	STUN服务器返回的公网IP	中
Relay	TURN中继服务器地址	最低

---

推拉流

推流

• 音视频采集：
  • 浏览器调用getUserMedia()获取摄像头/麦克风数据。
  • 或通过captureStream()捕获屏幕/Canvas数据。
• 媒体编码：
  • 浏览器自动按SDP协商的格式编码（如VP8 720p）。
• 传输控制：
  • 通过RTCPeerConnection.addTrack()添加音视频轨道。
  • ICE框架自动选择最优传输路径。

拉流

• 媒体解码：浏览器根据收到的SDP信息初始化解码器。
• 渲染播放：通过<video>标签的srcObject属性显示远程流。
• 自适应调整：根据RTCP反馈的丢包率动态调整分辨率/码率。

服务器中转模式

当P2P不可行时（如企业防火墙限制），需通过媒体服务器中转：

• SFU（Selective Forwarding Unit）：
  服务器只转发流，不混流（适合多人会议）。
• MCU（Multipoint Control Unit）：
  服务器混流后转发单一流（兼容性更好，延迟更高）。

---

应用场景

1. 视频会议：Zoom、Google Meet的浏览器版。
2. 直播连麦：主播与观众实时互动（替代RTMP连麦）。
3. 远程控制：基于数据通道传输指令（如远程桌面）。
4. IoT设备监控：摄像头直接向浏览器推流。

---

局限性

1. NAT穿透依赖STUN/TURN：复杂网络下需要中继服务器（增加成本）。
2. 移动端功耗高：持续编解码耗电量较大。
3. CDN兼容性差：传统CDN不支持WebRTC，需专用边缘节点。

总结：WebRTC通过多层协议协作，实现了浏览器端的零插件实时通信，其P2P优先的设计使其在延迟敏感场景（如会议、连麦）中远超RTMP等传统方案。