La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Le streaming des média à la demande sur Internet S. Natkin Février 2005."— 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éelsymétriqueinteractiveclasse 1 non interactivesans application non symétriqueinteractiveclasse 2 non interactivesans application non temps réelsymétriqueinteractiveclasse 3 non interactivesans application non symétriqueinteractiveclasse 4 non interactiveclasse 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 Classe 3 Messages multimédia Classe 4 Récupération de bases d'informations Jeux

8 Description dune session cliente de type SMIL

9 Architecture type Serveur vidéo 1 Flux S3 Serveur audio 1 Flux S1 Serveur audio 2 Flux S2 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 dun 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 dun objet média Session : Vue homogéne pour un utilisateur ou un ensemble dutilisateur interagissant via le réseau et utilisant des objets mutimédia des ressources disponibles et opérations possibles sur ces ressources Conférence: Ensemble dutilisateurs ou dentité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 lutilisateur 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 lordre 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 lutilisation des ressources réseau

14 Architecture de base Compresseur adaptatif Compresseur Non adaptatif Protocole de streaming Décompresseur Protocole de signalisation Mesure de Qos Flux non compressé Protocole de session De streaming 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 dun tampon 2 a 3 T Démarrage de lécoute tampon Flux entrant ecoute

21 Exemple

22 Exemple qui ne marche pas 1111

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

24 Compensation derreur 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 dautre techniques

25 Compensation derreur par entrelacement Dans RealAudioTampons de 240 ms:12 blocs de 20 ms Dou une attente dau moins 5,2 s

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

27 RTP/RTCP and RTSP Les protocoles multimédia pour lInternet Daprès

28 Historique IETF Audio/Video Transport WG –RTPv1RFC 1889 (January 1996) –RTPv2draft-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 deffort (comme ICMP) sans aucune garantie

29 Principes de conception Flexible mécanismes de bases qui peuvent être instanciés (H261, MPEG1/2/...) Peut sappuyer 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 à dautres 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 dun 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), len tête fixe est suivi dun 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 –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 dadresse (firewall…) –Conserve les flots et les SSRCs originaux

37 Mixer end system 1 end system 2 mixer end system 3 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 from ES1: SSRC=6 from ES2: SSRC=23 transl.2 from ES2: SSRC=23 from ES1: SSRC=6 authorized tunnel firewall from ES2: SSRC=23 from ES1: SSRC=6

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 SRsender reports statistiques (données transmises tx et données reçues rx) des émetteurs (serveurs) actifs RRreceiver reports statistiques rx des récepteurs ou des émetteurs actifs au- delà de 31 sources SDESsource description, comprenant CNAME BYEDépart du groupe APP PDU pour des extensions spécifiques aux application

41 RTCP généralitées Distribution –Comme RTP cest 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 didentifie rapidement les sources

42 PDU SR –SSRC de la source –NTP timestampdate démission du rapport –RTP timestampestampille 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 report receiver report SSRC source 2source 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 Senders packet count Senders octet count SSRC_1 (SSRC of first source), block 1 Senders packet count 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 lenvoi 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 destimer expected –interarrival jitter J=J+(|D(i-1,i)|-J)/16 avec D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si) –LSRdate de la dernière SR reçue –DLSRtemps écoulé depuis la réception de cette SR Délai AR à réception dune RR: Date de réception-LSR- DLSR

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

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

48 Example of RTCP compound packet SR sender report receiver report receiver report SSRC source 2source 3 RTCP packet 1 SDES CNAME PHONE SSRC 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 data unit fragment 1 fragment 2 fragment 3 application RTP network tx fragment 2fragment 1 LOST RTP uncomplete data!!! application useless!!! Src Rx

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 CentrumJVOIPLIB Version: 1.0 (11/2000) JVOIPLIB is an object-oriented Voice over IP (VoIP) library written in C++. JavaSoft/Sun MicrosystemsJava Media Framework RTP application and library for audio/video session playback over IP networks. Limburgs Universitair Centrum and Universiteit MaastrichtJRTPLIB Version: 2.4 (7/2000) JRTPLIB (Jori's RTP library) is a C++ library. Live.comLIVE.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). UCLCommon 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 –RFC 2326 Real-Time Streaming Protocol –Agit comme un gestionnaire réparti des conférences MM Réalise les operations suivantes: –Recherche dun 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 rtsp://media.example.com:554/twister Une piste audio de la présentation rtsp://media.example.com:554/twister/audi o 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 CSeq: 2 Session: Range: smpte=0:10:00-0:20:00 RTP-Info: url=rtsp://video.example.com/twister/video; seq= ;rtptime= seq# for request/response pair session identifier method to applyURLRTSP version play starting at that offset for an undefined duration status codeversion 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 dun objet média –DESCRIBE:demande la descrition détaillée dun objet média –RECORD:Demande denregistrement dun flux –REDIRECT:re direction dun client vers un nouveau serveur –SET_PARAMETER:dun périphérique ou de lencodage dun 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 CachePossibilté de stocker lobjet média en cache

59 Intégration dans le Web 1.web avec le guide des programmes 2. qui pointe sur une description de la preésentation (say, SMIL): 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 video server audio server media descr. web server client step 1: get description (in SDP format) step 2: open streams with RTSP step 3: play step 4: teardown C W AV

61 Exemple (2) client C web server W media servers A & V HTTP GET presentation description (sdp) SETUP 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 CSeq: 1 Session: Transport: RTP/AVP/UDP;unicast;client_port= ; server_port= C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 1 Transport: RTP/AVP/UDP;unicast;client_port= V->C: RTSP/ OK CSeq: 1 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 CSeq: 2 Session: 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 CSeq: 2 Session: 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 CSeq: 3 C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0 CSeq: 3 Session: V->C: RTSP/ OK CSeq: 3

67 Gestion du temps (1) NPT (normal play time) –position relative au début de lobjet 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 –relative to au début dun 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 dutilisation 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 Invite un serveur dajouter un flux dun nouveau media dans une présentation existante client utilise SETUP et les patamètres transport/conference

72 Invitation dun serveur dajouter 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 CSeq: 2 Transport: RTP/AVP;multicast;destination= ; port= ;ttl=127 Session: Conference: C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 3 Session: M->C: RTSP/ OK CSeq: 3

74 Implémentations (by Schulzrinne) AppleDarwin QuickTime Streaming ServerAppleDarwin QuickTime Streaming Server serverMacOS, unixSDPopen source, full RTP/RTSP server Apple QuickTime 4AppleQuickTime 4 clientMacOS, Windows SDP QuickTime 4 also supports importing SDP files that describe multicasts, with standard decoders. CernWrtpCernWrtp Columbia UniversityrtspdColumbia Universityrtspd serverNT, Solaris SDP no container files EnteraEntera Lightweight Streaming ApplicationEnteraEntera Lightweight Streaming Application serverWindow, unix SDP IBM RTSP ToolkitIBMRTSP Toolkit KOM TU-Damstadt KOM-PlayerKOM TU-DamstadtKOM-Player playerLinux, AIX SDP MPEG-1 System; alternative RTSP server for IBM's VideoCharger nCUBE Corporation rtspsrvnCUBE Corporation serverTransit SDP Delivers MPEG-2 video over ATM, QAM, or DVB-ASI; no RTP delivery. Oracle Corporation Oracle Video ServerOracle CorporationOracle Video Server client, server Windows, unixSDP MPEG-1 Systems, MPEG-2 Transport, AVI codecs. ATM, QAM, IP, DVB-ASI. No RTP delivery. Real Networks proxy kit (firewall) Real Networks server Windows, unix SDP, RTSL Real Networks RealServer G2Real NetworksRealServer G2 serverWindows, unix SDP, SMIL supports RTP for RTP-based clients Real Networks "Hosting" serverReal Networks"Hosting" server server Windows, unixStreams.au and.wav files over RTP when configured for multicast. Sun JMF 2.1SunJMF 2.1 client Solaris, Windows, MacOS Sun MediaCentral serverSunMediaCentral server server Solaris Vovida serverLinuxOpen 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,, March –Schulzrinne, RTP home page, RTSP –Schulzrinne, Rao, Lanphier, « Real-Time Streaming Protocol (RTSP) », IETF, Request For Comments 2327, April –Schulzrinne, RTSP home page, ~hgs/rtsp/


Télécharger ppt "Le streaming des média à la demande sur Internet S. Natkin Février 2005."

Présentations similaires


Annonces Google