Відеотрансляція у TAK: інтеграція живих потоків у COP

Екіпаж дрона бачить колону техніки, що рухається вздовж лісосмуги. Офіцер S2 за три кілометри дивиться на карту без відео. Оператор дрона переказує побачене голосом по радіо. Поки ця інформація стане записом у спільній оперативній картині, колона вже зрушила. Інтеграція живого відео в TAK усуває цей розрив – вона виводить потік просто на COP, геоприв'язаним, розповсюдженим і доступним на кожному клієнті ATAK і WinTAK у мережі без ручного налаштування. Ця стаття охоплює повний стек інтеграції: налаштування транспорту RTSP, публікацію відеопосилання CoT, геоприв'язку сліду сенсора, архітектуру ретрансляції для обмежених каналів, бюджети затримки та налаштування на стороні відображення в ATAK Video Receiver.

Як TAK обробляє відео: модель відеопосилання CoT

TAK не передає відеобайти через TAK Server. Архітектура навмисно розв'язана: TAK Server розповсюджує посилання на потік – подію відеопосилання CoT Video – тоді як саме відео тече точка-точка (або через ретранслятор) між джерелом і кожним глядачем. Це розділення тримає вимоги до смуги пропускання TAK Server керованими й дозволяє масштабувати відеоінфраструктуру незалежно від мережі тактичних даних.

Подія CoT Video — це стандартне XML-повідомлення CoT з типом b-i-v. Її блок detail містить елемент Video з URL потоку, зрозумілим людині псевдонімом, типом протоколу (rtsp, rtsps або udp), підказкою кодека й унікальним ідентифікатором потоку. Коли TAK Server отримує цю подію, він зберігає її та ретранслює всім підключеним клієнтам у відповідній групі. Клієнт ATAK, отримавши подію Video, автоматично додає потік до списку потоків плагіна Video Receiver – оператор може потім відкрити потік за псевдонімом, не знаючи базового URL і не налаштовуючи нічого вручну.

Та сама модель CoT обробляє відкликання потоку: публікація події Video з тим самим UID і застарілою міткою часу в минулому видаляє потік зі списків клієнтів. Це робить керування життєвим циклом потоку програмованим і узгодженим з рештою моделі даних TAK.

Транспортний рівень: RTSP, RTP та вибір кодека

RTSP (Real Time Streaming Protocol) — домінуючий транспорт для відеопотоків TAK. RTSP працює як канал керування – він узгоджує параметри сесії та встановлює потік – тоді як саме медіа тече через RTP (Real-time Transport Protocol) на окремому порту. Два поширені режими транспорту RTSP для TAK такі:

RTSP поверх TCP (interleaved). Медіапакети RTP мультиплексуються в TCP-з'єднання RTSP. Цей режим надійніше проходить NAT і правила фаєрвола, ніж UDP, бо використовує єдине встановлене TCP-з'єднання. Це рекомендований режим для потоків, що проходять через супутник, LTE чи будь-який канал з обмежувальною фільтрацією пакетів. Компроміс у тому, що поведінка ретрансляції TCP може додавати змінну затримку під час сплесків втрати пакетів – проблема якості з'єднання на деградованих каналах.

RTSP з UDP-транспортом медіа. Медіа RTP тече через окремі UDP-порти, узгоджені під час обміну RTSP SETUP. UDP-транспорт досягає нижчої базової затримки, ніж TCP, бо немає ретрансляції – втрачені пакети дають артефакти відео, а не зупинку декодера. На локальному сегменті MANET з низькою втратою пакетів (<1%) UDP-транспорт є кращим вибором. На каналах з вищим рівнем втрат поведінка зупинки декодера в TCP часто переважає помилки декодування UDP.

Щодо вибору кодека, H.264 (AVC) з профілем Baseline або Main — універсальна база. Кожен Android-пристрій з підтримкою ATAK і кожна інсталяція WinTAK можуть апаратно декодувати H.264. H.265 (HEVC) зменшує смугу пропускання приблизно на 40% за еквівалентної якості – значна економія на радіоканалах – але потребує явної підтримки декодера на пристрої-приймачі. Старіше захищене Android-обладнання може не мати апаратного декодування H.265, переходячи на програмне декодування з вищим навантаженням на ЦП і затримкою. Безпечний вибір для гетерогенного парку — H.264; H.265 доречний, коли набір пристроїв однорідний і добре охарактеризований.

Бітрейт та інтервал ключових кадрів

Вибір бітрейту визначає навантаження на смугу пропускання тактичного каналу. Практичні рекомендації за типом каналу: 1.5–2.5 Мбіт/с для виділеного бекхолу LTE з гарним сигналом; 800–1200 кбіт/с для керованої Wi-Fi-сітки; 400–800 кбіт/с для радіо MANET із сукупним бюджетом 1–2 Мбіт/с, спільним з трафіком CoT; 200–400 кбіт/с для супутникового чи BLOS-каналу. Нижче 300 кбіт/с відео H.264 1080p стає візуально неприйнятним – зменшіть роздільність до 720p чи 480p замість подальшого стиснення 1080p.

Інтервал ключових кадрів (інтервал I-кадрів) визначає, як швидко новий глядач може почати відображати потік. Інтервал ключових кадрів 1 секунда означає, що нове з'єднання починає відображення щонайбільше за 1 секунду від останнього ключового кадру. Інтервал 4 секунди економить смугу, але означає, що нові глядачі чекають до 4 секунд на перший декодований кадр. Для тактичного використання рекомендований інтервал — 1–2 секунди. Зауважте, що коротші інтервали збільшують бітрейт – інтервал I-кадрів 1 секунда при 800 кбіт/с дає більші I-кадри приблизно кожні 800 кбіт, що може спричиняти короткі сплески бітрейту на каналі.

Архітектура ретрансляції для обмежених і багатоступеневих мереж

Пряма модель RTSP – клієнти ATAK підключаються до RTSP-сервера пристрою-джерела – працює в плоских локальних мережах, але дає збій у більшості операційних розгортань. Наземні станції керування БпЛА знаходяться в іншій IP-підмережі, ніж клієнти ATAK. Супутникові чи BLOS-канали потребують ретрансляції, щоб завести віддалені потоки в тактичну мережу. Кілька одночасних глядачів навантажують смугу вихідного каналу пристрою-джерела. Сервер-ретранслятор вирішує всі три проблеми.

Ретранслятор отримує потік від джерела один раз – одне з'єднання, один потік байтів – і перерозподіляє його будь-якій кількості споживачів нижче за течією. URL події CoT Video встановлюється на адресу ретранслятора, а не джерела. Кожен клієнт ATAK підключається до ретранслятора й отримує той самий потік без збільшення навантаження на джерело GCS чи канал БпЛА.

Вузол сервера-ретранслятора потребує: прямого мережевого шляху до джерела (сегмент мережі GCS чи кінцева точка супутникового бекхолу) та шляху до мережі TAK. У стандартному розгортанні передового командного пункту ретранслятор працює на тому ж фізичному вузлі, що й TAK Server, або на виділеному обчислювальному вузлі на командному пункті. Для крайових розгортань, де ретранслятор має працювати близько до джерела (поблизу GCS), він може пересилати потоки через тунель OpenVPN чи WireGuard у тактичну мережу, з другим екземпляром ретранслятора на стороні TAK Server, що перерозподіляє локально.

Публікація відео в мережу TAK через CoT

Механіка події CoT Video проста, але поля detail мають значення. Мінімальна сумісна подія Video виглядає так у блоці detail:

<Video url="rtsp://RELAY_IP:8554/feed1" protocol="rtsp" alias="DRONE-ALPHA Camera" uid="VIDEO-DRONE-ALPHA-01" />

Додаткові необов'язкові поля несуть підказки кодека (codec="H264"), мережевий тайм-аут у мілісекундах (networkTimeout="10000") та підказку часу буферизації (bufferTime="0" – встановлення цього в нуль сигналізує плеєру, що бажаний режим низької затримки, придушуючи стандартний споживчий буфер). Поле uid — постійний ідентифікатор – повторне використання того самого UID у пізнішій події оновлює посилання на потік, а не створює дублікат.

Для розробників плагінів ATAK, що публікують відео зсередини плагіна: використовуйте API CotService, щоб впровадити подію Video CoT у внутрішню шину ATAK. Подія потім поширюється на TAK Server через активний канал даних і звідти всім членам групи. Окремого API керування відео немає – шина подій CoT є єдиним механізмом розповсюдження.

Геоприв'язка: накладення сліду сенсора

Відеопотік, відображений у панелі Video Receiver, показує оператору те, що бачить камера. Накладення на карту показує кожному іншому оператору, куди камера спрямована. Разом ці двоє – синхронізоване відео й слід – дають COP справжній просторовий контекст, який не може забезпечити голосовий опис.

Для потоків БпЛА обчислення сліду потребує п'яти вхідних даних: позиції дрона WGS84 (широта, довгота, висота над землею), кута повороту підвісу (горизонтальний напрямок наведення відносно курсу дрона), кута нахилу підвісу (кут пониження нижче горизонталі) та горизонтального й вертикального поля зору камери. З них будуються чотири кутові вектори променів і перетинаються з поверхнею рельєфу (моделлю висот DTED або наближенням плоскої землі для низьковисотних операцій). Чотири точки перетину утворюють вершини полігона сліду.

Слід публікується як CoT GeoObject – подія CoT заповненого полігона – з використанням послідовного UID, прив'язаного до дрона чи сенсора. Він оновлюється з частотою телеметрії. Для накладення на карту оновлення 1–2 Гц візуально плавні й накладають незначне навантаження на трафік CoT. За вищих швидкостей повороту підвісу (швидке панорамування під час активного супроводу) 5 Гц забезпечує краще відстеження руху сліду на карті. Частота оновлення має бути незалежно конфігурованою від частоти телеметрії, що використовується для треку позиції дрона.

Стаціонарні камери – на щоглі, периметрові сенсори на техніці – дають статичний або повільно змінний слід. Для камери з фіксованим азимутом слід — це трапеція, орієнтована в напрямку курсу камери, що оновлюється лише при зміні масштабу або переміщенні камери. Публікація сліду для стаціонарних сенсорів виконується за тим самим механізмом CoT GeoObject; видавцем є програмне забезпечення керування сенсором, а не міст телеметрії БпЛА.

Бюджет затримки: затримка відображення та її джерела

Загальна затримка відображення – від моменту, коли сцена захоплена камерою, до моменту, коли вона з'являється на екрані оператора – це сума п'яти послідовних затримок:

Затримка кодування: 30–80 мс на спроможному апаратному кодувальнику з H.264. Програмні кодувальники на малому обчислювальному обладнанні БпЛА можуть додавати 100–200 мс. Це не регулюється оператором наземної станції.

Затримка мережевого транзиту: 10–50 мс для MANET чи LTE прямої видимості; 30–150 мс для багатоступеневої сітки; 500–600 мс в один бік для ретрансляції через геостаціонарний супутник. Супутникова ретрансляція — найбільший окремий фіксований внесок у затримку й накладає жорстке обмеження на досяжну наскрізну затримку для потоків з супутниковим бекхолом.

Затримка обробки ретранслятора: менше 5 мс для добре реалізованого RTSP-ретранслятора. Незначна, якщо ретранслятор на локальному вузлі.

Буфер джитера на приймальній стороні: найбільше кероване джерело затримки. Буфер джитера 2 секунди – стандарт у багатьох споживчих відеоплеєрах – додає 2 секунди фіксованої затримки до кожного кадру. Для тактичного використання буфер джитера слід зменшити до 100–300 мс. Компроміс — збільшення візуальних артефактів під час сплесків втрати пакетів. Це операційне рішення: прийняти випадкові збої кадрів в обмін на майже реальний час зображення, або прийняти 2-секундну затримку заради плавного відтворення. Для ураження цілей, чутливих до часу, налаштування 100–300 мс є обов'язковим.

Конвеєр декодування та відображення: 20–40 мс для апаратно прискореного декодування H.264 на сучасному Android-пристрої. Не регулюється.

Керування кількома потоками та UX оператора

Один клієнт ATAK може відображати кілька одночасних відеопотоків. Плагін Video Receiver подає зареєстровані потоки за псевдонімом у списку; оператор торкається, щоб відкрити потік у плаваючій панелі чи на повний екран. Для підрозділів, що оперують кількома БпЛА одночасно, угода про іменування псевдонімів потоків є основним елементом керування UX: послідовна угода (DRONE-[CALLSIGN]-[SENSOR]) дозволяє операторам миттєво ідентифікувати правильний потік без проб і помилок.

Сигнали пріоритету потоку – вбудовані в поле remarks події CoT Video чи в супутню подію CoT – можуть використовуватися програмним забезпеченням C2 для автоматичного виведення на передній план найпріоритетнішого потоку. TAKpilot, наприклад, може отримати команду оператора природною мовою («покажи мені камеру дрона Alpha») і вивести відповідний потік на передній план за іменем-псевдонімом без ручної навігації оператора списком потоків.

Для підрозділів, що використовують WinTAK на командному пункті, ті самі події CoT Video, розповсюджені через TAK Server, заповнюють відеосписок WinTAK ідентично. Більша площа екрана WinTAK підтримує відеопанелі поруч, роблячи його кращою платформою для операторів дронів і вузлів C2, що моніторять кілька потоків одночасно. Базовий протокол потоку й архітектура ретрансляції ідентичні незалежно від того, чи споживач — ATAK, чи WinTAK.