Streaming multimedia II

Transcription

1 Streaming multimedia II Protocoles Alain Mérigot Université Paris sud A. Mérigot Streaming multimedia II 1 / 49

2 Applications multimédia internet Différentes applications Accès à des fichiers préenregistrés Diffusion en direct Vidéoconférence Toutes ces application nécessitent des protocoles spécifiques pour traiter des données temps-réel RTP (Real time protocol) et le protocole associé RTCP (Real-time control protocol) RSVP (reservation de ressource au niveau du routage) QoS Quality of Service A. Mérigot Streaming multimedia II 2 / 49

3 Applications multimédia internet Autres protocoles et méthodes impliqués Vidéo préenregistrée sur un serveur de streaming RTSP (Real Time Streaming Protocole) permet de controler une session de streaming et d intéragir avec un serveur Diffusion en direct Multicast Vidéoconference SIP (Session Initiation Protocole) Initiation de session, gestion et terminaison A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 3 / 49

4 Applications multimédia internet A. Mérigot Streaming multimedia II 4 / 49

5 TCP Rappel des fonctionnalités de TCP : les applications sur un hote créent une connexion entre émetteur et récepteur une transmission fiable et correctement ordonnée des données de l émetteur vers le récepteur est garantie. les segments TCP sont numérotés pour ordonner les données reçues des sommes de contrôle (checksums) permettent de détecter les erreurs utilisation d acquitements et de temporisation pour détecter les pertes de paquets la protection contre les erreurs est réalisée par retransmission et détecttion de débordement de temps (time-out) le délai de transmission est imprédictible ne peut pas être utilisé pour des applications temps-reél A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 5 / 49

6 UDP Rappel : fonctionnalités UDP service de transport de datagrammes simple, mais non fiable aucune fiabilité, ni aucun ordonnancement des paquets n est garanti les datagrammes peuvent arriver dans le désordre ou être perdus sans notification des checksums sont utilisées pour détecter les paquets contennant des erreurs rapide et efficace pour des applications pour lesquelles le temps est important meilleur choix pour une transmission vidéo temps-réel A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 6 / 49

7 UDP Lite The lighweight User Datagram Protocol Protocole non connecté similaire à UDP Une somme de contrôle n est appliquée que sur un sous ensemble des données Source Destination Port Port Checksum Coverage Checksum : Payload : A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 7 / 49

8 UDP Lite Checksum Coverage est le nombre d octets, à partir du premier octet de l entête UDP-Lite, qui sont pris en compte dans la checksum (remplace le champ length d UDP) Un paquet défecteux serait éliminé par UDP Il peut être conservé par UDP-Lite, à condition que l erreur soit en dehors de la zone de checksum coverage. Il est peut-être meilleur pour des applications audio et vidéo d obtenir des données partiellement corrompues que aucun paquet! Utilise un autre port IP qu UDP (136). A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 8 / 49

9 Real Time Protocole (RTP) RTP est une extension d UDP (ou optionnellement TCP) Concerne la couche 7 OSI (couche application) Installé entre UDP et l application Implementé par une bibliothèque applicative Ses objectifs Mise en paquet Multiplexage Synchronisation Détection d erreurs Identification du contenu Peut être utilisé dans différentes configurations : un-vers-un, un-vers-beaucoup, beaucoup-vers-beaucoup,... RTP consiste en une partie transfert de données et une partie contrôle (RTCP) RFC 3550 A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 9 / 49

10 Real Time Protocole (RTP) Paquets RTP Consiste en une entête RTP, des entêtes optionnelles pour le chargement et le chargement (payload) lui-même surcoût RTP = 12 octets surcoût IP+UDP+RTP = = 40 octets Entête: Payload Type: 7 bits, 128 types d encodage différents; eg PCM, MPEG2 vidéo, etc. Payload type Sequence number Timestamp Synchronization source identif. Miscellanous fields A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 10 / 49

11 Real Time Protocole (RTP) Types de chargements pour les formats audio and vidéo Index Format audio Freq. d echt Debit 0 PCM µ 8 khz 64 kb/s khz 4.8 kb/s 3 GSM 8 khz 13 kb/s 7 LPC 8 khz 2.4 kb/s 9 G khz kb/s 14 MPEG audio 90 khz variable 15 G khz 16 kb/s Index Format vidéo 26 Motion JPEG 31 H MPEG 1 vidéo 33 MPEG 2 vidéo A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 11 / 49

12 Real Time Protocole (RTP) Sequence Number: 16 bits; permet de détecter une perte de paquet Timestamp: 32 bits; Indique la date d échantillonage du premier octet audio/vidéo du paquet; Supprime la gigue du réseau Synchronization Source identifier (SSRC): 32 bits; identifie une source de données; générée aléatoirement par la source Payload type Sequence number Timestamp Synchronization source identif. Miscellanous fields A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 12 / 49

13 Real Time Protocole (RTP) marquages temporels et numéro de séquence le marquage temporel (Timestamp) est relatif à un instant réel Obtenu par une horloge média specifique le numéro de séquence donne l ordre relatif du paquet Ces informations sont complementaires et doivent être utilisées ensemble et doivent être utilisées simultanément pour traiter des pertes de paquets A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 13 / 49

14 Real Time Protocole (RTP) Exemple : comment traiter les silences audio? Quel est la meilleure manière de traiter les silences? Ne rien envoyer!! Quel problème cela peut-il créer? On doit distinguer entre un silence et la perte d un paquet (qui peut nécessiter une interpolation) Le récepteur utilise simultanément le marquage temporel et le numéro de séquence pour prendre la décision A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 14 / 49

15 Real Time Protocole (RTP) RTP Control Protocol (RTCP) Utilisé conjointement avec RTP. Echange d informations de contrôle entre émetteur et récepteur. Fournit un retour sur la qualité de la distribution de données. Trois types de reports : réception, émission et description de source Les rapports contiennent des statistiques Nombre de paquets envoyés Nombre de paquets reçus Gigue (jitter) La bande passante RTCP doit être limitée à 5% de la bande passante. Environ un rapport émetteur pour 3 rapports récepteurs A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 15 / 49

16 Real Time Protocole (RTP) Paquets RTCP SR (rapport émetteur) Utilisé pour des statistiques de transmission et de reception des hotes qui sont des émetteurs actifs RR (rapport récepteur) Utilisé pour des statistiques de transmission et de reception des hotes qui ne sont pas des émetteurs actifs SDES (description de source), incluant CNAME (Canonical Name identicateur de source RTP) BYE - Indique une fin de participation APP - operations specifique à une application A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 16 / 49

17 Real Time Protocole (RTP) A. Mérigot Streaming multimedia II 17 / 49

18 Real Time Protocole (RTP) Informations fournies par RTCP au moyen de rapports émetteur et récepteur (SR et RR) compte de paquets Le nombre de paquets attendu pendant un intervalle est donné par la différence entre les numéros de séquence les plus hauts La perte de paquets durant un intervalle entre deux receptions de rapports est donné par la différence entre les nombres cumulatifs de pertes de paquets le pourcentage de pertes sur l intervalle est donné dans le rapport RR ou calculé comme le rapport entre les deux précédents. Le taux de pertes par seconde est simplement obtenu en divisant la fraction perdue par la différence entre les marquages temporels NTP entre deux rapports. le nombre de paquets reçus est le nombre de paquets attendus moins le nombre de paquets perdus. Utile pour qualifier la validité statistique du taux de perte. A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 18 / 49

19 Real Time Protocole (RTP) Informations fournies par RTCP au moyen des rapports émetteur et récepteur (suite...) Timestamps. Utilies pour calculer le temps d aller et retour (Round-Trip Time RTT). Nécessite l émission d un rapport SR et RR. Estimation de la bande passante disponible. Disponible pour un récepteur donné comme le nombre de paquets reçus durant une période multiplié par la taille moyenne du chargement Gigue à l arrivée. Calculée par le récepteur (et probablement utilisée pour determiner le délai de restitution). Information utile à l émetteur, car elle donne une mesure rapide de la congestion du réseau (avant même une perte de paquet). L utilisation de compte cumulatifs dans les rapports émetteur et récepteur permet de calculer les differences entre deux rapports (mesure sur une longue période), et permet de résister à la perte d un rapport. A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 19 / 49

20 Real Time Protocole (RTP) Paquetization RTP Basée sur l information fournie par la couche vidéo. Le codeur vidéo organie l information en paquets: Paquetized Elementatry Streams (MPEG), NALU (Network abstraction layer units) (H264). Ces informations correspondent aux paquets réseau. La paquetization network friendly (comme les NALUs H264) aide l émetteur à réaliser une paquetization efficace. La priorité des paquets est indiquée Les données inutiles (cad indecodable à cause de pertes) peuvent être detectées sans nécessité de décoder tout le flot de bits Les informations importantes peuvent être detectées : Instantaneous Decodeur Refresh IDR (images I) Parameter sets, réémis en cas de perte Transmission flexible: les NALUs correspondent en general aux paquets RTP, mais ils peuvent être fragmentés en plusieurs paquets or aggregés, avec plusieurs NALU dans un paquet RTP. A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 20 / 49

21 Real Time Protocole (RTP) Résumé RTP Supporte unicast ou multicast Fournit correctement le sequencement le temps la synchroniaation utilisé optionnellement avec RTCP Mis en oeuvre dans l application Complètement indépendant des protocoles sous jacents Ne fournit aucun mecanisme pour : Assurer une livraison à temps qualité de service Uniquement un cadre de protocole qui doit être adapté à une application specifique A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 21 / 49

22 RealTime Streaming Protocole (RTSP) Streaming de contenu multimédia préenregistré Les données Audio/Vidéo sont mises en paquet et envoyées par UDP (de préférence) ou TCP, avec RTP (Real-Time Protocole) Réalisé par le serveur de streaming Une interaction entre utilisateur et serveur est fournie par le Real Time Streaming Protocole (RTSP) A. Mérigot Streaming multimedia II 22 / 49

23 RealTime Streaming Protocole (RTSP) Le protocole est mis en oeuvre par l application de visualisation du média (media player) (avec ou sans navigateur WEB) RealPlayer, WMP, QT, vidéolan. Realise : Décompression. Suppression de la gigue Correction des erreurs au moyen des paquets redondants pour permettre une reconstruction correcte du flux original Controle de l utilisateur (pause, rewind, etc) A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 23 / 49

24 RealTime Streaming Protocole (RTSP) Streaming depuis un serveur WEB Audio et vidéo envoyées comme des objets HTTP Méthode la plus simple : le navigateur demande les objets Après réception il les envoie au media player pour visualisation Nécessite une transmission complète A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 24 / 49

25 RealTime Streaming Protocole (RTSP) Utilisation d un serveur WEB. A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 25 / 49

26 RealTime Streaming Protocole (RTSP) Alternative: mettre en place une connection directe entre le serveur et le media player Le navigateur demande et reçoit un Meta Fichier qui décrit la méthode pour accéder aux objets et non le fichier media lui-même; Le navigateur lance le média player et lui donne le metafichier; Le média player établit une connection RTP avec le serveur streaming et reçoit les données multimédia A. Mérigot Streaming multimedia II 26 / 49

27 RealTime Streaming Protocole (RTSP) Utilisation d un serveur de streaming : reception du métafichier A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 27 / 49

28 RealTime Streaming Protocole (RTSP) Utilisation d un serveur de streaming : reception en streaming du media A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 28 / 49

29 RealTime Streaming Protocole (RTSP) Real Time Streaming Protocole (RTSP) Permet de controler l affichage : rewind, pause, fast forward, etc Utilise une connection hors-bande séparée : une pour le controle (Port 554) et une pour le flux. RFC 2326 Peut utiliser TCP ou UDP pour le canal de controle (cancl RTSP) Un metafichier est envoyé au navigateur web pour lancer le client de visualisation. Le client établit une connection RTSP pour le controle et une connection RTP pour le flot multimédia A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 29 / 49

30 RealTime Streaming Protocole (RTSP) Exemple de metafichier <title>twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="pcmu/8000/1" src="rtsp://audio.exemple.com/twister/audio.en/lofi"> <track type=audio e="dvi4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.exemple.com/twister/audio.en/hifi"> </switch> <track type="vidéo/mpeg" src="rtsp://vidéo.exemple.com/twister/vidéo"> </group> </session> A. Mérigot Streaming multimedia II 30 / 49

31 RealTime Streaming Protocole (RTSP) Opérations RTSP A. Mérigot Streaming multimedia II 31 / 49

32 RealTime Streaming Protocole (RTSP) Méthodes RTSP OPTIONS get available methods SETUP establish transport ANNOUNCE change description of média object DESCRIBE get (low-level) description of média object PLAY start playback, reposition RECORD start recording REDIRECT redirect client to new serveur PAUSE halt delivery, but keep state SET PARAMETER device or encoding control TEARDOWN remove state A. Mérigot Streaming multimedia II 32 / 49

33 RealTime Streaming Protocole (RTSP) Entêtes des requêtes Accept media description formats Accept-Encoding encoding of média 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 Utilisateur-Agent software A. Mérigot Streaming multimedia II 33 / 49

34 RealTime Streaming Protocole (RTSP) entêtes des réponses Location redirection Proxy-Authenticate authenticate to proxy Public methods supported Retry-After busy; come back later Serveur server software Vary cache tag WWW-Authenticate request authorization A. Mérigot Streaming multimedia II 34 / 49

35 RealTime Streaming Protocole (RTSP) La conception de RTSP est similaire à HTTP protocol format: text, entêtes MIME request/response status codes security mechanisms URL format negotiation du contenu supporte toute description de session Controle les pistes (audio, vidéo) et la présentation (film) A. Mérigot Streaming multimedia II 35 / 49

36 SIP: Session Initiation Protocol Vidéoconference interactive Comment trouver la personne avec qui je veux discuter? Avec quel équipement? Quelle est son addresse? Comment contrôler son état (active/absente)? Comment authentifier son identité? Comment avoir une passerelle entre fournisseurs? Session Initiation Protocol (SIP) A. Mérigot Streaming multimedia II 36 / 49

37 SIP: Session Initiation Protocol Un protocole de signalisation pour : initier, gérer terminer une session de communication interactive Peut être utilisé pour des messageries instantanées (MSN, AIM), de la téléphonie internet (VoIP), vidéoconference, etc. Développé par l Internet Engineering Task Force (IETF) IETF RFC 3261 Connectivité with IP Peut être étendu pour des services comme : controle d appel, mobilité, interoperabilité evc la téléphonie standard, etc. NB : Ne transporte aucun média. Utiliser RTP A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 37 / 49

38 SIP: Session Initiation Protocol Entitités dans le protocole SIP User Agent (téléphones, clients logiciel) les User Agent Client (UAC) font des requêtes les User Agent Server (UAS) acceptent les requêtes Redirect Server Proxy Server Registrar Permet d enregistrer et d authentifier un utilisateur Ex : pierre@thishost.thisdomain.com on Location server A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 38 / 49

39 SIP: Session Initiation Protocol Methodes SIP INVITE ACK OPTIONS CANCEL BYE REGISTER Session request Answer to an INVITE Asks for server capacities Cancels a pending request Ends a session Sends to the server an user address A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 39 / 49

40 SIP: Session Initiation Protocol Réponses SIP 1XX Provisional 100 Trying 2XX Successful 200 OK 3XX Redirection 302 Moved Temporarily 4XX Client Error 404 Not Found 5XX Server Error 504 Server Time-out 6XX Global Failure 603 Decline A. Mérigot Streaming multimedia II 40 / 49

41 SIP: Session Initiation Protocol Exemple d une requête INVITE INVITE sip:e9-airport.mit.edu SIP/2.0 From: "Dennis Baron"<sip: @mit.edu>;tag=1c41 To: sip:e9-airport.mit.edu Call-Id: call @ Cseq: 1 INVITE Contact: "Dennis Baron"<sip: @ > Content-Type: application/sdp Content-Length: 304 Accept-Language: en Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE Supported: sip-cc, sip-cc-01, timer, replaces User-Agent: Pingtel/ (WinNT) Date: Thu, 30 Sep :28:42 GMT Via: SIP/2.0/UDP A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 41 / 49

42 SIP: Session Initiation Protocol Initiation de session point-à-point et terminaison A. Mérigot Streaming multimedia II 42 / 49

43 SIP: Session Initiation Protocol Redirection d appel avec un serveur de redirection A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 43 / 49

44 SIP: Session Initiation Protocol Utilisation d un serveur proxy A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 44 / 49

45 SIP: Session Initiation Protocol Applications SIP Point à point Ex : MSN Messenger et Windows Messenger, AIM, Yahoo, et ichat Multipoint Interoperabilité avec H.323 A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 45 / 49

46 SIP: Session Initiation Protocol Standards SIP RFC3261 Core SIP specification obsoletes RFC2543 RFC2327 SDP Session Description Protocol RFC1889 RTP Real-time Transport Protocol RFC2326 RTSP Real-Time Streaming Protocol RFC3263 Locating SIP servers SRV and NAPTR RFC3264 Offer/answer model for SDP use with SIP RFC3265 SIP event notification SUBSCRIBE and NOTIFY RFC3266 IPv6 support in SDP RFC3361 Locating outbound SIP proxy with DHCP RFC3428 SIP extensions for Instant Messaging RFC3515 SIP REFER method eg. call transfer SIMPLE IM/Presence Etc. A. Mérigot Streaming multimedia II 46 / 49

47 SIP: Session Initiation Protocol SIP et H.323 H.323 est un standard ITU ancien Fonctionnalités similaires, mais : plus complexe, utilise une codage binaire, basé sur un ensemble de protocoles enfouis pour les différentes taches Les deux protocoles sont acceptés par l IETF et l ITU A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 47 / 49

48 Session Description Protocol (SDP) SDP est un protocole pour décrire une session multimédia : announce, invitation et initiation. Une session multimédia est une ensemble de média flux qui existent pour un certain temps. RFC SDP inclut : le type de média (vidéo, audio, etc.) protocole de transport (RTP/UDP/IP, H.320, etc.) le format du média (H.264 vidéo, MPEG vidéo, etc.) des informations pour retrouver ces média (addresses, ports, formats, etc) Peut être utilisé avec SIP, RTSP, etc... A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 48 / 49

49 Conclusion Différents protocoles pour le streaming multimédia RTP/RTCP est toujours utilisé pour le transport du média RTSP permet l interaction avec un serveur de média préenregistrés SIP utilisé pour la gestion des sessions intéractives (vidéoconferenc, téléphonie) SDP décrit une session vidéo multicast, RSVP A. Mérigot (alain.merigot@u-psud.fr) Streaming multimedia II 49 / 49