1. 课程导入
在边缘智能视频分析场景中，最常见的需求是：把一台网络摄像机（IPC）的 RTSP 视频流接入到边缘计算设备，实时解码成图像帧，按策略抽帧，再把帧送入 BPU（Brain Processing Unit）完成目标检测、分类等推理任务，最后输出结构化结果。这条链路看似简单，但真正落地时会遇到协议协商、解码性能、抽帧节奏、内存拷贝、推理吞吐等一系列工程问题。本课程以“旭日”系列边缘 AI 平台为背景，带你完整走通这条链路。
一、学习目标
完成本课程后，你应当能够独立完成以下任务：
- 理解 RTSP/RTP 协议在视频接入中的角色，能配置并验证一路 RTSP 流的连通性；
- 掌握基于 FFmpeg 或 GStreamer 的解码流程，理解 H.264/H.265 解码的关键参数；
- 设计合理的抽帧策略，在时延、算力与业务需求之间取得平衡；
- 掌握 BPU 推理的输入预处理、模型加载与推理调用方法；
- 能够定位“花屏、卡顿、丢帧、推理延迟高”等典型故障；
- 能够用日志与指标量化整条流水线的性能。
二、核心概念
在进入实操之前，先厘清几个贯穿全课程的核心概念，它们决定了后续所有参数与代码的取舍。
| 概念 | 含义 | 在本课程中的作用 |
|---|---|---|
| RTSP | 实时流传输控制协议，负责会话建立与流控制 | 摄像机接入的“入口”，决定拉流地址与传输方式 |
| RTP/RTCP | 承载音视频数据与传输质量反馈 | 影响丢包、抖动与时间戳对齐 |
| 解码（Decode） | 把 H.264/H.265 压缩码流还原为 YUV/RGB 图像 | 整条链路的主要 CPU 开销来源 |
| 抽帧（Frame Sampling） | 按时间或帧号间隔选取部分帧 | 控制推理频率，直接决定算力占用 |
| BPU | 面向神经网络推理的专用加速单元 | 执行模型推理，输出检测/分类结果 |
| 流水线（Pipeline） | 多阶段并行处理结构 | 决定吞吐、时延与资源利用率 |
其中，抽帧策略是最容易被忽视却最影响整体性能的环节。若每帧都推理，BPU 可能成为瓶颈；若抽帧过稀，又会漏掉关键事件。因此本课程会重点讲解“按时间抽帧”与“按帧号抽帧”的差异，以及如何结合业务场景选择。
三、整体框架
下图展示了本课程要构建的完整数据流：从摄像机 RTSP 地址出发，经过协议解析、解码、抽帧、预处理，进入 BPU 推理，最终输出结构化结果。图中同时标注了各阶段的主要资源消耗与可观测点，便于后续调优。
从图中可以看到，整条链路存在两个关键“节流点”：一是解码阶段的 CPU 占用，二是 BPU 推理的吞吐上限。抽帧正是连接两者的调节阀。理解这一点，后续所有参数调优都会变得有据可依。
四、典型场景与常见误区
假设一个园区安防场景：4 路 1080p@25fps 的 RTSP 摄像机，需要在边缘盒子上做人形检测。若不做抽帧，每秒需推理 100 帧，BPU 很可能跑不满实时；若按每 5 帧抽 1 帧，则每秒 20 帧，算力压力大幅下降，同时仍能覆盖人员走动事件。这就是“业务需求决定抽帧策略”的典型例子。
常见误区二：把抽帧写成“每 N 帧取一帧”却忽略时间戳，导致不同路视频的时间对齐错乱。
常见误区三：直接在解码输出上做推理，忽略颜色空间与尺寸转换，造成精度下降或推理报错。
下面是一段典型的 RTSP 拉流与解码参数示例，后续章节会在此基础上逐步扩展：
ffmpeg -rtsp_transport tcp \
-i rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101 \
-vf fps=5 -f rawvideo -pix_fmt nv12 -s 1920x1080 pipe:1
其中 -rtsp_transport tcp 用于规避 UDP 丢包导致的花屏，fps=5 即抽帧到 5 帧/秒，pix_fmt nv12 是 BPU 推理常用的输入格式。这些参数的选择依据，正是本课程后续要逐一展开的内容。
本课程将按照“接入—解码—抽帧—推理—调优”的顺序推进，每一节都围绕真实可运行的代码与参数展开。你现在需要建立的认知是：这不是四个孤立的技术点，而是一条有明确数据形态、资源约束和观测指标的流水线。带着这个整体框架进入后续学习，你会更容易理解每个参数为什么这样设置。