Comment envoyer un live vers une destination SRT
Une destination SRT demande quelques informations de plus que le RTMP : un mode, un hôte et un port, et souvent un stream ID, une passphrase et une latence. Voici ce que signifie chaque partie d'une URL srt:// et comment connecter votre live.
Environ 7 min de lecture
Sur cette page
Pour envoyer un live vers une destination SRT, récupérez une adresse srt:// auprès du récepteur, confirmez quel côté écoute et quel côté appelle, et reprenez à l'identique le stream ID, la passphrase et la latence attendus par le récepteur. Ouvrez ensuite le port UDP du récepteur, lancez l'émetteur et vérifiez que la vidéo arrive bien avant de compter dessus.
Les petites incohérences cassent les configurations SRT : reprenez chaque détail à l'identique. Vous découvrez le protocole ? Commencez par ce qu'est le streaming SRT.
À retenir
- D'un côté d'une connexion SRT, on écoute sur un port UDP ; de l'autre, on appelle.
- Une URL srt:// contient l'hôte et le port, plus des options comme mode, streamid et passphrase.
- La plupart des échecs viennent d'un port fermé, de deux callers, ou d'une passphrase ou d'un stream ID qui ne correspondent pas.
- Testez en local avant de pointer un live 24/7 vers un récepteur de production.
Qui utilise vraiment des destinations SRT
En général, on n'envoie pas de SRT vers une grande plateforme sociale. Les destinations SRT sont plutôt des systèmes gérés par un diffuseur, une entreprise ou un partenaire :
- Diffusion broadcast et production. Les studios reçoivent des flux de contribution en SRT dans des décodeurs matériels, des mélangeurs et des systèmes de playout.
- Serveurs média. Les serveurs média auto-hébergés et commerciaux acceptent le SRT et le reconditionnent pour des lecteurs, l'enregistrement ou une distribution ultérieure.
- Transmissions entre partenaires. Une chaîne qui fournit des programmes à un réseau, à des écrans dans une salle ou à un distributeur les livre souvent en SRT.
- Services vidéo cloud. Certaines plateformes professionnelles proposent l'ingestion SRT en plus du RTMP.
Dans chaque cas, l'opérateur du récepteur vous fournit des informations de connexion à reprendre à l'identique. Si l'autre extrémité ne propose que le RTMP, suivez plutôt le guide du serveur RTMP personnalisé.
Les modes caller, listener et rendezvous
Toute connexion SRT a besoin d'un côté qui attend et d'un côté qui compose.
- Listener se lie à un port UDP et attend les connexions. Il lui faut une adresse joignable et un port ouvert dans le pare-feu.
- Caller se connecte à l'hôte et au port d'un listener, et fonctionne derrière la plupart des pare-feu puisque la connexion est sortante.
- Rendezvous fait appeler les deux côtés simultanément sur des ports convenus, ce qui peut aider quand aucun des deux n'accepte le trafic entrant.
Le mode n'a rien à voir avec le sens dans lequel circule la vidéo. Quand un service cloud ou un encodeur livre vers votre serveur, la configuration habituelle est émetteur en caller et récepteur en listener.
L'erreur classique : deux callers ou deux listeners. Les deux côtés attendent sans message d'erreur clair, alors confirmez le mode avec l'opérateur du récepteur.
Lire une URL srt:// élément par élément
Une adresse SRT ressemble généralement à ceci :
srt://ingest.example.com:9000?mode=caller&streamid=channel-main&passphrase=YOUR-LONG-SECRET
- Hôte et port. Le nom d'hôte ou l'adresse IP du récepteur et le port UDP sur lequel il écoute. Il n'existe pas de port par défaut universel : utilisez celui qu'on vous donne.
- mode. Le rôle de votre côté : caller, listener ou rendezvous.
- streamid. Un identifiant que certains récepteurs utilisent pour router ou autoriser un flux, un peu comme une clé de stream. Son format dépend du récepteur.
- passphrase. Le secret partagé pour le chiffrement AES, qui doit généralement compter de 10 à 79 caractères. Les deux extrémités doivent correspondre exactement.
- pbkeylen. Longueur de clé optionnelle de 16, 24 ou 32 octets, soit AES-128, 192 ou 256.
- latency. Le tampon de récupération. Certains outils l'expriment en millisecondes alors que les logiciels basés sur FFmpeg attendent souvent des microsecondes : vérifiez avant de recopier une valeur d'une autre configuration.
Préparer le côté récepteur
Si vous gérez vous-même le récepteur, préparez-le avant tout envoi :
- Configurez un listener sur un port UDP fixe dans votre serveur média, votre décodeur ou votre logiciel de playout.
- Ouvrez ce port UDP dans le pare-feu du serveur et dans tout groupe de sécurité cloud ou routeur placé devant. Les règles TCP ne couvrent pas le SRT.
- Choisissez une passphrase et, si votre logiciel route selon le stream ID, un identifiant pour ce flux.
- Choisissez une latence adaptée au trajet ; les routes longues ou instables en demandent davantage.
- Confirmez le format. Le SRT transporte généralement du MPEG-TS avec de la vidéo H.264 et de l'audio AAC : assurez-vous que le récepteur l'accepte.
- Testez en local en envoyant un court flux depuis OBS ou FFmpeg sur une autre machine.
Si le récepteur n'accepte que des adresses approuvées, autorisez aussi celle de l'émetteur.
Dépanner une connexion SRT qui refuse de démarrer
Les erreurs SRT sont souvent vagues : diagnostiquez à partir du symptôme.
- La connexion expire. Le port UDP est fermé ou non redirigé, l'hôte est erroné, ou les deux côtés utilisent le même mode.
- La connexion est refusée. Généralement une passphrase qui ne correspond pas, une passphrase définie d'un seul côté, ou un stream ID que le récepteur ne reconnaît pas.
- La connexion s'établit, puis saccade ou coupe. La latence est trop faible pour le trajet réseau, ou la bande passante est inférieure au débit augmenté du surcoût des retransmissions. Augmentez d'abord la latence.
- La connexion s'établit sans image ni son. Le récepteur attend un autre conteneur ou un autre codec, et ses logs indiquent généralement lequel.
Une fois que tout fonctionne, notez chaque valeur qui a permis la connexion. Les bonnes pratiques plus générales pour garder un live 24/7 en ligne s'appliquent aussi aux destinations SRT.
Ajouter une destination SRT à un live StreamHouse
Dans StreamHouse, le SRT est une destination personnalisée à côté des plateformes intégrées. Collez l'URL srt:// complète du récepteur, avec les options qu'il exige, comme une passphrase. Si l'on vous a donné un stream ID ou une clé séparément, saisissez-le dans le champ stream ID : StreamHouse l'ajoute comme paramètre streamid lorsque l'URL n'en contient pas déjà un. Sans mode dans l'URL, StreamHouse se connecte en caller, votre récepteur doit donc être en écoute.
Envoyez une playlist en boucle de vidéos pré-encodées vers votre récepteur 24h/24, ou ajoutez le SRT à côté de YouTube, Twitch et d'autres destinations RTMP sur le même live, sans consommer d'emplacement de stream supplémentaire. Tout tourne dans le cloud et se reconnecte automatiquement après un incident. Le guide de démarrage vous accompagne pour un premier live.
Questions fréquentes
Quel port utilise le SRT ?
Il n'existe pas de port standard unique. Le listener peut utiliser n'importe quel port UDP disponible, et l'opérateur du récepteur vous indique lequel. Ce port doit être ouvert au trafic UDP dans chaque pare-feu situé entre l'émetteur et le listener.
Mon émetteur SRT doit-il être caller ou listener ?
En général, l'émetteur appelle et le récepteur écoute, car les récepteurs ont souvent des adresses fixes et des ports ouverts alors que les émetteurs se trouvent derrière des pare-feu. Techniquement, les deux fonctionnent, tant que les deux côtés utilisent des modes opposés ou tous deux le mode rendezvous.
Quelle latence régler pour le streaming SRT ?
Un point de départ courant est plusieurs fois le temps d'aller-retour entre l'émetteur et le récepteur, en l'augmentant pour les liaisons avec pertes ou longue distance. Commencez prudemment, surveillez les paquets perdus, puis baissez-la progressivement. Vérifiez si votre outil attend des millisecondes ou des microsecondes.
Peut-on envoyer du SRT et du RTMP depuis le même live ?
Oui, si votre outil gère plusieurs sorties. Un service cloud peut livrer du RTMP aux plateformes publiques et du SRT à un récepteur privé en même temps, sans upload supplémentaire depuis votre connexion. Chaque destination a tout de même besoin de ses propres informations correctes.
