无人机画面卡顿、AI 识别延迟高，问题往往不在网络，而在"编解码"。这篇文章用 5 分钟帮你搞懂：视频是怎么被压缩和还原的、软硬编解码差多少、以及怎么给你的项目选对方案。
一、为什么非要做这个测试？
先看看边缘设备做视频的三道坎：
1. 视频太大：原始 1080p 视频高达几百 Mbps～1Gbps，不压缩根本传不动。
2. 设备太弱：Jetson Orin Nano 是边缘板，CPU 算力有限，3 路视频一起来就吃紧。
3. 还要实时：无人机 / 摄像头画面要低延迟，慢一点就"卡成 PPT"，AI 识别也跟不上。
所以必须做一件事：在"又弱又小"的边缘板上，把视频压到能传、能实时、AI 能跑得动。这就是本文要测的"编解码选型"。
图 1：为什么非要做编解码测试？（原因）
二、这篇文章要帮你搞清楚什么？
我们做了一套视频编解码性能测试：用 Jetson Orin Nano 模拟真实场景，把"编解码是什么""软编还是硬编""延迟怎么压""AI 管线怎么串"这些坑全部踩了一遍。
看完你会带走三件事：
1. 编解码到底是什么，它们怎么配合工作
2. 软编、硬编、硬解的速度和资源占用差多少
3. 在自己的项目上，怎么快速判断"该用什么、不该用什么"
一句话定位：这是一篇面向新手的「视频编解码选型实测指南」。
图 2：视频编解码，其实就这三步（目标/核心概念）
三、我们是怎么测的？
图 3：测试与优化流程总览（方法）
整个测试分 6 步走：先探测硬件，再逐项对比，最后给出选型结论。下面把每一步拆开讲。
四、3 个先懂的概念
不用背术语，用人话记：
- 编码（压缩）：把原始视频"打包变小"，才能省带宽、好传输。
- 解码（还原）：把压缩后的码流"拆包还原"成画面，人才能看、AI 才能推理。
- 软编 / 软解：用 CPU 干，灵活但累；硬编 / 硬解：用芯片里的专用电路干，快且省电。
记住一句话：能请专用电路就别让 CPU 干苦力；请不到，就老老实实把 CPU 调快。
五、最重要的核心发现
先上结论，这是全文最值钱的地方：
Jetson Orin Nano 只有 NVDEC 硬件解码器，没有 NVENC 硬件编码器。
也就是说，在这类边缘设备上：
- 解码：可以用硬件，又快又省 CPU
- 编码：只能走软件（libx264 / libx265），必须学会调参
怎么发现的？不是靠经验，而是靠探测：
gst-inspect-1.0 | grep nvv4l2dec# 看有没有硬件解码 ls /dev/nvhost-nvdec# 验证解码节点存在
而硬件编码器 `nvv4l2h264enc` 根本不存在，`/dev/nvhost-msenc` 节点也没有。
选型第一步永远是：先探测，再下结论。别想当然。
六、解码：硬件为什么快？
用一段 1280×720、30fps、36.3 秒的 H.264 视频实测：
方案 | 实时速度 | 单帧耗时 | CPU 占用 |
NVDEC 硬件解码 | 16.7x 实时 | < 1ms | 极低 |
软件解码 | 明显慢 | 高 | 接近打满 |
结论很干脆：只要设备有硬解（NVDEC / nvv4l2dec / VAAPI），解码就无脑交给硬件。
七、编码：没硬编怎么办？
边缘板没有 NVENC，我们就在 CPU 上把 x264 / x265 跑出真实水位：
编码器 | 单帧耗时 | CPU 占用 | 吞吐 |
x264 | 1222 us | 14.7% | 94.2 FPS |
x265 | 923 us | 63.9% | 35.7 FPS |
注意一个反直觉点：x265 单帧编码时间比 x264 短，但 CPU 占用是 4.3 倍，整体吞吐反而只有 35.7 FPS。所以实时场景别盲目上 x265。
再用 bench_codec 扫描参数（640×360 / 2000kbps）：
扫描维度 | 结果 | 结论 |
Preset | ultrafast 1210us / fast 2707us / medium 17871us | ultrafast 比 medium 快 14.8 倍 |
分辨率 | 640×360 1275us → 1280×720 3672us | 分辨率是最敏感的编码参数 |
码率 | 1M~4M 差异 <3% | 对速度几乎无影响 |
GOP | 1~120 差异 <4% | 对速度影响很小 |
最佳平衡点：ultrafast + 640×360 + 2000k。
八、对照：有硬编会快多少？
为了看清"软编 vs 硬编"的差距，我们在带 RTX 5060 的桌面上做了对照实验：
工具 | 分辨率 | 软编 | 硬编（NVENC） |
FFmpeg | 720P | 11.5x | 38.9x |
FFmpeg | 1080P | 5.73x | 18.3x |
GStreamer | 720P | 11.9x | 50.4x |
GStreamer | 1080P | 6.74x | 11.31x |
硬件编码速度约为软件编码的 3~5 倍，CPU 占用从 90%+ 降到 15~25%。下面两张资源监视截图就是同一场景下的真实对比：
硬编资源占用（NVENC）
软编资源占用（x264，CPU 打满）
画质方面，软编 PSNR 约 49dB、硬编约 48dB，差 1dB 左右，人眼基本看不出差别。为了速度选硬编，完全 OK。
九、低延迟的秘密：B 帧
直播卡顿很多时候不是网速慢，而是编码器为了画质开了 B 帧。
H.264 的三种帧：
- I 帧：完整画面，可独立解码 → 无额外延迟
- P 帧：参考前一帧 → 小延迟
- B 帧：参考前后两帧 → 大延迟！
B 帧要"缓存未来帧"才能编码，会引入 1~2 秒缓冲。
低延迟配方：关 B 帧 + 小 GOP(15~30) + preset=ultrafast。
ffmpeg -i in.mp4 -c:v h264_nvenc -preset p1 -tune ll -bf 0 out.mp4
十、把编解码装进 AI 视频流水线
编解码只是 AI 流水线的一环。我们打通了"获取 → 解码 → 预处理 → 推理 → 后处理 → 编码 → 输出"七个环节，并做了 5 版优化：
版本 | 总耗时/帧 | 理论 FPS | 关键改动 |
v1 | 22,395 us | 44.7 | CPU 预处理 + H2D + D2H |
v2 | 12,157 us | 82.3 | cudaHostAlloc 零拷贝 |
v3 | 7,889 us | 126.8 | CUDA 预处理 |
v4 | 7,603 us | 131.5 | sigmoid 优化 |
v5 | 3,812 us | **262.3** | skip=2 隔帧推理 |
解码用硬解省下的 CPU、编码用 ultrafast 压住的时延，最终都转化成了整条链路更快的 AI 识别速度。下图为 Jetson 视频前处理全链路示意：
Jetson 视频前处理全链路示意（7 个环节 + 每步用什么硬件/软件）
十一、选型速查表
场景 | 建议 | |
解码 | 有硬解（NVDEC / nvv4l2dec / VAAPI）就无脑用硬件 | |
编码 | 有 NVENC / MPP 用硬编；没有就软编 | |
实时低延迟 | 关 B 帧 + 小 GOP + ultrafast | |
画质优先 | 同码率软编略好，但硬编差距人眼难辨 | |
推流协议 | 优先 HTTP-FLV / 低延迟 RTSP，慎选 HLS | |
第一步 | 先 `gst-inspect-1.0 \ | grep` 探测硬件能力 |
十二、总结：4 句话带走
1. 编解码 = 打包 + 拆包，中间走的是压缩后的码流。
2. 解码能硬解就硬解，NVDEC 比软解快十几倍。
3. 边缘板往往没有硬编，软编要靠 ultrafast + 低分辨率撑住实时性。
4. 直播低延迟的秘诀就一句：关 B 帧、小 GOP、用 ultrafast。
十三、相关阅读 & 系列预告
本文属于「无人机视频流实时处理」系列。如果你想完整了解从硬件到软件的实现路径，可以回看这些文章：
硬件相关：
如何从0到1完成一台巡检智能体的无人机
软件相关：
如何实现无人机视频流实时推流与处理？
视频流处理实战：RTMP拉流转推与SRS服务器部署指南
下一篇预告：
《无人机视频流系列（二）：YOLOv8 如何在 Jetson 上实现毫秒级目标检测》——我们将继续深入边缘端，拆解 TensorRT 加速背后的关键技术。
十四、附录：可复制的命令
探测硬件能力：
gst-inspect-1.0 | grep nvv4l2dec ls /dev/nvhost-nvdec
边缘端软编（低延迟）：
gst-launch-1.0 videotestsrc num-buffers=150 ! videoconvert \ ! x264enc tune=zerolatency speed-preset=ultrafast \ ! h264parse ! filesink location=test_libx264.h264
桌面 NVENC 硬编（对照）：
ffmpeg -i in.mp4 -c:v h264_nvenc -preset p1 -tune ll -bf 0 out_hw.mp4
本文数据均来自实测：边缘端 Jetson Orin Nano（NVDEC 硬解 / libx264、libx265 软编 / 七环节 AI 管线优化），对照端桌面 RTX 5060（NVENC 软/硬编 / 画质 / 时延 / 协议开销）。
