Protocoles de transmission¶

Comment livrer un flux d’un nœud à un autre ou à un équipement tiers. Ici : quel protocole choisir, ce qu’il coûte en bande passante et en latence, quels ports il occupe et comment il est chiffré.

Si ce n’est pas la liaison qui tombe en panne, mais la source, le réseau ou le nœud : Redondance : ce qui protège contre quoi.

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 COP3/RTP+FEC (SMPTE 2022-1/2) 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.

Connexion. C’est le récepteur qui initie la connexion : un NAT de son côté n’est donc pas un obstacle, et aucune redirection de ports n’est nécessaire sur le récepteur. L”émetteur admet le récepteur en tant que Peer — par identifiant et mot de passe, ou par IP.
Latence — 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 ceux des récepteurs (latence).
Le changement de source sur l’émetteur ne coupe pas la connexion : le trou est comblé par la retransmission normale.

PS1 est un protocole propriétaire qui ne fonctionne qu’entre nœuds Perfect Streamer. Il convient le mieux à une configuration point-à-multipoint : un émetteur et de nombreux récepteurs.

SRT¶

Un protocole ouvert basé sur UDP (dérivé du protocole 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 un nœud de réception comportant un grand nombre d’entrées SRT en mode caller, il est possible de désactiver le tampon du récepteur SRT (TSBPD, livraison selon les horodatages de l’émetteur) : la synchronisation sera assurée par le tampon de gigue du nœud (Synchronisation), et la charge CPU baissera sensiblement.

RIST¶

Un protocole ouvert basé sur RTP/RTCP. Il fonctionne selon le principe ARQ par NACK : le récepteur ne signale que les pertes. Il utilise l’unicast et le 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 FEC¶

Livraison de MPEG-TS sur RTP avec correction d’erreurs anticipée (FEC), sans canal de retour. Perfect Streamer 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, dont les lignes et les colonnes servent à former 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 ».

Important

Version bêta 2.1. Ce qui est décrit ici n’existe que dans la version bêta 2.1 : elle s’installe depuis le dépôt bêta et uniquement avec une licence ; la version stable 2.0.2 et la version de démonstration ne l’ont pas. La version bêta est fournie sans garantie, et l’assistance est assurée dans la mesure du possible (Programme de test bêta).

Dans la version 2.1, le FEC d’entrée et de sortie est conforme à SMPTE ST 2022-1 :

les récepteurs standard s’en servent pour récupérer les pertes ;
l’entrée accepte le FEC par colonnes seulement (1D) et par colonnes et lignes (2D), avec une matrice de n’importe quelle taille ;
la sortie peut n’envoyer que le FEC par colonnes : avec une matrice 5 × 10, le surcoût est de 10 % au lieu de 30 %, mais la récupération est plus faible ;
Pro-MPEG se combine avec le second chemin SMPTE ST 2022-7 et avec la réserve à chaud des sorties (Redondance : ce qui protège contre quoi).

Latence due à l’attente du FEC : Planification de la bande passante, de la latence et des ports.

Choix du protocole de transmission¶

En bref.

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, marge de retransmission en pourcentage au-dessus du débit — 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 FEC.

En détail :

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 FEC	FEC sur RTP	non requis	faible, fixe	ouvert (SMPTE 2022-1/2) ; équipements de diffusion professionnels

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). 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 convient donc aux canaux à faibles pertes. La récupération par FEC ajoute une latence à la réception : tant qu’un paquet perdu attend le FEC de sa matrice, l’entrée retarde la sortie du flux. Plus la matrice est grande et le débit faible, plus l’attente est longue — avec une grande matrice et un faible débit, elle se compte en secondes, et elle doit être couverte par le tampon de gigue de l’entrée (limite d’attente FEC).

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, le catalogue commun des adresses et des ports occupés aide à éviter les collisions (voir Meshwork).

Chiffrement des flux¶

Le chiffrement AES s’active au moyen d’une phrase secrète commune, définie des deux côtés de la connexion ; les phrases doivent coïncider. Une phrase vide signifie un fonctionnement sans chiffrement. Le chiffrement ne modifie pas le débit du flux.

La prise en charge et la longueur admissible de la phrase diffèrent selon les protocoles :

Protocole	Longueur de la phrase secrète	Particularités
PS1	10–64 octets	—
SRT	10–79 octets	La longueur de clé se choisit en plus : 128, 192 ou 256 bits. Une phrase hors de la longueur admissible arrête l”entrée ou la sortie avec un message d’erreur explicite.
RIST	non vérifiée ; les 127 premiers octets sont utilisés	Uniquement dans le profil Main. Dans le profil Simple, la phrase secrète est sans effet.
Pro-MPEG	10–64 octets	Extension non standard : lorsqu’elle est activée, la compatibilité avec les logiciels et équipements tiers n’est pas garantie.

La longueur de la phrase se compte en octets et non en caractères : une lettre cyrillique occupe deux octets.

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	l”entrée est réservée au SPTS ; la variante de la playlist adaptative est choisie par son numéro (la première par défaut)
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 MPEG-TS vers un périphérique (par exemple, ASI) ; 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.

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 (codé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 multiplex dans Flux MPTS.