FAQ

Réponses aux questions qui se posent le plus souvent en exploitation : la compatibilité SRT avec les logiciels tiers et la réception de multicast à haut débit.

SRT : autorisation par identifiant et mot de passe dans un logiciel tiers

Entre deux nœuds Perfect Streamer, l’autorisation SRT se configure de manière native, par les champs de l’entrée et de la sortie (SRT). Le fonctionnement avec d’autres logiciels n’est pas garanti : le paramètre stream ID n’est pas normalisé et il est mis en œuvre différemment selon le logiciel.

Le mécanisme de compatibilité est le même dans tous les cas : la partie réceptrice prend le stream ID du client qui se connecte et recherche à partir de celui-ci un compte dans la liste des identifiants locaux (Utilisateur : ajout et modification). C’est le champ « Identifiant » qui doit correspondre — intégralement — à la valeur du stream ID. Par exemple, avec l’URL

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

dans le champ « Identifiant », on saisit

!#::u=1234567890,password=1234567890

La syntaxe du stream ID est sans importance pour Perfect Streamer : la chaîne n’est pas décomposée en parties, elle est comparée dans son intégralité. Il existe trois exceptions — des caractères que le nœud interprète lui-même :

  • | — séparateur : la partie de la chaîne située avant le premier caractère de ce type est prise pour l’identifiant, le reste pour le mot de passe du compte ;

  • * — le stream ID n’est pas défini ; le client est autorisé par son adresse, c’est-à-dire par un compte portant l’indicateur « Compte par adresse IP » ;

  • @ en début de chaîne est réservé à l’autorisation de service entre les nœuds d’un domaine Meshwork.

Perfect Streamer ne limite pas la longueur du stream ID — la limite vient de la bibliothèque SRT et s’élève à 512 octets, zéro terminal compris. Les valeurs dépassant environ 500 caractères ne doivent pas être transmises : une chaîne trop longue soit interrompt la connexion, soit part vide sans aucun message d’erreur.

Chaque logiciel construit le stream ID à sa manière ; par conséquent, si la réception par l’URL ne fonctionne pas, activez le réglage supplémentaire « Trace » sur la sortie SRT. Le journal du flux qui accepte la connexion affichera alors l’adresse du client, le stream ID reçu et le motif du refus — cette ligne montre ce que l’autre partie a réellement envoyé. Le stream ID peut ensuite être corrigé : par exemple, en supprimant les caractères superflus en début de chaîne qui empêchent la transmission de la valeur.

Recommandations pour l’utilisation du multicast UDP

Objectif. Recevoir de façon stable du multicast UDP dont le débit cumulé atteint plusieurs centaines de Mbps (1 Gbps et plus) sur un seul serveur.

Problème. Lors d’une réception sur des cartes réseau à interface RJ-45, des pertes croissantes de paquets multicast apparaissent dès que le trafic dépasse quelques centaines de mégabits. Le réglage fin de la carte n’y change rien — les versions actuelles des systèmes d’exploitation utilisent déjà les valeurs optimales. Les cartes équipées de meilleures puces ne suppriment pas non plus le problème, en particulier au-delà de 500 Mbps. Le bonding de deux cartes n’aide pas davantage : un même groupe multicast arrive toujours sur un seul lien physique et sur une seule file de réception ; c’est donc la bande passante totale qui est agrégée, et non la marge disponible pour un flux pris isolément.

Solution. L’expérience d’exploitation montre que la réception et l’émission de multicast UDP doivent s’appuyer sur des cartes réseau 10 gigabits à interface SFP+. Une carte économique de la classe Intel X520-DA1/2 (Intel 82599ES) suffit — dans nos tests, elle élimine les pertes de paquets pour un trafic multicast supérieur à 1 Gbps. La charge CPU diminue en outre sensiblement : le traitement des interruptions et des files de réception revient moins cher sur ces cartes.

À prendre en compte lors du diagnostic : le compteur d’erreurs de réception recv-err des statistiques de l’entrée ne comptabilise que les erreurs de lecture du socket et les pertes de synchronisation sur la frontière du paquet TS. Les pertes provoquées par le débordement du tampon de réception du noyau n’atteignent pas l’application et n’entrent pas dans ce compteur — elles sont visibles avec la commande netstat -su (ligne RcvbufErrors) et à travers les erreurs de continuité dans l’analyseur de flux (Analyseur).

Recommandations de configuration réseau pour le multicast

Cette section s’applique aux entrées réseau UDP / RTP et Pro-MPEG. Ces paramètres n’influent pas sur la réception SRT : la bibliothèque SRT définit elle-même la taille du tampon, tandis que la latence et la marge de retransmission se configurent sur l’entrée elle-même (SRT).

La taille du tampon de réception du socket est définie par le réglage supplémentaire « Socket buffer (bytes) » de l’entrée. Par défaut, il vaut zéro — le nœud ne demande rien et le socket reçoit la taille de tampon fixée dans le système par le paramètre net.core.rmem_default. Dès qu’une valeur est définie explicitement, le plafond net.core.rmem_max entre en vigueur : le noyau réduit silencieusement la demande à cette limite, sans signaler la troncature ni au journal ni aux statistiques. C’est pourquoi le plafond est relevé avant de définir la taille du tampon sur l’entrée.

Les paramètres sont définis dans un fichier distinct sous /etc/sysctl.d/ :

cat > /etc/sysctl.d/99-pss-net.conf <<EOF
net.core.rmem_default=8388608
net.core.rmem_max=16777216
EOF

Appliquer :

sudo sysctl --system

La valeur rmem_max n’est qu’un plafond, aucune mémoire n’est réservée à ce titre. La valeur rmem_default s’applique à tous les sockets UDP du système ; si une telle taille globale n’est pas souhaitable, laissez-la inchangée et ne définissez « Socket buffer (bytes) » que sur les entrées qui en ont réellement besoin. Pour le calcul, prenez comme repère le débit du flux multiplié par la pause admissible dans le traitement du socket : 8 MB couvrent environ 64 ms à 1 Gbps.

Flussonic et SRT

Exemple d’URL SRT pour la réception par le logiciel « Flussonic » :

srt://Stream_IP:port?streamid=flussonic

Où streamid est l’identifiant du client dans le logiciel « Flussonic », qui se définit dans la section « Configuration — Paramétrage des pairs ».

Lors de l’ajout d’un nouveau client, il suffit d’indiquer uniquement l’identifiant ; l’URL de test utilise « flussonic ». Lorsqu’il travaille avec SRT, le logiciel « Flussonic » génère automatiquement le streamID, et si l’identifiant streamID n’est pas indiqué dans l’URL du côté réception, le flux ne sera pas reçu et Perfect Streamer ne pourra pas le délivrer.

De la même manière, il est possible de définir le streamID au format identifiant et mot de passe : créez dans Perfect Streamer un compte dont le champ « Identifiant » est égal à !#::u=1234567890,password=1234567890, puis renseignez dans « Flussonic » l’URL :

srt://Stream_IP:port?streamid=!#::u=1234567890,password=1234567890

Il est possible d’indiquer le streamID au format adresse IP dans Perfect Streamer — pour cela, l’indicateur « Compte par adresse IP » est activé sur le compte et le champ d’adresse reçoit :

  • 192.168.1.1 — une IP unique ;

  • 192.168.1.1-192.168.1.254 — une plage d’IP.

Dans les deux cas, l’URL de réception par IP dans « Flussonic » se présente ainsi : srt://Stream_IP:port?streamid=*

Le flux est lié à l’adresse IP du client : la réception via cette URL n’est possible que depuis l’adresse IP indiquée (ou depuis la plage indiquée).