Питання про інфраструктуру live-стримінгу для дронів

[Danylo 0]

Привіт усім,
працюю над рішенням для live-стримінгу відео з дронів. Потрібно передавати відео з мінімальною затримкою, але при цьому система має працювати навіть у обмежених або частково ізольованих мережах (не завжди є стабільний інтернет).

Зараз я вивчаю різні підходи (WebRTC, RTMP, HLS) і натрапив на американське рішення Red5 Pro, яке використовується для low-latency стримінгу та підтримує різні протоколи:
https://www.red5.net/solutions/drone-public-safety/

Хотів би запитати:

Чи хтось в Україні працював з подібними системами для дронів або відеоспостереження? Чи є локальні або українські альтернативи, які добре працюють у таких умовах? Який підхід краще показав себе на практиці для реального часу? Буду вдячний за будь-який досвід або поради.

[Alver 339]

В чем проблема передавать видео с цифровой IP камеры по  RTSP ?   Задержка ? Она там в этом протоколе минимальная из возможных по IP сети. Совершенно точно меньше чем например по  HLS. И собственно зачем вам нужно именно live-streaming? Передавать видео  по Интернет ?  Для этого есть другие решения.

 Задержка в  RTSP  в основном определяется медиаплеером , например у VLС она может быть высокой из-за буферизации потока. Есть плейеры RTSP под  Linuх  или железячные видеорегистраторы где она минимальна.

Большинство    IP камер дронов  и отчасти  систем видеонаблюдения работают именно по RTSP.

Передача видео с камер дронов или видеонаблюдения -тема хорошо проработана.  Использование стриминговых протоколов, в основном предназначенных для медиасервисов TV/Video  типа  OTT,  для этих задач -непонятно что хотите получить и улучшить, то есть сама постановка задачи изначально тупиковая.

Відредаговано 2026-01-21 06:50:03 Alver

[Alver 339]

Отдельно следует  сказать за видеоcистему  DJI,  там действительно  минимальная задержка (именно видео)  и протокол видео    не   RTSP (   что есть  L5  уровень Application level OSI)  , а свой проприетарный  протокол   L2  ( вместо  стандартного L2 MAC )    без стека   TCP/UDP IP ( 3   и 4     level OSI) -   просто цифровое видео передается   по  их  L2  .      И в   ее разработку   вложено  не миллионы, и не десятки млн $,  а значительно больше,  и много лет работы тысячи китайских программистов и инженеров по видео и радио ( изначально много лет назад  этой были приглашенные американские инженеры). Но это другая  отдельная история и главный вопрос в постановке  задачи, надо ли оно нам сейчас (для каких задач)    в подобной  нестандартной ( в этом есть ключевая  проблема) реализации. Как по мне - такой задачи и  необходимости в функционале БПЛА  за такие деньги, что дает решение этой задачи, в нашей складывающейся   тактике боевого применения  БПЛА  - нет.  

  Иными словами то технологическое преимущество ( низкая задержка и  джиттер), что реально есть в видеосистеме   DGI , интегрированной в их в общем то неплохую   систему радиосвязи  ( в сравнении с  радиотехнологией      LORA в реализации  TBS Crossfire ,ELRS, но  уступающую  по   многим  параметрам    радиотехнологии 4G, 5G мобильного и фиксированного доступа   в  реализации например Qualcomm  )     страдает многими побочными  но  критичными   недостатками  в целом ( из-за проприетарности)  и  невостребовано  ( я бы сказал больше   -     архитектурно    несовместимо и поэтому непригодно ) для реализации  широкого круга потребного функционала для  БПЛА различного назначения для многих ( если не всех ) вариантов  их боевого применения.     

   Фиксация      DJI  на снижение задержки именно         в  передаче  видео  и управления    для "гоночных"       FPV    дронов за счет потери функционала для решения других задач  БПЛА  играет против  экосистемы    DJI   и это уже имеет    свои последствия.

Відредаговано 2026-01-22 21:41:51 Alver

[exnetlife 126]

Написав в особисті. Але для загального розвитку напишу тут декілька ньюансів:

- є різниця між транспортом від дрону до меді-сервісу і між медіа-сервісом та програвачем. 

- додатково дрон це не тільки картинка, це ще телеметрія. Можна відразу телеметрію писати в відео як OSD, дотаковий час на енкодінг оверлею, але якщо плануєте колись працювати з НАТО - користуватися KLV і писати дата стрім в єдиний MPEG TS потік. 

 

тепер по затримці та error correction: 

- дрон - медіа-сервер потрібна мінімальна затримка, для цього потрібен будь-який протокол який вам підходить, але потрібно мати FEC (forward error correction). По протоколу - раджу подивитися в бік SRT. Але його by default від використовує NACK. Я писав пакет фільтер щоб він робив FEC.  

- меді-сервер -> користувач - тут як правило інтернет краще, і ціль побачити все навіть якщо трафіку пробіжить більше, тут підходять NACK. Звичайний WebRTC працює на ура. 

Але

Для WebRTC вам потрібно зробити нормальний плеєр, який буде цей WebRTC показувати, особливо якщо будете використовувати KLV. 

 

із медіа серверів, раджу подивитися на Mediamtx. Дає мінімальну затримку, opensource, жодних проблем.

Напишіть мені, якщо цілі співпадають - я проконсультую.