Le Streaming Audio et Vidéo
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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 13Les protocoles de streaming Audio et Video 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 plate- forme 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 Lucie LEROY et Benoit LHOTE Page 2 sur 13
Les protocoles de streaming Audio et Video 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". Lucie LEROY et Benoit LHOTE Page 3 sur 13
Les protocoles de streaming Audio et Video
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 …
Lucie LEROY et Benoit LHOTE Page 4 sur 13Les protocoles de streaming Audio et Video
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.
Extension de
Architecture Format natif Streaming media
fichier
QuickTime Format QuickTime .mov
RealMedia Format RealMedia .rm
Windows Advanced Streaming Format ou
.asf, .wmv, .wma
Media Windows Media Video/Audio
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.
Lucie LEROY et Benoit LHOTE Page 5 sur 13Les protocoles de streaming Audio et Video 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é. Lucie LEROY et Benoit LHOTE Page 6 sur 13
Les protocoles de streaming Audio et Video
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é "plug-
in", 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
RTC
Présentation FTP HTTP SMTP RTSP RTP RSVP
P
Session
Transport TCP UDP RSVP
Réseau IP
Liaison de
données
Physique
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.
Lucie LEROY et Benoit LHOTE Page 7 sur 13Les protocoles de streaming Audio et Video 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. Lucie LEROY et Benoit LHOTE Page 8 sur 13
Les protocoles de streaming Audio et Video
L'En Tête RTP,
0 15 16 32
Mot 1 V P X CC M PT Numéro de Séquence
Mot 2 Horodatage (Timestamp)
Mot 3 Identificateur de la source de synchronisation (SSRC)
Mot 4 Identificateur(s) de la (des) Source(s) Contributrice(s) (CSRC)
Mot 5 Données
V : Version 2 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
P : Padding 1
partie de bourrage.
X : Extension 1 Spécifie qu'un en-tête supplémentaire suit le paquet (=1).
CC : Nombre de Contient le nombre d'identificateur de source contributrices
4
CSRC contenues dans la listes CSRC.
Indique la présence de descriptifs contenant la trace
M : Marker 1
d'évènements particuliers.
Donne le type de contenu audio et/ou vidéo transporté par le
PT : Payload Type 7
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
Numéro de
16 détecter une perte de paquet et de réorganiser des paquets qui,
séquence
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
Horodatage 32 doit être monotone et linéaire pour assurer une synchronisation
de flux.
Identifie la source de synchronisation, c'est à dire l'émetteur sur
SSRC 32 lequel il faut caler la base de temps commune à tous les
participants.
Liste des participants ayant apportés leur contribution (audio,
CSRC 32
vidéo) aux données du paquets. Peut être nul.
Lucie LEROY et Benoit LHOTE Page 9 sur 13Les protocoles de streaming Audio et Video
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.
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.
Garder une trace de tous les participants à une session.
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
Lucie LEROY et Benoit LHOTE Page 10 sur 13Les protocoles de streaming Audio et Video
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 15 16 32
Mot 1 V P RC PT Longueur
Mot 2 Rapport(s)
V : Version 2 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
P : Padding 1
partie de bourrage.
RC : Report Contient le nombre de rapports contenus dans le paquet (un
5
Counter rapport pour chaque source).
PT : Packet Type 8 Donne le type de rapport du paquet (SR, RR, SDES ou BYE).
Longueur 16 Longueur du paquet.
Lucie LEROY et Benoit LHOTE Page 11 sur 13Les protocoles de streaming Audio et Video
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 15 16 32
Type de
Mot 1 V F Checksum
Message
Mot 2 Send_TTL Réservé Longueur du message
Lucie LEROY et Benoit LHOTE Page 12 sur 13Les protocoles de streaming Audio et Video
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).
Lucie LEROY et Benoit LHOTE Page 13 sur 13Vous pouvez aussi lire
