Video-Streaming in TAK: Live-Feeds in das COP integrieren

Eine Drohnenbesatzung sieht eine Fahrzeugkolonne, die sich entlang einer Baumreihe bewegt. Der S2-Offizier, drei Kilometer entfernt, starrt auf eine Karte ohne Video. Der Drohnenbediener berichtet über Sprechfunk. Bis diese Information ein Eintrag im gemeinsamen Lagebild wird, hat sich die Kolonne weiterbewegt. Die Live-Video-Integration in TAK beseitigt diese Lücke – sie bringt den Feed direkt auf das COP, georeferenziert, verteilt und auf jedem ATAK- und WinTAK-Client im Netz ohne manuelle Konfiguration zugänglich. Dieser Artikel behandelt den vollständigen Integrationsstack: RTSP-Transportkonfiguration, CoT-Videolink-Veröffentlichung, Georeferenzierung des Sensor-Footprints, Relay-Architektur für eingeschränkte Verbindungen, Latenzbudgets und anzeigeseitige Konfiguration im ATAK Video Receiver.

Wie TAK Video handhabt: das CoT-Videolink-Modell

TAK transportiert keine Videobytes durch den TAK Server. Die Architektur ist bewusst entkoppelt: Der TAK Server verteilt eine Referenz auf einen Stream – ein CoT-Video-Link-Ereignis – während das eigentliche Video Punkt-zu-Punkt (oder über ein Relay) zwischen der Quelle und jedem Zuschauer fließt. Diese Trennung hält die Bandbreitenanforderungen des TAK Servers beherrschbar und ermöglicht es, die Videoinfrastruktur unabhängig vom taktischen Datennetz zu dimensionieren.

Ein CoT-Video-Ereignis ist eine standardmäßige CoT-XML-Nachricht vom Typ b-i-v. Ihr detail-Block enthält ein Video-Element mit der Stream-URL, einem menschenlesbaren Alias, dem Protokolltyp (rtsp, rtsps oder udp), einem Codec-Hinweis und einer eindeutigen Stream-Kennung. Wenn der TAK Server dieses Ereignis empfängt, speichert er es und leitet es an alle verbundenen Clients der betreffenden Gruppe weiter. Ein ATAK-Client, der das Video-Ereignis empfängt, fügt den Stream automatisch der Stream-Liste des Video-Receiver-Plugins hinzu – der Bediener kann den Feed dann per Alias öffnen, ohne die zugrunde liegende URL zu kennen oder etwas manuell zu konfigurieren.

Dasselbe CoT-Modell handhabt den Stream-Widerruf: Die Veröffentlichung eines Video-Ereignisses mit derselben UID und einem veralteten Zeitstempel in der Vergangenheit entfernt den Stream aus den Client-Listen. Dies macht die Verwaltung des Stream-Lebenszyklus programmatisch und konsistent mit dem übrigen TAK-Datenmodell.

Transportschicht: RTSP, RTP und Codec-Auswahl

RTSP (Real Time Streaming Protocol) ist der dominierende Transport für TAK-Videofeeds. RTSP fungiert als Steuerkanal – es verhandelt Sitzungsparameter und stellt den Stream her – während die eigentlichen Medien über RTP (Real-time Transport Protocol) auf einem separaten Port fließen. Die zwei gängigen RTSP-Transportmodi für TAK sind:

RTSP über TCP (interleaved). Die RTP-Medienpakete werden in die RTSP-TCP-Verbindung gemultiplext. Dieser Modus durchquert NAT- und Firewall-Regeln zuverlässiger als UDP, weil er eine einzige aufgebaute TCP-Verbindung nutzt. Es ist der empfohlene Modus für Feeds, die über Satellit, LTE oder eine Verbindung mit restriktiver Paketfilterung laufen. Der Nachteil ist, dass das Retransmissionsverhalten von TCP während Paketverlust-Bursts variable Latenz hinzufügen kann – ein Problem der Verbindungsqualität auf degradierten Verbindungen.

RTSP mit UDP-Medientransport. Die RTP-Medien fließen über separate UDP-Ports, die während des RTSP-SETUP-Austauschs verhandelt werden. Der UDP-Transport erreicht eine geringere Basislatenz als TCP, weil keine Retransmission stattfindet – verlorene Pakete erzeugen Videoartefakte statt den Decoder anzuhalten. Auf einem lokalen MANET-Segment mit geringem Paketverlust (<1 %) wird der UDP-Transport bevorzugt. Auf Verbindungen mit höheren Verlustraten ist das Decoder-Stall-Verhalten von TCP oft den Decodierungsfehlern von UDP vorzuziehen.

Bei der Codec-Auswahl ist H.264 (AVC) im Baseline- oder Main-Profil die universelle Grundlage. Jedes ATAK-fähige Android-Gerät und jede WinTAK-Installation kann H.264 hardwareseitig decodieren. H.265 (HEVC) reduziert die Bandbreite bei gleichwertiger Qualität um rund 40 % – eine erhebliche Einsparung auf Funkverbindungen – erfordert aber explizite Decoder-Unterstützung auf dem empfangenden Gerät. Ältere ruggedisierte Android-Hardware verfügt möglicherweise nicht über H.265-Hardware-Decode und fällt auf Software-Decode mit höherem CPU- und Latenz-Overhead zurück. Die sichere Wahl für eine heterogene Flotte ist H.264; H.265 ist angemessen, wenn der Geräteumfang homogen und gut charakterisiert ist.

Bitrate und Keyframe-Intervall

Die Bitratenwahl bestimmt die Bandbreitenlast auf der taktischen Verbindung. Praktische Empfehlungen nach Verbindungstyp: 1,5–2,5 Mbit/s für einen dedizierten LTE-Backhaul mit gutem Signal; 800–1200 kbit/s für ein verwaltetes Wi-Fi-Mesh; 400–800 kbit/s für ein MANET-Funkgerät mit einem mit dem CoT-Verkehr geteilten Gesamtbudget von 1–2 Mbit/s; 200–400 kbit/s für eine Satelliten- oder BLOS-Verbindung. Unter 300 kbit/s wird H.264-1080p-Video visuell inakzeptabel – reduzieren Sie auf 720p- oder 480p-Auflösung, statt 1080p weiter zu komprimieren.

Das Keyframe-Intervall (I-Frame-Intervall) bestimmt, wie schnell ein neuer Zuschauer mit der Anzeige des Streams beginnen kann. Ein Keyframe-Intervall von 1 Sekunde bedeutet, dass eine neue Verbindung innerhalb von höchstens 1 Sekunde nach dem letzten Keyframe mit der Anzeige beginnt. Ein 4-Sekunden-Intervall spart Bandbreite, bedeutet aber, dass neue Zuschauer bis zu 4 Sekunden auf das erste decodierbare Bild warten. Für den taktischen Einsatz ist 1–2 Sekunden das empfohlene Intervall. Beachten Sie, dass kürzere Intervalle die Bitrate erhöhen – ein I-Frame-Intervall von 1 Sekunde bei 800 kbit/s erzeugt größere I-Frames etwa alle 800 kbit, was kurze Bitratenspitzen auf der Verbindung verursachen kann.

Relay-Architektur für eingeschränkte und Multi-Hop-Netze

Das direkte RTSP-Modell – ATAK-Clients verbinden sich mit dem RTSP-Server des Quellgeräts – funktioniert in flachen lokalen Netzen, scheitert aber in den meisten operativen Einsätzen. UAV-Bodenkontrollstationen befinden sich in einem anderen IP-Subnetz als ATAK-Clients. Satelliten- oder BLOS-Verbindungen erfordern ein Relay, um entfernte Feeds in das taktische Netz zu bringen. Mehrere gleichzeitige Zuschauer belasten die Upload-Bandbreite des Quellgeräts. Ein Relay-Server löst alle drei Probleme.

Das Relay zieht den Stream einmal von der Quelle – eine einzige Verbindung, ein einziger Bytestrom – und verteilt ihn an beliebig viele nachgelagerte Verbraucher. Die URL des CoT-Video-Ereignisses wird auf die Adresse des Relays statt auf die Quelle gesetzt. Jeder ATAK-Client verbindet sich mit dem Relay und erhält denselben Stream, ohne die Last auf der Quell-GCS oder der UAV-Verbindung zu erhöhen.

Ein Relay-Server-Knoten benötigt: einen direkten Netzpfad zur Quelle (GCS-Netzsegment oder Satelliten-Backhaul-Endpunkt) und einen Pfad zum TAK-Netz. In einem standardmäßigen Einsatz an einer vorgeschobenen Gefechtsstation läuft das Relay auf demselben physischen Knoten wie der TAK Server oder auf einem dedizierten Rechenknoten an der Gefechtsstation. Für Edge-Einsätze, bei denen das Relay nahe der Quelle (in der Nähe der GCS) laufen muss, kann das Relay Streams über einen OpenVPN- oder WireGuard-Tunnel in das taktische Netz weiterleiten, mit einer zweiten Relay-Instanz auf der TAK-Server-Seite, die lokal weiterverteilt.

Veröffentlichung von Video in das TAK-Netz über CoT

Die Mechanik des CoT-Video-Ereignisses ist unkompliziert, aber die Detailfelder sind wichtig. Ein minimales konformes Video-Ereignis sieht im detail-Block so aus:

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

Zusätzliche optionale Felder tragen Codec-Hinweise (codec="H264"), Netzwerk-Timeout in Millisekunden (networkTimeout="10000") und einen Pufferzeit-Hinweis (bufferTime="0" – das Setzen auf null signalisiert dem Player, dass ein Modus mit geringer Latenz gewünscht ist, und unterdrückt den standardmäßigen Consumer-Puffer). Das uid-Feld ist die persistente Kennung – die Wiederverwendung derselben UID in einem späteren Ereignis aktualisiert die Stream-Referenz, statt ein Duplikat zu erzeugen.

Für Entwickler von ATAK-Plugins, die Video aus einem Plugin heraus veröffentlichen: Verwenden Sie die CotService-API, um das Video-CoT-Ereignis in den internen Bus von ATAK einzuspeisen. Das Ereignis propagiert dann über die aktive Datenverbindung zum TAK Server und von dort an alle Gruppenmitglieder. Es gibt keine separate Videoverwaltungs-API – der CoT-Ereignisbus ist der einzige Verteilungsmechanismus.

Georeferenzierung: das Sensor-Footprint-Overlay

Ein im Video-Receiver-Panel angezeigter Videofeed zeigt dem Bediener, was die Kamera sieht. Das Kartenüberlagerung zeigt jedem anderen Bediener, wohin die Kamera zeigt. Beide zusammen – synchronisiertes Video und Footprint – geben dem COP echten räumlichen Kontext, den eine Sprachbeschreibung nicht liefern kann.

Bei UAV-Feeds erfordert die Footprint-Berechnung fünf Eingaben: die WGS84-Position der Drohne (Breite, Länge, Höhe über Grund), den Schwenkwinkel des Gimbals (horizontale Ausrichtungsrichtung relativ zum Drohnenkurs), den Neigewinkel des Gimbals (Depressionswinkel unter der Horizontalen) sowie das horizontale und vertikale Sichtfeld der Kamera. Daraus werden vier Eck-Strahlenvektoren konstruiert und mit einer Geländeoberfläche geschnitten (einem DTED-Höhenmodell oder einer Flacherde-Näherung für Operationen in geringer Höhe). Die vier Schnittpunkte bilden die Eckpunkte des Footprint-Polygons.

Der Footprint wird als CoT-GeoObject – ein gefülltes Polygon-CoT-Ereignis – mit einer konsistenten, an die Drohne oder den Sensor gebundenen UID veröffentlicht. Er wird mit der Telemetrierate aktualisiert. Für Zwecke des Kartenüberlagerungs sind Aktualisierungen mit 1–2 Hz visuell flüssig und belasten den CoT-Verkehr vernachlässigbar. Bei höheren Gimbal-Schwenkraten (schnelles Schwenken bei aktiver Verfolgung) bietet 5 Hz eine bessere Verfolgung der Footprint-Bewegung auf der Karte. Die Aktualisierungsrate sollte unabhängig von der für die Positionsspur der Drohne verwendeten Telemetrierate konfigurierbar sein.

Stationäre Kameras – mastmontierte, fahrzeugmontierte Perimetersensoren – erzeugen einen statischen oder sich langsam ändernden Footprint. Für eine Kamera mit festem Azimut ist der Footprint ein Trapez, das in Kursrichtung der Kamera ausgerichtet ist und nur bei Änderung der Zoomstufe oder Umpositionierung der Kamera aktualisiert wird. Die Veröffentlichung des Footprints für stationäre Sensoren folgt demselben CoT-GeoObject-Mechanismus; der Publisher ist die Sensorverwaltungssoftware statt einer UAV-Telemetriebrücke.

Latenzbudget: Anzeigelatenz und ihre Quellen

Die Gesamt-Anzeigelatenz – vom Moment, in dem eine Szene von der Kamera erfasst wird, bis zu dem Moment, in dem sie auf dem Bildschirm des Bedieners erscheint – ist die Summe von fünf sequenziellen Verzögerungen:

Encoding-Latenz: 30–80 ms auf einem leistungsfähigen Hardware-Encoder mit H.264. Software-Encoder auf kleiner UAV-Rechenhardware können 100–200 ms hinzufügen. Dies ist vom Bodenstationsbediener nicht einstellbar.

Netzwerk-Transitlatenz: 10–50 ms für MANET oder LTE mit Sichtverbindung; 30–150 ms für Multi-Hop-Mesh; 500–600 ms in eine Richtung für geostationäres Satelliten-Relay. Das Satelliten-Relay ist der einzelne größte feste Latenzbeitrag und legt eine harte Beschränkung für die erreichbare Ende-zu-Ende-Latenz bei Satelliten-Backhaul-Feeds fest.

Relay-Verarbeitungslatenz: weniger als 5 ms für ein gut implementiertes RTSP-Relay. Vernachlässigbar, wenn sich das Relay auf einem lokalen Knoten befindet.

Empfangsseitiger Jitter-Puffer: die größte steuerbare Latenzquelle. Ein 2-Sekunden-Jitter-Puffer – die Voreinstellung in vielen Consumer-Videoplayern – fügt jedem Bild 2 Sekunden feste Latenz hinzu. Für den taktischen Einsatz sollte der Jitter-Puffer auf 100–300 ms reduziert werden. Der Nachteil sind verstärkte visuelle Artefakte während Bursts von Paketverlust. Dies ist eine operative Entscheidung: gelegentliche Bildstörungen im Austausch für nahezu Echtzeit-Bilder akzeptieren oder 2 Sekunden Latenz für flüssige Wiedergabe akzeptieren. Für zeitkritische Zielbekämpfung ist die Einstellung 100–300 ms zwingend.

Decode- und Anzeige-Pipeline: 20–40 ms für hardwarebeschleunigtes H.264-Decoding auf einem modernen Android-Gerät. Nicht einstellbar.

Multi-Stream-Verwaltung und Bediener-UX

Ein einzelner ATAK-Client kann mehrere gleichzeitige Videostreams anzeigen. Das Video-Receiver-Plugin präsentiert registrierte Streams per Alias in einer Liste; der Bediener tippt, um einen Feed in einem schwebenden Panel oder im Vollbild zu öffnen. Für Einheiten, die mehrere UAVs gleichzeitig betreiben, ist die Namenskonvention der Stream-Aliase das primäre UX-Steuerelement: Eine konsistente Konvention (DRONE-[CALLSIGN]-[SENSOR]) lässt Bediener den richtigen Feed sofort ohne Versuch und Irrtum identifizieren.

Stream-Prioritätssignale – eingebettet im remarks-Feld des CoT-Video-Ereignisses oder in einem begleitenden CoT-Ereignis – können von der C2-Software genutzt werden, um den Feed mit der höchsten Priorität automatisch in den Vordergrund zu bringen. TAKpilot kann beispielsweise einen Bedienerbefehl in natürlicher Sprache empfangen („Zeig mir die Kamera der Alpha-Drohne“) und den entsprechenden Stream per Alias-Name in den Vordergrund bringen, ohne dass der Bediener die Stream-Liste manuell durchnavigieren muss.

Für Einheiten, die WinTAK an der Gefechtsstation verwenden, befüllen dieselben über den TAK Server verteilten CoT-Video-Ereignisse die Videoliste von WinTAK identisch. Die größere Bildschirmfläche von WinTAK unterstützt nebeneinander angeordnete Videopanels und macht es zur bevorzugten Plattform für Drohnenbediener und C2-Knoten, die mehrere Feeds gleichzeitig überwachen. Das zugrunde liegende Stream-Protokoll und die Relay-Architektur sind identisch, unabhängig davon, ob der Verbraucher ATAK oder WinTAK ist.