Les protocoles temps réel

Streamming : architecture et service Dominique PRESENT I.U.T. de Marne la Vallée Les protocoles temps réel RSVP (Ressource ReSerVation Protocol) : 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 Une Règle de Contrôle (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 ressource pour fournir la QoS demandée. RTP (Real-time Transport Protocol) assure la reconstruction temporelle, la détection de perte, la sécurité et l'identification du contenu. travaille avec le protocole RTCP pour obtenir des feed-back 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 prendre garde aux problèmes liés au temps. RTP tourne au-dessus de UDP En-tête IP En-tête UDP En-tête RTP Données vidéo temps-réel Les protocoles temps réel RTCP (Real-Time Control Protocol) périodiquement des paquets RTCP envoie des informations sur la qualité du service délivrée. Travaille avec RTP. RTCP offre les services suivants : Contrôle de la congestion et monitoring de la QoS ; Identification de la source ; Synchronisation inter-média ; Information de contrôle RTSP (Real-Time Streaming Protocol) 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. Les données quant à elles sont transmises séparément en utilisant le plus souvent RTP. 1

Session multimédia «temps réel» Serveur «temps réel» Application «temps réel» RTP UDP RTCP 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 Routeur RSVP Routeur RSVP Application «temps réel» RTP Client RTCP UDP Routeur RSVP RSVP Video en ligne : le streaming 1 - test de performance de la liaison Versions du fichier 2 - création d un buffer pouvant stocker 28Kb/s 56Kb/s 512Kb/s «n secondes» de vidéo 3 - transmission des paquets 4 - visualisation «n secondes» après l arrivée du premier paquet Routeur 3 Routeur Internet RTC serveur Modem 56Kb/s "streaming" 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 4 Buffer 7Ko 2 client Les outils de streaming : 4 éditeurs Real Networks : RealProducer Plus pour le codage audio/vidéo RealServer pour le service de streaming RealPlayer pour la lecture des vidéo 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 : 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 Macromedia : Flash Media Server pour le service de streaming Flash 8 Video Encoder pour le codage audio/vidéo Flash Player pour la lecture 2

fichier audio/vidéo avec Real Producer A partir de fichiers : les fichiers doivent être aux formats audio (.au ou.wav) ou vidéo (.avi). Les fichiers mpeg-1 à 3 et quicktime (nécessitent DirectX 6.0) A partir de sources : microphones, caméra vidéo Convertir le fichier en fichier RealMedia : avec RealProducer Plus en choisissant les paramètres de codage (débit, qualité, ) Transférer le fichier RealMedia sur un serveur RealServer insérer les liens avec vos fichiers vidéo dans une page Web Enregistrement «SureStream» : permet avec un seul fichier une lecture à des débits différents (ex.: 28Kb/s et 56Kb/s). Le fichier est ainsi lisible par d anciennes versions de RealPlayer. L infrastructure : Web + streaming serveur administration Web serveur Hub "streaming" r é s e a u Hub client Serveur «sreaming» : Serveur Web : station bi-processeur Xéon + logiciel Hélix Producer station mono-processeur Pentium 3 + logiciel Apache Station «administration» : station mono-processeur Pentium 3 encodeur Hélix Producer interface d administration RealNetwork en ligne éditeur HTML Dreamweaver éditeur SMIL SMIL Editor Station client : navigateur + lecteur de médias RealOne Player Le serveur Helix Universal Server Serveur de streaming pouvant être installé sur les plateformes Windows server, Windows station et Unix ; nombreux médias compatibles : Realnetworks : RealAudio (.rm), RealVideo (.rm,.rmvb), RealPix (.rp) et RealText (.rt) ; Macromedia : Flash (.swf) ; Microsoft : Windows Media (.asf,.wma,.wmv) ; Apple : QuickTime (.mov) ; Standards : MPEG-1; MPEG-4, MP3 ; Images : GIF (.gif), JPEG (.jpg,.jpeg), PNG (.png) ; Autres : AU (.au), AIFF (.aif,.ief), WAV (.wav) Enregistrement «SureStream» : permet une lecture à des débits adaptés au lecteur (ex.: modems 28Kb/s ou 56Kb/s, ADSL 256Kb/s ou 512Kb/s). 3

diversité des présentations RealText : édition de clips textes pouvant être combinés avec d autres médias (audio ou vidéo). Réalisation de sous-titres par exemple ; RealPix : création de diaporama mixant des images GIF, JPEG ou PNG. Le langage incluse des animations et effets tels que zoom, fondus SMIL : Langage de présentations multimédias (Synchronized Multimedia Integration Language) basé sur le XML. Permet le multi-affichage dans une fenêtre mixant des vidéos, sons, des images et du texte. Peut intégrer des présentations réalisées avec RealText ou RealPix. diffusion : à la demande : la visualisation débute à la demande du client qui dispose des commandes d arrêt, retour arrière, avance rapide en direct : le client se connecte à une présentation pré-programmée. Il ne dispose pas de commandes. Deux méthodes de diffusion : point à point chaque client reçoit son propre flux de données ; multipoint un seul flux de données pour tous les clients. Caractéristiques du serveur stockage réparti : les fichiers distribuables peuvent être placés sur le serveur (répertoire «content») ou sur tout autre serveur du réseau ; informations de lecture : des informations sur les fichiers lus peuvent être transmises et affichées par le lecteur ; serveur secouru : en cas d interruption de lecture, le client peut être connecté à un serveur de secours ; serveurs proxys : permettent d accélérer la connexion des clients et la distribution des clips ; contrôle d accès : limitation du nombre de connexions simultanées ; autorisations d accès par adresses IP ou numéros de ports ; authentification des clients par nom et mot de passe ; gestion et contrôle : fichier de listage des accès clients, fichiers ; activité temps réel du serveur (bande passante, fichiers ouverts, clients connectés ) Points d accès du serveur Les URLs pour accèder utilisent des «points d accès» (mount points) fonctionnant comme des répertoires. Les points d accès par défaut sont : /admin accès aux pages d administration du serveur ; /ramgen requêtes venant des navigateurs ; /httpfs ouverture des pages HTML par HTTP ; /viewsource envoi de pages HTML listant les informations sur les fichiers visionnés ; /encfs dialogue entre Helix Producer et Helix Server ; /asxgen requêtes des navigateurs concernant des fichiers Windows ; /nscfile ouverture des lecteurs Windows Media en multicast; /scalable requêtes des connexions multicast à débit configurable. Exemples : accès aux pages d administration du serveur en local http://<localhost>:<adminport>/admin/index.html accès aux données RealNetworks du répertoire «content» http://<serveur>:80/ramgen/répertoire/fichier.smi 4

Ports et protocoles Ports par défaut Généré dynamiquement RealServer : le serveur de streaming 2 versions logicielles : windows NT et Unix Le serveur utilise 2 canaux par client : un canal pour le contrôle et les commandes, un canal pour les données pour chaque client, le serveur crée une tâche et réserve une zone RAM (12Kb par Kb/s de débit) le serveur utilise 2 protocoles avec les applications de lecture vidéo : Real Time Streaming Protocole (RTSP) et Progressive Networks Audio (PNA) Connexion TCP de contrôle RealServer Flux UDP de données RealPlayer Contrôle de débit par RTSP Le serveur peut adapter le débit des données : Par négociation entre client et serveur. L adaptation de débit n est mise en œuvre que si les conditions négociées à l ouverture de la session sont réunies ; De sa propre initiative, sans demande du client. Dans ce cas, le serveur ignore les requêtes d adaptation de débit du client, et s appuie sur les informations de congestion fournies par le protocole RDT. Un mécanisme de signalisation dans RTSP est en cours de standardisation (3GPP 26.234). Ce mécanisme nécessite que : Les extensions de réponses dans RTCP (NADU APP) soient utilisées pendant la session ; La fréquence des réponses soit précisée ; Des seuils soient prédéfinis dans le buffer du client. Les paramètres d adaptation de débit peuvent être échangés à la demande ou lors de l ouverture de session dans un descriptif de session (Session Description Protocol). Ce descriptif est systématique dans le cas de diffusion multicast. 5

Architecture de Helix DNA Server Le noyau du serveur «Helix DNA» (Media Delivery Engine ) : fournit un ensemble de services communs à toutes les applications de la plateforme. Les compléments assurent les fonctions spécifiques à certaines applications. FileSystem FileFormat InputSource Broadcast Plugin Socket noyau DataFlow RateControl Session Control Allowance Registry Logging Transport Protocol Data Socket Socket Helix DNA Server : modèle d interaction entre objets control feedback data client Les congestions sont contrôlées par RDT Le contrôle de congestion du serveur s appuie sur les informations retournées par le client. La caractérisation de la connexion utilise 2 variables principales : le taux de perte et le délai de propagation. Le protocole RDT ne dispose pas d information d horloge comme RTP. Le protocole RDT compense par une analyse de la périodicité des acquittements (ACK/NACK). A terme, le protocole RDT devrait se rapprocher des fonctionnalités du protocole RTP. Par le protocole RDP le client fournit au serveur des informations sur l état du buffer (nombre d octets stockés). Le transport des données dans RTP H.263 Vidéo : 0 31 l en-tête contient le type données, la longueur de l en-tête des données et un «marqueur de temps», basé RTP Header H.263 + payload Header H.263 + compressed Data Stream sur une horloge à 90kHz. MPEG-4 Audio/Visual : L en-tête contient un n uméro de séquence, un marqueur de temps basé sur une horloge à 90kHz 0 31 RTP paramètres RTP Marqueur de temps header ID de synchro de source paramètres complémentaires MPEG-4 Data Stream 6

Le contrôle et la gestion de session Le contrôle de session porte sur les interactions entre le serveur et le lecteur pour des actions telles que l ouverture, la lecture, la pause Le recours à un protocole tel que RTSP entre le serveur et le lecteur facilite l interaction ; Pour chaque requête, un objet est créé par le Player Packet Management. Player::Session Object : OnPause Session Control Player Packet Management Protocol RTSP Request (pause) Les 5 étapes de création des fichiers serveur Web serveur "streaming" 3 4 2 5 1 administration Hub r é s e a u I n t e r n e t Routeur Etape 1 : encodage des vidéos sur la station d administration avec Real Producer ; Etape 2 : transfert des fichiers vidéos vers le serveur de streaming à partir de la station d administration ; Etape 3 : création des fichiers HTML regroupant les liens vers les fichiers de pointage ; Etape 4 : création du fichier «Ram» de liaison entre navigateur et lecteur multimédia ; Etape 5 : création des fichiers de présentation multimédia SMIL sur le serveur de streaming ou serveur Web ; Etape 1 : encoder en fonction du débit Les vidéo 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 l audio le sur-débit. Pour une bande passante de 65Kb/s, la répartition des sous-bandes peut se faire de la manière suivante : Bande passante : 56Kb/s 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 Débit total 56Kb/s données 34Kb/s voix 6,5Kb/s Voix + musique 8,5Kb/s Musique mono 8Kb/s Musique stéréo 8Kb/s 7

Etape 1 : les formats d image pour la vidéo La qualité de l image pour une bande passante donnée dépend fortement de sa dimension: Débit total données 176 x 132 240 x 180 320 x 240 640 x 480 RTC 28,8Kb/s 20Kb/s RTC 56Kb/s 34Kb/s bon correct Faible RNIS 64Kb/s 45Kb/s LAN 150Kb/s excellent correct ADSL 256Kb/s 225Kb/s bon ADSL 512Kb/s 450Kb/s Etape 1 : l échantillonnage audio Débit audio (kb/s) 5 6,5 8,5 16 32 64 Échantillonnage (khz) 8 8 8 16 22 44 Échantillonnage de la voix Échantillonnage (khz) 11 22 12Kb/s St 20Kb/s St St-RA8; St-HR 32Kb/s St; St-RA8 44Kb/s St 64Kb/s 96Kb/s 264Kb/s 44 St-HR St-RA8; St-HR; Sd St; St-RA8; Sd St; St-RA8; Sd St-RA8; Sd St : stéréo St-RA8 : stéréo RealAudio 8 St-HR : stéréo High Response Sd : surround Échantillonnage de la musique Le codage audio/vidéo : paramètrage Type de codage Choix des débits Format du fichier 8

Statistiques d enregistrement Durée de codage par rapport à la durée du clip Caractéristiques des flux audio/vidéo Session de codage : paramètrage Nom du serveur Nom du fichier Port utilisé utilisateur Etape 1 : le paramétrage vidéo avancé Le type de flux : flux à débit constant (CBR) ; flux à débit variable (VBR)/débit moyen (le codage moyen peut être dépassé pour des images complexes pendant une brève période) ; flux à débit variable/qualité vidéo (les séquences complexes utiliseront le débit maximum possible). Les options des flux : la taille du buffer (nombre d images stockées avant visualisation) de 4 à 25 secondes ; la fréquence des images I (images à codage intrinsèque) de 0 à 60sec ; l utilisation ou non d une correction d erreur (loss protection) 9

Etape 2 : transfert des fichiers Les fichiers sont placés sur le répertoire «content» du serveur ; des sous-répertoires peuvent être créés ; des alias facilitent l accès aux présentations placées dans les sousrépertoires créés ; si des fichiers sont placés sur d autres serveurs, des fichiers de liens doivent être créés dans le répertoire «content». Dialogue client-serveur Web-serveur streaming Serveur Web Fichier RAM 2 1 Vidéo disponibles : astérix obélix idéfix RealServer Fichier SMIL Fichiers vidéo RealPlayer navigateur 6 1 un click sur le lien envoie une requête au serveur 2 le serveur Web télécharge le fichier RAM (.ram) 3 le lecteur vidéo est chargé 4 le lecteur interroge le fichier SMIL (.smil) et évalue le fichier vidéo adapté 5 le lecteur demande la lecture du fichier 4 5 6 la lecture de la vidéo commence 3 Etape 4 : Les fichiers RAM Lien entre la page Web et les fichiers vidéos : Lancent le lecteur RealOne ; Ouvrent les connexions RTSP avec le serveur ; Passent au lecteur les URL des fichiers pouvant être ouverts ; un fichier vidéo ne doit être défini qu une seule fois. Exemple de fichier : videos.ram rtsp://www.compagnie.com/media/video128k.rm rtsp://www.compagnie.com/media/video156k.rm rtsp://www.compagnie.com/mediaserver/videos.smil La page web pointera sur ce fichier : <a href=«http://www.compagnie.com/ramfiles/videos.ram»>cliquer pour choisir une vidéo</a> Note : pour un test en local, le fichier Ram est placé dans le répertoire du clip. L URL commencera par file:// 10

Etape 4 : des paramètres d initialisation Le fichier RAM permet de paramétrer le lecteur à son ouverture : Dimensions de l écran screensize=double full original Mode d affichage des boutons de contrôle mode=normal theater toolbar Début et fin de lecture du clip start (end)=hh:mm:ss.x Exemples : rtsp://www.compagnie.com/media/video128k.rm?screensize=full #affiche le clip en plein écran rtsp://www.compagnie.com/media/video128k.rm?rpcontextheigh=150 &rpcontextwidth=250&rpcontexturl=http://ww.companie.com/index.ht ml # affiche la page html dans un fenêtre de 250x150 rtsp://www.compagnie.com/media/video128k.rm?start=55&end=1:35 # affiche le clip pendant 40 secondes Etape 4 : des infos dans le lecteur Pendant la lecture d un clip, le fichier RAM permet d afficher les informations d une page html ; Ces informations s affichent dans une fenêtre séparée. Exemples : rtsp://www.compagnie.com/media/video128k.rm?rpcontext height=250&rpcontextwidth=280&rpcontexturl=«http://co mpagnie.com/infomedias.html» #affiche le contenu de la page dans un rectangle de 250x280 pixels rtsp://www.compagnie.com/media/video128k.rm?rpurl=«h ttp://compagnie.com/index.html» #affiche le contenu de la page dans le navigateur Etape 4 : emplacement et liens Les fichiers Ram peuvent être placés sur le serveur de streaming ou sur n importe quel serveur Web ; si les fichiers sont sur le serveur de streaming, les liens vers les clips peuvent utiliser des chemins relatifs ; si les fichiers sont sur un serveur autre, les liens veers les clips doivent utiliser des URL complets. 11

Etape 5 : présentation en SMIL Utilisent le langage au standard internationnal Synchronized Multimedia Integration Language permettent la sélection de la bande passante ces fichiers sont optionnels Exemple de fichier : videos.smil <smil> <body> <switch> <ref src="lpsticm.rm" system-bitrate="220000 "/> <ref src="lpsticl.rm" system-bitrate="150000"/> <ref src="lpsticd.rm" system-bitrate="64000"/> </switch> </body> </smil> Liens utiles Real Server : Outils de streaming - http://europe.realnetworks.com/?src=fr_gb_home Architecture du serveur Helix DNA - https://protocol.helixcommunity.org/2006/devdocs/sod-rtsp-adaptation-signaling- 02.txt Protocoles - https://protocol.helixcommunity.org/ Protocoles Temps Réel : RTCP RTSP - http://www.ietf.org/rfc/rfc2326.txt RTP - http://www.ietf.org/rfc/rfc1889.txt RDT - https://protocol.helixcommunity.org/2005/devdocs/rdt_feature_level_30.txt SMIL : XHTML & SMIL - http://aristote1.aristote.asso.fr/csmil/ Normes - http://www.w3.org/tr/rec-smil Éditeur + cours - http://wam.inrialpes.fr/ Site de streaming : Vidéothèque de l IRIA - http://www.inria.fr/multimedia/videotheque-fra.html 12