SRTKit

Quand vous diffusez un flux vidéo en direct sur un réseau instable — une contribution terrain, un lien satellite, une connexion 4G depuis un stade — le protocole de transport fait toute la différence. TCP est fiable mais ajoute de la latence, UDP est rapide mais perd des paquets sans prévenir. SRT (Secure Reliable Transport) combine le meilleur des deux : transport UDP avec fiabilité, basse latence, chiffrement AES, et correction d'erreur.

Créé par Haivision et devenu un standard ouvert via la SRT Alliance, SRT est aujourd'hui utilisé par les diffuseurs du monde entier — de la contribution live aux workflows broadcast, en passant par le cloud media. Le protocole gère le handshake en trois modes (Caller, Listener, Rendezvous), le chiffrement AES-CTR et AES-GCM de bout en bout, la correction d'erreur par XOR (FEC), le bonding de connexions pour le failover, et le contrôle de congestion adaptatif.

En travaillant sur l'écosystème streaming d'Atelier Socle — HLSKit pour le HTTP Live Streaming, IcecastKit pour Icecast/SHOUTcast, RTMPKit pour RTMP — la dernière brique manquante était SRT. Et pas un wrapper autour de libsrt en C — une implémentation Swift pure, depuis le transport UDP jusqu'au chiffrement AES, avec la concurrence structurée de Swift 6.2, zéro dépendance C, et une interopérabilité validée avec libsrt 1.5.4.

J'ai cherché. Rien n'existait en Swift pur. SRTKit est née de ce besoin.

La 0.2.0 ajoute le support IPv6 natif et corrige le format fil du StreamID — les octets doivent être inversés par blocs de 4 octets (chaque bloc est traité comme un UInt32 avec le premier octet de la chaîne en position LSB). Sans cette inversion, aucun serveur basé sur libsrt (OBS, FFmpeg, MediaMTX, srt-live-transmit) ne pouvait lire le StreamID correctement.

La 0.3.0 corrige trois problèmes fondamentaux de conformité au protocole. Le compteur de messageNumber des paquets de données — qui était fixé à 0 — est maintenant incrémenté sur 26 bits (2²⁶ − 1, valeur 0 réservée au FEC), résolvant le problème "opened but never publishing" avec MediaMTX. Le traitement des ACK est implémenté : le CIF est parsé pour extraire le dernier numéro de séquence acquitté, le RTT et la capacité du lien, les paquets acquittés sont libérés du buffer d'envoi, et un ACKACK est renvoyé en réponse. Enfin, l'Initial Sequence Number (ISN) est généré aléatoirement et indépendamment par direction (local pour l'envoi, peer pour la réception), conformément au draft IETF §4.3.

SRTKit est une implémentation Swift pure du protocole SRT. Elle couvre l'ensemble du protocole : connexion en trois modes, chiffrement AES, correction d'erreur FEC, bonding de connexion, contrôle de congestion, statistiques temps réel, enregistrement de flux, contrôle d'accès, et reconnexion automatique. Le tout avec conformité Sendable stricte de bout en bout. Ce n'est PAS un wrapper libsrt — c'est une implémentation complète depuis zéro.

Se connecter à un listener SRT, envoyer des données, vérifier les statistiques, et se déconnecter :

Via Swift Package Manager, en ajoutant la dépendance dans votre Package.swift :

Puis dans le target concerné :

Connexion chiffrée AES-256 en mode CTR avec passphrase :

Démarrer un listener SRT et accepter les connexions entrantes :

Le builder permet de construire une configuration complète avec mode, latence et chiffrement de manière fluide :

Six presets intégrés couvrent les cas d'usage courants. Chacun configure automatiquement la latence, le contrôle de congestion et les options socket :

Configuration en une ligne pour les serveurs et logiciels de streaming courants. Chaque preset configure automatiquement la latence, le chiffrement, la taille des buffers, et le format StreamID pour une compatibilité optimale avec le produit cible :

Chiffrement et déchiffrement au niveau paquet avec AES-CTR. La clé de session (SEK) et le sel sont utilisés pour chiffrer chaque payload indépendamment, en utilisant le numéro de séquence comme partie de l'IV :

FEC basé sur XOR en ligne, colonne et matrice pour récupérer les paquets perdus sans retransmission. Layouts staircase et even, avec modes ARQ configurables :

Le bonding de connexion permet d'agréger ou de basculer entre plusieurs liens réseau. Trois modes sont disponibles : broadcast (envoi sur tous les liens), main/backup (failover automatique), et balancing (agrégation pondérée) :

Métriques complètes avec scoring de qualité automatique (0.0–1.0, cinq grades), export Prometheus et StatsD :

Contrôle d'accès basé sur StreamID au format #!:: pour le routage et l'authentification des flux :

SRTKit gère la reconnexion automatique avec backoff exponentiel. Quatre presets sont disponibles, plus les politiques custom avec jitter :

Le caller SRT bind désormais :: en IPv6 et 0.0.0.0 en IPv4, avec extraction correcte des adresses peer via SRTPeerAddress — un enum qui encapsule les deux familles d'adresses, y compris le format IPv4-mapped IPv6 (::ffff:a.b.c.d).

Le format fil du StreamID est corrigé pour correspondre à la spec SRT : chaque bloc de 4 octets est traité comme un UInt32 avec le premier octet de la chaîne en position LSB (least-significant byte). Cette inversion était requise pour l'interopérabilité avec toute implémentation basée sur libsrt — OBS, FFmpeg, MediaMTX, srt-live-transmit.

Trois corrections de conformité au protocole SRT rendent la connexion fiable avec les implémentations tierces.

Le compteur messageNumber des paquets de données est maintenant incrémenté sur 26 bits (champ de la spec SRT), avec wraparound à 0x03FFFFFF et valeur 0 réservée aux paquets de contrôle FEC. Avant, tous les paquets partaient avec messageNumber = 0, ce qui déclenchait la déduplication côté receiver.

Le traitement des ACK est implémenté : le CIF (Control Information Field) est parsé pour extraire le numéro de séquence acquitté, le RTT, la capacité du lien estimée et la taille de buffer disponible. Les paquets acquittés sont libérés du buffer d'envoi, et un ACKACK (type 0x0006) est renvoyé au peer.

L'Initial Sequence Number est généré aléatoirement par direction — un ISN local pour les paquets sortants, un ISN peer pour le buffer de réception — conformément au draft IETF SRT §4.3.

L'interopérabilité est validée avec MediaMTX 1.16.3 — un stream MPEG-TS H.264+AAC de 3 minutes publié depuis SRTKit caller vers MediaMTX listener, 0 erreurs, 0 buffer overflow. Les deux formats de StreamID sont supportés : le format SRT Access Control (#!::r=live/test,m=publish) utilisé par libsrt et Haivision, et le format court (publish:live/test) utilisé par MediaMTX.

La bibliothèque est organisée en modules clairement séparés, chacun avec une responsabilité bien définie :

srt-cli fournit l'envoi, la réception, le sondage, les statistiques, le test en loopback, et le diagnostic en ligne de commande avec affichage de progression et sortie structurée.

SRTKit fait partie de l'écosystème streaming d'Atelier Socle :