Streaming video în TAK: integrarea fluxurilor live în COP

Un echipaj de dronă vede o coloană de vehicule deplasându-se printr-o linie de copaci. Ofițerul S2, la trei kilometri distanță, privește o hartă fără video. Operatorul dronei relatează prin radioul de voce. Până când acea informație devine o intrare în imaginea operațională comună, coloana s-a deplasat deja. Integrarea video live în TAK elimină acest decalaj – plasează fluxul direct pe COP, georeferențiat, distribuit și accesibil pe fiecare client ATAK și WinTAK din rețea, fără configurare manuală. Acest articol acoperă întreaga stivă de integrare: configurarea transportului RTSP, publicarea linkului video CoT, georeferențierea amprentei senzorului, arhitectura de releu pentru legături constrânse, bugetele de latență și configurarea afișării în ATAK Video Receiver.

Cum gestionează TAK video: modelul de link video CoT

TAK nu transportă octeți video prin TAK Server. Arhitectura este deliberat decuplată: TAK Server distribuie o referință către un flux – un eveniment de link CoT Video – în timp ce video-ul efectiv circulă punct-la-punct (sau printr-un releu) între sursă și fiecare spectator. Această separare menține cerințele de lățime de bandă ale TAK Server gestionabile și permite ca infrastructura video să fie dimensionată independent de rețeaua de date tactică.

Un eveniment CoT Video este un mesaj CoT XML standard cu tipul b-i-v. Blocul său detail conține un element Video cu URL-ul fluxului, un alias lizibil de om, tipul de protocol (rtsp, rtsps sau udp), un indiciu de codec și un identificator unic de flux. Când TAK Server primește acest eveniment, îl persistă și îl retransmite către toți clienții conectați din grupul relevant. Un client ATAK care primește evenimentul Video adaugă automat fluxul în lista de fluxuri a plug-inului Video Receiver – operatorul poate apoi deschide fluxul după alias fără să cunoască URL-ul subiacent sau să configureze ceva manual.

Același model CoT gestionează revocarea fluxului: publicarea unui eveniment Video cu același UID și o marcă temporală expirată în trecut elimină fluxul din listele clienților. Acest lucru face gestionarea ciclului de viață al fluxului programatică și consistentă cu restul modelului de date TAK.

Stratul de transport: RTSP, RTP și selecția codecului

RTSP (Real Time Streaming Protocol) este transportul dominant pentru fluxurile video TAK. RTSP funcționează ca un canal de control – negociază parametrii sesiunii și stabilește fluxul – în timp ce media efectivă circulă peste RTP (Real-time Transport Protocol) pe un port separat. Cele două moduri comune de transport RTSP pentru TAK sunt:

RTSP peste TCP (interleaved). Pachetele media RTP sunt multiplexate în conexiunea TCP RTSP. Acest mod traversează regulile NAT și firewall mai fiabil decât UDP, deoarece folosește o singură conexiune TCP stabilită. Este modul recomandat pentru fluxurile care călătoresc peste satelit, LTE sau orice legătură cu filtrare restrictivă a pachetelor. Compromisul este că comportamentul de retransmisie al TCP poate adăuga o latență variabilă în timpul rafalelor de pierdere de pachete – o problemă de calitate a conexiunii pe legăturile degradate.

RTSP cu transport media UDP. Media RTP circulă peste porturi UDP separate, negociate în timpul schimbului RTSP SETUP. Transportul UDP atinge o latență de bază mai mică decât TCP deoarece nu există retransmisie – pachetele pierdute produc artefacte video în loc să blocheze decodorul. Pe un segment MANET local cu pierdere redusă de pachete (<1%), transportul UDP este preferat. Pe legăturile cu rate de pierdere mai mari, comportamentul de blocare a decodorului al TCP este adesea preferabil erorilor de decodare ale UDP.

Pentru selecția codecului, H.264 (AVC) la profil Baseline sau Main este linia de bază universală. Fiecare dispozitiv Android capabil de ATAK și fiecare instalare WinTAK poate decoda hardware H.264. H.265 (HEVC) reduce lățimea de bandă cu aproximativ 40% la calitate echivalentă – o economie semnificativă pe legăturile radio – dar necesită suport explicit de decodor pe dispozitivul receptor. Hardware-ul Android ruggedizat mai vechi poate să nu aibă suport de decodare hardware H.265, recurgând la decodarea software cu o supraîncărcare mai mare de CPU și latență. Alegerea sigură pentru o flotă eterogenă este H.264; H.265 este potrivit când setul de dispozitive este omogen și bine caracterizat.

Rata de biți și intervalul de keyframe

Selecția ratei de biți determină sarcina de lățime de bandă pe legătura tactică. Ghid practic în funcție de tipul de legătură: 1,5–2,5 Mbps pentru un backhaul LTE dedicat cu semnal bun; 800–1200 kbps pentru un mesh Wi-Fi gestionat; 400–800 kbps pentru un radio MANET cu un buget agregat de 1–2 Mbps partajat cu traficul CoT; 200–400 kbps pentru o legătură prin satelit sau BLOS. Sub 300 kbps, video-ul H.264 1080p devine inacceptabil vizual – redu la rezoluția 720p sau 480p în loc să comprimi mai mult 1080p.

Intervalul de keyframe (intervalul I-frame) determină cât de repede un nou spectator poate începe să afișeze fluxul. Un interval de keyframe de 1 secundă înseamnă că o nouă conexiune începe să afișeze în cel mult 1 secundă de la ultimul keyframe. Un interval de 4 secunde economisește lățime de bandă, dar înseamnă că noii spectatori așteaptă până la 4 secunde pentru primul cadru decodabil. Pentru uz tactic, 1–2 secunde este intervalul recomandat. Reține că intervalele mai scurte cresc rata de biți – un interval I-frame de 1 secundă la 800 kbps produce cadre I mai mari aproximativ la fiecare 800 kbiți, ceea ce poate cauza vârfuri scurte de rată de biți pe legătură.

Arhitectura de releu pentru rețele constrânse și multi-hop

Modelul RTSP direct – clienții ATAK se conectează la serverul RTSP al dispozitivului sursă – funcționează pe rețelele locale plate, dar eșuează în majoritatea implementărilor operaționale. Stațiile de control la sol ale UAV-urilor sunt pe o subrețea IP diferită de clienții ATAK. Legăturile prin satelit sau BLOS necesită releu pentru a aduce fluxurile la distanță în rețeaua tactică. Mai mulți spectatori simultani solicită lățimea de bandă de încărcare a dispozitivului sursă. Un server de releu rezolvă toate cele trei probleme.

Releul extrage fluxul de la sursă o singură dată – o singură conexiune, un singur flux de octeți – și îl redistribuie către orice număr de consumatori din aval. URL-ul evenimentului CoT Video este setat la adresa releului, nu a sursei. Fiecare client ATAK se conectează la releu și primește același flux fără a crește sarcina pe GCS-ul sursă sau pe legătura UAV.

Un nod de server de releu are nevoie de: o cale de rețea directă către sursă (segmentul de rețea GCS sau punctul terminal de backhaul prin satelit) și o cale către rețeaua TAK. Într-o implementare standard de post de comandă înaintat, releul rulează pe același nod fizic ca TAK Server, sau pe un nod de calcul dedicat la postul de comandă. Pentru implementările de margine în care releul trebuie să ruleze aproape de sursă (lângă GCS), releul poate transmite fluxurile printr-un tunel OpenVPN sau WireGuard în rețeaua tactică, cu o a doua instanță de releu pe partea TAK Server care redistribuie local.

Publicarea video în rețeaua TAK prin CoT

Mecanica evenimentului CoT Video este simplă, dar câmpurile de detaliu contează. Un eveniment Video minim conform arată astfel în blocul detail:

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

Câmpurile opționale suplimentare poartă indicii de codec (codec="H264"), timeout de rețea în milisecunde (networkTimeout="10000") și un indiciu de timp de buffer (bufferTime="0" – setarea acestuia la zero semnalează playerului că este dorit modul de latență redusă, suprimând bufferul implicit de nivel consumator). Câmpul uid este identificatorul persistent – reutilizarea aceluiași UID într-un eveniment ulterior actualizează referința fluxului în loc să creeze un duplicat.

Pentru dezvoltatorii de plug-inuri ATAK care publică video din interiorul unui plug-in: folosește API-ul CotService pentru a injecta evenimentul Video CoT în magistrala internă a ATAK. Evenimentul se propagă apoi către TAK Server peste legătura de date activă și de acolo către toți membrii grupului. Nu există un API separat de gestionare video – magistrala de evenimente CoT este singurul mecanism de distribuție.

Georeferențiere: overlay-ul amprentei senzorului

Un flux video afișat în panoul Video Receiver arată operatorului ce vede camera. Overlay-ul de hartă arată fiecărui alt operator unde este îndreptată camera. Cele două împreună – video sincronizat și amprentă – oferă COP-ului un context spațial autentic pe care descrierea vocală nu îl poate furniza.

Pentru fluxurile UAV, calculul amprentei necesită cinci intrări: poziția WGS84 a dronei (latitudine, longitudine, altitudine deasupra solului), unghiul de panoramare al gimbalului (direcția de orientare orizontală față de direcția dronei), unghiul de înclinare al gimbalului (unghiul de coborâre sub orizontală) și câmpul vizual orizontal și vertical al camerei. Din acestea, se construiesc patru vectori de rază de colț și se intersectează cu o suprafață de teren (un model de elevație DTED sau o aproximare de Pământ plat pentru operațiunile la altitudine joasă). Cele patru puncte de intersecție formează vârfurile poligonului amprentei.

Amprenta este publicată ca un CoT GeoObject – un eveniment CoT de poligon umplut – folosind un UID consistent legat de dronă sau senzor. Se actualizează la rata de telemetrie. Pentru scopuri de overlay pe hartă, actualizările de 1–2 Hz sunt vizual fluide și impun o sarcină neglijabilă de trafic CoT. La rate de rotire mai mari ale gimbalului (panoramare rapidă în timpul urmăririi active), 5 Hz oferă o urmărire mai bună a mișcării amprentei pe hartă. Rata de actualizare ar trebui să fie configurabilă independent de rata de telemetrie folosită pentru pista de poziție a dronei.

Camerele fixe – senzori de perimetru montați pe turn, montați pe vehicul – produc o amprentă statică sau care se schimbă lent. Pentru o cameră cu azimut fix, amprenta este un trapez orientat în direcția de orientare a camerei, actualizat doar când nivelul de zoom se modifică sau camera este repoziționată. Publicarea amprentei pentru senzorii ficși urmează același mecanism CoT GeoObject; editorul este software-ul de gestionare a senzorilor, nu o punte de telemetrie UAV.

Bugetul de latență: latența de afișare și sursele acesteia

Latența totală de afișare – din momentul în care o scenă este capturată de cameră până în momentul în care apare pe ecranul operatorului – este suma a cinci întârzieri secvențiale:

Latența de encodare: 30–80 ms pe un encoder hardware capabil care rulează H.264. Encoderele software pe hardware-ul de calcul UAV mic pot adăuga 100–200 ms. Aceasta nu este reglabilă de operatorul stației de la sol.

Latența de tranzit prin rețea: 10–50 ms pentru MANET sau LTE cu linie directă; 30–150 ms pentru mesh multi-hop; 500–600 ms într-un sens pentru releul prin satelit geostaționar. Releul prin satelit este cel mai mare contribuitor unic de latență fixă și impune o constrângere dură asupra latenței end-to-end realizabile pentru fluxurile cu backhaul prin satelit.

Latența de procesare a releului: mai puțin de 5 ms pentru un releu RTSP bine implementat. Neglijabilă dacă releul este pe un nod local.

Bufferul de jitter de pe partea de recepție: cea mai mare sursă controlabilă de latență. Un buffer de jitter de 2 secunde – implicit în multe playere video pentru consumatori – adaugă 2 secunde de latență fixă la fiecare cadru. Pentru uz tactic, bufferul de jitter ar trebui redus la 100–300 ms. Compromisul îl reprezintă artefactele vizuale crescute în timpul rafalelor de pierdere de pachete. Aceasta este o decizie operațională: acceptă defecțiuni ocazionale de cadre în schimbul imaginilor aproape în timp real, sau acceptă o latență de 2 secunde pentru o redare fluidă. Pentru țintirea sensibilă la timp, setarea de 100–300 ms este obligatorie.

Conducta de decodare și afișare: 20–40 ms pentru decodarea H.264 accelerată hardware pe un dispozitiv Android modern. Nereglabilă.

Gestionarea fluxurilor multiple și UX-ul operatorului

Un singur client ATAK poate afișa mai multe fluxuri video simultane. Plug-inul Video Receiver prezintă fluxurile înregistrate după alias într-o listă; operatorul atinge pentru a deschide un flux într-un panou flotant sau pe ecran complet. Pentru unitățile care operează simultan mai multe UAV-uri, convenția de denumire a aliasului fluxului este controlul UX principal: o convenție consistentă (DRONE-[INDICATIV]-[SENZOR]) le permite operatorilor să identifice instant fluxul corect fără încercări și erori.

Semnalele de prioritate ale fluxului – încorporate în câmpul remarks al evenimentului CoT Video sau într-un eveniment CoT însoțitor – pot fi folosite de software-ul C2 pentru a aduce automat în prim-plan fluxul cu cea mai mare prioritate. TAKpilot, de exemplu, poate primi o comandă a operatorului în limbaj natural ("arată-mi camera dronei Alpha") și poate aduce fluxul corespunzător în prim-plan după numele aliasului fără ca operatorul să navigheze lista de fluxuri manual.

Pentru unitățile care folosesc WinTAK la postul de comandă, aceleași evenimente CoT Video distribuite prin TAK Server populează identic lista video a WinTAK. Spațiul mai mare de ecran al WinTAK susține panouri video alăturate, făcându-l platforma preferată pentru operatorii de drone și nodurile C2 care monitorizează simultan mai multe fluxuri. Protocolul de flux subiacent și arhitectura de releu sunt identice indiferent dacă consumatorul este ATAK sau WinTAK.