系列文章目录
嵌入式音视频开发（零）移植ffmpeg及推流测试
嵌入式音视频开发（一）ffmpeg框架及内核解析
嵌入式音视频开发（二）ffmpeg音视频同步
嵌入式音视频开发（三）直播协议及编码器
文章目录
- 系列文章目录
- 前言
- 一、直播协议
- 1.1 RTMP与HTTP-FLV
- 1.2 RTSP协议
- 1.3 HLS协议
- 1.4 WebRTC协议
- 2. 编码器
- 2.1 H.264/AVC
- 2.2 H.265/HEVC
- 2.3 MP3和AAC
前言
本期深入解析直播协议的核心原理与编码器技术选型，重点探讨在嵌入式设备上的适配优化。通过对比RTMP、RTSP、HLS、WebRTC等协议的传输特性，结合H.264、HEVC等编码器的压缩效率，为低功耗、高实时性场景提供解决方案。
一、直播协议
| 协议 | 传输层 | 延迟 | 适用场景 | 嵌入式适配难度 |
|---|---|---|---|---|
| RTMP | TCP | 1-3s | 推流、传统直播 | 中 |
| HTTP-FLV | HTTP | 1-3s | 浏览器拉流 | 低 |
| RTSP+RTP | UDP/TCP | 0.5-2s | 监控设备、IPC | 高 |
| HLS | HTTP | 10s+ | 点播、高兼容性直播 | 低 |
| WebRTC | UDP | <1s | 实时通信、低延迟直播 | 高 |
1.1 RTMP与HTTP-FLV
RTMP（Real-Time Messaging Protocol）与 HTTP-FLV（HTTP-FLV Protocol）都是基于 FLV（Flash Video）封装格式的流媒体协议。它们的主要区别在于用途和传输方式的不同。RTMP 协议广泛应用于实时直播推流，而 HTTP-FLV 更多用于客户端播放直播流。
RTMP 协议最初由 Adobe 开发，主要用于直播视频的推送和拉取，既可以推流也可以拉流，二者的地址是一样的，格式大致为rtmp://[ip Address]:[port]/[name]，例如：rtmp://0.0.0.0:1935]/stream。尽管 RTMP 在高并发情况下可能存在性能瓶颈，如带宽和延迟问题，但因其较低的延迟和较强的错误恢复能力，它依然是直播推流的首选协议之一。特别是在实时性要求较高的应用场景中，RTMP 具有较强的优势。RTMP通信是建立在TCP长连接通道的，封装音视频数据时会强行切分数据块，再由服务端进行组合，将头部压缩减少冗余，这种操作一定程度上具有弱网抵抗能力，保障了实时性。但受Flash衰落影响，逐渐被WebRTC替代。
&emspHTTP-FLV协议基于HTTP协议实现，可以视为RTMP协议的一种变体，适用于通过HTTP协议播放直播流。与RTMP不同的是，HTTP-FLV仅用于播放，不支持推流功能。由于其依赖于HTTP协议，因此能够更好地适应Web环境下的需求。HTTP-FLV的优势在于它可以通过标准的HTTP服务器进行分发，具有更好的穿透防火墙的能力，并且可以利用现有的CDN基础设施来提高分发效率。
1.2 RTSP协议
说完RTMP协议，我们再来讲一下另一种常用的推流协议——RTSP。RTSP本身不传输数据，需配合RTP/RTCP实现流控制，通过UDP传输时需处理丢包重传逻辑。RTSP 支持推流和拉流，可以灵活地进行点播和直播操作，但与 HTTP 和 RTMP 协议相比，RTSP 协议的网络适应性较差，尤其是在 Web 环境中可谓是灾难。RTSP 的通信可以通过 TCP 或 UDP 协议进行，选择 UDP 时则需要特别处理丢包和重传机制。RTSP协议的优点在于它可以灵活地控制流媒体的播放进度，适合需要精确控制的应用场景。
1.3 HLS协议
HLS通常只用来拉流，可以进行直播、点播的功能，但严格意义上来讲，它并不是流协议。HLS的工作原理就是通过HTTP协议下载静态文件，而这些文件都是直接写入磁盘内部的。这些文件包括多个TS（Transport Stream）碎片视频文件和记录这些碎片文件地址的m3u8索引文件。典型的HLS观看地址形式为 http://[ip_address]/live.m3u8。频繁写入TS文件可能会对存储介质寿命产生影响，建议采用RAM缓存或调整切片大小以缓解这一问题。HLS的主要优点在于其广泛的兼容性和跨平台支持，但它的一个主要缺点是延迟较高，通常在10秒以上。
1.4 WebRTC协议
WebRTC协议实际上是一种基于UDP的点对点视频/语音通话协议，通过ICE框架穿透NAT，依赖STUN/TURN服务器解决对称型NAT问题。WebRTC在建立通信后以流的形式发送数据，具有极低的延迟。SDP协商中的 a=rtcp-fb 字段支持NACK、FIR等重传请求，提高了抗丢包能力。WebRTC 支持实时音视频流的推流和拉流，且协议本身不需要额外的插件或播放器，浏览器原生支持，极大地简化了开发和部署工作，其地址格式类似于 webrtc://[ip_address]:[port]/[application_name]。WebRTC 非常适合需要低延迟、实时互动的场景，但由于其点对点的特性，在大规模广播场景下可能面临带宽瓶颈和网络限制。
2. 编码器
2.1 H.264/AVC
H.264（也称为 AVC）是目前最广泛使用的视频编码标准，几乎在所有流媒体平台、视频会议、高清电视等领域得到应用。它支持多种分辨率，适用于从低分辨率到4K的各类视频，可通过硬件加速解码，广泛支持各种设备，如智能手机、平板、电视、计算机等。具有较高的压缩效率，其编码延迟较低，适用于实时视频传输。H.264编码通过加入运动补偿技术，根据前一帧或后一帧来推算当前帧，包含I帧、P帧和B帧三种类型：
- I帧：能独立播放、完整的视频帧；
- P帧：需要根据前一个I帧或者P帧才能计算最后的图像；
- B帧：同时需要前一个和后一个I帧或者P帧才能得出图像。
GOP（Group of Pictures）是指一组完整的视频帧序列，开头必须是I帧，主要用于流媒体设置，以缓解网络因素导致的画面问题。对于嵌入式硬件，可以通过启用Baseline Profile舍弃B帧来减少计算量，从而降低系统负载。除此之外，H.264 引入了环路滤波器，用来在解码过程中改善图像质量。它主要作用于去块效应（deblocking），使视频播放时更加平滑。去块滤波器会根据块的边界情况对图像进行微调，减少编码过程中的失真。
2.2 H.265/HEVC
H.265/HEVC相比H.264，在同等画质下可降低约50%的码率，支持高动态范围（HDR）视频和更高色深的色彩空间。但编码复杂度提升了3到5倍，对硬件的要求也更高。浏览器对H.265的支持有限，因此其普及程度并未达到预期。适用于4K视频及带宽受限的移动推流场景，但需评估设备的计算能力。尽管H.265的压缩效率更高，但由于其较高的计算要求，目前尚未得到广泛应用。
2.3 MP3和AAC
说完了视频编码器，我们来学习一下常见的音频编码器MP3。MP3 是最为广泛使用的音频编码格式之一，属于 MPEG-1 标准的一部分。它通过利用人耳对某些频率不敏感的特点（心理声学模型）来有效压缩音频数据，能够在低比特率下提供相对较好的音质，十分适用于流媒体传输和存储。
AAC是 MPEG-4 标准的一部分，是一种高级的音频编码标准，旨在提供比 MP3 更高的音质和压缩效率。AAC 被广泛应用于各种流媒体平台（如 YouTube、Apple Music 等），以及移动设备。适合低比特率传输，特别是在流媒体和广播中表现良好。AAC 的采样和编码方式结合了时间域和频率域的处理。具体来说，它将音频信号分成小块，然后使用窗函数（如 窗函数技术）对每个块进行时间频率转换。音频信号被分割为每帧 1024 个采样点进行处理，AAC 对这些采样点应用短时傅里叶变换（STFT）或 MDCT（修改离散余弦变换） 来将音频信号从时间域转换到频率域，这样做的目的是减少音频信号在分帧时的失真，同时改善压缩效果。
AAC 还支持多通道音频（如 5.1 声道、7.1 声道等），它通过对每个声道独立进行编码，确保多声道音频可以通过压缩方式高效传输， 使用 BSS（或称为 声道共享技术）来减少多声道音频所需的比特率，并通过时间域和频率域的联合编码提升效率。AAC 通过对不同频段应用动态范围控制，确保在各种播放设备上都能获得良好的音质
免责声明：本文参考了网上公开的部分资料，仅供学习参考使用，若有侵权或勘误请联系笔者
