Videostreaming in TAK: live beelden integreren in het COP

Een dronebemanning ziet een voertuigcolonne door een bomenrij bewegen. De S2-officier, drie kilometer verderop, staart naar een kaart zonder video. De drone-operator vertelt het via spraakradio. Tegen de tijd dat die informatie een vermelding in het gemeenschappelijke operationele beeld wordt, is de colonne verplaatst. Live video-integratie in TAK elimineert dat gat – het plaatst de feed rechtstreeks op het COP, georefereerd, verspreid en toegankelijk op elke ATAK- en WinTAK-client in het netwerk zonder handmatige configuratie. Dit artikel behandelt de volledige integratiestack: RTSP-transportconfiguratie, CoT-videolink-publicatie, georeferentie van de sensorvoetafdruk, relay-architectuur voor beperkte verbindingen, latentiebudgetten en weergaveconfiguratie in de ATAK Video Receiver.

Hoe TAK video afhandelt: het CoT-videolinkmodel

TAK draagt geen videobytes door de TAK Server. De architectuur is bewust ontkoppeld: de TAK Server verspreidt een referentie naar een stream – een CoT Video-link-event – terwijl de daadwerkelijke video punt-naar-punt stroomt (of via een relay) tussen de bron en elke kijker. Deze scheiding houdt de bandbreedtevereisten van de TAK Server beheersbaar en maakt het mogelijk om de video-infrastructuur onafhankelijk van het tactische datanetwerk te dimensioneren.

Een CoT Video-event is een standaard CoT XML-bericht met type b-i-v. Het detail-blok bevat een Video-element met de stream-URL, een door mensen leesbare alias, het protocoltype (rtsp, rtsps of udp), een codec-hint en een unieke streamidentificator. Wanneer de TAK Server dit event ontvangt, slaat hij het persistent op en geeft het door aan alle verbonden clients in de relevante groep. Een ATAK-client die het Video-event ontvangt, voegt de stream automatisch toe aan de streamlijst van de Video Receiver-plug-in – de operator kan de feed dan op alias openen zonder de onderliggende URL te kennen of iets handmatig te configureren.

Hetzelfde CoT-model handelt de intrekking van streams af: het publiceren van een Video-event met dezelfde UID en een verlopen tijdstempel in het verleden verwijdert de stream uit de clientlijsten. Dit maakt het beheer van de streamlevenscyclus programmatisch en consistent met de rest van het TAK-datamodel.

Transportlaag: RTSP, RTP en codecselectie

RTSP (Real Time Streaming Protocol) is het dominante transport voor TAK-videofeeds. RTSP fungeert als een besturingskanaal – het onderhandelt over sessieparameters en brengt de stream tot stand – terwijl de daadwerkelijke media over RTP (Real-time Transport Protocol) op een aparte poort stroomt. De twee gangbare RTSP-transportmodi voor TAK zijn:

RTSP over TCP (interleaved). De RTP-mediapakketten worden gemultiplext in de RTSP TCP-verbinding. Deze modus passeert NAT- en firewallregels betrouwbaarder dan UDP omdat hij één tot stand gebrachte TCP-verbinding gebruikt. Het is de aanbevolen modus voor feeds die over satelliet, LTE of een verbinding met restrictieve pakketfiltering reizen. De afweging is dat het retransmissiegedrag van TCP variabele latentie kan toevoegen tijdens uitbarstingen van pakketverlies – een verbindingskwaliteitsprobleem op gedegradeerde verbindingen.

RTSP met UDP-mediatransport. De RTP-media stroomt over aparte UDP-poorten die tijdens de RTSP SETUP-uitwisseling worden onderhandeld. UDP-transport bereikt een lagere basislatentie dan TCP omdat er geen retransmissie is – verloren pakketten produceren videoartefacten in plaats van de decoder te laten stagneren. Op een lokaal MANET-segment met laag pakketverlies (<1%) heeft UDP-transport de voorkeur. Op verbindingen met hogere verliespercentages is het decoder-stagneergedrag van TCP vaak verkieslijker dan de decodeerfouten van UDP.

Voor codecselectie is H.264 (AVC) op Baseline- of Main-profiel de universele basislijn. Elk ATAK-capabel Android-apparaat en elke WinTAK-installatie kan H.264 in hardware decoderen. H.265 (HEVC) vermindert de bandbreedte met ongeveer 40% bij gelijkwaardige kwaliteit – een aanzienlijke besparing op radioverbindingen – maar vereist expliciete decoderondersteuning op het ontvangende apparaat. Oudere geruggedized Android-hardware kan H.265-hardwaredecodering missen en terugvallen op softwaredecodering met hogere CPU- en latentie-overhead. De veilige keuze voor een heterogene vloot is H.264; H.265 is geschikt wanneer de apparaatset homogeen en goed gekarakteriseerd is.

Bitrate en keyframe-interval

De bitrate-selectie bepaalt de bandbreedtebelasting op de tactische verbinding. Praktische richtlijnen per verbindingstype: 1,5–2,5 Mbps voor een toegewijde LTE-backhaul met goed signaal; 800–1200 kbps voor een beheerd Wi-Fi-mesh; 400–800 kbps voor een MANET-radio met een gedeeld totaalbudget van 1–2 Mbps met CoT-verkeer; 200–400 kbps voor een satelliet- of BLOS-verbinding. Onder 300 kbps wordt H.264 1080p-video visueel onaanvaardbaar – verlaag naar 720p- of 480p-resolutie in plaats van 1080p verder te comprimeren.

Het keyframe-interval (I-frame-interval) bepaalt hoe snel een nieuwe kijker de stream kan beginnen weergeven. Een keyframe-interval van 1 seconde betekent dat een nieuwe verbinding binnen maximaal 1 seconde na het laatste keyframe begint weer te geven. Een interval van 4 seconden bespaart bandbreedte maar betekent dat nieuwe kijkers tot 4 seconden wachten op het eerste decodeerbare frame. Voor tactisch gebruik is 1–2 seconden het aanbevolen interval. Merk op dat kortere intervallen de bitrate verhogen – een I-frame-interval van 1 seconde bij 800 kbps produceert ongeveer elke 800 kbits grotere I-frames, wat kortstondige bitratepieken op de verbinding kan veroorzaken.

Relay-architectuur voor beperkte en multi-hop-netwerken

Het directe RTSP-model – ATAK-clients maken verbinding met de RTSP-server van het bronapparaat – werkt op platte lokale netwerken maar faalt in de meeste operationele implementaties. UAV-grondbesturingsstations bevinden zich op een ander IP-subnet dan ATAK-clients. Satelliet- of BLOS-verbindingen vereisen een relay om externe feeds in het tactische netwerk te brengen. Meerdere gelijktijdige kijkers belasten de uploadbandbreedte van het bronapparaat. Een relayserver pakt alle drie de problemen aan.

De relay haalt de stream één keer van de bron op – een enkele verbinding, een enkele stroom bytes – en herverdeelt deze naar een willekeurig aantal downstream-consumenten. De URL van het CoT Video-event wordt ingesteld op het adres van de relay, niet de bron. Elke ATAK-client maakt verbinding met de relay en ontvangt dezelfde stream zonder de belasting op het bron-GCS of de UAV-verbinding te verhogen.

Een relayserverknooppunt heeft nodig: een direct netwerkpad naar de bron (GCS-netwerksegment of satelliet-backhaul-eindpunt) en een pad naar het TAK-netwerk. In een standaard vooruitgeschoven commandopostimplementatie draait de relay op hetzelfde fysieke knooppunt als de TAK Server, of op een toegewijd rekenknooppunt op de commandopost. Voor edge-implementaties waarbij de relay dicht bij de bron moet draaien (nabij het GCS), kan de relay streams doorsturen over een OpenVPN- of WireGuard-tunnel naar het tactische netwerk, met een tweede relay-instantie aan de TAK Server-zijde die lokaal herverdeelt.

Video publiceren naar het TAK-netwerk via CoT

De mechanica van het CoT Video-event is eenvoudig, maar de detailvelden zijn belangrijk. Een minimaal conform Video-event ziet er als volgt uit in het detail-blok:

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

Aanvullende optionele velden dragen codec-hints (codec="H264"), netwerktime-out in milliseconden (networkTimeout="10000") en een buffertijd-hint (bufferTime="0" – dit op nul instellen signaleert de speler dat de modus met lage latentie gewenst is, waarbij de standaard consumentenbuffer wordt onderdrukt). Het uid-veld is de persistente identificator – het hergebruiken van dezelfde UID in een later event werkt de streamreferentie bij in plaats van een duplicaat te maken.

Voor ATAK-plug-in-ontwikkelaars die video vanuit een plug-in publiceren: gebruik de CotService-API om het Video-CoT-event in de interne bus van ATAK te injecteren. Het event propageert dan naar de TAK Server over de actieve datalink en van daaruit naar alle groepsleden. Er is geen aparte videobeheer-API – de CoT-eventbus is het enige distributiemechanisme.

Georeferentie: de sensorvoetafdrukoverlay

Een in het Video Receiver-paneel weergegeven videofeed toont de operator wat de camera ziet. De kaartoverlay toont elke andere operator waar de camera op gericht is. De twee samen – gesynchroniseerde video en voetafdruk – geven het COP een echte ruimtelijke context die een gesproken beschrijving niet kan bieden.

Voor UAV-feeds vereist de voetafdrukberekening vijf invoeren: de WGS84-positie van de drone (breedtegraad, lengtegraad, hoogte boven de grond), de panhoek van de gimbal (horizontale richtingsaanwijzing ten opzichte van de koers van de drone), de kantelhoek van de gimbal (depressiehoek onder het horizontale) en het horizontale en verticale gezichtsveld van de camera. Hieruit worden vier hoekstraalvectoren geconstrueerd en gesneden met een terreinoppervlak (een DTED-hoogtemodel, of een platte-aardebenadering voor operaties op lage hoogte). De vier snijpunten vormen de hoekpunten van de voetafdrukpolygoon.

De voetafdruk wordt gepubliceerd als een CoT GeoObject – een gevuld-polygoon-CoT-event – met een consistente UID die gekoppeld is aan de drone of sensor. Het wordt bijgewerkt op de telemetriesnelheid. Voor kaartoverlay-doeleinden zijn updates van 1–2 Hz visueel soepel en leggen ze een verwaarloosbare CoT-verkeersbelasting op. Bij hogere gimbal-zwenksnelheden (snel pannen tijdens actief volgen) biedt 5 Hz een betere volging van de beweging van de voetafdruk op de kaart. De updatesnelheid moet onafhankelijk configureerbaar zijn van de telemetriesnelheid die wordt gebruikt voor het positiespoor van de drone.

Vaste camera's – mast-gemonteerde, voertuig-gemonteerde perimetersensoren – produceren een statische of langzaam veranderende voetafdruk. Voor een camera met vaste azimut is de voetafdruk een trapezium dat in de koersrichting van de camera is georiënteerd, alleen bijgewerkt wanneer het zoomniveau verandert of de camera wordt verplaatst. Het publiceren van de voetafdruk voor vaste sensoren volgt hetzelfde CoT GeoObject-mechanisme; de uitgever is de sensorbeheersoftware in plaats van een UAV-telemetriebrug.

Latentiebudget: weergavelatentie en de bronnen daarvan

De totale weergavelatentie – van het moment dat een scène door de camera wordt vastgelegd tot het moment dat deze op het scherm van de operator verschijnt – is de som van vijf opeenvolgende vertragingen:

Encodeerlatentie: 30–80 ms op een capabele hardware-encoder die H.264 draait. Software-encoders op kleine UAV-rekenhardware kunnen 100–200 ms toevoegen. Dit is niet afstembaar door de grondstationoperator.

Netwerktransitlatentie: 10–50 ms voor zichtlijn-MANET of LTE; 30–150 ms voor multi-hop-mesh; 500–600 ms enkele richting voor geostationaire satellietrelay. Satellietrelay is de grootste vaste latentiebijdrager en legt een harde beperking op aan de haalbare end-to-end-latentie voor feeds met satelliet-backhaul.

Relayverwerkingslatentie: minder dan 5 ms voor een goed geïmplementeerde RTSP-relay. Verwaarloosbaar als de relay op een lokaal knooppunt staat.

Jitterbuffer aan ontvangstzijde: de grootste controleerbare latentiebron. Een jitterbuffer van 2 seconden – de standaard in veel consumentenvideospelers – voegt 2 seconden vaste latentie toe aan elk frame. Voor tactisch gebruik moet de jitterbuffer worden verlaagd naar 100–300 ms. De afweging zijn toegenomen visuele artefacten tijdens uitbarstingen van pakketverlies. Dit is een operationele beslissing: accepteer incidentele frameglitches in ruil voor bijna-realtime beelden, of accepteer 2 seconden latentie voor soepele weergave. Voor tijdgevoelige targeting is de instelling van 100–300 ms verplicht.

Decodeer- en weergavepijplijn: 20–40 ms voor hardware-versnelde H.264-decodering op een modern Android-apparaat. Niet afstembaar.

Multi-streambeheer en operator-UX

Eén ATAK-client kan meerdere gelijktijdige videostreams weergeven. De Video Receiver-plug-in presenteert geregistreerde streams op alias in een lijst; de operator tikt om een feed te openen in een zwevend paneel of op volledig scherm. Voor eenheden die meerdere UAV's tegelijkertijd bedienen, is de naamgevingsconventie voor stream-aliassen de primaire UX-controle: een consistente conventie (DRONE-[ROEPNAAM]-[SENSOR]) laat operators direct de juiste feed identificeren zonder vallen en opstaan.

Streamprioriteitssignalen – ingebed in het remarks-veld van het CoT Video-event of in een begeleidend CoT-event – kunnen door de C2-software worden gebruikt om de feed met de hoogste prioriteit automatisch naar voren te halen. TAKpilot kan bijvoorbeeld een operatorcommando in natuurlijke taal ontvangen ("toon mij de camera van de Alpha-drone") en de overeenkomstige stream op naam van alias naar de voorgrond brengen zonder dat de operator de streamlijst handmatig moet navigeren.

Voor eenheden die WinTAK op de commandopost gebruiken, vullen dezelfde via de TAK Server verspreide CoT Video-events de videolijst van WinTAK identiek. De grotere schermruimte van WinTAK ondersteunt video-panelen naast elkaar, waardoor het het voorkeursplatform is voor drone-operators en C2-knooppunten die meerdere feeds tegelijkertijd monitoren. Het onderliggende streamprotocol en de relay-architectuur zijn identiek, ongeacht of de consument ATAK of WinTAK is.