2、流媒体核心概念:编解码器、封装格式、推流与拉流模型

说实话,很多刚入行的朋友一上来就急着搭服务器、推流,结果遇到花屏、卡顿、延迟高,完全摸不着头脑。其实啊,问题多半出在最基础的概念上——编解码器、封装格式、推拉流模型。今天我就把这几个核心概念掰开揉碎了讲清楚。

2.1 编解码器:H.264 与 H.265

编解码器,说白了就是压缩视频的算法。原始视频数据量巨大,不压缩根本没法传。我见过有人直接用 YUV 裸流推 RTSP,结果带宽直接爆了——嗯,那画面太美我不敢看。

2.1.1 H.264(AVC)

H.264 是目前最主流的视频编码标准。它把视频分成 I 帧、P 帧、B 帧:

  • I 帧(关键帧):完整的图像,类似 JPEG 快照。解码时必须有它。
  • P 帧(前向预测帧):只记录与前一帧的差异,压缩率高。
  • B 帧(双向预测帧):参考前后帧,压缩率最高,但计算量大。

我个人习惯在 RTSP 推流中,把 I 帧间隔设为 2 秒(比如 25fps 就是 50 帧一个关键帧)。为什么?因为如果间隔太长,拉流端刚接入时要等很久才能出图;太短又浪费带宽。这是我在做安防项目时踩过的坑。

经验之谈: 大多数 RTSP 摄像头默认 I 帧间隔是 50 或 100 帧。如果你做实时交互,建议手动设为 25-50 帧,能明显缩短首屏显示时间。

2.1.2 H.265(HEVC)

H.265 是 H.264 的升级版,压缩率能提升 30%-50%。说白了,同样的画质,码率可以砍一半。但代价是编码计算量翻倍。

我记得有一次给客户做 4K 直播,用 H.264 推流码率飙到 20Mbps,客户说卡。换成 H.265 后,8Mbps 就搞定了,画质还更好。不过要注意,很多老旧的 RTSP 播放器不支持 H.265,你得确认客户端兼容性。

特性 H.264 H.265
压缩率 基准 提升 30%-50%
编码复杂度 低 高(约 2-4 倍)
硬件支持 几乎所有设备 较新设备
适用场景 1080p 及以下 4K/8K、低带宽
避坑指南: 我曾经在项目中直接用 H.265 推流,结果客户那边的解码器不支持,画面全黑。后来我加了一层协商逻辑:先尝试 H.265,如果拉流端返回不支持,自动降级到 H.264。这个机制现在成了我的标配。

2.2 封装格式:MP4、TS、FLV

编解码器压缩的是视频内容,封装格式则是把压缩后的数据打包成文件或流。你可以把封装格式想象成一个快递箱——里面装的是 H.264/H.265 视频、AAC 音频,还有时间戳、字幕等元数据。

2.2.1 MP4

MP4 是最常见的封装格式,适合点播和本地播放。它的结构是「文件头 + 数据 + 文件尾」,播放器需要先读取文件头才能解码。这意味着——它不适合直播。为什么?因为直播是源源不断的数据流,没有完整的文件头。

不过,RTSP 推流时如果录制为 MP4 文件,那是可以的。我一般用 FFmpeg 的 -f mp4 参数来录制。

2.2.2 TS(MPEG-TS)

TS 是直播领域的「老炮儿」。它的设计初衷就是应对不可靠传输——每个 TS 包都是独立的,丢了一个包不影响后续解码。RTSP 推流中,TS 经常作为底层传输格式。

我记得做 DVB 数字电视项目时,TS 流里每个包都有 4 字节的同步头,哪怕网络抖动再厉害,解码器也能快速恢复同步。这个特性在弱网环境下特别有用。

2.2.3 FLV

FLV 是 Adobe 的格式,结构简单:文件头 + 一个个 Tag(视频/音频/脚本)。RTMP 推流用的就是 FLV 封装。虽然 RTSP 不直接使用 FLV,但很多转码服务会把 RTSP 流转成 FLV 再推给 CDN。

封装格式 适合场景 RTSP 中的角色
MP4 点播、录制 录制文件
TS 直播、广播 传输流
FLV RTMP 推流 转码中间格式

2.3 推流与拉流模型

推流和拉流,是流媒体传输的两种基本模式。你想想看,一个直播系统里,总得有发送方和接收方吧?

2.3.1 推流模型

推流,就是客户端主动把数据发送到服务器。在 RTSP 中,推流通常使用 RTSP PUBLISH 方法(或者通过 RTP 直接发送)。

流程大致是:

  1. 推流端向服务器发送 OPTIONS 请求,确认服务器能力。
  2. 发送 ANNOUNCE 描述媒体信息(编码、分辨率等)。
  3. 发送 SETUP 建立传输通道(UDP 或 TCP)。
  4. 发送 RECORD 开始推流。
  5. 持续发送 RTP 数据包。

我个人习惯用 FFmpeg 做推流测试,命令很简单:

ffmpeg -re -i input.mp4 -c copy -f rtsp rtsp://server/live/stream

这里的 -re 表示按原始帧率读取,模拟实时推流。如果不加这个参数,FFmpeg 会以最快速度推完,那就变成「秒传」了。

2.3.2 拉流模型

拉流,就是客户端主动从服务器获取数据。RTSP 拉流使用 PLAY 方法,流程类似:

  1. 发送 OPTIONS 确认。
  2. 发送 DESCRIBE 获取媒体描述(SDP)。
  3. 发送 SETUP 建立通道。
  4. 发送 PLAY 开始接收数据。

拉流端收到的是 RTP 包,需要解包、排序、解码、渲染。我常用的拉流命令:

ffplay rtsp://server/live/stream

或者用 VLC 媒体播放器,打开网络串流输入 RTSP 地址就行。

2.3.3 推拉流对比

维度 推流 拉流
发起方 发送端主动 接收端主动
服务器压力 接收数据 分发数据
延迟 低(端到端) 取决于拉流时机
典型场景 摄像头推流 播放器观看
核心要点: 推流是「数据主动上报」,拉流是「数据被动获取」。在 RTSP 协议中,推流和拉流使用不同的方法(RECORD vs PLAY),但底层传输都是 RTP。

2.4 知识体系总览

下面这张图把本章的核心概念串起来了。你看一遍,应该能对整个流程有个直观印象。

流媒体核心概念关系图 流媒体核心概念关系图 编解码器 H.264 / H.265 封装格式 MP4 / TS / FLV 推流模型 PUBLISH / RECORD 拉流模型 DESCRIBE / PLAY 压缩后数据 打包后流 服务器分发 核心流程说明: 1. 原始视频 → 编解码器压缩(H.264/H.265) 2. 压缩数据 → 封装格式打包(MP4/TS/FLV) 3. 打包后流 → 推流模型发送到服务器 4. 服务器存储/转发 → 拉流模型分发给客户端

从这张图可以看得很清楚:编解码器负责压缩,封装格式负责打包,推流模型负责发送,拉流模型负责接收。四者环环相扣,缺一不可。

我的建议: 初学者先别急着搭完整系统。拿 FFmpeg 分别做一遍推流和拉流,感受一下数据是怎么流动的。等你亲手跑通一次,这些概念就真正变成你自己的了。