srt
v1.5.4
À propos de SRT | Caractéristiques | Commencer | Instructions de construction | Exemples d'applications et d'outils | Contribuer | Licence | Sorties
Secure Reliable Transport (SRT) est un protocole de transport pour le streaming vidéo et audio en direct à latence ultra faible (inférieure à la seconde), ainsi que pour le transfert générique de données en masse 1 . SRT est disponible en tant que technologie open source avec le code sur GitHub, une version Internet publiée et une communauté croissante d'utilisateurs SRT.
SRT est appliqué aux points de terminaison de contribution et de distribution dans le cadre d'un flux de travail de flux vidéo pour fournir à tout moment la meilleure qualité vidéo avec la latence la plus faible.
| Sécurisé | Crypte les flux vidéo |
| Fiable | Récupération après une grave perte de paquets |
| Transport | S'adapte dynamiquement aux conditions changeantes du réseau |
Dans les configurations de diffusion en direct, le protocole SRT maintient une latence constante de bout en bout. Cela permet de recréer les caractéristiques du signal du flux en direct côté récepteur, réduisant ainsi le besoin de mise en mémoire tampon. À mesure que les paquets sont diffusés de la source à la destination, SRT détecte et s'adapte aux conditions du réseau en temps réel entre les deux points de terminaison. Il permet de compenser la gigue et les fluctuations de bande passante dues à la congestion sur les réseaux bruyants.
SRT implémente le cryptage AES pour protéger la charge utile des flux multimédias et propose divers mécanismes de récupération d'erreur pour minimiser la perte de paquets typique des connexions Internet, dont la demande de répétition automatique (ARQ) est la méthode principale. Avec ARQ, lorsqu'un récepteur détecte qu'un paquet est manquant, il envoie une alerte à l'expéditeur demandant la retransmission de ce paquet manquant. La correction des erreurs directes (FEC) et la liaison de connexion, qui ajoutent une protection transparente des flux et un basculement sans incident, sont également prises en charge par le protocole.
Pour en savoir plus sur le protocole, abonnez-vous au blog Innovation Labs sur
Pour poser une question, rejoignez la conversation sur le canal #development sur 
? Cliquez sur le bouton ► pour développer une description de fonctionnalité.
Peu importe le manque de fiabilité de votre réseau, SRT peut récupérer après de graves pertes de paquets et une instabilité, garantissant ainsi l'intégrité et la qualité de vos flux vidéo.
La correction des erreurs de flux de SRT est configurable pour s'adapter aux conditions de déploiement d'un utilisateur. Tirant parti du développement des communications IP en temps réel pour étendre les pratiques traditionnelles de récupération d'erreurs réseau, SRT fournit des médias avec une latence nettement inférieure à celle de TCP/IP, tout en offrant la vitesse de transmission UDP avec une fiabilité considérablement améliorée.
Contrairement à certains autres protocoles de streaming qui ne prennent en charge que des formats vidéo et audio spécifiques, SRT est indépendant de la charge utile. Étant donné que SRT fonctionne au niveau du transport réseau, agissant comme une enveloppe autour de votre contenu, il peut transporter tout type de format vidéo, codec, résolution ou fréquence d'images.
Le processus d'établissement de liaison utilisé par SRT prend en charge les connexions sortantes sans les risques et dangers potentiels liés à l'ouverture de ports extérieurs permanents dans un pare-feu, maintenant ainsi les politiques de sécurité du réseau local de l'entreprise et minimisant le besoin d'intervention informatique.
Grâce au cryptage AES 128/192/256 bits approuvé par les gouvernements et les organisations du monde entier, SRT garantit que le contenu précieux est protégé de bout en bout, de la contribution à la distribution, afin qu'aucune partie non autorisée ne puisse l'écouter.
SRT 1.4 voit l'introduction de l' API de filtrage de paquets . Ce mécanisme permet d'effectuer un traitement personnalisé sur les paquets réseau du côté de l'expéditeur avant qu'ils ne soient envoyés, et du côté du récepteur une fois reçus du réseau. L'API permet aux utilisateurs d'écrire leur propre plugin, étendant ainsi encore plus les capacités du protocole SRT avec toutes sortes de filtrage de paquets différents. Les utilisateurs peuvent manipuler les données de filtrage de paquets résultantes de n'importe quelle manière, par exemple pour un cryptage personnalisé, une inspection des paquets ou l'accès aux données avant leur envoi.
Le premier plugin créé comme exemple de ce qui peut être réalisé avec l'API de filtre de paquets concerne la correction d'erreur directe (FEC) qui, dans certains cas d'utilisation, peut offrir une latence légèrement inférieure à celle de la demande de répétition automatique (ARQ). Ce plugin permet trois modes différents :
ARQ uniquement – retransmet les paquets perdus,
FEC uniquement – fournit la surcharge nécessaire à la récupération FEC côté récepteur,
FEC et ARQ – retransmet les paquets perdus que FEC ne parvient pas à récupérer.
Semblable au SMPTE-2022-7 sur les réseaux gérés, Connection Bonding ajoute une protection transparente des flux et un basculement sans incident au protocole SRT. Cette technologie s'appuie sur plusieurs chemins de réseau IP pour éviter toute interruption des flux vidéo en direct en cas de congestion ou de panne du réseau, garantissant ainsi la continuité du service.
Ceci est accompli en utilisant les groupes de sockets introduits dans SRT v1.5. Le concept général des groupes de sockets signifie avoir un groupe contenant plusieurs sockets, où une opération d'envoi d'un signal de données est appliquée au groupe. Des prises uniques à l'intérieur du groupe prendront en charge cette opération et feront le nécessaire pour transmettre le signal au récepteur.
Deux modes sont pris en charge :
Broadcast - En mode Broadcast , les données sont envoyées de manière redondante sur tous les liens membres d'un groupe. Si l'un des liens tombe en panne ou subit une instabilité du réseau et/ou une perte de paquets, les données manquantes seront reçues via un autre lien du groupe. Les paquets redondants sont simplement rejetés du côté du récepteur.
Principal/Sauvegarde - En mode Principal/Sauvegarde , un seul lien (principal) à la fois est utilisé pour la transmission de données tandis que les autres connexions (de secours) sont en attente pour garantir la poursuite de la transmission en cas de défaillance de la liaison principale. L'objectif du mode principal/sauvegarde est d'identifier une rupture de lien potentielle avant qu'elle ne se produise, fournissant ainsi une fenêtre de temps pendant laquelle basculer de manière transparente vers l'un des liens de sauvegarde.
Le contrôle d'accès permet à l'application en amont d'attribuer un ID de flux à des flux SRT individuels. En utilisant un ID de flux unique, généré automatiquement ou personnalisé, l'application en amont peut envoyer plusieurs flux SRT vers une seule adresse IP et un seul port UDP. Les ID de flux peuvent ensuite être utilisés par un récepteur pour identifier et différencier les flux d'ingestion, appliquer des méthodes d'accès par mot de passe utilisateur et, dans certains cas, même appliquer une automatisation basée sur la dénomination de l'ID de flux. Par exemple, la contribution pourrait être envoyée à un flux de production vidéo et la surveillance à un service de surveillance.
Pour les diffuseurs, Stream ID est essentiel pour remplacer RTMP pour l'ingestion de flux vidéo, en particulier de contenu HEVC/H.265, dans un service cloud ou des CDN dotés d'un seul socket IP (adresse + port) ouvert pour la vidéo entrante.
| L'API SRT | Projet Internet de l'IETF | Exemples d'applications |
| Documentation de référence pour l'API de la bibliothèque SRT | Le projet Internet du protocole SRT | Instructions d'utilisation des applications de test ( srt-live-transmit , srt-file-transmit , etc.) |
| Présentation technique du SRT | Guide de déploiement SRT | Livre de recettes SRT |
| Aperçu technique de la première ébauche (précurseur de l'ébauche Internet) | Un aperçu complet du protocole avec des directives de déploiement | Notes de développement sur le protocole SRT |
| Blog des laboratoires d'innovation | Chaîne YouTube du SRTLab | Mou |
| Le blog sur Medium avec des articles techniques liés au SRT | Chaîne YouTube technique avec des vidéos utiles | Chaînes Slack pour obtenir les dernières mises à jour et poser des questions Rejoignez l'Alliance SRT sur Slack |
Pourquoi SRT ? - Un bref historique et justification de SRT par Marc Cymontkowski.
RTMP vs SRT : Comparaison du livre blanc sur la latence et la bande passante maximale.
Documentation sur GitHub avec les documents de l'API SRT, les descriptions des fonctionnalités, etc.
Le projet Internet du protocole SRT : Datatracker | Dernière version | Dernière copie de travail | Dépôt GitHub
Linux (Ubuntu/CentOS) | Fenêtres | macOS | iOS | Android | Gestionnaires de paquets
Compilateur compatible C++03 ou supérieur.
CMake 2.8.12 ou supérieur en tant que système de build.
OpenSSL 1.1 pour activer le cryptage, sinon construisez avec -DENABLE_ENCRYPTION=OFF .
Le multithreading est fourni par l'un des éléments suivants :
C++11 : bibliothèque standard (option std by -DENABLE_STDCXX_SYNC=ON CMake),
C++03 : Pthreads (pour les systèmes POSIX, il est intégré, pour Windows, il existe une bibliothèque portée).
Tcl 8.5 est facultatif et est utilisé par le script ./configure . Sinon, utilisez CMake directement.
Pour des descriptions détaillées du système de build et des options, veuillez lire le document Options de build SRT.
Le référentiel actuel fournit des exemples d'applications et des exemples de code qui démontrent l'utilisation de l'API de la bibliothèque SRT. Parmi eux figurent srt-live-transmit , srt-file-transmit et d'autres applications. La documentation correspondante peut être trouvée ici. Notez que tous les exemples sont fournis à des fins pédagogiques et ne doivent pas être utilisés dans un environnement de production.
L'utilitaire srt-xtransmit est activement utilisé pour les tests internes et l'évaluation des performances. Entre autres fonctionnalités, il prend en charge la génération de charges utiles factices, le routage du trafic et la liaison de connexions. Des détails supplémentaires sont disponibles dans le dépôt srt-xtransmit lui-même.
Les outils Python qui pourraient être utiles lors du développement sont :
srt-stats-plotting - Un script conçu pour tracer des graphiques basés sur les statistiques SRT .csv .
lib-tcpdump-processing - Une bibliothèque conçue pour traiter les fichiers de trace .pcap(ng) tcpdump ou Wireshark et extraire les paquets SRT d'intérêt pour une analyse plus approfondie.
lib-srt-utils - Une bibliothèque Python contenant du code de prise en charge pour exécuter des tests SRT basés sur une configuration expérimentale.
Tout le monde est invité à contribuer. Si vous décidez de vous impliquer, veuillez prendre un moment pour consulter les lignes directrices :
Guide du développeur SRT
Contribuer
Problèmes de signalement
Pour plus d'informations sur la contribution au brouillon Internet ou pour soumettre des problèmes, veuillez consulter le dépôt suivant. Le dépôt pour contribuer à SRT CookBook peut être trouvé ici.
En contribuant au code du projet SRT, vous acceptez d'octroyer une licence pour votre contribution sous la licence MPLv2.0.
Notes de version
Gestion des versions SRT
Le terme « live streaming » désigne une transmission continue de données (MPEG-TS ou équivalent) avec gestion de la latence. Le streaming en direct basé sur la segmentation et la transmission de fichiers comme dans le protocole HTTP Live Streaming (HLS) (tel que décrit dans la RFC8216) ne fait pas partie de ce cas d'utilisation. La transmission de fichiers en mode message ou en mode tampon doit être envisagée dans ce cas. Voir la section 7. Meilleures pratiques et conseils de configuration pour la transmission de données via SRT du projet Internet pour plus de détails. Notez que SRT est indépendant du contenu, ce qui signifie que tout type de données peut être transmis via sa charge utile. ↩
