Abonnez-vous à DeepL Pro pour éditer ce d

Visitez [Link]/pro pour en savoir plus.

Guide de déploiement des SRT, v1.1, édition 01

1
 Table des matières
A propos de ce guide .............................................................................iv
A propos de l'Alliance
SRT........................................................................................................... iv
A propos de
Haivision....................................................................................................................... iv
À propos de
Wowza.......................................................................................................................... iv
Conventions des
documents............................................................................................................. v

Introduction à la SRT ..........................................................................1

Aperçu................................................................................................................................... 1
Solutions SRT........................................................................................................................... 2
Historique des versions et compatibilité des
SRT..................................................................................... 4
Concepts de base de la TRS ................................................................................................................. 5
Source et destination ......................................................................................................... 5
Modes d'appel
SRT................................................................................................................. 6
Exemples de mode d'appel SRT
........................................................................................................ 7
SRT et pare-feux .................................................................................................................... 9
Exemple 1........................................................................................................................... 9
Exemple 2......................................................................................................................... 10

Scénarios de déploiement ....................................................................11

Scénario 1 : Streaming sur un LAN ou WAN privé.............................................................. 12
Scénario 2 : Streaming utilisant les modes Caller &
Listener........................................................... 14
Notes sur les pare-feu
.................................................................................................................. 20
Scénario 3 : Streaming en utilisant le mode
Rendezvous..................................................................... 21
Mode rendez-vous et pare-feu............................................................................................ 23

Configuration des flux SRT ................................................................25

Contexte............................................................................................................................. 25
Configurer un flux SRT ................................................................................................... 26
Paramètres SRT ...................................................................................................................... 28
Round Trip Time.............................................................................................................. 28

Guide de déploiement des SRT, v1.1, édition 01

 Multiplicateur
RTT................................................................................................................. 28
Taux de perte de paquets
.............................................................................................................. 28 Surcharge de la
bande passante........................................................................................................ 29
Exemple de calcul de la surcharge de la bande passante
....................................................................... 29
Latence............................................................................................................................. 30
Cryptage des flux SRT ........................................................................................................ 31
Optimisation des performances de la SRT
................................................................................................ 32

Guide de déploiement des SRT, v1.1, édition 01i

Statistiques ........................................................................................................................... 32
SRT................................................................................................................................... 34
Retards............................................................................................................................... 37
Bande passante utilisée............................................................................................................... 38
Taux d'échantillonnage du
graphique................................................................................................................ 40
Journaux
SRT................................................................................................................................ 41

Annexe A : Informations complémentaires

Questions fréquemment posées...................................................................................................
42
Termes et définitions ............................................................................................................ 47
À propos de la SRT
Alliance.......................................................................................................... 49
 ii
Copyright
©2017 Haivision. Tous droits réservés.

Numéro du document : HVS-ID-DG-SRT-1.1

Numéro de version : v1.1-01
Cette publication et le produit qu'elle décrit contiennent des informations exclusives et
confidentielles. Aucune partie de ce document ne peut être copiée, photocopiée,
reproduite, traduite ou réduite à un format électronique ou lisible par une machine sans
l'autorisation écrite préalable de Haivision. Les informations contenues dans ce document
sont susceptibles d'être modifiées sans préavis. Haivision n'assume aucune responsabilité
pour tout dommage résultant de l'utilisation de ce document, y compris, mais sans s'y
limiter, la perte de revenus, la perte de données, les réclamations de tiers ou autres
dommages.
Si vous avez des commentaires ou des suggestions concernant ce guide de l'utilisateur,
veuillez contacter :
Département des publications techniques
Haivision
4445 Garand
Montréal, Québec, H4R 2H9 Canada
Téléphone : 1-514-334-5445
Numéro gratuit (Amérique du Nord) 1-877-224-5445
infodev@[Link]

Marques commerciales
Le logo Haivision, Haivision et certaines autres marques utilisées ici sont des marques de
commerce de
Haivision. Tous les autres noms de marques ou de produits identifiés dans ce document
sont des marques commerciales ou des marques déposées de leurs sociétés ou
organisations respectives.
Le logo de l'Alliance SRT utilisé ici est une marque de l'Alliance SRT. Les logos SRT et
Makito X utilisés dans ce document sont des marques de commerce de Haivision. Tous les
autres noms de marques ou de produits identifiés dans ce document sont des marques
commerciales ou des marques déposées de leurs sociétés ou organisations respectives.
HDMI, le logo HDMI et High-Definition Multimedia Interface sont des marques ou des
marques déposées de HDMI Licensing LLC.

À propos de ce guide

Guide de déploiement des SRT, v1.1, édition 01

 Bienvenue dans le guide de déploiement. Ce guide décrit le protocole SRT et la manière
dont il est configuré et utilisé entre tous les dispositifs pris en charge.

A propos de l'Alliance SRT

L'alliance SRT, fondée par Haivision et Wowza, est un groupe financé par des fonds
commerciaux qui se consacre à la gestion et au soutien de l'implémentation open source
de SRT, un protocole de transport permettant la diffusion de vidéos de haute qualité et à
faible latence sur l'Internet public. Cette alliance accélère l'interopérabilité des solutions
de streaming vidéo et encourage la collaboration avec les leaders du secteur pour parvenir
à un transport vidéo Internet à faible latence. L'alliance SRT est ouverte à de nouveaux
membres. Les entreprises qui souhaitent participer activement à la croissance de
l'écosystème SRT dans les flux de travail de streaming vidéo à faible latence sont invitées
à nous contacter à l'adresse info@[Link].

À propos de Haivision
Haivision est un leader mondial dans la fourniture de solutions avancées de réseaux vidéo,
de signalisation numérique et de distribution vidéo sur IP. Haivision offre une technologie
complète de bout en bout pour la vidéo, les graphiques et les métadonnées afin d'aider les
clients à créer, gérer et distribuer leur contenu multimédia aux utilisateurs d'une
organisation ou d'Internet. Haivision possède une expertise spécifique dans les marchés de
l'entreprise, de l'éducation, de la médecine et des soins de santé, ainsi que dans le secteur
fédéral et militaire.
Haivision est basée à Montréal et Chicago, avec des centres techniques à Beaverton,
Oregon, Austin, Texas et Hambourg, Allemagne.

À propos de Wowza
Wowza Media Systems™ est la référence reconnue en matière de streaming, qui permet
aux organisations d'étendre leur portée et d'engager plus profondément leur public sur
n'importe quel appareil, partout dans le monde.

iv
Conventions relatives aux documents
Les conventions de document suivantes sont utilisées dans ce guide.

Le symbole de l'ampoule électrique met en évidence les suggestions ou les

conseils utiles.

Indique une note, contenant des instructions ou des informations particulières qui peuvent s'appl
dans des cas
uniquement
particuliers.

IMPORTANT Indique une note mise en évidence. Elle fournit des informations que vous devez
dont il faut être particulièrement conscient pour accomplir une tâche et qui ne doivent pas
être négligées. IMPORTANT est généralement utilisé pour éviter la perte de données.

ATTENTION Indique une situation potentiellement dangereuse qui, si elle n'est pas évitée,
peut entraîner des dommages aux données ou à l'équipement, ou des blessures
mineures à modérées. Il peut également être utilisé pour mettre en garde contre des
pratiques dangereuses.

Guide de déploiement des SRT, v1.1, édition 01

 v

Introduction à la SRT

Ce document fournit des conseils sur la mise en place et le déploiement de la technologie

SRT, qui est une caractéristique d'un nombre croissant de produits.
Pour des informations générales sur la création et la gestion des flux, veuillez vous référer
à la documentation spécifique de votre/vos produit(s).

Vue d'ensemble
Secure Reliable Transport (SRT) est une technologie de transport qui optimise les
performances de la diffusion en continu sur des réseaux imprévisibles, tels qu'Internet.
Secure Cryptage des flux vidéo

Fiable Récupération après une perte de paquets importante

Transport S'adapte dynamiquement aux conditions changeantes du réseau

La SRT est appliquée aux points d'extrémité de contribution et de distribution dans le cadre
d'un flux de travail vidéo afin de fournir à tout moment la meilleure qualité et la plus faible
latence vidéo.
Lorsque les paquets audio/vidéo sont diffusés en continu d'un appareil source à un
appareil de destination, la SRT détecte et s'adapte aux conditions du réseau en temps réel
entre les deux points d'extrémité. La SRT permet de compenser la gigue et les
fluctuations de la bande passante dues à la congestion sur les réseaux bruyants, comme
Internet. Son mécanisme de récupération des erreurs minimise la perte de paquets typique
des connexions Internet. Enfin, la SRT prend en charge le cryptage AES pour une
sécurité de bout en bout, afin de protéger vos flux de données des regards indiscrets.
SRT Solutions

SRT Solutions
SRT est un protocole point à point, orienté connexion. Chaque flux SRT se caractérise par
le transport de données multimédia unidirectionnelles et de messages de contrôle
bidirectionnels, une seule connexion UDP étant utilisée par flux SRT. Néanmoins, il est
possible de configurer des solutions SRT qui englobent une variété de situations.

Point à point et interactif

Guide de déploiement des SRT, v1.1, édition 01 1

 La SRT peut être facilement approvisionnée pour des connexions simples au sein et entre
les installations afin de réaliser une distribution vidéo à faible latence et à faible coût.
Elle peut être utile sur des réseaux locaux bruyants et peu fiables. Dans les grandes
entreprises comptant de nombreux utilisateurs sur le même réseau local, les
encombrements et les pertes de paquets sont fréquents - la vidéo y est très sensible. Même
à l'intérieur d'un même bâtiment sur un réseau local contrôlé, la SRT peut améliorer
l'expérience.
Certains réseaux ont des VLAN avec une bande passante réservée (où les routeurs
hiérarchisent le trafic) qui nécessitent une connaissance approfondie des routeurs et des
commutateurs. La SRT supprime la nécessité d'une intervention informatique pour faire
passer votre vidéo sur le réseau.

La faible latence obtenue avec la SRT convient même aux applications interactives sur
Internet.

Contribution et agrégation

Plusieurs dispositifs SRT source et destination peuvent être configurés pour alimenter des
infrastructures vidéo à forte demande.

Guide de déploiement des SRT, v1.1, édition 01 2

 SRT Solutions

Plusieurs flux SRT peuvent être agrégés et redistribués via unicast et multicast dans des
services d'enregistrement, d'IPTV et de signalisation numérique.

Point à Multi-Point

Bien que la SRT fonctionne sur des connexions point à point, certaines passerelles sont
conçues pour prendre en charge plusieurs de ces connexions. Un seul flux SRT entrant
peut être redistribué via ces passerelles vers plusieurs périphériques de destination SRT.

SRT Stream Flipping

Les appareils de destination SRT prennent en charge le "stream flipping", c'est-à-dire la

possibilité de convertir les flux SRT en flux de transport MPEG standard (TS). Cette
opération s'effectue en désencapsulant un flux SRT entrant et en le rediffusant sous la
forme d'un flux TS/UDP (et vice versa). Elle est généralement effectuée pour permettre

Guide de déploiement des SRT, v1.1, édition 01 3

 aux appareils (sur un réseau local) qui ne prennent pas en charge la SRT d'avoir accès au
contenu du flux SRT entrant.
Historique et compatibilité des versions de SRT

Historique et compatibilité des versions de SRT

La SRT est conçue pour être rétrocompatible, de sorte que les produits nouveaux ou mis à
niveau pourront supporter les interactions SRT avec les anciens. Notez cependant que les
nouvelles versions de SRT peuvent avoir des fonctionnalités non disponibles sur les
anciennes.

Guide de déploiement des SRT, v1.1, édition 01 4

 Concepts de base de la SRT

Concepts de base de la SRT

Source et destination
Le protocole SRT s'appuie sur le trafic UDP bidirectionnel pour optimiser la diffusion
vidéo sur les réseaux publics. Outre les données vidéo qui sont envoyées dans un sens -
d'un dispositif source de contenu vers une destination - il y a un échange constant
d'informations de contrôle entre les deux points d'extrémité, y compris des paquets "keep
alive" (si nécessaire) toutes les 10 ms environ, qui permettent aux flux SRT d'être
automatiquement restaurés après une perte de connexion.

REMARQUE Il est important de comprendre qu'avec un flux SRT, la source est le dispositif
qui envoie le contenu (données audio et/ou vidéo), tandis que la destination est le
dispositif qui reçoit le contenu. Ailleurs, vous pourrez rencontrer des références à un
émetteur SRT et à un récepteur SRT, mais pour éviter toute confusion dans ce document,
nous utiliserons les termes source et destination.

Dans certains cas, un dispositif peut agir à la fois comme source et comme destination.
Par exemple, un serveur passerelle peut agir comme une destination tout en recevant un
flux SRT d'un codeur, puis devenir un dispositif source lorsqu'il rediffuse le flux vers un
décodeur.
Concepts de base de la SRT

Modes d'appel SRT

Afin d'établir un flux bidirectionnel, la SRT utilise un mécanisme de poignée de main où
chaque dispositif s'identifie comme appelant ou comme auditeur. Dans certains cas,
deux périphériques peuvent négocier simultanément une session SRT dans ce que l'on

Guide de déploiement des SRT, v1.1, édition 01 5

 appelle le mode Rendez-vous. Lorsque vous configurez des flux SRT, vous devez
comprendre ces modes de poignée de main et savoir quand les appliquer :
Mode d'appel Ce qu'il fait Quand l'utiliser
SRT
Appelant Définit un périphérique source ou de (1) Pour lancer un streaming point à
destination comme initiateur d'une point (par exemple, configurer un
session de streaming SRT. Le dispositif encodeur en mode appelant pour diffuser
appelant doit connaître l'adresse IP un flux vers un décodeur sur un réseau
publique et le numéro de port du dispositif privé, ou vice versa).
écoutant. (2) Sur un périphérique source ou de
destination qui se trouve derrière un pare-
feu ; il peut être nécessaire qu'un
administrateur réseau configure les
paramètres du pare-feu.
(3) Sur un appareil source ou de
destination qui n'est pas derrière un pare-
feu.
(4) Sur un périphérique source ou de
destination avec une adresse IP
dynamique (par exemple, un encodeur
portable utilisant DHCP).
Auditeur Configure un périphérique pour qu'il (1) Pour participer à une session de
attende une demande de démarrage d'une streaming point à point initiée par un
session de streaming SRT. Le appelant (par exemple, faire passer un
périphérique Listener doit simplement décodeur en mode "écouteur" pour
savoir qu'il doit écouter un flux SRT sur un recevoir un flux SRT d'un encodeur).
certain port. (2) Sur un appareil source ou de
destination qui se trouve derrière un pare-
feu dont vous avez le contrôle et sur lequel
vous pouvez ouvrir un port.
(3) Sur un appareil source ou de
destination qui n'est pas derrière un pare-
feu, ou exposé directement sur Internet.
(4) Vous savez qu'un autre appareil
va initier la session.
Rendez-vous Permet à deux dispositifs de négocier une (1) Lorsqu'un ou les deux appareils sont
session SRT sur un port convenu derrière un pare-feu. Une fois que certains
mutuellement. La source et la paramètres sont en place sur le pare-feu,
destination doivent toutes deux être en les sessions SRT peuvent être lancées
mode Rendez-vous. sans autre intervention de la part d'un
administrateur réseau.
Exemples de mode d'appel SRT

Guide de déploiement des SRT, v1.1, édition 01 6

Exemples de mode d'appel SRT
Dans la figure 1 ci-dessous, le dispositif source SRT est en mode appelant et le dispositif
de destination SRT est en mode auditeur. La source SRT (Caller) initie la poignée de
main en envoyant une série de paquets de contrôle dans un flux UDP (1). Lorsque la
destination SRT (Listener) reçoit ces paquets de contrôle, elle répond en envoyant les
siens (2). Une fois la poignée de main terminée, le dispositif source SRT commence à
ajouter des paquets média au flux UDP (3).

Figure 1Le dispositif source SRT initie la connexion

a terminé les deux

source et destination continuent à échanger des paquets de contrôle contenant
REMARQUE Quel que soit le dispositif dans quel mode, lorsque la poignée de main SRT est
des informations sur les conditions du réseau, les paquets abandonnés, etc. Une fois la
communication établie, la notion de quel dispositif est l'appelant et quel dispositif est
l'auditeur devient sans importance. Ce qui compte, c'est la relation source/destination,
qui est découplée de la relation appelant/auditeur.

Exemples de mode d'appel SRT

Dans la figure 2 ci-dessous, les rôles sont inversés : le dispositif SRT source est en mode
"Listener" et le dispositif SRT de destination est en mode "Caller". La destination SRT
(Caller) initie la poignée de main en envoyant une série de paquets de contrôle dans un

Guide de déploiement des SRT, v1.1, édition 01 7

 flux UDP (1). Lorsque la source SRT (Listener) reçoit ces paquets de contrôle, elle répond
en envoyant les siens (2). Une fois la poignée de main terminée, le dispositif source SRT
commence à ajouter des paquets média au flux UDP (3).

Figure 2Le dispositif de destination SRT initie la connexion

Dans la figure 3 ci-dessous, le dispositif SRT source et le dispositif SRT de destination

sont tous deux en mode Rendez-vous. Les deux dispositifs envoient une série de paquets
de contrôle dans un flux UDP (1). Une fois la poignée de main terminée, le dispositif
source SRT commence à ajouter des paquets média au flux UDP (2).

Figure 3Connexion SRT initiée à l'aide de Rendezvous

SRT et pare-feu

Guide de déploiement des SRT, v1.1, édition 01 8

SRT et pare-feu
Dans de nombreuses situations réelles, notamment celles impliquant une transmission sur
Internet, les flux SRT devront traverser un pare-feu à la source, à la destination ou aux
deux extrémités. Pour ce faire, un administrateur réseau peut être amené à configurer
certains paramètres sur le ou les pare-feu, notamment ceux relatifs à la traduction
d'adresses réseau (NAT) et au filtrage des paquets. Ces paramètres diffèrent selon que les
dispositifs situés derrière les pare-feu sont en mode appelant, auditeur ou rendez-vous.

Exemple 1
La figure de droite illustre un exemple simple, où une
Un dispositif source SRT tente de diffuser un flux de
données sur Internet vers une destination SRT située
derrière un pare-feu. Si l'on considère le cas où le dispositif
source SRT est en mode appelant et le dispositif de
destination en mode auditeur, certaines conditions
doivent être remplies pour que le processus d'échange de
signaux décrit précédemment soit mené à bien (et qu'une
session de diffusion SRT soit établie) :
• Le dispositif SRT source doit "connaître" l'adresse IP
publique du pare-feu et le numéro de port sur lequel le
dispositif SRT de destination "écoute".
• Le pare-feu doit permettre au port de destination
spécifique utilisé par le SRT d'être accessible depuis
Internet.
• Le pare-feu doit autoriser le trafic UDP bidirectionnel.
• Le transfert de port doit être activé sur le pare-feu pour
permettre aux données de circuler vers l'adresse IP et
le port du dispositif de destination SRT.
• Le filtrage des paquets doit être désactivé (pour
permettre aux paquets SRT de passer).
SRT et pare-feu

Guide de déploiement des SRT, v1.1, édition 01 9

 Exemple 2
Cette figure illustre un exemple plus complexe, dans lequel
un dispositif source SRT situé derrière un pare-feu tente de
transmettre un flux continu sur Internet vers une
destination SRT, également située derrière un pare-feu. Si
l'on considère le cas où le dispositif source SRT est en
mode appelant et le dispositif de destination en mode
auditeur, certaines conditions doivent être remplies pour
que le processus d'échange de données décrit
précédemment soit mené à bien (et qu'une session de
diffusion SRT soit établie) :
• Le dispositif SRT source doit "connaître" l'adresse IP
publique du pare-feu de destination et le numéro du
port sur lequel le dispositif de destination "écoute".
Ces informations proviennent généralement de
l'administrateur informatique responsable du pare-feu.
• Les deux pare-feu doivent autoriser le trafic UDP
bidirectionnel.
• Le transfert de port (NAT) doit être configuré sur les
deux pare-feu pour permettre aux données de circuler
entre les périphériques source et de destination du
SRT.
• Le filtrage des paquets doit être désactivé sur les deux
pare-feu (c'est-à-dire que les paquets SRT échangés
entre le dispositif source et le dispositif de destination
doivent être autorisés à passer).

REMARQUE L'ordre dans lequel un pare-feu effectue la

traduction d'adresses réseau et le filtrage de paquets
aura un impact sur la façon dont les règles de filtrage de
paquets sont configurées.

Guide de déploiement des SRT, v1.1, édition 01 10

 Scénarios de déploiement

Cette section décrit trois scénarios courants de déploiement du SRT :

• Scénario 1 : diffusion en continu sur un LAN et/ou WAN privé, sans pare-feu.
• Scénario 2 : diffusion en continu sur un réseau public avec la source et la destination
derrière un pare-feu (mode appelant/auditeur)
• Scénario 3 : diffusion en continu sur un réseau public avec la source et la destination
derrière un pare-feu (mode Rendez-vous)
Dans les applications du monde réel, les éléments de ces scénarios peuvent être utilisés de
diverses manières.

Certaines des valeurs fournies à titre d'exemple dans ces scénarios (adresses IP, port
) ne sont donnés qu'à titre d'exemple.

NOTE Le projet open source SRT ne contient pas d'éléments d'interface utilisateur Web.
À des fins d'illustration, cette section contient des exemples d'interface Web basés sur
des produits SRT existants.
Scénario 1 : diffusion en continu sur un LAN ou un WAN privé

Scénario 1 : diffusion en continu sur un LAN ou un WAN privé

Dans ce scénario, un dispositif source SRT (l'appelant) lance une session point à point
avec un dispositif de destination SRT (l'auditeur) sur un LAN (réseau local) ou un WAN
(réseau étendu) privé.

Étape 1 - Configurer l'encodeur

Sur l'encodeur (le périphérique source SRT), procédez comme suit :

1. En utilisant les paramètres du tableau ci-dessous, créez et démarrez un flux de sortie sur
l'encodeur (le périphérique source SRT) :
Réglage de Exemple Description

Protocole TS sur SRT SRT est basé sur le protocole UDP.

Mode Appelant L'encodeur va initier la session SRT.

Adresse [Link] L'adresse cible du flux SRT, qui est l'adresse IP du décodeur.

Guide de déploiement des SRT, v1.1, édition 01 11

 Source : 20000 Le port source UDP pour le flux SRT, qui est le port unique sur lequel
Port l'encodeur enverra le flux SRT. Vous pouvez (facultativement) spécifier le
port source UDP. S'il n'est pas renseigné, un port source éphémère sera
attribué (entre 32768 et 61000).

Port de 30000 Le port sur lequel le décodeur sera en écoute.

destination
Étape 2 - Configuration du décodeur
Sur le décodeur (le périphérique de destination SRT), procédez comme suit :

1. En utilisant les paramètres du tableau ci-dessous, créez un flux d'entrée sur le décodeur
(le périphérique de destination SRT) :
Réglage de Exemple Description

Mode Auditeur Le décodeur attendra que l'appareil source lance la session SRT.

Port de 30000 Il s'agit du port sur lequel le décodeur sera à l'écoute (le port vers lequel
destination le pare-feu B transmettra les paquets SRT).

L'encodeur et le décodeur s'accordent et établissent une session SRT. L'encodeur envoie

le flux vidéo au décodeur, qui traite le flux et renvoie des paquets de contrôle comprenant
des données sur la congestion, la latence et d'autres statistiques. L'encodeur utilisera ces
informations pour adapter sa transmission (renvoi des paquets perdus, ajustement du
débit binaire, etc.)
Notez que lorsque la poignée de main SRT est terminée, la source et la destination
continuent à échanger des paquets de contrôle. Une fois la communication établie, la
désignation de l'appelant ou de l'auditeur devient sans importance. Ce qui compte, c'est la
relation source/destination, ou flux vidéo, qui est découplée de la relation
appelant/auditeur.
Scénario 1 : diffusion en continu sur un LAN ou
un WAN privé

Guide de déploiement des SRT, v1.1, édition 01 12

Guide de déploiement des SRT, v1.1, édition 01 13
Scénario 2 : Streaming en utilisant les modes "Caller" et "Listener".
Dans ce scénario, un dispositif source SRT (un codeur en mode appelant) derrière un
pare-feu initie une session point à point sur Internet avec un dispositif de destination
SRT (un décodeur en mode auditeur), également derrière un pare-feu.

Étape 1 - Configuration de l'encodeur

Sur l'encodeur (le périphérique source SRT), procédez comme suit :

1. En utilisant les paramètres du tableau ci-dessous, créez et démarrez un flux de sortie sur
l'encodeur (le périphérique source SRT) :
Réglage de Exemple Description

Protocole TS sur SRT SRT est basé sur le protocole UDP.

Mode Appelant L'encodeur va initier la session SRT.

Adresse [Link] L'adresse cible du flux SRT, qui est l'adresse IP publique du pare-feu B (à la
destination).

Source : 20000 Le port source UDP unique pour le flux SRT ; vous pouvez laisser la valeur
Port par défaut (Auto-assign), auquel cas un port éphémère est attribué, ou, si les
politiques informatiques de votre organisation l'exigent, entrer un numéro de
port spécifique (statique). Si vous utilisez l'attribution automatique, le pare-feu
A doit être configuré pour mapper TOUT port source de son côté local à un
port spécifique de son côté public afin que le trafic de retour puisse être dirigé
vers l'encodeur.
Destination 30000 Le port sur lequel le décodeur sera à l'écoute. Il s'agit du numéro de port
Port publiquement mappé pour le périphérique de destination SRT (c'est-à-dire le
port que le pare-feu B ouvre pour la session SRT). Ce port doit être connu (il
ne peut pas être "any").

Guide de déploiement des SRT, v1.1, édition 01 14

 Étape 2 - Configurer le pare-feu à la source

Guide de déploiement des SRT, v1.1, édition 01 15

 Sur le pare-feu A (à la source), procédez comme suit :

1. À l'aide des paramètres du tableau ci-dessous, créez une règle NAT sortante qui autorise
le trafic UDP bidirectionnel, avec une entrée de transfert de port pour le trafic entrant
sur l'adresse IP/le port public du pare-feu qui le transmet à l'adresse IP/au numéro de
port de l'encodeur :
Réglage de Exemple Description

Protocole UDP SRT est basé sur le protocole UDP.

Source IP [Link] L'adresse IP de l'encodeur

Port source 20000 Dans ce cas, nous utilisons une assignation de

port statique. pour le port source, mais s'il est
auto-assigné, il peut être n'importe quoi dans la
gamme de ports éphémères.
(généralement 32768 à 61000 sur les
périphériques Linux).
IP de destination [Link] Il s'agit de l'adresse IP publique du pare-feu B.

Port de destination 30000 Il s'agit du port sur lequel le décodeur écoutera.

NAT sortant 20000 Votre pare-feu doit prendre en charge le port

Port source source NAT sortant (qui désactive la réécriture du
port NAT sortant), sinon le mode Rendez-vous
peut être nécessaire (voir le scénario 3).

Voici un exemple de règle NAT sortante pour le pare-feu A :

Étape 3 - Configurer le pare-feu à la destination

Sur le pare-feu B (à la destination), faites ce qui suit :

1. En utilisant les paramètres du tableau ci-dessous, créez une règle NAT entrante pour
permettre le transfert du trafic SRT vers l'adresse IP/le numéro de port du décodeur :
Réglage de Exemple Description

Protocole UDP SRT est basé sur le protocole UDP.

Source IP [Link] Il s'agit de l'adresse IP publique du pare-feu à la

source (pare-feu A).

Port source 20000 Il doit correspondre au port source NAT sortant

du pare-feu à la source (pare-feu A).

Guide de déploiement des SRT, v1.1, édition 01 16

 Réglage de Exemple Description

IP de destination [Link] Il s'agit de l'adresse IP publique (externe) du

pare-feu à la destination (pare-feu B).

Port de destination 30000 Il s'agit du port public (externe) du pare-feu de la

destination (pare-feu B), qui dans cet exemple
est également le port sur lequel le décodeur
écoutera (dstport).

Redirection de l'IP [Link] Il s'agit de l'adresse du décodeur (l'IP de

cible destination interne).

Rediriger la cible 30000 Il s'agit du port sur lequel le décodeur écoutera

Port (le port de destination interne, ou dstport).

REMARQUE L'IP et le port de la cible de redirection sont l'IP interne et le numéro de port
que le périphérique de destination utilise. L'IP et le port de destination sont l'interface
externe du pare-feu. Les numéros de port ne doivent pas nécessairement être identiques.
Pour plus de clarté, il peut être utile de toujours utiliser le même numéro de port, mais c'est
à l'administrateur du pare-feu d'en décider.

Voici un exemple de règle NAT entrante pour le pare-feu B :

2. En utilisant les paramètres du tableau ci-dessous, créez une règle de filtrage de paquets
pour permettre aux paquets SRT de passer librement vers et depuis l'adresse IP/le
numéro de port du décodeur :
Réglage de Exemple Description

Protocole UDP SRT est basé sur le protocole UDP.

Source IP [Link] Il s'agit de l'adresse IP publique du pare-feu à la

source.

Port source 20000 Il doit correspondre au port source NAT sortant

du pare-feu à la source.

Guide de déploiement des SRT, v1.1, édition 01 17

 IP de destination [Link] ou En fonction de votre pare-feu, les règles NAT
[Link] peuvent être appliquées avant ou après les
règles de filtrage de paquets. Cela aura un impact
sur la définition des règles de filtrage. Si le
Si le NAT est appliqué avant, vous devez
spécifier l'adresse IP interne du Pare-feu B. Si le
NAT est appliqué après, vous devez spécifier
l'adresse IP publique du Pare-feu B.
Réglage de Exemple Description

Port de destination 30000 Il s'agit du port sur lequel le décodeur écoutera

(dstport).

Politique Accepter/Passer Permet aux paquets de passer librement entre la

source et la destination.

Voici un exemple de règle de filtrage de paquets pour le pare-feu B :

Étape 4 - Configuration du décodeur

Sur le décodeur (le périphérique de destination SRT), procédez comme suit :

1. En utilisant les paramètres du tableau ci-dessous, créez un flux d'entrée sur le décodeur
(le périphérique de destination SRT) :
Réglage de Exemple Description

Mode Auditeur Le décodeur attendra que l'appareil source lance la

session SRT.

Port de 30000 Il s'agit du port sur lequel le décodeur écoutera

destination (l'option
port vers lequel le pare-feu B transmettra les paquets
SRT). Si vous avez une règle de traduction NAT sur le
pare-feu B, le port de destination est le port vers lequel
la règle transmettra les paquets.l
Une fois que tous les paramètres ont été appliqués, l'encodeur et le décodeur s'accordent et
établissent une session SRT. L'encodeur envoie le flux vidéo au décodeur, qui traite le flux
et renvoie des paquets de contrôle comprenant des données sur la congestion, la latence et
d'autres statistiques. L'encodeur utilisera ces informations pour adapter sa transmission
(renvoi des paquets perdus, ajustement du débit binaire, etc.)

Guide de déploiement des SRT, v1.1, édition 01 18

Guide de déploiement des SRT, v1.1, édition 01 19
 Notes sur le pare-feu
• Si le port du périphérique source est attribué automatiquement, le pare-feu de la
source doit avoir une règle NAT sortante pour [port source] définie sur "any".
• Si le port du périphérique source est spécifié, la même valeur doit être utilisée dans la
règle NAT sortante.
• Si un pare-feu de destination possède une règle de filtrage qui fait correspondre un
port source avec une IP source, vous devez désactiver la réécriture des ports sortants
sur le pare-feu source. La désactivation de cette option permet au pare-feu source de
faire correspondre n'importe quel port du dispositif source SRT à un port unique et
prédéfini après l'application des règles NAT.
• En fonction de votre pare-feu, les règles NAT peuvent être appliquées avant ou après
les règles de filtrage de paquets. Cela aura une incidence sur la définition des règles de
filtrage. Si les règles NAT sont appliquées avant, vous devez spécifier l'adresse IP
interne du pare-feu. Si les règles NAT sont appliquées après, vous devez spécifier
l'adresse IP publique du pare-feu.

IMPORTANT Les sessions point à point à travers les pare-feu peuvent être réalisées en
sens inverse, le dispositif SRT source étant en mode Écoute et le dispositif SRT de
destination en mode Appelant.

Guide de déploiement des SRT, v1.1, édition 01 20

 Scénario 3 : Streaming en utilisant le mode Rendezvous

Scénario 3 : Streaming en utilisant le mode Rendezvous

Dans ce scénario, un codeur en mode Rendez-vous derrière un pare-feu et un décodeur,
également en mode Rendez-vous et derrière un pare-feu, établissent mutuellement une
session de diffusion SRT point à point sur Internet.

Réglage de Exemple Description

Protocole TS sur SRT SRT est basé sur le protocole UDP.

Mode Rendez-vous Encoder tentera d'initier la session SRT, et

écoutera les demandes de connexion SRT
entrantes.

Adresse [Link] Il s'agit de l'adresse cible du flux SRT, qui

est l'adresse IP publique du pare-feu à la
destination.

Source : 20000 Pour le mode Rendez-vous, les ports

Port source et destination sont les mêmes.

Destination 20000 Il s'agit du port sur lequel le décodeur sera

Port en écoute.

Guide de déploiement des SRT, v1.1, édition 01 21

 Étape 1 - Configuration de l'encodeur
En utilisant les paramètres du tableau ci-dessous, créez et démarrez un flux
de sortie sur l'encodeur (le périphérique source SRT) :

Guide de déploiement des SRT, v1.1, édition 01 22

 Scénario 3 : Streaming en utilisant le mode Rendezvous

Étape 2 - Configurer le(s) pare-feu(s)

- Assurez-vous que la réécriture des ports est désactivée dans les pare-feu situés entre les
périphériques source et de destination (c'est-à-dire que le mappage statique des ports
doit être autorisé). Dans ce scénario, par exemple, cela est nécessaire pour permettre à
l'encodeur et au décodeur d'établir une session SRT sur 20000.

Étape 3 - Configuration du décodeur

Sur le décodeur (le périphérique de destination SRT), procédez comme suit :

1. En utilisant les paramètres du tableau ci-dessous, créez un flux d'entrée sur le décodeur
(le périphérique de destination SRT) :
Réglage de Exemple Description

Protocole TS sur SRT SRT est basé sur le protocole UDP.

Mode Rendez-vous Le décodeur tentera d'initier la session SRT, et

écoutera les demandes de connexion SRT entrantes.

Adresse [Link] Il s'agit de l'adresse IP publique du pare-feu à la

source.
Port source 20000 En mode Rendez-vous, le port source doit être le même
que le port de destination.

Port de 20000 Il s'agit du port sur lequel l'encodeur écoutera.

destination

Guide de déploiement des SRT, v1.1, édition 01 23

 Une fois que tous les paramètres ont été appliqués, l'encodeur et le décodeur s'accordent et
établissent une session SRT. L'encodeur envoie le flux vidéo au décodeur, qui traite le flux
et renvoie des paquets de contrôle comprenant des données sur la congestion, la latence et
d'autres statistiques. L'encodeur utilisera ces informations pour adapter sa transmission
(renvoi des paquets perdus, ajustement du débit binaire, etc.)
Mode rendez-vous et pare-feu

Mode rendez-vous et pare-feu

Le mode rendez-vous permet au trafic SRT entre la source et la destination de traverser
un pare-feu sans qu'un administrateur informatique ait besoin d'ouvrir un port, pour autant
que les pare-feu soient "stateful".
Même si aucune règle n'autorise explicitement un périphérique SRT de destination à
communiquer avec le monde extérieur, ses paquets de contrôle pourront néanmoins revenir
au périphérique SRT source grâce à la fonction de "suivi des connexions" des pare-feu
dynamiques. Le mode Rendez-vous utilise ce comportement pour créer des "trous" à
travers les deux pare-feu.

Suivi des connexions

Les pare-feu dynamiques maintiennent une table de suivi des connexions, qui est construite
dynamiquement sur la base du trafic réel passant par le pare-feu.
Dans un tableau de suivi des connexions, une entrée typique pourrait consister en un
trafic UDP provenant d'un périphérique avec une IP source et un numéro de port, qui est
converti par NAT, puis connecté à l'IP publique d'un pare-feu sur ce port de destination :
Protocole Source Routeur Destination

UDP [Link]:20000 --> [Link]:20000 --> [Link]:20000

Si vous avez un appel entrant de l'autre extrémité, vous verrez la même entrée en sens
inverse dans le tableau de suivi des connexions :
Protocole Source Routeur Destination

UDP [Link]:20000 --> [Link]:20000 --> [Link]:20000

En général, un codeur démarre une session SRT en mode Caller, tandis qu'un décodeur en
mode Listener attend des paquets de contrôle. En mode Rendezvous, les deux envoient des
paquets de contrôle pour initier la session. Les paquets sortants créent une entrée dans la
table. Lorsque les paquets entrants arrivent, ils créent une entrée complémentaire. Le pare-
feu est ainsi amené à penser que les paquets entrants sont les réponses aux paquets sortants,
ce qui lui permet de laisser passer les paquets pendant la durée de la session de streaming.
Le mode Rendez-vous permet aux dispositifs source et de destination de "percer" des trous
à l'intérieur de leurs pare-feu respectifs. Les seules conditions sont que les deux dispositifs
doivent être en mode Rendez-vous, qu'ils doivent utiliser le même numéro de port et qu'une
entrée sortante doit être configurée sur chaque pare-feu afin que le numéro de port source
soit préservé (c'est-à-dire qu'il n'est pas nécessaire de créer des règles d'entrée).

Guide de déploiement des SRT, v1.1, édition 01 24

 Mode rendez-vous et pare-feu

Autres considérations
• Il est important que le numéro de port utilisé soit unique. L'utilisation de l'option d'un
pare-feu pour accepter n'importe quel port (éphémère) peut être problématique dans
un scénario où plusieurs encodeurs envoient des flux.
• Si le pare-feu de la source est configuré pour permettre au dispositif source d'utiliser
n'importe quel port (éphémère), la réécriture des ports sortants doit être désactivée
pour le mode Rendez-vous. L'attribution de port doit être statique pour que les
participants SRT puissent se rencontrer.
• Si le périphérique SRT source ou de destination se trouve derrière un pare-feu qui
n'autorise pas le trafic sortant, vous devrez configurer le pare-feu pour autoriser le
trafic sortant.
• Il existe encore des cas où il serait nécessaire (ou préférable) de configurer
manuellement les paramètres de l'appelant et de l'auditeur pour qu'ils traversent les
pare-feu à chaque extrémité. Par exemple, dans les environnements de haute sécurité
qui utilisent le "filtrage de sortie", les pare-feu sont souvent configurés pour empêcher
l'attribution de ports sortants arbitraires. Une adresse interne ne peut pas envoyer vers
un port de sortie aléatoire. Dans ce cas, les appareils source et de destination seraient
enregistrés auprès du pare-feu, qui bloquerait tout le reste.

Guide de déploiement des SRT, v1.1, édition 01 25

 Configuration des flux SRT

REMARQUE Cette section décrit comment configurer et régler un flux SRT. Pour plus de
détails sur la configuration d'un flux, veuillez vous reporter au guide de l'utilisateur de
votre appareil.
Le projet open source SRT ne contient pas d'éléments d'interface utilisateur web. À des fins
d'illustration, cette section contient des captures d'écran des produits SRT de Haivsion.

Contexte
Outre les paramètres standard associés à toute sortie en streaming, il existe d'autres valeurs
importantes que vous devez spécifier pour un flux SRT. Pour vous présenter ces
paramètres, prenons un exemple hypothétique d'un flux SRT envoyé à un périphérique de
destination, et voyons ce qui se passe au fil du temps.
Le schéma ci-dessous représente un flux envoyé sur un canal quelconque, tel qu'un réseau
local ou une connexion Internet, avec une certaine capacité. Les paquets envoyés par une
source sont stockés dans une mémoire tampon à la destination. Supposons qu'à un moment
donné, il y ait une défaillance totale de la liaison, puis, peu après, la connexion est rétablie.
Ainsi, pendant une courte période, la destination ne reçoit aucune donnée.

SRT traite de telles situations de deux manières. La première est que la destination s'appuie
sur son tampon pour maintenir la sortie du flux à son extrémité. La taille de ce tampon est
déterminée par le paramètre
Configuration d'un flux SRT

Guide de déploiement des SRT, v1.1, édition 01 26

 Réglage de la latence SRT. Une fois la liaison rétablie, la source peut recommencer à
envoyer des paquets, y compris les paquets perdus pendant la défaillance de la liaison.
Pour gérer cette "rafale" supplémentaire de paquets, un flux SRT prévoit une certaine
quantité de surcharge. Cette surcharge de bande passante est calculée de telle sorte que,
dans le pire des cas, la source puisse délivrer le nombre de paquets "perdus" pendant la
défaillance de la liaison (zone A) sur une "durée de rafale" (zone B), où la zone B doit être
égale à la zone A. La durée maximale pendant laquelle une rafale de paquets perdus peut
être maintenue sans provoquer d'artefact est la suivante :
Latence SRT (ms) * Surcharge de la bande passante (%) ÷ 100

Configuration d'un flux SRT

Une fois les appareils source et de destination configurés (y compris les modes d'appel
établis et les paramètres du pare-feu), suivez ces étapes pour configurer un flux SRT :

1. Mesurez le temps d'aller-retour (RTT) à l'aide de la commande ping.

• Si le ping ne fonctionne pas ou n'est pas disponible, configurez un flux SRT de
test et utilisez la valeur RTT de la page Statistiques.
• Si le RTT est <= 20 ms, alors utilisez 20 ms pour la valeur du RTT. En effet, le
SRT ne répond pas aux événements sur des échelles de temps inférieures à 20 ms.

2. Mesurez le taux de perte de paquets.

• Le taux de perte de paquets d'un canal détermine les calculs de latence SRT et
de surcharge de bande passante. Ce taux de perte peut être extrait de iperf stats.
• Si l'utilisation de iperf n'est pas possible, configurez un flux SRT de test, puis
utilisez les octets renvoyés / octets envoyés (comme indiqué sur la page de
statistiques du flux SRT) sur une période de 60 secondes pour calculer le taux
de perte de paquets comme suit :
Taux de perte de paquets = octets renvoyés ÷ octets envoyés *
100

3. En utilisant le tableau suivant*, trouvez les valeurs du multiplicateur RTT et de la

surcharge de la bande passante qui correspondent à votre taux de perte de paquets
mesuré :
Taux de perte dans RTT Surcharge de la Latence minimale du SRT
le pire des cas (%) Multiplicateur bande passante (pour RTT <= 20 ms)
(%)
<= 1 3 33 60

<= 3 4 25 80

<= 7 5 20 100

<= 10 6 17 120

* Ce tableau prend en compte la perte constante et la perte en rafale. Voir "Taux de

perte de paquets" à la page 28 pour plus d'informations.

Guide de déploiement des SRT, v1.1, édition 01 27

 4. Déterminez votre valeur de latence SRT en utilisant la formule suivante :
Latence SRT = Multiplicateur RTT * RTT
• Si RTT < 20, utilisez la valeur de latence SRT minimale dans le tableau ci-
dessus.
Configuration d'un flux SRT

5. Mesurez la capacité nominale du canal disponible pour le flux SRT en utilisant

l'utilitaire iperf.
- Si iperf ne fonctionne pas ou n'est pas disponible, configurez un flux SRT de test et
utilisez la valeur Max Bandwidth ou Path Max Bandwidth de la page Statistics.

6. Déterminez le débit binaire du flux.

• Le débit vapeur est la somme des débits d'essence de la vidéo, de l'audio et des
métadonnées, plus une surcharge du protocole SRT. Il doit respecter la contrainte
suivante :
Capacité du canal > Bande passante du flux SRT * (100 +
surcharge de la bande passante) ÷ 100
• Si cette valeur n'est pas respectée, le débit binaire de la vidéo, de l'audio et des
métadonnées doit être réduit jusqu'à ce qu'elle soit respectée.
• Il est recommandé d'ajouter une marge de manœuvre importante pour se prémunir
contre les variations de la capacité du canal, de sorte qu'une contrainte plus
prudente serait la suivante :
0,75 * capacité du canal > largeur de bande du flux SRT * (100 +
surcharge de la bande passante) ÷ 100

7. Déterminez si le flux SRT a été configuré correctement.

- La meilleure façon de le déterminer est de configurer un flux SRT de test et de
regarder le graphique du tampon d'envoi SRT sur la page des statistiques du
périphérique source. La valeur du tampon d'envoi ne doit jamais dépasser la limite
de la latence SRT. Si les deux courbes sont proches, augmentez la latence SRT.

Guide de déploiement des SRT, v1.1, édition 01 28

Paramètres SRT
Cette section décrit les différents paramètres qui ont un effet sur les performances d'un flux
SRT.

Durée du trajet aller-retour

Le temps d'aller-retour (RTT) est le temps que met un paquet pour aller d'une source à
une destination et inversement. Il fournit une indication de la distance (indirectement, le
nombre de sauts) entre les points d'extrémité d'un réseau. Entre deux dispositifs SRT sur
le même commutateur rapide d'un réseau local, le RTT devrait être presque nul. Sur le
territoire continental des États-Unis, le RTT sur Internet peut varier en fonction de la
liaison et de la distance, mais il peut se situer entre 60 et 100 ms. Le RTT transocéanique
peut être de 60 à 200 ms selon la route.
Le RTT est utilisé comme guide lors de la configuration de la surcharge de la bande
passante et de la latence. Pour connaître le RTT entre deux périphériques, vous pouvez
utiliser la commande ping. Par exemple :
ping [Link]
Réponse (RTT = 6,633 ms) :
56 octets de données 64 octets de [Link] : seq=1 ttl=64 time=6.633 ms
Vous pouvez également trouver le RTT pour une session de streaming SRT active affichée
sur la page des statistiques.

Multiplicateur RTT
Le multiplicateur RTT est une valeur utilisée dans le calcul de la latence SRT. Il reflète la
relation entre le degré de congestion d'un réseau et le temps d'aller-retour. Lorsque la
congestion du réseau augmente, le taux d'échange des paquets de contrôle SRT (ainsi que
la retransmission des paquets perdus) augmente également. Chacun de ces échanges est
limité par le RTT pour ce canal, et donc pour compenser, la latence SRT doit être
augmentée. Le facteur qui détermine cette augmentation est le multiplicateur RTT, tel
que :
Latence SRT = Multiplicateur RTT * RTT
Le multiplicateur RTT est donc une indication du nombre maximum de fois que le SRT
essaiera de renvoyer un paquet avant d'abandonner.

Taux de perte de paquets

Le taux de perte de paquets est une mesure de la congestion du réseau, exprimée en
pourcentage de paquets perdus par rapport aux paquets envoyés.

Guide de déploiement des SRT, v1.1, édition 01 29

 • La perte constante fait référence à la condition dans laquelle un canal perd des
paquets à un taux constant. Dans ce cas, l'overhead SRT est limité par une borne
inférieure, de telle sorte que :
Surcharge minimale de la bande passante = 1,65 * Taux de perte de
paquets
• La perte en rafale désigne la situation dans laquelle un canal perd plusieurs paquets
consécutifs, jusqu'à l'équivalent du contenu du tampon de latence de la SRT. Dans de
tels cas, le surdébit SRT est limité par une borne inférieure, de sorte que :
Surcharge minimale de la bande passante = 100 ÷ multiplicateur RTT
• Les pertes de burst qui durent plus longtemps que la latence SRT entraîneront des
artefacts de flux. La latence de la SRT doit toujours être réglée sur une valeur
supérieure à la période de perte de rafale la plus défavorable.

Surcharge de la bande passante

Les paquets de contrôle associés à un flux SRT occupent, bien entendu, une partie de la
bande passante disponible, tout comme les retransmissions de paquets média. Lorsque
vous configurez un flux SRT, vous devez spécifier une valeur de surcharge de la bande
passante pour tenir compte de ce facteur important.
La part du contenu audio et vidéo dans le flux est déterminée par leurs paramètres de débit
binaire respectifs, qui sont configurés sur les encodeurs audio et vidéo eux-mêmes. La
surcharge de la bande passante SRT est calculée en pourcentage du débit binaire A/V, de
sorte que la somme des deux représente un débit binaire seuil, qui est la bande passante
maximale que le flux SRT est censé utiliser.
La surcharge de la bande passante de la SRT est un pourcentage que vous attribuez, en
partie en fonction de la qualité du réseau sur lequel vous allez diffuser. Les réseaux plus
bruyants nécessiteront l'échange d'un plus grand nombre de paquets de contrôle, ainsi que
la réexpédition de paquets média, et donc un pourcentage plus élevé.

La surcharge de la bande passante SRT ne doit pas dépasser 50%. La valeur par défaut est de

Guide de déploiement des SRT, v1.1, édition 01 30

 Exemple de calcul de la surcharge de la bande passante
Disons que vous diffusez de la vidéo à un débit de 1000 kbps et de l'audio à 128 kbps. Cela
donne un total de 1128 kbps, que nous arrondirons à 1200 kbps pour tenir compte des
métadonnées et autres données auxiliaires. Il s'agit de la bande passante moyenne, qui est
calculée automatiquement en fonction de vos paramètres de sortie réels. Si vous acceptez
le paramètre par défaut Bandwidth Overhead de 25%, la bande passante totale réservée au
flux SRT sera de :
1200 + (25% * 1200) = 1500 kbps (1,5 Mbps)
Il s'agit de la bande passante maximale que SRT utilisera. S'il n'y a pas de perte, seule une
légère surcharge pour le contrôle est utilisée. Tant que cette bande passante SRT totale est
inférieure ou égale à la bande passante disponible entre les périphériques SRT source et
de destination, le flux devrait circuler de l'un à l'autre sans incident.

Latence
Il existe un délai associé à l'envoi de paquets sur un réseau (généralement imprévisible).
En raison de ce délai, un dispositif source SRT doit mettre en file d'attente les paquets
qu'il envoie dans un tampon pour s'assurer qu'ils sont disponibles pour la transmission et
la retransmission. À l'autre extrémité, un dispositif de destination SRT doit maintenir son
propre tampon pour stocker les paquets entrants (qui peuvent arriver dans n'importe quel
ordre) afin de s'assurer qu'il dispose des bons paquets dans la bonne séquence pour le
décodage et la lecture. La latence SRT est une valeur fixe (de 20 à 8000 ms) représentant
la taille maximale du tampon disponible pour la gestion des paquets SRT.
Les tampons d'un dispositif source SRT contiennent des paquets de flux non acquittés
(ceux dont la réception n'a pas été confirmée par le dispositif de destination).
Les tampons d'un périphérique de destination SRT contiennent des paquets de flux qui
ont été reçus et qui attendent d'être décodés.
La latence SRT doit être définie de manière à ce que le contenu du tampon du périphérique
source (mesuré en msecs) reste, en moyenne, inférieur à cette valeur, tout en veillant à ce
que le tampon du périphérique de destination ne soit jamais proche de zéro.
La valeur utilisée pour la latence SRT est basée sur les caractéristiques de la liaison
actuelle. Sur un réseau assez bon (0,1-0,2% de perte), une "règle empirique" pour cette
valeur serait de quatre fois le RTT. En général, la formule pour calculer la latence est la
suivante :
Latence SRT = Multiplicateur RTT * RTT
La latence SRT peut être définie à la fois sur la source SRT et les dispositifs de
destination. La plus élevée des deux valeurs est utilisée pour le flux SRT.

Guide de déploiement des SRT, v1.1, édition 01 31

Guide de déploiement des SRT, v1.1, édition 01 32
 Cryptage des flux SRT

Cryptage des flux SRT

Les flux SRT peuvent être chiffrés à l'aide d'algorithmes cryptographiques AES, puis
déchiffrés à leur destination. Pour mettre en œuvre le cryptage d'un flux SRT, vous devez
spécifier le type de cryptage sur le périphérique source, puis une phrase de passe sur la
source et la destination.

Cryptage Ce paramètre spécifie la longueur de la clé de chiffrement AES

(Advanced Encryption Standard) et le chiffre.
Gamme : AES-128, AES-256

Phrase de Il s'agit d'une chaîne de caractères utilisée pour générer le

passe wrapper de la clé de chiffrement AES via une fonction à sens
unique, de sorte que le wrapper de la clé de chiffrement utilisé ne
puisse pas être deviné à partir de la connaissance du mot de
passe.
Plage : 10-79 caractères imprimables UTF-8
Optimiser les performances de la SRT
Les dispositifs SRT source et destination échangent diverses informations sur les
conditions du réseau et le transfert de paquets, ce qui leur permet de négocier la meilleure
livraison possible du contenu audio/vidéo principal.

NOTE Le projet SRT open source contient toutes les fonctionnalités sous-jacentes
nécessaires pour créer une représentation graphique de cet échange, qui pourrait ensuite
être mise à disposition à partir de l'interface web de tout dispositif SRT.
Le suivi et la compréhension des données statistiques peuvent vous aider à régler et à
optimiser les performances de votre streaming SRT.
À titre d'illustration, les paragraphes suivants décrivent les différentes sections de
l'Accord.

Guide de déploiement des SRT, v1.1, édition 01 33

 Page de statistiques utilisant les images d'un échange SRT entre un encodeur Makito X
(source) et un décodeur Makito X (destination). Ces images sont destinées à montrer
comment, en comparant les sections correspondantes entre les dispositifs SRT source
et destination, vous pouvez déterminer les caractéristiques de performance et identifier
les possibilités d'optimisation du flux.

Statistiques
La section Statistiques donne un aperçu de l'état d'un flux SRT : son état actuel, les paquets
et les octets envoyés et reçus, le débit binaire actuel et (dans le cas du périphérique source),
la durée d'activité du flux.
Makito X Encoder (dispositif source SRT) Makito X Decoder (dispositif de destination
SRT)

Src Dest Paramètre Description

X État L'état de fonctionnement actuel du flux (STREAMING,

ARRÊTÉ, CONNECTÉ, ÉCOUTÉ, SÉCURISÉ,
SCRAMBLED, ou PAUSED)

X Temps de montée La durée pendant laquelle le flux est activement diffusé (par
ex,
1d22h5m41s) ; disponible uniquement lorsque l'état est
STREAMING.
X Paquets envoyés Nombre de paquets UDP envoyés pour ce flux.

X Octets envoyés Nombre d'octets envoyés pour ce flux.

Guide de déploiement des SRT, v1.1, édition 01 34

 X Paquets non envoyés Nombre de paquets UDP non envoyés pour ce flux (affiché
uniquement si différent de 0).

X Octets non envoyés Nombre d'octets non envoyés pour ce flux (affiché
uniquement s'il est différent de 0).

X Paquets reçus Nombre de paquets UDP reçus pour ce flux.

X Octets reçus Nombre d'octets reçus pour ce flux.

X Dernière erreur La dernière erreur signalée par le sous-système SRT. Toutes

les erreurs sont enregistrées dans un fichier journal (voir
"Journaux SRT" à la page 41).
X Survenu Le temps écoulé depuis que la dernière erreur a été
signalée.
X Adresse de la source Adresse IP du dispositif source SRT

X X Bitrate Le débit binaire du flux (en kbps).

X X Réinitialiser Cliquez pour réinitialiser la page des statistiques.

Ce qu'il faut rechercher :

-Vérifiez que l'état de la connexion n'est pas SCRAMBLED ou STOPPED.
SRT
La section SRT fournit un aperçu détaillé du trafic SRT.
Makito X Encoder (dispositif source SRT) Makito X Decoder (dispositif de destination
SRT)

Guide de déploiement des SRT, v1.1, édition 01 35

 Src Dest Paramètre Description

X X Reconnexions Nombre de reconnexions depuis le début du flux. Un

encombrement important du réseau peut entraîner une
interruption de la connexion, mais celle-ci sera
automatiquement reconnectée.
X Cryptage AES Indique l'état du cryptage AES (s'il est activé)

X Longueur de la clé Indique la longueur de clé spécifiée pour le cryptage AES.

X Décryptage par les Indique si le flux SRT est décrypté avec succès ou non.
pairs

X Décryptage Indique si le flux SRT est décrypté avec succès ou non.

X Renvoyer les Nombre de paquets retransmis en fonction des rapports du

paquets périphérique de destination (ou de son absence).

X Octets renvoyés Total des octets retransmis.

X Paquets Nombre de paquets déclarés manquants par le périphérique de

abandonnés destination. Il s'agit du nombre brut de paquets abandonnés
par le réseau. Ces paquets peuvent être récupérés par
retransmission par le périphérique source, et n'entraînent donc
pas nécessairement d'artefacts vidéo.

Src Dest Paramètre Description

X Octets abandonnés Nombre d'octets abandonnés.

X Paquets perdus Nombre de paquets signalés manquants par le décodeur.

X Paquets oubliés Les paquets qui sont arrivés trop tard au dispositif de
destination, ou qui ne sont jamais arrivés du tout. Si le "temps
de lecture" d'un paquet est écoulé et qu'il n'est pas arrivé au
décodeur ou qu'il arrive après que le contenu auquel il est
associé a déjà été lu, ce paquet est signalé comme "sauté" sur
le périphérique de destination. Cela se traduit généralement
par un type d'artefact vidéo (une image rejouée ou un blocage
vidéo).
X ACKs reçus Nombre total de paquets d'accusé de réception et de
rétroaction reçus du dispositif de destination (il s'agit d'une
mesure de la progression de la transmission).

X NAKs reçus Nombre total de paquets d'accusé de réception négatifs reçus

du dispositif de destination.

Guide de déploiement des SRT, v1.1, édition 01 36

 X Largeur de bande Estimation de la largeur de bande maximale disponible, vue
de liaison depuis le périphérique de destination.

X Bande passante Largeur de bande maximale utilisée par le dispositif source

maximale pour ce flux SRT (c'est-à-dire le total actuel du débit binaire
audio/vidéo plus les données auxiliaires plus la surcharge de la
bande passante SRT).
X Largeur de bande La même valeur que Link Bandwidth. Le périphérique de
maximale du chemin destination envoie la valeur au périphérique source avec un
paquet d'accusé de réception.

X X RTT Le temps d'aller-retour (RTT) est le temps nécessaire à un

paquet pour aller d'une source spécifique à une destination
spécifique et inversement.
Src Dest Paramètre Description

X X Tampon Taille du tampon SRT (en millisecondes).

Les tampons du dispositif source SRT contiennent des
paquets de flux non acquittés (ceux dont la réception n'a pas
été confirmée par le décodeur). La taille de la mémoire tampon
du dispositif source, en l'absence de congestion ou de perte
de paquets, se situe autour de la valeur RTT. En présence
d'une perte de paquets récupérable, la valeur devrait se situer
entre celles du RTT et de la latence.
Le tampon du dispositif de destination SRT contient les
paquets de flux reçus et en attente d'être transmis ou décodés.
Cette statistique montre la portion du tampon du dispositif de
destination jusqu'au premier paquet manquant (c'est-à-dire le
temps restant pour transmettre le paquet manquant avant qu'il
ne soit trop tard). La valeur du tampon du périphérique de
destination en l'absence de perte de paquets est juste en
dessous de la valeur de latence. En présence de perte de
paquets, elle se situe entre 0 et la valeur de latence.
Notez que si vous modifiez le débit binaire de 6 à 2 Mb/s, le
nombre d'octets changera mais un tampon de 2 secondes
restera de 2 secondes.
X X Latence Une valeur fixe (de 20 à 8000 ms) représentant la taille
maximale du tampon disponible pour la gestion des paquets
SRT.
Les valeurs peuvent être saisies à la fois sur les dispositifs
source et destination. Lorsque la poignée de main se produit
au début d'une session de diffusion SRT, la plus élevée des
deux valeurs est mise en œuvre sur les deux appareils. La
valeur par défaut de la destination est fixée au minimum (20
ms) afin que la valeur puisse être contrôlée depuis la source.
La valeur de latence par défaut sur la source est de 125 ms.
Ce qu'il faut rechercher :
• Si vous commencez à voir beaucoup de reconnexions, cela indique qu'il y a un
problème avec le canal de communication entre les appareils.

Guide de déploiement des SRT, v1.1, édition 01 37

 • Un nombre de NAK en constante augmentation indique un problème.
• Il est normal de voir quelques paquets abandonnés, mais il ne doit pas y en avoir trop.
Un faible nombre de paquets abandonnés indique que vous utilisez votre bande
passante de manière optimale.
• Si le nombre de paquets sautés augmente lentement, la meilleure chose à faire est
d'augmenter la latence SRT. S'il augmente par bonds importants, la meilleure chose à
faire est de réduire le débit vidéo ou d'augmenter le pourcentage de surcharge de la
bande passante si vous disposez de la capacité nécessaire.

CONSEIL Lorsque vous ajustez les paramètres SRT, ignorez les pics ou autres variations
qui apparaissent sur les graphiques de statistiques au moment de la modification.
Retards
La section Délais fournit un aperçu graphique de la façon dont les tampons de flux SRT
gèrent le trafic.
Makito X Encoder (dispositif source SRT) Makito X Decoder (dispositif de destination
SRT)

Src Dest Paramètre Description

X X Dernières X minutes Choisissez un intervalle de temps (5 minutes, 60 minutes

ou 24 heures).
pour les données à afficher dans les graphiques DELAIS
et LARGEUR DE BANDE UTILISÉE.
X X Télécharger le fichier Cliquez pour télécharger un fichier CSV.
CSV
X Tampon d'envoi du Cochez cette case pour afficher un graphique du contenu
codeur (en ms) du tampon de l'encodeur en fonction du temps
(ligne bleue dans le graphique).

Guide de déploiement des SRT, v1.1, édition 01 38

 X Décodeur Tampon de Cochez cette case pour afficher un graphique du contenu
réception (en ms) du tampon du décodeur en fonction du temps
(ligne bleue dans le graphique).
X X Durée du trajet aller- Cochez cette case pour afficher un graphique de la valeur
retour RTT dans le temps (ligne blanche dans le graphique).

X X Latence Cochez cette case pour afficher un graphique de la valeur

de la latence dans le temps (ligne orange dans le
graphique).
Ce qu'il faut rechercher :
• La valeur de Buffer (ligne bleue) sur le périphérique source ne doit normalement pas
dépasser la valeur de Latency (ligne orange). Si la mémoire tampon d'envoi du codeur
dépasse la ligne de latence, augmentez la latence de la SRT. Vous pouvez observer des
pics occasionnels (avec des anomalies correspondantes à l'écran). Mais si ceux-ci sont
peu nombreux et que l'impact sur l'affichage du flux est tolérable, vous pouvez choisir
d'ignorer ces pics lorsque vous réglez les paramètres du flux.
• Idéalement, le niveau de tampon du périphérique de destination devrait être juste en
dessous de la valeur de latence. Si la mémoire tampon de réception du décodeur passe
souvent à 0, il est fort probable que la mémoire tampon du périphérique de destination
est insuffisante.
pour supporter le débit binaire souhaité (qui doit donc être réduit). Si le tampon de
réception du décodeur ne passe qu'occasionnellement à 0, alors la latence SRT doit
être augmentée.
• Sur le périphérique source, si le tampon d'envoi de l'encodeur atteint ou dépasse
souvent la valeur de latence, il est fort probable que la bande passante est insuffisante
pour supporter le débit binaire souhaité (qui doit donc être réduit). Si le tampon d'envoi
de l'encodeur n'atteint ou ne dépasse qu'occasionnellement la valeur de latence, la
latence SRT doit être augmentée.

Bande passante utilisée

La section Bande passante utilisée donne un aperçu graphique de la façon dont la bande
passante du réseau disponible pour le flux SRT est effectivement utilisée, en termes de
taux d'envoi, de réception, de renvoi et de perte de paquets, ainsi que de volume de données
(taux × temps).
Makito X Encoder (dispositif source SRT) Makito X Decoder (dispositif de destination
SRT)

Guide de déploiement des SRT, v1.1, édition 01 39

 Src Dest Paramètre Description

X Taux d'envoi Cochez cette case pour afficher un graphique du débit

binaire sortant du dispositif source SRT en fonction du
temps (ligne bleue dans le graphique).
X Taux de réception Cochez cette case pour afficher un graphique du débit
binaire entrant du périphérique de destination SRT en
fonction du temps (ligne bleue dans le graphique).
X Taux de retransmission Cochez cette case pour afficher un graphique de la
vitesse à laquelle le dispositif source SRT renvoie des
paquets (ligne orange dans le graphique).

X Taux de perte Cochez cette case pour afficher un graphique du taux

auquel le dispositif source SRT rapporte les paquets
perdus (ligne orange dans le graphique).

X X Largeur de bande de Cochez cette case pour afficher un graphique de la bande

liaison passante disponible pour le flux SRT (ligne blanche dans
le graphique). Il s'agit d'un tracé de la bande passante de
liaison (ou de la bande passante de chemin maximale
équivalente sur le périphérique source) affichée dans le
panneau SRT.
Ce qu'il faut rechercher :
• L'utilisation du cryptage a un impact sur les ressources de traitement du dispositif
source, ce qui peut avoir un effet sur la capacité globale de diffusion en continu.
• Si le périphérique de destination SRT présente trop d'images sautées ou abandonnées,
augmentez la latence SRT, réduisez le débit vidéo et/ou augmentez le pourcentage de
surcharge de la bande passante.

Guide de déploiement des SRT, v1.1, édition 01 40

 Graphique des taux d'échantillonnage

Graphique des taux d'échantillonnage

Les informations présentées dans les graphiques de la page Statistiques sont basées sur
des échantillons continus prélevés toutes les 5 secondes sur une période de 24 heures
(l'échantillonnage n'a pas lieu pendant les pauses ou les déconnexions).
Les données sont affichées en 60 ou 120 colonnes (selon la période affichée), où chaque
colonne représente une valeur moyenne basée sur la période affichée.
Nombre de colonnes (points de données)
Graphique Time Span
affichées
5 dernières minutes 60

Dernières 60 minutes 60

Dernières 24 heures 120

Par exemple, si le graphique présente les données des 5 dernières minutes (300 secondes),
il contiendra 300 ÷ 5 sec. = 60 échantillons sur 60 colonnes (ce qui correspond à un
échantillon par colonne).
Si le graphique présente les données des dernières 24 heures (86400 secondes), il
contiendra 86400 ÷ 5 sec. = 17280 échantillons répartis sur 120 colonnes. Chaque colonne
contient la valeur moyenne de 144 échantillons (17280 ÷ 120).
Journaux de bord SRT

Journaux de bord SRT

Les données associées à un flux SRT sont enregistrées en continu (un journal par flux). Le
fichier journal contient des entrées horodatées à des intervalles de 5 secondes pour un
maximum de 24 heures. L'échantillonnage est non-contigu (aucune entrée de journal n'est
effectuée lorsque le flux est inactif). Par exemple, le journal peut contenir des données
couvrant 4 jours, mais seulement pendant 6 heures par jour.
À partir de la page Statistiques, vous pouvez télécharger le fichier journal au format CSV,
qui peut être utilisé avec des applications telles que Microsoft Excel ou un logiciel tiers
d'analyse des journaux. Il peut être utile d'examiner les journaux pour faciliter le
dépannage, ou pour déterminer comment la bande passante disponible est utilisée au fil du
temps, ce qui peut vous permettre de mieux contrôler les coûts associés.
Le tableau ci-dessous montre un exemple de journal avec quelques lignes de données :
DateTime Taux ReSnRate Taux de MaxBw DisponibleBw RTT SendBufs PdDelay
d'envoi chute
2016-06-09T[Link]-0400 3479 0 0 4226 140504 74.417 72 125

Guide de déploiement des SRT, v1.1, édition 01 41

2016-06-09T[Link]-0400 3334 0 0 4226 155224 74.304 77 125

2016-06-09T[Link]-0400 3385 0 0 4226 92273 74.514 87 125

2016-06-09T[Link]-0400 3377 0 0 4226 66601 74.248 91 125

2016-06-09T[Link]-0400 3493 0 0 4226 56608 74.204 81 125

2016-06-09T[Link]-0400 3358 0 0 4226 156397 74.214 73 125

2016-06-09T[Link]-0400 3391 0 0 4226 176659 74.338 73 125

2016-06-09T[Link]-0400 3397 0 0 4226 302024 74.512 70 125

2016-06-09T[Link]-0400 3460 0 0 4226 72274 74.341 97 125

2016-06-09T[Link]-0400 3334 0 0 4226 51725 74.264 43 125

ANNEXE A : Informations complémentaires

Questions fréquemment posées

Quelle est la structure sous-jacente du protocole SRT ?
Le SRT est basé sur le protocole UDP (User Datagram Protocol), mais il possède ses
propres mécanismes pour assurer la diffusion en temps réel de flux de médias sur des
réseaux bruyants, comme l'Internet.

Quels sont les ports qui doivent être ouverts par un pare-feu ?
Les ports UDP des périphériques source et destination sont configurables. Chaque
flux ne nécessite qu'un seul port. Le port est défini par l'utilisateur et peut être compris
entre 1025 et 65 535. Les exigences spécifiques en matière de port pour les pare-feu
peuvent dépendre des politiques de sécurité de votre organisation. Consultez votre
administrateur système réseau.

Quelle est la bande passante requise pour une connexion traversant l'Internet ?
BW Overhead spécifie la surcharge maximale de la bande passante du flux qui peut
être utilisée pour la récupération des paquets perdus. La valeur par défaut de BW
Overhead est de 25%. En fonction de vos paramètres, SRT retransmettra les paquets
perdus soit rapidement (utilisant ainsi plus de bande passante), soit sur une période
plus longue (nécessitant moins de bande passante mais entraînant une latence plus
élevée).

Comment le cryptage affecte-t-il la bande passante ?

Guide de déploiement des SRT, v1.1, édition 01 42

 Le cryptage n'affecte pas la bande passante. Cependant, l'application du cryptage est
une tâche exigeante pour le processeur et peut avoir un impact sur le nombre et le
débit binaire des flux qu'un encodeur est capable de produire.

La SRT est-elle compatible avec les réseaux sans fil ?

La SRT peut être utilisée sur des réseaux sans fil, des WiMAN (Wireless Metro Area
Networks), des LAN, des WAN privés ou l'Internet public.

Le nombre de "paquets perdus" augmente-t-il même lorsqu'une retransmission SRT est

réussie ? Les paquets perdus peuvent-ils entraîner des artefacts visuels ou des
problèmes de qualité ?
Les "paquets perdus" et les "paquets sautés" correspondants sont des statistiques
rapportées par un décodeur SRT :
Paquets perdus : Un trou dans la séquence de paquets a été détecté. Une demande
de retransmission du paquet perdu a été envoyée au dispositif source. Ce paquet
perdu peut (ou ne peut pas) être récupéré par la demande de retransmission.

Guide de déploiement des SRT, v1.1, édition 01 43

 Paquets manqués : Le moment de lire le paquet est arrivé et le paquet perdu n'a pas
été récupéré, le décodeur va donc continuer la lecture sans lui. Un artefact vidéo ou
audio peut résulter d'un paquet sauté.

Comment puis-je déterminer les besoins en bande passante SRT d'un décodeur vers un
encodeur ?
Les paquets de contrôle du canal arrière SRT, du décodeur au codeur, occupent un
minimum de ~40 Kbps de bande passante lorsque les conditions du canal sont
parfaites. S'il y a des paquets perdus sur la liaison, le décodeur SRT génère un trafic
de signaux plus important, proportionnel au taux de paquets perdus. Un seul paquet
perdu consommera environ 400 bps de la bande passante disponible du côté du
décodeur.
Du décodeur au codeur, l'utilisation de la bande passante augmente linéairement avec
le taux de perte de paquets.

Comment puis-je déterminer la bande passante disponible entre deux points

d'extrémité avant de lancer un flux SRT ?
Si vous avez établi un flux SRT, vous pouvez visualiser les informations relatives à la
bande passante dans les statistiques des périphériques source et de destination.
Si aucun flux SRT n'est en cours d'exécution, vous pouvez utiliser l'utilitaire de
mesure de la bande passante Iperf pour obtenir des informations sur la bande passante
et la gigue. Vous devez spécifier le numéro de port et arrêter tout flux avant d'utiliser
Iperf (pour libérer les ports).

Sur le périphérique de destination, assurez-vous que tous les flux sont arrêtés, puis
entrez les commandes suivantes :
iperf -s -u -i 1 -p "port#"

où "port#" est le même que le port ouvert sur le pare-feu. Le paramètre "-u"
spécifie l'utilisation de paquets UDP (l'utilisation de TCP ferait baisser la valeur de la
bande passante disponible mesurée).
Sur le périphérique source, assurez-vous que tous les flux sont arrêtés, puis entrez les
commandes suivantes :
iperf -c "ADRESSE IP DE LA DESTINATION" -u -b "BW" -i 1 -p "Port#".

où "BW" est la largeur de bande appropriée en Mbps, et "ADRESSE IP DE

DESTINATION" est l'adresse IP du dispositif de destination (utilisez l'adresse IP
publique si vous traversez des pare-feu).
Exemple : iperf -c [Link] -u -b 5.5m -i 1
-p 20000

Résultat :
0,0-10,1 sec 6,50 MBytes 5,41 Mbits/sec 0,247 ms 38/ 4678 (0,81%)

Guide de déploiement des SRT, v1.1, édition 01 44

 où 5,41 Mbits/seconde est la largeur de bande réelle, 0,247 ms est la gigue, et 0,81%
est le pourcentage de paquets perdus.
Notez que lorsque vous utilisez Iperf dans une configuration client/serveur UDP, le
"serveur" écoute les connexions des clients, mais c'est le "client" qui génère le trafic.

Puis-je streamer d'un encodeur vers plusieurs décodeurs ?

Non. Le SRT est destiné aux connexions point à point. Il ne prend pas en charge la
multidiffusion. Si vous avez besoin qu'un flux SRT soit distribué à plusieurs
décodeurs, vous pouvez utiliser un serveur passerelle.

Je vois un motif en "dents de scie" sur la page des statistiques de mon codeur. Qu'est-ce
que cela signifie ?
Cela signifie que le décodeur n'accuse pas réception des paquets envoyés par
l'encodeur. Le codeur conserve les paquets qu'il a envoyés dans sa mémoire tampon
jusqu'à ce qu'il reçoive une réponse (cela prend au moins l'équivalent du temps
d'aller-retour). Si l'encodeur reçoit rapidement des accusés de réception du décodeur,
le tampon reste relativement vide. Dans le cas contraire, le tampon se remplit
progressivement jusqu'à ce qu'il atteigne un point où il doit abandonner les paquets
non acquittés, créant ainsi le motif caractéristique en dents de scie.
Cela se produit généralement lorsque vous n'avez pas assez de bande passante pour
transmettre. La valeur de la mémoire tampon augmente jusqu'au point où elle ne peut
plus suivre, puis elle diminue selon un schéma classique en dents de scie. Dans ce
cas, essayez d'augmenter l'overhead SRT, ou de diminuer le débit binaire de votre
vidéo.

Que signifie le fait que la ligne bleue passe en dessous de la ligne blanche sur la page
des statistiques de mon décodeur ?
Le décodeur dispose d'un tampon (ligne bleue) qu'il utilise pour conserver ce qu'il a
reçu afin de laisser le temps de retransmettre les paquets manquants. Normalement, le
contenu de ce tampon (mesuré en millisecondes) doit se situer entre la latence (ligne
orange) configurée pour le flux SRT, et la valeur du temps de parcours (ligne blanche).
S'il tombe en dessous du RTT, cela signifie que le décodeur n'a pas de paquets à lire,
et pas assez de temps pour en demander d'autres. La sortie vidéo sera donc un écran
noir. Il se peut que l'encodeur n'ait pas donné de paquets au décodeur, ce qui indique
un problème à la source ou dans le réseau intermédiaire. Mais c'est peut-être
simplement parce qu'il n'y a rien à afficher.

Quand dois-je commencer à m'inquiéter d'un nombre croissant de paquets abandonnés

?
Si le débit augmente constamment, cela signifie que vous n'avez pas configuré
suffisamment de bande passante ou de latence. Vérifiez que vous ne dépassez pas trop
la valeur de latence de l'encodeur.

Guide de déploiement des SRT, v1.1, édition 01 45

 Et les paquets sautés sur le décodeur ?
Parfois, un paquet arrive au décodeur avant l'heure et se trouve dans la file d'attente,
prêt à être joué. Mais le paquet qui devrait être joué immédiatement avant arrive en
retard (ou jamais), alors le décodeur ignore le paquet qui se trouve dans la file
d'attente. En d'autres termes, le temps de lecture du paquet associé est passé, et soit il
n'est pas arrivé au décodeur, soit il arrive après que le contenu associé ait déjà été lu.
En général, cela signifie qu'un certain type d'artefact vidéo se produit également (une
image rejouée ou des artefacts de blocage vidéo).
On peut considérer qu'un paquet sauté est un paquet que le décodeur laisse tomber,
sauf qu'il ne le dit pas à l'encodeur. Le décodeur envoie un ACK positif, même si le
paquet est "perdu" du point de vue du décodeur. Il peut abandonner une trame entière
parce qu'elle est corrompue, mais l'encodeur ne le sait pas. En effet, lorsque les choses
vont mal, la dernière chose que vous voulez faire est d'augmenter le trafic de la
poignée de main. Un paquet a un certain temps de vie, et s'il n'est pas lu après ce
temps, il est ignoré.
Il se peut que le nombre de paquets ignorés augmente sur le décodeur, sans effet
correspondant sur le nombre de paquets abandonnés sur l'encodeur. Si le nombre de
paquets ignorés sur le décodeur augmente lentement, vous devez augmenter la latence
SRT. Si le nombre de paquets ignorés sur le décodeur augmente par bonds importants,
la meilleure chose à faire est de réduire le débit vidéo ou d'augmenter le pourcentage
de surcharge de la bande passante si vous disposez de la capacité nécessaire.

Est-ce que je contrôle la valeur de la latence à la source ou à la destination ?

Vous pouvez contrôler la latence, le débit binaire et le pourcentage d'overhead sur le
périphérique source. Mais vous pouvez également configurer la latence sur le
périphérique de destination. Les deux appareils se mettront d'accord sur la valeur
maximale.

Comment puis-je décider d'augmenter la latence ou de diminuer le débit binaire ?

Vous devez décider ce qui est le plus important pour vous : la qualité ou la latence. Si
une faible latence est plus importante pour vous, vous constaterez peut-être que vous
n'utilisez pas votre bande passante aussi efficacement et que la qualité de l'image n'est
pas optimale. Si vous voulez plus de qualité, vous devez utiliser le maximum de bande
passante disponible, avec un minimum de surcharge, et donc plus de latence. Une
transmission SRT nécessite soit de la bande passante, soit du temps. Ainsi, si vous
utilisez votre bande passante maximale à un débit binaire plus élevé parce que vous
voulez une meilleure qualité, vous devrez prévoir plus de temps pour récupérer les
erreurs.

Que se passe-t-il si je fixe une valeur de latence trop basse ?

Si le paramètre de délai/latence est trop faible, vous verrez des lignes bleues (tampon
d'envoi) dépasser la ligne orange (latence) dans le graphique sur l'encodeur. Cela se

Guide de déploiement des SRT, v1.1, édition 01 46

 reflétera à la destination sous forme d'artefacts visibles, correspondant à des paquets
sautés sur le décodeur.

Si je vois mon tampon d'envoi augmenter régulièrement d'une ou deux secondes, de

combien dois-je augmenter ma latence ?
Dans les premières versions de SRT, la tolérance était faible. Les valeurs du tampon
d'envoi devaient rester inférieures à la latence pour obtenir de bons résultats. Avec la
version la plus récente de la SRT, le tampon d'envoi peut parfois dépasser une seconde
sans être abandonné. Cependant, cela peut poser un problème à l'autre extrémité, car
bien que les paquets soient affichés comme "livrés" sur l'encodeur, ils peuvent ne pas
arriver à l'autre extrémité.

La SRT prend-elle en charge la correction d'erreur avant Pro-MPEG ?

Non, la SRT ne prend pas en charge la récupération des erreurs PRO-MPEG pour le
moment. Son mécanisme de récupération d'erreur est basé sur des demandes de
retransmission, sous la forme de paquets NAK (Negative Acknowledgement). Le
dispositif de destination renvoie des NAK au dispositif source chaque fois que des
paquets manquants sont détectés. Le dispositif source répond en retransmettant les
paquets identifiés dans les NAK.

Que sont les paquets "keep alive" ?

Pour maintenir une connexion SRT, les paquets de contrôle doivent être envoyés à
un intervalle de 10 ms (max). Lorsqu'un périphérique de destination reçoit un paquet
média, il accuse réception en renvoyant un paquet de contrôle "ack". Si l'intervalle
entre les paquets "ack" est supérieur à 10 ms, des paquets "keep alive" sont envoyés
pour maintenir la connexion ouverte.
Notez que, contrairement au TCP, si une connexion SRT est rompue, le dispositif
source ne saura pas que la destination ne reçoit pas de paquets pendant plusieurs
secondes avant que la connexion ne soit rétablie.

Pour plus d'informations, veuillez consulter le site

[Link].

Guide de déploiement des SRT, v1.1, édition 01 47

 Termes et définitions

Termes et définitions
Les termes suivants sont utilisés dans ce guide :
Terme Abréviation Description

Bande passante BW Le débit d'échange de données (mesuré en bps, Kbps ou Mbps)

d'un canal de communication, tel qu'un flux SRT.

Surcharge de la La portion de la largeur de bande totale d'un flux qui est requise
bande passante pour l'échange de paquets de contrôle et de récupération SRT.
Cette valeur est généralement calculée en pourcentage du débit
de sortie de base (TS) d'un codeur (vidéo + audio + métadonnées
+ données auxiliaires). La somme du débit de sortie de base et de
la surcharge de la bande passante détermine la bande passante
maximale qui peut être utilisée par le protocole SRT.
Gigue La gigue (mesurée en millisecondes) est l'écart indésirable par
rapport à la périodicité réelle d'un signal supposé périodique en
électronique et en télécommunications, souvent par rapport à une
source d'horloge de référence. Dans un contexte de réseau
informatique, la gigue est la variation de la latence, mesurée par
la variabilité dans le temps de la latence des paquets sur un
réseau.
Réseau local LAN Un réseau informatique qui interconnecte les ordinateurs dans
une zone limitée, comme un immeuble de bureaux.

Latence Le temps qui s'écoule entre la capture et l'affichage d'une image

vidéo, y compris le temps nécessaire au codage, à la transmission
et au décodage. Avec la SRT, la latence est un paramètre qui peut
être ajusté pour augmenter les tampons à la source et à la
destination afin de permettre à ces dispositifs de s'adapter aux
conditions du réseau.
Traduction NAT Une fonctionnalité qui permet de remapper une adresse IP à une
d'adresses de autre. La traduction d'adresses réseau permet à un dispositif, tel
réseau qu'un routeur ou un pare-feu, de rediriger le trafic entre l'Internet
et un réseau privé.
Perte de paquets La perte de paquets se produit lorsque des paquets de données
n'atteignent pas leur destination. Elle peut être causée par un
certain nombre de facteurs, notamment la dégradation du signal
sur un réseau, l'encombrement des canaux, la corruption, un
matériel réseau défectueux, des pilotes réseau défectueux ou des
routages normaux (tels que le DSR, Dynamic Source Routing,
dans les réseaux ad hoc). La perte de paquets est mesurée en
pourcentage de paquets perdus par rapport aux paquets envoyés.
Variation du PDV La variation du délai des paquets est la différence du délai
retard des unidirectionnel de bout en bout entre des paquets sélectionnés
paquets dans un flux, les paquets perdus étant ignorés. [RFC 3393]

Guide de déploiement des SRT, v1.1, édition 01 48

Durée du voyage RTT Également appelé délai d'aller-retour, le RTT (mesuré en
aller-retour millisecondes) est le temps nécessaire à un paquet pour aller
d'une source spécifique à une destination spécifique et
inversement.
Termes et définitions

Transport sécurisé SRT Une technologie de transport développée par Haivision qui
et fiable optimise les performances du streaming sur des réseaux
imprévisibles tels qu'Internet.

Privé virtuel VPN Mécanisme permettant de se connecter à un réseau privé via un

Réseau réseau public tel qu'Internet. Le plus souvent, un VPN est utilisé
pour fournir un tunnel sécurisé et crypté par lequel un utilisateur
distant (autorisé) peut accéder à un réseau d'entreprise.
 A propos de l'Alliance SRT

A propos de l'Alliance SRT

La mission de l'Alliance SRT est de soutenir la mise à disposition gratuite du protocole de
transport vidéo SRT open-source afin d'accélérer l'innovation par le biais du
développement collaboratif. En outre, l'Alliance SRT promouvra la reconnaissance et
l'adoption par l'ensemble de l'industrie du protocole SRT en tant que norme commune et
de facto pour tous les flux Internet à faible latence.
L'un des objectifs importants de l'Alliance SRT est de mettre de nouvelles fonctionnalités à
la disposition de la communauté open source, qu'elles soient soumises pour inclusion par les
développeurs de la communauté ou qu'elles proviennent directement des équipes de
développement de Haivision ou Wowza. Les fonctionnalités SRT open source contribuées
par la communauté seront disponibles pour tout développeur, et les nouveaux
développements des membres de l'Alliance SRT seront régulièrement réintégrés dans les
SRT open source.
Si vous souhaitez contribuer à cette initiative et rejoindre l'alliance SRT, veuillez contacter
l'alliance à l'adresse info@[Link].

Guide de déploiement des SRT, v1.1, édition 01 50

[Link]