Chapitre 3.

Techniques de
synchronisation multimédia

1
 Introduction
De nouvelles applications apparaissent sur Internet
comme la vidéo à la demande, la téléphonie sur IP,
la vidéoconférence, etc. Ces applications ont une
particularité : elles sont temps réel. L'Internet actuel
est basé sur le Best-Effort, c'est-à-dire que dans un
routeur les paquets sont traités dans l'ordre d'arrivée.
Ce mécanisme est insuffisant pour répondre aux
exigences des applications temps réel, qui souffrent
de trop grands délais et qui nécessitent beaucoup de
bande passante.

2
Souvent, ces applications font intervenir plusieurs
personnes, connectées sur des machines différentes,
qui peuvent interagir entre elles. Lorsque le nombre
de machines est grand, cela génère beaucoup de
trafic sur le réseau. Les applications temps réel sont
gourmandes en ressources notamment lorsqu'il y a
beaucoup d'utilisateurs. L'ajout de ces applications
en plus des applications déjà existantes sur les
mêmes ressources de l'Internet entraîne de plus en
plus de contraintes d'utilisation des ressources. Le
multicast permet la gestion d'un grand nombre
d'utilisateurs en économisant de la bande passante.
En revanche il nécessite une organisation plus
complexe qu'en unicast.

3
 Les applications temps réel
Une application temps réel est une application pour
laquelle le délai est limité. Voici quelques exemples
d'applications temps réel :
– Le tableau blanc partagé
– La messagerie instantanée
– Les applications multimédia
– La vidéoconférence
– La vidéo à la demande
– Les jeux en réseau … etc

4
 Le multicast
Le multicast permet de diffuser des données à plusieurs
destinataires. Il se base sur la notion de groupe : chaque
personne désirant recevoir certaines informations doit
s'inscrire au groupe concerné. Ainsi, elle pourra recevoir
des données concernant ce groupe, et aussi en envoyer si
elle le souhaite (dans le cas de conférence audio ou vidéo
par exemple).
Les termes « diffusion multipoint » ou « diffusion de
groupe » sont également employés.
Inversement , Le terme unicast définit une
connexion réseau point à point, c'est-à-dire d'un hôte vers
un (seul) autre hôte.

5
Exemple d’une architecture multicast

Sur cette figure , les terminaux connectés au réseau sont représentés par
des cercles, les carrés sont des routeurs. Les terminaux, sauf la source,
sont hachurés suivant le groupe auquel ils sont abonnés, ou blanc pour
aucun groupe. On suppose ici qu'il n'y a qu'une seule source pour
simplifier le schéma.

6
Lorsque la source désire envoyer une information concernant
le groupe 1, elle émet un seul paquet par lien emprunté, ayant
pour adresse de destination l'adresse du groupe multicast 1 (les
adresses multicast sont comprises entre 224.0.0.0 et
239.255.255.255 pour IPv4*). Les routeurs ont connaissance
de l'ensemble des interfaces de sorties sur lesquelles ils
doivent retransmettre l'information pour un groupe donné.
Ainsi, ils peuvent diriger les paquets vers les destinataires
abonnés au groupe. Si l'ensemble est constitué de plus d'une
sortie, le paquet sera répliqué autant de fois. Mais sur une
sortie, une seule copie du paquet circule. Les abonnés d'un
groupe peuvent à tout moment se désabonner et s'abonner à
autant de groupes qu'ils souhaitent en même temps.

7
On distingue les communications un-à-plusieurs
et plusieurs-à-plusieurs. Dans le premier cas, une
seule source émet des paquets vers un ensemble
de destinataires (comme dans la figure
précédente ) ; cela concerne les applications de
type Source Specific Multicast (SSM) . Dans le
second cas, il peut y avoir plusieurs sources ; les
applications concernées sont Any Source
Multicast (ASM) .

8
 Le multicast pour les applications
temps réel
Le multicast a pour avantage majeur de permettre
l'envoi d'un seul paquet par lien emprunté depuis la
source, quel que soit le nombre de destinataires, ce
qui économise de la bande passante. Au contraire,
en unicast la source devrait envoyer autant de copies
du paquet qu'il y a de destinataires. Dans notre cas
de diffusion de flux temps réel, l'avantage est
d'autant plus important qu'il permet de ne pas
surcharger la source en envois, et limite la
congestion dans le réseau puisque moins de paquets
transitent.

9
 Remarque

Broadcast ?
Broadcast est un verbe anglais composé par broad (autour)
et cast (distribuer), signifiant "diffuser". Ce terme est
essentiellement utilisé par les techniciens de télévision pour
qualifier le niveau d'un équipement, d'un système de diffusion ou
d'une source qui respectent les normes professionnelles (« qualité
broadcast »).
Par extension, le nom commun broadcasting est employé dans
plusieurs secteurs d'activité.
Dans le domaine de la télévision et
des télécommunications, broadcasting signifie télédiffusion ou ra
diodiffusion.
Dans le domaine de l'informatique, le broadcasting désigne une
méthode de transmission de données à l'ensemble des machines
d'un réseau.

10
Sur Internet, ces applications souffrent des performances
trop variables du réseau. Pour certaines, la gigue* doit
être minimale pour permettre que la présentation du flux à
l'application soit fluide. Par exemple, lors d'une diffusion
audio, si la gigue est trop importante, la présentation du
son sera déformée. De même, la perte de paquets dans le
réseau et l'augmentation du délai d'acheminement d'un
paquet doivent être limitées. Dans ce cas, l'application
doit utiliser des mécanismes pour masquer la perte ou le
délai, mais cela est généralement perceptible. Pour éviter
d'éventuelles baisses de qualité dans la présentation, il
faudrait contrôler notamment le délai, la gigue et le taux
de perte, et ainsi pouvoir contrôler la QoS.

*La gigue ( en anglais packet delay variation (PDV) ou packet jitter ) est la
différence de délai de transmission de bout en bout entre des paquets choisis dans
un même flux de paquets, sans prendre en compte les paquets éventuellement
perdus. 11
 La Qualité de Service
La Qualité de Service (QoS) constitue un ensemble de
paramètres utilisés pour décrire les exigences d'une
communication et pour analyser les performances d'une
connexion. Ces différents paramètres peuvent exprimer
les besoins d'une application en termes de débit minimal,
de bande passante minimale, de gigue maximale... En
mesurant ces paramètres on peut donner à un récepteur la
description des performances que l'on est capable de
fournir pour lui envoyer des informations au travers du
réseau. La valeur de ces paramètres dépend d'une part des
capacités matérielles de l'émetteur, et d'autre part de l'état
du réseau à un moment donné.

12
 Importance de la QoS
Par exemple TCP/IP permet de contrôler la
transmission des données pour éviter les pertes dans
le réseau. Notamment, il utilise un procédé de
fenêtre pour minimiser la congestion. Ainsi la
quantité de données qui transite entre deux
machines sur le réseau est diminuée par TCP dès la
détection de la perte d'un paquet. Si plus aucune
perte de paquet n'est détectée sur cette transmission,
la fenêtre est agrandie (donc la quantité de données
émises est augmentée) .

13
 Ce moyen de contrôle de la congestion n'est pas
toujours applicable sur Internet pour plusieurs
raisons :
– Certaines applications ne supportent pas des états
particuliers du réseau : les applications temps réel
ne supportent pas les grandes variations du taux
de transmission.
– Des abus pourraient être observés (ouverture de
multiples connections TCP entre deux mêmes
terminaux pour augmenter leur taux de
transmission), etc.
Il est donc nécessaire d'utiliser des architectures qui
satisfont les exigences de différentes applications.

14
 Qu'est ce que RTP et RTCP ?
La diffusion des ordinateurs, ajouté à la disponibilité de
matériel informatique audio/vidéo bon marché, ainsi qu'à
la disponibilité de liaisons à plus haut débit, ont fait surgir
l'intérêt d'utiliser le réseau Internet pour envoyer de
l'audio et de la vidéo, types de données qui
traditionnellement étaient réservés aux réseaux spécialisés
à cet effet, et depuis déjà quelques années l'audio et la
vidéoconférence sont devenus une pratique courante.
Mais la nature même de l'Internet, fait que ce réseau ne
soit pas adapté pour la transmission des données temps
réel, ceci a comme conséquence que la qualité de l'audio
envoyé à travers l'Internet a en moyenne une qualité
médiocre.
15
 RTP (Real-time Transfert Protocole)

Le but de RTP et de fournir un moyen uniforme

de transmettre sur IP des données soumises à des
contraintes de temps réel (audio, vidéo, ... ). Le
rôle principal de RTP consiste à mettre en œuvre
des numéros de séquence de paquets IP pour
reconstituer les informations de voix ou vidéo
même si le réseau sous-jacent change l'ordre des
paquets.

16
Plus généralement, RTP permet :
– d'identifier le type de l'information transportée;
– d'ajouter des marqueurs temporels et des
numéros de séquence à l'information
transportée;
– de contrôler l'arrivée à destination des paquets.
De plus, RTP peut être véhiculé par des paquets
multicast afin d'acheminer des conversations
vers des destinataires multiples.

17
 RTCP (Real-time Transfert Control
Protocole)
– Le protocole RTCP est basé sur des
transmissions périodiques de paquets de
contrôle par tous les participants dans la
session.
– C'est un protocole de contrôle des flux RTP,
permettant de véhiculer des informations
basiques sur les participants d'une session, et
sur la qualité de service.

18
 Utilisation prévue de RTP et RTCP
RTP permet une gestion des flux multimédias (voix,
vidéo) sur IP. RTP fonctionne sur UDP. L'en-tête
RTP comporte des informations de synchronisation,
de numérotation. Le codage des données dépendra
du type de compression.
Le RFC*xxxx spécifie RTP, par contre l'adaptation
d'une méthode de compression à RTP sera décrite
dans un RFC spécifique.
*Les requests for comments (RFC), littéralement « demande de commentaires », sont
une série numérotée de documents officiels décrivant les aspects techniques d'Internet,
ou de différents matériels informatiques (routeurs, serveur DHCP). Peu de RFC sont
des standards, mais tous les documents publiés par l'IETF sont des RFC.
*L’Internet Engineering Task Force (IETF), élabore et promeut des standards
Internet, en particulier les normes qui composent la suite de protocoles Internet
(TCP/IP). 19
Par exemple H261* sur RTP est décrit dans le
RFCxxxx. Un canal RTP est employé par type de
flux: un pour l'audio, un pour la vidéo. Le champ
xxx est employé pour la synchronisation.
*H.261 est une recommandation de compression vidéo de l'UIT. C'est une évolution de la
norme H.120. Elle fut notamment popularisée par la console de jeu PlayStation de Sony,
qui l'intégra entièrement dans son moteur de décompression de données. Les travaux sur la
norme H.261 ont ultérieurement servi de base à la norme MPEG.
Cette norme devenu obsolète, sa succession fut assurée par la norme H.263 de meilleure
qualité pour la VoIP; pour le pur encodage vidéo, on préfèrera la norme H.264.
*Caractéristiques techniques :
Bande passante sur le réseau : 64 kbit/s.
Formats d'images :
Débit de 15 images par seconde (352 × 288 pixels)
Débit de 30 images par seconde (176 × 144 pixels).
Technique de compression : DCT (Discrete Cosine Transform) + codage de Huffman.

20
RTP offre un service de bout en bout. Il ajoute
une en-tête qui fournit les informations de timing
nécessaires à la synchronisation de flux temps
réel du type son et vidéo. RTP (Realtime
Transport Protocol) et son compagnon RTCP
(Realtime Transport Control Protocol)
permettent respectivement de transporter et de
contrôler des flots de données qui ont des
propriétés temps-réel.

21
RTP et RTCP sont des protocoles qui se situent
au niveau de l'application et utilisent les
protocoles sous-jacents de transport TCP ou
UDP. Mais l'utilisation de RTP/RTCP se fait
généralement au-dessus de UDP. RTP et RTCP
peuvent utiliser aussi bien le mode Unicast
(point à point) que le mode Multicast
(multipoint). Chacun d'eux utilise un port séparé
d'une paire de ports. RTP utilise le port pair et
RTCP le port impair immédiatement supérieur.

22
 Format des en-têtes et leurs contenus

L'en-tête RTP comportera les informations

suivantes :

23
• Le champ Version V de 2 bits de longueur indique
la version du protocole (V=2)
• Le champ padding P : 1 bit, si P est égal à 1, le
paquet contient des octets additionnels de bourrage
(padding) pour finir le dernier paquet.
• Le champ extension X : 1 bit, si X=1 l'en-tête est
suivie d'un paquet d'extension
• Le champ CSRC count CC : 4 bits, contient le
nombre de CSRC (contributing source) qui suivent
l'entête.
• Le champ marker M: 1 bit, son interprétation est
définie par un profil d'application (profile)
• Le champ payload type PT : 7 bits, ce champ
identifie le type du payload (audio, vidéo, image,
texte, html, etc.)
24
• Le champ séquence number : 16 bits, sa valeur initiale est
aléatoire et il s'incrémente de 1 à chaque paquet envoyé, il peut
servir à détecter des paquets perdus
• Le champ timestamp : 32 bits, reflète l'instant où le premier
octet du paquet RTP à été échantillonné. Cet instant doit être
dérivé d'une horloge qui augmente de façon monotone et linéaire
dans le temps pour permettre la synchronisation et le calcul de la
gigue à la destination
• Le champ SSRC : 32 bits, identifie de manière unique la source,
sa valeur est choisie de manière aléatoire par l'application. Le
champ SSRC identifie la source de synchronisation (ou dit
simplement "la source"). Cet identificateur est choisi de manière
aléatoire avec l'intérêt qu'il soit unique parmi toutes les sources
d'une même session La liste des CSRC identifie les sources
(SSRC) qui ont contribué à l'obtention des données contenues
dans le paquet qui contient ces identificateurs. Le nombre
d'identificateurs est donné dans le champ CC
• Le champ CSRC : 32 bits, identifie les sources contribuant.

25
 L'en-tête RTCP
L'objectif de RTCP est de fournir différents types d'informations et un retour quant à la
qualité de réception.

• L'en-tête RTCP comportera les informations suivantes :

• Le champ version (2 bits)
• Le champ padding (1 bits) indique qu'il y a du bourrage dont la taille est indiquée
dans le dernier octet
• Le champ reception report count (5 bits): nombre de compte-rendus dans le
paquet
• Le champ packet type (8 bits) 200 pour SR
• Le champ length (16 bits) longueur du paquet en mots de 32 bits
• Le champ SSRC (32 bits): identification de la source spécifique à l'émetteur
• Le champ NTP timestamp (64 bits)
• Le champ RTP timestamp (32 bits)
• Le champ sender's packet count (32 bits)
• Le champ sender's octet count (32 bits) statistiques
• Le champ SSRC-n (32 bits) numéro de la source dont le flux est analysé
• Le champ fraction lost (8 bits)
• Le champ cumulative number of packets lost (24 bits)
• Le champ extended highest sequence number received (32 bits)
• Le champ interarrival jitter (32 bits). C'est une estimation de l'intervalle de temps
d'un packet de donnés RTP qui est mesuré avec le timestamp et qui est sous forme
d'un entier. C'est en fait le temps relatif de transit entre deux paquets de donnés. 26
La formule pour le calculer est :
J=J+(|D(i-1,i)|-J)/16

L'inter-arrival jitter est calculé à chaque packet

de donnée reçu par la source SSRC_n
i → Premier paquet
i-1 → paquet précédent
D → différence
J → Second paquet
• Le champ last SR timestamp (32 bits)
• Le champ delay since last SR (32 bits)

27
 Comment est utilisé RTCP vis à vis de
RTP ?
RTCP est un protocole de contrôle associé à RTP,
il mesure les performances, par contre il n'offre
pas de garantie. Pour cela il faut, employer un
protocole de réservation du type RSVP* ou bien
s'assurer que les liens de communications utilisés
sont correctement dimensionnés par rapport à
l'utilisation qui en est faite.
* Resource ReSerVation Protocol (ou RSVP) est un protocole de la couche
transport du modèle OSI

28
 RSVP
Ce protocole souvent associé au protocole RTP peut fournir fiabilité et
qualité de service (QoS) qui font défaut à ce dernier. En effet, RTP est
un protocole "bout et bout", il ne gère pas les paramètres liés au réseau.
Le protocole RSVP (Ressource reSerVation Protocol)) est un protocole
de contrôle de réseau qui permet au destinataire des données de
demander une certaine qualité de service (par exemple le délai ou la
bande passante) à travers le réseau.
Ce protocole de signalisation permet d'allouer dynamiquement de la
bande passante : il est utilisé par les applications "temps réel" afin de
réserver les ressources nécessaires au niveau des routeurs pour que la
bande passante nécessaire soit disponible lors de la transmission. Les
routeurs communiquent via RSVP pour initialiser et gérer la bande
passante réservée aux sessions. Ce protocole est responsable de la
négociation des paramètres de connexion avec ces routeurs. Si la
réservation est établie, RSVP se charge aussi du maintien de l'état des
routeurs et de l'hôte afin de fournir le service demandé.

29
Dans RSVP, le destinataire est responsable de la réservation de
ressources QoS. L'émetteur RSVP envoie ses exigences au
destinataire. Après réception, le destinataire RSVP utilise le
même chemin pour renvoyer un message spécifiant la QoS
souhaitée et fixer la réservation des ressources correspondantes
dans chaque nœud. L'émetteur RSVP envoie alors les données.
• Ce protocole a pour objectif :
- Etablissement et maintien d'un chemin unique pour la
transmission de données.
- Elaboration d'un système d'ordonnancement des paquets.
- Création d'un module de contrôle pour les ressources des
différents nœuds du réseau.

30
En résumé :
– Conçu surtout pour le multicast, mais peut
également être utilisé en unicast .
– Commandé par le(s) destinataire(s).
– Une réservation de ressource vaut pour un
flux unidirectionnel.
– RSVP est transparent pour les routeurs qui ne
le connaissent pas.
– Une réservation est acceptée si le demandeur
est autorisé et la politique du routeur est
compatible.

31
 Au-dessus de quels protocoles
fonctionnent RTP et RTCP?

RTP/RTCP est au-dessus du transport UDP/TCP,

mais pratiquement au-dessus de UDP.
RTP est un protocole de session, mais il est placé
dans l'application. C'est au développeur de
l'intégrer.

32
 Comment le type de flux est-il véhiculé ?
RTP n'a rien a voir avec le type de flux, il est au-dessus de
UDP lui-même au-dessus de IP. Le type de flux est
théoriquement utilise dans IP.
RTP apporte un numéro de séquence, un timestamp* et un
identificateur unique de la source(SSRC).
*L'horodatage (en anglais timestamping) est un mécanisme
qui consiste à associer une date et une heure à un événement,
une information ou une donnée informatique. Il a
généralement pour but d'enregistrer l'instant auquel une
opération a été effectuée.
En informatique, l'horodatage est fréquemment employé dans
les journaux d'événements (ou historiques).

33