3. 视频流基础：视频编码格式、协议与AI的相爱相杀
好，咱们进入第三讲。说实话，视频流这块内容，是很多做AI推理的工程师容易忽略的。大家总觉得“视频嘛，不就是一帧一帧的图片吗？”——嗯，真这么想，到了边缘设备上，你会吃大亏的。
我个人习惯，在开始设计任何视频AI流水线之前，先搞清楚三件事：视频是怎么压缩的、怎么传过来的、以及帧率和分辨率到底怎么影响我的模型。这三件事搞不明白，后面优化性能就是瞎忙活。
3.1 视频编码格式：H.264 vs H.265
先说编码。视频为什么需要编码？说白了，原始视频数据量太大了。一帧1080p的RGB图像，大概6MB。30帧每秒，就是180MB/s。这数据量，别说边缘设备，普通PC的硬盘都扛不住。
所以我们需要编码器，把冗余信息去掉。
H.264（AVC）
H.264是现在最主流的编码格式。我在项目中遇到过，几乎所有的摄像头、NVR、视频平台都支持它。它的压缩比大概在100:1到200:1之间。
核心特点：
- 成熟稳定：硬件解码器几乎无处不在。树莓派、Jetson、RK3588，全都有硬解模块。
- 计算开销适中：解码H.264对CPU的压力相对较小。
- 缺点：同等画质下，码率比H.265高30%-50%。
H.265（HEVC）
H.265是H.264的继任者。压缩效率更高，同等画质下码率能降低一半。但代价是什么？计算复杂度翻了好几倍。
核心特点：
- 压缩率更高：带宽和存储成本更低。
- 解码更吃资源：很多老一点的边缘设备，硬解H.265会卡顿，或者干脆不支持。
- 专利授权问题：嗯，这个有点敏感。有些设备厂商因为专利费，对H.265支持得不好。
编码格式对AI的影响
这里有个关键点：AI模型推理，通常需要解码后的原始图像（YUV或RGB）。所以编码格式直接影响的是解码环节的性能。
| 编码格式 | 解码计算量 | 对AI推理延迟的影响 | 推荐场景 |
|---|---|---|---|
| H.264 | 低 | 解码延迟小，推理延迟主要取决于模型 | 大多数边缘设备，入门首选 |
| H.265 | 高 | 解码可能成为瓶颈，尤其多路视频时 | 带宽受限、硬件解码支持良好的场景 |
| MJPEG | 极低（每帧独立） | 延迟最低，但码率极高 | 对延迟极度敏感，且带宽充裕的场景 |
你想想看，如果解码环节就占了50%的CPU，那留给AI推理的资源就少得可怜了。所以，选编码格式，本质是在选解码器的性能。
3.2 视频流协议：RTSP、RTMP、WebRTC
编码搞定了，接下来是怎么把视频从摄像头传到你的AI处理单元。这里涉及三个最常见的协议。
RTSP（Real-Time Streaming Protocol）
RTSP是安防摄像头领域的事实标准。我敢说，市面上90%的IP摄像头都支持RTSP。
- 特点：它本身不传输数据，而是用来控制流媒体会话（比如播放、暂停、停止）。真正的视频数据通常通过RTP传输。
- 优势：延迟低（通常200-500ms），支持TCP和UDP。
- 劣势：防火墙穿透困难，不适合公网传输。
RTMP（Real-Time Messaging Protocol）
RTMP是Adobe家的老协议，主要用于直播推流。现在很多直播平台还在用。
- 特点：基于TCP，延迟比RTSP稍高（1-3秒）。
- 优势：推流稳定，防火墙友好。
- 劣势：逐渐被淘汰，浏览器原生不支持。
说实话，在边缘AI场景里，RTMP用得不多。除非你的视频需要先推到云端，再从云端拉回来做分析——但这样延迟就大了。
WebRTC（Web Real-Time Communication）
WebRTC是近几年最火的实时通信协议。它最大的特点是：浏览器原生支持，延迟极低（<100ms）。
- 特点：点对点通信，基于UDP，自带NAT穿透。
- 优势：延迟最低，适合交互式AI应用（比如远程操控机器人）。
- 劣势：实现复杂，需要信令服务器，对网络质量要求高。
协议对比
| 协议 | 延迟 | 适用场景 | 边缘AI推荐度 |
|---|---|---|---|
| RTSP | 200-500ms | 本地局域网摄像头拉流 | ⭐⭐⭐⭐⭐ |
| RTMP | 1-3s | 直播推流到服务器 | ⭐⭐⭐ |
| WebRTC | <100ms | 实时交互、浏览器展示 | ⭐⭐⭐⭐ |
3.3 帧率与分辨率对AI的影响
这是最容易被忽视，但影响最大的两个参数。我见过太多人，上来就搞4K 30fps，结果模型跑不动，然后抱怨硬件不行。
分辨率：精度与速度的博弈
分辨率越高，图像细节越多，模型理论上能检测到更小的目标。但代价是什么？
- 推理时间增加：输入图像越大，模型计算量越大。比如YOLOv8，输入640x640和输入1280x1280，推理时间可能差4倍。
- 内存占用飙升：高分辨率意味着更大的张量，显存/内存消耗成倍增长。
我的经验： 对于大多数边缘设备，不要直接用原始分辨率做推理。我习惯的做法是：先解码到原始分辨率，然后根据模型输入尺寸进行缩放。比如摄像头是1080p，但模型输入是640x640，那就缩放到640x640再推理。这样既保留了原始画面的视野，又控制了计算量。
帧率：不是越高越好
帧率决定了每秒处理多少帧。很多人觉得帧率越高越好，其实不一定。
- 高帧率的代价：解码压力大、推理压力大、存储压力大。
- 实际需求：对于行人检测，5fps可能就够了；对于高速运动物体（比如车辆），可能需要15-30fps。
帧率与分辨率的平衡策略
在实际项目中，我通常会这样做：
- 先确定业务需求：需要检测多小的目标？需要多快的响应？
- 再确定分辨率：根据目标大小，选择合适的分辨率。能低就不高。
- 最后确定帧率：在满足业务需求的前提下，帧率越低越好。
举个例子：
# 一个简单的帧率控制策略
import cv2
cap = cv2.VideoCapture("rtsp://camera_stream")
target_fps = 10 # 目标帧率
frame_interval = 1.0 / target_fps
while True:
start_time = time.time()
ret, frame = cap.read()
if not ret:
break
# 缩放分辨率
frame_resized = cv2.resize(frame, (640, 640))
# 推理...
# results = model(frame_resized)
# 控制帧率
elapsed = time.time() - start_time
sleep_time = max(0, frame_interval - elapsed)
time.sleep(sleep_time)
这段代码很简单，但很实用。它保证了推理不会超过目标帧率，避免了资源浪费。
3.4 总结：给AI流水线的建议
好了，这一章的内容就这些。最后给你几个实操建议：
- 编码选H.264，除非你确认硬件支持H.265硬解。
- 协议选RTSP，本地拉流最稳定。
- 分辨率不要贪高，够用就行。
- 帧率按需设定，别盲目追求30fps。
下一章，我们会聊到具体的AI模型选型。到时候你会发现，前面这些视频基础，直接决定了你的模型能不能跑起来、跑多快。嗯，咱们下章见。