PFE1

Mmoire de Projet de Fin dtudes
Pour lObtention du Titre
Master Spcialis Rseaux et Systmes

Par Benjieda Hicham Encadr par Pr. Fakhri Youssef Mr.Elbachraoui Mohamed
Sujet
La mise en place dune plateforme de vido surveillance logicielle, base sur des technologies de compression vido rcentes
Soutenu le 10 juillet 2010, devant le Jury : M. Jaafar ABOUCHABAKA, Facult des Sciences de Kenitra, prsident M. Youssef FAKHRI, Facult des Sciences de Kenitra M. Mohammed LAAROUSSI, Facult des Sciences de Kenitra
Anne Universitaire 2009-2010
Ddicace A mes trs chers parents, Aucun mot et aucune langue ne pourra exprimer mes sentiments envers vous. A mes chres surs Naima et Fatimazahra A mes chers frres Rachid et Ayoub A toute ma famille. A tous mes chers amis, A mes chers amis de la facult, Pour tout le soutien que vous mavez offert, je vous dis MERCI.
A tous ceux qui maiment.
Hicham Benjieda
Remerciements
Il mest agrable dexprimer ma reconnaissance auprs de toutes les personnes, dont lintervention au cours de ce projet, a favoris son aboutissement.
Ainsi, je tiens exprimer ma grande estime et toutes mes reconnaissances mon encadrant M. Youssef FAKHRI pour ses directives prcieuses et ses conseils pertinents qui ont t dun appui considrable dans ma dmarche.
Jexprime mes profonds respects et mes sincres gratitudes M. Mohamed ELBACHRAOUI, de mavoir accueilli au sein de sa direction lONEP.
Je tiens remercier, M. Jaafar ABOUCHABAKA, pour son soutien et son apport tout au long de ces deux annes dtudes universitaires.
Je saisis loccasion pour remercier tous les membres du jury qui nous ont fait lhonneur daccepter de juger notre travail.
Je ne saurais oublier dans mes remerciements tout le cadre professoral de la FSK, pour la formation quil nous a prodigu.
Que tous ceux qui nous ont aids, de prs ou de loin, trouvent ici lexpression de mes meilleurs sentiments.
Rsum
La vido surveillance est gnralement dploy dans de nombreuses socits a fin de protger des bien ainsi que des zones spcifique au sein de linfrastructure dune entreprise .Nanmoins ce genre de solution est bien souvent trop onreuse en raison de linvestissement dans le matriel ddi mais galement du fait quil est souvent ncessaire quun employ soit la source du system pour superviser lensemble. Ce projet de fin dtudes men au sein de lONEP (Office National dEau Potable) consiste dvelopper sous linux une plate forme de vido surveillance logicielle, base sur des technologies de compression vido rcentes. Pour cela il faut dvelopper du socle logiciel permettant dassurer les fonctions de bases dun system de vido surveillance numrique, en utilisant des technologies de compression vido pour minimiser la taille du flux transfr et aussi bien enregistr. Suite une comparaison entre les technologies de streaming existantes, nous avons opt pour RealSystem de RealNetworks qui offre une solution complte comprenant : le codeur, le serveur et le client.
Mots cls : Vido surveillance, Compression vido, RTP (Real-time Transport Protocol), RealSystem, RealNetwork, suivi.
Table des figures

Figure 1 : Organigramme de lONEP ...................................................................................... 16 Figure 2 : Architecture rseau de lONEP................................................................................ 17 Figure 3 : Organigramme de la DSI ......................................................................................... 18 Figure 4 : Camras de surveillance .......................................................................................... 22 Figure 5 : Evolution du matriel de vidosurveillance............................................................. 28 Figure 6 : Le format YUV 4 :1 :1............................................................................................. 39 Figure 7 : Introduction des pertes dans le processus de compression ...................................... 39 Figure 8 : schma gnral dun codeur vido........................................................................... 40 Figure 9 : Exemple dagencement dun GOP .......................................................................... 42 Figure 10 : Allure typique dune courbe du rapport dbit / distorsion ..................................... 43 Figure 11 : Exemple dimage mosaque construite partir dun ensemble dimages ............. 44 Figure 12 : Schma de codage H.261 ....................................................................................... 46 Figure 13 : Transmission unipoint dun flux ............................................................................ 50 Figure 14 : Transmission multipoint dun flux ........................................................................ 50 Figure 15 : Paquets RTP et RTCP ............................................................................................ 52 Figure 16 : Principe du RSVP .................................................................................................. 53 Figure 17 : Les communications client/serveur dans le cas du RTP ........................................ 56 Figure 18 : Les communications client/serveur en mode RDT ................................................ 57 Figure 19 : Les communications client/serveur en mode TCP seul ......................................... 57 Figure 20 : Fonctionnement de RTSP ...................................................................................... 58 Figure 21 : Les composants de real system...62 Figure 22 : Initialisation des communications entre RealServer et RealPlayer ....................... 63 Figure 23 : Comparaison des technologies de streaming ......................................................... 65 Figure 24 : Enregistrement des prsentations Real Media ....................................................... 66 Figure 25 : Enregistrement dune prsentation pour diffrentes largeurs de bande ................. 67 Figure 26 : Fonctionnement codeur/serveur dans le cas normal .............................................. 70 Figure 27 : Fonctionnement codeur/serveur dans le cas dun pare-feu .................................... 71 Figure 28 : Phase initial de la communication client/serveur .................................................. 71 Figure 29 : Phase de transfert de donnes entre le client et le serveur ..................................... 71 Figure 30 : Schma de multipoint ............................................................................................ 73 Figure 31 : Schma de la back-Channel multicast ................................................................... 74 Figure 32 : Schma du scalable multicast.74
Figure 33 : Type de permission.77 Figure 34 : Prfrences de transmission...79 Figure 35 : Options de transport pour le protocole RTSP79 Figure 36 : Utilisations des proxys...80 Figure 37 : Plate-forme ralise81 Figure 38 : Cration du sous rseau R1....83
Table des matires
Table des matires

Table des figures ........................................................................................................................ 5 Table des matires ...................................................................................................................... 7 Introduction gnrale ................................................................................................................ 11 Contexte du projet .................................................................................................................... 12 Chapitre 1 ................................................................................................................................. 13 Organisme daccueil : ONEP ................................................................................................ 13 1 2 3 4 5 Historique de lONEP ...................................................................................................... 14 Principales activits .......................................................................................................... 15 Organigramme de lONEP ............................................................................................... 16 Architecture rseau de lONEP ........................................................................................ 17 Prsentation de la DSI ...................................................................................................... 18 5.1 Organigramme de la DSI Direction contrle de gestion et Systems dinformation ..................................................................................................................... 18 5.2 Missions de la DSI .................................................................................................. 19 Conclusion ................................................................................................................................ 19 Chapitre 2 ................................................................................................................................ 20 Etude thorique et analyse du projet de vidosurveillance ................................................. 20 1 Dfinition du domaine ...................................................................................................... 21 1.1 1.2 2 2.1 2.2 2.3 2.4 2.5 2.6 3 3.1 3.2 3.3 4 Scurit ..................................................................................................................... 21 vidosurveillance ...................................................................................................... 22 Acquisition .............................................................................................................. 24 Transmission ........................................................................................................... 25 Compression ............................................................................................................ 25 Traitement ............................................................................................................... 26 Archivage ................................................................................................................ 27 Affichage ................................................................................................................. 28 Premire gnration : le tout analogique ................................................................. 29 Deuxime gnration : systme hybride ................................................................. 29 Troisime gnration : le tout numrique IP ........................................................... 31
Composantes dun systme de vidosurveillance ............................................................ 23
volution des systmes de vidosurveillance .................................................................. 28
Vidosurveillance IP ........................................................................................................ 32
Table des matires
Architecture dun rseau de vidosurveillance intelligente ............................................. 35 5.1 5.2 Architecture centralise ........................................................................................... 35 Architecture distribue ............................................................................................ 35
Conclusion ................................................................................................................................ 36 Chapitre 3 ................................................................................................................................ 37 Compression vido ................................................................................................................. 37 1 La reprsentation dune squence vido .......................................................................... 38 1.1 2.1 3.1 3.2 Le format YUV 4 :1 :1 ............................................................................................. 38 La rduction de lentropie .................................................................................... 40 La structuration du flux vido .............................................................................. 42 Apprciation des erreurs de compression ............................................................. 43
2 La compression de donnes .................................................................................................. 39 3 Codage vido par estimation et compensation de mouvements ........................................... 41
4 Les images de rfrence ...................................................................................................... 44 5 Les normes de compression excitantes ............................................................................... 44 5.1 5.1 Les normes de lUIT-T ......................................................................................... 45 Les normes de lISO-IEC ..................................................................................... 47
Conclusion ................................................................................................................................ 48 Chapitre 4 ................................................................................................................................ 49 Lapproche Streaming ............................................................................................................ 49 1 Notions sur la transmission des mdias............................................................................... 50 1.1 1.2 1.3 1.4 2.1 2.2 3.1 3.2 3.2.1 3.2.2 3.2.3 3.3 La transmission multipoint ................................................................................... 50 RTP : Le Protocole temps rel .................................................................................... 51 RTCP : Le Protocole de contrle ................................................................................ 51 RSVP : Rservation des ressources ............................................................................. 52 Le temps rel sur un serveur web ......................................................................... 53 Le temps rel sur un serveur ddi ....................................................................... 54 RTSP et HTTP ..................................................................................................... 55 Les formats de paquets de donnes ...................................................................... 55 Utilisation de RTP ............................................................................................ 56 Utilisation de RDT ........................................................................................... 56 Utilisation de TCP seul .................................................................................... 57 Les mthodes RTSP ............................................................................................. 57
2 Les mthodes de streaming ................................................................................................. 53
3 Le protocole RTSP .............................................................................................................. 55
Table des matires
Conclusion ................................................................................................................................ 59 Chapitre 5 ................................................................................................................................ 60 Solution et ralisation ............................................................................................................. 60 1 Introduction ......................................................................................................................... 61 1.1 2.1 2.2 2.3 3.1 3.1.1 3.1.2 3.1.2 3.1.2 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.3.1 3.3.2 3.3.3 4.1 4.2 4.3 4.4 4.4 4.4.1 4.4.2 4.4.3 Prsentation de RealSyetem ..................................................................................... 61 Cot .......................................................................................................................... 63 Scalabilit ................................................................................................................. 64 Administration et scurit ........................................................................................ 64 Le codeur de RealNetworks .................................................................................... 65 Fonctionnement de RealProducer .................................................................... 65 SureStream ....................................................................................................... 66 Realvideo .......................................................................................................... 67 Options de compression ................................................................................... 68 Le serveur de RealNetworks ................................................................................... 69 Conditions de fonctionnement ......................................................................... 69 Fonctionnement ................................................................................................ 69 Mthode de livraison des mdias ..................................................................... 72 Le multipoint .................................................................................................... 73 Gestion de la bande passante ............................................................................ 75 La Scurit ........................................................................................................ 75 RealPlayer ............................................................................................................... 78 Fonctionnement ................................................................................................ 78 Transport des donnes ...................................................................................... 78 Autres configurations ....................................................................................... 80 Schma de la plate-forme ralise ........................................................................... 81 Principe de lARP Proxy ......................................................................................... 82 Lutilitaire ipchains ................................................................................................. 84 Configuration requises du noyau ............................................................................. 84 Logiciels utiliss ...................................................................................................... 85 Le serveur web apache ..................................................................................... 85 Fonctionnement ................................................................................................ 85 Configuration ................................................................................................... 86 2 Comparaison entre les technologies de streaming .............................................................. 63
3 tude du cas de RealNetworks ............................................................................................ 65
4 Plate-forme ralise ............................................................................................................. 81
Table des matires
Conclusion ................................................................................................................................ 86 Conclusion Gnrale ............................................................................................................... 87 Bibliographie ........................................................................................................................... 88
Introduction gnrale
Introduction gnrale
Le progrs en tlcommunications numriques sest conjugu au progrs calculatoire qui la prcd pour offrir la ralisation darchitectures complexes de systmes communiquant entre eux dont la mise en liaison a permis de rsoudre beaucoup de problmes dans beaucoup de domaines. La vidosurveillance a ainsi volu depuis les simples systmes analogiques indpendants vers le client-serveur analogique numrique et depuis le client serveur simple vers les architectures distribues qui dlivrent un rsultat riche et pertinent dduit partir de la fusion de plusieurs informations issues de plusieurs camras. Ce progrs a aussi chang la manire dont on a pu exploiter nos systmes classiques : la vidosurveillance de nos jours ne rpond pas seulement au problme de la scurit mais elle aide aussi dgager des statistiques sur le trafic routier sur des larges chelles, et des donnes de comportement de la clientle dun centre commercial sur la petite chelle pour dornavant assister la prise des dcisions ! La vidosurveillance est dornavant un domaine part qui comporte des techniques et des objectifs totalement nouveaux. Il y a quelques annes, on ne cite la vidosurveillance que pour parler des systmes de numrisations, des systmes de codage et des techniques de capture du signal images. Mais aujourdhui, de la reprsentation vers la transmission ou du traitement vers lexploitation, le signal est dornavant maitris sur le plan programmatique, et du coup tout a chang, et les axes de recherche et dexploitation daujourdhui se sont totalement transforms. Dans ce projet, le premier chapitre est consacr lONEP : son historique, ses activits et son organigramme, le second chapitre traite ltude gnrale du projet de vidosurveillance, le troisime chapitre dtaille laspect thorique des technologies de compression vido, et le quatrime chapitre je vais expliquer les mthodes de streaming utilises et leur fonctionnement avant dexposer la solution ralise et ses rsultats dans le dernier chapitre.
11
Contexte du projet
Contexte du projet
Environnement Ce projet comporte deux grandes parties : La mise en place dune plateforme de vido surveillance logicielle permettant dassurer les fonctions de bases dun systme de vido surveillance numrique. utilisation des technologies de compression vido rcentes.
Lenvironnement utilis est le suivant : Systme d'exploitation : Windows server 2003 et Linux
12
Chapitre 1
Organisme daccueil : ONEP

Historique Principales activits Lorganigramme de lONEP Architecture rseau de lONEP Prsentation de la DSI
Rsum Ce chapitre introduit lorganisme daccueil : Office National de lEau Potable (ONEP) son historique, ses activits organigramme. et son
Chapitre 1
1 Historique de lONEP
LOffice National de lEau Potable a t cr en 1972 suite la rgie dexploitation industrielle cre par le dahir du 19 juillet 1929 qui avait une activit trs diversifie durant le protectorat Cest le 1er tablissement public qui a rgi un contrat plan avec ltat prvoyant les obligations et les droits de chaque partie. Le statut de cet tablissement est public, il vise lintrt gnral caractre industriel et commercial. Sa cration a permis un meilleur rapport qualit prix et llargissement du champ daction au petit centre et au monde rural et la distribution de leau via les rgies seulement lorsque les communes sont dans lincapacit de le faire (lONEP 200 centres en grance). De plus, lONEP est dot de lautonomie financire et de lautonomie de gestion, plac sous la tutelle du ministre de lquipement. Lobjectif de lONEP est fix par les missions principales dont elle est investie telles quelles sont dfinies par son dahir de cration. Ses missions principales vont de la planification la distribution de leau potable en passant par les phases de ltude, conception, ralisation (Travaux et prvisions financires), gestion et exploitation des units de production et de distribution et du contrle de la qualit des eaux (41 laboratoires) jusqu la protection de la ressource et ses derniers temps lassainissement galement. Sans oublier la direction de centre de formation aux techniques de leau interne lONEP qui participe la formation continue et aux diverses formations programmes pour assurer aux agents ONEP les performances requises.
14
Chapitre 1
2 Principales activits PLANIFIER

L'approvisionnement en eau potable du Royaume et la programmation des projets.
ETUDIER
L'approvisionnement en eau potable et assurer l'excution des travaux des units de production et de distribution.
GERER
La production d'eau potable et assurer la distribution pour le compte des communes qui le souhaitent.
CONTROLER
La qualit des eaux produites et distribues et la pollution des eaux susceptibles d'tre utilises pour l'alimentation humaine.
ASSISTER
En matire de surveillance de la qualit de l'eau
PARTICIPER
aux tudes, en liaison avec les ministres intresss, des projets de textes lgislatifs et rglementaires ncessaires l'accomplissement de sa mission.
15
Chapitre 1
3 Organigramme de lONEP
Figure 1 : Organigramme de lONEP
16
Chapitre 1
4 Architecture rseau de lONEP
Figure 2 : Architecture rseau de lONEP
17
Chapitre 1
5 Prsentation de la DSI
5.1 Organigramme de la DSI Direction contrle de gestion et Systems dinformation
Figure 3 : Organigramme de la DSI
18
Chapitre 1
5.2
Missions de la DSI
MISSIONS
Assurer le suivi et le pilotage du systme de contractualisation interne ; Piloter llaboration du budget et ses mises jour ; Mettre en place et piloter un systme de pilotage et de reporting la Direction Gnrale; Migration dune application de gestion de mobilit de personnelles vers lASP.net. Assurer la prparation et le bon droulement des sessions du Conseil dAdministration CA de loffice ; Mettre en place un systme de contrle des performances ; Participer llaboration des contrats programmes.
Conclusion
Ce stage ma t trs bnfique, car il m a permis, dune part davoir plus dinformations concernant tout quest en relation avec les rseaux et systmes et aussi bien la programmation Oriente Objet et dautre part, il ma permis de reconnatre des gens, oprer des contacts et grer des situations quasi nouvelles Et cest bien en ce sens que nous considrons cette exprience trs dterminante parce quelle nous a permis de mettre lpreuve notre savoir et perfectionner nos tudes et tablir des communications crites et orales avec les intervenants internes et externes de lONEP.
19
Chapitre 2
Etude thorique et analyse du projet de vidosurveillance
Dfinition du domaine Composantes dun systme de vidosurveillance Evolution des systmes de vidosurveillance Vidosurveillance IP Architecture dun rseau de vidosurveillance intelligente
Rsum Dans ce deuxime chapitre du prsent rapport nous prsentons une tude thorique du projet de vidosurveillance en commenant par une dfinition du domaine de la vidosurveillance et introduire les composantes dun systme de vidosurveillance, ensuite nous dvoilons lvolution de ce systme vers le IP et enfin nous parlons de larchitecture dun rseau de vidosurveillance intelligente.
Chapitre 2
1 Dfinition du domaine
1.1 Scurit
La scurit comprend deux aspects : la scurit physique et la scurit logique. La scurit physique traite des mesures physiques prises pour sauvegarder le personnel, empcher tout accs non autoris aux quipements, installations, matriels et documents et les protger contre l'espionnage, le sabotage, les dtriorations et le vol. Elle couvre donc la protection des personnes, des biens et des lieux. La scurit logique cible la protection dactifs informatiques dune organisation et vise la mise en vigueur dun ensemble de mesures de scurit permettant dassurer la confidentialit et lintgrit des biens informatiques immatriels et des oprations informatiques, et de les protger contre toute forme de menace accidentelle ou humaine. Lexpression biens informatiques immatriels dsigne les logiciels, les donnes et les rseaux. Avec linformatisation et la cybercriminalit quelle entrane, la scurit logique, quoiquencore rcente, gagne en importance. Alors que la scurit physique est habituellement prise en charge par du personnel de scurit (agents de scurit, gardiens, services de police, etc.), la scurit logique relve de spcialistes en technologies de linformation et administrateurs de systmes informatiques. Toutefois, lheure o la protection physique et la surveillance reposent de plus en plus sur des technologies informatiques, scurit physique et logique ont tendance converger. Dans son application, la scurit peut se rpartir en cinq fonctions : protection civile, prvention, intervention, investigation et rtablissement. Depuis les vnements du 11 septembre 2001 survenus aux tats-Unis, on note un changement de paradigme en scurit. On vise davantage la prvention dincidents potentiellement catastrophiques plutt que lenqute aprs le fait. On cherche des mthodes et des technologies qui permettront de dtecter les vnements suspects et den prvenir les dommages sur les personnes, les biens, les lieux et les donnes.
21
Chapitre 2
1.2
vidosurveillance
La vidosurveillance est un segment de lindustrie de la scurit physique. Cette dernire inclut aussi le contrle daccs, la dtection et le contrle dincendies, la gestion technique de btiments, les systmes assurant la scurit des personnes et la dtection dintrusion. La vidosurveillance consiste surveiller distance des lieux publics ou privs, l'aide de camras, le plus souvent motorises, qui transmettent les images saisies un quipement de contrle qui les enregistre ou les reproduit sur un cran (Figure 4). Elle capte sur image les flux de personnes pour surveiller les alles et venues, prvenir les vols, agressions et fraudes, ainsi que pour grer les incidents et mouvements de foule.
Figure 4 : Camras de surveillance
Bien que ses premires utilisations remontent aux annes 1950, la surveillance au moyen de systmes de tlvision en circuit ferm (TVCF) sest vraiment dveloppe partir des annes 1970, principalement au Royaume-Uni, pour lutter contre les activits terroristes. lheure actuelle, le Royaume-Uni constitue dailleurs la socit la plus surveille avec un nombre estim plus de quatre millions de camras de surveillance dployes sur son territoire. Limplantation de la vidosurveillance sest intensifie au cours des annes 1990, mais elle a connu un dveloppement fulgurant suite aux attentats de septembre 2001 aux tats-Unis, et puis ceux de Londres en 2005. La peur grandissante face au terrorisme n'est pas le seul facteur dadoption de la technologie de vidosurveillance. Celle-ci savre indispensable pour le suivi des oprations et la gestion des incidents de scurit dans les lieux publics et privs. De plus, elle constitue un outil denqute irremplaable pour la rsolution de crimes, de mfaits ou de 22
Chapitre 2
litiges. Toutefois, la preuve ne semble pas encore faite que la vidosurveillance actuelle permette de prvenir les incidents de scurit ou quelle fasse chuter la criminalit. Un rseau de tlvision en circuit ferm (TVCF) est un systme vido qui transmet des images en boucle ferme. Autrefois uniquement analogiques, les rseaux TVCF intgrent maintenant des composantes numriques. Laccs au rseau de transmission peut, dans certains cas, se faire par Internet. Seuls des utilisateurs dtenant des droits daccs au rseau peuvent accder linformation fournie par les camras. Les activits de scurit dun rseau de TVCF sont : Dissuasion Observation Surveillance Collecte de renseignements valuation dun incident probable et intervention connexe valuation dun incident en cours et intervention connexe Analyse judiciaire aprs lincident Analyse des lments de preuve aprs lincident Il existe trois types de vidosurveillance : Active : surveillance dune aire pour appuyer le travail sur place dagents de scurit ou lors dintervention durgence. Passive : un employ surveille un petit nombre dcrans de tlvision en sadonnant dautres tches. Enregistrement : permet de collecter des renseignements, des fins denqute et de preuve. Les enregistrements sont conservs pendant une dure dtermine, dpendant des besoins et des limites des espaces darchivages.
2 Composantes dun systme de vidosurveillance

Cette section prsente, de faon sommaire, les diffrentes composantes matrielles et logicielles des systmes de vidosurveillance. Une description plus dtaille de linfrastructure des systmes de vidosurveillance
23
Chapitre 2
2.1
Acquisition
Il existe une panoplie de modles de camras rpondant diffrents besoins de surveillance. Elles sont analogiques ou numriques et peuvent tre motorises ou non. Plus spcifiquement, on retrouve les types de camras suivants.
Fixe : Pointe dans une direction unique, elle couvre une zone dfinie (une entre, une
portion de stationnement, etc.). Cest la camra de surveillance traditionnelle. Elle constitue un excellent choix lorsquon dsire que la prsence de la camra, ainsi que sa direction de surveillance, soient visibles.
PTZ (Pan-Tilt-Zoom) : Motorise, elle peut tre actionne, manuellement ou
automatiquement, dans des mouvements panoramique/inclinaison/zoom. Elle sert suivre des objets ou des individus se dplaant dans la scne ou zoomer sur des rgions dintrt (par exemple, sur une plaque dimmatriculation).
* Dme : Recouverte dun caisson hmisphrique, ce qui la rend discrte et, dans certains
modles, rsistante au vandalisme et aux intempries. Elle peut tre fixe ou mobile. Les versions motorises couvrent une zone trs large, grce leur balayage horizontal de 360 et de 180 la verticale. Bien quen tour de garde , elle puisse remplacer dix camras fixes en balayant laire surveiller, elle nobserve quune seule direction la fois.
* Mgapixel : Offre une rsolution plus leve que les camras standards, allant de 1 16
mgapixels. Elle permet soit de capter une image plus dtaille, soit de couvrir un plus large champ visuel, rduisant le nombre de camras ncessaires pour couvrir une aire surveiller. Lorsquutilise avec un grand angle, elle possde un espace de visualisation allant gnralement de 140 360. Offrant la possibilit de zoomer de faon logicielle dans limage, elle peut ainsi devenir une alternative la camra PTZ mcanique qui entrane lusure des pices. Sa rsolution leve contribue lamlioration de la performance des algorithmes de dtection et de reconnaissance exigeant un haut niveau de dtails, telles que la lecture de plaques dimmatriculation et la reconnaissance de visage.
* Infrarouge et thermique : Sensible au rayonnement infrarouge (IR), elle est capable de
produire une image de bonne qualit dans le noir pour une surveillance nocturne. De nuit, elle filme en noir et blanc, mais elle peut produire une image couleur le jour. Certaines camras infrarouges sont quipes de leur propre source de lumire IR, allume lorsque le niveau dclairage chute sous un certain seuil. Des projecteurs IR spars (lampe ou LED) peuvent 24
Chapitre 2
aussi tre utiliss. Les camras thermiques enregistrent le rayonnement de chaleur des objets. Elles ne requirent aucune source dillumination.
* Panoramique : Grce une optique spciale, elle offre 360 de visibilit avec une seule
camra. Elle permet un PTZ virtuel dans limage. Les principales technologies panoramiques pour la surveillance sont le fisheye, la lentille miroirs et la lentille panomorphe. Toutefois, la rsolution de ces camras est souvent insuffisante pour des analyses ncessitant un niveau de dtail lev.
2.2
Transmission
La vido capte par les camras de surveillance doit tre transmise aux systmes denregistrement, de traitement et de visionnement. Cette transmission peut se faire par cble (cbles coaxiaux ou fibre optique, fils de cuivre torsads) ou travers lair (signaux infrarouges, transmission radiolectrique). La vido filaire prdomine largement dans les systmes de vidosurveillance. Elle offre une plus grande bande passante et une meilleure fiabilit que les connections sans fil, un cot infrieur. Cependant, la transmission vido sans fil simpose parfois comme solution, par exemple dans le cas de surveillance de grands primtres o linstallation de cblage savrerait trop coteuse, ou lorsque les zones surveiller sont impossibles rejoindre par cble. Quil transite par fil ou sans fil, le signal vido peut tre analogique ou numrique. Encore aujourdhui, la majeure partie des transmissions vido pour la surveillance sont analogiques. Nanmoins, les rseaux informatiques (LAN, WAN ou Internet) sont de plus en plus utiliss pour transporter la vido grce au protocole IP. Les camras IP peuvent se connecter directement sur ces rseaux, tandis que les flux vido mergeant de camras analogiques doivent, au pralable, tre numriss par un encodeur, aussi appel serveur vido, pour passer par les rseaux IP.
2.3
Compression
La vido numrise reprsente une grande quantit de donnes transmettre et archiver. Lenvoi dune squence vido peut ncessiter jusqu 165 mgabits de bande passante et la vido dune seule camra pour une journe peut occuper sept gigaoctets despace disque. Cest pourquoi la vido de surveillance doit tre compresse grce des codecs, algorithmes permettant de rduire la quantit de donnes en supprimant les redondances, par image ou entre les trames dune squence, ainsi que les dtails imperceptibles lil humain. Selon le type de compression, lusage du processeur requis pour lexcution du codec est plus ou 25
Chapitre 2
moins intensif. Un compromis simpose donc entre le taux de compression et les ressources du processeur qui sont accapares. Il existe deux grands groupes de standards internationaux de compression : JPEG, crs par le Joint Photographic Experts Group, et MPEG, labors par le Moving Photographic Experts Group. Dans le premier groupe, on retrouve les formats JPEG pour les images fixes, et MJPEG pour les squences vido. Le second groupe comprend les formats MPEG-1, MPEG-2, MPEG-4 et H.264. lheure actuelle, MJPEG et MPEG-4 sont les standards les plus rpandus en vidosurveillance. Toutefois, avec les amliorations en qualit et efficacit (taux de compression, latence, rsistance lerreur) quil apporte, H.264 devrait bientt remplacer MPEG-4. En effet, sans affecter la qualit de limage, lencodeur H.264 permet de rduire la taille de celle-ci de plus de 80 % par rapport la compression MJPEG, et de 50 % par rapport la compression MPEG-4. Et je vais parler de la compression vido plus en dtail dans le chapitre suivant.
2.4
Traitement
Les systmes de gestion vido oprent les traitements des images de vidosurveillance, tels que la gestion des diffrents flux vido, le visionnement, lenregistrement, lanalyse et la recherche dans les squences enregistres. Il existe quatre grandes catgories de systmes de gestion vido. Enregistreur vido numrique (DVR) : Appareil qui dispose dun disque dur interne pour lenregistrement numrique de la vido et dun logiciel intgr de traitement de la vido. Il naccepte que les flux provenant de camras analogiques, quil numrise. Les modles rcents permettent de visionner la vido distance sur ordinateur. Encore trs rpandus, ils laissent toutefois peu peu leur place aux systmes supportant la vido IP de bout en bout. Enregistreur vido hybride (HDVR) : Similaire lenregistreur numrique, mais accepte la fois le branchement de camras analogiques et IP. Il est possible de rendre hybrides plusieurs modles denregistreurs vido numriques par lajout dun logiciel. Enregistreur numrique rseau (NVR) : Conu pour les architectures rseaux IP de vidosurveillance, il ne peut traiter que les signaux vido provenant de camras IP ou dencodeurs. Logiciel de vidosurveillance IP : Solution purement logicielle de gestion de la vido sur un rseau IP. Dans le cas de systmes de surveillance comportant peu de camras, un navigateur Web peut suffire grer la vido. Pour de plus gros rseaux de vidosurveillance, 26
Chapitre 2
un logiciel ddi de gestion vido doit tre utilis. Celui-ci sinstalle sur un ordinateur personnel ou un serveur. Plus complexe installer, en raison des configurations ncessaires du serveur, il offre une plus grande flexibilit pour le choix et lajout de composantes au rseau de vidosurveillance. Les logiciels de vidosurveillance IP reprsentent une tendance forte en gestion vido, surtout dans les infrastructures comportant un grand nombre de camras. Les plateformes ouvertes permettent dintgrer facilement des camras et composantes matrielles de diffrents manufacturiers.
2.5
Archivage
La priode darchivage des squences vido varie selon les besoins de surveillance, allant de quelques jours quelques annes. En moyenne, les organisations conservent les preuves vido entre 30 et 90 jours. Le dploiement de vastes rseaux de camras et lutilisation de vidosurveillance haute rsolution fait exploser les demandes pour les systmes de stockage. Bien que le cot des supports denregistrement ait considrablement baiss dans les dernires annes, larchivage reprsente souvent une part importante des dpenses dinfrastructure en vidosurveillance, en raison de la quantit toujours croissante de donnes vido stocker. Les solutions de stockage sont de deux types : Interne : Les disques durs intgrs aux enregistreurs vido numriques ou aux serveurs reprsentent la forme darchivage la plus rpandue. Elle peut offrir jusqu quatre traoctets despace. Certaines camras IP disposent mme dune carte mmoire ou dun disque USB permettant denregistrer des heures, voir des jours de vido. Les solutions internes darchivage conviennent bien pour les systmes de vidosurveillance de taille modeste, comprenant jusqu 50 camras. Rattach : Larchivage se fait sur des appareils externes aux enregistreurs ou serveurs vido. De type NAS (Network Attached Storage) ou SAN (Storage Area Network), ces systmes offrent un espace de stockage partag entre les diffrents clients du rseau. Sur un systme de stockage en rseau NAS, un fichier est archiv sur un mme disque dur, alors quavec le rseau de stockage SAN, un fichier peut tre sauvegard en fragments rpartis sur plusieurs supports de stockage. Ces solutions darchivage rattaches sont particulirement avantageuses pour les grands rseaux de vidosurveillance comportant un grand nombre de camras. Bien que plus onreuses que les systmes internes darchivage, ces solutions rattaches sont suprieures en termes dextensibilit, de flexibilit et de redondance. 27
Chapitre 2
2.6
Affichage
Une grande partie de la vido capte par les camras de surveillance nest jamais regarde. Elle est simplement archive, au cas o un visionnement soit ncessaire suite un incident. Traditionnellement, la vidosurveillance a principalement servi comme outil denqute. Toutefois, dans plusieurs cas de surveillance, des agents de scurit visionnent, en temps rel, les images provenant des camras de surveillance. Sans ncessairement regarder toute la vido capte, les agents peuvent faire une revue priodique des diffrentes sources vido. La vido de surveillance peut tre visionne sur diffrents appareils. Dans de petites installations, il est possible de regarder la vido directement de lenregistreur, simultanment son enregistrement. Plus gnralement, les images seront regardes distance, sur un ordinateur ou, de faon mobile, sur un tlphone ou dispositif portable. Les grands centres doprations de scurit, supervisant des centaines de camras, utilisent souvent un mur dcrans vido. Ceux-ci offrent une grande surface de visionnement et permettent dafficher diffrents flux vido.
3 volution des systmes de vidosurveillance

La transition numrique en vidosurveillance sest opre en plusieurs tapes. Amorce avec lapparition de lenregistreur numrique, elle se poursuit vers une conversion totale linfrastructure IP, o la vido est transmise sur rseau intranet ou Internet de la camra lcran de visionnement. Dans ce passage, lon retrouve plusieurs systmes hybrides, intgrant composantes analogiques et numriques. La figure ci-dessous prsente les jalons importants qui ont marqu lvolution vers la vidosurveillance intelligente sur rseau IP.
Figure 5 : Evolution du matriel de vidosurveillance
28
Chapitre 2
3.1
Premire gnration : le tout analogique
Dans le rseau TVCF analogique traditionnel, des camras analogiques sont connectes par cbles coaxiaux (un cble par camra) aux crans de surveillance et, pour des fins darchivage, un magntoscope qui enregistre la vido sur cassette. Un multiplexeur peut tre utilis pour grouper les flux vido de plusieurs camras en un seul signal composite qui est transmis au magntoscope ou un moniteur analogique. Il permet dafficher quatre, neuf ou 16 signaux vido sur un mme cran, ou denregistrer ceux-ci sur un mme systme darchivage. Aucune compression nest effectue sur les signaux vido. Avec un magntoscope conu cet effet, lenregistrement taux de trame (frame rate) rduit permet dconomiser de lespace sur la bande vido, selon les besoins de surveillance. Avantages - Les systmes analogiques sont trs fiables - Simple utiliser, ils ne requirent pas de comptences informatiques. Inconvnients - La qualit de la vido est infrieure celle des systmes numriques. - Il faut changer les cassettes frquemment (aux trois jours ou plus). - Ncessite un nettoyage et un entretien rgulier des magntoscopes. - La qualit de la vido enregistre se dtriore avec le temps. - Ne permet pas le visionnement distance, comme sur les rseaux numriques. - Ce sont des systmes propritaires.
3.2
Deuxime gnration : systme hybride
Le remplacement du magntoscope cassette par un enregistreur numrique (DVR) reprsente la premire tape de la transition numrique en vidosurveillance. Apparus dans les annes 90, les enregistreurs numriques archivent la vido sur des disques durs. Comportant souvent plusieurs entres vido, lenregistreur numrique remplace la fois le multiplexeur et le magntoscope analogique. Les modles rcents sont quips dun port Ethernet, permettant la connexion un rseau et laccs distance la vido, soit en temps rel, soit partir de lenregistrement. Les transmissions vido se font sous protocole IP partir de lenregistreur 29
Chapitre 2
numrique. Ils permettent la transition vers un systme hybride de vidosurveillance sur rseau IP, tout en conservant les camras analogiques. Lenregistreur numrique hybride (HDVR), quant lui, peut recevoir la fois les flux vido de camras analogiques et IP. Il reprsente une solution efficace pour moderniser un systme de vidosurveillance en profitant des avantages des nouvelles camras IP, tout en conservant les camras analogiques existantes en place. Alors quon estime que 95 % des camras sont encore analogiques, les enregistreurs numriques et les enregistreurs numriques hybrides sont des technologies trs rpandues. Avantages - Aucune cassette changer. - La vido archive est de meilleure qualit, sans dtrioration avec le temps. - Possibilit de chercher rapidement dans les enregistrements vido. - Surveillance vido et opration du systme distance partir dun PC. Inconvnients : - Concentration des tches de numrisation, compression vido, enregistrement et rseautage dans la mme machine. - Lenregistreur numrique est un appareil propritaire, ce qui augmente les cots de maintenance et de mise jour. - Le nombre dentres vido de lenregistreur numrique (souvent un multiple de 16) contraint lajout de camras. Les encodeurs vido, aussi appels serveurs vido, sont utiliss pour convertir les signaux provenant de camras analogiques et les transmettre en flux IP sur un rseau via un commutateur. Tout en conservant les camras analogiques, ils permettent un passage presque complet linfrastructure rseau pour la vidosurveillance, puisque que la vido est constamment transmise sous le protocole IP travers le rseau. Les encodeurs vido peuvent tre utiliss avec lenregistreur vido rseau (NVR). Ceux-ci ne peuvent traiter et enregistrer que des flux vido IP. Ils sont offerts sous une plateforme ouverte (un ordinateur muni d'un logiciel de gestion vido) ou dans un matriel propritaire ddi. Sous cette dernire forme, lenregistreur vido rseau se compare un enregistreur numrique hybride, except quil ncessite lusage dencodeurs pour oprer avec des camras analogiques.
30
Chapitre 2 Avantages
- Utilisation dordinateurs et de matriel standards de rseau pour lenregistrement et la gestion de la vido. - Possibilit denregistrer lextrieur du site de surveillance (par exemple, centralisation des enregistrements). - Architecture distribue qui offre flexibilit, extensibilit (peut ajouter une camra la fois) et redondance (en cas de bris ou pannes). Inconvnients - Gourmand en bande passante, si lenregistrement est fait hors du site de surveillance (par ex., de faon centralise). - Si le rseau tombe en panne, lenregistrement peut tre interrompu. - Si lenregistrement centralis nest pas requis, lutilisation denregistreurs vido rseau est souvent plus coteuse que celle denregistreurs numriques. - Ncessitent des calculs complexes pour dterminer le nombre de flux vido pouvant tre supports par le serveur, la quantit despace disque ncessaire lenregistrement, le taux de trames, le niveau de compression et dautres facteurs lis aux capacits du rseau.
3.3
Troisime gnration : le tout numrique IP
Au sens strict, un systme de vidosurveillance est compltement IP, lorsque toutes ses composantes sont numriques et toutes les transmissions sont effectues sous le protocole IP. Ces rseaux comprennent donc des camras rseau, aussi appeles IP. Il sagit de camras intgrant leur propre encodeur. Celles-ci sont relies, via des commutateurs rseau, des serveurs (ordinateurs personnels), munis dun logiciel de gestion vido. Lenregistrement est fait sur serveur ou sur des enregistreurs vido rseau propritaires. Les traitements sont effectus sur le serveur ou dans les priphriques. Toutefois, beaucoup de gens considrent quun systme de vidosurveillance dont la vido est transmise sous protocole IP partir des encodeurs, constitue un systme rseau IP. Dans ces systmes, les camras peuvent tre analogiques, en autant quelles soient relies des encodeurs. Plus de dtails sur la vidosurveillance IP et, notamment ses avantages et inconvnients, sont fournis dans la section suivante. 31
Chapitre 2
4 Vidosurveillance IP
Depuis deux ans, le march de la vidosurveillance migre de la vido analogique la vido IP. Cet essor de la vidosurveillance rseau est favoris par le perfectionnement des processeurs, la baisse des cots de stockage et lamlioration des algorithmes de compression. Bien que cette transition sobserve, elle ne fait que dbuter et il est difficile de prdire quel rythme le tout IP prendra le dessus sur les technologies analogiques en vidosurveillance. Les camras constituent le facteur de rsistance. En effet, il est estim que 95 % des 40 millions de camras installes travers le monde sont encore analogiques. De plus, encore aujourdhui, seulement un acheteur sur quatre choisit des camras IP. Pourtant, les camras IP offrent des avantages techniques sur les camras analogiques, tels quune meilleure qualit dimage, une rsolution plus leve et de lintelligence embarque. Le cot lev des camras IP, environ le double des camras analogiques, reste le principal frein lachat. Avec les amliorations apportes par les manufacturiers aux enregistreurs vido et lexistence denregistreurs vido hybrides, le rgne des camras analogiques pourrait se prolonger encore quelques annes. Les rseaux IP de vidosurveillance de dernire gnration prsentent les caractristiques suivantes : Ils sont numriques de A Z : camras, rseaux, enregistrement, accs. Ils peuvent inclure diffrents types de camras : intelligente, mgapixel, sans fil, PTZ, panoramiques, etc. Ils utilisent du matriel non propritaire. Ils fonctionnent avec des serveurs distribus et multiplateformes. La sauvegarde se fait sur rseau (NVR). On peut y accder distance, nimporte o, nimporte quand, soit dun centre de contrle, via Internet ou un rseau LAN ou WAN, sur un cellulaire ou un assistant numrique personnel, etc. Ils peuvent inclure de lanalytique vido.
La vidosurveillance sur rseau IP offre de nombreux avantages. Elle repose sur une infrastructure plus souple que la vido analogique, combinant transmission cble et sans fil. De plus, linfrastructure rseau est rapide et facilement extensible. Il ny a pas de limite au nombre de camras qui peuvent sy ajouter. Considrant que les systmes actuels peuvent 32
Chapitre 2
facilement comporter entre 400 et 500 camras, comparativement 25 30 il y a quatre ans, cette facilit dtendre le rseau de vidosurveillance est trs attrayante lorsquon pense dployer un nouveau systme. Pour les installations tendues comportant de grandes distances entre les camras et les systmes denregistrement, les camras IP deviennent un choix avantageux, car le cot du cble coaxial est trs lev. Cest pourquoi les camras IP sont surtout dployes pour la surveillance dinstitutions, telles que les tablissements scolaires, les campus de grandes entreprises, les municipalits et les bases militaires. Les camras IP apportent de nombreux bnfices techniques. Par exemple, les camras mgapixel IP offrent des avantages indniables au niveau de la vidosurveillance. Ces camras, prsentant une rsolution nettement suprieure celle des camras analogiques, ont le potentiel de rsoudre plus de crimes. Bien que son cot soit lev, une seule camra mgapixel peut souvent remplacer plusieurs camras. Les camras intelligentes, intgrant des processeurs, apportent des gains techniques aux systmes de vidosurveillance de nouvelle gnration. Elles permettent de distribuer les calculs pour les traitements danalytique vido et, ainsi, de mnager la bande passante en ne transmettant que les donnes pertinentes pour la scurit. Larchitecture ouverte des rseaux de vidosurveillance IP permet de combiner le matriel de diffrents manufacturiers. Il est ainsi possible de slectionner les composantes les plus adaptes son application de surveillance. De plus, larchitecture IP facilite lintgration de diffrents systmes de scurit (vido, alarmes de feux, contrle daccs, etc.). La configuration de ces rseaux avec redondance, tant au niveau de la transmission que de larchivage, assure une meilleure fiabilit. Dans un rseau entirement analogique, le mauvais fonctionnement dune camra ou dun enregistreur peut signifier une perte dfinitive de vido. De plus, larchivage sur rseau, dont les cots ne cessent de baisser, permet de conserver des annes de vido plutt que quelques jours ou semaines avec les magntoscopes ou enregistreurs numriques. Il suffit dajouter des disques durs pour augmenter la capacit de stockage. Dans ces rseaux, la transmission numrique de la vido, de bout en bout du systme, rduit les pertes de qualit quoccasionnent les conversions danalogique numrique. De plus, par des traitements logiciels intelligents, il est possible de filtrer les vnements pertinents dans la vido et de ne transmettre que les mtadonnes les dcrivant. Ceci permet dconomiser de la bande passante. Ces mtadonnes servent ensuite indexer le contenu vido pour permettre des recherches plus performantes dans les squences captes. Il est aussi possible, dans ces rseaux, de transmettre des commandes aux camras, en fonction de la vido traite. Par exemple, en rponse un vnement suspect, le logiciel de gestion vido pourra activer automatiquement le zoom optique ou numrique sur une camra du 33
Chapitre 2
rseau pour un suivi plus prcis de la situation. Le passage la vidosurveillance IP comporte tout de mme certains inconvnients. Par exemple, dans le cas dinfrastructures analogiques existantes, refaire tout le filage rseau peut reprsenter un cot lev. Dans ce cas, lutilisation dencodeurs pour numriser les signaux analogiques permet de conserver les camras en place et dimplanter un rseau hybride. De plus, la technologie des enregistreurs numriques a beaucoup progress, afin de rester comptitive. Les enregistreurs numriques offrent dsormais plusieurs avantages comparables aux technologies sur rseaux IP : accs distance, capacit de grer un grand nombre de camras, intgration avec les autres systmes (contrle daccs, dtection dintrusion, systmes de points de vente, etc.), capacit analytique. Pour de petites installations de vidosurveillance, lutilisation de camras analogiques avec enregistreurs numriques offre donc un excellent rendement, des cots moindres que la vido IP. Bien que sur le plan technologique, les rseaux IP de vidosurveillance offrent de nombreux avantages, le dploiement de ceux-ci pose certains problmes organisationnels. Le premier rside dans linstallation. La plupart des intgrateurs et installateurs en vidosurveillance sont issus du secteur de la scurit physique. Or, linstallation de systmes de vidosurveillance sur rseau IP requiert des comptences en technologie de linformation, particulirement en rseautique. Encore peu dintgrateurs et installateurs de
vidosurveillance sont spcialiss dans ce domaine. Le second problme touche la gestion de ces systmes. Une fois installs, qui, dans lorganisation, est responsable du systme de vidosurveillance : le personnel de scurit physique ou les services informatiques ? Le flou qui existe encore sur cette question dans les organisations retarde bien souvent le passage la vidosurveillance IP. Finalement, passer dun rseau de tlvision en circuit ferm un systme de vidosurveillance, dont les donnes transitent par les rseaux Ethernet ou Internet, soulve les questions de scurit informatique. videmment, ceci ncessite de mettre en place les mcanismes de scurit adquats pour protger la vido de surveillance. Aussi, le bon fonctionnement de la vidosurveillance devient tributaire de la fiabilit du rseau. cet gard, l'intgration de la vidosurveillance sur rseaux IP suivra peut-tre celle de la tlphonie IP, qui est maintenant bien rpandue.
34
Chapitre 2
5 Architecture intelligente
dun
rseau
de
vidosurveillance
Les systmes de vidosurveillance intelligente peuvent tre dploys selon deux grands types darchitecture, soit centralise ou distribue. Lune comme lautre oprent des traitements intelligents pour extraire des donnes sur les images vido et peuvent, au besoin, commander le dplacement dune camra PTZ pour oprer une surveillance active.
5.1
Architecture centralise
Dans une architecture centralise, tous les traitements intelligents sont concentrs en un mme endroit. Dans les systmes traditionnels, cest lenregistreur numrique qui rcoltera tous les flux vido pour en faire lanalyse. Pour les infrastructures en rseau, cest un serveur informatique (un PC) qui oprera les traitements analytiques. Lanalyse vido ncessite une grande puissance de calcul qui monopolise une part importante des ressources du processeur. Comme ils doivent aussi grer lencodage, lenregistrement et le visionnement des flux vido, les enregistreurs numriques et serveurs ne peuvent accomplir des tches danalytique vido que sur un nombre restreint de camras. De plus, dans le cas des systmes de vidosurveillance sur rseau, la transmission de tous les flux vido en un point centralis consomme beaucoup de bande passante. Le rseau informatique doit pouvoir soutenir ce trafic.
5.2
Architecture distribue
Comme son nom lindique, larchitecture distribue rpartit les traitements intelligents dans les diffrents nuds du systme de vidosurveillance. Ainsi, les calculs ncessaires lanalytique pourront tre faits en priphrie, sur des camras intelligentes dotes de processeurs, les encodeurs ou dans les commutateurs rseau. Dans cette architecture, plutt que denvoyer des flux vido lenregistreur numrique ou un ordinateur central, seules des mtadonnes extraites sur la vido sont transmises. Lintelligence peut aussi tre partage entre les priphriques et lunit centrale de traitement. Cette infrastructure aide diminuer les cots de cblage et la bande passante requise dans un rseau de vidosurveillance. De plus, elle offre une meilleure extensibilit, puisque lajout de camras nest pas ncessairement limit par la puissance de calcul de lenregistreur numrique ou du serveur. 35
Chapitre 2
Conclusion
Ce chapitre a prsent le sujet et les contraintes qui se posent. Nous tudions dans ce qui suit laspect thorique de compression vido quest une composante importante dun systme de vidosurveillance dans le but dapporter des solutions thoriques qui se prtent bien une implmentation pratique.
36
Chapitre 3
Compression vido
La reprsentation dune squence vido La compression de donnes Codage vido par estimation et compensation de mouvements Les images de rfrence Les normes de compression existantes
Rsum Dans ce troisime chapitre nous abordons laxe principal de notre service qui est la compression vido. Le traitement de la vido passe par des tapes justifies soit par les dfauts de lorgane humains relatifs ou par les proprits statistiques de limage pour cela nous allons dvelopper dans ce chapitre les normes de compression vido existantes.
Chapitre 3
Compression vido
1 La reprsentation dune squence vido

Une squence vido brute est une suite d'images fixes, qui peut tre caractrise par trois principaux paramtres : sa rsolution en luminance, sa rsolution spatiale et sa rsolution temporelle. La rsolution en luminance dtermine le nombre de nuances ou de couleurs possibles pour un pixel. Celle-ci est gnralement de 8 bits pour les niveaux de gris et de 24 bits pour les squences en couleurs. La rsolution spatiale, quant elle, dfinit le nombre de lignes et de colonnes de la matrice de pixels. Enfin, la rsolution temporelle est le nombre d'images par seconde. La valeur de ces trois paramtres dtermine l'espace mmoire ncessaire pour stocker chaque image de la squence. Cet espace mmoire est caractrise par le dbit, qui est le cot de stockage pour une seconde (capacit mmoire ncessaire pour stocker une seconde de vido). Par exemple, une squence ayant une rsolution de 720 par 576 pixels, un codage des couleurs sur 24 bits, et une frquence de 25 images par seconde, ncessitera un dbit de 137 Mb/s (mgabits par seconde). Le dbit d'une squence vido brute est trs leve compare aux dbits et l'espace offerts par les moyens de stockage et de transferts actuels.
1.1
Le format YUV 4 :1 :1
Dans un premier temps, une solution pour rduire ce dbit est de sous-chantillonner les composantes de chrominance de la squence. L'il humain tant plus sensible aux variations de luminance que de chrominance, on utilise l'espace de reprsentation de couleurs YUV, en sous-chantillonnant les composantes U et V. Historiquement et techniquement, le format YUV est utilis pour la transmission des signaux vido analogiques couleurs. Dans ce sigle, Y reprsente la luminance, U et V les composantes Rouge et Bleu (chrominances). Ces 3 informations permettent de restituer au final les composantes RGB et apporte l'avantage de permettre une compression facile des couleurs et de fiabiliser le transport du signal vido. Mais surtout la partie Y (luminescence) permet une parfaite compatibilit avec les anciens quipements en noir et blanc, ce qui a permis le dploiement de la diffusion couleur alors que la totalit des foyers taient alors quipes de tlviseurs noir et blanc. Dans le format YUV 4 :1 :1, les composantes de chrominance sont rduits la moiti de la rsolution verticale et horizontale de la composante de luminance, soit 4 composantes de chrominance pour une composante U, et une composante V (voir Figure 6).
38
Chapitre 3
Compression vido
Figure 6 : Le format YUV 4 :1 :1
Ce sous-chantillonnage correspond une rduction de la redondance psycho-visuelle. Dans la suite, nous tudierons les techniques permettant de rduire les redondances spatiales et temporelles.
2 La compression de donnes
Dans cette section nous allons nous intresser aux techniques utilises pour compresser le signal vido en utilisant la redondance spatiale. Le but est de rduire le dbit de la squence vido compresser, tout en minimisant les erreurs visibles. La compression de donnes permet de rduire la quantit d'information, en modifiant son mode de reprsentation. Pour cela, il existe deux principales techniques, la compression sans pertes et la compression avec pertes.
Figure 7 : Introduction des pertes dans le processus de compression
La premire permet de retrouver l'information initiale aprs dcompression, tandis que la deuxime n'en restituera qu'une approximation. Dans le cas de la compression d'images naturelles (par opposition aux images de synthse), la compression sans pertes est insuffisante, et l'introduction de pertes dans le processus de compression permet d'obtenir de meilleurs rsultats sans empcher l'interprtation du contenu visuel (voir Figure 7). 39
Chapitre 3
Compression vido
Les normes vido actuelles utilisent un systme de codage hybride avec compensation du mouvement bas sur des blocs et rduction de l'entropie par transforme (voir Figure 8), que nous allons tudier maintenant.
2.1
La rduction de lentropie
L'entropie (H(X)) d'une image est la quantit moyenne d'informations apporte par chaque nouveau pixel transmis, ou encore, l'incertitude moyenne sur le prochain pixel qui va tre trait.
L'entropie sera maximale si la source obit une loi uniforme, alors qu'elle sera plus faible si la distribution est concentre autour de quelques valeurs seulement. Le but de la rduction de l'entropie est par consquent de transformer la distribution des valeurs de l'information transmettre.
Figure 8 : schma gnral dun codeur vido
40
Chapitre 3
Compression vido
La rduction de l'entropie est composte de trois tapes, tel que la dcorrlation, la quantification, et le codage entropique. La dcorrlation est opre par un codage par transforme. Parmi les transformations utilises pour la compression d'images, on peut citer la transformation de Kahrunen-Love (KLT), la transforme en cosinus discrte (DCT) et les transformes en ondelettes discrtes (DWT). La KLT est la transforme optimale, mais comporte l'inconvnient d'tre dpendante des donnes, puisque compose des vecteurs propres de la matrice de covariance de l'image. Cette dpendance induit un cot de calcul lev, que ne prsentent pas les deux autres transformes. Dans le cas des images naturelles, les pixels voisins prsentent une forte corrlation, de ce fait, les capacits de la DCT sont trs proches de celle de la KLT tout en rduisant la complexit de calcul. La DWT a l'avantage de produire une matrice contenant beaucoup de zros, ce qui a la proprit d'allger les calculs lors d'oprations matricielles. Elle peut donc tre applique l'image entire, contrairement la DCT qui est applique par blocs pour limiter les calculs. L'application d'une transforme sur une image naturelle permet d'obtenir des composantes dont la variance est concentre sur les composantes de basses frquences. L'image ainsi transforme est ensuite quantifie puis compresse l'aide d'un codeur entropique.
3 Codage vido par estimation et compensation de mouvements

La technique que nous allons maintenant tudier permet d'exploiter les redondances temporelles, fortement prsentes dans une squence vido naturelle. La compression par compensation de mouvement consiste pour une image, ne coder que les erreurs rsultantes de l'estimation de mouvement faite partir d'une image de rfrence. L'estimation de mouvement est faite par mise en correspondance de blocs des images (ou bloc matching), afin d'obtenir les vecteurs de mouvement correspondant. Cette estimation n'est qu'une approximation, car la mise en correspondance n'est pas complte. Les erreurs rsiduelles, qui consistent en la diffrence entre l'image prdite et l'image compense, sont donc ajoutes aux vecteurs de mouvement. Cette compensation et ces erreurs sont ensuite transformes, quantifies et codes, avant d'tre transmises. En plus d'tre codes et transmises, elles subissent galement une quantification inverse et une transformation inverse. Le but de dcoder les images l'intrieur du processus d'encodage, est d'effectuer les prdictions partir des images dcodes, afin de travailler avec les mmes informations que le dcodeur cible.
41
Chapitre 3
Compression vido
3.1
La structuration du flux vido
Ce codage prdictif rend les images interdpendantes, puisque lors du dcodage, il est ncessaire d'avoir l'image prcdente pour dcoder l'image en cours. Cette dpendance est gnante si l'on souhaite naviguer de manire alatoire, le dcodage de tout le dbut de la squence tant ncessaire, ou si une image est perdue lors d'un transfert, le dcodage du reste de la squence tant impossible. C'est pourquoi le processus de compression comprend deux modes : le mode intra et le mode inter. Le mode intra correspond une compression spatiale sans compensation de mouvement (transforme, quantification et codage), tandis que le mode inter utilise la compression temporelle. Les commutateurs prsents dans la Figure 2.3 page cicontre reprsentent le choix du mode de codage. Les images sont regroupes en GOP (Group Of Pictures) composes de trois types d'image. Les images I sont codes en mode intra, et sont donc indpendantes mais demandent plus de ressources. Les images P sont codes par compensation de mouvement partir de la dernire image I ou P . Les images B sont prdites bi directionnellement partir d'images I ou P . Un GOP dbute toujours par une image I , qui constitue l'image-cl du GOP. Cette image, est ensuite suivie d'image P , intercales par des images de type B (voir Figure 2.4). La frquence des images de type P , et la taille du GOP sont des paramtres qui influeront sur le taux de compression, et sur le temps de dcodage. En effet, plus le GOP sera long, et plus la dpendance entre les images sera forte, mais moins il y aura d'images I qui freine sensiblement le taux de compression. L'introduction des images induit un dlai de dcodage additionnel, puisque les images P postrieures doivent tre dcodes avant que les images B antrieures puissent tre dcodes.
Figure 9 : Exemple dagencement dun GOP
Le choix du mode de codage peut tre fait sur les images entires (dtermin par la structure de GOP utilis) ou sur des blocs d'images. En effet, lors du codage d'un bloc d'une image, le 42
Chapitre 3
Compression vido
processus de compensation de mouvement peut s'avrer inefficace, dans ce cas, le bloc est cod en utilisant le mode inter.
3.2
Apprciation des erreurs de compression
La quantification est l'opration qui introduit les pertes. Ces pertes sont mesures par l'erreur quadratique moyenne (EQM) qui est calcule partir de l'image originale et de l'image reconstruite.
De cette EQM, on drive une autre grandeur, plus significative, appele peak signal to noise ratio (PSNR). Cette grandeur est un gain qui s'exprime en dcibels, et s'obtient ainsi :
Cette mesure de la distorsion couple avec le dbit de la squence rsultante permet d'apprcier le compromis entre le gain de la compression et la qualit de restitution. Ce compromis est visible sur la courbe de la Figure 10. Le but tant, en gnral, d'obtenir la meilleure fidlit (ou la plus grande distorsion) compte tenu de la capacit du canal de transmission, qui dtermine la contrainte de dbit. Cette optimisation peut tre faite l'aide des techniques de minimisation de Lagrange fondes sur la thorie du dbit-distorsion
Figure 10 : Allure typique dune courbe du rapport dbit / distorsion
43
Chapitre 3
Compression vido
4 Les images de rfrence

On appelle image de rfrence, l'image qui va tre utilise pour prdire une image et estimer le mouvement compenser. Cette image peut tre simplement une image prcdemment code dans la squence. Dans les dernires normes, de nouvelles images sont utilises : les objets mosaques. Un objet mosaque contient l'ensemble de l'information disponible sur un objet physique donn. Il est souvent utilis sous la forme d'objet mosaque plan (voir Figure 11 ) appel MOP (Mosaic Object Plane) qui est construit partir d'une squence de vues de l'objet considr. Le principe de construction consiste recaler les images (ou portions d'images) traites dans le rfrentiel de l'objet mosaque . Ces images peuvent tre utilises pour reprsenter sur une seule image la totalit d'une scne. Cette mosaque est gnralement plus grande qu'une image de la squence.
Figure 11 : Exemple dimage mosaque construite partir dun ensemble dimages
Le standard MPEG-4 a ajout le mode de codage sprite aux modes intra et inter, pour construire de tels objets. En revanche, rien n'est spcifi dans ce standard en ce qui concerne le processus de construction.
5 Les normes de compression excitantes

Les codeurs vido actuellement normaliss (familles H.26x ou MPEG-x) utilisent tous le mme principe de base dont la connaissance aide comprendre la fois leurs potentialits et limites dutilisation. Cette section dcrit les principaux standards normaliss lUIT-T et lISO/IEC. 44
Chapitre 3
Compression vido
5.1
Les normes de lUIT-T
Premire norme vido approuve en 1993, H.261 vise les applications de visiophonie pour le rseau RNIS des dbits multiples de 64 kbit/s. Les formats d'image traits sont le QCIF (144x176 pixels) et le CIF (288x352 pixels). La frquence image de base est 29.97 Hz mais peut tre rduite (sous-multiples). Le schma de codage (Figure 12) est constitu de plusieurs modules : lestimation et la compensation de mouvement, le calcul des rsidus, la transforme espace-frquence (DCT), la quantification et le codage entropique. Le codeur intgre galement un dcodeur qui effectue les oprations inverses. Pour la compensation de mouvement chaque MB peut tre affect d'un vecteur de mouvement dont les dimensions horizontales et verticales ne peuvent excder +/- 15 pixels. Le vecteur de mouvement estim sur la luminance pointe un MB inclus dans l'image prcdemment reconstruite. Les chrominances sont prdites par le mme vecteur mouvement dont les coordonnes ont t divises par 2 et arrondies l'entier le plus proche. Cette prdiction correspond la construction d'une image P. Le filtrage, optionnel, est un filtre spatial deux dimensions non rcursif travaillant au niveau pixel sur des blocs de taille 8x8 intervenants dans la boucle de codage. Le flux vido est structur en quatre niveaux : image, groupe de blocs (GOB), macrobloc (MB) et enfin bloc.
45
Chapitre 3
Compression vido
Figure 12 : Schma de codage H.261
H.263 est une norme de codage vido pour la communication vido trs bas dbit dont la premire version fut adopte en 1995. Elle vise les applications de visiophonie et de visioconfrence sur RTC et RNIS. Cette norme repose sur les principes mis en place par la recommandation H.261. Les formats dimages sont des multiples et sous-multiples du CIF (352x288 pixels). Le codeur H.263 a la possibilit d'effectuer des compensations en mouvement avec une prcision au demi-pixel, ce qui amliore grandement la qualit de la vido en rduisant fortement les effets dits "moustiques". L'utilisation d'image B est dsormais possible. La version 2 de la recommandation H.263 (1998), souvent appele H.263+, met en uvre douze options supplmentaires et permet dsormais de dfinir des formats et frquences d'image personnaliss. Les caractristiques de vido (Taille frquence) sont transmises dans le flux vido. Les options ajoutes amliorent fortement la qualit et la robustesse aux erreurs. La dernire version de H.263 (2000), appele H.263++, ajoute trois 46
Chapitre 3
Compression vido
options et une spcification la version antrieure. Outre l'amlioration en termes de qualit et de taux de compression, elle prend mieux en compte la transmission vido temps rel sur des rseaux qualit de service non garantie (IP et mobiles).
5.1
Les normes de lISO-IEC
Premire norme de compression vido dveloppe par lISO/IEC, MPEG-1 vise une qualit quivalente au VHS (format SIF ou CIF) un dbit de 1,5 Mbps. Cette norme a t construite sur la base de H.261 dont elle reprend les principes en les amliorant : compensation de mouvement au 12 pixel, images de types I (Intra), P (Prdite) ou B (Bidirectionnelle), quantification optimise par lutilisation de matrices de quantification, prdiction spatiale du coefficient DC pour les images I.MPEG-1 nest plus gure utilise aujourdhui si ce nest en compression du son avec le format MP3 pour le stockage de la musique La norme MPEG-2 a t dfinie pour les applications lies la TV numrique, la fois au niveau professionnel (production audiovisuelle, etc.) et au niveau du grand public (diffusion vers les postes TV). Elle reprend les principes de MPEG-1 en ajoutant les outils indispensables pour les applications tlvisuelles : traitement des formats entrelacs, optimisation des outils MPEG-1 (dynamique des vecteurs mouvements, etc.), scalabilit visant la compatibilit TV/TVHD. Ce standard a t adopt par le consortium DVB (Digital Video Broadcasting) pour les services de TV numrique par voie hertzienne terrestre (DVB-T) et satellite (DVB-S). Il est galement utilis comme format de codage du DVD (Digital Vido Disc). MPEG-4 est une norme gnrique de compression destine la manipulation dobjets multimdia. Elle permet le codage dune grande varit de format vido (taille, rsolution, frquence image) mais aussi le codage dobjets vido de forme arbitraire, dimages fixes (codage par ondelettes) ainsi que dobjets synthtiques 3D. De ce fait, cette norme adresse une large gamme dapplications audiovisuelles allant de la visioconfrence la production audiovisuelle en passant par le streaming sur Internet ou encore la ralit virtuelle distribue. Concernant le codage de la vido traditionnelle, MPEG-4 combine les outils de MPEG-2 et H.263 ainsi que de nouveaux outils lui confrant une plus grande efficacit en compression tels que des modes de scalabilit plus adapts une transmission sur rseaux dbit fluctuant ainsi quune plus grande robustesse aux erreurs de transmission.
47
Chapitre 3
Compression vido
Conclusion
Le MPEG4 apporte une solution efficace pour lencodage vido. Ses algorithmes sont relativement volues, et promettent une qualit leve dbit bien plus bas que le MPEG2. Le MPEG4 utilise galement un systme de licence beaucoup plus facile, le rendant plus attractif lutilisation. Son utilisation commence faire son apparition un peu partout et le MPEG4 est devenu assez clbre au public au travers des codecs dit DivX.
48
Chapitre 4
Lapproche Streaming
Notions sur la transmission des mdias Les mthodes de streaming Le protocole RTSP
Rsum Dans ce chapitre, nous prsenterons tout dabord des notions sur la transmission des medias et aprs on verra les mthodes de streaming existantes. Ensuite, nous aborderons brivement un protocole ddie au streaming, savoir le RTSP.
Chapitre 4
Lapproche Streaming
1 Notions sur la transmission des mdias

1.1 La transmission multipoint
Le mode multipoint ou multicast consiste transmettre sur le rseau, des paquets de donnes dune source vers plusieurs destinataires reprsents par une adresse unique. Au lieu dtre rpts par la source, les paquets sont dupliqus par les noeuds intermdiaires de routage. En utilisant le protocole IP standard, chaque serveur devrait rpter le flot de paquets vers autant de destinataires quen comporte la liste de diffusion. Lenvoie dune information vers n destinataires, oblige dupliquer n fois le flux de paquets. La consommation de ressources est trs importante en temps machine, pour les routeurs et les branches du rseau.
Figure 13 : Transmission unipoint dun flux
En utilisant le multicast, la transmission dune information vers n destinataires ne requiert plus que lmission dun seul flux de paquets par la source. Chaque paquet, emporte la liste des adresses de tous les correspondants, sous une adresse unique multipoint. Les routeurs et les nuds intermdiaires assurent la rplication des paquets aux intersections. Ainsi, sur un segment, ne voyage quune seule copie dun mme paquet. La bande passante globale utilise est considrablement rduite.
Figure 14 : Transmission multipoint dun flux
50
Chapitre 4
Lapproche Streaming
Les applications multipoints seront difficiles mettre en uvre en mode connect. Supposons que lon veuille mettre un mme fichier vers 100 destinataires, il faudra alors ouvrir 100 connexions et en dfinir chaque interlocuteur ses paramtres. Dautres part, dans le cas dun rseau en toile, le multipoint napporte pas damliorations.
1.2 RTP : Le Protocole temps rel

Le transport de paquets dans un rseau non dterministe ne garantit pas les dlais. Le rcepteur doit donc pralablement restaurer la synchronisation du flux. Les enttes IP, UDP ou mme TCP ne datent pas les paquets, ils ne fournissent pas lhorodatage qui faciliterait la remise en forme temporelle du flux : les paquets retardataires ne seront pas limins. Pour cette raison, le groupe de travail Audio Vido Transport (AVT-WG) a t charg au sein de lIETF de dvelopper un protocole qui faciliterait le transport des donnes temps rel. Ctait alors RTP. Real time Transport Protocol est un protocole de transport adapt aux applications prsentant un caractre temps rel. Il est indpendant du protocole transport sous-jacent. RTP fournit des informations trs utiles au transport des contenus. Il assure lhorodatage des paquets en imposant une estampille de temps, qui indique lheure de leur cration. La remise en ordre des paquets se trouve ainsi simplifi.
1.3
RTCP : Le Protocole de contrle
Une transmission temps rel, a pour stratgie dabandonner les paquets perdus, pour prserver la continuit du service, ainsi, elle ne peut tre fiable. Il faut donc mettre en place un change de rapport de rception, par lesquels les destinations informent la source du niveau de qualit de service constate. Ils permettent lmetteur de connatre lefficacit de la transmission. Cest le rle du Real time Transport Control Protocol , RTCP.
51
Chapitre 4
Lapproche Streaming
Figure 15 : Paquets RTP et RTCP
RTCP fournit un retour dinformation sur la qualit de rception des donnes transmises dans les paquets RTP. Cette information peut tre immdiatement utilise par la source, pour adapter le type de codage. Ces fonctions de compte rendu sont effectues grce aux rapport mis par un rcepteur et reus par une source.
1.4 RSVP : Rservation des ressources

Les congestions sont la cause principale des pertes dinformation et des retards dacheminement. Les protocoles RTP et RTCP ne sattaquent pas directement aux pertes de paquets et nvitent pas les congestions. Ils se contentent dassister lmetteur et le destinataire dans leur activit dchange de contenu. Cest la couche application aux extrmits de sadapter la situation. Une solution envisage consiste incorporer dans les routeurs intermdiaires une stratgie dynamique de rgulation des flux. Le Resource reSerVation Protocol , RSVP a t alors introduit. RSVP achemine la rservation de bande passante le long d'un chemin de donnes, prdtermin par le protocole de routage rseau. En effet, lorsquune application demande un niveau de qualit de service, elle transmet une requte RSVP au nud de rattachement. Celui-ci distribue la requte tous les nuds intermdiaires traverss par les paquets depuis la source mettrice. Les paquets RSVP voyagent donc contre courant, du rcepteur vers lmetteur. La figure 16 illustre le fonctionnement du protocole.
52
Chapitre 4
Lapproche Streaming
Figure 16 : Principe du RSVP
Certaines demandes de qualit de service peuvent tre incompatibles avec les ressources dun des nuds de la chane, dans ce cas RSVP renvoie un message derreur lapplication.
2 Les mthodes de streaming

Au fur et mesure du dveloppement des mdias temps rel, deux mthodes pour acheminer le contenu se sont dveloppes : Dans la premire, un serveur Web standard est utilis pour fournir les donnes au client. Dans la deuxime, on utilise un serveur spcifique ddi au temps rel.
2.1
Le temps rel sur un serveur web
Cette approche nest en fait quune volution du modle Download and play classique. Les sources vido et audio sont dabord compresss dans un fichier, grce un algorithme tenant compte des contraintes du temps rel, des limitations de la bande passante. Ces fichiers sont placs sur un serveur Web standard o se trouve galement le fichier HTML y faisant rfrence. Lorsque le lien est activ, il dclenche le lecteur du ct du client. Jusque l, rien ne diffre du tlchargement classique. Les diffrences sont dans les fonctionnalits du lecteur. A loppos du mode Download and play , Le client commence jouer aprs seulement quelques secondes de tlchargement, temps ncessaire la bufferrisation des premires donnes. Cette mthode sappuie donc sur HTTP, protocole qui utilise les services de TCP pour le transport de donnes. Optimis pour les applications ne ncessitent pas de temps rel (transfert de fichiers par exemple), le but de TCP est dassurer le transport des donnes dun bout lautre sans pertes de paquets tout en restant efficace du point de vue dbit. Pour y arriver, TCP utilise lalgorithme dit de slow start , prsent au premier chapitre. TCP finalise ce travail de fiabilit en rmettant les paquets perdus. De ce fait il ne peut assurer, que tous les paquets rmis arrivent temps, pour tre jous par le lecteur temps rel. Cependant cette mthode a un avantage. Elle utilise les infrastructures existantes, puisquun 53
Chapitre 4
Lapproche Streaming
serveur Web est forcement dj prsent pour le transfert des fichiers HTML, aucun nouveau matriel ou logiciel na besoin dtre install et gr. Il est important noter que la charge supplmentaire impose aux serveurs HTTP, crera, si la demande en flux temps rel est forte, un besoin de nouvelles ressources pour rpondre de nombreuses demandes de flux audio et vido. Ainsi, le choix de cette solution sur de simples critres de cots matriels, nest pas forcement judicieux.
2.2
Le temps rel sur un serveur ddi
Dans cette approche, les premires tapes sont similaires lapproche Web. La diffrence rside dans le fait que les fichiers compresss sont placs sur un serveur ddi au temps rel. Les pages HTML qui y font rfrence sont toujours placs sur le serveur HTTP. Les donnes sont envoyes au client de faon dite intelligente , dans la mesure o le serveur peut rajuster le dbit en fonction de ltat du rseau. Le serveur et le client restent en troite collaboration durant le processus. Bien que ces serveurs puissent utiliser les protocoles HTTP et TCP, ils peuvent surtout choisir le protocole RTSP qui utilise UDP, dans la plupart du temps. A la diffrence de TCP, UDP est un protocole rapide et lger : il ne rmet pas les paquets perdus et il nintgre pas de fonctions de gestion de flux et de congestion. Cela, en fait un protocole idal pour les flux temps rels ou lordre des informations reues est plus important que la perte des paquets. Lutilisation dun serveur ddi prsente plusieurs avantages : Meilleure utilisation des capacits du rseau : le protocole UDP utilisera mieux la bande passante que TCP, en supposant un mme niveau de congestion sur le rseau. Meilleure qualit pour lutilisateur : en cas de congestion, le serveur peut dcider de rduire la qualit de linformation transmise afin de se contenter de la bande passante disponible. Dans le cas du systme bas sur serveur Web, o aucun retour dinformation du poste client nest possible, la rgulation du dbit nest pas possible. En cas de congestion la lecture cessera pour un temps qui sera ncessaire pour la bufferisation . Plus de fonctionnalits : la technique permet lutilisation de fonctions avances, typiquement celles dun magntoscope (avance rapide, pause et retour). Ces fonctions, si elles sont ralisables dans lapproche HTTP, sont difficiles implmenter. Protection des copyrights : les serveurs ddis peuvent interdire la copie des fichiers envoys sur le cache du client. 54
Chapitre 4
Lapproche Streaming
Mode de livraison multiple : les serveurs ddis supportent diffrentes configurations de protocoles. Ils sont capables de passer dun protocole a lautre sans intervention du rcepteur. Le serveur essaiera dabord de transmettre en utilisant le protocole optimal : UDP. Mais puisque beaucoup dadministrateur rseau ferment le trafic au firewall UDP, le serveur tentera de transmettre via TCP brut ou via TCP + HTTP. Aux termes de cette comparaison entre les serveurs Web et les serveurs ddis, au niveau du streaming, il est clair que lutilisation de la deuxime catgorie sera plus bnfique.
3 Le protocole RTSP
RTSP, Real Time Streaming Protocol, est un protocole de la couche application, qui est bas sur le modle client-serveur. Il a t conu pour transmettre et contrler un ou plusieurs flux synchroniss dobjets mdia, sur un rseau IP. Il a t dvelopp par RealNetworks, Netscape Communications et Columbia University avec la contribution de lIETF qui la publi comme standard en avril 1998. Cette section prsentera brivement quelques proprits de RTSP.
3.1
RTSP et HTTP
RTSP ressemble HTTP 1.1 au niveau de la syntaxe et des oprations. Cependant certains aspects, diffrencient RTSP du HTTP. Parmi ces diffrences : RTSP dispose dun certain nombre de nouvelles mthodes. De plus il a un identificateur de protocole diffrent. RTSP est un protocole avec tat, contrairement HTTP. En fait, il maintient linformation sur la session en cours, jusqu ce que celle-ci soit explicitement interrompue par le client. Le serveur et le client peuvent tous les deux, lancer des requtes. RTSP peut utiliser dautres protocoles, tels que RTP et RDT (Real Data Transport), pour transporter les donnes.
3.2
Les formats de paquets de donnes
En gnral, un serveur de RTSP peut utiliser n'importe quel type de format de paquet pour envoyer des donnes mdias un client. Principalement, deux protocoles sont utiliss ce propos, RTP et RDT. RTSP permet galement de surveiller la qualit de la transmission travers RTCP. Pour cela le client met priodiquement destination du serveur des rapports sur la qualit de la transmission, contenant le pourcentage et le nombre de paquets perdus, le 55
Chapitre 4
Lapproche Streaming
dlai de transmission, etc. Le serveur reoit ces rapports et apprcie sil y a congestion. Dans ce cas, la source rduit alors le dbit mis Dautre part, RTSP tient compte dune varit doptions pour le transfert des donnes, comprenant ainsi UDP, UDP multicast et TCP. Cependant, il utilise uniquement TCP pour la transmission des commandes et des rponses.
3.2.1
Utilisation de RTP
Le client RTSP tablie trois canaux de connexion avec le serveur, lorsque les donnes sont livres par RTP (voir figure 17) . Une connexion TCP bidirectionnelle, pour le contrle et la ngociation. Un canal UDP unidirectionnel, pour la livraison des donnes mdias travers RTP. Un canal UDP bidirectionnelle, travers lequel RTCP est utilis.
Figure 17 : Les communications client/serveur dans le cas du RTP
Le numro de port RTP doit tre pair, alors que le RTCP doit oprer sur le prochain port conscutif. Par consquent, le port RTCP est toujours un nombre impair. Le port standard de connexion de TCP pour un serveur de RTSP est 554.
3.2.2
Utilisation de RDT
RDT est un protocole propre RealNetworks, qui opre sur le mme niveau que RTP. Dans le cas o cest ce protocole qui est utilis, le client tablira, de mme que dans le cas prcdent, trois connexions : Une connexion TCP bidirectionnelle, pour le contrle et la ngociation. Un canal UDP unidirectionnel, pour la livraison des donnes mdias. Un deuxime canal UDP unidirectionnelle, pour demander au serveur de renvoyer les paquets, UDP de donnes mdias, perdus. 56
Chapitre 4
Lapproche Streaming
Figure 18 : Les communications client/serveur en mode RDT
3.2.3
Utilisation de TCP seul
Les donnes mdias peuvent tre mis dans des paquets RTP ou RDT, qui seront transporter par TCP. Dans ce cas une seule connexion TCP bidirectionnelle est utilise pour le contrle et le transfert des donnes.
Figure 19 : Les communications client/serveur en mode TCP seul
3.3
Les mthodes RTSP
Les diffrentes requtes RTSP sont dfinies travers un ensemble de mthodes (voir figure 20). Les principales mthodes sont : DESCRIBE : Elle est utilise par le client pour rcuprer la description d'une prsentation ou d'un objet mdia, identifi par un URI (Uniform Resource Identifier), sur un serveur RTSP. SETUP : Elle est utilise par le client pour spcifier au serveur les paramtres de transport du flot mdia, comme par exemple le type de protocole de transport, le mode de transport (point point ou multipoint) et le numro du port de communication.
57
Chapitre 4
Lapproche Streaming
PLAY : Elle signale au serveur qu'il peut commencer envoyer les donnes via le mcanisme spcifi dans la mthode SETUP. Elle permet galement de jouer un ou plusieurs sous-intervalles de la dure d'un objet mdia, par exemple jouer une audio partir de la 10me seconde jusqu' la 20me seconde. PAUSE : Elle est utilise par le client pour demander au serveur d'interrompre temporairement le transfert du flux mdia. Le client peut reprendre la transmission du flux en envoyant la requte PLAY au serveur. TEARDOWN : Elle est utilise par le client pour demander au serveur d'arrter dfinitivement le transfert du flux mdia.
Figure 20 : Fonctionnement de RTSP
En rsum, RTSP dispose de plusieurs fonctionnalits, qui lui permettent un transfert de donnes, plus adapt aux mdias. En plus, il maintient une horloge qui est associe chaque objet mdia transmis. Cest cette horloge qui permet de dterminer, a chaque instant, si une partie des donnes transmettre, a dj dpass son chance. Dans ce cas, il est inutile de lenvoyer au client qui la rejetterai sa rception. RTSP permet donc la mise en uvre de stratgies de filtrage des donnes du ct du serveur et donc la source. Vu lefficacit du protocole RTSP, plusieurs diteurs de logiciels se sont intresss mettre en place des outils de streaming utilisant ce protocole. La section suivante prsentera ces diffrentes platesformes.
58
Chapitre 4
Lapproche Streaming
Conclusion
Ce chapitre nous a permis de dcouvrir la notion de streaming, ainsi que les caractristiques du protocole RTSP et des serveurs lutilisant. Nous avons pu voir aussi, dans ce chapitre, diffrents problmes, lis aux transmissions temps rel. Nous avons prsent galement quelques outils permettant de rsoudre les problmes dj cits. Le chapitre suivant prsentera la solution ralise.
59
Chapitre 5
Solution et ralisation
Introduction Comparaison entre les technologies de streaming Etude du cas de RealNetworks Plate-forme ralise
Rsum Dans ce dernier chapitre je dcrierai la plateforme ralise, qui est base sur des logiciels que je vais les mentionner dans ce chapitre ainsi que dautre outils complmentaires.
Chapitre 5
1 Introduction
RealNetworks a dvelopp une famille de logiciels, dans le but de raliser une architecture complte pour le streaming. Cette famille est appele RealSystem .
1.1 Prsentation de RealSyetem

Real System est une famille d'outils, compose essentiellement de trois logiciels : RealProducer , cest un outil de cration des mdias (son, vido ou animation). Il joue le rle du codeur. RealServer , pour servir les mdias. RealPlayer , cest le logiciel client permettant de jouer les prsentations servies. La figue suivante illustre comment ces composants sont relis ensemble.
Figure 21 : Les composants de real system
RealProducer
Cest le codeur de Real Networks. Il est disponible sur toutes les plates-formes. Actuellement, il est sa version 11. Le rle de cet outil de production consiste optimiser le codage pour une transmission efficace sur Internet ou encore sur des Intranets. La cration du contenu peut tre faite en diffr ou bien paralllement lvnement qui se produit. RealProducer est utilis pour convertir un son, une vido ou une animation en un format que le serveur peut transmettre. Mais puisque le RealServer supporte plusieurs formats (AVI, MOV, WAV et MP3), autres outils de cration du contenu peuvent tre utiliss, cependant, ils ne seront pas aussi performants que le RealProducer surtout que cest le seul programme capable de
61
Chapitre 5
communiquer avec le serveur lorsquil sagit de transmettre des donnes paralllement leur production.
RealServer
RealServer utilise plusieurs protocoles pour fournir les mdias aux clients travers lInternet ou des Intranets. Ainsi, suivant les situations, il servira ses donnes selon les protocoles RTSP, PNA (Progressive Network Audio) ou HTTP. Avec sa version 11, RealServer prsente plusieurs avantages. Ses dispositifs de control daccs et dauthentification permettent un trs bon niveau de scurit. De plus, il est dot dune interface dadministration distance, trs facile manipuler.
RealPlayer
Cest loutil le plus connu, parmi ceux de Real Networks, il est maintenant sa version 8. RealPlayer est le seul logiciel client capable de communiquer avec un RealServer. Il est dot de plusieurs fonctionnalits lui permettant de communiquer galement avec un serveur Web, ralisant ainsi un streaming avec le protocole HTTP. RealPlayer 11 est disponible en deux versions : le RealPlayer Basic et le RealPlayer Plus . Contrairement la version Basic , la version Plus nest pas gratuite et dispose de plus de fonctionnalits. Real Networks dispose dun autre outil aussi important savoir le RealProxy . Cet outil limine les transmissions redondantes, rduisant ainsi la bande passante utilise et permettant de servir plus de clients. En plus de RealServer, la plate-forme contiendra un serveur Web. En fait ce serveur Web, de type Apache, ne sert qu contenir des pages HTML, qui prsenteront les squences vido enregistre sur le serveur vido. Lorsquun utilisateur clique sur un lien donn, le logiciel client, savoir RealPlayer, se dclenchera pour permettre la visualisation des vidos. Le schma de la communication nest pas aussi simple quil parat. La figure 22 prsente les diffrentes tapes intermdiaires entre le clique du client et la visualisation de la vido.
62
Chapitre 5
Figure 21 : Initialisation des communications entre RealServer et RealPlayer
Tout dabord lorsque le client clique sur un lien qui lintresse, le navigateur Web contacte le serveur vido. Lors de la deuxime tape, le navigateur Web reoit un petit fichier qui pointe sur le contenu dsir. Cependant, il reconnat que ce type de fichier ne lui est pas destin. Il cherche alors le programme appropri, capable de comprendre ce quil y a dans le fichier reu. Ainsi RealPlayer est lanc. Dans ltape suivante, RealPlayer lira dans le fichier reu, le nom et lemplacement de la vido dans RealServer. Ensuite, il enviera une requte au serveur vido. Ce dernier rpondra en dernire tape, en transmettant la vido dsire.
2 Comparaison entre les technologies de streaming

QuickTime Streaming Server dApple, Windows Media Server (galement connu sous le nom de NetShow) de Microsoft et RealServer de RealNetworks sont les serveurs ddis les plus connus. Tous ces serveurs monopolisent le micro processeur de la machine serveur, amenant lutilisation du CPU 100% lors de la diffusion des images via le rseau. Il est alors impossible dexploiter simultanment le serveur vido comme serveur Web ou serveur de fichiers. Pour pouvoir choisir loutil convenable, une comparaison simpose. Ainsi, cette section abordera les diffrences entre les trois technologies en matire de cot, de scalabilit, dadministration et de scurit.
2.1
Cot
Tout serveur ddi ncessite un logiciel client appropri, qui peut tre tlcharg gratuitement. Les trois technologies fournissent galement un ensemble de logiciels pour manipuler et synchroniser les mdias temps-rel. Le NetShow de Microsoft est gratuit, il est partie standard de Windows 2000 et Windows NT. Les dernires mises jour sont disponibles au site Web de Microsoft. La qualit amliore de la dernire version fait de Windows Media 63
Chapitre 5
Server un choix convenable pour une socit environnement Windows. En ce qui concerne le serveur dApple, il a t initialement dvelopp pour son propre systme dexploitation. Cependant Apple a galement dvelopp un code source, connu sous le nom de Darwin Streaming Server , qui est tlchargeable sur le site Web dApple avec des versions pour Windows NT et 2000, Solaris et Linux aussi bien que la version initiale de Macintosh. A la diffrence des deux premires, Real Networks ne fournit pas son serveur gratuitement et cest tout fait raisonnable puisquelle na aucune autre source de revenu. Le cot de RealServer dpend du nombre maximal de connexions simultanes quil peut supporter. Le RealServer existe pour toutes les plates-formes, sur lesquelles il fonctionne de la mme faon.
2.2
Scalabilit
La scalabilit permet de servir une vido, de haute qualit aux utilisateurs disposant dune bande large et de qualit infrieure ceux ayant une bande troite. Chaque serveur traite la scalabilit dune manire lgrement diffrente. Windows Media Server est le plus limit. On peut produire deux versions de chaque fichier (bonne et mauvaise qualit), en utilisant diffrentes compressions. Quand quelquun demande une vido, le serveur de mdia teste la vitesse de connexion du client. Il sert alors la version la plus approprie. Cette approche signifie quon a deux copies de chaque fichier traiter ce qui augmente le temps et leffort pour contrler le site. RealServer communique avec RealPlayer de la mme manire. Cependant, les fichiers doivent tre comprims en utilisant une technique spcifique appele SureStream . On peut crer alors jusqu six versions diffrentes dune vido, chacune avec ses propres configurations de compression, mais qui seront fusionnes ensemble dans un grand fichier simple. Ceci ninflue pas sur la qualit, mais il permet de rduire le nombre de fichiers grer. QuickTime est le plus souple des trois technologies. Il permet de produire nimporte quel nombre de versions dune vido. En plus de la vitesse de la connexion de lutilisateur, le serveur peut vrifier dautres dtails tels que la vitesse du processeur de la machine qui tlcharge la vido.
2.3
Administration et scurit
Le client dadministration distante, crit en Java, de RealServer est particulirement utile. Le produit de Microsoft, apporte moins de contrles. Il est facile administrer mais il impose dutiliser Internet Explorer et dinstaller un Active X en complment du navigateur Web. Quant QuickTime, il ne propose aucune fonction dadministration distante. En matire de scurit, RealServer permet le control daccs, lauthentification des clients ainsi que le 64
Chapitre 5
cryptage du flux vido et la configuration de la dure daffichage et des droits de visualisation, de tell ou telle vido en fonction des permissions sur les rpertoires. QuickTime prsente des lacunes de scurit alors que Windows Media Server utilise les avantages des fonctions de base de Windows NT telles que les listes de contrles daccs et les permissions de fichiers. Une comparaison entre quatre technologies a t faite par le magazine Rseaux & Tlcoms . Toutes les socits, en relation avec le streaming, ont t invites fournir les logiciels serveurs et les outils ncessaires pour crer, modifier et importer les vidos. La comparaison a t faite en tenant compte de plusieurs contraintes. Le tableau suivant rsume les rsultats des tests.
Figure 22 : Comparaison des technologies de streaming
Au terme de ces tests, la technologie de Real Networks, savre la meilleure solution pour diffuser de la vido sur rseau numrique. Elle prsente plusieurs avantages : images de haute qualit, bonnes performances, fonctionnement identique quelle que soit la plateforme de visualisation, administration distante simple mettre en uvre.
Nous avons pu voir dans ce paragraphe, une comparaison entre les trois meilleures technologies de streaming. Une comparaison qui a donn lavantage la famille RealSystem de RealNetworks.
3 tude du cas de RealNetworks 3.1

3.1.1
Le codeur de RealNetworks
Fonctionnement de RealProducer
RealProducer peut convertir les sons et les vidos partir de fichiers (AVI, MOV, QT,
65
Chapitre 5
WAV et AU) ou directement partir dun outil dacquisition. Le rsultat de la conversion peut tre stock sur un fichier ou bien transmis en direct travers un RealServer.
Figure 23 : Enregistrement des prsentations Real Media
A noter que RealProducer naccepte quune seule entre et une seule sortie la fois. Avant de commencer le traitement, il demande son utilisateur si lentre sera un fichier ou un outil dacquisition, la combinaison des deux nest pas possible. De mme pour la sortie, lutilisateur doit prciser lemplacement du fichier si les donnes seront stockes localement. Sinon, il doit indiquer le serveur auquel elles seront transmises, les deux possibilits ne peuvent tre ralises simultanment. RealProducer fonctionne sur toutes les plates-formes, Windows 95/98/2000 et NT 4.0, Mac OS 8.6 ou 9, Linux 2.2.x et Solaris 2.7. Les conditions ncessaires pour un fonctionnement correct du logiciel sur un systme Windows ou Linux varient suivant la source des mdias convertir. Ainsi, dans le cas dune acquisition, le matriel doit tre plus performant, par rapport au cas o la source serait un simple fichier.
3.1.2
SureStream
Lors de la cration dun contenu avec RealProducer, on est amen choisir entre une prsentation simple cadence ou bien dutiliser la notion de SureStream qui donnera naissance une prsentation cadences multiples . Le SureStream consiste inclure dans la mme sortie, diffrents flux optimiss pour des largeurs de bande diffrentes. Ainsi, on peut atteindre un public trs large, tout en fournissant tous les utilisateurs le meilleur son et la meilleure image pour leur bande passante. De plus lors dune congestion du rseau, la prsentation commutera automatiquement un dbit infrieur. Par exemple, dans le menu du RealProducer, lutilisateur peut enregistrer une vido pour les trois cibles 10, 20 et 100 Mga bits par seconde (Kbps). RealPlayer utilisera automatiquement le flux convenable sa vitesse de connexion sachant que tous les flux sont dans le mme fichier. 66
Chapitre 5
Figure 24 : Enregistrement dune prsentation pour diffrentes largeurs de bande
SureStream fonctionne seulement sur un RealServer. Puisquun seul fichier contient tous les flux, le serveur doit tre capable dextraire juste le ncessaire. Un RealServer peut localiser chaque flux et par consquent transmettre le plus convenable. Par contre, un serveur Web, ne connat pas les dtails, alors il transmettra toutes les donnes au lieu de choisir un seul flux. Bien que lon puisse coder une vido, en utilisant le SureStream, juste pour une vitesse de connexion donne, ce contenu ne doit pas tre servi par un serveur Web. Mme lorsque le contenu est cod pour une seule vitesse, il contiendra plusieurs flux, afin de pouvoir diminuer en dbit sil y des problmes sur le rseau. Par exemple, une vido compresse seulement pour 28,8 Mbps, mais en utilisant le SureStream, contient des flux 16 et 11 Mbps. Un serveur Web tlchargera le tout, gaspillant ainsi la bande passante. Le fait que tous les flux soient mis ensemble dans un mme fichier peut donner naissance des fichiers de tailles plus grandes que les sources, mme sils sont compresss. Si le volume des fichiers pose un problme, il faut limiter le choix aux vitesses essentielles.
3.1.2
Realvideo
Une vido se compose de deux parties : le son et les images. Pour compresser la partie sonore, RealProducer utilise RealAudio, alors que pour la partie visuelle, ce sont les codecs RealVideo qui sont employs. Le rsultat de la conversion sera mis dans un fichier dextension rm . RealProducer convertit diffrents attributs de la vido savoir la cadence des trames, les types de mouvement et la taille des images.
67
Chapitre 5
Principe
Contrairement RealAudio, RealVideo utilise un seul codec pour compresser la piste visuelle pour toutes les largeurs de bande. Le codec RealVideo permet une grande chelle de scalabilit, la vido peut tre alors code de 20 Mbps des centaines de Mbps. RealVideo utilise une compression avec perte. Lorsque cest ncessaire, il limine intelligemment les donnes, pour garder une qualit aussi bonne que possible. Pour diminuer la taille de la vido, RealProducer joue aussi sur la cadence des images. En fait, la plupart des vidos ont des cadences de 15 30 images par secondes (i/s), RealProducer ajuste dynamiquement cette cadence. Dans ce sens, il la maintient leve lorsquil sagit dune scne mouvement rapide, alors que lorsque le mouvement est lent, il diminue la cadence. RealProducer dtermine comment coder une vido partir des choix suivants : Vitesse cible, Type du son, Nature de la vido (mouvement rapide ou lent.)
3.1.2
Options de compression
RealProducer dispose de plusieurs options de codage. * Protection contre les pertes : ce dispositif ajoute des donnes de correction d'erreurs au flux compress, permettant ainsi de maintenir sa qualit dans un environnement pertes. Il a un impact ngligeable sur la vitesse de codage. * Codage VBR : le principe du VBR (Variable Bit Rate) consiste rguler le dbit de sortie du codeur, donnant ainsi plus de largeur de bande aux scnes difficiles compresser et moins de bande pour les scnes faciles. Le codage VBR donne gnralement des vidos de qualit meilleure ceux codes par CBR (Constant Bit Rate). * Maximum de temps entre deux images cl : RealProducer code toutes les donnes dune cl, alors que pour celles qui la suivent, il ne codera que la diffrence entre limage et celle qui la prcde. Par dfaut, le maximum de temps entre deux images cl est de 10 secondes. En diminuant cette valeur, plus dimages cl seront produites et par consquent les distorsions diminueront. Mais puisque les images cl contiennent plus de donnes, le fait de diminuer le temps entre deux images de ce type peut entraner une dgradation de la qualit si la largeur de bande est la mme. 68
Chapitre 5
3.2
Le serveur de RealNetworks
RealServer est un logiciel qui permet de transmettre des mdias pr-enregistrs ou en direct sur l'Internet ou dans un Intranet. Il diffuse le son, la vido, les images, les animations, le texte et d'autres types de donnes, aux ordinateurs clients. Cette partie survole brivement les diffrentes proprits du serveur de RealNetworks, il fournit les rponses aux questions suivantes : Quelles sont les conditions dun bon fonctionnement du logiciel ? Quel est son principe de fonctionnement ? Quelles sont les mthodes quil utilise pour dlivrer les donnes aux clients ? Cette partie prsente galement les dispositifs, de scurit et de manipulation de la bande passante, intgrs dans RealServer.
3.2.1
Conditions de fonctionnement
Indpendamment de la plate-forme utilise, le RealServer fonctionne mieux lorsquil est install sur un ordinateur ddi. Il faut viter par consquent d'installer des serveurs Web ou d'autres applications sur le mme ordinateur que RealServer. Le RealServer utilise un modle multiprocesseur, qui est particulirement bien adapt l'architecture client/serveur. Quand un client essaie de se relier au serveur, le gestionnaire de systme cre un nouveau processus pour contrler ce client alors qu'un autre processus coute les connexions des autres clients. Ainsi, le RealServer est plus performant quand il fonctionne sur un systme avec plus d'un processeur. La mmoire et les processeurs affectent le fonctionnement du RealServer. En ajoutant de la mmoire il pourra manipuler plus d'informations n'importe quel moment, tandis que lajout des processeurs lui permet de traiter l'information plus rapidement.
3.2.2
Fonctionnement
Canaux et protocoles
Chaque lien, au contenu du RealServer, doit commencer par un identificateur de protocole, tel que RTSP, PNM ou HTTP. RealServer emploie principalement deux protocoles : RTSP, 69
Chapitre 5
PNA, le HTTP nest utilis quoccasionnellement. En fait RealServer sen sert pour les fichiers mta qui pointent sur le contenu du serveur ainsi que pour les pages de HTML qu'il sert (les pages HTML pour ladministration). Il peut galement tre employ pour livrer des vidos aux clients qui sont situs derrire un pare-feu. RealServer utilise deux connexions, connues sous le nom de canaux, pour communiquer avec les clients. La premire voie est connue par le nom de canal de contrle . Cest travers ce canal que le serveur demande et reoit des mots de passe et que les clients envoient des instructions telles que lavance rapide, et l'arrt complet ou instantan. D'autre part, les mdias sont transmis sur une voie spare dite canal de donnes . Dans ces canaux, le serveur utilise deux protocoles pour envoyer les instructions et les donnes: TCP : pour envoyer les commandes du client, et les informations spcifiques aux mdias prsents tel que titre. UDP : pour le transfert du contenu.
Puisque beaucoup de firewalls sont configurs pour permettre seulement des connexions TCP ou bien du trafic HTTP, on peut avoir besoin de faire quelques modifications pour recevoir les donnes d'un codeur ou bien pour servir les clients qui derrire un pare-feu.
Communication entre un codeur et un realserver
Figure 25 : Fonctionnement codeur/serveur dans le cas normal
Dans le cas normal, quand un codeur se connecte au serveur, il utilise un canal TCP bidirectionnel pour le contrle et un canal UDP sens unique pour transmettre les donnes. Parfois les pare-feu nautorisent pas les paquets UDP. Ainsi, la connexion TCP est utilise la fois pour le contrle et les donnes.
70
Chapitre 5
Figure 26 : Fonctionnement codeur/serveur dans le cas dun pare-feu
Communication entre un RealPlayer et un RealServer

Quand un utilisateur clique sur un lien qui pointe sur une prsentation donne, le client ouvre une connexion bi-directionnelle avec le serveur. Cette connexion utilise TCP pour changer des informations concernant les mdias transmettre ou bien lauthentification de lutilisateur.
Figure 27 : Phase initial de la communication client/serveur
Lorsque le serveur accepte la demande, il envoie les mdias demands au RealPlayer le long d'un canal UDP sens unique.
Figure 28 : Phase de transfert de donnes entre le client et le serveur
71
Chapitre 5
3.2.3
Mthode de livraison des mdias
A la demande
Les donnes sont la disposition de lutilisateur nimporte quel moment. Ce type de mdias est pr-enregistr, les vidos sont servies sur demande. Un utilisateur qui clique sur un lien pointant sur ce genre de donnes, pourra visualiser la vido depuis le dbut. Il pourra galement avancer ou arrter la prsentation.
En direct
Les prsentations en direct sont transmises aussitt quelles sont cres. Elles nexistent pas sous forme de fichiers. Lutilisateur peut joindre les vnements qui se droulent nimporte quel moment, une fois quil a cliqu sur un lien vers une prsentation en direct. Contrairement aux transmissions la demande, le client ne peut pas avancer ou arrter les mdias. Servir des prsentations en direct, ncessite le matriel et le logiciel convenables pour lacquisition du contenu ainsi que sa conversion en un format que le RealServer peut diffuser. Les prsentations en direct peuvent tre transmises de diffrentes manires, selon les besoins du rseau ladministrateur dcide de choisir une mthode donne. * Le point point : cest la mthode la plus simple et la plus connue pour des diffusions en direct, puisquelle ne ncessite aucune configuration. Cependant, elle exige une bande passante assez large pour pouvoir servir tous les clients connects. * Le splitting : cest le terme utilis pour dcrire comment un RealServer peut partager ses flux de mdias, transmis en direct, avec dautres RealServers. Les clients se connectent ces serveurs, plutt quau serveur principal qui est lorigine des mdias. Le splitting rduit la charge du trafic sur le serveur source. Cette mthode permet aussi de dplacer les missions plus prs des clients, amliorant ainsi la qualit de service. * Le multipoint : il exige un rseau supportant le multipoint, malheureusement ce nest pas le cas au Maroc. Le multicast sera dcrite plus en dtail dans le paragraphe suivant. Le choix de la mthode la plus convenable dpend des situations. Le point point est typiquement utilis pour un nombre assez rduit de client. Le splitting et le multipoint sont plus appropris pour les diffusions un grand nombre dutilisateurs.
72
Chapitre 5
3.2.4
Le multipoint
Le multipoint consiste transmettre un seul flux pour diffrents clients, plutt que de d'envoyer un flux par client.
Figure 29 : Schma de multipoint
Pour tirer profit du multipoint, les routeurs et les commutateurs reliant le serveur ses clients, doivent supporter le multicast. Pour cette raison, le multipoint est utilis dans la plupart du temps dans les Intranets, o les dispositifs de rseau peuvent tre configurer pour fonctionner en multicast. Par contre sur Internet, il se peut que des dispositifs intermdiaires du rseau ne supportent pas le multipoint. RealServer permet deux mthodes de multipoint : le back channel multicast et le scalable multicast.
Back-Channel multicast
Cette mthode consiste maintenir un canal de contrle entre le serveur et chaque client. Le serveur utilise ce canal pour fournir des informations au sujet de la prsentation, pour demander des informations dauthentification au client ou pour recevoir les commandes de ce dernier.
73
Chapitre 5
Figure 30 : Schma de la back-Channel multicast
Le back-Channel multicast peut utiliser les protocoles RTSP ou PNA. Les informations dauthentification, les statistiques et les mesures de qualit de service peuvent tre transmises puisque le serveur et le client sont relis par un canal bidirectionnel.
Scalable multicast
Contrairement la premire mthode, celle-ci nutilise pas de canal de contrle, ainsi elle ncessite moins de bande passante.
Figure 32 : Schma du scalable multicast
Le scalable multicast permet de servir un nombre illimit de clients puisque la transmission du RealServer est sens unique et aucune connexion ne le relie ses clients. Toutes les donnes sont diffuses sur le rseau une seule fois pour tous les clients. Pareil au back channel multicast, le scalable multicast supporte les deux protocoles RTSP et PNA. Cependant cause de labsence du canal de contrle, lauthentification des clients ne peut pas avoir lieu. Alors 74
Chapitre 5
que les statistiques sont transmises la fin. Ainsi, avec le RealServer, deux formes de multicast sont possibles, permettant dconomiser la bande passante. Cependant la notion de SureStream nest pas oprationnelle si lon opte pour le multipoint. En fait puisque la mme prsentation sera servie tous les clients, il est impossible dadapter la qualit transmise chacun.
3.2.5
Gestion de la bande passante
RealServer fournit des outils permettant de grer la bande passante utilise. Dans ce sens on peut limiter le nombre de clients pouvant se connecter au serveur simultanment ou encore limiter la bande passante consomme par le RealServer. En rglant le paramtre Maximum Client Connections , on peut limiter le nombre dutilisateur servis simultanment. Ce nombre peut prendre des valeurs de 1 32767, tant qu'il est infrieur ou gal au nombre de transmissions permises par la licence. Sil est gal zro ou quil est non prcis, RealServer utilise le nombre maximal de flux permis par la licence. Une fois que la limite est atteinte, les clients qui essayeront de se connecter recevront un message derreur et ne pourront tre servis que lorsquun utlisateur se dconnectera. De mme, le paramtre Maximum Bandwidth , permet de restreindre la quantit de bande passante, en Kilo bits par seconde, que le RealServer peut utiliser. Si lon tablit des valeurs pour les deux variables, RealServer limitera l'accs quand le seuil infrieur est atteint.
3.2.6
La Scurit
Le RealServer permet diffrentes mesures de scurit. Il est alors possible de limiter laccs au serveur suivant les adresses IP ou bien dauthentifier les utilisateurs. RealNetworks a dvelopp galement des plug-ins client et serveur pour une communication crypte entre les deux.
Le contrle daccs
On peut bloquer ou permettre l'accs au serveur, en se basant sur les adresses IP de la machine dsirant se connecter et sur le port auquel la demande est faite. Chaque contenu est associ un numro de port spcifique : les mdias sont servis sur le port RTSP et le port PNA, les pages HTML sont disponibles travers le port HTTP. Les codeurs fournissent les donnes compresses par lintermdiaire dun port particulier. De mme, ladministration distante 75
Chapitre 5
utilise un port prcis qui sera dfini linstallation. Le dispositif de contrle daccs, permet ladministrateur du rseau de choisir qui peut se connecter et quel port. Par exemple on peut restreindre laccs des codeurs en choisissant les machines qui peuvent utiliser le port de codage (4040 par dfaut). On peut galement permettre seulement certaines personnes de visualiser les prsentations servies, en prcisant leurs adresses IP ainsi que les numros de ports daccs pour les protocoles RTSP, PNA et HTTP. Les clients qui ne sont pas autoriss, recevront un message d'erreur indiquant que lURL est incorrecte. Les informations, concernant chaque adresse ou plage dadresses quon dsire autoriser ou non, sont stockes dans des rgles. Une rgle est un ensemble d'instructions dcrivant la manire dont le serveur doit se comporter vis vis de certaines adresses IP. Chaque rgle est identifie par un nombre qui lui sera assign lors de sa cration. Une rgle contient les informations suivantes : Numro de la rgle : il identifie la rgle. Accs : client autoris ou non. Adresse IP du client : individuelle ou bien une plage dadresses. Adresse IP du serveur : ladresse du RealServer. Numros de Ports. Lorsquun client essaie de jouer une prsentation ou bien denvoyer des mdias compresss, le serveur compare son adresse et le port demand aux adresses et aux ports numrs dans les rgles. Si ladresse IP du client et le numro de port napparaissent dans aucune rgle, le serveur refuse laccs. Par exemple, pour permettre un codeur denvoyer ses donnes au serveur, on crera une rgle qui spcifiera l'adresse IP du client et le port de codage 4040. Lors de la vrification des rgles, RealServer commence par les rgles ayant les plus petits identificateurs. Cest pourquoi, les rgles ayant des numros petits, doivent tre les plus strictes. Le contrle daccs est bas sur les adresses IP et les ports requis. RealServer possde galement un autre dispositif plus slectif en matire de restriction daccs aux donnes servies et reues. Ce dispositif est lauthentification.
Lauthentification
Elle permet de contrler laccs des utilisateurs aux services du RealServer, quils soient codeurs, administrateurs distants ou clients dsirant visualiser des prsentations quils ont payes. En utilisant l'authentification, l'identit des utilisateurs ou logiciels, qui ont lanc des 76
Chapitre 5
requtes vers le serveur, sera vrifie avant le commencement du dialogue. Pour les codeurs, il sera exig de fournir un nom et un mot de passe avant denvoyer leurs donnes. Si lidentit est non correcte le transfert naura pas lieu. En ce qui concerne ladministration, pour protger le serveur contre des changements, seules les personnes ayant des identits valables pourront accder au RealSystem Administrator , outil dadministration des serveurs de RealNetworks. Quant aux clients en plus des identits exiges, laccs pourra tre limit un certain nombre de rpertoires ou de prsentations. Les noms des utilisateurs autoriss pour chaque catgorie (codeurs, administrateurs et clients), sont enregistrs dans des bases de donnes spares. RealServer permet plus quune simple authentification lorsquil sagit de visualiser des prsentations. A partir de lURL demande et de lidentit de lutilisateur, il dtermine le type daccs aux donnes. En fait lors de lajout dun utilisateur la base de donnes, on dfinit ses droits daccs pour chaque fichier et rpertoire du contenu scuris. Les types daccs sont prsents par le tableau 33 :
Figure 33 : Type de permission
Les termes Event, Calendar, Duration et Credit sont les paramtres utiliss au niveau du RealSystem Administrator pour dfinir le type daccs.
Cryptage
Real Networks fournit un autre mcanisme pour scuriser les mdias transmis en chiffrant le flux de donnes entre le serveur et le client. Le chiffrement est ralis par des plug-ins qui permettent de crypter les donnes au niveau du serveur et de dcrypter le flux reus au niveau du client. Ces plug-ins changent des messages travers le canal de contrle. Ces messages peuvent par exemple contenir les cls publiques de cryptage. Le serveur cryptera les donnes avec une cl publique du client, ensuite le rsultat sera transmis. Une fois le flux chez le 77
Chapitre 5
client, il sera dchiffr, en utilisant la cl prive de ce client. Ensuite la visualisation commencera. Le processus entier, cryptage/dcryptage, est transparent l'utilisateur. Actuellement, le cryptage peut tre utilis seulement pour les connexions point point. Puisque chaque flux est chiffr pour un client spcifique, il ne peut tre dchiffr que par ce client. Le canal de donnes est utilis pour fournir le contenu crypt. Cest un canal avec pertes, il ny a aucune garantie que les paquets arriveront leur destination. Le chiffrement employ par RealServer, a t spcifiquement conu pour fournir une scurit forte dans ce type d'environnement afin dviter les problmes au niveau du dchiffrement. Ainsi, la mthode employe, consiste crypter les paquets de manire indpendante. Par consquent, si un paquet est dtruit, dform ou perdu, il ninfluencera pas le processus de dcryptage.
3.3
3.3.1
RealPlayer
Fonctionnement
RealPlayer peut communiquer avec un serveur Web ou un RealServer. Il est capable de lire les mdias aussitt quune partie sera reue. Ainsi, il commence la prsentation tout en continuant recevoir les donnes. Pour viter au maximum les interruptions qui peuvent avoir lieu lors de la lecture des mdias, RealPlayer utilise la notion de bufferisation . En effet il se sert dun buffer pour stocker un certain nombre de paquets qui vont tre jous par la suite. Cependant, si le rseau est congestionn, il se peut que la rception soit en retard par rapport la prsentation. Dans ce cas RealPlayer, doit attendre le remplissage de buffer pour jouer les donnes qui y sont stockes. De cette manire la continuit du flot sera sur des squences et non pas pour toute la prsentation. RealPlayer gre aussi la synchronisation des donnes. En fait lorsquil sagit dune vido, le son et les images sont transmis sur des diffrents paquets. A la rception, RealPlayer rorganise les donnes avant de les prsenter.
3.3.2
Transport des donnes
RealPlayer permet son utilisateur de spcifier le protocole de transport qui sera utilis lors de la communication avec le serveur. La figure 34 prsente les diffrents choix que permet RealPlayer. Selon la figure 34, RealPlayer peut lancer une configuration automatique, choisissant ainsi le mode de transport le plus efficace. Mais, il est aussi possible de laisser
78
Chapitre 5
lutilisateur linitiative de spcifier certains paramtres pour les protocoles RTSP et PNA. Dans ce dernier cas, la figure 35 illustre les diffrentes options possibles.
Figure 34 : Prfrences de transmission
Figure 35 : Options de transport pour le protocole RTSP
79
Chapitre 5
3.3.3
Autres configurations
Pour des raisons de scurit, des serveurs proxys peuvent tre imposs pour communiquer avec les serveurs. RealPlayer peut tre configur pour passer par ces proxys, il suffit dindiquer leurs adresses IP ainsi que les ports quils utilisent.
Figure 36 : Utilisations des proxys
RealPlayer permet de rgler dautres paramtres qui sont en relation avec les performances du systme. Dans ce sens, lutilisateur peut optimiser lutilisation de son processeur ainsi que la mise en cache des fichiers consults.
80
Chapitre 5
4 Plate-forme ralise 4.1 Schma de la plate-forme ralise
En tenant compte des informations que je viens de prsenter, ainsi que des mesures de scurit que nous devons prendre, le schma de la plate-forme ralise se prsente comme suit:
Figure 37 : Plate-forme ralise
Une requte qui vient de lextrieur, arrivera tout dabord au rseau local du DSI, en passant par son routeur. Elle sera ensuite achemine vers la machine protectrice machine P . Cette dernire appliquera des mesures de scurit, puis si le flux est accept, il sera redirig vers les serveurs machine S . Les rponses des serveurs prendront le chemin inverse. A noter que pour des raisons defficacit, il serait mieux de mettre le serveur Web et le serveur vido sur des machines diffrentes. Les machines S et P sont des ordinateurs Linux, dont la version du noyau est 2.2. Sur la premire, jai install un RealServer et un serveur Web Apache alors que sur la deuxime, jai mis en place un RealProxy et un proxy HTTP Squid . De plus la machine P dispose de deux interfaces rseau : deux cartes Ethernet, une est relie au rseau local du DSI alors que lautre est connecte directement la machine S. 81
Chapitre 5
La machine S qui offre un service Web et un service vido, doit tre accessible de lextrieur, travers Internet. Autrement dit, elle doit disposer dune adresse IP publique, de la forme 194.204.209.x. Une requte extrieure, arrivera au routeur qui doit lacheminer vers la machine 194.204.209.x. Pour ce faire, il a besoin de ladresse matrielle adresse MAC de cette machine. La solution est une requte ARP (Address Resolution Protocol). Dans ce sens, le routeur enviera, toutes les machines de son rseau, un message demandant la machine dadresse IP 194.204.209.x de lui envoyer son adresse MAC. Cest ce niveau que nous devons intervenir. En fait, si la machine S est connecte directement au rseau local de la direction, elle rpondra la requte ARP et le paquet provenant de lextrieur arrivera aux serveurs sans contrle. Une solution est de sparer la machine S du rseau local et de la connecter seulement la machine P qui doit tre configure de telle sorte rpondre aux requtes ARP destines ladresse IP 194.204.209.x. Cest la notion dARP Proxy. Une fois les paquets sont au niveau de la machine P, ils seront redirigs, grce lutilitaire ipchains contenu dans les systmes Linux, vers les applications proxys, pour appliquer les mesures de scurit. Les rponses des serveurs prendront le chemin inverse, mais pour cela, la machine S doit tre configure de telle sorte avoir la machine P comme passerelle par dfaut.
4.2
Principe de lARP Proxy
Pour mettre en place mon architecture, jai cre un sous rseau R1 du rseau local du DSI R0 .
82
Chapitre 5
Figure 38 : Cration du sous rseau R1
Pour R1, jai choisi un masque, de 30 bits (255.255.255.252), qui permet de dfinir deux adresses IP sur ce rseau. La machine P sera connecte R0 travers linterface Ethernet eth0 et R1 par lintermdiaire de linterface eth1 . Supposons quune machine L (routeur ou ordinateur) de R0 veuille envoyer un paquet la machine S. Puisque ladresse IP de cette dernire laisse croire la machine L que S est sur le mme rseau physique, la machine L utilisera le protocole de rsolution d'adresse ARP pour envoyer un message de diffusion sur R0, demandant la machine qui a ladresse IP de S de rpondre avec son adresse matrielle (adresse Ethernet ou MAC). La machine S ne verra pas cette requte, puisqu'en ralit elle n'est pas sur R0, par contre la machine P, qui est sur les deux rseaux, la verra. Lorsque le noyau Linux de la machine P est configur en ARP Proxy, il dtermine quune requte est arrive sur l'interface eth0, et que ladresse IP rsoudre est dans l'intervalle du R1. La machine P envoie alors sa propre adresse Ethernet la machine L dans un paquet de rponse ARP. La machine L met alors jour son cache ARP en y ajoutant une entre pour la machine S, mais avec l'adresse matrielle de la machine P. La machine L peut alors envoyer le paquet, qui sera reu par P. La machine P remarque que l'adresse IP de destination n'est pas la sienne, mais celle de S. Le code de routage du noyau Linux de la machine P essaie alors dacheminer ce paquet vers la machine S en cherchant dans ses tables de routage pour savoir 83
Chapitre 5
quelle interface contient ladresse de S. Maintenant P doit trouver la vraie adresse matrielle de la machine S, en supposant qu'elle ne l'a pas dj dans son cache ARP. P utilisera une requte ARP, travers linterface eth1, la machine S rpondra par consquent en donnant sa propre adresse Ethernet. P peut alors envoyer le paquet, qui venait de L, vers la machine S.
4.3
Lutilitaire ipchains
ipchains est un outil de filtrage des paquets IP, intgr dans le noyau Linux partir de la version 2.1. En effet tout le trafic circulant dans un rseau est envoy sous formes de paquets. Le dbut de chaque paquet prcise son type, sa source, sa destination et divers autres dtails. ipchains, comme tout filtre de paquet, est un programme qui regarde lentte des paquets et dcident de leur destin. Il peut alors les refuser (les supprimer comme sils nont jamais t reus), de les rejeter (effet identique au refus, mais il est prcis la source que le paquet na pas t accept), de les accepter ou de les rediriger vers dautres ports.
4.4
Configuration requises du noyau
Pour pourvoir utiliser lutilitaire ipchains le noyau Linux doit supporter certaines configurations rseau. Donc, sous le rpertoire /usr/src/linux/ , la commande make xconfig permet de lancer un utilitaire de configuration de tout le systme Linux. Dans le menu Options rseau , il faut alors activer les options suivantes : Rseau TCP/IP : il est hautement recommand dactiver cette option, les protocoles utiliss dans Internet seront ainsi chargs et reconnus par le noyau. IP routeur avanc : la machine P servira comme routeur, qui transmet et redirige les paquets rseau. En activant cette option, plus de fonctionnalits seront disponibles au niveau du processus de routage. Cependant, la machine P ne peut fonctionner en routeur que si la transmission IP IP forwarding est active dans le noyau par la commande echo 1 > /proc/sys/net/ipv4/ip_forward .En activant la transmission IP, nous aurons galement le rp_filter , qui rejette automatiquement les paquets entrants, si lentr de la table de routage pour leur adresse source ne correspond pas linterface rseau par laquelle ils arrivent. Cela est un avantage pour la scurit, dans la mesure o rp_filter prvient les attaques dIPspoofing, prsentes dans le premier chapitre. IP passage par barrire coupe feu : cette option est ncessaire pour utiliser une machine Linux comme un firewall filtre de paquet. Le code de firewalling ne fonctionne que si la transmission IP est active dans le noyau. 84
Chapitre 5
IP proxy transparent : cette option permet au firewall de rediriger de manire transparente tout trafic rseau vers un serveur proxy local. Cela fait que les ordinateurs pensent communiquer avec le serveur distant alors quils sont connects au proxy. La redirection est utilise en dfinissant des rgles de barrire pare-feu laide de lutilitaire ipchains. Il est noter que pour un bon fonctionnement de la machine P, il serait prfrable de choisir loption Optimiser comme un routeur et non comme hte dans les options rseau du noyau. Dautre part, puisque le but est de scuriser notre plate-forme, il serait trs utile dactiver loption Protection contre linondation SYN . En fait le fonctionnement normal en TCP/IP est victime dune attaque connue sous le nom dinondation SYN. Cette attaque qui est de type dni de service (voir chapitre 1), empche les utilisateurs lgitimes de se connecter lordinateur. En activant loption Protection contre linondation SYN , la couche TCP/IP utilisera un protocole cryptographique, connu sous le nom de SYN cookies , pour permettre aux utilisateurs lgitimes de continuer de se connecter mme si la machine subit des attaques.
4.4
4.4.1
Logiciels utiliss
Le serveur web apache
Les communications sur le Web sont rgies par un protocole, nomm HTTP, Hypertext Transfer Protocol. Elles font appel une architecture client-serveur fonde sur un systme de requtes et de rponses. Fondamentalement un serveur HTTP nest rien dautre quun serveur de fichiers lcoute sur un port TCP (gnralement le port 80). Lorsquil reoit une demande de connexion suivie dune requte, il rpond en expdiant le fichier demand.
4.4.2
Fonctionnement
Apache est un serveur Web, qui est totalement gratuit. Il est offert par toutes les distributions Linux. Apache bnficie dune richesse doptions impressionnante et en constante volution. Cest de surcrot lun des serveurs les plus performants disponibles lheure actuelle. Certaines fonctions disponibles avec Apache ne sont pas directement intgres au serveur, mais proposes sous forme de modules rattachs lors de la compilation. Apache, peut fonctionner avec inetd ou en mode standalone . La diffrence se situe dans le fait quen mode inetd , un nouveau serveur sera lanc chaque requte. Ce mode est acceptable si le site est de taille raisonnable avec une frquentation acceptable, mais il peut reprsenter une charge machine trop importante ds lors que le nombre de connexions augmente. En mode standalone , Apache grent au mieux le nombre de processus quil lance, ainsi dmarre 85
Chapitre 5
demble un nombre minimal de processus afin de rpondre quelques requtes sans devoir dmarrer un nouveau serveur chaque fois. Afin de ne pas trop occuper la mmoire avec des processus inactifs, il en supprime automatiquement une partie
4.4.3
Configuration
Tous les fichiers de configuration du serveur Web Apache se trouvent dans un rpertoire commun, dont le nom dpend de linstallation. Dans le rpertoire racine, l o Apache a t install, se trouve un dossier conf . Ce rpertoire comporte quatre fichiers, dont trois sont directement responsables de la configuration du serveur. Le quatrime contient une liste de types MIME . Les noms de ces fichiers sont les suivants : httpd.conf : cest le fichier de configuration principal dApache. Il est lanc en premier et contient les paramtres de base ncessaires lexploitation du serveur Web. access.conf : ce fichier rgle les questions de scurit daccs. Il permet dindiquer quels rpertoires sont accessibles tous les utilisateurs, de dfinir des restrictions pour dautres rpertoires plus sensibles, voire den interdire compltement laccs toutes les machines qui ne ferait pas partie dun domaine donn. srm.conf : il permet de dfinir les configurations qui concernent les ressources. Dans ce sens ce fichier prcise, les options de configuration relatives lorganisation du site, quil sagisse des rpertoires contenant les documents ou des types de fichiers quils reprsentent. mime.conf : il prcise au serveur comment retrouver le type MIME dun document partir de son action.
Conclusion
Dans ce chapitre, nous avons pu voir les diffrents outils composant la plate-forme logicielle, qui a t mise en place au niveau de lONEP, pour permettre la vido surveillance dans la direction de system informatique. Cette plate-forme logicielle prsente certains avantages trs important, mais galement quelques limites en matire dinteractivit et dinsertion doutils pour le codage, lindexation et la mesure de qualit.
86
Conclusion
Conclusion Gnrale
Limplmentation dun serveur vido, qui fait lobjet de mon projet de fin dtude, est une partie intgrante de la ralisation dune plate-forme de vido surveillance. Jai donc pos, ds le dpart, deux questions majeurs, savoir : Comment raliser un serveur de streaming ? Comment compresser le flux vido ? Vu les contraintes imposes en termes de systme dexploitation (Linux), nous avons opt pour la solution RealSystem de RealNetworks. Cette dernire savre le meilleur non seulement sur Linux mais aussi sur les autres plates-formes. Elle comprend un ensemble complet doutils pour crer larchitecture (serveur, proxy, codeur, client). En matire de scurit, le systme dexploitation Linux, nous a permis de raliser le control daccs. Par ailleurs, grce des fonctionnalits propres RealServer et RealProxy, concernant le cryptage et lauthentification, nous avons pu atteindre un niveau assez lev de scurit.
87
Conclusion
Bibliographie
[1] D.pam , a tutorial on MPEG/vido compression ,IEEE ,2004 [2]: Helmut HOLZ, Bernd SCHMITT et Andreas TIKART, Internet et intranet sous Linux , EYROLLES, September 2007. [3]: Internet Engineering Task Force, Real Time Streaming Protocol , RFC n 2326, Avril 2005. [4] : Barry NANCE, Quatre serveurs vido pour IP , Rseaux & Tlcoms, N162, 7 avril 2006. [5] : Etudiants de l'option Ingnierie et Informatique pour le multimdia, Recueil des exposs , ENIC, Lile, France, Promotion 2000. [6]: Apache HTTP server project , http://httpd.apache.org/ [7]: RealNetworks, RTSP Interoperability with RealSystem Server 8 , http://docs.real.com/docs/rtsp.pdf [8]: RealNetworks, RealServer Administration Guide, version 8.0 , http://service.real.com/help/library/guides/server8/realsrvr.htm [9]: RealNetworks, RealProducer Plus User's Guide, version 8.5 for Unix , http://service.real.com/help/library/guides/uproducerplus85/producer.htm [10]: RealNetworks, RealPlayer 8 Plus User Manual , http://service.real.com/help/player/plus_manual.8/rppmanual.htm [11]: Microsoft, Streaming Methods : Web Server vs. Streaming Media Server , http://www.microsoft.com/Windows/windowsmedia/en/compare/WebServVStreamServ.asp [12]: compression vido http://fr.wikipedia.org/wiki/Compression_video [13]: compression video, MPEG4 http://fr.wikipedia.org/wiki/MPEG-4
88
Conclusion
[14]: Comprendre la compression vido http://www.siteduzero.com/tutoriel-3-34107-comprendre-la-compression-video.html [15]: Rapid prototyping of a surveillance video compression system http://www.mathworks.com/company/newsletters/digest/sept03/prototyping.html
89

PFE1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PFE1

Загружено:

Авторское право:

Доступные форматы

Mmoire de Projet de Fin dtudes

Pour lObtention du Titre

Master Spcialis Rseaux et Systmes

Anne Universitaire 2009-2010

A tous ceux qui maiment.

Table des figures

Table des matires

Table des matires

Composantes dun systme de vidosurveillance ............................................................ 23

volution des systmes de vidosurveillance .................................................................. 28

Table des matires

2 Les mthodes de streaming ................................................................................................. 53

3 Le protocole RTSP .............................................................................................................. 55

Table des matires

3 tude du cas de RealNetworks ............................................................................................ 65

4 Plate-forme ralise ............................................................................................................. 81

Table des matires

Organisme daccueil : ONEP

Organisme daccueil : ONEP

Organisme daccueil : ONEP

2 Principales activits PLANIFIER

Organisme daccueil : ONEP

Figure 1 : Organigramme de lONEP

Organisme daccueil : ONEP

4 Architecture rseau de lONEP

Figure 2 : Architecture rseau de lONEP

Organisme daccueil : ONEP

Figure 3 : Organigramme de la DSI

Organisme daccueil : ONEP

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Figure 4 : Camras de surveillance

Etude thorique et analyse du projet de vidosurveillance

2 Composantes dun systme de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

3 volution des systmes de vidosurveillance

Figure 5 : Evolution du matriel de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Premire gnration : le tout analogique

Deuxime gnration : systme hybride

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Troisime gnration : le tout numrique IP

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

Etude thorique et analyse du projet de vidosurveillance

1 La reprsentation dune squence vido

Figure 6 : Le format YUV 4 :1 :1

Figure 7 : Introduction des pertes dans le processus de compression

Figure 8 : schma gnral dun codeur vido

3 Codage vido par estimation et compensation de mouvements

La structuration du flux vido

Figure 9 : Exemple dagencement dun GOP

Apprciation des erreurs de compression

Figure 10 : Allure typique dune courbe du rapport dbit / distorsion

4 Les images de rfrence

Figure 11 : Exemple dimage mosaque construite partir dun ensemble dimages

5 Les normes de compression excitantes