Le streaming des média à la demande sur Internet

Présentation au sujet: "Le streaming des média à la demande sur Internet"— Transcription de la présentation:

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

2 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

3 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.

4 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

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

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

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

8 Description d’une session cliente de type SMIL

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 Architecture Internet
and the result…

17 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)

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

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

20 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

21 Exemple

22 Exemple qui ne marche pas
1

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

24 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

25 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

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

27 RTP/RTCP and RTSP Les protocoles multimédia pour l’Internet
D’après

28 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

29 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)

30 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.

31 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

32 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)

33 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

34 PDU RTP |V=2|P|X| CC |M| PT | sequence number | | timestamp | | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | | | payload (audio, video...) | | | | padding | count |

35 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”

36 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

37 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

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

39 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 qui ne change pas (contrairement au SSRC) Permet d’établir une relation entre plusieurs flux de même origine sur le client

40 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

41 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

42 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

43 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

44 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

45 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

46 PDU SDES |V=2|P| SC | PT=SDES=202 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= | SSRC/CSRC_ | chunk | SDES items =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC/CSRC_ | chunk | SDES items =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

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

48 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)

49 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

50 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!!!

51 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. Limburgs Universitair Centrum JVOIPLIB Version: 1.0 (11/2000) JVOIPLIB is an object-oriented Voice over IP (VoIP) library written in C++. JavaSoft/Sun Microsystems Java Media Framework RTP application and library for audio/video session playback over IP networks. Limburgs Universitair Centrum and Universiteit Maastricht JRTPLIB Version: 2.4 (7/2000) JRTPLIB (Jori's RTP library) is a C++ library. 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). UCL Common Multimedia Library Version: (May 2001) The UCL common multimedia library implements a number of algorithms and protocols (including RTP) needed by a number of our applications.

52 RTSP

53 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

54 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

55 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

56 Exemple d’échange PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2 Session: Range: smpte=0:10:00- RTSP/ OK Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq= ;rtptime= 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

57 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

58 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

59 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

60 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

61 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

62 Example (2) : réception des descrpteurs via HTTP
C->W: GET /twister.sdp HTTP/1.1 Host: Accept: application/sdp W->C: HTTP/ OK Content-Type: application/sdp v=0 o= IN IP 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

63 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= A->C: RTSP/ OK Session: Transport: RTP/AVP/UDP;unicast;client_port= ; server_port= C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 Transport: RTP/AVP/UDP;unicast;client_port= V->C: RTSP/ OK Session: Transport: RTP/AVP/UDP;unicast;client_port= ; server_port=

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

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

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

67 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=

68 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 T Z date (yyyymmdd) heure (hhmmss.sub)

69 Gestion du temps (3) Permet une gestion du temps absolu
exemple: start playing movie at T Z, 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)

70 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

71 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

72 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/ OK Content-type: application/sdp Content-Length: 44 v=0 o= IN IP s=RTSP Session i=See above t=0 0 m=audio 0 RTP/AVP 0

73 suite C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 2 Transport: RTP/AVP;multicast;destination= ; port= ;ttl=127 Conference: M->C: RTSP/ OK Session: C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 3

74 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

75 Bibliographie General
Schulzrinne, IRT (Internet Real-Time) lab, 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, RTSP Schulzrinne, Rao, Lanphier, « Real-Time Streaming Protocol (RTSP) », IETF, Request For Comments 2327, April 1998. Schulzrinne, RTSP home page, ~hgs/rtsp/