Le Streaming Audio et Vidéo

Transcription

Les protocoles de streaming Audio et Video
Le Streaming Audio et Vidéo
Qu'est ce que le streaming ?
Synonyme de diffusion de contenus multimédias, le streaming est intimement lié au
développement d'Internet à haut débit. Le streaming média apporte de l'action et du son aux sites
Web ce qui accroît leur intérêt et leur interactivité. Il permet d'accéder en temps réel ou à la
demande à des contenus audio ou vidéo via Internet ou un Intranet.
Un stream est un flux de données de son ou de vidéo transporté par le réseau :
Ce site n'a pas pour objectif de vous apprendre à faire du streaming mais plutôt celui de vous
expliquer comment il fonctionne et sur quels protocoles il est basé.
Lucie LEROY et Benoit LHOTE
Page 1 sur 13
Les architectures de streaming media
Les architectures de streaming média sont constituées de codecs, de méthode de transmission, de
serveurs logiciels et de lecteurs (logiciel sur le poste client). Les trois architectures de streaming
media les plus utilisées sont :

Quick Time :

Real Média :

Windows Média :
Il existe d'autres possibilités de lecture des flux en streaming, notamment des architectures basées
sur des applets Java qui ne requièrent pas l'installation d'un lecteur propriétaire (ou plug-in) par
l'utilisateur. Néanmoins, ouvent ceux ci n'offrent pas la gamme complète de commandes
utilisateur dont on dispose avec les lecteurs propriétaires. Les trois architectures dominantes du
marché (RealMedia, Windows Media et QuickTime) ne sont pas compatibles entre elles. S'il
existe certaines possibilités, au niveau des lecteurs, de lire les formats d'autres architectures, cette
technologie est si concurrentielle que les formats évoluent rapidement. Cela est génant pour les
utilisateurs qui doivent être constament à jour au niveau des plug-ins et choisir leur lecteur par
défaut dans leur navigateur, en fonction de celui supporté par la majorité de leurs fournisseurs de
contenus préférés.
Les fichiers de streaming média sont généralement codés dans plusieurs plusieurs versions,
optimisés pour des taux de transfert différents. Le serveur de streaming média fournit la version
appropriée en fonction des paramètres sélectionnés manuellement par l'utilisateur ou des
paramètres par défaut du navigateur. Dans certains cas, le serveur peut sélectionner
automatiquement la meilleure version, selon les informations rapportées par le client sur sa plateforme et sa vitesse de connexion. En fonction de l'intelligence intégrée dans le serveur de médias
et du lecteur client, le flux peut être ajusté dynamiquement à l'une ou aux deux extrémités, si la
connexion ralentit
Page 2 sur 13
Du point de vue des fournisseurs ...
Dans une architecture streaming, tout doit être compatible :
La multiplication des architectures de streaming média rend la situation encore plus difficile pour
les fournisseurs. En effet, le serveur Windows Media ne peut pas "streamer" les fichiers
QuickTime et RealMedia et réciproquement. Les utilisateurs quant à eux choisissent leurs
lecteurs par défaut pour différentes raisons. C'est pourquoi, afin d'éviter que leurs médias soient
oubliés, les fournisseurs de contenu décident d'encoder, de servir et de streamer leurs contenus
dans au moins deux principaux formats, si ce n'est pas trois.
De plus, si les fournisseurs diffusent sur bande étroite, sur large bande ou les deux, les fichiers
multimédias sont offert dans plusieurs débits binaires dans chaque format. Ce qui rend la
situation encore plus complexe et plus couteuse, en effet, il peut y avoir jusqu'à neuf versions à
encoder, stocker et "streamer".
Page 3 sur 13
Les différentes étapes du streaming média :
Chaque architecture a ses avantages et ses inconvénients ainsi que des critiques positives ou
négatives. Il n'est pas facile de décider quelle architecture utiliser. Ces décisions dépendent des
paramètres du projet, du public, des objectifs …
Page 4 sur 13
Les formats de streaming média
Souvent, les architectures sont confondues avec les " formats ". Elle sont cependant bien plus que
cela. Un format, également appelé format de fichier, n'est que la structure de fichier que crée une
architecture avec ses " codecs ". Le format est généralement idenfiable par son extension du nom
de fichier.
Architecture Format natif Streaming media
QuickTime
RealMedia
Windows
Media
Format QuickTime
Format RealMedia
Advanced Streaming Format ou
Windows Media Video/Audio
Extension de
fichier
.mov
.rm
.asf, .wmv, .wma
MPEG est un format de fichier standard pour la vidéo, et il s'agit également d'un codec qui
permet de créer des formats, ce n'est cependant pas une architecture complète.
MPEG-1 ne prend pas en charge le vrai streaming, il permet seulement le téléchargement
progressif.
Récemment, un nouveau standard ouvert international basé sur le format QuickTime a été
introduit sur le marché : le MPEG-4 afin de permettre la vidéo sur le Web. Windows Media
Video v1 est un dérivé de ce codec. QuickTime 5, est la première mise en œuvre complète du
MPEG-4 pour le streaming media.
Page 5 sur 13
Le pseudo streaming
Le pseudo streaming, ou téléchargement progressif permet à l'utilisateur de lire un média alors
que le fichier est encore en cours de téléchargement. Il se différencie du téléchargement " normal
" pour lequel l'utilisateur doit attendre d'avoir complètement téléchargés le fichiers pour pouvoir
ensuite le lire depuis son disque dur. Avec le pseudo streaming, une copie du fichier est conservé
sur le disque de l'utilisateur, ce qui lui permettra de relire le media ultérieurement. Le
téléchargement progressif est également appelé streaming HTTP car les logiciels serveur Web
utilisant des protocoles standard (serveurs HTTP) peuvent transmettre des fichiers à
téléchargement progressif ; il se différencie du vrai streaming, qui tire parti des protocoles
spéciaux utilisés par les logiciels serveur de médias pour adapter la transmission à la bande
passante.
Le streaming permet de parcourir, d'avancer et de revenir à un point donné du contenu,
contrairement au téléchargement progressif, qui requiert de visionner le contenu du début à la fin.
Lorsque le protocole HTTP est utilisé pour le téléchargement progressif, la fiabilité même du
protocole peut poser des problèmes, étant donné que la retransmission des paquets perdus ou
endommagés peut interrompre la lecture du pseudo-streaming. Donc, fiables tels qu'ils le sont
pour la transmission de documents, les protocoles HTTP et FTP ne peuvent pas être utilisés pour
un vrai streaming, car leur système de correction d'erreurs affaiblit la relation temporelle entre les
paquets vidéo et audio. Ils n'offrent pas de fonction permettant d'adapter la vitesse de transfert des
données au débit audio ou vidéo, c'est-à-dire la vitesse de lecture des données qui constituent le
contenu multimédia. À l'aide des protocoles HTTP ou FTP, le téléchargement d'un film d'une
minute pourrait prendre une seconde, une minute ou même une heure, selon la taille du fichier et
la vitesse de la connexion. Si la vitesse de connexion est inférieure au débit de données du
contenu multimédia, celui-ci arrivera quand même au client, mais le téléchargement progressif ne
pourra s'effectuer sans difficulté.
Page 6 sur 13
Plug-in et codecs
Par défaut, les navigateurs web ne savent pas lire les fichiers vidéo ou audio, qu'il s'agisse de
streaming ou pas. En effet, pour pouvoir lire ce type de fichiers, il est nécessaire de posseder un
logiciel et des codecs. Bien souvent, ceux ci sont livrés avec un petit programme appelé "plugin", qui s'interface avec le navigateur web et qui permet de lire une vidéo ou une séquence audio
direcetement dans une page web.
En fonction de l'extension du fichier multimedia et du format MIME (Multipurpose Internet Mail
Extension) associé, le navigateur saura quel logiciel ou quel plug-in utiliser pour lire le fichier. Si
le type MIME est inconnu pour le navigateur, celui ci proposera de télécharger le fichier et
invitera à aller télécharger le plug-in chez l'éditeur correspond. Néanmoins, si il s'agit d'un fichier
multimédia en " vrai streaming ", il ne sera pas utilisable par l'utilisateur. La plupart des plug-in
permettant de lire les fichiers multimédia en streaming sont gratuits dans leur version basique.
Des versions plus évoluées sont également proposés à la vente.
Les protocoles de transmission du streaming
Les flux de données audio ou vidéo sont envoyés à partir d'un serveur de streamig média à un
client qui souvent utilise un protocole de transmission en temps réel appelé RTP (Real-time
Transport Protocol). Le protocole RTP est semblable aux protocoles HTTP et FTP mais il existe
des différences essentielles.
Applications
Présentation
Session
Transport
Réseau
Liaison de
données
Physique
FTP
HTTP
SMTP
RTSP
TCP
RTP
RTC
P
UDP
RSVP
RSVP
IP
Mais ce ne sont pas les seuls protocoles utilisés, nous allons vous expliquer le rôle de ces
différents protocoles utilisés dans le streaming : HTTP, FTP, RTP,RTCP, RSVP et RTSP.
Page 7 sur 13
Transmission de données sur Internet : HTTP et FTP
HTTP (hypertext transfer protocol) est le protocole utilisé pour transmettre des fichiers
Hypertexte sur le Web. L'Hypertexte, imaginé par l'informaticien Ted Nelson en 1965 désigne
un système qui permet, lors de la consultation d'une base documentaire électronique, de mettre en
relation un ensemble de données texte, image et son. Depuis que l'Hypertexte est intéractif, il
requiert un protocole de transmission bidirectionnelle qui permet au destinataire de répondre via
le réseau.
Le protocole FTP (File transfer protocol) permet sur Internet de tranmettre des fichiers entre
deux périphériques. De nombreuses applications de ce protocole sont développées sur Internet car
il est très pratique pour le téléchargement en amont ou en aval de la plupart des types de fichiers.
Et pour le Streaming ?
HTTP et FTP fonctionne sur TCP, ce qui leur permet de tramettre des contenus audio ou vidéo
sans perte ni endommagement. Les paquets perdus ou endommagés sont simplement renvoyés.
Cependant si on utilise HTTP pour le téléchargement progressif, la fiabilité même du protocole
peut poser des problèmes. En effet, la retransmission des paquets peu interrompre la lecture du
pseudo streaming. Les protocoles HTTP et FTP ne peuvent pas être utilisés pour le vrai
streaming, à cause de leur système de correction d'erreurs qui ralentit la transmission ou qui
pourrait "décaler" le son et la vidéo. De plus, il n'offre pas de contrôle de la vitesse de transfert de
données afin de l'adapter au débit audio et vidéo.
Le Protocole RTP,
Le protocole RTP (Real-Time Transfert Protocole) standardisé en 1996, permet la transmission
de données en temps réel. Il s'appuie sur le protocole UDP plutôt que sur le protocole TCP. RTP
fournit très peu de correction d'erreurs : les paquets perdus, en retard ou endommagés sont
ignorés. En effet, RTP privilégie l'enchainement du son et des images, plutôt que l'intégrités des
données. Cependant, si la vitesse de connexion est inférieure au débit de données, la lecture est
"saccadée" voire impossible. De même, si le taux d'erreur est supéreur à 10, la lecture est de
mauvaise qualité (le son peut par exemple être métallique).
Le but de RTP est de fournir un moyen uniforme de transmettre des données soumises à des
contraintes de temps réel. Son rôle principal est de mettre en oeuvre des numéros de séquence de
paquets IP pour reconstituer les infos de voix ou vidéo.
RTP offre des moyens aux applications pour :
Identifier le type de l'information transportée
Ajouter des marqueurs temporels et des numéros de séquence à l'information.
Contrôler l'arrivée à destination des paquets.
NB : RTP peut en théorie être utilisé seul mais il est généralement accompagné de RTCP (Real
Time Control Protocol). Ce second protocole assure le trafic de contrôle.
Page 8 sur 13
L'En Tête RTP,
0
Mot 1
Mot 2
Mot 3
Mot 4
Mot 5
15
V P X
V : Version
2
P : Padding
1
X : Extension
CC : Nombre de
CSRC
1
M : Marker
4
1
PT : Payload Type 7
Numéro de
séquence
16
Horodatage
32
SSRC
32
CSRC
32
CC
16
32
M
PT
Numéro de Séquence
Horodatage (Timestamp)
Identificateur de la source de synchronisation (SSRC)
Identificateur(s) de la (des) Source(s) Contributrice(s) (CSRC)
Données
Défini le numéro de la version de RTP : actuellement 2.
Indice permettant de spécifier que les octets de données ont une
partie de bourrage.
Spécifie qu'un en-tête supplémentaire suit le paquet (=1).
Contient le nombre d'identificateur de source contributrices
contenues dans la listes CSRC.
Indique la présence de descriptifs contenant la trace
d'évènements particuliers.
Donne le type de contenu audio et/ou vidéo transporté par le
paquets ainsi que le format de codage.
Numéro d'ordre d'émission des paquets, il est incrémenté d'une
unité à chaque paquet envoyé. Il permet ainsi au destinataire de
détecter une perte de paquet et de réorganiser des paquets qui,
du au réseau, serait arrivés dans un ordre différents de celui
d'émission.
Horloge système ou horloge d'échantillonage de l'émetteur. Elle
doit être monotone et linéaire pour assurer une synchronisation
de flux.
Identifie la source de synchronisation, c'est à dire l'émetteur sur
lequel il faut caler la base de temps commune à tous les
participants.
Liste des participants ayant apportés leur contribution (audio,
vidéo) aux données du paquets. Peut être nul.
Page 9 sur 13
Le Protocole RTCP
Le Real Transport Control Protocol ou protocole du transport en temps réel est basé sur la
transmission périodique de paquets de contrôle à tous les participants d’une session. Ce protocole
de contrôle des flux RTP permet de véhiculer des informations basiques sur les participants d'une
session, et sur la qualité de service. Le multiplexage des paquets de données RTP et des paquets
de contrôle RTCP est réalisé par le protocole sous-jacent (UDP par exemple).
Le protocole RTCP rempli trois missions principales :

Fournir des informations sur la qualité de la session.

Garder une trace de tous les participants à une session.

Information en retour pour une source (feedback). Ce feed-back sur la qualité de
réception des données transmises dans les paquets RTP est utilisée par la source
émettrice pour adapter le type de codage au niveau de ressources disponibles.
Permet à une source de changer de politique.
met en évidence des défauts de distribution individuels, collectifs.
RTCP transporte un identificateur originel de la source RTP c’est à dire la
provenance du flux, appelé « nom permanent » ou CNAME (Canonical name).
Dans le cas où un mixeur est utilisé, la source du flux change et la synchronisation
est prise en charge par le mixeur ; de ce fait on ne peut se fier au SSRC
(Synchronisation Source Identifier) pour identifier la provenance du flux. C'est
pourquoi, le CNAME est nécessaire afin de permettre une identification
permanente de chacun des flux multimédias entrant.
Contrôler le débit auquel les participants à une session RTP transmettent leur paquet
RTCP.

Plus il y a de participants, moins la fréquence d'envoie de paquets RTCP par un
participant est grande.
Il faut garder le trafic RTCP en dessous de 5% du trafic de la session
Et une fonction optionnelle :

Transmettre des informations de contrôle sur la session.

Exemple : identifier un participant sur les écrans des participants
Page 10 sur 13
Comme on peut le remarquer RTP et RTCP se contentent d'assister l'émetteur et le destinataire
dans leur activité d'échange de données et c'est à l'application de s'adapter à la situation. En effet,
les paquets de données traversent des routeurs avant d'arriver à leur destination, or lors de leurs
passages par le routeur ils sont disposés selon une file FIFO et sans aucune priorité. Afin de
pouvoir réserver des ressources en matière de bande passante on introduit une priorité dans le
traitement des paquets et ceci en faisant appel au protocole RSVP.
L'En Tête RTCP,
0
Mot 1
Mot 2
V P
15 16
RC
PT
32
Longueur
Rapport(s)
V : Version
2
P : Padding
1
RC : Report
5
Counter
PT : Packet Type 8
Longueur
16
Défini le numéro de la version de RTP : actuellement 2.
Indice permettant de spécifier que les octets de données ont une
partie de bourrage.
Contient le nombre de rapports contenus dans le paquet (un
rapport pour chaque source).
Donne le type de rapport du paquet (SR, RR, SDES ou BYE).
Longueur du paquet.
Page 11 sur 13
Principaux paquets de contrôle RTCP

SR (Sender Report) : ce rapport regroupe des statistiques concernant la transmission
(pourcentage de perte, nombre cumulé de paquets perdus, variation de délai (gigue),
…Ces rapports sont issus d'émetteurs actifs d'une session.
RR (Receiver Report) : ensemble de statistiques portant sur la communication entre les
participants. Ces rapports sont issus des récepteurs d'une session.
SDES (Source Description) : carte de visite de la source (nom, email, localisation).
BYE : message de fin de participation à une session.
RSVP : Protocole de réservation des ressources
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é.
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 noeud. 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 noeuds du réseau.
L'En Tête RSVP,
0
Mot 1
Mot 2
15 16
V
Type de
Message
Send_TTL
32
F
Checksum
Réservé
Longueur du message
Page 12 sur 13
Principaux paquets de contrôle RSVP
Il existe sept types de message RSVP:
Path : envoyé par la source pour indiquer la liste des routeurs du chemin suivi par les
données.
Resv : message de réservation vers les emetteurs.
PathErr : message d'erreur concernant le chemin.
ResvErr : message d'erreur de demande de réservation.
PathTear : indique aux routeurs d'annuler les états concernant la route.
ResvTear : indique aux routeurs d'annuler les états de réservation (fin de session).
ResvConf (optionnel) : message de confirmation envoyé par le routeur au demandeur de
la réservation.
Le Protocole RTSP
Pourquoi RTSP ?
RTSP a été développé par Real Networks, Netscape et l'Université de Columbia au sein du
groupe MMUSIC working group de l'Internet Engineering Task Force (IETF). RTSP utilise RTP
(Real-Time Transport Protocol) pour former les paquets contenant les données multimedia, il est
conçu pour diffuser efficacement des données audio-visuelles pour un grand nombre de
personnes.
Contrairement au protocole RTP, qui ne permet qu'un streaming unidirectionnel (la transmission
du contenu multimédia du serveur vers le client), le protocole RTSP est un protocole
bidirectionnel qui utilise généralement TCP pour communiquer. Ce protocole de niveau
applicatif est prévu pour fonctionner sur des protocoles tels que RTP/RTCP et RVP. Selon ses
développeurs, " le protocole RTSP fonctionne comme une ''commande à distance du réseau'' pour
les serveurs multimédias". Comme une télécommande de magnétoscope, le protocole RTSP
fournit un mécanisme qui permet aux utilisateurs de demander spécifiquement des données d'un
ou de plusieurs serveurs, ainsi qu'un type de transfert spécifique et une destination de
transmission des données. Ils peuvent également demander des informations sur les données dans
un format spécifique, lancer, arrêter et mettre en pause la transmission des données, et obtenir
l'accès direct à différents paquets de données (lorsque c'est possible, et ce n'est par exemple pas
possible dans le cas d'une alimentation en direct et en temps réel).
Page 13 sur 13