4. 开发环境搭建与首个流水线

在 IGX 平台上跑通第一条 DeepStream 流水线,关键不在于敲多少命令,而在于把"硬件、驱动、容器、配置、输入源"这五层关系理顺。IGX Orin 出厂时已经预装 JetPack 与 IGX 软件栈,GPU、NVDEC/NVENC、VIC 等硬件加速单元通过 CUDA 驱动暴露给上层;DeepStream SDK 则是在这套底座之上提供 GStreamer 插件、元数据结构和参考应用。理解这条依赖链,后面的安装与排错才有依据。

一、安装路径选择:本地 apt 还是容器

DeepStream 在 IGX 上有两种主流部署方式。第一种是本地 apt 安装,直接在系统里装 deepstream-6.x 包,优点是插件路径固定、调试方便,缺点是依赖与系统版本强绑定,升级 JetPack 时容易冲突。第二种是 NVIDIA 官方 NGC 容器,镜像如 nvcr.io/nvidia/deepstream:6.4-triton-multiarch,把 SDK、TensorRT、Triton 全部封装好,通过 --runtime=nvidia 把 GPU 与编解码器透传进容器。工程上更推荐容器方式,因为它把"环境"变成可复现的镜像,避免不同 IGX 设备之间出现版本漂移。

容器运行前需要确认两件事:一是 Docker 已启用 NVIDIA runtime,可用 docker info | grep -i runtime 看到 nvidia;二是宿主机已安装与 JetPack 匹配的驱动,容器内 nvidia-smi 能正常输出。若使用 RTSP 输入,还要保证容器网络为 --network=host,否则 RTSP 拉流会因 NAT 而失败。

# 拉取并启动 DeepStream 容器(示例)
docker pull nvcr.io/nvidia/deepstream:6.4-triton-multiarch
docker run --runtime=nvidia -it --rm \
  --network=host \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  -e DISPLAY=$DISPLAY \
  nvcr.io/nvidia/deepstream:6.4-triton-multiarch

二、deepstream-app 配置文件解析

DeepStream 参考应用 deepstream-app 的行为几乎完全由配置文件决定。一个典型的 source 段、streammux 段、primary-gie 段、sink 段构成了最小可用流水线。下面这张图把配置文件各段与 GStreamer 元素、硬件单元之间的对应关系画出来,便于对照修改。

deepstream-app 配置文件 → 流水线元素 → IGX 硬件映射 [source0] type=4 (RTSP) / type=1 (CSI) [streammux] batch-size / width / height [primary-gie] config-file / model-engine [tracker] ll-lib-file / ll-config-file [sink0] type=2 (RTSP) / type=1 (file) nvurisrcbin / nvcamerasrc 拉流 / 采集 nvstreammux 多路合批 nvinfer TensorRT 推理 nvtracker 目标跟踪 nvvideoconvert + sink 显示 / 编码输出 NVDEC 硬件解码 H.264 / H.265 解码 GPU 显存 / 批处理 统一 batch 内存 GPU Tensor Core INT8 / FP16 推理 GPU 计算 匈牙利匹配 / 卡尔曼 NVENC / 显示输出 H.264 编码 / HDMI 配置段决定元素拓扑,元素拓扑决定硬件占用;改配置即改流水线,无需重新编译。 排查顺序:先看 source 是否出帧 → 再看 streammux 是否合批 → 最后看 sink 是否输出

以 RTSP 输入为例,[source0] 中 type=4 表示 URI 源,uri=rtsp://admin:pass@192.168.1.64:554/Streaming/Channels/101;[streammux] 的 batch-size 要与实际路数一致,width/height 决定合批后的统一分辨率,设得过大将浪费显存;[primary-gie] 的 config-file 指向一个独立的推理配置文件,其中 onnx-file、model-engine-file、num-detected-classes 是三个最常改动的字段。首次运行会由 TensorRT 现场构建 engine,耗时可能数分钟,之后会复用 .engine 文件。

三、运行 sample 应用并验证输入

容器内 /opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/ 下自带多份配置。先用 source4_1080p_dec_infer-resnet_tracker_sgie_tiled_display_int8.txt 这类多路样例验证整机吞吐,再用单路 RTSP 配置验证拉流。运行命令形如:

deepstream-app -c source4_1080p_dec_infer-resnet_tracker_sgie_tiled_display_int8.txt

判断是否跑通,看三类信号。第一,终端是否出现 Created Pipeline 与各元素 state changed from PAUSED to PLAYING;第二,是否周期性打印 FPS 与 Perf 统计,若 FPS 长期为 0,多半是 source 未出帧;第三,sink 若为 type=2(RTSP 输出),可用 VLC 打开 rtsp://<IGX_IP>:8554/ds-test 观察画面。若使用 CSI 摄像头,type=1 配合 camera-v4l2-dev-node 指定 /dev/video0,并用 v4l2-ctl --list-devices 确认设备节点存在。

RTSP 拉流失败时,先在宿主机用 gst-launch-1.0 rtspsrc location=... ! fakesink 单独验证网络与鉴权,排除是 DeepStream 配置问题还是链路问题。

四、最小可复现检查清单

检查项命令 / 观察点通过标准
驱动与 GPUnvidia-smi显示 IGX GPU 型号与驱动版本
Docker runtimedocker info | grep -i runtime包含 nvidia
容器内 SDKdeepstream-app --version输出 DeepStream 版本号
输入源终端 FPS 统计FPS > 0 且稳定
输出VLC 打开 RTSP 或本地窗口可见带框画面