Services multimédia1 Services multimédia sur réseaux – La vidéo sur IP A. Quidelleur [email protected] SRC2 Meaux 2008-2009 M22.4 - Réseaux

Services multimédia 1

Services multimédia sur réseaux – La vidéo sur IP

A. [email protected]

SRC2 Meaux 2008-2009

M22.4 - Réseaux et Services sur RéseauxModule complémentaire – Option poursuite d’études

courtes


Trois types de vidéo sur IP

Vidéo à la demande comprend les serveurs de téléchargement de vidéo et les

serveurs de streaming la transmission se fait par des réseaux locaux ou d’opérateurs

Vidéoconférence ou visioconférence les débits doivent s’adapter à ceux des réseaux de transport les communications sont interactives (les délais de

transmission doivent être limités) Normes : H323 et SIP (voir cours Voix sur IP)

Télévision numérique s’appuie sur des standards de format (standards ETSI –

European Telecommunication Standards Institute) utilise plusieurs supports de transmission (câble, hertziens,

satellites) Le canal disponible a un débit fixe (2 Mbit/s en DVB câble ou

hertzien) : le taux de compression varie pour remplir le canal


Le besoin en QoS

La voix et la vidéo sont moins sensibles aux erreurs que les transferts de données informatiques

Mais elles ont des exigences en terme De débit : un débit minimal est requis De délai (doit rester borné) De gigue : ce sont des applications isochrones

l'écart de temps entre deux informations successives doit être constant.Si le réseau de transmission introduit un décalage, un mécanisme spécifique doit être mis en oeuvre par le récepteur.


Le besoin en QoS

La compression opérée sur les données de type voix et vidéo engendre des flux variables (voir cours numérisation S3)

Type de transfert

Type de débit

Débit requis

Sensibilité à la gigue

Sensibilité aux erreurs

Voix Constant Faible Elevée Faible

Voix compressée

Variable Faible Elevée Faible

Vidéo Constant Elevé Elevée Faible

Vidéo compressée

Variable Elevé Elevée Faible


Le réseau IP est inadapté

La bande passante n’est pas garantie durant toute la communication

prévoir des mécanismes qui assureront la réservation de bande passante pour les applications temps réel.

Les paquets sont routés indépendamment les uns des autres. Leur séquencement n’est pas assuré (ordre, espacement).

prévoir un protocole de transport permettant le séquencement

Les protocoles de transport utilisés doivent assurer les exigences temporelles que demande la vidéo temps réel comme la synchronisation.


Les protocoles utilisés pour pallier les défauts de IP

Le réseau IP offre un débit variable et non maîtrisé : les protocoles utilisés tentent de pallier ce défaut.

Les protocoles RTP/RTCP permettent de combler les défauts de IP pour maintenir une certaine qualité de service.

Le protocole RSVP permet, lorsque les nœuds du réseau le supportent, de réserver des ressources et donc un débit minimum.


Le protocole RTP (rappel)

RTP (Real-time Transport Protocol) assure la reconstruction temporelle, la détection de

perte, la sécurité (Secure RTP, RFC 3711) et l'identification du contenu.

fonctionne avec le protocole RTCP pour obtenir des feed-backs concernant la qualité de la transmission

fournit un système d'horloge (timestamping), une numérotation des séquences et d'autres mécanismes pour gérer les problèmes liés au temps.

En-tête IPEn-tête IP En-tête UDPEn-tête UDP En-tête RTPEn-tête RTP Données vidéo temps-réelDonnées vidéo temps-réel


Le protocole RTCP (rappel)

RTCP (Real-Time Control Protocol) Les participants envoient périodiquement des

paquets RTCP pour donner des informations sur la qualité du service délivrée. Fonctionne avec RTP.

offre les services suivants : Contrôle de la congestion et monitoring de la QoS

Identification de la source

Synchronisation inter-média (synchronisation du son et de l’image)

Information de contrôle


Le protocole RSVP

Reservation Setup Protocol (RFC 2205 et 2209) Utilisé par les applications temps réel pour réserver les

ressources nécessaires au niveau des routeurs situés le long du chemin de transmission

Un contrôle de police (Policy Control) détermine si l'utilisateur à la permission administrative de faire de la réservation.

Le contrôle d'admission (Admission Control) détermine si le nœud à suffisamment de ressources pour fournir la QoS demandée.

La réservation des ressources est effectuée pour chaque flux L'émetteur envoie ses exigences au récepteur Le récepteur réserve les ressources et précise la QoS souhaitée

sur le même chemin

Réservation des ressources par RSVP


Ouverture d’une session vidéo « temps réel »

UDP

RTP RTCP

Application«temps réel»

Serveur « temps réel »

UDP

RTP

Application«temps réel»

Client

RTCP RSVP

1- Réservation des ressources dans les routeurs à l ’établissement de la session

2- Transmission des données dans des paquets RTP

3- Contrôle de la qualité de la session (débit, gigue, perte) par des paquets RTCP

RouteurRSVP

RouteurRSVP

RouteurRSVP


La transmission unicast et la transmission multicast

Transmission unicast Chaque utilisateur reçoit un flux vidéo spécifique Une adresse IP unique de classe A, B ou C par

utilisateur est utilisée.

Autant de flux que d’utilisateurs

IP unicast

IP unicast

IP unicast

IP unicast


La transmission unicast et la transmission multicast

Transmission par groupe ou multicast Un flux vidéo concerne un groupe d’utilisateurs. Le groupe est identifié par une adresse IP multicast

de classe D.

IP multicast

IP multicast

IP multicast

IP multicast

1 seul flux @IPdst = IP du groupe


Le splitting : Unicast + Multicast

Un splitter peut être utilisé pour distribuer le flux sur des adresses unicast et multicast


Diffusion de la vidéo : off-line et streaming

Fichiers vidéo

1 - Le fichier est chargé sur l’ordinateur client

client

RTCInternetRouteur Routeur

Modem 56Kb/s serveur vidéooff-line

2 - Le fichier est visionné localement

22

Versions du fichier28Kb/s 56Kb/s 512Kb/s

serveur"streaming"

RTCInternetRouteur Routeur

Modem 56Kb/s

22

client

Buffer7Ko

33

1 - Test de performance de la liaison2 - Création d’un buffer pouvant stocker « n secondes » de vidéo

3 - Transmission des paquets

4 - Visualisation « n secondes » après l’arrivée du premier paquet

44

11


Le streaming


Le principe

Définition : La lecture en continu (ou streaming) est un principe utilisé principalement pour l'envoi de contenu en « direct » (ou en léger différé). Très utilisée sur Internet, elle permet la lecture d'un flux audio ou vidéo (cas de la VoD), à mesure qu'il est diffusé. Elle s'oppose ainsi à la diffusion par téléchargement qui nécessite de récupérer l'ensemble des données d'un morceau ou d'un extrait vidéo avant de pouvoir l'écouter ou le regarder.

Les outils : un logiciel de production audio/vidéo permettant le codage en

fonction du débit du réseau emprunté ; un serveur pour stocker les fichiers, établir et paramétrer la

connexion avec le client ; un logiciel de lecture sur le poste client.


Faux streaming et vrai streaming


Le serveur web comme intermédiaire


Un protocole pour la gestion de l’interactivité : RTSP

RTSP a été développé par Real Networks, Netscape et l'Université de Columbia.

RTSP (Real-Time Streaming Protocol), RFC 2326 initie et commande à distance des flux multimédia

stockés sur un serveur de données à travers un réseau IP.

offre des fonctionnalités comme l'arrêt, l'avance rapide, la recherche avancée pour des flux vidéo et audio. Protocole « télécommande »

Les données, quant à elles, sont transmises séparément en utilisant le plus souvent RTP.


Caractéristiques de RTSP

Port 554

Protocole de niveau applicatif qui fonctionne au-dessus de TCP et UDP.

Il peut être utilisé dans des applications unicast et multicast. Les flux peuvent provenir soit de vidéos stockées soit d'une

source temps réel (caméra, micro). RTSP peut contrôler et synchroniser plusieurs flux audio ou

vidéo (mais ne fournit pas lui-même le flux qui est à la charge d'autres protocoles comme RTP).

Il peut être utilisé pour rechercher un média sur un

serveur de médias, inviter un serveur de

médias à rejoindre une conférence (dans le e-learning par ex.),

ou ajouter un média à une présentation existante.


Fonctionnement de RTSP

Il est similaire, au niveau de la syntaxe et des fonctionnalités, à HTTP mais

RTSP est un protocole à états : nécessaire pour pouvoir corréler les demandes RTSP avec un flux

Le client et le serveur peuvent exprimer des requêtes. Pas de notion de connexion dans RTSP, bien que le serveur

maintienne une session ayant un identificateur. Une session RTSP ne correspond pas à une connexion de transport comme TCP. Durant une session, RTSP peut ouvrir et fermer plusieurs connexions de transport à chaque requête.

Peut fonctionner sur UDP

Chaque présentation et chaque flux média est identifié par une URL RTSP de la forme rtsp://media.example.com:554/twister/audiotrack

rtsp:// identifie une connexion sur TCP (rtspu:// pour UDP) 554 est le port utilisé twister est le nom de la présentation audiotrack est le nom d’un flux particulier dans la

présentation (optionnel)


Fonctionnement de RTSP

Chaque présentation et chaque flux média est identifié par une URL RTSP.

Une présentation peut contenir plus d'un flux média.

Le fichier de description de la présentation contient les codages, langage et d'autres paramètres qui permettent au client de choisir la combinaison la plus adéquate de médias.

Les méthodes RTSP utilisent un en-tête Session pour identifier la session RTSP dont l'état est en train d'être manipulé. Le serveur génère un identificateur session en réponse à la requête SETUP

<session><group>< track src="rtsp://audio.example.com/twister/audio.en">< track src="rtsp://video.example.com/video"></group></session>


Les méthodes RTSP

method direction object requirement

DESCRIBE C->S P,S recommendedANNOUNCE C->S, S->C P,S optionalGET_PARAMETER C->S, S->C P,S optionalOPTIONS C->S, S->C P,S required

(S->C: optional)PAUSE C->S P,S recommendedPLAY C->S P,S requiredRECORD C->S P,S optionalREDIRECT S->C P,S optionalSETUP C->S S requiredSET_PARAMETER C->S, S->C P,S optionalTEARDOWN C->S P,S required

C->S : Client -> Server, P : presentation, S : stream


Les méthodes RTSP Seules 5 méthodes contribuent à définir l'état de la session :

SETUP : Le client demande au serveur l'allocation des ressources pour un flux et commence une session RTSP ;

PLAY : Le client demande la transmission des données d'un flux alloué selon SETUP ;

RECORD : Le client initie l'enregistrement selon les paramètres de la description de la présentation ;

PAUSE : Le client arrête temporairement le flux sans libérer les ressources du serveur ;

TEARDOWN : Le client demande de libérer les ressources associées au flux. La session RTSP cesse d'exister sur le serveur ;


Exemple de dialogue RTSP (1)

Le client C veut télécharger un film depuis les serveurs A (audio.example.com) et V (video.examplt.org).

La description des media est stockée sur un serveur web W.

Elle contient une description de la présentation et de ses flux, notamment les codecs disponibles, les types de données RTP, la pile de protocoles utilisée et des informations comme la langue et les restrictions dues au copyright.

Elle peut aussi donner des indications sur la chronologie du film. Dans cet exemple, le client est uniquement intéressé par la dernière partie du film.



RTSP Session : GET description

C->W: GET /twister.sdp HTTP/1.1Host: www.example.comAccept: application/sdp

W->C: HTTP/1.0 200 OKContent-Type: application/sdpv=0o=- 2890844526 2890842807 IN IP4 192.16.24.202s=RTSP Sessionm=audio 0 RTP/AVP 0

a=control:rtsp://audio.example.com/twister/audio.enm=video 0 RTP/AVP 31a=control:rtsp://video.example.com/twister/video

Command

Response

Desc

ripti

on

au

form

at

SD

P



RTSP Session : Open Stream

C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0CSeq: 1Transport: RTP/AVP/UDP;unicast;client_port=3056-3057

A->C: RTSP/1.0 200 OKCSeq: 1Session: 12345678Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;

server_port=5000-5001

C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0CSeq: 1Transport: RTP/AVP/UDP;unicast;client_port=3058-3059

V->C: RTSP/1.0 200 OKCSeq: 1Session: 23456789Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;

server_port=5002-5003

Command

Command

Response

Response


Exemple de dialogue RSTP (4)

RTSP Session : Play

C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0CSeq: 2Session: 23456789Range: smpte=0:10:00-

V->C: RTSP/1.0 200 OKCSeq: 2Session: 23456789Range: smpte=0:10:00-0:20:00RTP-Info: url=rtsp://video.example.com/twister/video;

seq=12312232;rtptime=78712811

C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0CSeq: 2Session: 12345678Range: smpte=0:10:00-

A->C: RTSP/1.0 200 OKCSeq: 2Session: 12345678Range: smpte=0:10:00-0:20:00RTP-Info: url=rtsp://audio.example.com/twister/audio.en;

seq=876655;rtptime=1032181

Command

Command

Response

Response


Exemple de dialogue RSTP (5)

RTSP Session : Teardown

C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0

CSeq: 3Session: 12345678

A->C: RTSP/1.0 200 OKCSeq: 3

C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0CSeq: 3Session: 23456789

V->C: RTSP/1.0 200 OKCSeq: 3

Vidéo et audio sont stockés sur des serveurs différents, mais peuvent ne pas commencer exactement au même instant. Le client peut les synchroniser en utilisant les indications temporelles contenues dans RTCP.

Command

Command

Response

Response


Quelques outils de streaming

Real System (Real Networks) : indépendant de l’OS ; RealProducer Plus pour le codage audio/vidéo ; RealServer pour le service de streaming ; RealPlayer pour la lecture des vidéo

Windows Media (Microsoft) : Windows Media Encoder pour le codage audio/vidéo ; Windows Media Services pour le service de streaming ; Windows Media Player pour la lecture

Quick Time (Apple) : QuickTime Streaming Server (incluant QTSS Publisher) pour le service de streaming; QuickTime Broadcaster pour la production « live » ; QuickTime Player ou QuickTime Pro pour la lecture

VLC serveur : Open source et gratuit


Quelques players de streaming

Quick Time Le Player d’Apple. Le format de fichier est ".mov". Le logiciel existe en deux versions :

gratuite et payante.

Real Player Le player de Realnetworks. Le format de Fichier est .rm. Le logiciel existe en deux versions :


VLC Media Player Le player de The VideoLAN Team. Très peu consommateur en ressources et

ne nécessite pas l'installation de codecs. Le logiciel est gratuit.

Winamp Le Player de Nullsoft Inc. Logiciel particulièrement

polyvalent. Existe en deux versions :


Windows Media Player Le player de Microsoft. Le format de fichier est

".wma". Le logiciel est gratuit.


Infrastructure d’un service de streaming

La station d’administration Sert à la création des pages HTML et des fichiers de liaison

entre navigateur et lecteur multimédia Sert à paramétrer le serveur de streaming et superviser sont

fonctionnement (gestion de la bande passante, contrôle d’occupation de la mémoire et du temps processeur)

Réalise le codage vidéo qui nécessite trop de temps processeur pour être réalisé sur le serveur de streaming

En cas de production importante, il est conseillé de prévoir une station spécifique pour le montage et le codage des vidéo.

serveur"streaming" réseau

client

serveurWeb

HubHub

administration


Choix des débits

Les flux ne doivent jamais occuper toute la bande passante

Une partie doit toujours être gardée pour la surchage (overhead), les corrections d’erreurs, la retransmission de segments perdus…

En général, le débit de streaming maximum peut être calculé :

75% de la bande passante pour des connexions analogiques par modem

90% de la bande passante pour des connexions analogiques/numériques haut-débit type ADSL ou modem-câble

Il est possible de coder la vidéo pour plusieurs débits de transmission, le choix sera fait par le lecteur en fonction des paramètres de configuration. Ce choix porte en général sur 3 valeurs « bas débit », « ADSL » ou « LAN ».


Bande passante : 56Kb/s

Encodage en fonction du débit

Les vidéos sont codées pour respecter la bande passante du support de transmission choisi.

La bande passante est répartie en 3 sous-bandes : la vidéo : C’est toujours la bande passante utilisée pour la

vidéo qui sera réduite si nécessaire pour ne pas dépasser la bande passante choisie pour la transmission.

l’audio : jamais inférieure à 6,5 kbit/s le sur-débit : informations complémentaires (sous-titrage,

synchronisation son/image, renseignements sur les fichiers). Toujours 22 kbit/s

Ex. : Pour une bande passante de 56Kb/s, la répartition des sous-bandes peut se faire de la manière suivante :

Vidéo : 27,5Kb/s audio : 6,5Kb/s sur-débit : 22Kb/s

Vidéo : 26Kb/s audio : 8Kb/s sur-débit : 22Kb/s

Documents

Services multimédia1 Services multimédia sur réseaux – La vidéo sur IP A. Quidelleur [email protected] SRC2 Meaux 2008-2009 M22.4 - Réseaux