DeepStream 感知#

概述#

Jetson 平台服务提供基于 DeepStream 7.1 的感知服务，支持开箱即用的优化、实时和多流对象检测和跟踪支持。结合 SDR 和 VST 微服务，这也支持自动添加摄像头流。处理过程包括使用 NVIDIA 的 PeopleNet 模型（默认）或可选使用 YOLOv8s（如下所述）进行对象检测，然后使用 DeepStream 中提供的 NvDCF 跟踪器插件进行对象跟踪。应用程序的输出是基于 Metropolis 模式的元数据，使用 msgbroker 插件发送到 Redis 消息总线。

与标准示例容器相比，修改后的 Jetson 平台服务 DeepStream 7.1 容器具有以下更改

  • Service Maker deepstream-test5 应用程序的预编译版本

  • PeopleNet2.6 模型和校准文件，以及适用于各种 Jetson 平台和批大小的许多预编译引擎文件

  • 预编译的跟踪器引擎文件

  • 预编译的 YOLOv8s 插件和引擎文件

Jetson 平台服务使用基于新的 Service Maker 框架的示例 deepstream-test5 应用程序，该框架作为 DeepStream 7.1 的一部分受支持，用于以编程方式组装 DeepStream 管道，其源代码作为原生 DeepStream 安装和 DeepStream Docker 容器的一部分提供。传递到此应用程序的选项如下

  • -s 选项指定源列表配置文件。如果使用包含 nvmultiurisrcbin 的配置（如 AI-NVR 提供的参考配置），则启用 DeepStream 中的添加/删除 API。

  • -c 选项指定管道配置文件，其中包含程序管道中的各种组件和连接。

  • -l 选项指定模型的标签文件。

  • --perf-measurement-interval-sec 选项指定打印 fps 信息的频率（秒）。

    #example for running on Orin AGX
$ /opt/nvidia/deepstream/deepstream-7.1/service-maker/sources/apps/cpp/deepstream_test5_app/build/deepstream-test5-app -s /ds-config-files/pn26/service-maker/source-list-0_agx.yaml,/ds-config-files/pn26/service-maker/source-list-1_agx.yaml -c /ds-config-files/pn26/service-maker/ds-config-0_agx.yaml,/ds-config-files/pn26/service-maker/ds-config-1_agx.yaml -l /ds-config-files/pn26/labels.txt --perf-measurement-interval-sec 5

为了运行多个管道，您必须指定多个源列表和配置文件，并用逗号分隔，如上面的示例所示。

在 Orin AGX 和 Orin NX16 上，这些管道通过其 gie 配置文件 (config/deepstream/pn26/config_infer_primary_*) 使用 DLA 0 和 1

enable-dla=1 # 0 => disable, 1 => enable
use-dla-core=0 # dla core number => 0, 1, etc.

在 Orin NX8 上，只有一个 DLA 可用，因此只使用一个，而在 Orin Nano 上则使用 GPU。

请注意，用户也可以将传统的 test5 应用程序（默认包含在 DeepStream 7.1 容器中）作为其基于 Jetson 平台服务的系统的一部分，前提是与 Jetson 平台服务架构其余部分的集成点（在流添加 API 和 Metropolis 模式的元数据输出方面）得到保留。

DeepStream 配置文件位于 Docker Compose 仓库的 config/deepstream/pn26 文件夹中。每个配置都标有文件名末尾的设备类型 - agx、nx16、nx8 或 nano。此文件夹挂载在 DeepStream Docker 容器中。根据运行的 compose 文件（Orin AGX 的 compose_agx.yaml，Orin NX16 的 compose_nx16.yaml，Orin NX8 的 compose_nx8.yaml，Orin Nano 的 compose_nano.yaml），相应的 DeepStream 配置文件将传递到 DeepStream 应用程序。为所有支持的系统提供了 Service Maker 和传统版本的 DeepStream test5 应用程序的配置。

一个名为 SDR 的附加容器用于根据 VST 中发生的事件自动从 DeepStream 应用程序添加和删除流。下面可以看到 DeepStream 和 VST 如何与其他组件交互的概述

../_images/deepstream-sdr-overview.png

GitHub 仓库#

作为参考，JPS DeepStream 容器的 Dockerfile 和 YOLOv8s 的初始化脚本已开源，可在 GitHub 上 jetson-platform-services 仓库的 inference/perception 文件夹下找到。

配置#

DeepStream 配置文件应该不需要进行更改。Orin AGX 上每个 DLA 最多支持 8 个流（总共 16 个），Orin NX16 上每个 DLA 支持 4 个流（总共 8 个），Orin NX8 上总共 4 个流，Orin Nano 上总共 4 个流。关于配置的要点包括

  • 使用 PeopleNet 2.6 (PN2.6) 未剪枝模型以获得卓越的准确性，或使用 YOLOv8s 以获得多类支持

  • 在 Orin AGX、Orin NX16 和 Orin NX8 上，使用 DLA 为 PN2.6 分担 GPU 的推理负载

  • 根据 primary-gie 部分中的 interval 参数，每隔一帧进行推理

  • 使用 NvDCF 多对象跟踪器，该跟踪器支持在 PVA 后端上运行 PN2.6（在 Orin AGX、NX16、NX8 上），以进一步降低 GPU 的负载

  • 使用 Redis 消息代理进行元数据输出

  • 使用动态流添加功能，通过 SDR 微服务添加流（见下文）

要增加或减少每个管道的流数量（从默认值开始），需要更改 compose yaml 文件下的 WDM_WL_THRESHOLD 值。同样，VST 配置 (config/vst/vst_config.json) 中的 max_devices_supported 值也可能需要编辑以支持必要的流数量。为了获得最佳性能，应修改 DeepStream 配置中设置的批大小选项，以及生成和使用特定于新批大小和可用硬件（即 DLA）的引擎文件。

SDR（传感器分配和路由）#

向 DeepStream 添加流是基于一个名为 SDR 的专用微服务，用于从 VST 发现流并将它们动态添加到 DeepStream。SDR 用于使用 DeepStream 中的动态流添加功能，根据 VST 的事件触发，自动从 DeepStream 添加和删除流。当流添加到 VST 并且能够流式传输时，VST 会向 Redis 发送一个事件，格式如下

{
    "alert_type": "camera_status_change",
    "created_at": "2023-11-20T23:51:04Z",
    "event": {
        "camera_id": "MOJD7",
        "camera_name": "36398191-d48a-4260-b574-239fd59f156f",
        "camera_url": "rtsp://172.17.170.143/live/36398191-d48a-4260-b574-239fd59f156f",
        "change": "camera_streaming"
    },
    "source": "vst"
}

SDR 接收到此事件，然后确定 DeepStream 中当前哪个管道可用，并将其添加到该管道。

有时，当 SDR 启动时，VST 可能已经添加了流，并且不会在 Redis 上重新发送消息。例如，如果 SDR 重新启动，则可能会发生这种情况。为了解决这个问题，在启动时，SDR 会查询 VST 实时流端点，以获取已添加的流。然后，它也会将这些流添加到 DeepStream。

SDR 跟踪每个流添加到哪个管道。这样，当流被删除时，它就知道向哪个管道发送删除请求。每个 DeepStream 管道都有一个不同的端口，在使用添加或删除 API 调用时需要指定。

要向 DeepStream 添加流，必须向 https://127.0.0.1:9010/api/v1/stream/add 端点发出 POST 请求。请注意，localhost 可能需要更改为正确的 IP，并且端口从 9010 更改为其他端口 - 默认情况下，端口 9010 用于管道 1，端口 9011 用于管道 2，这在 DeepStream 配置文件中指定。以下 JSON 也必须包含在请求中

{
    "alert_type": "camera_status_change",
    "created_at": "2024-05-01T07:49:16Z",
    "event": {
        "camera_id": "Amcrest_3",
        "camera_name": "0227ed9f-de24-495e-b46f-b9d2b8122dd5",
        "camera_url": "rtsp://172.17.170.143/live/0227ed9f-de24-495e-b46f-b9d2b8122dd5",
        "change": "camera_streaming"
    },
    "source": "vst"
}

要从 DeepStream 中删除流，必须向 https://127.0.0.1:9010/api/v1/stream/remove 端点发出 POST 请求。同样，localhost 可能需要更改为正确的 IP 并指定正确的端口。以下 JSON 也必须包含在请求中

{
    "alert_type": "camera_status_change",
    "created_at": "2024-05-01T07:49:16Z",
    "event": {
        "camera_id": "Amcrest_3",
        "camera_name": "0227ed9f-de24-495e-b46f-b9d2b8122dd5",
        "camera_url": "rtsp://172.17.170.143/live/0227ed9f-de24-495e-b46f-b9d2b8122dd5",
        "change": "camera_remove"
    },
    "source": "vst"
}

请注意，只有 camera_id、camera_name、camera_url 和 change 值是必要的，其他所有内容都是可选的。另请注意，这两个 API 端点直接与 DeepStream 接口，因此如果手动使用，将跳过 SDR，并可能导致问题。在内部，SDR 使用这些端点和 JSON 格式与 DeepStream 接口。当在传统配置文件中使用 [source-list] 或在 Service Maker 配置中使用 nvmultiurisrcbin 时，默认 DeepStream test5 应用程序中提供了这些添加和删除端点。

SDR 还支持在 VST 丢失某些流的情况下进行协调。SDR sidecar 容器偶尔会查询 SDR 缓存和 VST 中的当前流，以确保它们同步，并在它们不同步的情况下根据需要在 SDR 中调用添加/删除功能。

有各种 SDR 配置选项可以通过容器环境变量设置，并且可以在 Docker Compose yaml 文件中使用。这些选项在下面指定。请注意，示例 docker compose 文件确实覆盖了此处指定的一些默认值。

变量

描述

默认值

PORT

SDR REST API 服务器的端口

4000

WDM_WL_SPEC

SDR 在崩溃/重启时使用的本地缓存文件

“./tests/data_wl.yaml”

WDM_CLUSTER_CONFIG_FILE

每个 DeepStream 管道的 IP/端口值

“docker_cluster_config.json”

WDM_MSG_KEY

SDR 应侦听的 Redis 键

“vst.event”

WDM_WL_REDIS_MSG_FIELD

Redis JSON 中要解析的键

“sensor.id”

WDM_WL_ADD_URL

服务添加端点

“/api/v1/stream/add”

WDM_WL_DELETE_URL

服务删除端点

“/api/v1/stream/remove”

WDM_WL_HEALTH_CHECK_URL

服务健康检查端点

“/api/v1/stream/add”

WDM_WL_CHANGE_ID_ADD

在 Redis 上侦听的 “change” 类型，以了解何时向 DeepStream 添加流

“camera_streaming”

WDM_PRELOAD_WORKLOAD

配置文件，其中包含启动时应自动加载的流（除了 VST 上已有的流）

“./event_pre-roll.json”

WDM_CLEAR_DATA_WL

如果应在启动时清除本地缓存，则为 True

False

WDM_KFK_ENABLE

如果应启用 Kafka，则为 True

True

WDM_DS_SWAP_ID_NAME

如果应在添加到 DeepStream 之前从 VST Redis 消息中交换 ID 和名称，则为 True

False

WDM_VALIDATE_BEFORE_ADD

如果应在发送到 DeepStream 之前验证添加 JSON（即，确保设置了名称、ID 和 URL），则为 True

False

WDM_PRELOAD_DELAY_FOR_DS_API

如果 SDR 应等待服务健康检查通过后再开始添加流，则为 True

False

WDM_WL_THRESHOLD

SDR 应添加到每个管道的最大流数

8

WDM_CLUSTER_TYPE

正在使用的集群类型

“docker”

WDM_POD_WATCH_DOCKER_DELAY

SDR 应多久（秒）检查容器重启并更新流分配

0.05

WDM_DS_STATUS_CHECK

如果应读取 DeepStream 返回状态代码而不是忽略，则为 True

False

WDM_RESTART_DS_ON_ADD_FAIL

如果在多次添加/删除事件失败时应重启 DeepStream，则为 True

False

WDM_DISABLE_WERKZEUG_LOGGING

如果应禁用 Werkzeug 日志记录以减少总体日志记录，则为 True

False

WDM_WL_OBJECT_NAME

发送到 Redis 的 SDR 事件的工作负载对象名称，并且在同一系统上运行的 SDR 实例中必须是唯一的

“testapp”

WDM_CONSUMER_GRP_ID

Redis 消费者组 ID，并且在同一系统上运行的 SDR 实例中必须是唯一的

“consumer-grp-id-3”

WDM_CLUSTER_CONTAINER_NAMES

要监视重启/崩溃以进行 SDR 恢复机制的容器名称

“["sdr", "deepstream", "vst"]”

docker_cluster_config.json 文件指定了 SDR 可以向其发送流的可用 DeepStream 管道的详细信息。此文件由 WDM_CLUSTER_CONFIG_FILE 环境变量指向，并且必须采用以下格式

{
    "moj-ds-01": {
        "provisioning_address": "localhost:9010",
        "process_type": "docker"
    },
    "moj-ds-02": {
        "provisioning_address": "localhost:9011",
        "process_type": "docker"
    }
}

其中

  • 键的数量等于您要分配到的服务的总数。

  • 所有键都必须是唯一的。

  • provisioning_address 必须设置为每个服务的 IP/端口（即，对于 DeepStream，IP 是 localhost，但两个管道的端口不同）。

  • process_type 如果使用 Docker Compose，则必须设置为 docker。

SDR 将按顺序填充每个服务。换句话说，SDR 将首先向 “moj-ds-01” 添加 WDM_WL_THRESHOLD 个源，然后再向 “moj-ds-02” 添加源。如果从 “moj-ds-01” 中删除一个源，则该位置将被下一个添加的源填充。

基于 PeopleNet 的推理#

DeepStream 模块使用 NVIDIA PeopleNet 2.6 版作为对象检测模型。预生成的引擎文件用于减少启动时间。引擎文件因使用的设备（Orin AGX、Orin NX16、Orin NX8、Orin Nano）以及批大小而异，因此 DeepStream 配置也因设备而异。使用 1 的跟踪距离，这意味着每隔一帧运行推理以限制推理利用率。混合聚类用于处理网络输出。

请注意，与 DeepStream 一起使用的 PeopleNet 2.6 引擎文件需要在 Jetpack 6.1 中与 TensorRT 在 DLA 上运行，由于 TensorRT 发行说明中记录的已知问题，需要离线生成，此处为了方便起见捕获如下

在为 DLA 构建 TensorRT 引擎时，存在一个已知问题，即“Layers Running on DLA”（在 TensorRT 的详细模式下可见）中列出的整个 DLA 子图无法构建/最终回退到 GPU，并显示消息“{ForeignNode[…]} cannot be compiled by DLA, falling back to GPU”。这已在两个基于 ResNet 的模型中观察到：来自 TAO 的 PeopleNet v2.6 和 TrafficCamNet。在这两种情况下，可以通过将 TensorRT 的默认 DLA SRAM 池大小从 1 MiB 更改为 0.5 MiB 来解决此问题。使用 trtexec，可以通过在构建 TensorRT 引擎时添加参数 --memPoolSize=dlaSRAM:0.5 来实现。

基于 YOLOv8s 的推理#

DeepStream 推理服务现在支持 YOLO (v8s) 模型，用于在 DLA 上进行对象检测。YOLO 是一种最先进的对象检测模型，支持低延迟和多类支持等多种功能。有关多年来发布的各种 YOLO 模型的更多背景信息，请参阅此链接：https://arxiv.org/abs/2304.00501

与 PeopleNet2.6 不同，YOLOv8s 使用传统的 test5 而不是 Service Maker 版本。由于此模型的自定义 DLA 支持版本存在已知问题，并且传统的 DeepStream test5 应用程序存在已知问题，因此默认情况下此模型仅支持一个流。有关如何使用此模型运行更多流的详细信息，请参阅下面的 增加 YOLOv8s 流计数。

基于 NvDCF 的跟踪器#

DeepStream 中使用的 NvDCF 跟踪器已配置为每隔一帧运行推理。NvDCF 特别适用于室内零售环境中的人员分析，这基于其视觉跟踪能力，使其能够抵抗完全或部分遮挡。有关正在使用的跟踪器配置，请参阅 DeepStream 配置文件中的 ll-config-file 变量定义。

Orin AGX、NX16 和 NX8 的默认配置通过 VPI 统一 API 使用 PVA 后端进行跟踪器，以便从 GPU 分担计算负载。子批处理也用于处理每个 PVA 实例的多个流。在 Orin AGX 上，CUDA 后端与 PVA 结合使用以处理某些流，因为支持的流计数很高。Orin Nano 没有 PVA 加速器，因此跟踪器计算在 GPU 上完成。

Redis#

来自 DeepStream 的检测事件由 MessageBroker 输出到 Redis test 流。可以使用以下命令查看最新的事件

sudo docker exec -it redis redis-cli

xinfo STREAM test

事件采用以下格式

"{\n  \"version\" : \"4.0\",\n  \"id\" : \"65704\",\n  \"@timestamp\" : \"2024-04-25T21:56:43.715Z\",\n  \"sensorId\" : \"MOJD7_2\",\n  \"objects\" : [\n    \"655|1364.74|230.769|1487.88|431.31|Person|-0.1|#||||||\",\n    \"607|137.03|204.356|282.938|583.155|Person|-0.1|#||||||\"\n  ]\n}"

这些消息包含有关最新处理的时间戳、sensorId 和对象检测的信息。然后，分析微服务将这些消息作为其输入消耗。有关更多信息，请查看 Redis 页面。

日志#

默认情况下，DeepStream 日志保存在 /data/logging-volume/deepstream.log 文件中。可以使用命令 tail -f /data/logging-volume/deepstream.log 查看实时日志。可以在此文件中查看 DeepStream 当前正在处理的流以及每个流的当前 fps 值。通常，使用默认配置选项时，这些值应在 30fps 左右，但如果输入流的 fps 值较低，则可能会更低。可以在下面看到 DeepStream 日志的示例片段

Active sources : 4
**PERF:  FPS 3 (Avg)    FPS 2 (Avg)     FPS 1 (Avg)     FPS 0 (Avg)
Thu Apr 25 17:26:26 2024
**PERF:
MOJD2_2mbps[e9ad9678-0506-4c3a-8621-9dc865bb1cb1] 30.03 (30.15) MOJD3[e728c793-cf9c-4b6c-b0c3-3565d001d9d9] 30.03 (30.86)       MOJD2_5mbps[9dab9be9-b1b0-4892-b6b9-7f7adfe08bb7] 30.03 (30.40)    MOJD6[555f23f8-4b8f-457d-8246-207af6e06263] 30.03 (30.92)
Active sources : 0
Thu Apr 25 17:26:26 2024

它指定了每个管道的源数量、当前日期/时间、fps 值、流 ID 和流名称。第一个 fps 是当前 fps 值，而括号中的数字是该流的平均值。流名称在通过 VST 添加流时设置，而流 ID 由 VST 随机生成作为唯一标识符。

默认情况下，SDR 日志保存在 /data/logging-volume/sdr-deepstream.log 文件中。可以使用命令 tail -f /data/logging-volume/sdr-deepstream.log 查看实时日志。可以在此文件中查看通过 SDR 添加到 DeepStream 的当前流以及 SDR 通过 Redis 接收到的最新相关消息。

部署#

示例 DeepStream 配置文件和容器信息可以在 NGC 上找到，作为参考 AI-NVR 应用程序的一部分。PeopleNet2.6 配置可以在 ai_nvr/config/deepstream/pn26 下找到，而 YOLOv8s 配置可以在 ai_nvr/config/deepstream/yolov8s 下找到。提供了不同的 docker compose 配置，以便轻松开箱即用地使用 PeopleNet2.6 或 YOLOv8s。请记住，提供的 DeepStream 容器中默认仅包含 PeopleNet2.6 引擎和模型文件。在快速入门指南中提供了使用默认 PeopleNet2.6 模型部署示例 AI-NVR 参考应用程序的命令。在部署之前，请首先按照 快速入门指南 设置您的 Jetson 平台服务系统。

修改 DeepStream 配置#

您可以根据您的用例修改 DeepStream 配置。这可能包括更改批大小、更改跟踪器配置、更改 primary-gie 配置以修改使用的模型或硬件加速器、启用或禁用各种接收器（如显示输出或不同的消息代理）等。在修改这些配置时，请记住以下几点

  • 如果更改 primary-gie 的批大小或配置，您可能还需要重命名（并可能生成）具有新批大小的新引擎文件。同样，您可能需要更改 docker compose yaml 配置中定义的 WDM_WL_THRESHOLD SDR 环境变量，以告知 SDR 应添加到给定 DeepStream 管道的最大流数。

  • 在 DeepStream 管道的不同组件之间使用各种宽度/高度选项可能会导致严重的性能损失。不同组件之间使用不同的批大小也是如此。建议在 DeepStream 管道的每个部分保持这些同步。

  • SDR 使用 DeepStream nvmultiurisrcbin source-bin 来添加/删除流。分析使用 DeepStream Redis 输出，由 msgbroker sink 定义。在 Grafana 中监控 DeepStream FPS 报告使用输出到主机上的 /data/logging-volume/deepstream.log 的日志。如果修改了这些方面中的任何一个，则参考 AI-NVR 应用程序的其他一些组件可能无法按预期运行。

下面提供了两个参考模型的其他注意事项。

PeopleNet2.6 部署#

如果您决定修改示例配置，您可能需要重新生成引擎文件以支持您的新配置。如上面的 PeopleNet2.6 部分所述，由于已知问题，这可能需要使用 trtexec 命令手动完成。下面提供了一个示例命令，用于为 Orin AGX 生成 DLA0 批大小为 8 的配置文件

$ /usr/src/tensorrt/bin/trtexec --onnx=./resnet34_peoplenet_int8.onnx --calib=./PeopleNet_calib.cal --int8 --minShapes="input_1:0":8x3x544x960 --optShapes="input_1:0":8x3x544x960 --maxShapes="input_1:0":8x3x544x960 --duration=100 --useDLACore=0 --allowGPUFallback --memPoolSize=dlaSRAM:0.5 --verbose --saveEngine=./dla0_pn26_jp6_halfmem_bs8.engine

这可以从提供的 Jetson 平台服务 DeepStream 容器的 /pn26-files 目录中运行。这是必要的 PeopleNet2.6 依赖项（onnx 和 cal 文件）所在的位置。可以根据需要修改传递到 trtexec 的选项。

使用 AI-NVR 参考应用程序部署 PeopleNet2.6 的命令可以在快速入门指南的 运行 IVA 应用程序 部分找到。

YOLOv8s 部署#

注意

对于用户选择使用的每个数据集，用户有责任检查数据集许可证是否适合预期用途。

增加 YOLOv8s 流计数#

由于此模型的自定义 DLA 支持版本存在已知问题，并且传统的 DeepStream test5 应用程序存在已知问题，因此默认情况下此模型仅支持一个流。此 DLA 模型目前仅支持批大小为 1，但如果使用 nvmultiurisrcbin，DeepStream 应用程序会自动覆盖此批大小值。可以在提供的 DeepStream 容器和配置中进行以下更改，以支持使用此模型的更多流

启动 DeepStream triton 和 JPS 示例容器

$ sudo docker run -itd --runtime nvidia --network host --name ds-modifications-triton nvcr.io/nvidia/deepstream:7.1-triton-multiarch
$ sudo docker run -itd --runtime nvidia --network host --name ds-modifications nvcr.io/nvidia/jps/deepstream:7.1-public-v1
$ sudo docker exec -it ds-modifications-triton /bin/bash

修改 /opt/nvidia/deepstream/deepstream-7.1/sources/apps/sample_apps/deepstream-app/deepstream_app.c 文件。找到以下部分（从第 1327 行开始）并注释掉它

/** if using nvmultiurisrcbin, override batch-size config for sgie */
if (config->use_nvmultiurisrcbin) {
    for (guint i = 0; i < config->num_secondary_gie_sub_bins; i++) {
        config->secondary_gie_sub_bin_config[i].batch_size =
        config->sgie_batch_size;
    }
}

这将禁用 DeepStream 根据 nvmultiurisrcbin 的批大小值覆盖 PGIE 的批大小值。

之后，重新编译 DeepStream test5 应用程序

$ cd /opt/nvidia/deepstream/deepstream-7.1/sources/apps/sample_apps/deepstream-test5
$ export CUDA_VER=12.6
$ make

退出容器，将新的可执行文件复制到 JPS 容器，然后提交新容器以保存它

$ exit
$ sudo docker cp ds-modifications-triton:/opt/nvidia/deepstream/deepstream-7.1/sources/apps/sample_apps/deepstream-test5 .
$ sudo docker cp deepstream-test5 ds-modifications:/opt/nvidia/deepstream/deepstream-7.1/sources/apps/sample_apps
$ sudo docker commit ds-modifications jps-ds:yolo-modifications
$ sudo docker stop ds-modifications-triton ds-modifications

修改提供的 DeepStream YOLOv8s 配置以更新批大小。编辑 config/deepstream/yolov8s/yolov8s-ds-config_<DEVICE_TYPE>.txt 的 [source-list] 部分。在此处将 [max-batch-size] 更新为 8。

您还需要更新 Docker Compose 配置以指向修改后的容器和其中的 test5 可执行文件的更新版本。将 compose_<DEVICE TYPE>_yolov8s.yaml 的 deepstream 部分下的 image 行更改为

image: jps-ds:yolo-modifications

同样，将同一部分中的 command 行更改为

command: sh -c '/opt/nvidia/deepstream/deepstream-7.1/sources/apps/sample_apps/deepstream-test5/deepstream-test5-app -c /ds-config-files/yolov8s/yolov8s-ds-config_nx16.txt 2>&1 | grep --line-buffered . | tee -a /log/deepstream.log'

最后，还要增加 SDR 将分配给 DeepStream 的流的数量。更新此同一 yaml 文件中 sdr 下的 WDM_WL_THRESHOLD，并将其设置为 8。

您现在可以使用与以前相同的 Docker Compose up 命令启动带有 YOLOv8s 的 AI-NVR，并且能够支持更高的流计数。

使用 AI-NVR 参考应用程序运行 YOLOv8s#

提供了 Docker compose 配置，以便将其与 AI-NVR 堆栈的其余部分一起运行。要运行，请使用以下命令

Orin AGX: sudo docker compose -f compose_agx_yolov8s.yaml up -d --force-recreate

Orin NX16: sudo docker compose -f compose_nx16_yolov8s.yaml up -d --force-recreate

停止

Orin AGX: sudo docker compose -f compose_agx_yolov8s.yaml down --remove-orphans

Orin NX16: sudo docker compose -f compose_nx16_yolov8s.yaml down --remove-orphans

本页目录