Le streaming des média à la demande sur Internet S. Natkin Février 2005

Objectifs Transfert de flux de données multimédia synchrones en diffusion, pour être joués en temps réel Par opposition au téléchargement des média Sans interactions « rapides »: radio pas téléphone

Application MPEG 4: critères de classification Contraintes temporelles Les applications sont classées selon qu'elles sont en temps réel ou non. Symétrie des moyens de transmission Les applications sont soit symétriques, soit asymétriques. Interactivité Les applications peuvent être interactives ou non interactives.

Application MPEG 4: les classes Temps réel symétrique interactive classe 1 non interactive sans application non symétrique classe 2 non temps réel classe 3 classe 4 classe 5

Application MPEG 4: Exemple classe 1 Visiotéléphonie Vidéotéléphonie multiple Vidéoconférence Travail de groupe Classe distante symétrique Expertise distante symétrique

Application MPEG 4: Exemple classe 2 Expertise distante asymétrique Contrôle distant et télésurveillance Collecte d'informations Classe distante asymétrique

Application MPEG 4: Exemple classe 3 et 4 Messages multimédia   Classe 4 Récupération de bases d'informations Jeux

Description d’une session cliente de type SMIL

Architecture type Serveur vidéo 1 Flux S3 Serveur audio 1 Flux S1 PC 1 :S1+S2 PC2 : S1+S2+S3 Téléphone : S1 TVI : S3

Terminologie « floue » revisitée par SN Objet média : unité continue et homogène de données d’un type définit existant (fichier) ou créé par captation ou synthèse en temps réel Flux (stream) multimédia: transfert de données résultant du transport d’un objet média Session : Vue homogéne pour un utilisateur ou un ensemble d’utilisateur interagissant via le réseau et utilisant des objets mutimédia des ressources disponibles et opérations possibles sur ces ressources Conférence: Ensemble d’utilisateurs ou d’entités informatiques ayant en commun un ou plusieurs flux multimédia

Synchronisation La synchronisation peut être relative: démarrer le flux audio1 7 s après la fin du flux vidéo2 Ou absolue :démarrer le flux audio1 au time code 00:07:00 du flux vidéo2 Evènementielle : démarrer le flux audio1 lorsque l’utilisateur clique sur le bouton start Ou continue: le time code du flux audio et vidéo doivent être égales

Sources Les sources des media peuvent être multiples (locales ou téléchargées, sur des serveurs distincts) Les capacités de traitement des serveurs inégales et peu prévisibles Les modes de compression sont variables: pré compression ou compression à la demande, adaptatives ou non adaptative

Problèmes techniques Assurer sur le client un débit constant Les messages étant traités dans l’ordre d’émission Délivrés selon des unités d’échantillonnage (une image un échantillon sonore) Selon une séquence synchrone et en synchronisant les différentes sources sur un réseau dont la technologie gère très mal les garanties de qualité de service gérer la diffusion: groupes de serveurs vers groupes de clients Plus accessoirement: Décrire les flux et sources multimédia Assurer la sécurité du transfert (gestion des droits sur les media) Optimiser l’utilisation des ressources réseau

Architecture de base Protocole de session De streaming Compresseur Non adaptatif Protocole de streaming Décompresseur Flux non compressé Mesure de Qos Mesure de Qos Compresseur adaptatif Protocole de signalisation Serveur Client

Une vue générale des protocoles temps réel Protocole de description du flux et de session : SDP, SMIL... Contôle du flux: RTSP Transport: RTP Réservation des ressources: RSVP, DiffServ

Architecture Internet and the result…

Problème de synchronisation du flux Internet est un réseau dont les performances sont très variables : les datagrammes peuvent traverser un nombre très variables de routeurs plus ou moins chargés. Les temps de propagation entre deux nœuds identiques de deux datgrammes identiques datagrammes peuvent varier de façon considérable (dans un rapport 1:100)

Exemple Délai moyen 10 ms, temps de décompression 3ms

Solution le bidon percé Comment transformer un débit asynchrone en un débit synchrone

Principe du protocole Mesure du temps de traversée max T Chargement d’un tampon 2 a 3 T Démarrage de l’écoute tampon Flux entrant ecoute

Exemple

Exemple qui ne marche pas 1

Mesure du QOS Nombre de paquets arrivés en retard (Jigue) Nombre de paquet perdus Délais A/R ….

Compensation d’erreur Pertes de messages Il est souvent préférable de ne rien faire que de retarder le flux Donc peut difficilement reposer sur une technique de détection par acquit et réémission (en général UDP et IP) A fortiori en diffusion Certains messages peuvent être perdus sans trop de dégats (les trames B en MPEG2 par exemple) Sinon il faut utiliser d’autre techniques

Compensation d’erreur par entrelacement Dans RealAudioTampons de 240 ms:12 blocs de 20 ms D’ou une attente d’au moins 5,2 s

Compensation d’erreur par code correcteur d’erreur Différentes autres approches avec des parités horizontales et verticales (comparable au RAID)

RTP/RTCP and RTSP Les protocoles multimédia pour l’Internet D’après vincent.roca@inrialpes.fr

Historique IETF Audio/Video Transport WG RTPv1 RFC 1889 (January 1996) RTPv2 draft-ietf-avt-rtp-new-09.txt (March 2001) Real-Time Protocol (RTP) « a framing protocol for real-time applications » Ne gère aucun mécanisme de QOS pour le temps réel Real-Time Control Protocol (RTCP) Mécanisme de mesure et de contrôle d’effort (comme ICMP) sans aucune garantie

Principes de conception Flexible mécanismes de bases qui peuvent être instanciés (H261, MPEG1/2/...) Peut s’appuyer sur des protocoles variés (UDP/IP, réseaux ATM privés...) Support de la diffusion: unicast, multicast, de 2 to  Sépare le contrôle et les données, certaines fonctions peuvent être déléguées à d’autres protocoles (i.e. RTSP)

Un scénario: A working group obtains an IP multicast address and a pair of ports through some allocation mechanism. One port for audio, one for control The address and the ports are distributed to intended participants. The participants send audio data in small chucks, 20ms duration. Each chuck of audio data is preceded with a RTP header, which indicates the type of encoding. The Internet may occasionally lose or reorder packets or delay the packet in variable amount time. To help the receiver reconstruct the timing produced by the sender, RTP header also include timing and sequence number information. Since the member may join and leave a group dynamically, it is useful to know who is participating and the audio quality at a given time. This task is done through RTCP.

Fonctions de gestion des donneés dans RTP Label de contenu (content labelling) Identification de la source Détection des pertes reséquencement Gestion du temps synchronisation intra-média : principe du bidon percé inter-media synchronisation: gestion d’un time code commun inter-média

Utilisation type Sur UDP Port UDP déterminé par ailleurs port RTCP = port UDP pour RTP + 1 Un média par session RTP/RTCP (i.e. port pair)

Indicateur de temps Temps RTP Valeur initiale aléatoire et indépendante pour chaque flux RTP timestamp dans chaque message Incrémentée du temps séparant la date de l’échantillon courant moins la date de l’échantillon précédent Temps NTP (wallclock time) temps absolu (format de Network Time Protocol) présent dans chaque rapport RTCP de l’émetteur (Sender Report) destiné à la synchronisation inter média

PDU RTP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | | timestamp | | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | | payload (audio, video...) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...| padding | count |

Contenu des champs P: Padding (1 bit), si les données sont plus petites que la taille du message (alignements à 4 octets). X: Extension(1 bit), l’en tête fixe est suivi d’un en tête variable (dépendant des applications). M: Marker, pour distinguer les évènements importants. PT: Payload type, type de contenu (PCM, ADPCM, etc) Timestamps: date RTP associée au premier octet de l’échantillon Sequence number field: Incrémenté à chaque PDU Synchronization SouRCe (SSRC) Identifie la source de façon unique Choisie aléatoirement (pas de nom unique négocié et faible probabilité de collisiosn Contributing SouRCe (CSRC) : Liste (dont le cardinal est donné par CC) qui identifie les sources avant traitement par un “mixer”

Mixers et Translators Mixers Translators Multiplexe les flots de plusieurs média en un seul pour diminuer le débit sur un réseau commuté Peut modifier le codage et la compression Définit une nouvelle source et un nouveau SSRC; SSRCs original dans la liste Translators Transformateur de protocole, translateur d’adresse (firewall…) Conserve les flots et les SSRCs originaux

Mixer end system 1 mixer end system 3 end system 2 from ES1: SSRC=6 from ES2: SSRC=23 from M: SSRC=52 CSRC list={6, 23} On ne mixe que des données de même type (audio, vidéo) Facilite la diffusion par multiplexage en cas de voies non homogènes

Translator end system 1 end system 2 transl.1 transl.2 from ES1: SSRC=6 from ES2: SSRC=23 transl.2 authorized tunnel firewall

Généralités sur RTCP Transmission périodique de messages de contrôle qui servent De mesure de la QOS de mesure d’écoute (nombre de récepteur A identifier une source par un nom unique CNAME (par exemple user@host) qui ne change pas (contrairement au SSRC) Permet d’établir une relation entre plusieurs flux de même origine sur le client

PDU RTCP SR sender reports statistiques (données transmises tx et données reçues rx) des émetteurs (serveurs) actifs RR receiver reports statistiques rx des récepteurs ou des émetteurs actifs au-delà de 31 sources SDES source description, comprenant CNAME BYE Départ du groupe APP PDU pour des extensions spécifiques aux application

RTCP généralitées Distribution Gestion de la charge générée Comme RTP c’est une diffusion de nm Plusieurs messages RTCP peuvent être concaténés par des translators/mixers (compound packet) Gestion de la charge générée Charge RTCP < 5% du total RTP+RTCP basée sur l’évaluation du nombre de participant période RTCP = f(nombre de participants) Au moins 25% de la charge RTCP est destiné aux information issues de la source Permet, entre autre d’identifie rapidement les sources

PDU SR SSRC de la source NTP timestamp date d’émission du rapport RTP timestamp estampille correspondante RTP packet count nombre total de messages envoyés octet count Suivi par une liste de rapport récepteur… exemple: SR sender report receiver SSRC source 2 source 3 RTCP packet

SR: sender report V=2 p rc PT=SR=200 length SSRC of sender NTP timestamp, MSW NTP timestamp, LSW RTP timestamp Sender’s packet count Sender’s octet count SSRC_1 (SSRC of first source), block 1 fraction lost cumulative number of packets lost extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC_2 (SSRC of second source), begin block 2 …. profile-specific extensions

RR: receiver report V=2 p rc PR=RR=201 length SSRC of sender SSRC of first source, begin block 1 Fraction lost (FL) cumlative number of packets lost extended highest sequence number received interarrival jitter last SR (LSR) delay since last SR (DLSR) SSRC of second source, begin block 2 ……. profile-specific extensions

PDU RR SSRC de la source identifie la source sur laquelle porte le rapport fraction lost depuis l’envoi de la dernière PDU RR (SR) (= int(256*lost/expected)) cumul des messages perdus Plus grand numéro de séquence de messages reçus Permet d’estimer expected interarrival jitter J=J+(|D(i-1,i)|-J)/16 avec D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si) LSR date de la dernière SR reçue DLSR temps écoulé depuis la réception de cette SR Délai AR à réception d’une RR: Date de réception-LSR-DLSR

PDU SDES 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT=SDES=202 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= | SSRC/CSRC_1 | chunk | SDES items =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_2 | chunk | SDES items +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Champs de SDES Pour chaque source peut contenir CNAME NAME nom d’utilisateur EMAIL PHONE LOC (localisation géogra^hique) TOOL (application) NOTE PRIV (extension privé)

Example of RTCP compound packet SR sender report receiver SSRC source 2 source 3 RTCP packet 1 SDES CNAME PHONE RTCP packet 2 compound packet (single UDP datagram)

profiles RTP RTP peut être instancié pour chaque média Exemple: MPEG1/2 Selon la recommandation RFC 2736, December 1999 Avec pour but « every packet received must be usefull !!! » Pour adapter les caractéristique du réseau (UDP/IP en particulier) aux contraintes du flux: ce qui est inutile, ce qui est important

Exemple de problème à résoudre: gestion de la fragmentation application application data unit Src RTP fragment 1 fragment 2 fragment 3 network tx LOST RTP fragment 1 fragment 2 Rx application uncomplete data!!! useless!!!

Implantations Bell Labs, Columbia Univ., Massachusetts Univ. RTP Library Version: 3.0 Beta (4/1997) An RTP implementations by the standard authors, source code available. http://www.bell-labs.com/topic/swdist/ Limburgs Universitair Centrum JVOIPLIB Version: 1.0 (11/2000) JVOIPLIB is an object-oriented Voice over IP (VoIP) library written in C++. http://lumumba.luc.ac.be/jori/jvoiplib/jvoiplib.html JavaSoft/Sun Microsystems Java Media Framework RTP application and library for audio/video session playback over IP networks. http://java.sun.com/products/java-media Limburgs Universitair Centrum and Universiteit Maastricht JRTPLIB Version: 2.4 (7/2000) JRTPLIB (Jori's RTP library) is a C++ library. http://lumumba.luc.ac.be/jori/jrtplib/jrtplib.html Live.com LIVE.COM Streaming Media Version: 1.0 (October 2000) This C++ code, distributed under a LGPL licence, forms a set of libraries that can be used within RTP/RTCP streaming applications, or can be extended to support additional media types and codecs (in addition to MP3 audio). http://live.sourceforge.net/ UCL Common Multimedia Library Version: 1.2.8 (May 2001) The UCL common multimedia library implements a number of algorithms and protocols (including RTP) needed by a number of our applications. http://www-mice.cs.ucl.ac.uk/multimedia/software/common/index.html

RTSP

Généralités RTSP IETF standard Real-Time Streaming Protocol RFC 2326 Real-Time Streaming Protocol Agit comme un gestionnaire réparti des conférences MM Réalise les operations suivantes: Recherche d’un média sur un serveur Gestion des participants à une conférence Suivi du déroulemnet

Principe du protocole (2) Mode caractère Independant du protocole support Intégre toute syntaxe de description (sdp, xml, etc.) Ressemble à HTTP mais Requêtes dans le deux sens (clients serveur) Contexte de session coté serveur Donnée transférée par une autre voie (hors bande) En point à point ou en diffusion

URL RTSP présentation Une piste audio de la présentation rtsp://media.example.com:554/twister Une piste audio de la présentation rtsp://media.example.com:554/twister/audio Hierarchie des noms de présentation hiérachie des média hiérachie des fichiers

Exemple d’échange PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00- RTSP/1.0 200 OK Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811 method to apply URL RTSP version seq# for request/response pair session identifier play starting at that offset for an undefined duration status code version seq# for request/response pair session identifier reason phrase

Méthodes RTSP Principales SETUP: Allocation par le serveur des ressources et début de session PLAY: Lire un flux PAUSE: Arrêt temporaire de lecture TEARDOWN: Fin de session, libération des ressources Annexes OPTIONS: Liste des méthodes utilisable ANNOUNCE: modifie la description d’un objet média DESCRIBE: demande la descrition détaillée d’un objet média RECORD: Demande d’enregistrement d’un flux REDIRECT: re direction d’un client vers un nouveau serveur SET_PARAMETER: d’un périphérique ou de l’encodage d’un média

Paramètres Accept media description formats Accept-Encoding encoding of media format Accept-Language human language Authorization basic and digest authentication Bandwidth client bandwidth available Conference conference identifier From name of requestor If-Modified-Since conditional retrieval Range time range to play Referer how did we get here? Scale (play time)/(real time) Speed speed-up delivery User-Agent software Cache Possibilté de stocker l’objet média en cache

Intégration dans le Web web avec le guide des programmes qui pointe sur une description de la preésentation (say, SMIL): <session> <group> <track src="rtsp://audio.mtv.com/movie"> <track src="rtsp://video.mtv.com/movie"> </group> </session> 3. RTSP gère la session 4. RSVP réserve les resources 5. RTP transporte les données 6. RTCP contrôle le transport

Exemple (1): media à la demande, point à point W A V C media descr. web server audio server video server client step 1: get description (in SDP format) step 2: open streams with RTSP step 3: play step 4: teardown

Exemple (2) HTTP GET web server W presentation description (sdp) SETUP client C HTTP GET presentation description (sdp) web server W SETUP media servers A & V PLAY RTP audio/video RTCP TEARDOWN

Example (2) : réception des descrpteurs via HTTP C->W: GET /twister.sdp HTTP/1.1 Host: www.example.com Accept: application/sdp W->C: HTTP/1.0 200 OK Content-Type: application/sdp v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session m=audio 0 RTP/AVP 0 a=control:rtsp://audio.example.com/twister/audio.en m=video 0 RTP/AVP 31 a=control:rtsp://video.example.com/twister/video

Example (3): ouverture des flux de média C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057 A->C: RTSP/1.0 200 OK Session: 12345678 Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001 C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059 V->C: RTSP/1.0 200 OK Session: 23456789 Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003

Exemple (4) play C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 2 Session: 23456789 Range: smpte=0:10:00- V->C: RTSP/1.0 200 OK Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq=12312232;rtptime=78712811

Exemple (5) play C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 2 Session: 12345678 Range: smpte=0:10:00- A->C: RTSP/1.0 200 OK Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://audio.example.com/twister/audio.en; seq=876655;rtptime=1032181 NB: use standard RTP synchronization methods for lip-sync!

Exemple6, Teardown C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0 CSeq: 3 Session: 12345678 A->C: RTSP/1.0 200 OK C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 Session: 23456789 V->C: RTSP/1.0 200 OK

Gestion du temps (1) NPT (normal play time) position relative au début de l’objet ou de la présentation spécifiée deuxformats: hours:minutes:seconds.subseconds seconds.subseconds exemple: npt= 10:07:00- 10:07:33 npt=121.45-125

Gestion du temps (2) SMPTE Temps absolu relative to au début d’un objet média format: hours:minutes:seconds:frames.subframes exemple: smpte-30-drop=10:07:00-10:07:33:05.01 Temps absolu selon ISO 8601, using UTC/GMT exemple: current time is 20010829T114501.00Z date (yyyymmdd) heure (hhmmss.sub)

Gestion du temps (3) Permet une gestion du temps absolu exemple: start playing movie at 20010829T114501.00Z, at npt= 10:07:00 Peut servir à la sychronisation répartie A la précision de NTP près Permet une certaine forme d’édition des média (genre smil)

communications RTSP Trois modes d’utilisation du transport dans le sens client/serveur connexion de transport persistante (TCP) pour une suite de Une connexion (TCP) par requêtes/réponses (mode HTTP 1.0) Sans connexion (UDP) Définit par l’ URL: « rtsp » connexion de transport persistante « rtspu » sans connexion Seul les connexions de transports persistantes sont utilisées dans le sens serveur/client

Invitation client utilise SETUP et les patamètres transport/conference Invite un serveur d’ajouter un flux d’un nouveau media dans une présentation existante client utilise SETUP et les patamètres transport/conference

Invitation d’un serveur d’ajouter un objet sonore à une connexion C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 1 Accept: application/sdp M->C: RTSP/1.0 200 1 OK Content-type: application/sdp Content-Length: 44 v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session i=See above t=0 0 m=audio 0 RTP/AVP 0

suite C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 Transport: RTP/AVP;multicast;destination=225.219.201.15; port=7000-7001;ttl=127 Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr M->C: RTSP/1.0 200 OK Session: 91389234234 C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 3

Implémentations (by Schulzrinne) Apple Darwin QuickTime Streaming Server server MacOS, unix SDP open source, full RTP/RTSP server Apple QuickTime 4 client MacOS, Windows SDP QuickTime 4 also supports importing SDP files that describe multicasts, with standard decoders. Cern Wrtp Columbia University rtspd server NT, Solaris SDP no container files Entera Entera Lightweight Streaming Application server Window, unix SDP IBM RTSP Toolkit KOM TU-Damstadt KOM-Player player Linux, AIX SDP MPEG-1 System; alternative RTSP server for IBM's VideoCharger nCUBE Corporation rtspsrv server Transit SDP Delivers MPEG-2 video over ATM, QAM, or DVB-ASI; no RTP delivery. Oracle Corporation Oracle Video Server client, server Windows, unix SDP MPEG-1 Systems, MPEG-2 Transport, AVI codecs. ATM, QAM, IP, DVB-ASI. No RTP delivery. Real Networks Real Networks proxy kit (firewall) server Windows, unix SDP, RTSL Real Networks RealServer G2 server Windows, unix SDP, SMIL supports RTP for RTP-based clients Real Networks "Hosting" server server Windows, unix Streams .au and .wav files over RTP when configured for multicast. Sun JMF 2.1 client Solaris, Windows, MacOS Sun MediaCentral server server Solaris Vovida server Linux Open source, RECORD and PLAY

Bibliographie General Schulzrinne, IRT (Internet Real-Time) lab, http://www.cs.columbia.edu/~hgs/research/IRT RTP Schulzrinne, Casner, Frederick, Jacobson, « RTP, a tranport protocol for real-time applications », IETF, work in progress, <draft-ietf-avt-rtp-new-09.txt>, March 2001. Schulzrinne, RTP home page, http://www.cs.columbia.edu/~hgs/rtp/ RTSP Schulzrinne, Rao, Lanphier, « Real-Time Streaming Protocol (RTSP) », IETF, Request For Comments 2327, April 1998. Schulzrinne, RTSP home page, http://www.cs.columbia.edu/ ~hgs/rtsp/