Planification et protocoles de transmission de données¶
Le cœur de Perfect Streamer est la livraison fiable de flux MPEG-TS entre nœuds sur un réseau public soumis aux pertes de paquets et aux délais. Cette section décrit le modèle de transmission, les protocoles de transport et la manière de planifier un canal : choisir un protocole, calculer la bande passante, la latence et les ports. Les réglages détaillés des différents champs sont traités dans la description contextuelle de l’interface web (Interface web), et le traitement du flux sur un nœud dans la section Streamer : détails d’implémentation.
Modèle de transmission : Stream, Sender, Receiver, Peer¶
L’unité de travail est un flux (Stream), un seul canal MPEG-TS. Pour chaque flux, on configure un serveur émetteur (Sender) et un ou plusieurs récepteurs (Receiver) ; l’association émetteur-récepteur est désignée par Peer.
La configuration se résume à des listes d’entrées (input) et de sorties (output) pour chaque flux :
sur l’émetteur, input correspond aux sources MPEG-TS, output à la transmission vers les récepteurs ;
sur le récepteur, input correspond à la réception du flux depuis l’émetteur.
Plusieurs entrées dans la liste assurent la redondance des sources, plusieurs sorties assurent la diffusion simultanée d’un même canal vers de nombreux destinataires et via différents protocoles.
Pour les protocoles où le récepteur initie la connexion, un récepteur derrière un NAT se connecte lui-même à l’émetteur — aucune redirection des ports entrants de son côté n’est requise.
Protocoles Peer de transmission fiable¶
Quatre protocoles Peer sont disponibles pour la transmission entre l’émetteur et le récepteur. Ils se répartissent en deux classes selon le principe de compensation des pertes :
ARQ (Automatic Repeat reQuest) — les paquets perdus sont retransmis à la demande du récepteur. Nécessite un canal de retour et un tampon sur le récepteur ; la profondeur de récupération est configurable. PS1, SRT et RIST appartiennent à cette classe.
FEC (Forward Error Correction) — des données redondantes sont ajoutées en permanence au flux, permettant de récupérer les pertes sans canal de retour. Pro-MPEG / RTP+FEC appartient à cette classe.
PS1 (Perfect Stream)¶
Un protocole propriétaire basé sur UDP. Il fonctionne selon le principe ARQ avec retransmission sélective. Il se distingue par une faible consommation de ressources et transporte des flux à débit élevé, y compris un MPTS complet.
Le récepteur initie la connexion, l’émetteur exige donc une authentification : les récepteurs sont enregistrés en tant que Peer avec identifiant et mot de passe, ou sont autorisés par IP. La latence est déterminée par le tampon du récepteur (fenêtre de suppression de la gigue et de retransmission) ; le tampon de l’émetteur doit être plus grand que celui des récepteurs. Lors du changement de source active sur l’émetteur, les récepteurs ne se reconnectent pas — l’interruption est corrigée par une retransmission normale, sans reconnexion visible.
PS1 est un protocole propriétaire qui ne fonctionne qu’entre nœuds Perfect Streamer. Il est particulièrement efficace dans une configuration point-à-multipoint : un émetteur et de nombreux récepteurs.
SRT¶
Un protocole ouvert basé sur UDP (UDT). Il est largement répandu et compense bien les pertes de paquets. Il prend en charge les modes listener et caller, ce qui assure la compatibilité avec les équipements SRT tiers et les services cloud.
En mode listener sur l’émetteur, plusieurs récepteurs se connectent à un même flux ; pour l’autorisation, les récepteurs sont enregistrés en tant que Peer, et l’autorisation par IP est disponible. La partie initiatrice (caller) peut se trouver aussi bien sur le récepteur que sur l’émetteur. La marge de bande passante pour la retransmission se définit en pourcentage au-dessus du débit du flux.
Sur les nœuds de réception denses comportant un grand nombre d’entrées SRT en mode caller, il est possible de désactiver la mise en tampon intégrée du récepteur SRT (TSBPD) : la synchronisation est alors assurée par le tampon anti-gigue du nœud (Synchronisation), ce qui réduit sensiblement la charge CPU.
RIST¶
Un protocole ouvert basé sur RTP/RTCP. Il fonctionne selon le principe ARQ sans ACK, uniquement par NACK, ce qui assure une grande efficacité. Il utilise unicast et multicast.
Les profils Simple et Main sont implémentés : Simple occupe deux ports UDP consécutifs (le port de base doit être pair), Main multiplexe les données sur un seul port. Plusieurs chemins (peers) avec équilibrage pondéré sont pris en charge — pour la redondance et l’agrégation. En multicast, les récepteurs peuvent être nombreux, avec autorisation par IP.
Pro-MPEG / RTP+FEC (SMPTE 2022-1/2)¶
Livraison de MPEG-TS sur RTP avec correction d’erreurs anticipée (FEC), sans canal de retour. Le protocole est également connu sous le nom de Pro-MPEG COP3. PSS implémente une matrice FEC bidimensionnelle (lignes et colonnes, SMPTE 2022-2).
Le flux de paquets RTP est regroupé en une matrice de taille donnée, le long des lignes et colonnes de laquelle sont formés les paquets FEC. Plus la matrice est petite, meilleure est la récupération, mais plus le surcoût permanent est élevé. Les canaux FEC occupent deux ports supplémentaires (port+2 et port+4), ce qu’il faut prendre en compte lors du placement de plusieurs flux sur un même hôte ou dans un même groupe multicast.
Les avantages sont une faible latence fixe et la compatibilité avec les équipements de diffusion professionnels. Les inconvénients sont un trafic supplémentaire permanent et une faible récupération en cas de pertes importantes (au-delà de ~0,2 %), c’est pourquoi le protocole est conçu pour des canaux gérés à faibles pertes et non pour l’internet public « lourd ».
Choix du protocole de transmission¶
Protocole |
Principe |
Canal de retour |
Latence |
Compatibilité |
|---|---|---|---|---|
PS1 |
ARQ sur UDP |
requis |
configurable |
uniquement entre nœuds Perfect Streamer |
SRT |
ARQ sur UDP (UDT) |
requis |
configurable |
ouvert ; équipements SRT tiers et cloud |
RIST |
ARQ (NACK) sur RTP/RTCP |
requis |
configurable |
ouvert ; équipements RIST tiers ; unicast et multicast |
Pro-MPEG / RTP+FEC |
FEC sur RTP |
non requis |
faible, fixe |
ouvert (SMPTE 2022-1/2) ; équipements de diffusion professionnels |
Repères de choix :
un canal entre nœuds Perfect Streamer, débit élevé ou MPTS complet, diffusion point-à-multipoint — PS1 ;
compatibilité avec des équipements tiers ou le cloud, réglage flexible de la marge de retransmission — SRT ;
un transport ouvert basé sur RTP, multicast, équilibrage sur plusieurs chemins — RIST ;
un canal géré à faibles pertes, latence minimale sans canal de retour, équipements de diffusion professionnels — Pro-MPEG / RTP+FEC.
Planification de la bande passante, de la latence et des ports¶
Protocoles ARQ (PS1, SRT, RIST). Les pertes sont compensées par la retransmission, il faut donc prévoir :
un canal de retour du récepteur vers l’émetteur ;
une marge de bande passante au-dessus du débit nominal — les pics de pertes provoquent des pics de trafic de retransmission ;
un tampon sur le récepteur pour la latence du canal. Plus le tampon est grand, plus la récupération des pertes est profonde, mais plus la latence de bout en bout est élevée ; à titre de repère, plusieurs valeurs de RTT. Les flux à faible débit nécessitent un tampon plus grand en durée, afin qu’un nombre suffisant de paquets tienne dans la fenêtre de récupération.
Protocole FEC (Pro-MPEG / RTP+FEC). Les paquets redondants sont transmis en permanence, indépendamment des pertes réelles, de sorte que le surcoût est fixe et dépend de la taille de la matrice FEC. Aucun canal de retour n’est nécessaire, la latence est faible et fixe, mais la récupération est limitée — ce transport est destiné aux canaux à faibles pertes.
Ports. Chaque point d’écoute a besoin d’un port UDP unique au sein de l’hôte ou du groupe. Tenez également compte du fait que le profil RIST Simple occupe deux ports consécutifs (le port de base pair et le suivant), et Pro-MPEG le port de base plus deux ports FEC (port+2 et port+4). Dans un réseau Meshwork, un catalogue commun des adresses et des ports occupés aide à éviter les collisions (voir Meshwork).
Chiffrement des flux¶
Tous les protocoles Peer prennent en charge le chiffrement AES à l’aide d’une phrase secrète commune saisie des deux côtés. Pour SRT, la longueur de clé est en outre sélectionnée (128, 192 ou 256 bits). Le chiffrement ne modifie pas le débit du flux.
Pour Pro-MPEG, le chiffrement est une extension non standard ; par conséquent, lorsqu’il est activé, la compatibilité avec les logiciels et équipements tiers n’est pas garantie.
Autres entrées et sorties¶
Outre les protocoles Peer, des transports standard pour la réception et la transmission sont disponibles :
Protocole |
Entrée |
Sortie |
Remarque |
|---|---|---|---|
UDP |
oui |
oui |
unicast/multicast, SSM, sélection de l’interface ; jusqu’à 7 paquets TS par datagramme |
RTP |
oui |
oui |
rétablissement de l’ordre des paquets désordonnés |
TCP |
oui |
— |
mode client ; réception là où UDP est bloqué |
HLS / HTTP |
oui |
oui |
en réception, la variante de la playlist adaptative est sélectionnée par un numéro configurable (la première par défaut) ; l’entrée est réservée au SPTS |
RTSP |
oui |
— |
caméras IP et serveurs RTSP ; auto-remux en MPEG-TS ; uniquement pour SPTS |
RTMP / RTMPS |
oui |
oui |
publication vers des récepteurs RTMP tiers ; H.264 et HEVC ; SPTS uniquement |
file / device |
oui |
oui |
enregistrement dans un fichier TS et sortie vers un périphérique (y compris SDI) ; lecture en boucle depuis un fichier |
pipe (FIFO) |
oui |
oui |
pont vers un processus externe via un canal nommé |
std (application externe) |
oui |
oui |
pont vers des protocoles non standard via une application console |
La publication et la réception RTMP sont décrites dans Publication et réception RTMP ; le RTSP, l’entrée HLS/HTTP, les fichiers et périphériques, les tubes nommés et les applications externes sont décrits dans Autres entrées et sorties. Les réglages détaillés de chaque transport figurent dans la section Interface web. La diffusion OTT (HLS, LL-HLS, DASH) est décrite séparément dans OTT et DVR.
Redondance des sources et diffusion¶
Redondance. Plusieurs entrées peuvent être définies pour un flux ; une seule est active à la fois. En cas de défaillance de l’entrée active, le flux bascule automatiquement vers la suivante de la liste et, après rétablissement, il peut revenir à la source prioritaire. Cela permet de planifier à l’avance les sources principale et de secours d’un canal ; les réglages détaillés de la commutation des entrées sont décrits dans Flux SPTS.
Diffusion. Plusieurs sorties sur un même flux permettent de diffuser un même canal à de nombreux destinataires à la fois et via différents protocoles simultanément.
Exigences relatives au flux d’entrée¶
Conformité à ISO/IEC 13818-1, Single Program (SPTS) ou Multi Program Transport Stream (MPTS).
La composition des pistes dépend du type de contenu sélectionné pour le flux SPTS, voir Flux SPTS.
Les flux embrouillés (chiffrés) sont pris en charge, voir Flux SPTS.
Pour la synchronisation, le flux doit contenir des marques PCR valides.
Le filtrage, la modification et les modes de débit du flux d’entrée sont décrits dans Flux SPTS, et les particularités du multiplexage dans Flux MPTS.