Videon suoratoisto TAK:ssa: livekuvan integrointi yhteiseen tilannekuvaan

Lennokkimiehistö näkee ajoneuvokolonnan liikkuvan puurivistön läpi. S2-upseeri kolmen kilometrin päässä tuijottaa karttaa ilman videota. Lennokin operaattori selostaa puheradion yli. Siihen mennessä, kun tieto on merkitty yhteiseen tilannekuvaan, kolonna on jo liikkunut. Livevideon integrointi TAK:iin poistaa tämän aukon – se tuo syötteen suoraan tilannekuvaan, geo-viitattuna, jaettuna ja saatavilla jokaisella verkon ATAK- ja WinTAK-asiakkaalla ilman manuaalista määritystä. Tämä artikkeli kattaa koko integrointipinon: RTSP-kuljetuksen määrityksen, CoT-videolinkin julkaisun, sensorin jalanjäljen geo-viittauksen, välitysarkkitehtuurin rajoitetuille linkeille, viivebudjetit ja näyttöpuolen määrityksen ATAK Video Receiverissä.

Kuinka TAK käsittelee videota: CoT-videolinkkimalli

TAK ei kuljeta videotavuja TAK Serverin läpi. Arkkitehtuuri on tarkoituksellisesti irrotettu toisistaan: TAK Server jakaa viitteen striimiin – CoT Video -linkkitapahtuman – kun taas varsinainen video virtaa pisteestä pisteeseen (tai välittimen kautta) lähteen ja kunkin katsojan välillä. Tämä erottelu pitää TAK Serverin kaistanleveysvaatimukset hallittavina ja sallii videoinfrastruktuurin mitoittamisen riippumatta taktisesta tietoverkosta.

CoT Video -tapahtuma on vakiomuotoinen CoT XML -viesti tyypillä b-i-v. Sen detail-lohko sisältää Video-elementin striimin URL-osoitteella, ihmisluettavalla aliaksella, protokollatyypillä (rtsp, rtsps tai udp), koodekkivihjeellä ja yksilöllisellä striimitunnisteella. Kun TAK Server vastaanottaa tämän tapahtuman, se tallentaa sen pysyvästi ja välittää sen kaikille asiaankuuluvan ryhmän yhdistetyille asiakkaille. Video-tapahtuman vastaanottava ATAK-asiakas lisää striimin automaattisesti Video Receiver -liitännäisen striimilistaan – operaattori voi sitten avata syötteen aliaksella tietämättä taustalla olevaa URL-osoitetta tai määrittämättä mitään manuaalisesti.

Sama CoT-malli käsittelee striimin peruuttamisen: Video-tapahtuman julkaiseminen samalla UID:llä ja vanhentuneella aikaleimalla menneisyydessä poistaa striimin asiakaslistoilta. Tämä tekee striimin elinkaaren hallinnasta ohjelmallista ja yhdenmukaista muun TAK-tietomallin kanssa.

Kuljetuskerros: RTSP, RTP ja koodekin valinta

RTSP (Real Time Streaming Protocol) on hallitseva kuljetus TAK-videosyötteille. RTSP toimii ohjauskanavana – se neuvottelee istunnon parametrit ja muodostaa striimin – kun taas varsinainen media virtaa RTP:n (Real-time Transport Protocol) yli erillisessä portissa. Kaksi yleistä RTSP-kuljetustilaa TAK:lle ovat:

RTSP TCP:n yli (lomitettu). RTP-mediapaketit multipleksoidaan RTSP TCP -yhteyteen. Tämä tila läpäisee NAT- ja palomuurisäännöt luotettavammin kuin UDP, koska se käyttää yhtä muodostettua TCP-yhteyttä. Se on suositeltu tila syötteille, jotka kulkevat satelliitin, LTE:n tai minkä tahansa rajoittavan pakettisuodatuksen linkin yli. Vaihtokauppa on, että TCP:n uudelleenlähetyskäyttäytyminen voi lisätä vaihtelevaa viivettä pakettihäviöpurskeiden aikana – yhteyden laatuongelma heikentyneillä linkeillä.

RTSP UDP-mediakuljetuksella. RTP-media virtaa erillisten UDP-porttien yli, jotka neuvotellaan RTSP SETUP -vaihdon aikana. UDP-kuljetus saavuttaa matalamman perusviiveen kuin TCP, koska uudelleenlähetystä ei ole – hävinneet paketit tuottavat videoartefakteja sen sijaan, että ne pysäyttäisivät dekooderin. Paikallisessa MANET-segmentissä, jossa on matala pakettihäviö (<1 %), UDP-kuljetus on suositeltava. Korkeamman häviötason linkeillä TCP:n dekooderin pysäytyskäyttäytyminen on usein parempi kuin UDP:n dekoodausvirheet.

Koodekin valinnassa H.264 (AVC) Baseline- tai Main-profiililla on universaali perustaso. Jokainen ATAK-kykyinen Android-laite ja jokainen WinTAK-asennus voi laitteistodekoodata H.264:n. H.265 (HEVC) vähentää kaistanleveyttä noin 40 % vastaavalla laadulla – merkittävä säästö radiolinkeillä – mutta vaatii nimenomaisen dekooderituen vastaanottavalla laitteella. Vanhempi Android-vahvistettu laitteisto saattaa puuttua H.265-laitteistodekoodaustuesta, jolloin se palaa ohjelmistodekoodaukseen korkeammalla suoritin- ja viiverasituksella. Turvallinen valinta heterogeeniselle laivastolle on H.264; H.265 on sopiva, kun laitejoukko on homogeeninen ja hyvin karakterisoitu.

Bittinopeus ja avainkehysväli

Bittinopeuden valinta määrää kaistanleveyskuorman taktisella linkillä. Käytännön ohjeistus linkkityypin mukaan: 1,5–2,5 Mbps omistetulle LTE-runkoyhteydelle hyvällä signaalilla; 800–1200 kbps hallitulle Wi-Fi-meshille; 400–800 kbps MANET-radiolle, jonka 1–2 Mbps:n kokonaisbudjetti jaetaan CoT-liikenteen kanssa; 200–400 kbps satelliitti- tai BLOS-linkille. Alle 300 kbps:n H.264 1080p -videosta tulee visuaalisesti hyväksymätön – pienennä resoluutio 720p:hen tai 480p:hen sen sijaan, että pakkaisit 1080p:tä lisää.

Avainkehysväli (I-frame-väli) määrää, kuinka nopeasti uusi katsoja voi alkaa näyttää striimiä. 1 sekunnin avainkehysväli tarkoittaa, että uusi yhteys alkaa näyttää kuvaa enintään 1 sekunnin kuluessa viimeisestä avainkehyksestä. 4 sekunnin väli säästää kaistanleveyttä mutta tarkoittaa, että uudet katsojat odottavat jopa 4 sekuntia ensimmäistä dekoodattavaa kehystä. Taktiseen käyttöön 1–2 sekuntia on suositeltu väli. Huomaa, että lyhyemmät välit lisäävät bittinopeutta – 1 sekunnin I-frame-väli 800 kbps:llä tuottaa suurempia I-kehyksiä noin joka 800 kbitin välein, mikä voi aiheuttaa lyhyitä bittinopeuspiikkejä linkillä.

Välitysarkkitehtuuri rajoitetuille ja monihyppyisille verkoille

Suora RTSP-malli – ATAK-asiakkaat yhdistyvät lähdelaitteen RTSP-palvelimeen – toimii tasaisissa paikallisverkoissa mutta epäonnistuu useimmissa operatiivisissa käyttöönotoissa. UAV-maaohjausasemat ovat eri IP-aliverkossa kuin ATAK-asiakkaat. Satelliitti- tai BLOS-linkit vaativat välitystä etäsyötteiden tuomiseksi taktiseen verkkoon. Useat samanaikaiset katsojat rasittavat lähdelaitteen lähetyskaistanleveyttä. Välityspalvelin ratkaisee kaikki kolme ongelmaa.

Välitin hakee striimin lähteestä kerran – yksi yhteys, yksi tavuvirta – ja jakaa sen edelleen mille tahansa määrälle alavirran kuluttajia. CoT Video -tapahtuman URL asetetaan välittimen osoitteeseen, ei lähteeseen. Jokainen ATAK-asiakas yhdistyy välittimeen ja vastaanottaa saman striimin lisäämättä kuormaa lähde-GCS:lle tai UAV-linkille.

Välityspalvelinsolmu tarvitsee: suoran verkkopolun lähteeseen (GCS-verkkosegmentti tai satelliittirunkoyhteyden päätepiste) ja polun TAK-verkkoon. Standardissa eteenpäin työnnetyn komentopaikan käyttöönotossa välitin ajetaan samalla fyysisellä solmulla kuin TAK Server, tai erillisellä laskentasolmulla komentopaikalla. Reunakäyttöönotoissa, joissa välittimen on toimittava lähellä lähdettä (lähellä GCS:ää), välitin voi välittää striimejä OpenVPN- tai WireGuard-tunnelin yli taktiseen verkkoon, toisen välitininstanssin jakaessa paikallisesti TAK Serverin puolella.

Videon julkaiseminen TAK-verkkoon CoT:n kautta

CoT Video -tapahtuman mekaniikka on suoraviivaista, mutta detail-kentillä on merkitystä. Minimaalinen yhteensopiva Video-tapahtuma näyttää tältä detail-lohkossa:

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

Lisävalinnaiset kentät kantavat koodekkivihjeitä (codec="H264"), verkon aikakatkaisua millisekunneissa (networkTimeout="10000") ja puskuriaikavihjettä (bufferTime="0" – tämän asettaminen nollaan ilmoittaa soittimelle, että matalan viiveen tila on haluttu, vaimentaen oletuksena kuluttajatason puskurin). uid-kenttä on pysyvä tunniste – saman UID:n uudelleenkäyttö myöhemmässä tapahtumassa päivittää striimiviitteen sen sijaan, että loisi duplikaatin.

ATAK-liitännäisen kehittäjille, jotka julkaisevat videota liitännäisestä: käytä CotService-APIa Video-CoT-tapahtuman injektoimiseksi ATAK:n sisäiseen väylään. Tapahtuma etenee sitten TAK Serverille aktiivisen datalinkin yli ja sieltä kaikille ryhmän jäsenille. Erillistä videonhallinta-APIa ei ole – CoT-tapahtumaväylä on ainoa jakelumekanismi.

Geo-viittaus: sensorin jalanjälkipeittokuva

Video Receiver -paneelissa näytetty videosyöte näyttää operaattorille, mitä kamera näkee. Karttapeittokuva näyttää jokaiselle muulle operaattorille, mihin kamera osoittaa. Nämä kaksi yhdessä – synkronoitu video ja jalanjälki – antavat tilannekuvalle aidon tilakontekstin, jota suullinen kuvaus ei voi tarjota.

UAV-syötteille jalanjäljen laskenta vaatii viisi syötettä: dronen WGS84-sijainnin (leveysaste, pituusaste, korkeus maanpinnan yläpuolella), kardaanin panoroinnin kulman (vaakasuuntainen osoitussuunta suhteessa dronen suuntaan), kardaanin kallistuskulman (laskukulma vaakatason alapuolella) sekä kameran vaaka- ja pystysuuntaisen näkökentän. Näistä rakennetaan neljä nurkkasädevektoria ja leikataan ne maastopinnan kanssa (DTED-korkeusmalli tai tasomaa-approksimaatio matalan korkeuden operaatioille). Neljä leikkauspistettä muodostavat jalanjälkimonikulmion kärjet.

Jalanjälki julkaistaan CoT GeoObjectina – täytetty monikulmio-CoT-tapahtuma – käyttäen yhdenmukaista UID:tä, joka on sidottu droneen tai sensoriin. Se päivittyy telemetrian taajuudella. Karttapeittokuvatarkoituksiin 1–2 Hz:n päivitykset ovat visuaalisesti sileitä ja aiheuttavat vähäpätöistä CoT-liikennekuormaa. Korkeammilla kardaanin kääntönopeuksilla (nopea panorointi aktiivisen seurannan aikana) 5 Hz tarjoaa paremman jalanjäljen liikkeen seurannan kartalla. Päivitysnopeuden tulisi olla riippumattomasti määritettävissä dronen sijaintiseurantaan käytetystä telemetrian taajuudesta.

Kiinteät kamerat – mastoon asennetut, ajoneuvoon asennetut perimetrisensorit – tuottavat staattisen tai hitaasti muuttuvan jalanjäljen. Kiinteäazimuuttiselle kameralle jalanjälki on puolisuunnikas, joka on suunnattu kameran suuntaan, päivitettynä vain kun zoomaustaso muuttuu tai kamera siirretään uudelleen. Jalanjäljen julkaiseminen kiinteille sensoreille noudattaa samaa CoT GeoObject -mekanismia; julkaisija on sensorinhallintaohjelmisto eikä UAV-telemetriasilta.

Viivebudjetti: näyttöviive ja sen lähteet

Kokonaisnäyttöviive – hetkestä, jolloin kamera kaappaa kohtauksen, hetkeen, jolloin se ilmestyy operaattorin näytölle – on viiden peräkkäisen viiveen summa:

Enkoodausviive: 30–80 ms kykenevällä laitteistoenkooderilla, joka ajaa H.264:ää. Ohjelmistoenkooderit pienellä UAV-laskentalaitteistolla voivat lisätä 100–200 ms. Tämä ei ole maa-aseman operaattorin säädettävissä.

Verkon kulkuviive: 10–50 ms näköyhteyden MANET:lle tai LTE:lle; 30–150 ms monihyppyiselle meshille; 500–600 ms yksisuuntaisesti geostationaariselle satelliittivälitykselle. Satelliittivälitys on yksittäinen suurin kiinteä viivetekijä ja asettaa kovan rajoituksen saavutettavissa olevalle päästä päähän -viiveelle satelliittirunkoyhteyden syötteille.

Välittimen käsittelyviive: alle 5 ms hyvin toteutetulle RTSP-välittimelle. Vähäpätöinen, jos välitin on paikallisella solmulla.

Vastaanottopuolen värinäpuskuri: suurin hallittava viiveen lähde. 2 sekunnin värinäpuskuri – oletus monissa kuluttajavideosoittimissa – lisää 2 sekunnin kiinteän viiveen jokaiseen kehykseen. Taktiseen käyttöön värinäpuskuri tulisi vähentää arvoon 100–300 ms. Vaihtokauppa on lisääntyneet visuaaliset artefaktit pakettihäviöpurskeiden aikana. Tämä on operatiivinen päätös: hyväksy satunnaiset kehyshäiriöt vastineeksi lähes reaaliaikaisesta kuvasta, tai hyväksy 2 sekunnin viive sileästä toistosta. Aikakriittiseen kohdentamiseen 100–300 ms:n asetus on pakollinen.

Dekoodaus- ja näyttöputki: 20–40 ms laitteistokiihdytetylle H.264-dekoodaukselle nykyaikaisessa Android-laitteessa. Ei säädettävissä.

Monistriiminhallinta ja operaattorin käyttökokemus

Yksi ATAK-asiakas voi näyttää useita samanaikaisia videostriimejä. Video Receiver -liitännäinen esittää rekisteröidyt striimit aliaksella listassa; operaattori napauttaa avatakseen syötteen kelluvassa paneelissa tai koko näytöllä. Yksiköille, jotka operoivat useita UAV:ita samanaikaisesti, striimin aliaksen nimeämiskäytäntö on ensisijainen käyttökokemuksen ohjain: yhdenmukainen käytäntö (DRONE-[KUTSU]-[SENSORI]) antaa operaattoreiden tunnistaa oikean syötteen välittömästi ilman yritystä ja erehdystä.

Striimin prioriteettisignaalit – upotettuina CoT Video -tapahtuman remarks-kenttään tai oheen liitettyyn CoT-tapahtumaan – voidaan käyttää C2-ohjelmistolla korkeimman prioriteetin syötteen tuomiseksi esiin automaattisesti. TAKpilot voi esimerkiksi vastaanottaa luonnollisen kielen operaattorikomennon ("näytä minulle Alfa-dronen kamera") ja tuoda vastaavan striimin etualalle aliaksen nimellä ilman, että operaattori navigoi striimilistaa manuaalisesti.

Yksiköille, jotka käyttävät WinTAK:ia komentopaikalla, samat TAK Serverin kautta jaetut CoT Video -tapahtumat täyttävät WinTAK:n videolistan identtisesti. WinTAK:n suurempi näyttötila tukee vierekkäisiä videopaneeleita, mikä tekee siitä ensisijaisen alustan lennokin operaattoreille ja C2-solmuille, jotka valvovat useita syötteitä samanaikaisesti. Taustalla oleva striimiprotokolla ja välitysarkkitehtuuri on identtinen riippumatta siitä, onko kuluttaja ATAK vai WinTAK.