Conception Serveur Vod

DESS S.R.
Universit du Havre
Conception d'un serveur de vido la demande
Responsable : Claude Duvallet

Anne universitaire 2003/2004
Sommaire
Sommaire
Introduction........................................................................................................................................3 I. Analyse du projet............................................................................................................................4 I.1. Prsentation gnrale...................................................................................................... 4 I.2. Les acteurs du projet....................................................................................................... 4 I.3. Prsentation de la VOD.................................................................................................. 5 I.3.a. Prsentation............................................................................................................. 5 I.3.b. Fonctionnement....................................................................................................... 6 I.4. Le streaming video......................................................................................................... 6 I.4.a. Dfinition................................................................................................................ 6 I.4.b. Exemple de streaming............................................................................................. 8 I.4.c. 2 grands du streaming............................................................................................. 8 I.5. Protocoles rtsp/rtp........................................................................................................... 9 I.5.a. Le protocole rtp....................................................................................................... 9 I.5.b. Le protocole rtsp..................................................................................................... 10 I.5.c. Relation rtp/rtsp...................................................................................................... 13 I.6. Protocole sdp.................................................................................................................. 15 II. Conception...................................................................................................................................17 II.1.Solutions possibles......................................................................................................... 17 II.1.a. Serveur rtsp/rtp complet......................................................................................... 17 II.1.b. Partir de vls............................................................................................................ 18 II.1.c. Partir de vlc............................................................................................................ 18 II.1.d. Lancements de vlc................................................................................................. 19 II.1.e. Solution vobstreamer............................................................................................. 19 II.2. Solution choisie.............................................................................................................. 20 III. Ralisation..................................................................................................................................21 III.1.Dcoupage du film : mpgtx........................................................................................... 21 III.2.Videolan......................................................................................................................... 22 III.3.Vlc.................................................................................................................................. 23
Dess SRO Conception d'un serveur de vido la demande Toinel Ludovic Thault Ludovic Goeres Damien Jacquot Georges
Sommaire
III.4.Vls.................................................................................................................................. 24 III.4.a. Structure......................................................................................................... 24 III.4.b. Utilisation....................................................................................................... 26 III.5.Vod-k............................................................................................................................. 28 III.5.a. Principe de fonctionnement............................................................................ 28 III.5.b. Bibliothques dveloppes pour Vod-k......................................................... 28 III.5.c. Schma de fonctionnement des processus..................................................... 31 IV. Tests.............................................................................................................................................33 Perspectives.......................................................................................................................................38 Conclusion.........................................................................................................................................39 Glossaire............................................................................................................................................40
Dess SRO
Conception d'un serveur de vido la demande Toinel Ludovic Thault Ludovic Goeres Damien Jacquot Georges
Remerciements
Remerciements
Nous tenons remercier tout particulirement :

M. Claude Duvallet pour son aide, et le temps qu'il nous a consacr tout au long du projet. Cedric Lacroix de l'Epita qui nous a beaucoup aid pour les modifications de VLS. M. Fenrir, pour le temps qu'il a consacr rpondre nos questions concernant le dveloppement de VLC. La facult du Havre qui nous a donn les moyens pour russir ce projet.
Dess SRO
Introduction
I. Introduction
La Vido sur demande est l'une des technologies multimdia les plus rvolutionnaires depuis ses dernires annes; avec l'apparition de logiciels comme Real Vido ou mme Windows Media Server, le streaming vido et audio a pris beaucoup d'ampleur sur Internet. Cette rvolution est en trs grande partie due l'introprabilit des protocoles utiliss (RTP/RTSP). Cependant, l'heure actuelle, aucun logiciel libre ne supporte ces protocoles correctement, ce qui rduit considrablement le nombre de serveurs de streaming, car les licenses des logiciels propritaires ont un cot trs lev. Notre projet consiste donc concevoir et raliser un serveur de vido sur demande partir des outils existants, comme les outils dvelopps par Vidolan. Ce dossier est la synthse des phases d'analyse, de conception, de ralisation et de tests du logiciel que nous avons conu dans le cadre de notre projet tutor de DESS.
Dess SRO
3/40
I. Analyse du projet
I.1. Prsentation gnrale
Le streaming vido consiste servir des contenus multimdia aux utilisateurs qui en font la demande. Il s'agit notamment des serveurs de vido la demande (VoD). Gnralement, ceci s'effectue au moyen des protocoles RTSP/RTCP (RFC 2326) selon un mode client/serveur. Le serveur dispose d'un certain nombre de contenus (films) qu'il met disposition sur le rseau. Des clients peuvent alors effectuer des demandes de films qui vont tre servis et diffuss en temps rel. La connexion s'tablit classiquement au moyen d'une socket et on peut alors initialiser la transmission du flux vers le client sous forme de paquets RTP. Chaque client visualise son film indpendamment des autres et dispose de toutes les fonctionnalits classiques d'un magntoscope ou lecteur DVD (jouer, pause, retour en arrire, avance rapide, arrt). Pour ce travail, il faudra s'appuyer essentiellement sur les RFC 2326 et RFC 1890 mais d'autres RFC ou documents peuvent tre utiliss. Il s'agira essentiellement de dvelopper un client/serveur RTSP fonctionnant sous linux (et ventuellement d'autres SE). Le dveloppement devra tre effectu en C/C++ pour des raisons de performances. Le format principal de contenu vido sera le MPEG-2 mais on peut aussi envisager de supporter le MPEG-1 et le MPEG-4. Pour la partie visualisation des contenus, on pourra s'appuyer sur un lecteur multimedia existant tel que VLC (http://www.videolan.org).
I.2. Les acteurs du projet

M. Duvallet : Chercheur & Matre de confrence. Equipe VODK : Thault Ludovic, Toinel Ludovic, Goeres Damien, Jacquot Georges. Equipe RTP (Epita) : Dupasquier Julien, Lacroix Cdric, Rapp Davy. Equipe Videolan : Fenrir.
Dess SRO
4/40
I.3. Video On Demand I.3.a. Prsentation La Video On Demand ou Vido sur demande est un des enjeux majeurs des dveloppements de la technologie actuelle. La Video On Demand est un concept qui permet un utilisateur d'accder depuis un client des documents sous forme de flux audio et/ou vido. Les intrts sont importants : son dveloppement devrait permettre d'accder, via un ordinateur connect un rseau, aux types de services auxquels la tlvision nous a habitus depuis longtemps, avec en plus les avantages du magntoscope. On peut en effet, dans les applications de Video la Demande, programmer la diffusion d'un document, ou mme demander sa diffusion immdiate. On peut galement ajouter cette diffusion, les fonctionnalits d'interactivit. Par exemple, lors de la diffusion de la rclame d'un produit, on pourra faire apparatre un bon de commande en cliquant sur le produit, ou voir mme faire un zoom sur le produit,... les possibilits sont infinies. La rception sera ainsi personnalise, on pourra paramtrer la qualit de la diffusion, l'heure laquelle celle-ci sera envoye... De plus, la diffusion de documents bass sur ces technologies peut tre trs bon march, ne ncessitant souvent que la mise en place d'un serveur chez le diffuseur et d'un client chez le consommateur. Cela permet tout un chacun de produire, diffuser ses propres documents vido, comme le Web permet de publier en ligne des documents mlant eux aussi des textes, des sons, des vidos, des images,... Les technologies de Video On Demand devraient d'ailleurs se fondrent dans celles dj employes sur le Web, et les amliorer. A l'avenir, on accdera aux documents diffuss par un serveur de vido de faon transparente, au cours de la navigation sur le web, travers son navigateur. On peut ds lors imaginer de nombreuses applications, des dveloppements de ces technologies, qui permettaient d'accder et de controler un flux multimdia, ce qu'il n'est pas possible de faire avec la tlvision, de par son mode de diffusion coteux et n'admettant pas le cas par cas. On aura, par exemple, en plus de la possibilit qu'offrent nos tlvisions actuelles, accs des bases de donnes de films ducatifs ou de loisir, des bases de donnes de cours (tlenseignement) permettant un lve de grer son programme et son rythme d'apprentissage,... le tout en haute dfinition ! En rsum, la Video On Demand permettra ce que le Web permet dj, avec en plus une vritable interactivit multimdia et un service temps rel. Le principale fondement de la VOD consiste tablir un dialogue entre le serveur et ses clients.
Dess SRO
5/40
I. Analyse du projet I.3.b. Fonctionnement
Le principe de la VOD est de relier le serveur avec ses clients par une connexion TCP/IP. Cette liaison permet ainsi d'changer des informations toutes autres que le flux vido. Le client peut ainsi demander au serveur revenir en arrire sur le flux vido d'un DVD, ou mme demander le programme de la journe pour un flux provenant d'une carte tuner ou satellite. La VOD permet donc l'utilisateur de disposer de commandes de magntoscope pour les vidos. De plus, la VOD permet d'offrir les mme fonctionnalits que la tlvision numrique, tel que les programmes la carte, l'affichage des sous-titres ou la visualisation du nom et du rsum du programme.
I.4. Le streaming video I.4.a. Dfinition Le principe du streaming est d'acheminer de la video au sens large et un script de synchronisation, comme un flot continu de donnes. La capacit mettre du streaming multimedia implique que le client puisse recevoir le contenu, pendant que celui-ci est achemin sur le rseau et sans qu'il n'ait t pralablement
Dess SRO
6/40
I. Analyse du projet tlcharg (lgre bufferisation du lecteur). Le streaming est suprieur au tlchargement en matire de multimdia parce qu'il reduit considrablement les temps d'attente et de stockage requis par l'ordinateur client. Le streaming ouvre la porte aux prsentations de taille illimite comme dans le cas de diffusions en direct. Il faut savoir que sans le streaming, les fichiers sons ou vidos mettraient beaucoup plus de temps tre lus. Prenons par exemple un extrait musical de 5 minutes de taille de 1MO, ce qui correspond selon l'algorithme choisi un codage de faible qualit monophonique, et un utilisateur disposant d'un modem ayant une bande passante de 28 800 bits/s : il lui faudra environ 7 minutes pour pouvoir tlcharger le morceau sur sa machine et ensuite le lire.
Maintenant voyons avec la technologie du streaming, le tlchargement durera toujours 7 minutes mais il pourra entendre le dbut du morceau ds la reception de paquets, c'est dire au bout de quelques secondes, alors que le morceau n'a pas t tlcharg dans son intgralit. L'intret est donc d'envoyer des petits paquets de donnes qui seront lus par le client plutt que d'envoyer le fichier contenant les donnes multimdia dans son intgralit. Effectivement ds le dbut de la connexion en streaming, il y a interrogation du serveur permettant de mesurer la bande passante disponible, un calcul est alors fait pour choisir le delai optimal d'attente observer avant de commencer diffuser le fichier. Sauf baisse brutale de la bande passante, l'utilisateur n'aura pas supporter les coupures qui seraient necessaires pour attendre la suite. Evidemment si le fichier est encod pour supporter diffrentes bandes passantes (le surestream), il pourra s'adapter et passer d'une version strophonique haute qualit une qualit moyenne, il y aura une baisse de la qualit mais aucune coupure surviendra. Cette ngociation de qualit entre l'application cliente et le serveur repose sur des protocoles particuliers, le protocole RTSP/RTCP est le plus utilis sur le web. Le protocole utilis pour le streaming doit dcouper le flot et l'envoyer en continuit, l'autre bout: il est bufferis, et reconstitu, ainsi il n'y a pas de perte de qualit. C'est le cas de HTTP et de RTP. La vido rpondra a un encodage-compression particulier, ainsi que le script de synchronisation et l'audio. On pourra utiliser toutes formes de mdia et synchroniser, texte, son, video transparents... Dans ce cas on parle de Rich media (fichier smil de real), ainsi nous pourrons arriver a produire de la "WEB TV".
Dess SRO
7/40
I.4.b. Exemple de streaming Voici les tapes suivre pour l'internaute afin de visualiser un mdia partir de son navigateur : L'internaute active un lien sur une page web pour lire un "stream video". Le serveur transmet au navigateur un fichier texte (metafile). Le metafile contient l'adresse du fichier vido sur le serveur de mdia. Tlcharg par le navigateur, il est transmis l'application client (player). Le player lit l'adresse contenue dans le "metafile" et envoie une requte au serveur vido. Le serveur ddi dlivre en continu ("stream") une rplique du fichier vido adapte la connexion spcifie du player.
Tlchargement en STREAMING : Pour rguler le flux, des donnes de contrle informent le serveur vido sur la faon dont le buffer reoit les paquets.
I.4.c. Les 2 grands du streaming REAL NETWORKS qui se dcline en REAL PLAYER (gratuit dans sa version 8 basique) sait lire de trs nombreux encodages et se connecter sur les sites de radio REAL SERVER (plusieurs possibilits), REAL PRESENTER ( synchronisation de page web ou de prsentation power point avec une vido), REAL PRODUCER ( production d'une vido en direct ou vido la demande). Le point fort de REAL, le SURE STREAM c'est dire la possibilit partir d'un serveur Real de diffuser du streaming selon la bande passante du rseau, voire d'utiliser http comme protocole de transmission. Le point faible est le prix.
Dess SRO
8/40
WINDOWS MEDIA SDK (software developmen kit) (microsoft) qui se dcline en WINDOWS MEDIA PLAYER sait lire l'encodage microsoft (fichier asx) et les cd musicaux WINDOWS MEDIA ENCODER ( production d une video en direct ou video la demande ) et serveur en meme temps ? WINDOWS MEDIA services, format, metafiles, rights manager divers services non tests. Le point fort de WINDOWS MEDIA SDK est sa gratuit. Son point faible est qu'il n'est pas introprable avec d'autres systmes d'exploitations que Windows. Ces deux serveurs utilisent le TCP pour la synchronistion client-serveur et l'UDP pour le flux vidos. Il est aussi possible de faire du TCP, de choisir les ports et de faire du multicast-udp.
I.5. Les protocoles RTSP/RTP
I.5.a. Le protocole RTP (Real-time Transfert Protocole RFC1889) Quest-ce que le Real Time Transport Protocole (RTP)? Le Realtime Transport Protocol (RTP) est la fois un standard IETF et un standard de lInternational Tlcommunications Union (ITU). Cest un paquet format pour la transmission de donnes multimdia. RTP est utilis par de nombreux protocoles standards, comme RTSP pour les applications de transmission, H.323 et SIP pour les applications tlphoniques, et par SAP/SDP pour des applications multicast. Cela fournit les donnes pour tous ces protocoles.

Les besoins Dans notre projet, la VOD a besoin d'une partie commande de flux vido pour pouvoir interagir avec elle. Exemple : si l'on veut revenir la 2me minute du film, il faut un protocole de commande et d'archivage des paquets du flux.
Dess SRO
9/40
Le but du protocole RTP et les solutions apportes Le but de RTP est de fournir un moyen uniforme de transmettre sur IP, des donnes soumises des contraintes de temps rel (audio, vido, ... ). Le rle principal de RTP consiste mettre en oeuvre des numros de squence de paquets IP pour reconstituer les informations de voix ou vido mme si le rseau sous-jacent change l'ordre des paquets. Plus gnralement, le RTP permet : D'identifier le type de l'information transporte. D'ajouter des marqueurs temporels et des numros de squence l'information transporte. De contrler l'arrive destination des paquets. De plus, RTP peut tre vhicul par des paquets destination multiple. Utilisation prvue de RTP dans le cadre du VOD RTP permet une gestion des flux multimdia (son, vido) sur IP. RTP fonctionne sur UDP. L'en-tte RTP comporte des informations de synchronisation, de numrotation. Elle est rajoute au dbut du paquet contenant les informations audio et vido du flux.
I.5.b. Le protocole RTSP (Real Time Streaming Protocol, RFC 2326) Dfinition RTSP est un protocole client serveur pour les flux multimdia, conut pour un transport efficace dun flux travers les rseaux. Il utilise des infrastructures Web, et fonctionne aussi bien pour des connexions uniques que pour des multi-connexions. Real Networks, Netscape Communications et Columbia University ont dvelopp conjointement RTSP avec MMUSIC working group de Internet Engineering Task Force (IETF). En Avril 1998 il a t publi comme un standard par lIETF.
Comment RTSP ragit avec les autres protocoles standard dInternet ?
RTSP est une pice trs importante dans le puzzle de linteroprabilit. L'interoprabilit pour les mdia de streaming implique de nombreux composants (Lecteurs, Serveurs, Encodeurs/Outils) qui doivent partager des mcanismes communs. Encodeurs et outils de cration doivent tre capables de stocker leurs informations dans des fichiers que les serveurs peuvent lire. Les Serveurs doivent tre capables denvoyer des informations en utilisant des protocoles que les lecteurs peuvent comprendre. Les Encodeurs et les outils doivent aussi stocker les types de donnes dans des fichiers aux formats que les lecteurs vont pouvoir ventuellement comprendre. Pourquoi RTSP ? Un des intrts majeurs de l'Internet Multimdia est de pouvoir effectuer un Streaming du flux de donnes. Le Streaming consiste dcouper les donnes en paquets dont la taille est adapte la bande passante disponible entre le client et le serveur. Quand le client a reu suffisamment de paquets (bufferring), l'application cliente commence jouer un paquet, dcompresse un autre
Dess SRO Conception d'un serveur de vido la demande Toinel Ludovic Thault Ludovic Goeres Damien Jacquot Georges 10/40
I. Analyse du projet et reoit un troisime. Ainsi l'utilisateur peut avoir le flux multimdia sans avoir tlcharger tout le fichier. Toutefois, il y a un retard d la bufferisation. RTSP (Real Time Streaming Protocol) permet de contrler la distribution de flux multimdias (streaming) sur un rseau IP. C'est un protocole de niveau applicatif prvu pour fonctionner avec des protocoles tels que RTP/RTCP et RSVP. Les flux peuvent provenir soit de clips stocks soit d'une source temps rel (camra, micro).
Les besoins Comme on l'a vu, le protocole RTP organise les Flux audio et vido. Maintenant avec le protocole RTSP, nous allons pouvoir rpondre aux besoins du client, en lui permettant d'envoyer des commandes au serveur qui permettront le contrle du flux. Exemple : un bouton de commande sur le client VLC : play , pause , avance rapide , revenir un temps donn , etc Pour ce faire, le dveloppement d'une librairie sur le protocole RTSP conformment la RFC est ncessaire. Le but du protocole RTSP et les solutions apportes RTSP propose de fournir un protocole solide pour dlivrer, en unicast ou multicast, du contenu multimdia. Par l'intermdiaire du protocole RTSP, le client est libre d'arrter le flux provenant du serveur (mode pause) ou de manire plus intressante, d'accder directement une partie avance du mdia sans avoir tlcharger la partie passe (mode avance rapide). De la mme manire le serveur peut tre amen envoyer des requtes au client comme la demande d'mission de compte-rendu sur la qualit de la connexion pour adapter, s'il est ncessaire, la nature du flux.

Voici certains des avantages du protocole RTSP : - Extensible (nouveaux paramtres et nouvelles mthodes peuvent tre aisment implments). - Facile lire (les parseurs standard HTML ou MIME peuvent tre utiliss). - Scuris (mthode d'authentication HTTP, mcanisme de scurit applicable sur les couches transports ou rseaux). - Indpendant de la mthode de transport (les protocoles tels que UDP, RDP et TCP sont supports). - Capacit grer plusieurs serveurs de diffusion (il peut y avoir plusieurs flux de diffrents serveurs de diffusion l'intrieur d'une mme prsentation). - Commande de contrle de l'enregistrement (les deux fonctions de lecture et d'enregistrement peuvent tre utilises par le client). - Sparation du contrle du flux multimdia et de la commande d'ouverture du mdia - Description neutre des donnes (pas de format particulier impos, le format des descriptions doit ncessairement contenir au minimum l'URI RTSP du mdia). - Fonctionne avec proxy ou firewall. - Eutilise les concepts HTTP. - Contrle du serveur distant.
Dess SRO
11/40
I. Analyse du projet - Type du transport ngociable (la mthode de transport peut tre ngocie avant la diffusion du mdia) - Capacit de ngociation (le client doit avoir le moyen de savoir si certains services de base ont t retirs du serveur)
Utilisation prvue de RTSP dans le cadre de la VOD RTSP permet le contrle des flux multimdia (son, vido) sur IP. RTSP fonctionne sur TCP (ou UDP). Fonctionnement de RTSP Chaque prsentation et chaque flux mdia est identifi par une URL RTSP. Une prsentation peut contenir plus d'un flux mdia. Le fichier de description de la prsentation contient les codages, langages et d'autres paramtres qui permettent au client de choisir la combinaison la plus adquate pour ce mdia. <session> <group> < track src="rtsp://audio.example.com/twister/audio.en"> < track src="rtsp://video.example.com/video"> </group> </session> Mthodes RTSP:
Dess SRO
" ! F D E " ! F D E F D E " ! $ " ! F D E F D E $ " ! $#
12/40
'5 764 '5 764 ' '5 764 '5 764 '5 764 '5 764 '5 764 '5 764 '5 764 '5 764
' 3 2 $( ($CB$( 3 2 ' 5 ' 3 2 ' 3 2 $( ( 3 2 $' ' 3 2 $( ' 3 2 $( ' 3 2 $( ($CB$( 3 2 ' 5 ' 3 2 ($CB$( 3 2 ' 5 ' 3 2 (3$CB$( 2 ' 5 ' 3 2 ' 3 2 $(
9 S @ % ) 8 & H )$$4 $' & H & P 8 ) 8 I H & 4 A H & ' H ( & ) 0 % & $$) % ) @ ( & $) R 8 Q $4 & A 8 ' $4 ' 0 @ 9 @ H 4 )&H&P$$4 $& G 8 ) 8 I H &$8 ( 9 A @ 9 9 & 1 0 ) ( & ' %
I. Analyse du projet I.5.c. Relation rtsp/rtp
Des protocoles comme RTSP sont ncessaires mais pas suffisant pour russir linteroprabilit. Les fichiers aux formats comme ASF et Quick Time FF agissent comme des conteneurs pour les donnes multimdia, les types de donnes comme Real Audio, RealVideo, H.263 et MPEG Audio et Vido sont tous des types de donnes qui peuvent tre lus sur ce type de systmes. Quest-ce que H.323 ? H.323 est une structure de travail, standardise par lInternational Tlcommunications Union (ITU). Elle est utilise pour la connexion peer-to-peer : deux chemins apportent les donnes audio et vido par la ligne tlphonique. Elle est conue pour bien interagir avec les standards de communication dInternet et fonctionner correctement pour un nombre modr de participants. Comment RTSP, RTP et H.323 se comportent entre eux? H.323 et RTSP sont complmentaires. H.323 est utile pour rgler laudio/vido de confrences dans un groupe peer-to-peer modr, tandis que RTSP est utile pour les larges diffusions et la vido la demande. On peut penser H.323 comme offrant des services quivalant un tlphone avec trois faons dappeler, pendant que RTSP offre des services comme un stock de vidos avec des services de livraison, comme,le VCR, le cble ou la tlvision. RTSP fournit des fonctionalits de contrle comme pause, avance rapide, retour, position absolue, qui est derrire un plan de H.323 et RTP. H.323 et RTSP utilisent RTP comme leurs standards, cela signifie en fait quils transportent les donnes multimdia. Le niveau de donnes compatibles rend efficace les chemins daccs entre tous les protocoles possibles, seulement les messages de contrle ont besoin dtre transports.

Dess SRO
13/40
I. Analyse du projet Quelle est la relation entre RTP, RTCP et RTSP? RTP est un protocole de transport pour les donnes en temps rels, incluant les flux audio et vido. RTCP est une part de RTP et aide la synchronisation et la gestion de la qualit de service, parmi dautres. RTSP est un protocole de contrle qui initialise et dirige le transport de flux multimdia depuis un serveur, "Internet VCR Remote Control Protocol". RTSP ne transporte pas les donnes, alors la connexion RTSP peut tre utilise pour contrler le traffic RTP faciliter lutilisation avec les firewalls et dautres outils du rseau. RTP et RTSP seront utilises ensemble dans beaucoup de systmes, mais lun lautre peuvent tre utiliss seuls. Les spcifications RTSP contiennent une section sur lutilisation de RTP avec RTSP.
Quest-ce que le MPEG-4? MPEG-4 est un standard issu du Motion Picture Experts Group (MPEG). Le comit MPEG est un groupe de standards travaillant sous la direction et les lois de lInternational Standards Organization (ISO), et sous la direction lAmerican National Standards Institut (ANSI), aux Etats-Unis le dveloppement du MPEG4 a commenc dans le milieu des annes 90 et il est constitu de plus de 1000 pages de document mettant en relief une grande tendue dlments multimdia, fichiers formats, et prsentation alternative. Tout son intrt aujourdhui est reprsent par les codecs vido et les fichiers aux formats qui sont spcifis dans les sous paragraphes de la charte. Comment le MPEG-4 est utilise avec RTSP/RTP ? MPEG-4 et RTSP/RTP spcifient diffrentes choses. Le MPEG-4 spcifie lApi du media, rglage du type de donnes, et le fichier format pour le support multimdia. RTSP et RTP spcifient le ncessaire pour linteraction client-server pour envoyer le flux multimdia sur Internet, flux qui peu tre au format MPEG-4. Le groupe de travail MPEG-4 travaille avec l IETF sur diffrentes reprsentations du MPEG-4 au travers de RTSP et RTP.
Dess SRO
14/40
I.6. Le protocole SDP

SDP est dfini dans la RFC 2327. Description du protocole et de construction de fichier SDP http://www.ietf.org/rfc/rfc2327.txt SDP inclut : Le nom de la session La dure pendant laquelle la session est active Les informations sur le media Les informations sur la rception du media (adresses, ports, formats etc ..) Comme les ressources ncessaires pour une session peuvent tre limites, quelques informations complmentaires peuvent aussi tre ajoutes :

Le nom de la personne envoyant la session Informations sur la largeur de bande qui doit tre utilise Le type de mdias (vido, audio, etc) Le protocole de transport (RTP/UDP/IP, H.320, etc) Le format des mdias (H.261 vido, vido de MPEG, etc) Pour une session de multicoup IP, les objets suivants sont aussi transmis : Adresse de multicast pour mdias Port de Transport pour mdias
Pour une session multicast, on doit transmettre : Adresse des mdias Port de transport pour adresse de contact Description de session v= (protocol version) -> 0 o= (owner/creator and session identifier). s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information - not required if included in all media) b=* (bandwidth information) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Zero or more media descriptions (see below) Time description t= (time the session is active)
Dess SRO
15/40
I. Analyse du projet r=* (zero or more repeat times) Media description m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) k=* (encryption key) a=* (zero or more media attribute lines) Un exemple de fichier SDP pour un flux MPEG audio/video : v=0 o=- 49451 3 IN IP4 127.0.0.1 s=Test MPEG Audio+Video session i=Parameters for the session streamed by "testMPEGAudioVideoStreamer" t=0 0 a=tool:testMPEGAudioVideoStreamer a=type:broadcast m=audio 6666 RTP/AVP 14 c=IN IP4 239.255.42.42/127 m=video 8888 RTP/AVP 32 c=IN IP4 239.255.42.42/127
Dess SRO
16/40
II. Conception
II. Conception
II.1. Solutions possibles
II.1.a. Dvelopper un serveur de VOD - RTP/RTSP en entier
La premire solution trouve est videmment de dvelopper en entier le serveur. Le but est de dvelopper un serveur de vido la demande implmentant les protocoles RTP/RTSP. On implmente un serveur capable de grer le rtsp et le rtp. On ne s'occupe pas du client : en effet, l'utilisateur peut accder au serveur avec un client par exemple Mplayer, Vlc capable de grer le rtp. L'avantage de cette mthode est que l'on connait le code en entier et on n'a pas besoin de dcrypter et comprendre le code implment par un autre. Mais cela implique une charge de travail consquente avec l'tude et le dveloppement des protocoles RTP et RTSP, ce qui est impossible compte tenu du dlai pour ce projet.
Dess SRO
17/40
II. Conception
II.1.b. Partir de VLS
Le but est de dvelopper un serveur de streaming partir des sources de VLS (VideoLan Server). Vls est une application dveloppe en parallle de Vlc par une quipe de Vidolan. C'est un serveur de streaming complet, en effet VLS est capable de diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, des canaux satellite numriques, des chanes de tlvision numrique terrestre, et de la vido en temps rel sur un rseau en unicast ou multicast,. Il fonctionne avec la commande telnet pour dmarrer les flux.
II.1.c. Partir de VLC
Le but est de dvelopper un serveur de streaming partir des sources de VLC (VideoLan Client). En effet Vlc peut diffuser un flux multimdia grce sa fonction stream output. Pour tre un vrai "streamer", VLC devrait pouvoir lire plusieurs sources la fois. VLS peut le faire depuis ses dbuts, alors que VLC ne peut pas pour le moment. On ne peut alors visionner qu'un seul film pour tous les clients. Cependant nous avons test cette solution avec succs, un des clients Vlc envoie le flux de donnes et l'autre client vlc est capable de recevoir le flux en streaming. On pourrait alors utiliser cette mthode pour notre serveur de vido la demande en dveloppant le produit Vlc en y intgrant d'autres fonctionnalits. Les avantages de cette mthode est que Vlc est un outil complet, supportant de nombreux formats vidos, dvelopp par des franais. Cependant il n'est pas facile de transposer le logiciel dont le code dvelopp depuis plusieurs annes est important.
Dess SRO
18/40
II. Conception
II.1.d. Dvelopper un serveur de VOD capable de lancer des VLC la demande On peut galement dvelopper un serveur capable de lancer des threads VLC sur demande. Cette solution reprend la solution prcdente et pour grer le fait de pouvoir lancer plusieurs flux on implmenterait une application capable, la demande d'un client, de crer un thread vlc sur le serveur. Cette solution n'est videmment pas la meilleure des solutions!!! En effet si le nombre de client devient important il faut lancer le programme vlc autant de fois que le nombre de mdia demands.
II.1.e. Reprendre vobStreamer un streamer video RTP/RTSP Une autre solution est de dvelopper un serveur de streaming partir de vobStreamer. VobStreamer est implment par Live.com qui est une librairie supportant le RTSP/RTP et qui est utilis par la plus part des lecteurs vidos actuels ((mplayer|mplayer], VideoLan). Celle-ci a t dveloppe en C++ et est sous licence GPL. Elle permet le dveloppement trs rapide de serveurs et clients RTSP, RTP etc. La librairie contient aussi de nombreux outils permettant de dmontrer le niveau de fonctionnalit de la librairie. Parmis ces outils, on peut citer : openRTSP : un client capable d'ouvrir, de recevoir et d'enregistrer un flux RTSP. VobStreamer : un serveur de streaming video utilisant le RTP. Cette librairie est utilise par les deux lecteurs multimdia les plus utiliss sous Linux actuellement : MPlayer et VLC. Avantages : vobStreamer implmente les protocoles RTP/RTSP. vobStreamer semble tre minimaliste et facile modifier. Mplayer est capable de lire aux donnes envoyes par vobStreamer.
Dess SRO
19/40
II. Conception
II.2. Solution choisie
La solution choisie consiste utiliser vls comme serveur de streaming RTP. On lui ajoute un serveur nomm Vod-k qui dialogue avec les clients via le protocole RTSP. C'est ce serveur que nous implmnterons. Il permet de ne plus utiliser la commande telnet pour lancer les flux de vls. Il gre les demandes des clients et transmet les informations vls. Par exemple un client demande rtsp://xxx.xxx.xxx.xxx/extrait.mpg un film sur son lecteur vlc, par exemple
L'information est alors envoye au serveur Vod-k qui vrifie que le film est bien contenu sur le serveur Vls et si ce n'est pas le cas envoie un message d'erreur au client. Si le film est bien prsent le serveur Vod-k demande Vls de dmarrer la diffusion du film pour le client. Ensuite pour chaque requte rtsp du client, par exemple PAUSE, FORWARD... Vod-k transmet ces requtes Vls (grce aux commandes Vls) qui les excute.
Dess SRO
20/40
III. Ralisation
III. Ralisation
III.1. Dcoupage du film : mpgtx

Description : mpgtx permet de couper, joindre et dmultiplexer les films MPEG 1 et les mp3. mpgtx peut aussi diter en masse les tags ID3 des fichiers mp3 et de classer ces fichiers selon leur TAG. mpgtx est un MPeG ToolboX et un outil permettant de dcouper de la vido ou du son en paquets. Exemple de son utilisation : Dcoupe le film Matrix en 166 paquets de taille unique : mpgtx -166 matrix-trailer.mpg -b mychunk Now processing Chunk 1/166 ... 100.00 Now processing Chunk 2/166 ... 92.79 Syntaxe : mpgtx [mode] [options] file [file | range] ... Modes :

mpgtx has five fundamental modes : split mode (-s switch) join mode (-j switch) info mode (-i switch) demultiplex mode (-d switch) ID3 tag mode (-T switch)
Dess SRO
21/40
III. Ralisation
III.2. Videolan
VideoLan est une solution logicielle complte de diffusion vido, dveloppe par des tudiants de l'Ecole Centrale Paris et des dveloppeurs du monde entier, sous license GNU General Public License (GPL). VideoLan est conu pour diffuser des vidos MPEG sur des rseaux haut dbit.
La solution VideoLan comprend : VLS (VideoLan Server), qui est capable de diffuser des fichiers MPEG-1, MPEG2 et MPEG-4, des DVDs, des canaux satellite numriques, des chanes de tlvision numrique terrestre, et de la vido en temps rel sur un rseau en unicast ou multicast, VLC ( l'origine, VideoLan Client), qui peut tre utilis en tant que serveur, pour diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs, ou de la vido en temps rel sur un rseau en unicast ou multicast ; ou utilis en temps que client pour recevoir, dcoder et afficher des flux vido sous de nombreux systmes d'exploitation .
Dess SRO
22/40
III. Ralisation
III.3. VLC
Contrairement aux autres serveurs tel que Quick Time ou Microsoft, VLS, ainsi que son client VLC, ont t ports sur un grand nombre de systmes d'exploitation. On les retrouve par exemple sous Linux, Windows ou xBSD ; et mme sous Mac OS X, BeOS et Pocket PC. VLC, en plus de lire les flux provenant d'un rseau, permet galement de lire des media stocks sur DVD ou sur un disque dur. L'quipe de VideoLAN est constitue d'une cinquantaine de membres travers le monde. Le projet tant sous licence GPL, l'quipe se compose dtudiants de l'Ecole Centrale Paris, mais aussi de dveloppeurs extrieurs souhaitant apporter leur contribution au projet. VideoLAN tant un projet d'une ampleur mondiale ; des programmeurs de toutes nationalits se sont joints l'quipe de dveloppement. VLC fonctionne sur de nombreuses plateformes : Linux, Windows, Mac OS X, BeOS, *BSD, Solaris, Familiar Linux, Yopy/Linupy et QNX. Il est capable de lire : Des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX depuis un disque dur, un lecteur de CD-ROMInterface d' administration Des DVDs et VCDs, depuis une carte satellite (DVB-S), Des flux MPEG-1, MPEG-2 et MPEG-4 envoys sur le rseau par un VLS ou un VLC.
VLC peut galement tre employ en tant que serveur pour diffuser: Des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX , des DVDs, depuis une carte d'encodage MPEG,
Dess SRO
23/40
III. Ralisation
vers :

une machine (c'est dire une addresse IP) : ceci est appel unicast. Un groupe dynamique de machines que les clients rejoignent ou quittent (une addresse IP multicast): ceci est appel multicast,en IPv4 ou en IPv6 .
VLC ne fonctionne pas sous Mac OS 9, et ne fonctionnera probablement jamais sur cette plateforme.
III.4. VLS
VLS est capable de diffuser: des fichiers MPEG-1, MPEG-2 ou MPEG-4 stocks sur un disque dur, un CD, ..., un DVD dans un lecteur local ou copi sur un disque dur, une carte satellite (DVB-S) ou une carte de tlvision numrique terrestre (DVB-T) , une carte d'encodage MPEG ; vers :

une machine (c'est dire une adresse IP) : ceci est appel unicast, Un groupe dynamique de machines que les clients rejoignent ou quittent (une adresse IP multicast): ceci est appel multicast, en IPv4 ou en IPv6 .
Une machine base de Pentium 100 MHz munie de 32 Mo de mmoire devrait suffire pour diffuser un flux sur un rseau. Si vous diffusez de nombreuses vidos, stockes sur un disque dur, la vraie limitation ne vient pas du processeur mais du disque dur et de la connexion rseau. VLS fonctionne sous Linux et Windows. Pour la liste complte des possibilits de VLS sur chaque plateforme, rfrez-vous la page des fonctionnalits de diffusion.
a. Structure de VLS D'un point de vue utilisateur, VLS peut tre divis en quatre composants majeurs : un gestionnaire, des entres, des convertisseurs, et des sorties.
Dess SRO
24/40
III. Ralisation
Entres Le rle d'une entre est de lire des flux MPEG depuis une source donne (fichier, DVD, carte DVB, ...), et de les envoyer aux convertisseurs. Une entre peut lire plusieurs flux. Ceux-ci sont alors appells des programmes. Il existe plusieurs types d'entres : l'entre local, qui peut lire depuis des fichiers et des DVDs , l'entre video, qui peut lire des vidos depuis des cartes d'encodage MPEG , l'entre dvb, qui peut lire depuis des cartes DVB , l'entre v4l, qui peut lire depuis les cartes d'acquisition supportes par les pilotes Video4Linux . Vous pouvez utiliser plusieurs entres et jouer plusieurs programmes en mme temps . Les convertisseurs Le rle d'un convertisseur est de recevoir un flux depuis une entre et de le convertir au format MPEG-TS. VLS peut convertir des flux PS (provenant d'un DVD, par exemple) en flux TS, en utilisant le convertisseur ps2ts. Bien sr, il peut galement lire les flux TS, et les rparer en prenant en charge les discontinuits du flux (convertisseur ts2ts) . Les sorties Une sortie recoit le flux depuis le convertisseur, et l'envoie vers une destination donne (rseau, fichier). Actuellement, il existe deux types de sorties : network et file. Pour l'instant, VLS ne peut utiliser qu'une sortie par flux, donc vous ne pouvez pas diffuser un flux sur le rseau et l'enregistrer dans un fichier en mme temps. La sortie rseau est trs configurable: vous pouvez choisir l'interface rseau, et spcifier les adresses IP source et destination. Le gestionnaire Le gestionnaire contrle l'envoi des flux. En utilisant une interface d'administration, vous pouvez lancer, arrter, interrompre, ou reprendre les programmes. Vous pouvez galement afficher la liste des programmes disponibles, lue depuis le fichier de configuration de VLS (vls.cfg) (c'est pourquoi elle ne peut pas tre change aprs le dmarrage). Pour l'instant, vous ne pouvez pas demander au gestionnaire si un flux est en cours de diffusion, mais une erreur se produira si vous tentez de stopper un flux qui ne l'est pas .
Dess SRO
25/40
III. Ralisation
Interface d' administration Il existe deux moyens de contrler VLS : vous pouvez utiliser la ligne de commande pour passer des arguments au dmarrage, ou vous pouvez utiliser l'interface Telnet pour contrler la diffusion tout moment. Afin d'utiliser l'interface Telnet, vous devez tout d'abord vous authentifier, car tous les utilisateurs ne peuvent excuter toutes les commandes (ceci se rgle dans le fichier de configuration vls.cfg). b. Utilisation de vls Lancement de VLS Si vous dsirez utiliser l'interface telnet, lancer VLS est trs simple : tapez juste vls dans une console et c'est tout. Lancer vlsd lancera VLS en tant que dmon et le dtachera de la console. Souvenez-vous que VLS va essayer de charger son fichier de configuration (vls.cfg) depuis le rpertoire courant, et si il ne l'y trouve pas, depuis SYSCONF_DIR/etc/videolan (voir la section Configuration) . Si tout se passe bien, vous verrez quelque chose comme : VideoLAN Server v 0.5.5 (Jan 15 2004) - (c)1999-2003 VideoLAN
Une fois que VLS a dmarr, il ne prend pas d'argument sur son entre standard, et vous pouvez le mettre en tche de fond (vous pouvez utiliser l'utilitaire screen pour cela . Utilisation de l' interface telnet Aprs le lancement de VLS, un serveur telnet est ouvert, sur le port 9999 par dfaut. Vous pouvez vous y connecter l'aide de la commande : telnet localhost 9999
Vous devriez voir quelque chose comme : Trying 127.0.0.1... Connected to vls. Escape character is '^]'. Videolan Server Administration System Login:
Dess SRO
26/40
III. Ralisation
Vous devez ensuite vous authentifier l'aide du couple login/password dfini dans le fichier de configuration. Une fois l'authentification ralise, vous devriez voir une invite du type : admin@vls> > Vous pouvez ensuite taper les commandes dfinies dans le paragraphe suivant. Pour vous dlogguer, tapez logout l'invite .
Commandes de l' interface help Utilisation: help [commande] . Appele sans argument, la commande donne la liste de toutes les commandes (disponibles ou non). Avec un argument, elle donne le dtail de l'utilisation de la commande spcifie. browse Utilisation: browse [entre] . Sans argument, la commande liste les programmes des entres. Avec un argument, elle donne les programmes de l'entre spcifie. Le statut de chaque programme est donn. start Utilisation: start <programme> <sortie> <entre> [--loop] [--rtp] : lance le programme spcifi de l'entre spcifie sur la sortie spcifie. L'option --loop fait que le programme se rpte. L'option --rtp fait que les paquets TS sont envoys en utilisant le protocole RTP, dfini dans les RFC 1889 et 2250. stop Utilisation: stop <sortie> : "stop" arrte la diffusion sur la sortie spcifie. forward,rewind Utilisation: forward <sortie> <vitesse> : Avance dans la sortie donne la vitesse donne. Ceci ne fonctionne pas lors de la lecture depuis une carte d'acquisition, d'encodage, ou une carte DVB . suspend Utilisation: suspend <sortie> : Interrompt la diffusion sur la sortie spcifie. resume Utilisation: resume <sortie> : Reprend la diffusion de la sortie spcifie. logout Utilisation: logout : Ferme la session et la connexion. shutdown Utilisation: shutdown : Stoppe les diffusions et arrte VLS.
Dess SRO
27/40
III. Ralisation
III.5. VOD-K
III.5.a. Principe de fonctionnement - on lance le module vod-k qui se lance selon les paramtres de configuration et les paramtres passs en arguments : vod-k cre une socket d'coute - chaque connexion cliente, vod-k lance un processus fils qui s'occupe du dialogue avec ce client - le dialogue gre les requtes RTSP DESCRIBE, OPTIONS, SETUP, PLAY, TEARDOWN et effectue les traitements adquates - dans le cas des requtes PLAY TEARDOWN, le dialogue lance ou stoppe le streamer qui quant lui s'occupe de la diffusion du flux du media demand vers ce client via le protocole RTP (pour cela, un autre processus fils est cr et lance le streamer avec les paramtres correspondant la demande du client) - la dconnexion d'un client, tous les processus crs pour sa gestion sont tus. III.5.b. Les bibliothques dveloppes pour VoD-K Afin de grer les fonctionnalits prsentes, nous avons dvelopp le module vod-k ainsi que deux bibliothques ddies ce module : stream.h et rtsp.h vod-k : - int main (int argc, char *argv[]) programme principal qui se charge de l'initialisation du module en fonction des paramtres de configuration, des options passes en argument et de la cration du dmon qui coute les connexions clientes - void handler_main (int sig) fonction qui s'occupe du signal CTRL-C - void handler_sub (int sig) fonction qui s'occupe de la fermeture des sockets lors de l'envoi d'un signal - void deamon (char* conf_file) cette fonction permet de lanc le module en mode dmon, i.e. charge les options, cre la socket d'coute des connexions clients et cre un thread pour chaque client le module vod-k, aprs cration du thread client, lance la fonction de dialogue avec celui-ci, dialogue dfini dans la bibliothque rtsp.
Dess SRO
28/40
III. Ralisation rtsp : - int dialogue(int sock_client,int num_port) Permet la gestion du dialogue entre le client VLC et le serveur de vido. A chaque requte de la part du client, une rponse est construite et retourne. Cette fonction analyse la nature de la requte RTSP reue et lance la fonction de cration de la rponse en consquence. - int answer_describe(int sock, char * msg,char *video_name) Fonction permettant de rpondre la requete RTSP 'describe' du client : construction de la rponse en appelant les diffrentes fonctions dfinies plus loin : searchVideo, getVersionRTSP, getCSeqRTSP,getBaseRTSP,setSDP. - int answer_option(int sock, char *msg) Fonction permettant de rpondre la requete 'options' du client. Cette requete lui permet de savoir quelles actions il peut oprer sur le flux RTSP pour controler la vido demande. - int answer_setup(int sock, char *msg, int port) Fonction permettant de rpondre la requete RTSP 'setup' mise par le client. - int answer_play(int sock, char *msg, char *video_name) Cette fonction permet quant elle de rpondre la requete du client : 'play'. Aprs avoir fourni cette rponse, le client sera en mesure de recevoir le flux envoy par le serveur correspondant sa demande. - int answer_teardown(int sock, char *recu, int stream_id) Cette fonction permet d'arrter le flux vido et de stopper toute session pour ce client qui a souhaiter executer la requete 'teardown'. - int answer_not_implemented(int sock,char *recu) Cette fonction permet de signaler au client RTSP que l'action qu'il souhaite effectuer n'a pas t implement. - void getVersionRTSP(char * recu,char *ptr) Rcupration de la version RTPS prcise dans la requete RTSP 'recu' et initialise 'ptr' la valeur trouve. - void getCSeqRTSP(char * recu, char *ptr) Rcupration du numro de squence demande dans la requete RTSP 'recu' et initialisation de ptr cette valeur. - void getBaseRTSP(char * recu, char *ptr) Fonction permettant de rcuprer la location de la vido demande dans la requete 'recu' afin de rpondre la requete RTSP 'describe' mise par le client. Stockage de la chaine dans 'ptr'. - void getDateRTSP(char * strDate)
Dess SRO
29/40
III. Ralisation Permet d'initialiser la chaine strDate, selon un format GMT, la date courante - void setSDP(char * sdp) Cette fonction construit la description SDP du fichier video demande par le client et place le rsultat dans la chaine de caracteres 'sdp
- void getTransport(char * recu, char *ptr,int port) Cette fonction permet de retourner la ligne dcrivant les paramtres de Transport. - void getSession(char *ptr) Initialise 'ptr' : cette chaine est compose de mot Session suivi d'un numro alatoire qui reprsente son identifiant de session - int searchVideo(char *recu, char *video_name) La fonction searchVideo initialise la variable 'video_name' du nom de la vido contenu dans la requete RTSP 'recu' qu' mis le client. Appel la fonction 'stream_exists(...)' de la librairie stream.h afin de savoir si la video demande est disponible du cot serveur. Retourne 1 (TRUE) si la vido est disponible et 0 (FALSE) sinon. stream : - int stream_start(char* movie) Cette fonction est responsable de lancement du streamer : un processus fils est cre et celui-ci execute la commande via un execlp. Elle retourne le pid du fils afin d'avoir une rfrence sur le processus du streamer et pouvoir ainsi le tu quand ncessaire. - int stream_stop(int pid) Cette fonction est responsable de lancement du streamer : un processus fils est cre et celui-ci execute la commande via un execlp. - int stream_exists(char* movie) Cette fonction vrifie si le media demand (nom pass en paramtre) est prsent et disponible du ct serveur (i.e. Prsent dans le sous-rpertoire contenant les media).
Dess SRO
30/40
III. Ralisation
III.5.c. Schma de fonctionnement des processus dans VoD-k
Dess SRO
31/40
III. Ralisation
Dess SRO
32/40
IV. Tests
IV. Tests
- lancement de vod-k Console de vod-k
[root@a104-06 src]# ./vodk == == == == [] [] [] [] [][] [] [][] [] [] [] [] [][] [] [] [][] [][] [] [] == == == ==
[][] [] [] [][]
VoD-K v0.2b ## Chargement du fichier de configuration: rtp_source = 'local' connect_port = '554' connect_max = '2' vls_server = 'bozo:bozo@172.16.20.106:9999' vls_server = 'bozo:bozo@127.0.0.1:9999' ## Ouverture de la socket ## Serveur en attente de connexions clientes
- Connexion de vlc Console de vlc :

bash-2.05b$ /usr/local/bin/vlc rtsp://localhost:554/test.mpg VLC media player 0.7.1-test2 Bond [00000194] main input: playlist item `rtsp://localhost:554/test.mpg'
Console de vod-k :
## Serveur en attente de connexions clientes Processus PID: 2721 -> Connexion de 127.0.0.1 ## Server : waiting for client 4 action ...
Dess SRO
33/40
IV. Tests
- La requte RTSP 'DESCRIBE' Console de vlc :

Sending request: DESCRIBE rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 1 Accept: application/sdp User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 1 Content-Base: rtsp://localhost:554/test.mpg Content-Type: application/sdp Content-Length: 328 Need to read 328 extra bytes Read 328 extra bytes: v=0 o=VoDk 49451 3 IN IP4 127.0.0.1 s=SDP VoDk i=test.mpg a=tool:LIVE.COM Streaming Media v2004.02.20 a=type:broadcast a=control:* a=source-filter:incl IN IP4 * 127.0.0.1 a=rtcp:unicast reflection u=http://www.prospere.ath.cx e=vod-k-development-request@lists.sourceforge.net t=0 0 m=video 1234 RTP/AVP 32 c=IN IP4 127.0.0.1 sdp=v=0 o=VoDk 49451 3 IN IP4 127.0.0.1 s=SDP VoDk i=test.mpg a=tool:LIVE.COM Streaming Media v2004.02.20 a=type:broadcast a=control:* a=source-filter:incl IN IP4 * 127.0.0.1 a=rtcp:unicast reflection u=http://www.prospere.ath.cx e=vod-k-development-request@lists.sourceforge.net t=0 0 m=video 1234 RTP/AVP 32 c=IN IP4 127.0.0.1
Dess SRO
34/40
IV. Tests Console de vod-k :

## Client 4 sends : DESCRIBE rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 1 Accept: application/sdp User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) ## Server: sends DESCRIPTION to client 4 : OK. Sent : RTSP/1.0 200 OK CSeq: 1 Content-Base: rtsp://localhost:554/test.mpg Content-Type: application/sdp Content-Length: 328 v=0 o=VoDk 49451 3 IN IP4 127.0.0.1 s=SDP VoDk i=test.mpg a=tool:LIVE.COM Streaming Media v2004.02.20 a=type:broadcast a=control:* a=source-filter:incl IN IP4 * 127.0.0.1 a=rtcp:unicast reflection u=http://www.prospere.ath.cx e=vod-k-development-request@lists.sourceforge.net t=0 0 m=video 1234 RTP/AVP 32 c=IN IP4 127.0.0.1 ## Server : waiting for client 4 action ...
- la requte RTSP 'OPTIONS' Console de vlc :

Sending request: OPTIONS * RTSP/1.0 CSeq: 1 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY
Console de vod-k :
## Client 5 sends : OPTIONS * RTSP/1.0 CSeq: 1 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) ## Server: sends OPTION to client 5 : OK. Sent : RTSP/1.0 200 OK CSeq: 1 Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY ## Server : waiting for client 5 action ...
Dess SRO
35/40
IV. Tests
- la requte RTSP 'SETUP' Console de vlc :

Sending request: SETUP rtsp://localhost:554/test.mpg/ RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=1234-1235 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Received SETUP response: RTSP/1.0 200 OK CSeq: 2 Session: 84018771 Transport: RTP/AVP;multicast;destination=127.0.0.1;port=1234;ttl=255
Console de vod-k :
## Client 5 sends : SETUP rtsp://localhost:554/test.mpg/ RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=1234-1235 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) ## Server: sends SETUP to client 5 : OK. Sent : RTSP/1.0 200 OK CSeq: 2 Session: 84018771 Transport: RTP/AVP;multicast;destination=127.0.0.1;port=1234;ttl=255 ## Server : waiting for client 5 action ...
- la requte RTSP 'PLAY' Console de vlc :

Sending request: PLAY rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 3 Session: 84018771 Range: npt=0User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Received PLAY response: CSeq: 3 RTSP/1.0 200 OK
Dess SRO
36/40
IV. Tests
Console de vod-k :
## Client 5 sends : PLAY rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 3 Session: 84018771 Range: npt=0User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Beginning streaming... Beginning to read from file... -> Streaming de la video test.mpg lanc ... ## Server: sends PLAY [test.mpg] to client 5 : OK. Sent : RTSP/1.0 200 OK CSeq: 3 ## Server : waiting for client 5 action ...
- la requte RTSP 'TEARDOWN' Console de vlc :

Sending request: TEARDOWN rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 4 Session: 84018771 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) Received TEARDOWN response: CSeq: 4 bash-2.05b$ RTSP/1.0 200 OK
Console de vod-k :
## Client 5 sends : TEARDOWN rtsp://localhost:554/test.mpg RTSP/1.0 CSeq: 4 Session: 84018771 User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.02.20) ## Server: sends TEARDOWN to client 5 : OK. Sent : RTSP/1.0 200 OK CSeq: 4 ## Server : waiting for client 5 action ... Processus PID: 2723 -> Dconnexion du client Processus PID: 2721 -> Dconnexion du client
- fermeture du module vod-k Console de vod-k :

CTRL+C Processus fils: 2704 tu Terminaison du processus Fils n2704 [root@a104-06 src]# => 0
Dess SRO
37/40
Conclusion
Perspectives
Le projet VoD-k est sujet a de nombreuses perspectives d'avenir en terme de dveloppement de fonctionnalits : Implmenter VoD-k pour qu'il puisse recencer les vidos disponibles sur les diffrents serveurs VLS au sein d'une base de donnes dans le but de proposer la liste des mdia sur le Web. Implmenter un module de statistiques pour obtenir un retour d'utilisation du serveur VoD-k. Grer l'quilibrage de la charge rseau des diffrentes sources RTP (VLS, Streamer, ...) via le protocole SNMP. Implmenter VoD-k afin qu'il puisse changer avec d'autres serveurs VoD-k la liste des vidos disponibles Implmenter VLS pour qu'il s'annonce aux serveurs VoD-k lorsqu'il sont ''actifs'' Modifier VoD-k pour qu'il utilise directement les librairies de Live

Dess SRO
38/40
Conclusion
Conclusion
Ce projet a reprsent un travail de recherche important concernant les protocoles prsents, mais aussi concernant les outils utiliss. Le monde du logiciel libre tant trs instable, il a t trs difficile de faire des choix techniques concernant la ralisation du projet. Les volutions qu'ont subit VLC et VLS sont importantes depuis le dbut du projet et une adaptation de nos choix a d s'oprer tout au long de leurs volutions. De plus ce projet reprsente un norme travail relationnel, au sein du groupe, avec notre tuteur de projet, mais aussi avec l'quipe de l'Epita qui a travaill sur VLS et Fenrir le responsable du dveloppement de VLC. La communication reprsente une tache trs importante au sein du dveloppement d'un projet. Le dveloppement de VoD-k nous a ainsi men l'utilisation d'outils existants, l'adaptation de notre conception et ralisation du module en fonction des changements ; VoD-k est par consquant non seulement un travail d'quipe mais aussi un projet de collaboration. Le projet est disponible sur Internet via le site de Sourceforge, et nous esperons que son dveloppement continuera au fur et mesure que la librairie Live.com voluera.
Dess SRO
39/40
Glossaire
Glossaire
STREAMING : Terme gnrique pour dfinir la technologie de transfert et de visualisation de vido en temps rel sur l'Internet ou sur tout type de rseau. Cette technique permet de commencer visualiser un fichier vido avant mme la fin de son tlchargement complet. PROTOCOLE DE COMMUNICATION : Norme de communication entre ordinateurs. Logiciel d'change de logiciels distance - il s'assure que la copie soit conforme l'original. RTSP : Real Time Streaming Protocol. Protocole destin aux applications multimdia sur l'Internet. Ce protocole permet de rserver de la bande passante ncessaire la diffusion d'un fichier utilisant la technologie streaming. RTP : Real-time Transport Protocol. Protocole de transport en temps rel. Broadcast : Terme utilis pour indiquer que les paquets transfrs sur le rseau sont destination de toutes les machines dun sous-rseau. DVD : Digital Versatile Disc. Mdium informatique se prsentant sous forme de disque laser et offrant une capacit de stockage de 4,7 Go. Aujourdhui, le DVD est essentiellement utilis pour stocker des films vido. Mpeg : Format de compression vido. Multicast : Terme utilis pour indiquer que les paquets transfrs sur le rseau sont destination de plusieurs machines distinctes. Unicast : Terme utilis pour indiquer que les paquets transfrs sur le rseau sont destination dune seule et unique machine. VOD : Video On Demand. Technologie permettant que commander des films vido par le biais dun rseau local ou dinternet.
Dess SRO
40/40

Conception Serveur Vod

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Conception Serveur Vod

Hochgeladen von

Copyright:

Verfügbare Formate

DESS S.R.

Conception d'un serveur de vido la demande

Responsable : Claude Duvallet

Nous tenons remercier tout particulirement :

I.2. Les acteurs du projet

I. Analyse du projet I.3.b. Fonctionnement

I.5. Les protocoles RTSP/RTP

Comment RTSP ragit avec les autres protocoles standard dInternet ?

I. Analyse du projet I.5.c. Relation rtsp/rtp

I.6. Le protocole SDP

II.1.b. Partir de VLS

II.1.c. Partir de VLC

II.2. Solution choisie

III.1. Dcoupage du film : mpgtx

III.5.c. Schma de fonctionnement des processus dans VoD-k

- Connexion de vlc Console de vlc :

- La requte RTSP 'DESCRIBE' Console de vlc :

IV. Tests Console de vod-k :

- la requte RTSP 'OPTIONS' Console de vlc :

- la requte RTSP 'SETUP' Console de vlc :

- la requte RTSP 'PLAY' Console de vlc :

- la requte RTSP 'TEARDOWN' Console de vlc :

- fermeture du module vod-k Console de vod-k :

Das könnte Ihnen auch gefallen