3、视频流基础：视频编码（H.264/H.265）、封装格式（RTSP/RTMP/GB28181）、帧率/分辨率/码率、视频流拉取与解码原理

多路视频流边缘AI分析系统的第一道技术关口，在于“如何高效、可靠地把摄像头画面变成算法可处理的数字帧”。视频编码、封装格式、帧率/分辨率/码率三要素，以及拉流与解码链路，共同决定了系统的带宽占用、存储成本、解码延迟和AI推理的输入质量。本章从工程实践角度拆解这四块核心知识，帮助你在边缘设备上做出合理的选型与调优决策。

3.1 视频编码：H.264与H.265的工程选型

核心原理：视频编码的本质是去除空间冗余（帧内预测、DCT变换）和时间冗余（帧间运动估计与补偿）。H.264（AVC）自2003年标准化以来，凭借成熟的编码工具和广泛的硬件支持，成为当前视频监控领域的主流。H.265（HEVC）在H.264基础上引入了更灵活的编码树单元（CTU，最大64×64）、更精细的角度预测（最多35种帧内模式）以及SAO（样点自适应补偿）等工具，在同等画质下可节省约30%~50%的码率。

判断方法：边缘AI设备选型时，不能只看压缩率。H.265的解码复杂度约为H.264的1.5~2倍，对CPU和硬件解码器要求更高。若边缘设备使用ARM Cortex-A53/A72级别的CPU且无硬件解码单元，强行解码多路H.265会导致CPU占用率飙升、帧率下降。建议按以下优先级判断：

• 硬件解码支持：查阅芯片手册确认是否支持H.265硬解（如RK3588、Jetson Orin、海思Hi3559A均支持8K H.265硬解）。
• 码率节省需求：若带宽或存储成本敏感（如4G回传、SD卡本地存储），优先H.265。
• 兼容性：若需对接第三方平台或老旧NVR，H.264仍是更稳妥的选择。

3.2 封装格式与传输协议：RTSP、RTMP与GB28181

核心原理：封装格式解决的是“编码后的视频流如何打包传输”。RTSP（实时流协议）是监控领域最通用的控制协议，它本身不传输媒体数据，而是通过RTP/RTCP承载音视频流，支持TCP/UDP两种传输模式。RTMP（实时消息协议）基于TCP，最初用于Flash播放，现在仍是直播推流的主流协议，延迟低（1~3秒），但封装开销较大。GB28181是国标协议，基于SIP（会话初始协议）进行信令控制，媒体传输使用RTP/RTCP，专为安防监控系统互联互通设计，支持注册、心跳、实时音视频、云台控制等完整功能。

操作流程：在边缘AI系统中，拉取视频流通常遵循以下步骤：

1. URL解析：解析rtsp://、rtmp://或GB28181的SIP地址，获取IP、端口、流ID等参数。
2. 信令交互：RTSP发送OPTIONS、DESCRIBE、SETUP、PLAY命令；GB28181则通过SIP INVITE协商媒体参数。
3. 媒体传输：建立RTP会话，接收RTP包，处理丢包重传（RTCP反馈）。
4. 解封装：从RTP包中提取H.264/H.265的NALU（网络抽象层单元），去除RTP头、时间戳校正。

// FFmpeg拉取RTSP流并解码为YUV帧的典型命令
ffmpeg -rtsp_transport tcp -i "rtsp://192.168.1.64:554/stream1" \
       -c:v rawvideo -pix_fmt yuv420p -f rawvideo -

案例拆解：某智慧园区项目需接入12路摄像头，其中8路为海康威视（支持RTSP和GB28181），4路为第三方品牌（仅支持RTSP）。项目初期直接使用RTSP拉流，发现部分第三方摄像头在夜间码率波动大时频繁断流。分析日志发现，这些摄像头在码率超过6Mbps时会主动断开RTSP连接。解决方案：①在FFmpeg拉流命令中增加 -buffer_size 8192 和 -max_delay 500000 参数；②对第三方摄像头统一设置码率上限为4Mbps；③增加断线自动重连逻辑（指数退避，最大重试5次）。调整后，12路视频流稳定运行72小时无中断。

3.3 帧率、分辨率与码率的三角平衡

核心原理：帧率（fps）决定时间分辨率，分辨率决定空间细节，码率决定压缩后的数据量。三者相互制约：分辨率越高、帧率越高，需要的码率越大；码率不足时，编码器会降低画质（增加量化参数QP），导致模糊和块效应。对于边缘AI分析，并非分辨率越高越好——目标检测算法通常将输入缩放到640×640或1280×720，过高的原始分辨率只会增加解码负担，而不会提升检测精度。

判断方法：根据AI任务类型选择参数组合：

• 人脸识别/车牌识别：需要高分辨率（1080P以上），帧率15fps即可，码率不低于4Mbps。
• 人员跌倒/行为分析：需要高帧率（25~30fps），分辨率720P~1080P，码率2~4Mbps。
• 车辆计数/流量统计：720P@15fps即可满足，码率可降至1.5~2Mbps。

3.4 视频流拉取与解码原理：从RTP包到YUV帧

核心原理：视频流拉取的本质是“网络接收→解封装→解码→帧输出”的流水线。以RTSP为例，RTP包到达后，需要根据RTP时间戳和序列号进行排序和去重，然后剥离RTP头，得到完整的H.264/H.265访问单元（AU）。解码器接收AU后，经过熵解码、反量化、反变换、帧内/帧间预测重建，最终输出YUV420格式的原始帧。边缘AI系统通常还需要将YUV转换为RGB（通过CUDA、NEON或OpenCV的cvtColor），并缩放到模型输入尺寸。

操作流程：一个高效的拉流解码模块应包含以下环节：

1. 网络接收：使用非阻塞Socket + 多线程（每路流一个接收线程），避免单路卡顿影响全局。
2. Jitter Buffer：缓存200~500ms的数据，平滑网络抖动，但会增加延迟。
3. 硬件解码：调用NVDEC、VAAPI或RKMPP等硬件解码接口，将编码数据直接送入GPU/NPU解码。
4. 帧池管理：预分配帧缓冲区，避免频繁内存分配导致碎片和延迟。

// 使用FFmpeg API拉流并解码的核心逻辑（伪代码）
AVFormatContext *fmt_ctx = NULL;
avformat_open_input(&fmt_ctx, url, NULL, NULL);
avformat_find_stream_info(fmt_ctx, NULL);
AVCodecContext *dec_ctx = avcodec_alloc_context3(codec);
avcodec_parameters_to_context(dec_ctx, stream->codecpar);
avcodec_open2(dec_ctx, codec, NULL);

AVPacket pkt;
AVFrame *frame = av_frame_alloc();
while (av_read_frame(fmt_ctx, &pkt) >= 0) {
    if (pkt.stream_index == video_stream_idx) {
        avcodec_send_packet(dec_ctx, &pkt);
        while (avcodec_receive_frame(dec_ctx, frame) == 0) {
            // 此处获得解码后的YUV帧，可送入AI推理
            process_frame_for_ai(frame);
        }
    }
    av_packet_unref(&pkt);
}

常见误区与复盘：

• 误区1：认为解码后的帧可以直接用于AI推理。实际上，YUV420需要转换为RGB，且模型输入通常需要归一化到[0,1]或[-1,1]，这些转换会消耗CPU资源。
• 误区2：忽略GOP（关键帧间隔）的影响。若摄像头GOP设置为4秒，则断流重连后最多需要等待4秒才能收到I帧，导致AI分析中断。建议将GOP设置为1~2秒。
• 误区3：多路视频流共用一个解码线程。当某路视频出现网络抖动时，会阻塞其他视频流的解码。正确做法是每路流独立解码线程，或使用线程池+任务队列。

视频流基础是边缘AI系统的“水管工”环节，编码格式决定数据量，封装协议决定传输方式，帧率/分辨率/码率决定画质与带宽的平衡，拉流解码决定数据能否及时送达AI引擎。在实际项目中，建议先用工具（如ffprobe）探测摄像头的编码参数，再根据边缘设备的硬件能力做适配，最后通过压测验证多路并发下的稳定性。只有把这一层打牢，后续的AI算法才能发挥出应有的效果。