Strumieniowanie wideo w TAK: integracja podglądu na żywo z COP

Załoga drona widzi kolumnę pojazdów poruszającą się wzdłuż linii drzew. Oficer S2, trzy kilometry dalej, wpatruje się w mapę bez wideo. Operator drona relacjonuje przez radio głosowe. Zanim ta informacja stanie się wpisem we wspólnym obrazie operacyjnym, kolumna już się przemieściła. Integracja wideo na żywo w TAK eliminuje tę lukę – umieszcza podgląd bezpośrednio na COP, z georeferencją, zdystrybuowany i dostępny na każdym kliencie ATAK i WinTAK w sieci bez ręcznej konfiguracji. Ten artykuł obejmuje pełny stos integracji: konfigurację transportu RTSP, publikację łącza wideo CoT, georeferencję śladu czujnika, architekturę przekaźnikową dla ograniczonych łączy, budżety opóźnień oraz konfigurację po stronie wyświetlania w ATAK Video Receiver.

Jak TAK obsługuje wideo: model łącza wideo CoT

TAK nie przenosi bajtów wideo przez TAK Server. Architektura jest celowo rozłączona: TAK Server dystrybuuje odniesienie do strumienia – zdarzenie łącza CoT Video – podczas gdy faktyczne wideo płynie punkt-punkt (lub przez przekaźnik) między źródłem a każdym widzem. To rozdzielenie utrzymuje wymagania przepustowości TAK Server na rozsądnym poziomie i pozwala wymiarować infrastrukturę wideo niezależnie od taktycznej sieci danych.

Zdarzenie CoT Video to standardowa wiadomość XML CoT typu b-i-v. Jej blok detail zawiera element Video z URL strumienia, czytelnym aliasem, typem protokołu (rtsp, rtsps lub udp), podpowiedzią kodeka i unikalnym identyfikatorem strumienia. Gdy TAK Server odbiera to zdarzenie, utrwala je i przekazuje wszystkim podłączonym klientom w odpowiedniej grupie. Klient ATAK odbierający zdarzenie Video automatycznie dodaje strumień do listy strumieni wtyczki Video Receiver – operator może następnie otworzyć podgląd według aliasu bez znajomości bazowego URL i bez ręcznej konfiguracji.

Ten sam model CoT obsługuje cofanie strumienia: opublikowanie zdarzenia Video z tym samym UID i nieaktualnym znacznikiem czasu z przeszłości usuwa strumień z list klientów. Czyni to zarządzanie cyklem życia strumienia programowalnym i spójnym z resztą modelu danych TAK.

Warstwa transportowa: RTSP, RTP i wybór kodeka

RTSP (Real Time Streaming Protocol) to dominujący transport dla podglądu wideo TAK. RTSP działa jako kanał kontrolny – negocjuje parametry sesji i ustanawia strumień – podczas gdy faktyczne media płyną przez RTP (Real-time Transport Protocol) na osobnym porcie. Dwa powszechne tryby transportu RTSP dla TAK to:

RTSP przez TCP (interleaved). Pakiety mediów RTP są multipleksowane do połączenia TCP RTSP. Ten tryb przechodzi przez NAT i reguły firewall bardziej niezawodnie niż UDP, ponieważ używa jednego ustanowionego połączenia TCP. Jest to zalecany tryb dla podglądu przesyłanego przez satelitę, LTE lub dowolne łącze z restrykcyjnym filtrowaniem pakietów. Kompromisem jest to, że zachowanie retransmisji TCP może dodawać zmienne opóźnienie podczas serii utraty pakietów – problem jakości połączenia na zdegradowanych łączach.

RTSP z transportem mediów UDP. Media RTP płyną przez osobne porty UDP negocjowane podczas wymiany RTSP SETUP. Transport UDP osiąga niższe opóźnienie bazowe niż TCP, ponieważ nie ma retransmisji – utracone pakiety dają artefakty wideo zamiast zatrzymania dekodera. Na lokalnym segmencie MANET z niską utratą pakietów (<1%) transport UDP jest preferowany. Na łączach o wyższym poziomie strat zachowanie zatrzymania dekodera w TCP jest często korzystniejsze niż błędy dekodowania UDP.

Co do wyboru kodeka, H.264 (AVC) w profilu Baseline lub Main to uniwersalna podstawa. Każde urządzenie Android obsługujące ATAK i każda instalacja WinTAK może sprzętowo dekodować H.264. H.265 (HEVC) redukuje przepustowość o około 40% przy równoważnej jakości – znacząca oszczędność na łączach radiowych – ale wymaga jawnej obsługi dekodera na urządzeniu odbiorczym. Starszy wzmocniony sprzęt Android może nie mieć sprzętowego dekodowania H.265, przechodząc na dekodowanie programowe z wyższym narzutem CPU i opóźnienia. Bezpiecznym wyborem dla heterogenicznej floty jest H.264; H.265 jest odpowiedni, gdy zestaw urządzeń jest jednorodny i dobrze scharakteryzowany.

Przepływność i interwał klatek kluczowych

Wybór przepływności określa obciążenie przepustowości łącza taktycznego. Praktyczne wskazówki według typu łącza: 1,5–2,5 Mb/s dla dedykowanego backhaulu LTE z dobrym sygnałem; 800–1200 kb/s dla zarządzanej siatki Wi-Fi; 400–800 kb/s dla radia MANET z budżetem zagregowanym 1–2 Mb/s współdzielonym z ruchem CoT; 200–400 kb/s dla łącza satelitarnego lub BLOS. Poniżej 300 kb/s wideo H.264 1080p staje się wizualnie nieakceptowalne – zmniejsz rozdzielczość do 720p lub 480p zamiast dalej kompresować 1080p.

Interwał klatek kluczowych (interwał ramek I) określa, jak szybko nowy widz może zacząć wyświetlać strumień. Interwał klatek kluczowych 1 sekunda oznacza, że nowe połączenie zaczyna wyświetlanie najpóźniej w ciągu 1 sekundy od ostatniej klatki kluczowej. Interwał 4 sekund oszczędza przepustowość, ale oznacza, że nowi widzowie czekają do 4 sekund na pierwszą dekodowalną ramkę. Do użytku taktycznego zalecany interwał to 1–2 sekundy. Zwróć uwagę, że krótsze interwały zwiększają przepływność – interwał ramki I 1 sekunda przy 800 kb/s daje większe ramki I mniej więcej co 800 kbitów, co może powodować krótkie skoki przepływności na łączu.

Architektura przekaźnikowa dla ograniczonych i wielokrotnych sieci

Bezpośredni model RTSP – klienci ATAK łączą się z serwerem RTSP urządzenia źródłowego – działa w płaskich sieciach lokalnych, ale zawodzi w większości wdrożeń operacyjnych. Naziemne stacje kontroli UAV są w innej podsieci IP niż klienci ATAK. Łącza satelitarne lub BLOS wymagają przekaźnika, aby wprowadzić zdalny podgląd do sieci taktycznej. Wielu jednoczesnych widzów obciąża przepustowość wysyłania urządzenia źródłowego. Serwer przekaźnikowy rozwiązuje wszystkie trzy problemy.

Przekaźnik pobiera strumień ze źródła raz – jedno połączenie, jeden strumień bajtów – i redystrybuuje go do dowolnej liczby konsumentów w dół strumienia. URL zdarzenia CoT Video jest ustawiony na adres przekaźnika, a nie źródła. Każdy klient ATAK łączy się z przekaźnikiem i otrzymuje ten sam strumień bez zwiększania obciążenia źródłowego GCS lub łącza UAV.

Węzeł serwera przekaźnikowego potrzebuje: bezpośredniej ścieżki sieciowej do źródła (segment sieci GCS lub punkt końcowy backhaulu satelitarnego) oraz ścieżki do sieci TAK. W standardowym wdrożeniu wysuniętego stanowiska dowodzenia przekaźnik działa na tym samym fizycznym węźle co TAK Server lub na dedykowanym węźle obliczeniowym na stanowisku dowodzenia. Dla wdrożeń brzegowych, gdzie przekaźnik musi działać blisko źródła (w pobliżu GCS), przekaźnik może przekazywać strumienie przez tunel OpenVPN lub WireGuard do sieci taktycznej, z drugą instancją przekaźnika po stronie TAK Server redystrybuującą lokalnie.

Publikacja wideo do sieci TAK przez CoT

Mechanika zdarzenia CoT Video jest prosta, ale pola detail mają znaczenie. Minimalne zgodne zdarzenie Video wygląda tak w bloku detail:

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

Dodatkowe opcjonalne pola niosą podpowiedzi kodeka (codec="H264"), limit czasu sieci w milisekundach (networkTimeout="10000") oraz podpowiedź czasu buforowania (bufferTime="0" – ustawienie tego na zero sygnalizuje odtwarzaczowi, że pożądany jest tryb niskiego opóźnienia, tłumiąc domyślny bufor klasy konsumenckiej). Pole uid to trwały identyfikator – ponowne użycie tego samego UID w późniejszym zdarzeniu aktualizuje odniesienie do strumienia zamiast tworzyć duplikat.

Dla deweloperów wtyczek ATAK publikujących wideo z wnętrza wtyczki: użyj API CotService, aby wstrzyknąć zdarzenie Video CoT do wewnętrznej szyny ATAK. Zdarzenie następnie propaguje do TAK Server przez aktywne łącze danych i stamtąd do wszystkich członków grupy. Nie ma osobnego API zarządzania wideo – szyna zdarzeń CoT jest jedynym mechanizmem dystrybucji.

Georeferencja: nakładka śladu czujnika

Strumień wideo wyświetlany w panelu Video Receiver pokazuje operatorowi to, co widzi kamera. Nakładka mapowa pokazuje każdemu innemu operatorowi, gdzie kamera jest skierowana. Te dwie rzeczy razem – zsynchronizowane wideo i ślad – dają COP prawdziwy kontekst przestrzenny, którego opis głosowy nie może zapewnić.

Dla podglądu z UAV obliczenie śladu wymaga pięciu danych wejściowych: pozycji drona WGS84 (szerokość, długość, wysokość nad ziemią), kąta obrotu gimbala (poziomy kierunek wskazywania względem kursu drona), kąta pochylenia gimbala (kąt depresji poniżej poziomu) oraz poziomego i pionowego pola widzenia kamery. Z nich konstruowane są cztery narożne wektory promieni i przecinane z powierzchnią terenu (modelem wysokości DTED lub przybliżeniem płaskiej ziemi dla operacji niskiego pułapu). Cztery punkty przecięcia tworzą wierzchołki wielokąta śladu.

Ślad jest publikowany jako CoT GeoObject – zdarzenie CoT wypełnionego wielokąta – przy użyciu spójnego UID powiązanego z dronem lub czujnikiem. Aktualizuje się z częstotliwością telemetrii. Dla celów nakładki mapowej aktualizacje 1–2 Hz są wizualnie płynne i nakładają znikome obciążenie ruchu CoT. Przy wyższych prędkościach obrotu gimbala (szybkie panoramowanie podczas aktywnego śledzenia) 5 Hz zapewnia lepsze śledzenie ruchu śladu na mapie. Częstotliwość aktualizacji powinna być niezależnie konfigurowalna od częstotliwości telemetrii używanej do śladu pozycji drona.

Kamery stacjonarne – na maszcie, czujniki perymetryczne na pojeździe – produkują statyczny lub wolno zmieniający się ślad. Dla kamery o stałym azymucie ślad to trapez zorientowany w kierunku kursu kamery, aktualizowany tylko przy zmianie poziomu zoomu lub zmianie położenia kamery. Publikacja śladu dla czujników stacjonarnych podąża za tym samym mechanizmem CoT GeoObject; wydawcą jest oprogramowanie zarządzania czujnikiem, a nie most telemetrii UAV.

Budżet opóźnień: opóźnienie wyświetlania i jego źródła

Całkowite opóźnienie wyświetlania – od momentu uchwycenia sceny przez kamerę do momentu pojawienia się jej na ekranie operatora – jest sumą pięciu sekwencyjnych opóźnień:

Opóźnienie kodowania: 30–80 ms na wydajnym koderze sprzętowym z H.264. Kodery programowe na małym sprzęcie obliczeniowym UAV mogą dodać 100–200 ms. Nie jest to regulowane przez operatora stacji naziemnej.

Opóźnienie tranzytu sieciowego: 10–50 ms dla MANET lub LTE w linii wzroku; 30–150 ms dla siatki wieloskokowej; 500–600 ms w jedną stronę dla przekaźnika satelity geostacjonarnego. Przekaźnik satelitarny to pojedynczy największy stały wkład w opóźnienie i nakłada twarde ograniczenie na osiągalne opóźnienie end-to-end dla podglądu z backhaulem satelitarnym.

Opóźnienie przetwarzania przekaźnika: mniej niż 5 ms dla dobrze zaimplementowanego przekaźnika RTSP. Znikome, jeśli przekaźnik jest na lokalnym węźle.

Bufor jittera po stronie odbiorczej: największe sterowalne źródło opóźnienia. Bufor jittera 2 sekundy – domyślny w wielu konsumenckich odtwarzaczach wideo – dodaje 2 sekundy stałego opóźnienia do każdej ramki. Do użytku taktycznego bufor jittera powinien być zmniejszony do 100–300 ms. Kompromisem są zwiększone artefakty wizualne podczas serii utraty pakietów. To decyzja operacyjna: zaakceptować okazjonalne zakłócenia ramek w zamian za obraz niemal w czasie rzeczywistym lub zaakceptować 2-sekundowe opóźnienie dla płynnego odtwarzania. Dla rażenia celów wrażliwych czasowo ustawienie 100–300 ms jest obowiązkowe.

Potok dekodowania i wyświetlania: 20–40 ms dla sprzętowo przyspieszanego dekodowania H.264 na nowoczesnym urządzeniu Android. Nieregulowane.

Zarządzanie wieloma strumieniami i UX operatora

Pojedynczy klient ATAK może wyświetlać wiele jednoczesnych strumieni wideo. Wtyczka Video Receiver prezentuje zarejestrowane strumienie według aliasu na liście; operator dotyka, aby otworzyć podgląd w pływającym panelu lub na pełnym ekranie. Dla pododdziałów operujących wieloma UAV jednocześnie konwencja nazewnictwa aliasów strumieni jest podstawowym elementem sterowania UX: spójna konwencja (DRONE-[CALLSIGN]-[SENSOR]) pozwala operatorom natychmiast zidentyfikować właściwy podgląd bez prób i błędów.

Sygnały priorytetu strumienia – osadzone w polu remarks zdarzenia CoT Video lub w towarzyszącym zdarzeniu CoT – mogą być używane przez oprogramowanie C2 do automatycznego wysuwania na pierwszy plan podglądu o najwyższym priorytecie. TAKpilot na przykład może odebrać polecenie operatora w języku naturalnym („pokaż mi kamerę drona Alpha”) i wysunąć odpowiedni strumień na pierwszy plan według nazwy aliasu bez ręcznej nawigacji operatora po liście strumieni.

Dla pododdziałów używających WinTAK na stanowisku dowodzenia te same zdarzenia CoT Video dystrybuowane przez TAK Server zapełniają listę wideo WinTAK identycznie. Większa przestrzeń ekranu WinTAK obsługuje panele wideo obok siebie, czyniąc go preferowaną platformą dla operatorów dronów i węzłów C2 monitorujących wiele podglądów jednocześnie. Bazowy protokół strumienia i architektura przekaźnikowa są identyczne niezależnie od tego, czy konsumentem jest ATAK, czy WinTAK.