Streaming vidéo dans TAK : intégrer les flux en direct au COP

Un équipage de drone voit une colonne de véhicules se déplacer le long d'une ligne d'arbres. L'officier S2, à trois kilomètres de là, fixe une carte sans vidéo. L'opérateur du drone décrit la scène par radio vocale. Le temps que cette information devienne une entrée dans l'image opérationnelle commune, la colonne a déjà bougé. L'intégration de la vidéo en direct dans TAK élimine cet écart – elle place le flux directement sur le COP, géoréférencé, distribué et accessible sur chaque client ATAK et WinTAK du réseau sans configuration manuelle. Cet article couvre l'ensemble de la pile d'intégration : configuration du transport RTSP, publication du lien vidéo CoT, géoréférencement de l'empreinte du capteur, architecture de relais pour les liaisons contraintes, budgets de latence et configuration côté affichage dans l'ATAK Video Receiver.

Comment TAK gère la vidéo : le modèle de lien vidéo CoT

TAK ne transporte pas les octets vidéo à travers le TAK Server. L'architecture est volontairement découplée : le TAK Server distribue une référence vers un flux – un événement de lien CoT Video – tandis que la vidéo réelle circule de point à point (ou via un relais) entre la source et chaque spectateur. Cette séparation maintient les besoins en bande passante du TAK Server gérables et permet de dimensionner l'infrastructure vidéo indépendamment du réseau de données tactique.

Un événement CoT Video est un message XML CoT standard de type b-i-v. Son bloc detail contient un élément Video avec l'URL du flux, un alias lisible par l'humain, le type de protocole (rtsp, rtsps ou udp), une indication de codec et un identifiant unique de flux. Lorsque le TAK Server reçoit cet événement, il le persiste et le relaie à tous les clients connectés du groupe concerné. Un client ATAK recevant l'événement Video ajoute automatiquement le flux à la liste des flux du plugin Video Receiver – l'opérateur peut alors ouvrir le flux par alias sans connaître l'URL sous-jacente ni rien configurer manuellement.

Le même modèle CoT gère la révocation de flux : publier un événement Video avec le même UID et un horodatage périmé dans le passé supprime le flux des listes des clients. Cela rend la gestion du cycle de vie du flux programmatique et cohérente avec le reste du modèle de données TAK.

Couche de transport : RTSP, RTP et sélection du codec

RTSP (Real Time Streaming Protocol) est le transport dominant pour les flux vidéo TAK. RTSP fonctionne comme un canal de contrôle – il négocie les paramètres de session et établit le flux – tandis que les médias réels circulent via RTP (Real-time Transport Protocol) sur un port distinct. Les deux modes de transport RTSP courants pour TAK sont :

RTSP sur TCP (interleaved). Les paquets de médias RTP sont multiplexés dans la connexion TCP RTSP. Ce mode traverse les règles de NAT et de pare-feu plus fiablement que l'UDP car il utilise une seule connexion TCP établie. C'est le mode recommandé pour les flux transitant par satellite, LTE ou toute liaison à filtrage de paquets restrictif. Le compromis est que le comportement de retransmission de TCP peut ajouter une latence variable lors de rafales de pertes de paquets – un problème de qualité de connexion sur les liaisons dégradées.

RTSP avec transport de médias UDP. Les médias RTP circulent sur des ports UDP distincts négociés lors de l'échange RTSP SETUP. Le transport UDP atteint une latence de base inférieure à TCP car il n'y a pas de retransmission – les paquets perdus produisent des artefacts vidéo plutôt que de bloquer le décodeur. Sur un segment MANET local à faible perte de paquets (<1 %), le transport UDP est préféré. Sur les liaisons à taux de perte plus élevés, le comportement de blocage du décodeur de TCP est souvent préférable aux erreurs de décodage de l'UDP.

Pour la sélection du codec, H.264 (AVC) en profil Baseline ou Main est la base universelle. Chaque appareil Android compatible ATAK et chaque installation WinTAK peut décoder le H.264 matériellement. H.265 (HEVC) réduit la bande passante d'environ 40 % à qualité équivalente – une économie significative sur les liaisons radio – mais nécessite une prise en charge explicite du décodeur sur l'appareil récepteur. Le matériel Android durci plus ancien peut ne pas disposer du décodage matériel H.265, se rabattant sur le décodage logiciel avec un surcoût de CPU et de latence plus élevé. Le choix sûr pour une flotte hétérogène est le H.264 ; le H.265 est approprié lorsque l'ensemble des appareils est homogène et bien caractérisé.

Débit binaire et intervalle d'images-clés

Le choix du débit binaire détermine la charge de bande passante sur la liaison tactique. Recommandations pratiques par type de liaison : 1,5 à 2,5 Mbps pour un backhaul LTE dédié avec un bon signal ; 800 à 1200 kbps pour un maillage Wi-Fi géré ; 400 à 800 kbps pour une radio MANET avec un budget agrégé de 1 à 2 Mbps partagé avec le trafic CoT ; 200 à 400 kbps pour une liaison satellite ou BLOS. En dessous de 300 kbps, la vidéo H.264 1080p devient visuellement inacceptable – réduisez à une résolution 720p ou 480p plutôt que de compresser davantage le 1080p.

L'intervalle d'images-clés (intervalle d'images I) détermine à quelle vitesse un nouveau spectateur peut commencer à afficher le flux. Un intervalle d'images-clés d'une seconde signifie qu'une nouvelle connexion commence à afficher au plus tard une seconde après la dernière image-clé. Un intervalle de 4 secondes économise de la bande passante mais signifie que les nouveaux spectateurs attendent jusqu'à 4 secondes la première image décodable. Pour l'usage tactique, l'intervalle recommandé est de 1 à 2 secondes. Notez que des intervalles plus courts augmentent le débit binaire – un intervalle d'images I d'une seconde à 800 kbps produit des images I plus grandes environ tous les 800 kbits, ce qui peut provoquer de brèves pointes de débit sur la liaison.

Architecture de relais pour les réseaux contraints et multi-sauts

Le modèle RTSP direct – les clients ATAK se connectent au serveur RTSP de l'appareil source – fonctionne sur les réseaux locaux plats mais échoue dans la plupart des déploiements opérationnels. Les stations de contrôle au sol des UAV se trouvent sur un sous-réseau IP différent de celui des clients ATAK. Les liaisons satellite ou BLOS nécessitent un relais pour amener les flux distants dans le réseau tactique. Plusieurs spectateurs simultanés sollicitent la bande passante de téléversement de l'appareil source. Un serveur relais résout ces trois problèmes.

Le relais tire le flux de la source une seule fois – une connexion, un flux d'octets – et le redistribue à n'importe quel nombre de consommateurs en aval. L'URL de l'événement CoT Video est réglée sur l'adresse du relais, et non de la source. Chaque client ATAK se connecte au relais et reçoit le même flux sans augmenter la charge sur la GCS source ou la liaison UAV.

Un nœud de serveur relais nécessite : un chemin réseau direct vers la source (segment réseau de la GCS ou point terminal du backhaul satellite) et un chemin vers le réseau TAK. Dans un déploiement standard de poste de commandement avancé, le relais s'exécute sur le même nœud physique que le TAK Server, ou sur un nœud de calcul dédié au poste de commandement. Pour les déploiements en périphérie où le relais doit s'exécuter près de la source (près de la GCS), le relais peut transférer les flux via un tunnel OpenVPN ou WireGuard dans le réseau tactique, avec une seconde instance de relais côté TAK Server redistribuant localement.

Publication de la vidéo sur le réseau TAK via CoT

La mécanique de l'événement CoT Video est simple, mais les champs detail ont leur importance. Un événement Video minimal conforme ressemble à ceci dans le bloc detail :

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

Des champs optionnels supplémentaires portent les indications de codec (codec="H264"), le délai d'expiration réseau en millisecondes (networkTimeout="10000") et une indication de temps de tampon (bufferTime="0" – le régler à zéro signale au lecteur qu'un mode à faible latence est souhaité, supprimant le tampon grand public par défaut). Le champ uid est l'identifiant persistant – réutiliser le même UID dans un événement ultérieur met à jour la référence du flux plutôt que de créer un doublon.

Pour les développeurs de plugins ATAK publiant de la vidéo depuis un plugin : utilisez l'API CotService pour injecter l'événement Video CoT dans le bus interne d'ATAK. L'événement se propage ensuite vers le TAK Server via la liaison de données active et de là vers tous les membres du groupe. Il n'y a pas d'API de gestion vidéo distincte – le bus d'événements CoT est le seul mécanisme de distribution.

Géoréférencement : la superposition d'empreinte du capteur

Un flux vidéo affiché dans le panneau Video Receiver montre à l'opérateur ce que voit la caméra. La superposition cartographique montre à tous les autres opérateurs où la caméra est pointée. Les deux ensemble – vidéo synchronisée et empreinte – donnent au COP un véritable contexte spatial que la description vocale ne peut fournir.

Pour les flux UAV, le calcul de l'empreinte nécessite cinq entrées : la position WGS84 du drone (latitude, longitude, altitude au-dessus du sol), l'angle de panoramique de la nacelle (direction de pointage horizontale relative au cap du drone), l'angle d'inclinaison de la nacelle (angle de dépression sous l'horizontale) et les champs de vision horizontal et vertical de la caméra. À partir de ceux-ci, quatre vecteurs de rayon d'angle sont construits et intersectés avec une surface de terrain (un modèle d'élévation DTED ou une approximation de terre plate pour les opérations à basse altitude). Les quatre points d'intersection forment les sommets du polygone d'empreinte.

L'empreinte est publiée comme un CoT GeoObject – un événement CoT de polygone rempli – à l'aide d'un UID cohérent lié au drone ou au capteur. Elle se met à jour au débit de télémétrie. Pour la superposition cartographique, des mises à jour de 1 à 2 Hz sont visuellement fluides et imposent une charge de trafic CoT négligeable. À des vitesses de rotation de nacelle plus élevées (panoramique rapide lors d'un suivi actif), 5 Hz offre un meilleur suivi du déplacement de l'empreinte sur la carte. Le débit de mise à jour devrait être configurable indépendamment du débit de télémétrie utilisé pour la trace de position du drone.

Les caméras fixes – capteurs de périmètre sur mât, sur véhicule – produisent une empreinte statique ou à variation lente. Pour une caméra à azimut fixe, l'empreinte est un trapèze orienté dans la direction du cap de la caméra, mis à jour uniquement lorsque le niveau de zoom change ou que la caméra est repositionnée. La publication de l'empreinte pour les capteurs fixes suit le même mécanisme CoT GeoObject ; l'éditeur est le logiciel de gestion du capteur plutôt qu'un pont de télémétrie UAV.

Budget de latence : la latence d'affichage et ses sources

La latence d'affichage totale – du moment où une scène est capturée par la caméra au moment où elle apparaît sur l'écran de l'opérateur – est la somme de cinq délais séquentiels :

Latence d'encodage : 30 à 80 ms sur un encodeur matériel performant exécutant H.264. Les encodeurs logiciels sur du petit matériel de calcul UAV peuvent ajouter 100 à 200 ms. Ce n'est pas réglable par l'opérateur de la station au sol.

Latence de transit réseau : 10 à 50 ms pour le MANET ou la LTE en visibilité directe ; 30 à 150 ms pour le maillage multi-sauts ; 500 à 600 ms aller simple pour le relais satellite géostationnaire. Le relais satellite est le plus grand contributeur unique de latence fixe et impose une contrainte ferme sur la latence de bout en bout atteignable pour les flux à backhaul satellite.

Latence de traitement du relais : moins de 5 ms pour un relais RTSP bien implémenté. Négligeable si le relais est sur un nœud local.

Tampon de gigue côté réception : la plus grande source de latence contrôlable. Un tampon de gigue de 2 secondes – la valeur par défaut dans de nombreux lecteurs vidéo grand public – ajoute 2 secondes de latence fixe à chaque image. Pour l'usage tactique, le tampon de gigue devrait être réduit à 100 à 300 ms. Le compromis est une augmentation des artefacts visuels lors de rafales de pertes de paquets. C'est une décision opérationnelle : accepter des accrocs d'image occasionnels en échange d'une imagerie quasi temps réel, ou accepter 2 secondes de latence pour une lecture fluide. Pour le ciblage sensible au temps, le réglage de 100 à 300 ms est obligatoire.

Pipeline de décodage et d'affichage : 20 à 40 ms pour le décodage H.264 accéléré matériellement sur un appareil Android moderne. Non réglable.

Gestion multi-flux et UX de l'opérateur

Un seul client ATAK peut afficher plusieurs flux vidéo simultanés. Le plugin Video Receiver présente les flux enregistrés par alias dans une liste ; l'opérateur tape pour ouvrir un flux dans un panneau flottant ou en plein écran. Pour les unités exploitant plusieurs UAV simultanément, la convention de nommage des alias de flux est le principal levier d'UX : une convention cohérente (DRONE-[CALLSIGN]-[SENSOR]) permet aux opérateurs d'identifier instantanément le bon flux sans tâtonnement.

Les signaux de priorité de flux – intégrés dans le champ remarks de l'événement CoT Video ou dans un événement CoT compagnon – peuvent être utilisés par le logiciel C2 pour faire remonter automatiquement le flux de plus haute priorité. TAKpilot, par exemple, peut recevoir une commande d'opérateur en langage naturel (« montre-moi la caméra du drone Alpha ») et amener le flux correspondant au premier plan par son nom d'alias sans que l'opérateur navigue manuellement dans la liste des flux.

Pour les unités utilisant WinTAK au poste de commandement, les mêmes événements CoT Video distribués via le TAK Server peuplent la liste vidéo de WinTAK à l'identique. La plus grande surface d'écran de WinTAK prend en charge des panneaux vidéo côte à côte, ce qui en fait la plateforme préférée des opérateurs de drones et des nœuds C2 surveillant plusieurs flux simultanément. Le protocole de flux sous-jacent et l'architecture de relais sont identiques que le consommateur soit ATAK ou WinTAK.