DeepStream: много камери на GX10

01Какво ще научиш

• Защо на машина от класа GB10 DeepStream върви само в контейнер и как да го пуснеш.
• Как е устроен конвейерът (pipeline) и какво прави пакетирането на потоците.
• Как да пуснеш примерното приложение без камери и да видиш кадрите в секунда.
• Как да подадеш няколко камери, без паролите им да попаднат във файл за споделяне.
• Как да изпращаш резултатите като съобщения към брокер и защо няма запис „направо в базата“.
• Как да измериш капацитета на своята машина вместо да вярваш на чужди числа.

02Преди да започнеш

• Машина от класа NVIDIA GB10 (например ASUS Ascent GX10 или DGX Spark) с DGX OS и достъп до терминала ѝ.
• Docker с поддръжка на видеокартата — на DGX Spark е предварително инсталиран и настроен (по документацията на NVIDIA). Основите на контейнерите има в урока за n8n.
• Свободно място: образът на DeepStream е голям (гигабайти) — провери с df -h.
• Инструментът envsubst (пакет gettext-base в Ubuntu) за стъпка 4 — ⚠️ не сме проверявали дали е наличен по подразбиране.
• По желание: камери с RTSP поток. За първите стъпки са напълно достатъчни примерните видеа в контейнера.
• Лиценз: DeepStream е под лицензното споразумение на NVIDIA (EULA). Прочети го, преди да вградиш системата в продукт или услуга за клиент.
• Правна проверка: виж кутията в стъпка 7. Преди да обработваш поток с реални хора, говори с юрист.

03Стъпки

1. Какво е DeepStream и как е устроен

   Защо пакети? Видеокартата върви най-добре, когато върши една голяма работа, а не много малки. DeepStream взема по един кадър от всеки поток, слага ги в пакет и ги праща наведнъж. Затова „много камери“ не означава „много програми“, а един конвейер.

   Част	За какво е
   Източници (source)	Приемат и декодират потоците — RTSP камери или видеофайлове
   nvstreammux	Събира кадрите от всички източници в един пакет
   nvinfer	Пуска модела (TensorRT) върху целия пакет
   nvtracker	Дава на обектите номера, за да се знае, че е същият човек или кола от кадър на кадър
   nvmsgconv + nvmsgbroker	Превръщат резултата в съобщение и го пращат към брокер
   deepstream-app	Готовото примерно приложение: целият конвейер се описва с един конфигурационен файл

   ⚠️

   Само в контейнер

   По документацията на NVIDIA инсталирането на DeepStream директно в системата на DGX Spark не се поддържа — ползва се Docker контейнерът. Ако в стар материал виждаш .deb пакет, JetPack или „DeepStream 7.0“, това е за друга машина (Jetson).

2. Образ и контейнер

   Изтегляме образа на NVIDIA за DGX Spark. Командата за стартиране е взета от документацията; махнахме само опциите за показване на екран (машината ни е без монитор) и добавихме работна папка, в която ще слагаме своите файлове.

   bash · на машинатакопирай

   mkdir -p ~/ds-work
   sudo docker pull nvcr.io/nvidia/deepstream:9.1-triton-sbsa-dgx-spark
   
   sudo docker run -it --rm --runtime=nvidia --network=host \
     -e NVIDIA_DRIVER_CAPABILITIES=compute,utility,video,graphics \
     --gpus all \
     -v "$HOME/ds-work:/work" \
     nvcr.io/nvidia/deepstream:9.1-triton-sbsa-dgx-spark

   Първото стартиране може да отнеме няколко минути — контейнерът изгражда кеш за видеокартата (по NVIDIA). Вътре системата е Ubuntu 24.04. Опцията --network=host е от документацията: контейнерът ползва мрежата на машината. Това е удобно за проба; за постоянна работа реши с кого да я делиш. Драйверът: NVIDIA изисква версия 580.159.03 за DGX Spark и казва, че е включен в образа — ⚠️ провери с nvidia-smi какво показва твоята машина.

   💡

   Особености на контейнера за DGX Spark (по NVIDIA)

   За показване на картина се поддържа само nv3dsink, а nveglglessink — не. Блокът VIC не се поддържа, затова ако включиш [tiled-display], задай compute-hw=1 (видеокартата). Ние ще работим без картина, така че нито едното не ни трябва.

3. Първа проба с примерните потоци

   Вътре в контейнера има готови конфигурации и видеа. Ползваме примера с четири потока и го пускаме без картина: така се измерва само работата на видеокартата. (Тези две промени са от раздела на NVIDIA за измерване на производителността.)

   bash · в контейнеракопирай

   cd /opt/nvidia/deepstream/deepstream-9.1/samples/configs/deepstream-app
   cp source4_1080p_dec_infer-resnet_tracker_sgie_tiled_display.txt my_test.txt

   Отвори my_test.txt (например с nano) и в копието задай:

   ini · my_test.txt · променитекопирай

   [tiled-display]
   enable=0
   
   [sink0]
   enable=1
   type=1
   sync=0

   Тип 1 е „фалшив“ изход (fakesink): кадрите се обработват, но не се рисуват никъде. Пусни приложението:

   bash · в контейнеракопирай

   deepstream-app -c my_test.txt

   Първия път моделът обикновено се компилира за видеокартата и това отнема време. После приложението печата кадрите в секунда за всеки поток. Спри го с Ctrl+C. ⚠️ Точните имена в примерния файл при твоята версия може да са различни — ако редовете ги няма, търси ги по име на групата в документацията на референтното приложение.

4. Много потоци: свой конфигурационен файл

   Сега описваме потоците сами. В референтното приложение списък от източници се дава в групата [source-list], а общите им настройки — в [source-attr-all]. Две правила от NVIDIA: размерът на пакета (batch-size) в [streammux] и в основния детектор е равен на броя на източниците (по-малък или по-голям размер понякога добавя забавяне), а ширината и височината на мултиплексора са равни на размера на входния кадър.

   Адресите на камерите не са във файла. В шаблона стоят само имената на променливи; истинските адреси се вмъкват при пускане. Файлът ds_multicam.tpl се пише в работната папка на машината (~/ds-work):

   ini · ~/ds-work/ds_multicam.tplкопирай

   [application]
   enable-perf-measurement=1
   perf-measurement-interval-sec=10
   
   [source-list]
   num-source-bins=4
   list=${CAM1_URI};${CAM2_URI};${CAM3_URI};${CAM4_URI}
   
   [source-attr-all]
   enable=1
   type=3
   num-sources=1
   gpu-id=0
   cudadec-memtype=0
   latency=100
   rtsp-reconnect-interval-sec=10
   
   [streammux]
   gpu-id=0
   live-source=1
   batch-size=4
   batched-push-timeout=40000
   width=1280
   height=720
   
   [primary-gie]
   enable=1
   gpu-id=0
   batch-size=4
   config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_infer_primary.txt
   
   [tracker]
   enable=1
   tracker-width=640
   tracker-height=384
   ll-lib-file=/opt/nvidia/deepstream/deepstream/lib/libnvds_nvmultiobjecttracker.so
   ll-config-file=/opt/nvidia/deepstream/deepstream/samples/configs/deepstream-app/config_tracker_NvDCF_perf.yml
   
   [osd]
   enable=0
   
   [tiled-display]
   enable=0
   
   [sink0]
   enable=1
   type=1
   sync=0

   Основният детектор е примерният модел на NVIDIA от същата папка — за свой модел виж „Какво следва“. rtsp-reconnect-interval-sec=10 казва на приложението да се свърже отново, ако от камера не идват данни 10 секунди (с 0 повторното свързване е изключено). Стойностите на размерите са от примерите на NVIDIA и не са „най-добрите“ — подбират се според входа и модела.

   Първо с видеофайлове (те са вътре в контейнера). За файлове задай в шаблона live-source=0:

   bash · на машината, в ~/ds-workкопирай

   V=file:///opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4
   export CAM1_URI=$V CAM2_URI=$V CAM3_URI=$V CAM4_URI=$V
   
   envsubst < ds_multicam.tpl > ds_multicam.txt
   chmod 600 ds_multicam.txt

   След това в контейнера: deepstream-app -c /work/ds_multicam.txt. Работи ли с файлове, мини към камери: върни live-source=1 и задай променливите с реалните адреси (стойностите вземи от настройките на камерите):

   bash · на машинатакопирай

   export CAM1_URI='rtsp://<потребител>:<парола>@<адрес-на-камера-1>:554/<път-на-потока>'
   export CAM2_URI='rtsp://<потребител>:<парола>@<адрес-на-камера-2>:554/<път-на-потока>'
   export CAM3_URI='rtsp://<потребител>:<парола>@<адрес-на-камера-3>:554/<път-на-потока>'
   export CAM4_URI='rtsp://<потребител>:<парола>@<адрес-на-камера-4>:554/<път-на-потока>'
   
   envsubst < ds_multicam.tpl > ds_multicam.txt
   chmod 600 ds_multicam.txt

   ⚠️

   Генерираният файл съдържа пароли

   След envsubst файлът ds_multicam.txt вече има истинските адреси. Права 600, не го качвай в Git и не го пращай никому; изтрий го, когато приключиш (rm ds_multicam.txt) — шаблонът остава. За по-постоянна работа пази променливите в защитен файл с права само за теб, а не в историята на терминала.

   Започни с един поток, после два, после четири — и така намираш кой е проблемният. Когато добавяш камера, увеличи броя в num-source-bins, добави CAMn_URI към list и качи batch-size на двете места.

5. Резултатите като съобщения към брокер

   Конвейерът може да превръща метаданните (клас, рамка, номер, време) в съобщения чрез nvmsgconv и да ги праща с nvmsgbroker. Адаптерите, които идват с DeepStream, са за Kafka, Azure IoT, AMQP 0-9-1, Redis (потоци) и MQTT. За PostgreSQL няма такъв адаптер — затова между брокера и базата стои малък потребител (consumer): програма, която чете темата и пише в таблицата. Например таблицата security_events от урока за таблото; в n8n също има възли за някои брокери (виж документацията му).

   Втори изход в конфигурацията (type=6 е „преобразувател на съобщения + брокер“):

   ini · добавка към ds_multicam.tplкопирай

   [sink1]
   enable=1
   type=6
   msg-conv-config=<път-до-конфигурацията-на-msgconv>
   msg-conv-payload-type=0
   msg-broker-proto-lib=/opt/nvidia/deepstream/deepstream/lib/libnvds_kafka_proto.so
   msg-broker-conn-str=<адрес-на-брокера>;<порт>
   topic=<тема>

   Свържи го с твоя брокер: библиотеката е за Kafka; за Redis или MQTT избери съответната (виж раздела за протоколните адаптери на nvmsgbroker). Адаптерът за Kafka ползва librdkafka, а тя трябва да е инсталирана — ⚠️ не сме проверявали дали е вътре в образа. Файлът със схемата за msg-conv-config идва от примера deepstream-test5 на NVIDIA; пътят зависи от версията, затова не го даваме.

   В съобщението има метаданни (клас, рамка, номер на обект, време), а не кадри. Това е добра практика и за правния преглед: по-малко данни, по-лесно обосноваване.

6. Измери сам

   Колко потока издържа машината ти зависи от модела, размера на кадъра, кодека, камерите и от това дали рисуваш картина. Затова в урока няма наши числа. Какво да направиш:

   • Остави enable-perf-measurement=1 — приложението печата кадрите в секунда за всеки поток през perf-measurement-interval-sec секунди.
   • Изключи картината ([osd], [tiled-display] и изходен фалшив sink), както по-горе: така NVIDIA прави своите измервания.
   • Добавяй потоци един по един и гледай кога кадрите на всеки поток падат под нужните ти.
   • В друг терминал на машината следи nvidia-smi и docker stats. На GB10 „Memory-Usage: Not Supported“ в nvidia-smi е нормално — паметта е обща. tegrastats е за Jetson и тук не се ползва.
   • При дълго натоварване следи температурата и проветряването — NVIDIA напомня, че пиковата производителност иска добро охлаждане.

   Модел (измерване на NVIDIA на DGX Spark)	Вход · точност	Тракер	Кадри/сек
   RT-DETR	640×640 · FP16	няма	192
   RT-DETR	640×640 · FP16	NvDCF	190
   PeopleNet 2.6.3	640×640 · FP16	MV3DT	341
   TrafficCamNet Transformer Lite	544×960 · FP16	NvDCF	144

   Това са числа на NVIDIA (цялото приложение, без изобразяване, върху техен тестов видеоклип) — не са брой потоци и не са наши. Те само показват порядъка; твоите данни ще излязат различни.

7. Хората в кадъра: правна рамка

   ⚖️

   Записът и анализът на хора имат правни изисквания

   Видеонаблюдението, включително автоматичното откриване на хора в много камери, е обработване на лични данни и попада под правилата за защита на личните данни (GDPR) и българското право. Основание, информиране на хората, срок на съхранение, достъп до данните и права на засегнатите зависят от обекта и целта. Препоръка: преди да пуснеш система с реални камери, провери с юрист и запиши решенията му. Този урок е технически и не е правна консултация.
   • Пази само метаданни (клас, рамка, време) — не кадри и не лица.
   • Пази данните колкото е нужно и не повече, и ограничи кой има достъп до брокера и до базата.
   • Информирай хората на обекта по начина, който юристът ти препоръча.

04Проверка

• Образът е изтеглен и контейнерът се стартира с достъп до видеокартата.
• Копието на примерния конфигурационен файл работи без картина и печата кадрите на всеки поток.
• batch-size в [streammux] и в [primary-gie] е равен на броя на източниците.
• Собствената конфигурация работи с файлове, после и с камери — поток по поток.
• Адресите на камерите са само в променливи на средата, а генерираният файл е с права 600 и е изтрит след работа.
• Ако пращаш съобщения: брокерът работи, библиотеката е на правилния протокол и има потребител, който пише в базата.
• Имаш свои измервания, не чужди числа.
• Преди да насочиш реална камера към хора — говорил си с юрист.

Тест

05Какво следва

Свързани: съобщенията от тази стъпка могат да захранят таблото със Grafana, а основите на откриването — урокът за YOLO11. За свой модел в DeepStream виж раздела „Using a Custom Model“ в документацията на NVIDIA. Ако пишеш на Python, NVIDIA насочва новата разработка към pyservicemaker, а не към остарелия pyds.

06Източници

1. NVIDIA DeepStream: инсталиране 🔒 локално — раздел „DGX Spark“: само Docker, образът, особености.
2. DeepStream: бърз старт · контейнери · примерни конфигурации и потоци.
3. DeepStream: референтно приложение deepstream-app — групи и ключове на конфигурацията.
4. Gst-nvmsgbroker — протоколни адаптери (Kafka, Azure IoT, AMQP, Redis, MQTT).
5. DeepStream: производителност — таблицата за DGX Spark и настройките за измерване.
6. Python привързвания (остарели) · Service Maker за Python.
7. DeepStream: лицензно споразумение (EULA).
8. NVIDIA DGX Spark: хардуер · ASUS Ascent GX10: технически данни — процесор, обща памет, 1 PFLOP при FP4.