视频流与RTSP基础：视频流概念、RTSP协议原理、常见摄像头与流媒体服务器

在构建基于Raspberry Pi的视频流AI系统之前，必须先理解视频数据是如何从摄像头传输到处理单元的。视频流并非单一文件，而是连续帧序列的实时传输过程；RTSP（Real Time Streaming Protocol，实时流协议）则是控制这一传输过程的“交通指挥员”。本章将系统拆解视频流的核心概念、RTSP协议的工作机制，并对比主流摄像头与流媒体服务器的选型要点，为后续的抽帧与目标检测打下坚实的协议与硬件基础。

视频流AI系统的核心链路可概括为：摄像头采集 → 编码压缩 → 流媒体服务器分发 → 客户端（Raspberry Pi）通过RTSP拉流 → 解码抽帧 → AI推理。理解这条链路中每一层的职责与协议约束，是后续调优延迟与帧率的前提。

2.1 视频流核心概念：从连续帧到网络数据包

视频流本质上是将一系列静态图像（帧）按照时间顺序连续播放，利用人眼视觉暂留效应形成动态画面。但在网络传输中，原始视频数据量极大——以1080p@30fps为例，未压缩的RGB数据带宽需求约为 1920×1080×3字节×30 ≈ 186MB/s，远超普通网络承载能力。因此，视频流必须经过编码压缩。

2.1.1 编码压缩与帧类型

主流编码标准包括H.264（AVC）、H.265（HEVC）和MJPEG。H.264凭借高压缩比与广泛的硬件兼容性，成为IP摄像头的默认选择。编码器利用帧内与帧间预测消除冗余：I帧（关键帧）完整编码一帧画面，是随机访问的入口；P帧（预测帧）仅记录与前一帧的差异；B帧（双向预测帧）参考前后帧，压缩率最高但引入延迟。在AI抽帧场景中，I帧间隔（GOP大小）直接影响抽帧的随机性——若GOP过大，抽到P帧时仍需解码之前的I帧链，增加CPU开销。

2.1.2 封装与传输协议

编码后的视频流需要封装成适合网络传输的格式。RTSP场景下，RTP（Real-time Transport Protocol）是最常用的承载协议，它将视频分割为MTU（最大传输单元，通常1500字节）以内的数据包，并附加时间戳与序列号。RTP通常运行在UDP之上以降低延迟，但UDP丢包会导致画面花屏；若网络质量差，可切换为TCP封装（RTSP over TCP），牺牲实时性换取可靠性。下表对比了不同传输方式的特性：

2.2 RTSP协议原理：会话控制与媒体传输的分离

RTSP（RFC 2326）是一个应用层控制协议，负责建立和控制媒体会话，但它本身不传输媒体数据。RTSP的巧妙之处在于将“控制”与“数据”分离：控制指令走TCP 554端口，媒体数据走RTP/UDP端口。一个典型的RTSP会话流程如下：

1. OPTIONS：客户端询问服务器支持的指令集。
2. DESCRIBE：客户端请求媒体描述信息，服务器返回SDP（Session Description Protocol）文本，包含编码格式、分辨率、帧率、音视频轨道等参数。
3. SETUP：客户端指定接收RTP数据的端口，服务器分配会话标识符。
4. PLAY：客户端发送播放指令，服务器开始通过RTP推送媒体数据。
5. TEARDOWN：终止会话。

这种设计使得RTSP可以灵活控制播放、暂停、快进等操作，同时保持媒体传输的独立性。对于Raspberry Pi的AI应用，我们通常只关心PLAY之后的RTP数据流，但理解DESCRIBE阶段返回的SDP信息至关重要——它决定了OpenCV或GStreamer如何正确解码视频。

# 使用ffprobe查看RTSP流的SDP信息
ffprobe -v error -show_streams -select_streams v:0 rtsp://192.168.1.64:554/stream1
# 输出示例：
# codec_name=h264
# width=1920
# height=1080
# avg_frame_rate=25/1
# profile=High

2.3 常见摄像头与流媒体服务器选型

在Raspberry Pi项目中，视频源的选择直接影响系统复杂度与成本。下表对比了三种常见方案：

对于IP摄像头，RTSP URL的路径格式因厂商而异：海康通常为 /Streaming/Channels/101（主码流）和 /102（子码流）；大华多为 /cam/realmonitor?channel=1&subtype=0。建议在接入前使用VLC或ffprobe验证URL有效性。

当需要将多个摄像头汇聚或转发给多个AI处理单元时，流媒体服务器成为必要组件。MediaMTX（原rtsp-simple-server）轻量且易于配置，支持RTSP输入与WebRTC/RTMP输出；SRS（Simple Realtime Server）功能强大，适合大规模并发；Nginx-RTMP则适合与HTTP服务整合。在Raspberry Pi上，推荐使用MediaMTX，其二进制文件仅约10MB，CPU占用极低。

2.4 实战案例：从零搭建RTSP视频流测试环境

为验证本章概念，我们搭建一个最小化测试环境：使用Raspberry Pi 4B作为客户端，一台海康威视IP摄像头作为视频源，通过RTSP协议拉流并显示帧率与延迟。

背景与约束：摄像头与树莓派通过千兆交换机直连，IP分别为192.168.1.64与192.168.1.100。摄像头主码流为1080p@25fps，H.264编码，RTSP端口554。树莓派运行Raspberry Pi OS（64位），已安装OpenCV 4.5与GStreamer。

操作步骤：

1. 验证RTSP连通性：在树莓派终端执行 ffprobe rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101，确认能获取SDP信息。
2. 编写Python脚本使用OpenCV拉流并统计实际帧率：

import cv2
import time

cap = cv2.VideoCapture("rtsp://admin:password@192.168.1.64:554/Streaming/Channels/101?tcp")
if not cap.isOpened():
    print("无法打开RTSP流")
    exit()

frame_count = 0
start_time = time.time()
while frame_count < 100:
    ret, frame = cap.read()
    if not ret:
        print("读取失败")
        break
    frame_count += 1
    # 此处可插入AI推理代码

elapsed = time.time() - start_time
fps = frame_count / elapsed
print(f"实际帧率: {fps:.2f} FPS, 处理{frame_count}帧耗时{elapsed:.2f}秒")
cap.release()

结果与分析：实测帧率约为24.5 FPS，接近摄像头标称值，说明网络与解码性能充足。若帧率显著低于标称值，可能原因包括：Wi-Fi信号干扰（应改用有线）、树莓派CPU解码能力不足（可启用硬件解码）、或UDP丢包导致重传（应改用TCP）。

风险与代价：使用TCP模式虽提升了可靠性，但增加了约100-200ms延迟，对于实时性要求极高的场景（如自动驾驶）需权衡。此外，长时间运行后摄像头可能主动断开空闲会话，需在代码中实现自动重连机制。

2.5 常见误区与总结

初学者在接触RTSP时容易陷入以下误区：

• 混淆RTSP与RTP：RTSP是控制协议，RTP是数据传输协议。抓包时若只过滤RTSP端口554，会看不到媒体数据。
• 忽略GOP间隔：在抽帧做AI检测时，若GOP过大（如50帧），随机抽帧可能抽到P帧，导致解码错误或画面模糊。应优先抽取I帧或设置较小的GOP。
• 盲目追求高分辨率：4K分辨率虽清晰，但树莓派解码4K@30fps的H.264流会占用大量CPU资源，导致AI推理延迟飙升。建议在摄像头端设置子码流（如720p）用于AI分析，主码流用于录像。
• 忽视时间戳同步：RTP包携带时间戳，但OpenCV的VideoCapture会丢弃该信息。若需精确同步多路视频流，应使用GStreamer管道并提取PTS（呈现时间戳）。

总结而言，视频流与RTSP是Raspberry Pi视觉AI的“血管”与“神经”。掌握编码、封装、传输与协议交互的细节，能够帮助开发者快速定位延迟、花屏、断流等常见问题。下一阶段，我们将深入探讨如何在树莓派上高效地拉取RTSP流并进行抽帧处理，为YOLO等目标检测模型提供稳定的数据输入。