Pfe1

Transcript

Mémoire de Projet de Fin d’ Études Pour  l’Obtention du Titre  Master Spécialisé Réseaux et Systèmes Par Benjieda Hicham Encadré par Pr. Fakhri Youssef  Mr.Elbachraoui Mohamed Sujet « La mise en place d’une plateforme de vidéo surveillance logicielle, basée sur des technologies te chnologies de compression  vidéo récentes » Soutenu le 10 juillet 2010, devant le Jury : M. Jaafar ABOUCHABAKA, Faculté Faculté des Sciences Sciences de Kenitra, Kenitra, président M. Youssef FAKHRI, FAKHRI, Faculté des des Sciences de Kenitra M. Mohammed LAAROUSSI, LAAROUSSI, Faculté des Sciences Sciences de Kenitra Kenitra  Année Universitaire 2009-2010 Dédicace   A mes très chers parents,   Aucun mot et aucune langue ne pourra exprimer mes  sentiments envers vous.  A mes chères sœurs Naima sœurs  Naima et Fatimazahra   A mes chers frères 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 m’avez offert, je vous dis  .  A tous ceux qui m’aiment. Hicham Benjieda  Dédicace   A mes très chers parents,   Aucun mot et aucune langue ne pourra exprimer mes  sentiments envers vous.  A mes chères sœurs Naima sœurs  Naima et Fatimazahra   A mes chers frères 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 m’avez offert, je vous dis  .  A tous ceux qui m’aiment. Hicham Benjieda  Remerciements Il m’est agréable d’exprimer  ma reconnaissance auprès de toutes les personnes, dont l’intervention 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 précieuses et se s conseils pertinents qui ont été d’un appui considérable dans ma démarche. J’exprime J’exprime mes profonds respects et mes sincères gratitudes à M. Mohamed ELBACHRAOUI, m’avoir accueilli au sein de sa direction à l’ONEP. l’ONEP. de m’avoir Je tiens à remercier, M. Jaafar ABOUCHABAKA, pour son soutien et son apport tout au long de ces deux années d’études universitaires . Je saisis l’occasion pour remercier tous les membres du jury qui nous ont fait l’honneur  d’accepter de juger notre travail. Je ne saurais oublier dans mes remerciements tout le cadre professoral de la FSK, pour la formation qu’il nous a prodigué. Que tous ceux qui nous ont aidés, de près ou de loi n, trouvent ici l’expression de mes meilleurs sentiments. Résumé La vidéo surveillance est généralement déployé dans de nombreuses sociétés a fin de protéger des bien ainsi que des zones spécifique au sein de l’infrastructure d’une entreprise .Néanmoins ce genre de solution est bien souvent trop onéreuse en raison de l’investissement dans le matériel dédié mais également du fait qu’il est souvent nécessaire qu’un employé soit à la source du system pour superviser l’ensemble . Ce projet de fin d’études d’ études mené au sein de l’ONEP (Office National d’Eau Potable) consiste à développer sous linux une plate forme de vidéo surveillance logicielle, basée sur des technologies de compression vidéo récentes. Pour cela il faut développer du socle logiciel per mettant d’assurer les fonctions de bases d’un system de vidéo surveillance numérique, en utilisant des technologies de compression vidéo pour minimiser la taille du flux transféré et aussi bien enregistré. Suite à une comparaison entre les technologies de streaming existantes, nous avons opté pour « RealSystem » de « RealNetworks » qui offre une solution complète comprenant : le codeur, le serveur et le client. Mots clés : Vidéo surveillance, surveillance, Compression Compression vidéo, RTP (Real-time Transport Transport Protocol), RealSystem, RealSystem, RealNetwork, suivi. Table des figures Figure 1 : Organigramme de l’ONEP ...................................................................................... 16 Figure 2 : Architecture réseau de l’ONEP................................................................................ 17 Figure 3 : Organigramme de la DSI ......................................................................................... 18 Figure 4 : Caméras de surveillance .......................................................................................... 22 Figure 5 : Evolution du matériel de vidéosurveillance............................................................. 28 Figure 6 : Le format YUV 4 :1 :1 ............................................................................................. 39 Figure 7 : Introduction des pertes dans le processus de compression ...................................... 39 Figure 8 : schéma général d’un codeur vidéo ........................................................................... 40 Figure 9 : Exemple d’agencement d’un GOP .......................................................................... 42 Figure 10 : Allure typique d’une courbe du rapport débit / distorsion ..................................... 43 Figure 11 : Exemple d’image mosaïque construite à partir d’un ensemble d’images ............. 44 Figure 12 : Schéma de codage H.261 ....................................................................................... 46 Figure 13 : Transmission unipoint d’un flux ............................................................................ 50 Figure 14 : Transmission multipoint d’un 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…………………………………………………...6 2 Figure 22 : Initialisation des communications entre RealServer et RealPlayer ....................... 63 Figure 23 : Comparaison des technologies de streaming ......................................................... 65 Figure 24 : Enregistrement des présentations Real Media ....................................................... 66 Figure 25 : Enregistrement d’une présentation pour différentes largeurs de bande ................. 67 Figure 26 : Fonctionnement codeur/serveur dans le cas normal .............................................. 70 Figure 27 : Fonctionnement codeur/serveur dans le cas d’un pare -feu.................................... 71 Figure 28 : Phase initial de la communication client/serveur .................................................. 71 Figure 29 : Phase de transfert de données entre le client et le serveur ..................................... 71 Figure 30 : Schéma de multipoint ............................................................................................ 73 Figure 31 : Schéma de la back-Channel multicast ................................................................... 74 Figure 32 : Schéma du scalable multicast…………………………………………………….7 4 Figure 33 : Type de permission……………………………………………………………….77 Figure 34 : Préférences de transmission……………………………………………………...79 Figure 35 : Options de transport pour le protocole RTSP……………………………………79 Figure 36 : Utilisations des proxys…………………………………………………………...80 Figure 37 : Plate-forme réalisée………………………………………………………………81 Figure 38 : Création du sous réseau R1……………………………………………………....83 Table des matières Table des matières Table des figures ........................................................................................................................ 5 Table des matières ...................................................................................................................... 7 Introduction générale................................................................................................................ 11 Contexte du projet .................................................................................................................... 12 Chapitre 1 ................................................................................................................................. 13 Organisme d’accueil : ONEP ................................................................................................ 13 Historique de l’ONEP ...................................................................................................... 14 Principales activités .......................................................................................................... 15 Organigramme de l’ONEP ............................................................................................... 16 Architecture réseau de l’ONEP ........................................................................................ 17 Présentation de la DSI ...................................................................................................... 18 5.1 Organigramme de la DSI « Direction contrôle de gestion et Systems d’information »..................................................................................................................... 18 5.2 Missions de la DSI .................................................................................................. 19 Conclusion................................................................................................................................ 19 Chapitre 2 ................................................................................................................................ 20 1 2 3 4 5 Etude théorique et analyse du projet de vidéosurveillance ................................................. 20 1 Définition du domaine...................................................................................................... 21 1.1 Sécurité..................................................................................................................... 21 1.2 vidéosurveillance...................................................................................................... 22 2 Composantes d’un système de vidéosurveillance ............................................................ 23 2.1 Acquisition .............................................................................................................. 24 2.2 Transmission ........................................................................................................... 25 2.3 Compression............................................................................................................ 25 2.4 Traitement ............................................................................................................... 26 2.5 Archivage ................................................................................................................ 27 2.6 Affichage ................................................................................................................. 28 3 Évolution des systèmes de vidéosurveillance .................................................................. 28 3.1 Première génération : le tout analogique ................................................................. 29 3.2 Deuxième génération : système hybride ................................................................. 29 3.3 Troisième génération : le tout numérique IP ........................................................... 31 4 Vidéosurveillance IP ........................................................................................................ 32 Table des matières Architecture d’un réseau de vidéosurveillance intelligente ............................................. 35 5.1 Architecture centralisée........................................................................................... 35 5.2 Architecture distribuée ............................................................................................ 35 Conclusion................................................................................................................................ 36 Chapitre 3 ................................................................................................................................ 37 5 Compression vidéo ................................................................................................................. 37 La représentation d’une séquence vidéo .......................................................................... 38 1.1 Le format YUV 4 :1 :1 ............................................................................................. 38 2 La compression de données.................................................................................................. 39 La réduction de l’entropie .................................................................................... 40 2.1 3 Codage vidéo par estimation et compensation de mouvements ........................................... 41 3.1 La structuration du flux vidéo .............................................................................. 42 3.2 Appréciation des erreurs de compression............................................................. 43 4 Les images de référence ...................................................................................................... 44 5 Les normes de compression excitantes ............................................................................... 44 5.1 Les normes de l’UIT-T ......................................................................................... 45 5.1 Les normes de l’ISO-IEC ..................................................................................... 47 Conclusion................................................................................................................................ 48 Chapitre 4 ................................................................................................................................ 49 1 L’approche Streaming ............................................................................................................ 49 1 Notions sur la transmission des médias ............................................................................... 50 1.1 La transmission multipoint ................................................................................... 50 1.2 RTP : Le Protocole temps réel .................................................................................... 51 1.3 RTCP : Le Protocole de contrôle ................................................................................ 51 1.4 RSVP : Réservation des ressources............................................................................. 52 2 Les méthodes de streaming ................................................................................................. 53 2.1 Le temps réel sur un serveur web ......................................................................... 53 2.2 Le temps réel sur un serveur dédié ....................................................................... 54 3 Le protocole RTSP .............................................................................................................. 55 3.1 RTSP et HTTP ..................................................................................................... 55 3.2 Les formats de paquets de données ...................................................................... 55 3.2.1 Utilisation de RTP ............................................................................................ 56 3.2.2 Utilisation de RDT ........................................................................................... 56 3.2.3 Utilisation de TCP seul .................................................................................... 57 3.3 Les méthodes RTSP ............................................................................................. 57 Table des matières Conclusion................................................................................................................................ 59 Chapitre 5 ................................................................................................................................ 60 Solution et réalisation ............................................................................................................. 60 1 Introduction ......................................................................................................................... 61 1.1 Présentation de RealSyetem ..................................................................................... 61 2 Comparaison entre les technologies de streaming .............................................................. 63 2.1 Coût .......................................................................................................................... 63 2.2 Scalabilité ................................................................................................................. 64 2.3 Administration et sécurité ........................................................................................ 64 3 Étude du cas de RealNetworks ............................................................................................ 65 3.1 Le codeur de RealNetworks .................................................................................... 65 3.1.1 Fonctionnement de RealProducer .................................................................... 65 3.1.2 SureStream ....................................................................................................... 66 3.1.2 Realvideo.......................................................................................................... 67 3.1.2 Options de compression ................................................................................... 68 3.2 Le serveur de RealNetworks ................................................................................... 69 3.2.1 Conditions de fonctionnement ......................................................................... 69 3.2.2 Fonctionnement ................................................................................................ 69 3.2.3 Méthode de livraison des médias ..................................................................... 72 3.2.4 Le multipoint .................................................................................................... 73 3.2.5 Gestion de la bande passante............................................................................ 75 3.2.6 La Sécurité........................................................................................................ 75 3.3 RealPlayer ............................................................................................................... 78 3.3.1 Fonctionnement ................................................................................................ 78 3.3.2 Transport des données ...................................................................................... 78 3.3.3 Autres configurations ....................................................................................... 80 4 Plate-forme réalisée ............................................................................................................. 81 4.1 Schéma de la plate-forme réalisée........................................................................... 81 4.2 Principe de l’ARP Proxy ......................................................................................... 82 4.3 L’utilitaire ipchains ................................................................................................. 84 4.4 Configuration requises du noyau............................................................................. 84 4.4 Logiciels utilisés...................................................................................................... 85 4.4.1 Le serveur web apache ..................................................................................... 85 4.4.2 Fonctionnement ................................................................................................ 85 4.4.3 Configuration ................................................................................................... 86 Table des matières Conclusion................................................................................................................................ 86 Conclusion Générale ............................................................................................................... 87 Bibliographie ........................................................................................................................... 88 Introduction générale Introduction générale Le progrès en télécommunications numériques s’est conjugué au progrès calculatoire qui l’a précédé pour offrir la réalisation d’architectures complexes de systèmes communiquant entre eux dont la mise en liaison a permis de résoudre beaucoup de problèmes dans beaucoup de domaines. La vidéosurveillance a ainsi évolué depuis les simples systèmes analogiques indépendants vers le client-serveur analogique numérique et depuis le client serveur simple vers les architectures distribuées qui délivrent un résultat riche et pertinent déduit à partir de la fusion de plusieurs informations issues de plusieurs caméras. Ce progrès a aussi changé la manière dont on a pu exploiter nos systèmes classiques : la vidéosurveillance de nos jours ne répond pas seulement au problème de la sécurité mais elle aide aussi à dégager des statistiques sur le trafic routier sur des larges échelles, et des données de comportement de la clientèle d’un centre commercial sur la petite échelle pour  dorénavant assister à la prise des décisions ! La vidéosurveillance est dorénavant un domaine à part qui comporte des techniques et des objectifs totalement nouveaux. Il y a quelques années, on ne cite la vidéosurveillance que pour parler des systèmes de numérisations, des systèmes de codage et des techniques de capture du signal images. Mais aujourd’hui, de la représentation vers la transmission ou du traitement vers l’exploitation, le signal est dorénavant maitrisé sur le plan programmatique, et du coup tout a changé, et les axes de recherche et d’exploitation d’aujourd’hui se sont totalement transformés. Dans ce projet, le premier chapitre est consacré à l’ONEP : son historique, ses activités et son organigramme, le second chapitre traite l’étude générale du projet de vidéosurveillance, le troisième chapitre détaille l’aspect théorique des technologies de compression vidéo, et le quatrième chapitre je vais expliquer les méthodes de streaming utilisées et leur fonctionnement avant d’exposer la solution réalisée et ses résultats dans le dernier chapitre. 11 Contexte du projet Contexte du projet Environnement Ce projet comporte deux grandes parties :  La mise en place d’une plateforme de vidéo surveillance logicielle permettant d’assurer les fonctions de bases d’un système de vidéo surveillance numérique .  utilisation des technologies de compression vidéo récentes. L’environnement utilisé est le suivant : · Système d'exploitation : Windows server 2003 et Linux 12 Chapitre 1 Organisme d’accueil : ONEP  Historique   Principales activités   L’organigramme de l’ONEP   Architecture réseau de l’ONEP   Présentation de la DSI  Résumé  Ce chapitre introduit l’organisme d’accueil  :  Office National de  l’Eau Potable (ONEP) son historique, ses activités organigramme. et son  Chapitre 1 Organisme d’accueil : ONEP 1 Historique de l’ONEP L’Office National de l’Eau Potable a été créé en 1972 suite à la régie d’exploitation industrielle créée par le dahir du 19 juillet 1929 qui avait une activité très diversifiée durant le protectorat C’est le 1er établissement public qui a régi un contrat plan avec l’état prévoyant les obligations et les droits de chaque partie. Le statut de cet établissement est public, il vise l’intérêt général à caractère industriel et commercial. Sa création a permis un meilleur rapport qualité prix et l’éla rgissement du champ d’action au petit centre et au monde rural et la distribution de l’eau via les régies seulement lorsque les communes sont dans l’incapacité de le faire (l’ONEP à 200 centres en gérance). De plus, l’ONEP est doté de l’autonomie financière et de l’autonomie de gestion, placé sous la tutelle du ministère de l’équipement. L’objectif de l’ONEP est fixé par les missions principales dont elle est investie telles qu’elles sont définies par son dahir de création. Ses missions principales vont de la planification à la distribution de l’eau potable en  passant par les phases de l’étude, conception, réalisation (Travaux et prévisions financières), gestion et exploitation des unités de production et de distribution et du contrôle de la qualité des eaux (41 laboratoires) jusqu’à la protection de la ressource et ses derniers temps l’assainissement également. Sans oublier la direction de centre de formation aux techniques de l’eau interne à l’ONEP qui participe à la formation continue et aux diverses formations programmées pour assurer aux agents ONEP les performances requises. 14 Chapitre 1 Organisme d’accueil : ONEP 2 Principales activités  PLANIFIER L'approvisionnement en eau potable du Royaume et la programmation des projets.  ETUDIER L'approvisionnement en eau potable et assurer l'exécution des travaux des unités 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 distribuées et la pollution des eaux susceptibles d'être utilisées pour l'alimentation humaine.  ASSISTER En matière de surveillance de la qualité de l'eau  PARTICIPER aux études, en liaison avec les ministères intéressés, des projets de textes législatifs et réglementaires nécessaires à l'accomplissement de sa mission. 15 Organisme d’accueil : ONEP Chapitre 1 3 Organigramme de l’ONEP Figure 1 : Organigramme de l’ONEP 16 Organisme d’accueil : ONEP Chapitre 1 4 Architecture réseau de l’ONEP Figure 2 : Architecture réseau de l’ONEP 17 Organisme d’accueil : ONEP Chapitre 1 5 Présentation de la DSI 5.1 Organigramme de la DSI « Direction contrôle de gestion et Systems d’information » Figure 3 : Organigramme de la DSI 18 Organisme d’accueil : ONEP Chapitre 1 5.2 Missions de la DSI  MISSIONS          Assurer le suivi et le pilotage du système de contractualisation interne ; Piloter l’élaboration du budget et ses mises à jour ; Mettre en place et piloter un système de pilotage et de reporting à la Direction Générale; Migration d’une application de gestion de mobilité de personnelles vers l’ASP.net.   Assurer la préparation et le bon déroulement des sessions du Conseil d’Administra tion « CA » de l’office ; Mettre en place un système de contrôle des performances ; Participer à l’élaboration des contrats programmes. Conclusion Ce stage m’a été très bénéfique, car il m’a permis, d’une part d’avoir plus d’informations concernant tout qu’est en relation avec les réseaux et systèmes et aussi bien la programmation Orientée Objet et d’autre part, il m’a permis de reconnaître des gens, opérer des contacts et gérer des situations quasi nouvelles Et c’est bien en ce sens que nous consi dérons cette expérience très déterminante parce qu’elle nous a permis de mettre à l’épreuve notre savoir et perfectionner nos études et établir des communications écrites et orales avec les intervenants internes et externes de l’ONEP. 19 Chapitre 2 Etude théorique et analyse du  projet de vidéosurveillance  Définition du domaine   Composantes d’un système de  vidéosurveillance   Evolution des systèmes de  vidéosurveillance   Vidéosurveillance IP   Architecture d’un réseau de  vidéosurveillance intelligente  Résumé  Dans ce deuxième chapitre du présent rapport nous présentons une  étude théorique du projet de vidéosurveillance en commençant par une  définition du domaine de la vidéosurveillance et introduire les  composantes d’un système de vidéosurveillance , ensuite nous dévoilons  l’évolution  de ce système vers le IP et enfin nous parlons de  l’architecture d’un réseau de vidéosurveillance intellig ente. Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance 1 Définition du domaine 1.1 Sécurité La sécurité comprend deux aspects : la sécurité physique et la sécurité logique. La sécurité physique traite des mesures physiques prises pour sauvegarder le personnel, empêcher tout accès non autorisé aux équipements, installations, matériels et documents et à les protéger contre l'espionnage, le sabotage, les détériorations et le vol . Elle couvre donc la protection des personnes, des biens et des lieux. La sécurité logique cible la protection d’actifs informatiques d’une organisation et vise la mise en vigueur d’un ensemble de mesures de sécurité permettant d’assurer la confidentialité et l’intégrité des biens informatiques immatériels e t des opérations informatiques, et de les   protéger contre toute forme de menace accidentelle ou humaine. L’expression biens informatiques immatériels désigne les logiciels, les données et les réseaux. Avec l’informatisation et la cybercriminalité qu’elle entraîne, la sécurité logique, quoiqu’encore récente, gagne en importance. Alors que la sécurité physique est habituellement prise en charge par du personnel de sécurité (agents de sécurité, gardiens, services de police, etc.), la sécurité logique relève de spécialistes en technologies de l’information et administrateurs de systèmes informatiques. Toutefois, à l’heure où la protection physique et la surveillance reposent de plus en plus sur des technologies informatiques, sécurité physique et logique ont tendance à converger. Dans son application, la sécurité peut se répartir en cinq fonctions : protection civile, prévention, intervention, investigation et rétablissement. Depuis les événements du 11 septembre 2001 survenus aux États-Unis, on note un changement de paradigme en sécurité. On vise davantage la prévention d’incidents potentiellement catastrophiques plutôt que l’enquête après le fait. On cherche des méthodes et des technologies qui permettront de détecter les événements suspects et d’en prévenir les dommages sur les personnes, les biens, les lieux et les données. 21 Chapitre 2 1.2 Etude théorique et analyse du projet de vidéosurveillance vidéosurveillance La vidéosurveillance est un segment de l’industrie de la sécurité physique. Cette dernière inclut aussi le contrôle d’accès, la détection et le contrôle d’incendies, la gestion technique de bâtiments, les systèmes assurant la sécurité des personnes et la d étection d’intrusion. La vidéosurveillance consiste à surveiller à distance des lieux publics ou privés, à l'aide de caméras, le plus souvent motorisées, qui transmettent les images saisies à un équipement de contrôle qui les enregistre ou les reproduit sur un écran (Figure 4). Elle capte sur image les flux de personnes pour surveiller les allées et venues, prévenir les vols, agressions et fraudes, ainsi que pour gérer les incidents et mouvements de foule . Figure 4 : Caméras de surveillance Bien que ses premières utilisations remontent aux années 1950, la surveillance au moyen de systèmes de télévision en circuit fermé (TVCF) s’est vraiment développée à partir des années 1970, principalement au Royaume-Uni, pour lutter contre les activités terroristes. À l’heure actuelle, le Royaume-Uni constitue d’ailleurs la société « la plus surveillée » avec un nombre estimé à plus de quatre millions de caméras de surveillance déployées sur son territoire. L’implantation de la vidéosurveillance s’est intensifiée au cours des années 1990, mais elle a connu un développement 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 d’adoption de la technologie de vidéosurveillance. Celle -ci s’avère indispensable pour le suivi des opérations et la gestion des incidents de sécurité dans les lieux publics et privés. De plus, elle constitue un outil d’enquête i rremplaçable pour la résolution de crimes, de méfaits ou de 22 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance litiges. Toutefois, la preuve ne semble pas encore faite que la vidéosurveillance actuelle  permette de prévenir les incidents de sécurité ou qu’elle fasse chuter la criminalité. Un réseau de télévision en circuit fermé (TVCF) est un système vidéo qui transmet des images en boucle fermée. Autrefois uniquement analogiques, les réseaux TVCF intègrent maintenant des composantes numériques. L’accès au réseau de transmission peut, dans certains cas, se f  aire   par Internet. Seuls des utilisateurs détenant des droits d’accès au réseau peuvent accéder à l’information fournie par les caméras. Les activités de sécurité d’un réseau de TVCF sont : • Dissuasion • Observation • Surveillance • Collecte de renseignements • Évaluation d’un incident probable et intervention connexe • Évaluation d’un incident en cours et intervention connexe • Analyse judiciaire après l’incident • Analyse des éléments de preuve après l’incident Il existe trois types de vidéosurveillance : • Active : surveillance d’une aire pour appuyer le travail sur place d’agents de sécurité ou lors d’intervention d’urgence. • Passive : un employé surveille un petit nombre d’écrans de télévision en s’adonnant à d’autres tâches. • Enregistrement : permet de collecter des renseignements, à des fins d’enquête et de preuve. Les enregistrements sont conservés pendant une durée déterminée, dépendant des besoins et des limites des espac es d’archivages. 2 Composantes d’un système de vidéosurveillance Cette section présente, de façon sommaire, les différentes composantes matérielles et logicielles des systèmes de vidéosurveillance. Une description plus détaillée de l’infrastructure des systèmes de vidéosurveillance 23 Chapitre 2 2.1 Etude théorique et analyse du projet de vidéosurveillance vidéosurveillan ce Acquisition Il existe une panoplie de modèles de caméras répondant à différents besoins de surveillance. Elles sont analogiques ou numériques et peuvent être motorisées ou non. Plus spécifiquement, on retrouve les types de caméras suivants. Fixe : Pointée dans une direction unique, elle couvre une zone définie (une entrée, une    portion de stationnement, etc.). C’est la caméra de surveillance traditionnelle. Elle constitue un excellent choix lorsqu’on désire que la présence de la caméra, ainsi que sa direction de surveillance, soient visibles. PTZ (Pan-Tilt-Zoom) : Motorisée, elle peut être actionnée, manuellement ou  automatiquement, dans des mouvements panoramique/inclinaison/zoom. Elle sert à suivre des objets ou des individus se déplaçant dans la scène ou à zoomer sur des régions d’intérêt (par  exemple, sur une plaque d’immatriculation). * Dôme : Recouverte d’un caisson hémisphérique, ce qui la rend discrète et, dans certains modèles, résistante au vandalisme et aux intempéries. Elle peut être fixe ou mobile. Les versions motorisées couvrent une zone très large, grâce à leur balayage horizontal de 360° et de 180° à la verticale. Bien qu’en « tour de garde », elle puisse remplacer dix caméras fixes en  balayant l’aire à surveiller, elle n’observe qu’une seule direction à la fois. * Mégapixel : Offre une résolution plus élevée que les caméras standards, allant de 1 à 16 mégapixels. Elle permet soit de capter une image plus détaillée, soit de couvrir un plus large champ visuel, réduisant le nombre de caméras nécessaires pour couvrir une aire à surveiller. Lorsqu’utilisée avec un grand angle, elle possède un espace de visualisation allant généralement de 140° à 360°. Offrant la possibilité de zoomer de façon logicielle dans l’image, elle peut ainsi devenir une alternative à la caméra PTZ mécanique qui entraîne l’usure des pièces. Sa résolution élevée contribue à l’amélioration de la performance des algorithmes de détection et de reconnaissance exigeant un haut niveau de détails, telles que la lecture de plaques d’immatriculation 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 caméras infrarouges sont équipées de leur propre source de lumière IR, allumée lorsque le niveau d’éclairage chute sous un certain seuil. Des projecteurs IR séparés (lampe ou LED) peuvent 24 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance vidéosurveillan ce aussi être utilisés. Les caméras thermiques enregistrent le rayonnement de chaleur des objets. Elles ne requièrent aucune source d’illumination. * Panoramique : Grâce à une optique spéciale, elle offre 360° de visibilité avec une seule caméra. Elle permet un PTZ virtuel dans l’image. Les principales technologies panoramiques pour la surveillance sont le fisheye, la lentille à miroirs et la lentille panomorphe. Toutefois, la résolution de ces caméras est souvent insuffisante pour des analyses nécessitant un niveau de détail élevé. 2.2 Transmission La vidéo captée par les caméras de surveillance doit être transmise aux systèmes d’enregistrement, de traitement et de visionnement. Cette transmission peut se faire par câble (câbles coaxiaux ou à fibre optique, fils de cuivre torsadés) ou à travers l’air (signaux infrarouges, transmission radioélectrique). La vidéo filaire prédomine largement dans les systèmes de vidéosurveillance. Elle offre une plus grande bande passante et une meilleure fiabilité que les connections sans fil, à un coût inférieur. Cependant, la transmission vidéo sans fil s’impose parfois comme solution, par exemple dans le cas de surveillance de grands   périmètres où l’installation de câblage s’avérerait trop coûteuse, ou lorsque les zones à surveiller sont impossibles à rejoindre par câble. Qu’il transite par fil ou sans fil, le signal vidéo peut être analogique ou numérique. Encore aujourd’hui, la majeure partie des transmissions vidéo pour la surveillance sont analogiques. Néanmoins, les réseaux informatiques (LAN, WAN ou Internet) sont de plus en plus utilisés pour transporter la vidéo grâce au protocole IP. Les caméras IP peuvent se connecter directement sur ces réseaux, tandis que les flux vidéo émergeant de caméras analogiques doivent, au préalable, être numérisés par un encodeur , aussi appelé serveur vidéo , pour passer par les réseaux IP. 2.3 Compression La vidéo numérisée représente une grande quantité de données à transmettre et à archiver. L’envoi d’une séquence vidéo peut nécessiter jusqu’à 165 mégabits de bande passante et la vidéo d’une seule caméra pour une journée peut occuper sept gigaoctets d’espace disque. C’est pourquoi la vidéo de surveillance doit être compressée g râce à des codecs , algorithmes permettant de réduire la quantité de données en supprimant les redondances, par image ou entre les trames d’une séquence, ainsi que les détails imperceptibles à l’œil humain. Selon le type de compression, l’usage du processeur requis pour l’e xécution du codec est plus ou 25 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance vidéosurveillan ce moins intensif. Un compromis s’impose donc entre le taux de compression et les ressources du processeur qui sont accaparées. Il existe deux grands groupes de standards internationaux de compression : JPEG, créés par le Joint Photographic Experts Group, et MPEG, élaborés par le Moving Photographic Experts Group. Dans le premier groupe, on retrouve les formats JPEG pour les images fixes, et MJPEG pour les séquences vidéo. Le second groupe comprend les formats MPEG-1, MPEG-2, MPEG-4 MPEG-4 et H.264. À l’heure actuelle, MJPEG et MPEG -4 sont les standards les plus répandus en vidéosurveillance. Toutefois, avec les améliorations en qualité et efficacité (taux de compression, latence, résistance à l’erreur) qu’il apporte, H.264 devrait bientôt remplacer MPEG-4. MPEG- 4. En effet, sans affecter la qualité de l’image, l’encodeur  H.264 permet de réduire 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 vidéo plus en détail dans le chapitre suivant. 2.4 Traitement Les systèmes de gestion vidéo opèrent les traitements des images de vidéosurveillance, tels que la gestion des différents flux vidéo, le visionnement, l’enregistrement, l’analyse et la recherche dans les séquences enregistrées. Il existe quatre grandes catégories de systèmes de gestion vidéo. • Enregistreur vidéo numérique (DVR) : Appareil qui dispose d’un disque dur interne  pour l’enregistrement numérique de la vidéo et d’un logiciel intégré de traitement de la vidéo. Il n’accepte que les flux provenant de caméras analogiques, qu’il numérise. Les modèles récents permettent de visionner la vidéo à distance sur ordinateur. Encore très répandus, ils laissent toutefois peu à peu leur place aux systèmes supportant la vidéo IP de bout en bout. • Enregistreur vidéo hybride (HDVR) : Similaire à l’enregistreur numérique, mais accepte à la fois le branchement de caméras analogiques et IP. Il est possible de rendre hybrides  plusieurs modèles d’enregistreurs vidéo numériques par l’ajout d’un logiciel. • Enregistreur numérique réseau (NVR) : Conçu pour les architectures réseaux IP de vidéosurveillance, il ne peut traiter que les signaux vidéo provenant de caméras IP ou d’encodeurs. • Logiciel de vidéosurveillance IP : Solution purement logicielle de gestion de la vidéo sur un réseau IP. Dans le cas de systèmes de surveillance comportant peu de caméras, un navigateur Web peut suffire à gérer la vidéo. Pour de plus gros réseaux de vidéosurveillance, 26 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance vidéosurveillan ce un logiciel dédié de gestion vidéo doit être utilisé. Celui- ci s’installe sur un ordinateur  personnel ou un serveur. Plus complexe à installer, en raison des configurations nécessaires du serveur, il offre une plus grande flexibilité pour le choix et l’ajout de composantes au réseau de vidéosurveillance. Les logiciels de vidéosurveillance IP représentent une tendance forte en gestion vidéo, surtout dans les infrastructures comportant un grand nombre de caméras. Les plateformes ouvertes permettent d’intégrer facilement des caméras et composantes matérielles de différents manufacturiers. 2.5 Archivage La période d’archivage des séquences vidéo v arie selon les besoins de surveillance, allant de quelques jours à quelques années. En moyenne, les organisations conservent les preuves vidéo entre 30 et 90 jours. Le déploiement de vastes réseaux de caméras et l’utilisation de vidéosurveillance à haute résolution fait exploser les demandes pour les systèmes de stockage. Bien que le coût des supports d’enregistrement ait considérablement baissé dans les dernières années, l’archivage représente souvent une part importante des dépenses d’infrastructure en vidéosurveillance, en raison de la quantité toujours croissante de données vidéo à stocker. Les solutions de stockage sont de deux types : • Interne : Les disques durs intégrés aux enregistreurs vidéo numériques ou aux serveurs représentent la forme d’archivage la plus répandue. Elle peut offrir jusqu’à quatre téraoctets d’espace. Certaines caméras IP disposent même d’une carte mémoire ou d’un disque USB   permettant d’enregistrer des heures, voir des jours de vidéo. Les solutions internes d’archivage conviennent convi ennent bien pour les systèmes de vidéosurveillance de taille modeste, comprenant jusqu’à 50 caméras. • Rattaché : L’archivage se fait sur des appareils externes aux enregistreurs ou serveurs vidéo. De type NAS (  Network Attached Storage) ou SAN (Storage Area Network ), ), ces systèmes offrent un espace de stockage partagé entre les différents clients du réseau. Sur un système de stockage en réseau NAS, un fichier est archivé sur un même disque dur, alors qu’avec le réseau de stockage SAN, un fichier peut être sauvegardé en fragments répartis sur   plusieurs supports de stockage. Ces solutions d’archivage rattachées sont particulièrement avantageuses pour les grands réseaux de vidéosurveillance comportant un grand nombre de caméras. Bien que plus onéreuses que les le s systèmes internes d’archivage, ces solutions rattachées sont supérieures en termes d’extensibilité, de flexibilité et de redondance. 27 Chapitre 2 2.6 Etude théorique et analyse du projet de vidéosurveillance Affichage Une grande partie de la vidéo captée par les caméras de surveillance n’est jamais regardée. Elle est simplement archivée, au cas où un visionnement soit nécessaire suite à un incident. Traditionnellement, la vidéosurveillance a principalement servi comme outil d’enquête. Toutefois, dans plusieurs cas de surveillance, des agents de sécurité visionnent, en temps réel, les images provenant des caméras de surveillance. Sans nécessairement regarder toute la vidéo captée, les agents peuvent faire une revue périodique des différentes sources vidéo. La vidéo de surveillance peut être visionnée sur différents appareils. Dans de petites installations, il est possible de regarder la vidéo directement de l’enregistreur, simultanément à son enregistrement. Plus généralement, les images seront regardées à distance, sur un ordinateur ou, de façon mobile, sur un téléphone ou dispositif portable. Les grands centres d’opérations de sécurité, supervisant des centaines de caméras, utilisent souvent un mur d’écrans vidéo. Ceux-ci offrent une grande surface de visionnement et permettent d’afficher différents flux vidéo. 3 Évolution des systèmes de vidéosurveillance La transition numérique en vidéosurveillance s’est opérée en plusieurs étapes. Amorcée avec l’apparition de l’enregistreur numérique, elle se poursuit vers une conversion totale à l’infrastructure IP, où la vidéo est transmise sur réseau intranet ou Intern et de la caméra à l’écran de visionnement. Dans ce passage, l’on retrouve plusieurs systèmes hybrides, intégrant composantes analogiques et numériques. La figure ci-dessous présente les jalons importants qui ont marqué l’évolution vers la vidéosurveillance intelligente sur réseau IP. Figure 5 : Evolution du matériel de vidéosurveillance 28 Chapitre 2 3.1 Etude théorique et analyse du projet de vidéosurveillance Première génération : le tout analogique Dans le réseau TVCF analogique traditionnel, des caméras analogiques sont connectées par câbles coaxiaux (un câble par caméra) aux écrans de surveillance et, pour des fins d’archivage, à un magnétoscope qui enregistre la vidéo sur cassette. Un multiplexeur peut être utilisé pour grouper les flux vidéo de plusieurs caméras en un seul signal composite qui est transmis au magnétoscope ou à un moniteur analogique. Il permet d’afficher quatre, neuf ou 16 signaux vidéo sur un même écran, ou d’enregistrer ceux -ci sur un même système d’archivage. Aucune compression n’est effectuée sur les signaux vidéo. Avec un magnétoscope conçu à cet effet, l’enregistrement à taux de trame (   frame rate) réduit permet d’économiser de l’espace sur la bande vidéo, selon les besoins de surveillance. • Avantages - Les systèmes analogiques sont très fiables - Simple à utiliser, ils ne requièrent pas de compétences informatiques. • Inconvénients - La qualité de la vidéo est inférieure à celle des systèmes numériques. - Il faut changer les cassettes fréquemment (aux trois jours ou plus). - Nécessite un nettoyage et un entretien régulier des magnétoscopes. - La qualité de la vidéo enregistrée se détériore avec le temps. - Ne permet pas le visionnement à distance, comme sur les réseaux numériques. - Ce sont des systèmes propriétaires. 3.2 Deuxième génération : système hybride Le remplacement du magnétoscope à cassette par un enregistreur numérique (DVR) représente la première étape de la transition numérique en vidéosurveillance. Apparus dans les années 90, les enregistreurs numériques archivent la vidéo sur des disques durs. Comportant souvent plusieurs entrées vidéo, l’enregistreur numérique remplace à la fois le multiplexeur et le magnétoscope analogique. Les modèles récents sont équipés d’un p ort Ethernet, permettant la connexion à un réseau et l’accès à distance à la vidéo, soit en temps réel, soit à partir de l’enregistrement. Les transmissions vidéo se font sous protocole IP à partir de l’enregistreur  29 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance numérique. Ils permettent la transition vers un système hybride de vidéosurveillance sur réseau IP, tout en conservant les caméras analogiques. L’enregistreur numérique hybride (HDVR), quant à lui, peut recevoir à la fois les flux vidéo de caméras analogiques et IP. Il représente une solution efficace pour moderniser un système de vidéosurveillance en profitant des avantages des nouvelles caméras IP, tout en conservant les caméras analogiques existantes en place. Alors qu’on estime que 95 % des caméras sont encore analogiques, les enregistreurs numériques et les enregistreurs numériques hybrides sont des technologies très répandues. • Avantages - Aucune cassette à changer. - La vidéo archivée est de meilleure qualité, sans détérioration avec le temps. - Possibilité de chercher rapidement dans les enregistrements vidéo. - Surveillance vidéo et opération du système à distance à partir d’un PC. • Inconvénients : - Concentration des tâches de numérisation, compression vidéo, enregistrement et réseautage dans la même machine. - L’enregistreur numérique est un appareil propriétaire, ce qui augmente les coûts de maintenance et de mise à jour. - Le nombre d’entrées vidéo de l’enregistreur numérique (souvent un multiple de 16) contraint l’ajout de caméras. Les encodeurs vidéo, aussi appelés serveurs vidéo, sont utilisés pour convertir les signaux provenant de caméras analogiques et les transmettre en flux IP sur un réseau via un commutateur. Tout en conservant les caméras analogiques, ils permettent un passage presque complet à l’infrastructure réseau pour la vidéosurveillance, puisque que la vidéo est constamment transmise sous le protocole IP à travers le réseau. Les encodeurs vidéo peuvent être utilisés avec l’enregistreur vidéo réseau (NVR). Ceux-ci ne peuvent traiter et enregistrer que des flux vidéo IP. Ils sont offerts sous une plateforme ouverte (un ordinateur muni d'un logiciel de gestion vidéo) ou dans un matériel propriétaire dédié. Sous cette dernière forme, l’enregistreur vidéo réseau se compare à un enregistreur numérique hybride, excepté qu’il nécessite l’usage d’encodeurs pour opérer avec des caméras analogiques. 30 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance • Avantages - Utilisation d’ordinateurs et de matériel standards de réseau pour l’enregistrement et la gestion de la vidéo. - Possibilité d’enregistrer à l’extérieur du site de surveillance (par exemple, centralisation des enregistrements). - Architecture distribuée qui offre flexibilité, extensibilité (peut ajouter une caméra à la fois) et redondance (en cas de bris ou pannes). • Inconvénients - Gourmand en bande passante, si l’enregistrement est fait hors du site de surveillance (par ex., de façon centralisée). - Si le réseau tombe en panne, l’enregistrement peut être interrompu. - Si l’enregistrement centralisé n’est pas requis, l’utilisation d’enre gistreurs vidéo réseau est souvent plus coûteuse que celle d’enregistreurs numériques. - Nécessitent des calculs complexes pour déterminer le nombre de flux vidéo  pouvant être supportés par le serveur, la quantité d’espace disque nécessaire à l’enregistrement, le taux de trames, le niveau de compression et d’autres facteurs liés aux capacités du réseau. 3.3 Troisième génération : le tout numérique IP Au sens strict, un système de vidéosurveillance est complètement IP, lorsque toutes ses composantes sont numériques et toutes les transmissions sont effectuées sous le protocole IP. Ces réseaux comprennent donc des caméras réseau, aussi appelées IP. Il s’a git de caméras intégrant leur propre encodeur. Celles-ci sont reliées, via des commutateurs réseau, à des serveurs (ordinateurs personnels), munis d’un logiciel de gestion vidéo. L’enregistrement est fait sur serveur ou sur des enregistreurs vidéo réseau propriétaires. Les traitements sont effectués sur le serveur ou dans les périphériques. Toutefois, beaucoup de gens considèrent qu’un système de vidéosurveillance dont la vidéo est transmise sous protocole IP à partir des encodeurs, constitue un système réseau IP. Dans ces systèmes, les caméras peuvent être analogiques, en autant qu’elles soient reliées à des encodeurs. Plus de détails sur la vidéosurveillance IP et, notamment ses avantages et inconvénients, sont fournis dans la section suivante. 31 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance 4 Vidéosurveillance IP Depuis deux ans, le marché de la vidéosurveillance migre de la vidéo analogique à la vidéo IP. Cet essor de la vidéosurveillance réseau est favorisé par le perfectionnement des  processeurs, la baisse des coûts de stockage et l’amélioration des a lgorithmes de compression. Bien que cette transition s’observe, elle ne fait que débuter et il est difficile de prédire à quel rythme le « tout IP » prendra le dessus sur les technologies analogiques en vidéosurveillance. Les caméras constituent le facteur de résistance. En effet, il est estimé que 95 % des 40 millions de caméras installées à travers le monde sont encore analogiques. De plus, encore aujourd’hui, seulement un acheteur sur quatre choisit des caméras IP. Pourtant, les caméras IP offrent des avantages techniques sur les caméras analogiques, tels qu’une meilleure qualité d’image, une résolution plus élevée et de l’intelli gence embarquée. Le coût élevé des caméras IP, environ le double des caméras analogiques, reste le principal frein à l’achat. Avec les améliorations apportées par les manufacturiers aux enregistreurs vidéo et l’existence d’enregistreurs vidéo hybrides, le règne des caméras analogiques pourrait se prolonger encore quelques années. Les réseaux IP de vidéosurveillance de dernière génération présentent les caractéristiques suivantes : • Ils sont numériques de A à Z : caméras, réseaux, enregistrement, accès. • Ils peuvent inclure différents types de caméras : intelligente, mégapixel, sans fil, PTZ, panoramiques, etc. • Ils utilisent du matériel non propriétaire. • Ils fonctionnent avec des serveurs distribués et multiplateformes. • La sauvegarde se fait sur réseau (NVR). • On peut y accéder à distance, n’importe où, n’importe quand, soit d’un centre de contrôle, via Internet ou un réseau LAN ou WAN, sur un cellulaire ou un assistant numérique personnel, etc. • Ils peuvent inclure de l’analytique vidéo. La vidéosurveillance sur réseau IP offre de nombreux avantages. Elle repose sur une infrastructure plus souple que la vidéo analogique, combinant transmission câblée et sans fil. De plus, l’infrastructure réseau est rapide et facilement extensible. Il n’y a pas de limite au nombre de caméras qui peuvent s’y ajouter. Considérant que les systèmes actuels peuvent 32 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance facilement comporter entre 400 et 500 caméras, comparativement à 25 à 30 il y a quatre ans, cette facilité d’étendre le réseau de vidéosurveillance est très attrayante lorsqu’on pense déployer un nouveau système. Pour les installations étendues comportant de grandes distances entre les caméras et les systèmes d’enregistrement, les caméras IP deviennent un choix avantageux, car le coût du câble coaxial est très élevé. C’est pourquoi les caméras IP sont surtout déployées pour la surveillance d’institutions, telles que les établissements scolaires, les campus de grandes entreprises, les municipalités et les bases militaires. Les caméras IP apportent de nombreux bénéfices techniques. Par exemple, les caméras mégapixel IP offrent des avantages indéniables au niveau de la vidéosurveillance. Ces caméras, présentant une résolution nettement supérieure à celle des caméras analogiques, ont le potentiel de résoudre plus de crimes. Bien que son coût soit élevé, une seule caméra mégapixel peut souvent remplacer plusieurs caméras. Les caméras intelligentes, intégrant des processeurs, apportent des gains techniques aux systèmes de vidéosurveillance de nouvelle génération. Elles permettent de distribuer les calculs pour les traitements d’analytique vidéo et, ainsi, de ménager la bande passante en ne transmettant que les données pertinentes pour la sécurité. L’architecture ouverte des réseaux de vidéosurveillance IP permet de combiner le matériel de différents manufacturiers. Il est ainsi possible de sélectionner les composantes les plus adaptées à son application de surveillance. De plus, l’architecture IP facilite l’intégration de différents systèmes de sécurité (vidéo, alarmes de feux, contrôle d’accès, etc.). La configuration de ces réseaux avec redondance, tant au niveau de la transmission que de l’archivage, assure une meilleure fiabilité. Dans un réseau entièrement analogique, le mauvais fonctionnement d’une caméra ou d’un enregistre ur peut signifier une perte définitive de vidéo. De plus, l’archivage sur réseau, dont les coûts ne cessent de baisser, permet de conserver des années de vidéo plutôt que quelques jours ou semaines avec les magnétoscopes ou enregistreurs numériques. Il suf fit d’ajouter des disques durs pour augmenter la capacité de stockage. Dans ces réseaux, la transmission numérique de la vidéo, de bout en bout du système, réduit les pertes de qualité qu’occasionnent les conversions d’analogique à numérique. De plus, par des traitements logiciels intelligents, il est possible de filtrer les événements pertinents dans la vidéo et de ne transmettre que les métadonnées les décrivant. Ceci permet d’économiser de la bande passante. Ces métadonnées servent ensuite à indexer le contenu vidéo pour permettre des recherches plus performantes dans les séquences captées. Il est aussi possible, dans ces réseaux, de transmettre des commandes aux caméras, en fonction de la vidéo traitée. Par exemple, en réponse à un événement suspect, le logiciel de gestion vidéo pourra activer automatiquement le zoom optique ou numérique sur une caméra du 33 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance réseau pour un suivi plus précis de la situation. Le passage à la vidéosurveillance IP comporte tout de même certains inconvénients. Par exemple, dans l e cas d’infrastructures analogiques existantes, refaire tout le filage réseau peut représenter un coût élevé. Dans ce cas, l’utilisation d’encodeurs pour numériser les signaux analogiques permet de conserver les caméras en place et d’implanter un réseau hybride. De plus, la technologie des enregistreurs numériques a beaucoup progressé, afin de rester compétitive. Les enregistreurs numériques offrent désormais plusieurs avantages comparables aux technologies sur réseaux IP : accès à distance, capacité de gérer un grand nombre de caméras, intégration avec les autres systèmes (contrôle d’accès, détection d’intrusion, systèmes de points de vente, etc.), capacité analytique. Pour de   petites installations de vidéosurveillance, l’utilisation de caméras analogiques avec enregistreurs numériques offre donc un excellent rendement, à des coûts moindres que la vidéo IP. Bien que sur le plan technologique, les réseaux IP de vidéosurveillance offrent de nombreux avantages, le déploiement de ceux-ci pose certains problèmes organisationnels. Le   premier réside dans l’installation. La plupart des intégrateurs et installateurs en vidéosurveillance sont issus du secteur de la sécurité physique. Or, l’installation de systèmes de vidéosurveillance sur réseau IP requiert des compéte nces en technologie de l’information,   particulièrement en réseautique. Encore peu d’intégrateurs et installateurs de vidéosurveillance sont spécialisés dans ce domaine. Le second problème touche à la gestion de ces systèmes. Une fois installés, qui, dans l ’organisation, est responsable du système de vidéosurveillance : le personnel de sécurité physique ou les services informatiques ? Le flou qui existe encore sur cette question dans les organisations retarde bien souvent le passage à la vidéosurveillance IP. Finalement, passer d’un réseau de télévision en circuit fermé à un système de vidéosurveillance, dont les données transitent par les réseaux Ethernet ou Internet, soulève les questions de sécurité informatique. Évidemment, ceci nécessite de mettre en place les mécanismes de sécurité adéquats pour protéger la vidéo de surveillance. Aussi, le bon fonctionnement de la vidéosurveillance devient tributaire de la fiabilité du réseau. À cet égard, l'intégration de la vidéosurveillance sur réseaux IP suivra peut-être celle de la téléphonie IP, qui est maintenant bien répandue. 34 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance 5 Architecture intelligente d’un réseau de vidéosurveillance Les systèmes de vidéosurveillance intelligente peuvent être déployés selon deux grands types d’architecture, soit centralisée ou distribuée. L’une comme l’autre opèrent des traitements intelligents pour extraire des données sur les images vidéo et peuvent, au besoin, commander le déplacement d’une caméra PTZ pour opérer une surveillance active. 5.1 Architecture centralisée Dans une architecture centralisée, tous les traitements intelligents sont concentrés en un même endroit. Dans les systèmes traditionnels, c’est l’enregistreur numérique qui récoltera tous les flux vidéo pour en faire l’analyse. Pour les infrastructures en réseau, c’est un serveur  informatique (un PC) qui opérera les traitements analytiques. L’analyse vidéo nécessite une grande puissance de calcul qui monopolise une part importante des ressources du processeur. Comme ils doivent aussi gérer l’encodage, l’enregistrement et le visionnement des flux vidéo, les enregistreurs numériques et serveurs ne peuvent accomplir des tâches d’analytique vidéo que sur un nombre restreint de caméras. De plus, dans le cas des systèmes de vidéosurveillance sur réseau, la transmission de tous les flux vidéo en un point centralisé consomme beaucoup de bande passante. Le réseau informatique doit pouvoir soutenir ce trafic. 5.2 Architecture distribuée Comme son nom l’indique, l’architecture distribuée répartit les traitements intelligents dans les différents nœuds du système de vidéosurveillance. Ainsi, les calculs nécessaires à l’analytique pourront être faits en périphérie, sur des caméras intelligentes dotées de processeurs, les encodeurs ou dans les commutateurs réseau. Dans cette architecture, plutôt que d’envoyer des flux vidéo à l’enregistreur numérique ou à un ordinateur central, seules des métadonnées extraites sur la vidéo sont transmises. L’intelligence peut aussi être partagée entre les périphériques et l’unité centrale de traitement. Cette infrastructure aide à diminuer  les coûts de câblage et la bande passante requise dans un réseau de vidéosurveillance. De plus, elle offre une meilleure extensibilité, puisque l’ajout de caméras n’est pas nécessairement limité par la puissance de calcul de l’enregistreur numérique ou du serveur. 35 Chapitre 2 Etude théorique et analyse du projet de vidéosurveillance Conclusion Ce chapitre a présenté le sujet et les contraintes qui se posent. Nous étudions dans ce qui suit l’aspect théorique de compression vidéo qu’est une composante importante d’un système de vidéosurveillance dans le but d’apporter des solutions théoriques qui se prêtent bien à une implémentation pratique. 36 Chapitre 3 Compression vidéo  La représentation d’une séquence vidéo   La compression de données   Codage vidéo par estimation et  compensation de mouvements   Les images de référence   Les normes de compression existantes  Résumé  Dans ce troisième chapitre nous abordons  l’axe principal de notre  service qui est la compression vidéo. Le traitement de la vidéo    passe par  des étapes justifiées soit par les défauts de l’organe  humains relatifs ou par les propriétés statistiques de l’image    pour cela nous allons développer dans ce chapitre les normes de  compression vidéo existantes. Chapitre 3 Compression vidéo 1 La représentation d’une séquence vidéo Une séquence vidéo brute est une suite d'images fixes, qui peut être caractérisée par trois principaux paramètres : sa résolution en luminance, sa résolution spatiale et sa résolution temporelle. La résolution en luminance détermine le nombre de nuances ou de couleurs possibles pour un pixel. Celle-ci est généralement de 8 bits pour les niveaux de gris et de 24 bits pour les séquences en couleurs. La résolution spatiale, quant à elle, définit le nombre de lignes et de colonnes de la matrice de pixels. Enfin, la résolution temporelle est le nombre d'images par seconde. La valeur de ces trois paramètres détermine l'espace mémoire nécessaire pour stocker chaque image de la séquence. Cet espace mémoire est caractérise par le débit, qui est le coût de stockage pour une seconde (capacité mémoire nécessaire pour stocker une seconde de vidéo). Par exemple, une séquence ayant une résolution de 720 par 576 pixels, un codage des couleurs sur 24 bits, et une fréquence de 25 images par seconde, nécessitera un débit de 137 Mb/s (mégabits par seconde). Le débit d'une séquence vidéo brute est très élevée compare aux débits 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 réduire ce débit est de sous-échantillonner les composantes de chrominance de la séquence. L'œil humain étant plus sensible aux variations de luminance que de chrominance, on utilise l'espace de représentation de couleurs YUV, en sous-échantillonnant les composantes U et V. Historiquement et techniquement, le format YUV est utilisé pour la transmission des signaux vidéo analogiques couleurs. Dans ce sigle, Y représente 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 vidéo. Mais surtout la partie Y (luminescence) permet une parfaite compatibilité avec les anciens équipements en noir et blanc, ce qui a permis le déploiement de la diffusion couleur alors que la totalité des foyers étaient alors équipes de téléviseurs noir et blanc. Dans le format YUV 4 :1 :1, les composantes de chrominance sont réduits à la moitié de la résolution 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 vidéo Figure 6 : Le format YUV 4 :1 :1 Ce sous-échantillonnage correspond à une réduction de la redondance psycho-visuelle. Dans la suite, nous étudierons les techniques permettant de réduire les redondances spatiales et temporelles. 2 La compression de données Dans cette section nous allons nous intéresser aux techniques utilisées pour compresser le signal vidéo en utilisant la redondance spatiale. Le but est de réduire le débit de la séquence vidéo à compresser, tout en minimisant les erreurs visibles. La compression de données permet de réduire la quantité d'information, en modifiant son mode de représentation. 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 première permet de retrouver l'information initiale après décompression, tandis que la deuxième n'en restituera qu'une approximation. Dans le cas de la compression d'images naturelles (par opposition aux images de synthèse), la compression sans pertes est insuffisante, et l'introduction de pertes dans le processus de compression permet d'obtenir de meilleurs résultats sans empêcher l'interprétation du contenu visuel (voir Figure 7). 39 Chapitre 3 Compression vidéo Les normes vidéo actuelles utilisent un système de codage hybride avec compensation du mouvement basé sur des blocs et réduction de l'entropie par transformée (voir Figure 8), que nous allons étudier maintenant. 2.1 La réduction de l’entropie L'entropie (H(X)) d'une image est la quantité moyenne d'informations apportée 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 obéit à une loi uniforme, alors qu'elle sera plus faible si la distribution est concentrée autour de quelques valeurs seulement. Le but de la réduction de l'entropie est par conséquent de transformer la distribution des valeurs de l'information à transmettre. Figure 8 : schéma général d’un codeur vid éo 40 Chapitre 3 Compression vidéo La réduction de l'entropie est compostée de trois étapes, tel que la décorrélation, la quantification, et le codage entropique. La décorrélation est opérée par un codage par transformée. Parmi les transformations utilisées pour la compression d'images, on peut citer la transformation de Kahrunen-Loève (KLT), la transformée en cosinus discrète (DCT) et les transformées en ondelettes discrètes (DWT). La KLT est la transformée optimale, mais comporte l'inconvénient d'être dépendante des données, puisque composée des vecteurs propres de la matrice de covariance de l'image. Cette dépendance induit un coût de calcul élevé, que ne présentent pas les deux autres transformées. Dans le cas des images naturelles, les pixels voisins présentent une forte corrélation, de ce fait, les capacités de la DCT sont très proches de celle de la KLT tout en réduisant la complexité de calcul. La DWT a l'avantage de produire une matrice contenant beaucoup de zéros, ce qui a la propriété d'alléger les calculs lors d'opérations matricielles. Elle peut donc être appliquée à l'image entière, contrairement à la DCT qui est appliquée par blocs pour limiter les calculs. L'application d'une transformée sur une image naturelle permet d'obtenir des composantes dont la variance est concentrée sur les composantes de basses fréquences. L'image ainsi transformée est ensuite quantifiée puis compressée à l'aide d'un codeur entropique. 3 Codage vidéo par estimation et compensation de mouvements La technique que nous allons maintenant étudier permet d'exploiter les redondances temporelles, fortement présentes dans une séquence vidéo naturelle. La compression par compensation de mouvement consiste pour une image, à ne coder que les erreurs résultantes de l'estimation de mouvement faite à partir d'une image de référence. 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 complète. Les erreurs résiduelles, qui consistent en la différence entre l'image prédite et l'image compensée, sont donc ajoutées aux vecteurs de mouvement. Cette compensation et ces erreurs sont ensuite transformées, quantifiées et codées, avant d'être transmises. En plus d'être codées et transmises, elles subissent également une quantification inverse et une transformation inverse. Le but de décoder les images à l'intérieur du processus d'encodage, est d'effectuer les prédictions à partir des images décodées, afin de travailler avec les mêmes informations que le décodeur cible. 41 Chapitre 3 Compression vidéo 3.1 La structuration du flux vidéo Ce codage prédictif rend les images interdépendantes, puisque lors du décodage, il est nécessaire d'avoir l'image précédente pour décoder l'image en cours. Cette dépendance est gênante si l'on souhaite naviguer de manière aléatoire, le décodage de tout le début de la séquence étant nécessaire, ou si une image est perdue lors d'un transfert, le décodage du reste de la séquence é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 (transformée, quantification et codage), tandis que le mode inter utilise la compression temporelle. Les commutateurs présents dans la Figure 2.3 page cicontre représentent le choix du mode de codage. Les images sont regroupées en GOP (Group Of Pictures) composées de trois types d'image. Les images « I » sont codées en mode intra, et sont donc indépendantes mais demandent plus de ressources. Les images « P » sont codées par compensation de mouvement à partir de la dernière image « I » ou « P ». Les images « B » sont prédites bi directionnellement à partir d'images « I » ou « P ». Un GOP débute toujours par une image « I », qui constitue l'image-clé du GOP. Cette image, est ensuite suivie d'image « P », intercalées par des images de type « B » (voir Figure 2.4). La fréquence des images de type « P », et la taille du GOP sont des paramètres qui influeront sur le taux de compression, et sur le temps de décodage. En effet, plus le GOP sera long, et plus la dépendance 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 délai de décodage additionnel, puisque les images « P » postérieures doivent être décodées avant que les images B antérieures puissent être décodées. Figure 9 : Exemple d’agencement d’un GOP Le choix du mode de codage peut être fait sur les images entières (déterminé 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 vidéo processus de compensation de mouvement peut s'avérer inefficace, dans ce cas, le bloc est codé en utilisant le mode inter. 3.2 Appréciation des erreurs de compression La quantification est l'opération qui introduit les pertes. Ces pertes sont mesurées par l'erreur quadratique moyenne (EQM) qui est calculée à partir de l'image originale et de l'image reconstruite. De cette EQM, on dérive une autre grandeur, plus significative, appelée peak signal to noise ratio (PSNR). Cette grandeur est un gain qui s'exprime en décibels, et s'obtient ainsi : Cette mesure de la distorsion couplée avec le débit de la séquence résultante permet d'apprécier 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 général, d'obtenir la meilleure fidélité (ou la plus grande distorsion) compte tenu de la capacité du canal de transmission, qui détermine la contrainte de débit. Cette optimisation peut être faite à l'aide des techniques de minimisation de Lagrange fondées sur la théorie du débit-distorsion Figure 10 : Allure typique d’une courbe du rapport débit / distorsion 43 Chapitre 3 Compression vidéo 4 Les images de référence On appelle image de référence, l'image qui va être utilisée pour prédire une image et estimer le mouvement à compenser. Cette image peut être simplement une image précédemment codée dans la séquence. Dans les dernières normes, de nouvelles images sont utilisées : les objets mosaïques. Un objet mosaïque contient l'ensemble de l'information disponible sur un objet physique donné. Il est souvent utilisé sous la forme d'objet mosaïque plan (voir Figure 11 ) appelé MOP (Mosaic Object Plane) qui est construit à partir d'une séquence de vues de l'objet considéré. Le principe de construction consiste à recaler les images (ou portions d'images) traitées dans le référentiel de l'objet mosaïque . Ces images peuvent être utilisées pour représenter sur une seule image la totalité d'une scène. Cette mosaïque est généralement plus grande qu'une image de la séquence. Figure 11 : Exemple d’image mosaïque construite à partir d’un ensemble d’images 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 spécifié dans ce standard en ce qui concerne le processus de construction. 5 Les normes de compression excitantes Les codeurs vidéo actuellement normalisés (familles H.26x ou MPEG-x) utilisent tous le même principe de base dont la connaissance aide à comprendre à la fois leurs potentialités et limites d’utilisation. Cette section décrit les principaux standards normalisés à l’UIT -T et à l’ISO/IEC. 44 Chapitre 3 Compression vidéo 5.1 Les normes de l’UIT-T Première norme vidéo approuvée en 1993, H.261 vise les applications de visiophonie pour le réseau RNIS à des débits multiples de 64 kbit/s. Les formats d'image traités sont le QCIF (144x176 pixels) et le CIF (288x352 pixels). La fréquence image de base est 29.97 Hz mais peut être réduite (sous-multiples). Le schéma de codage (Figure 12) est constitué de plusieurs modules : l’estimation et la compensation de mouvement, le calcul des résidus, la transformée espace-fréquence (DCT), la quantification et le codage entropique. Le codeur intègre également un décodeur qui effectue les opérations inverses. Pour la compensation de mouvement chaque MB peut être affecté d'un vecteur de mouvement dont les dimensions horizontales et verticales ne peuvent excéder +/- 15 pixels. Le vecteur de mouvement estimé sur la luminance pointe un MB inclus dans l'image précédemment reconstruite. Les chrominances sont prédites par le même vecteur mouvement dont les coordonnées ont été divisées par 2 et arrondies à l'entier le plus proche. Cette prédiction correspond à la construction d'une image P. Le filtrage, optionnel, est un filtre spatial à deux dimensions non récursif travaillant au niveau pixel sur des blocs de taille 8x8 intervenants dans la boucle de codage. Le flux vidéo est structuré en quatre niveaux : image, groupe de blocs (GOB), macrobloc (MB) et enfin bloc. 45 Chapitre 3 Compression vidéo Figure 12 : Schéma de codage H.261 H.263 est une norme de codage vidéo pour la communication vidéo à très bas débit dont la première version fut adoptée en 1995. Elle vise les applications de visiophonie et de visioconférence sur RTC et RNIS. Cette norme repose sur les principes mis en place par la recommandation H.261. Les formats d’images 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 précision au demi-pixel, ce qui améliore grandement la qualité de la vidéo en réduisant fortement les effets dits "moustiques". L'utilisation d'image B est désormais possible. La version 2 de la recommandation H.263 (1998), souvent appelée H.263+, met en œuvre douze options supplémentaires et permet désormais de définir des formats et fréquences d'image personnalisés. Les caractéristiques de vidéo (Taille fréquence) sont transmises dans le flux vidéo. Les options ajoutées améliorent fortement la qualité et la robustesse aux erreurs. La dernière version de H.263 (2000), appelée H.263++, ajoute trois 46 Chapitre 3 Compression vidéo options et une spécification à la version antérieure. Outre l'amélioration en termes de qualité et de taux de compression, elle prend mieux en compte la transmission vidéo temps réel sur des réseaux à qualité de service non garantie (IP et mobiles). 5.1 Les normes de l’ISO-IEC Première norme de compression vidéo développée par l’ISO/IEC, MPEG-1 vise une qualité équivalente au VHS (format SIF ou CIF) à un débit de 1,5 Mbps. Cette norme a été construite sur la base de H.261 dont elle reprend les principes en les améliorant : compensation de mouvement au 1⁄2 pixel, images de types I (Intra), P (Prédite) ou B (Bidirectionnelle), quantification optimisée par l’utilisation de matrices de quantifica tion, prédiction spatiale du coefficient DC pour les images I.MPEG-1 n’est plus guère utilisée aujourd’hui si ce n’est en compression du son avec le format MP3 pour le stockage de la musique La norme MPEG-2 a été définie pour les applications liées à la TV numérique, à 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 télévisuelles : traitement des formats entrelacés, 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 numérique par voie hertzienne terrestre (DVB-T) et satellite (DVB-S). Il est également utilisé comme format de codage du DVD (Digital Vidéo Disc). MPEG-4 est une norme générique de compression destinée à la manipulation d’objets multimédia. Elle permet le codage d’une grande variété de format vidéo (taille, résolution, fréquence image) mais aussi le codage d’objets vidéo de forme arbitraire, d’images fixes (codage par ondelettes) ainsi que d’objets synthétiques 3D. De ce fait, cette norme adresse une large gamme d’applications audiovisuelles allant de la visioconférence à la production audiovisuelle en passant par le streaming sur Internet ou encore la réalité virtuelle distribuée. Concernant le codage de la vidéo traditionnelle, MPEG-4 combine les outils de MPEG-2 et H.263 ainsi que de nouveaux outils lui conférant une plus grande efficacité en compression tels que des modes de scalabilité plus adaptés à une transmission sur réseaux à débit fluctuant ainsi qu’une plus grande robustesse aux erreurs de transmission. 47 Chapitre 3 Compression vidéo Conclusion Le MPEG4 apporte une solution efficace pour l’encod age vidéo. Ses algorithmes sont relativement évolues, et promettent une qualité élevée à débit bien plus bas que le MPEG2. Le MPEG4 utilise également un système de licence beaucoup plus facile, le rendant plus attractif  à l’utilisation. Son utilisation commence à faire son apparition un peu partout et le MPEG4 est devenu assez célèbre au public au travers des codecs dit DivX. 48 Chapitre 4 L’approche Streaming  Notions sur la transmission des médias   Les méthodes de streaming   Le protocole RTSP  Résumé  Dans ce chapitre, nous présenterons tout d’abord des notions sur  la transmission des medias et après on verra les méthodes de  streaming existantes. Ensuite, nous aborderons brièvement un   protocole dédie au streaming, à savoir le RTSP. L’approche Streaming Chapitre 4 1 Notions sur la transmission des médias 1.1 La transmission multipoint Le mode multipoint ou « multicast  » consiste à transmettre sur le réseau, des paquets de données d’une source vers plusieurs destinataires représentés par une adresse unique. Au lieu d’être répétés par la source, les paquets sont dupliqués par les noeuds intermédiaires de routage. En utilisant le protocole IP standard, chaque serveur devrait répéter le flot de paquets vers autant de destinataires qu’en comporte la liste de diffusion. L’envoie d’une information vers n destinataires, oblige à dupliquer n fois le flux de paquets. La consommation de ressources est très importante en temps machine, pour les routeurs et les branches du réseau. Figure 13 : Transmission unipoint d’un flux En utilisant le multicast, la transmission d’une information vers n destinataires ne requiert  plus que l’émission d’un 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 nœuds intermédiaires assurent la réplication des paquets aux intersections. Ainsi, su r un segment, ne voyage qu’une seule copie d’un même paquet. La bande passante globale utilisée est considérablement réduite. Figure 14 : Transmission multipoint d’un flux 50 Chapitre 4 L’approche Streaming Les applications multipoints seront difficiles à me ttre en œuvre en mode connecté. Supposons que l’on veuille émettre un même fichier vers 100 destinataires, il faudra alors ouvrir 100 connexions et en définir à chaque interlocuteur ses paramètres. D’autres part, dans le cas d’un réseau en étoile, le multi point n’apporte pas d’améliorations. 1.2 RTP : Le Protocole temps réel Le transport de paquets dans un réseau non déterministe ne garantit pas les délais. Le récepteur doit donc préalablement restaurer la synchronisation du flux. Les entêtes IP, UDP ou même TCP ne datent pas les paquets, ils ne fournissent pas l’horodatage qui faciliterait la remise en forme temporelle du flux : les paquets retardataires ne seront pas éliminés. Pour cette raison, le groupe de travail «  Audio Vidéo Transport (AVT-WG) » a été chargé au sein de l’IETF de développer un protocole qui faciliterait le transport des données temps réel. C’était alors RTP. «  Real time Transport Protocol » est un protocole de transport adapté aux applications présentant un caractère temps réel. Il est indépendant du protocole transport sous-jacent. RTP fournit des informations très utiles au transport des contenus. Il assure l’horodatage des paquets en imposant une estampille de temps, qui indique l’heure de leur création. La remise en ordre des paquets se trouve ainsi simplifié. 1.3 RTCP : Le Protocole de contrôle Une transmission temps réel, a pour stratégie d’abandonner les paquets perdus, pour  préserver la continuité du service, ainsi, elle ne peut être fiable. Il faut donc mettre en place un échange de rapport de réception, par lesquels les destinations informent la source du niveau de qualité de service constatée. Ils permettent à l’émetteur de connaître l’efficacité de la transmission. C’est le rôle du «  Real time Transport Control Protocol », RTCP. 51 L’approche Streaming Chapitre 4 Figure 15 : Paquets RTP et RTCP RTCP fournit un retour d’information sur la qualité de réception des données transmises dans les paquets RTP. Cette information peut être immédiatement utilisée par la source, pour adapter le type de codage. Ces fonctions de compte rendu sont effectuées grâce aux rapport émis par un récepteur et reçus par une source. 1.4 RSVP : Réservation des ressources Les congestions sont la cause principale des pertes d’inf ormation et des retards d’acheminement. Les protocoles RTP et RTCP ne s’attaquent pas directement aux pertes de  paquets et n’évitent pas les congestions. Ils se contentent d’assister l’émetteur et le destinataire dans leur activité d’échange de contenu. C’ est à la couche application aux extrémités de s’adapter à la situation. Une solution envisagée consiste à incorporer dans les routeurs intermédiaires une stratégie dynamique de régulation des flux. Le «  Resource reSerVation Protocol », RSVP a été alors introduit. RSVP achemine la réservation de bande passante le long d'un chemin de données, prédéterminé par le protocole de routage réseau. En effet, lorsqu’une application demande un niveau de qualité de service, elle transmet une requête RSVP au nœud de rattachement. Celui-ci distribue la requête à tous les nœuds intermédiaires traversés par les paquets depuis la source émettrice. Les paquets RSVP voyagent donc à contre courant, du récepteur vers l’ émetteur. La figure 16 illustre le fonctionnement du protocole. 52 L’approche Streaming Chapitre 4 Figure 16 : Principe du RSVP Certaines demandes de qualité de service peuvent être incompatibles avec les ressources d’un des nœuds de la chaîne, dans ce cas RSVP renvoie un message d’erreur à l’application. 2 Les méthodes de streaming Au fur et à mesure du développement des médias temps réel, deux méthodes pour acheminer le contenu se sont développées : Dans la première, un serveur Web standard est utilisé pour fournir les données au client.  Dans la deuxième, on utilise un serveur spécifique dédié au temps réel.  2.1 Le temps réel sur un serveur web Cette approche n’est en fait qu’une évolution du modèle «  Download and play » classique. Les sources vidéo et audio sont d’abord compressés dans un fichier, grâce à un algorithme tenant compte des contraintes du temps réel, des limitations de la bande passante. Ces fichiers sont placés sur un serveur Web standard où se trouve également le fichier HTML y faisant référence. Lorsque le lien est activé, il déclenche le lecteur du côté du client. Jusque là, rien ne diffère du téléchargement classique. Les différences sont dans les fonctionnalités du lecteur. A l’opposé du mode «  Download and play », Le client commence à jouer après seulement quelques secondes de téléchargement, temps nécessaire à la « bufferrisation » des premières données. Cette méthode s’appuie donc sur HTTP, protocole qui utilise les services de TCP pour le transport de données. Optimisé pour les applications ne nécessitent pas de temps réel (transfert de fichiers par exemple), le but de TCP est d’assurer le transport des données d’un  bout à l’autre sans pertes de paquets tout en restant efficace du point de vue débit. Pour y arriver, TCP utilise l’algorithme dit de « slow start  », présenté au premier chapitre. TCP finalise ce travail de fiabilité en réémettant les paquets perdus. De ce fait il ne peut assurer, que tous les paquets réémis arrivent à temps, pour être joués par le lecteur temps réel. Cependant cette méthode a un avantage. Elle utilise les infrastructures existantes, puisqu’un 53 L’approche Streaming Chapitre 4 serveur Web est forcement déjà présent pour le transfert des fichiers HTML, aucun nouveau matériel ou logiciel n’a besoin d’être installé et géré. Il est important à noter que la charge supplémentaire imposée aux serveurs HTTP, créera, si la demande en flux temps réel est forte, un besoin de nouvelles ressources pour répondre à de nombreuses demandes de flux audio et vidéo. Ainsi, le choix de cette solution sur de simples critères de coûts matériels, n’est pas forcement judicieux . 2.2 Le temps réel sur un serveur dédié Dans cette approche, les premières étapes sont similaires à l’approche Web. La différence réside dans le fait que les fichiers compressés sont placés sur un serveur dédié au temps réel. Les pages HTML qui y font référence sont toujours placés sur le serveur HTTP. Les données sont envoyées au client de façon dite « intelligente », dans la mesure où le serveur peut réajuster le débit en fonction de l’état du réseau. 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 différence de TCP, UDP est un protocole rapide et léger : il ne réémet pas les  paquets perdus et il n’intègre pas de fonctions de gestion de flux et de congestion. Cela, en fait un protocole idéal pour les flux temps réels ou l’ordre des i nformations reçues est plus important que la perte des paquets. L’utilisation d’un serveur dédié présente plusieurs avantages : Meilleure utilisation des capacités du réseau : le protocole UDP utilisera mieux la  bande passante que TCP, en supposant un même niveau de congestion sur le réseau. Meilleure qualité pour l’utilisateur  : en cas de congestion, le serveur peut décider de réduire la qualité de l’information transmise afin de se contenter de la bande passante disponible. Dans le cas du syst ème basé sur serveur Web, où aucun retour d’information du  poste client n’est possible, la régulation du débit n’est pas possible. En cas de congestion la lecture cessera pour un temps qui sera nécessaire pour la « bufferisation ». Plus de fonctionnalités : la technique permet l’utilisation de fonctions avancées,  typiquement celles d’un magnétoscope (avance rapide, pause et retour). Ces fonctions, si elles sont réalisables dans l’approche HTTP, sont difficiles à implémenter. Protection des copyrights : les serveurs dédiés peuvent interdire la copie des fichiers  envoyés sur le cache du client. 54 Chapitre 4 L’approche Streaming Mode de livraison multiple : les serveurs dédiés supportent différentes configurations de  protocoles. Ils sont capables de passer d’un protocole a l’autre sans intervention du récepteur. Le serveur essaiera d’abord de transmettre en utilisant le protocole optimal : UDP. Mais  puisque beaucoup d’administrateur réseau 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 dédiés, au niveau du streaming, il est clair que l’utilisation de la deuxième catégorie sera plus bénéfique. 3 Le protocole RTSP RTSP, Real Time Streaming Protocol, est un protocole de la couche application, qui est basé sur le modèle client-serveur. Il a été conçu pour transmettre et contrôler un ou plusieurs flux synchronisés d’objets média, sur un réseau IP. Il a été développé par RealNetworks, Net scape Communications et Columbia University avec la contribution de l’IETF qui l’a publié comme standard en avril 1998. Cette section présentera brièvement quelques propriétés de RTSP. 3.1 RTSP et HTTP RTSP ressemble à HTTP 1.1 au niveau de la syntaxe et des opérations. Cependant certains aspects, différencient RTSP du HTTP. Parmi ces différences :  RTSP dispose d’un certain nombre de nouvelles méthodes. De plus il a un identificateur de protocole différent.  RTSP est un protocole avec état, contrairement à HTTP. En fait, il maintient l’information 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 requêtes.  RTSP peut utiliser d’autres protocoles, tels que RTP et RDT ( Real Data Transport ), pour transporter les données. 3.2 Les formats de paquets de données En général, un serveur de RTSP peut utiliser n'importe quel type de format de paquet pour envoyer des données médias à un client. Principalement, deux protocoles sont utilisés à ce propos, RTP et RDT. RTSP permet également de surveiller la qualité de la transmission à travers RTCP. Pour cela le client émet périodiquement à destination du serveur des rapports sur la qualité de la transmission, contenant le pourcentage et le nombre de paquets perdus, le 55 L’approche Streaming Chapitre 4 délai de transmission, etc. Le serveur reçoit ces rapports et apprécie s’il y a congestion. Dans ce cas, la source réduit alors le débit émis D’autre part, RTSP tient compte d’u ne variété d’options pour le transfert des données, comprenant ainsi UDP, UDP multicast et TCP. Cependant, il utilise uniquement TCP pour la transmission des commandes et des réponses. 3.2.1 Utilisation de RTP Le client RTSP établie trois canaux de connexion avec le serveur, lorsque les données sont livrées par RTP (voir figure 17) . Une connexion TCP bidirectionnelle, pour le contrôle et la négociation.  Un canal UDP unidirectionnel, pour la livraison des données médias à travers RTP.  Un canal UDP bidirectionnelle, à travers lequel RTCP est utilisé.  Figure 17 : Les communications client/serveur dans le cas du RTP Le numéro de port RTP doit être pair, alors que le RTCP doit opérer sur le prochain port consécutif. Par conséquent, 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 opère sur le même niveau que RTP. Dans le cas où c’est ce protocole qui est utilisé, le client établira, de même que dans le cas précédent, trois connexions : Une connexion TCP bidirectionnelle, pour le contrôle et la négociation.  Un canal UDP unidirectionnel, pour la livraison des données médias.  Un deuxième canal UDP unidirectionnelle, pour demander au serveur de renvoyer les  paquets, UDP de données médias, perdus. 56 L’approche Streaming Chapitre 4 Figure 18 : Les communications client/serveur en mode RDT 3.2.3 Utilisation de TCP seul Les données médias peuvent être mis dans des paquets RTP ou RDT, qui seront transporter par TCP. Dans ce cas une seule connexion TCP bidirectionnelle est utilisée pour le contrôle et le transfert des données. Figure 19 : Les communications client/serveur en mode TCP seul 3.3 Les méthodes RTSP Les différentes requêtes RTSP sont définies à travers un ensemble de méthodes (voir figure 20). Les principales méthodes sont :  DESCRIBE : Elle est utilisée par le client pour récupérer la description d'une présentation  ou d'un objet média, identifié par un URI ( Uniform Resource Identifier ), sur un serveur RTSP. SETUP : Elle est utilisée par le client pour spécifier au serveur les paramètres de transport  du flot média, comme par exemple le type de protocole de transport, le mode de transport (point à point ou multipoint) et le numéro du port de communication. 57 L’approche Streaming Chapitre 4 PLAY  : Elle signale au serveur qu'il peut commencer à envoyer les données via le  mécanisme spécifié dans la méthode SETUP. Elle permet également de jouer un ou plusieurs sous-intervalles de la durée d'un objet média, par exemple jouer une audio à partir de la 10 ème seconde jusqu'à la 20 ème seconde. PAUSE : Elle est utilisée par le client pour demander au serveur d'interrompre  temporairement le transfert du flux média. Le client peut reprendre la transmission du flux en envoyant la requête PLAY au serveur. TEARDOWN : Elle est utilisée par le client pour demander au serveur d'arrêter  définitivement le transfert du flux média. Figure 20 : Fonctionnement de RTSP En résumé, RTSP dispose de plusieurs fonctionnalités, qui lui permettent un transfert de données, plus adapté aux médias. En plus, il maintient une horloge qui est associée à chaque objet média transmis. C’est cette horloge qui permet de déterminer, a chaque instant, si une partie des données à transmettre, a déjà dépassé son échéance. Dans ce cas, il est inutile de l’envoyer au client qui l’a rejetterai à sa réception. RTSP permet donc la mise en œuvre de stratégies de filtrage des données du côté d u serveur et donc à la source. Vu l’efficacité du protocole RTSP, plusieurs éditeurs de logiciels se sont intéressés à mettre en place des outils de streaming utilisant ce protocole. La section suivante présentera ces différentes platesformes. 58 Chapitre 4 L’approche Streaming Conclusion Ce chapitre nous a permis de découvrir la notion de streaming, ainsi que les caractéristiques du protocole RTSP et des serveurs l’utilisant. Nous avons pu voir aussi, dans ce chapitre, différents problèmes, liés aux transmissions temps réel. Nous avons présenté également quelques outils permettant de résoudre les problèmes déjà cités. Le chapitre suivant présentera la solution réalisée. 59 Chapitre 5 Solution et réalisation  Introduction   Comparaison entre les technologies  de streaming   Etude du cas de RealNetworks   Plate-forme réalisée  Résumé  Dans ce dernier chapitre je décrierai la plateforme réalisée, qui est  basée sur des logiciels que je vais les mentionner dans ce chapitre  ainsi que d’autre outils complémentaires. Chapitre 5 Solution et réalisation 1 Introduction RealNetworks a développé une famille de logiciels, dans le but de réaliser une architecture complète pour le streaming. Cette famille est appelée «  RealSystem ». 1.1 Présentation de RealSyetem Real System est une famille d'outils, composée essentiellement de trois logiciels : · « RealProducer », c’est un outil de création des médias (son, vidéo ou animation). Il joue le rôle du codeur. · « RealServer  », pour servir les médias. · « RealPlayer  », c’est le logiciel client permettant de jouer les présentations servies. La figue suivante illustre comment ces composants sont reliés ensemble. Figure 21 : Les composants de real system  RealProducer C’est le codeur de Real Networks. Il est disponible sur toutes les plates-formes. Actuellement, il est à sa version 11. Le rôle de cet outil de production consiste à optimiser le codage pour une transmission efficace sur Internet ou encore sur des Intranets. La création du contenu peut être faite en différé ou bien parallèlement à l’évènement qui se produit. RealProducer est utilisé pour convertir un son, une vidéo 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 création du contenu peuvent être utilisés, cependant, ils ne seront pas aussi performants que le RealProducer surtout que c’est le seul programme capable de 61 Chapitre 5 Solution et réalisation communiquer avec le serveur lorsqu’il s’agit de transmettre des données parallèlement à leur production.  RealServer RealServer utilise plusieurs protocoles pour fournir les médias aux clients à travers l’Internet ou des Intranets. Ainsi, suivant les situations, il servira ses données selon les protocoles RTSP, PNA (Progressive Network Audio) ou HTTP. Avec sa version 11, RealServer présente plusieurs avantages. Ses dispositifs de control d’accès et d’authentification permettent un très bon niveau de sécurité. De plus, il est doté d’une interface d’administration à distance, très facile à manipuler.  RealPlayer C’est l’outil 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 fonctionnalités lui permettant de communiquer également avec un serveur Web, réalisant 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 » n’est pas gratuite et dispose de plus de fonctionnalités. Real  Networks dispose d’un autre outil aussi important à savoir le «  RealProxy ». Cet outil élimine les transmissions redondantes, réduisant ainsi la bande passante utilisée 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 présenteront les séquences vidéo enregistrée sur le serveur vidéo. Lorsqu’un utilisateur cl ique sur un lien donné, le logiciel client, à savoir RealPlayer, se déclenchera pour permettre la visualisation des vidéos. Le schéma de la communication n’est pas aussi simple qu’il paraît. La figure 22 présente les différentes étapes intermédiaires entre le clique du client et la visualisation de la vidéo. 62 Chapitre 5 Solution et réalisation Figure 21 : Initialisation des communications entre RealServer et RealPlayer Tout d’abord lorsque le client clique sur un lien qui l’intér esse, le navigateur Web contacte le serveur vidéo. Lors de la deuxième étape, le navigateur Web reçoit un petit fichier qui pointe sur le contenu désiré. Cependant, il reconnaît que ce type de fichier ne lui est pas destiné. Il cherche alors le programme a pproprié, capable de comprendre ce qu’il y a dans le fichier  reçu. Ainsi RealPlayer est lancé. Dans l’étape suivante, RealPlayer lira dans le fichier reçu, le nom et l’emplacement de la vidéo dans RealServer. Ensuite, il enviera une requête au serveur vidéo. Ce dernier répondra en dernière étape, en transmettant la vidéo désirée. 2 Comparaison entre les technologies de streaming QuickTime Streaming Server d’Apple, Windows Media Server (également connu sous le nom de NetShow) de Microsoft et RealServer de RealNetworks sont les serveurs dédiés les plus connus. Tous ces serveurs monopolisent le micro processeur de la machine serveur, amenant l’utilisation du CPU à 100% lors de la diffusion des images via le réseau. Il est alors impossible d’exploiter simultan ément le serveur vidéo comme serveur Web ou serveur de fichiers. Pour pouvoir choisir l’outil convenable, une comparaison s’impose. Ainsi, cette section abordera les différences entre les trois technologies en matière de coût, de scalabilité, d’administration et de sécurité. 2.1 Coût Tout serveur dédié nécessite un logiciel client approprié, qui peut être téléchargé gratuitement. Les trois technologies fournissent également un ensemble de logiciels pour manipuler et synchroniser les médias temps-réel. Le NetShow de Microsoft est gratuit, il est partie standard de Windows 2000 et Windows NT. Les dernières mises à jour sont disponibles au site Web de Microsoft. La qualité améliorée de la dernière version fait de Windows Media 63 Chapitre 5 Solution et réalisation Server un choix convenable pour une société à environnement Windows. En ce qui concerne le serveur d’Apple, il a été initialement développé pour son propre système d’exploitation. Cependant Apple a également développé un code source, connu sous le nom de «  Darwin Streaming Server  », qui est téléchargeable sur le site Web d’Apple avec des versions pour  Windows NT et 2000, Solaris et Linux aussi bien que la version initiale de Macintosh. A la différence des deux premières, Real Networks ne fournit pas son serveur gratuitement et c’est tout à fait raisonnable puisqu’elle n’a aucune autre source de revenu. Le coût de RealServer dépend du nombre maximal de connexions simultanées qu’il peut supporter. Le RealServer existe pour toutes les plates-formes, sur lesquelles il fonctionne de la même façon. 2.2 Scalabilité La scalabilité permet de servir une vidéo, de haute qualité aux utilisateurs disposant d’une bande large et de qualité inférieure à ceux ayant une bande étroite. Chaque serveur traite la scalabilité d’une manière légèrement différente. Windows Media Server  est le plus limité. On peut produire deux versions de chaque fichier (bonne et mauvaise qualité), en utilisant différentes compressions. Quand quelqu’un demande une vidéo, le serveur de média teste la vitesse de connexion du client. Il sert alors la version la plus appropriée. Cette approche signifie qu’on a deux copies de chaque fichier à traiter ce qui augmente le temps et l’effort pour contrôler le site. RealServer communique avec RealPlayer de la même manière. Cependant, les fichiers doivent être comprimés en utilisant une technique spécifique appelée « SureStream ». On peut créer alors jusqu’à six versions différentes d’une vidéo, chacune avec ses propres configurations de compression, mais qui seront fusionnées ensemble dans un grand fichier simple. Ceci n’influe pas sur la qualité, mais il permet de réduire le nombre de fichiers à gérer. QuickTime est le plus souple des trois technologies. Il permet de produire n’importe quel nombre de versions d’une vidéo. En plus de la vitesse de la connexion de l’utilisateur, le serveur peut vérifier d’autres détails tels que la vitesse du processeur de la machine qui télécharge la vidéo. 2.3 Administration et sécurité Le client d’administration distante, écrit en Java, de RealServer est particulièrement utile. Le produit de Microsoft, apporte moins de contrôles. Il est facile à administrer mais il impose d’utiliser Internet Explorer et d’installer un Active X en complément du navigateur Web. Quant à QuickTime, il ne propose aucune fonction d’administration distante. En matière de sécurité, RealServer permet le control d’accès, l’authentification des clients ainsi que le 64 Chapitre 5 Solution et réalisation cryptage du flux vidéo et la configuration de la durée d’affichage et des droits de visualisation, de tell ou telle vidéo en fonction des permissions sur les répertoires. QuickTime présente des lacunes de sécurité alors que Windows Media Server utilise les avantages des fonctions de base de Windows NT telles que les listes de contrôles d’accès et les permissions de fichiers. Une comparaison entre quatre technologies a été faite par le magazine «  Réseaux & Télécoms ». Toutes les sociétés, en relation avec le streaming, ont été invitées à fournir les logiciels serveurs et les outils nécessaires pour créer, modifier et importer les vidéos. La comparaison a été faite en tenant compte de plusieurs contraintes. Le tableau suivant résume les résultats des tests. Figure 22 : Comparaison des technologies de streaming Au terme de ces tests, la technol ogie de Real Networks, s’avère la meilleure solution pour  diffuser de la vidéo sur réseau numérique. Elle présente 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é l’avantage à la famille RealSystem de RealNetworks. 3 Étude du cas de RealNetworks 3.1 Le codeur de RealNetworks 3.1.1 Fonctionnement de RealProducer RealProducer peut convertir les sons et les vidéos à partir de fichiers (AVI, MOV, QT, 65 Chapitre 5 Solution et réalisation WAV et AU) ou directement à partir d’un outil d’acquisition. Le résultat de la conversion peut être stocké sur un fichier ou bien transmis en direct à travers un RealServer. Figure 23 : Enregistrement des présentations Real Media A noter que RealProducer n’accepte qu’une seule entrée et u ne seule sortie à la fois. Avant de commencer le traitement, il demande à son utilisateur si l’entrée sera un fichier ou un outil d’acquisition, la combinaison des deux n’est pas possible. De même pour la sortie, l’utilisateur doit préciser l’emplacement d u fichier si les données seront stockées localement. Sinon, il doit indiquer le serveur auquel elles seront transmises, les deux possibilités ne peuvent être réalisées simultanément. 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 nécessaires pour un fonctionnement correct du logiciel sur un système Windows ou Linux varient suivant la source des médias à convertir. Ainsi, dans le cas d’une acquisition, le matériel doit être plus performant, par rapport au cas où la source serait un simple fichier. 3.1.2 SureStream Lors de la création d’un contenu avec RealProducer, on est amené à choisir entre une présentation à « simple cadence » ou bien d’utiliser la notion de « SureStream » qui donnera naissance à une présentation à « cadences multiples ». Le SureStream consiste à inclure dans la même sortie, différents flux optimisés pour des largeurs de bande différentes. Ainsi, on peut atteindre un public très large, tout en fournissant à tous les utilisateurs le meilleur son et la meilleure image pour leur bande passante. De plus lors d’une congestion du réseau, la présentation commutera automatiquement à un débit inférieur. Par exemple, dans le menu du RealProducer, l’utilisateur peut enregistrer une vidéo pour les trois cibles 10, 20 et 100 Méga bits par seconde (Kbps). RealPlayer utilisera automatiquement le flux convenable à sa vitesse de connexion sachant que tous les flux sont dans le même fichier. 66 Chapitre 5 Solution et réalisation Figure 24 : Enregistrement d’une présentation pour différentes largeurs de bande « SureStream » fonctionne seulement sur un RealServer. Puisqu’un seul fichier contient tous les flux, le serveur doit être capable d’extrai re juste le nécessaire. Un RealServer peut localiser chaque flux et par conséquent transmettre le plus convenable. Par contre, un serveur Web, ne connaît pas les détails, alors il transmettra toutes les données au lieu de choisir un seul flux. Bien que l’on puisse coder une vidéo, en utilisant le SureStream, juste pour une vitesse de connexion donnée, ce contenu ne doit pas être servi par un serveur Web. Même lorsque le contenu est codé pour une seule vitesse, il contiendra plusieurs flux, afin de pouvoir diminuer en débit s’il y des problèmes sur le réseau. Par exemple, une vidéo compressée seulement pour 28,8 Mbps, mais en utilisant le SureStream, contient des flux à 16 et 11 Mbps. Un serveur Web téléchargera le tout, gaspillant ainsi la bande passante. Le fait que tous les flux soient mis ensemble dans un même fichier peut donner naissance à des fichiers de tailles  plus grandes que les sources, même s’ils sont compressés. Si le volume des fichiers pose un problème, il faut limiter le choix aux vitesses essentielles. 3.1.2 Realvideo Une vidéo 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 employés. Le résultat de la conversion sera mis dans un fichier d’extension « rm ». RealProducer convertit différents attributs de la vidéo à savoir la cadence des trames, les types de mouvement et la taille des images. 67 Chapitre 5 Solution et réalisation  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 vidéo peut être alors codée de 20 Mbps à des centaines de Mbps. RealVideo utilise une compression avec perte. Lorsque c’est nécessaire, il élimine intelligemment les données, pour garder une qualité aussi bonne que possible. Pour diminuer la taille de la vidéo, RealProducer joue aussi sur la cadence des images. En fait, la plupart des vidéos ont des cadences de 15 à 30 images par secondes (i/s), RealProducer ajuste dynamiquement cette cadence. Dans ce sens, il la maintient élevée lorsqu’il s’agit d’une scène à mouvement rapide, alors que lorsque le mouvement est lent, il diminue la cadence. RealProducer détermine comment coder une vidéo à partir des choix suivants :  Vitesse ciblée,  Type du son,  Nature de la vidéo (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 données de correction d'erreurs au flux compressé, permettant ainsi de maintenir sa qualité dans un environnement à pertes. Il a un impact négligeable sur la vitesse de codage. * Codage VBR : le principe du VBR ( Variable Bit Rate ) consiste à réguler le débit de sortie du codeur, donnant ainsi plus de largeur de bande aux scènes difficiles à compresser et moins de bande pour les scènes faciles. Le codage VBR donne généralement des vidéos de qualité meilleure à ceux codées par CBR ( Constant Bit Rate). *  Maximum de temps entre deux images clé  : RealProducer code toutes les données d’une clé, alors que pour celles qui la suivent, il ne codera que la différence entre l’image et celle qui la précède. Par défaut, le maximum de temps entre deux images clé est de 10 secondes. En diminuant cette valeur, plus d’images clé seront produites et par conséquent les distorsions diminueront. Mais puisque les images clé contiennent plus de données, le fait de diminuer le temps entre deux images de ce type peut entraîner une dégradation de la qualité si la largeur de bande est la même. 68 Chapitre 5 Solution et réalisation 3.2 Le serveur de RealNetworks RealServer est un logiciel qui permet de transmettre des médias pré-enregistrés ou en direct sur l'Internet ou dans un Intranet. Il diffuse le son, la vidéo, les images, les animations, le texte et d'autres types de données, aux ordinateurs clients. Cette partie survole brièvement les différentes propriétés du serveur de RealNetworks, il fournit les réponses aux questions suivantes : Quelles sont les conditions d’un bon fonctionnement du logiciel ?  Quel est son principe de fonctionnement ?  Quelles sont les méthodes qu’il utilise pour délivrer les données aux clients ?  Cette partie présente également les dispositifs, de sécurité et de manipulation de la bande passante, intégrés dans RealServer. 3.2.1 Conditions de fonctionnement Indépendamment de la plate-forme utilisée, le RealServer fonctionne mieux lorsqu’il est installé sur un ordinateur dédié. Il faut éviter par conséquent d'installer des serveurs Web ou d'autres applications sur le même ordinateur que RealServer. Le RealServer utilise un modèle multiprocesseur, qui est particulièrement bien adapté à l'architecture client/serveur. Quand un client essaie de se relier au serveur, le gestionnaire de système crée un nouveau processus pour contrôler ce client alors qu'un autre processus écoute les connexions des autres clients. Ainsi, le RealServer est plus performant quand il fonctionne sur un système avec plus d'un processeur. La mémoire et les processeurs affectent le fonctionnement du RealServer. En ajoutant de la mémoire il pourra manipuler plus d'informations à n'importe quel moment, tandis que l’ajout 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 Solution et réalisation PNA, le HTTP n’est utilisé qu’occasion nellement. En fait RealServer s’en sert pour les fichiers « méta » qui pointent sur le contenu du serveur ainsi que pour les pages de HTML qu'il sert (les pages HTML pour l’administration). Il peut également ê tre employé pour livrer des vidéos aux clients qui sont situés derrière un pare-feu. RealServer utilise deux connexions, connues sous le nom de canaux, pour communiquer avec les clients. La première voie est connue par le nom de « canal de contrôle ». C’est à travers ce canal que le serveu r demande et reçoit des mots de passe et que les clients envoient des instructions telles que l’avance rapide, et l'arrêt complet ou instantané. D'autre part, les médias sont transmis sur une voie séparée dite « canal de données ». Dans ces canaux, le serveur utilise deux protocoles pour envoyer les instructions et les données:  TCP : pour envoyer les commandes du client, et les informations spécifiques aux médias présentés tel que titre.  UDP : pour le transfert du contenu. Puisque beaucoup de firewalls sont configurés pour permettre seulement des connexions TCP ou bien du trafic HTTP, on peut avoir besoin de faire quelques modifications pour recevoir les données d'un codeur ou bien pour servir les clients qui derrière 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 contrôle et un canal UDP à sens unique pour transmettre les données. Parfois les pare-feu n’autorisent pas les paquets UDP. Ainsi, la connexion TCP est utilisée à la fois pour le contrôle et les données. 70 Chapitre 5 Solution et réalisation Figure 26 : Fonctionnement codeur/serveur dans le cas d’un pare -feu  Communication entre un RealPlayer et un RealServer Quand un utilisateur clique sur un lien qui pointe sur une présentation donnée, le client ouvre une connexion bi-directionnelle avec le serveur. Cette connexion utilise TCP pour échanger des informations concernant les médias à transmettr e ou bien l’authentification de l’utilisateur. Figure 27 : Phase initial de la communication client/serveur Lorsque le serveur accepte la demande, il envoie les médias demandés au RealPlayer le long d'un canal UDP à sens unique. Figure 28 : Phase de transfert de données entre le client et le serveur 71 Chapitre 5 3.2.3 Solution et réalisation Méthode de livraison des médias  A la demande Les données sont à la disposition de l’utilisateur à n’importe quel moment. Ce type de médias est pré-enregistré, les vidéos sont servies sur demande. Un utilisateur qui clique sur un lien pointant sur ce genre de données, pourra visualiser la vidéo depuis le début. Il pourra également avancer ou arrêter la présentation.  En direct Les présentations en direct sont transmises aussitôt qu’elles sont créées. Elles n’existent pas sous forme de fichiers. L’utilisateur peut joindre les événements qui se déroulent à n’importe quel moment, une fois qu’il a cliqué sur un lien vers une présentation en direct. Contrairement aux transmissions à la demande, le client ne peut pas avancer ou arrêter les médias. Servir des  présentations en direct, nécessite le matériel et le logiciel convenables pour l’acquisition du contenu ainsi que sa conversion en un format que le RealServer peut diffuser. Les présentations en direct peuvent être transmises de différentes manières, selon les besoins du réseau l’administrateur décide de choisir une méthode donnée. * Le point à point : c’est la méthode la plus simple et la plus connue pour des diffusions en direct, puisqu’elle ne nécessite aucune configuration. Cependant, elle exige une bande passante assez large pour pouvoir servir tous les clients connectés. * Le splitting : c’est le terme utilisé pour décrire comment un RealServer peut partager  ses flux de médias, transmis en direct, avec d’autres RealServers. Les clients se connectent à ces serveurs, plutôt qu’au serveur principal qui est à l’origine des médias. Le splitting réduit la charge du trafic sur le serveur source. Cette méthode permet aussi de déplacer les émissions plus près des clients, améliorant ainsi la qualité de service. * Le multipoint : il exige un réseau supportant le multipoint, malheureusement ce n’est pas le cas au Maroc. Le multicast sera décrite plus en détail dans le paragraphe suivant. Le choix de la méthode la plus convenable dépend des situations. Le point à point est typiquement utilisé pour un nombre assez réduit de client. Le splitting et le multipoint sont  plus appropriés pour les diffusions à un grand nombre d’ utilisateurs. 72 Chapitre 5 3.2.4 Solution et réalisation Le multipoint Le multipoint consiste à transmettre un seul flux pour différents clients, plutôt que de d'envoyer un flux par client. Figure 29 : Schéma 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 réseau peuvent être configurer pour fonctionner en multicast. Par contre sur Internet, il se peut que des dispositifs intermédiaires du réseau ne supportent pas le multipoint. RealServer permet deux méthodes de multipoint : le back channel multicast et le scalable multicast.  Back-Channel multicast Cette méthode consiste à maintenir un canal de contrôle entre le serveur et chaque client. Le serveur utilise ce canal pour fournir des informations au sujet de la présentation, pour demander des informations d’authentification au client ou pour  recevoir les commandes de ce dernier. 73 Chapitre 5 Solution et réalisation Figure 30 : Schéma de la back-Channel multicast Le back-Channel multicast peut utiliser les protocoles RTSP ou PNA. Les informations d’authentification, les statistiques et les mesures de qualité de service peuvent être transmises puisque le serveur et le client sont reliés par un canal bidirectionnel.  Scalable multicast Contrairement à la première méthode, celle-ci n’utilise pas de canal de contrôle, ainsi elle nécessite moins de bande passante. Figure 32 : Schéma 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 données sont diffusées sur le réseau 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 l’absence du canal de contrôle, l’authentification des clien ts ne peut pas avoir lieu. Alors 74 Chapitre 5 Solution et réalisation que les statistiques sont transmises à la fin. Ainsi, avec le RealServer, deux formes de multicast sont possibles, permettant d’économiser la bande passante. Cependant la notion de « SureStream » n’est pas opérationnelle si l’on opte pour le multipoint. En fait puisque la même  présentation sera servie à tous les clients, il est impossible d’adapter la qualité transmise à chacun. 3.2.5 Gestion de la bande passante RealServer fournit des outils permettant de gérer la bande passante utilisée. Dans ce sens on peut limiter le nombre de clients pouvant se connecter au serveur simultanément ou encore limiter la bande passante consommée par le RealServer. En réglant le paramètre «  Maximum Client Connections », on peut limiter le nombre d’utilisateur servis simultanément. Ce nombre peut prendre des valeurs de 1 à 32767, tant qu'il est inférieur ou égal au nombre de transmissions permises par la licence. S’il est égal à zéro ou qu’il est non précisé, 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 d’erreur et ne pourront être servis que lorsqu’un utlisateur se déconnectera. De même, le paramètre «  Maximum Bandwidth », permet de restreindre la quantité de bande passante, en Kilo bits par seconde, que le RealServer peut utiliser. Si l’on établit des valeurs pour les deux variables, RealServer  limitera l'accès quand le seuil inférieur est atteint. 3.2.6 La Sécurité Le RealServer permet différentes mesures de sécurité. Il est alors possible de limiter l’accès au serveur suivant les adresses IP ou bien d’authentifier les utilisateurs. RealNetworks a développé également des plug-ins client et serveur pour une communication cryptée entre les deux.  Le contrôle d’accès On peut bloquer ou permettre l'accès au serveur, en se basant sur les adresses IP de la machine désirant se connecter et sur le port auquel la demande est faite. Chaque contenu est associé à un numéro de port spécifique : les médias sont servis sur le port RTSP et le port PNA, les pages HTML sont disponibles à travers le port HTTP. Les codeurs fournissent les données compressées par l’intermédiaire d’un port particulier. De même, l’administration distante 75 Chapitre 5 Solution et réalisation utilise un port précis qui sera défini à l’installation. Le dispositif de contrôle d’accès, permet à l’administrateur du réseau de choisir qui peut se connecter et à quel port. Par exemple on peut restreindre l’accès des codeurs en choisissant les machines qui peuvent utiliser le port de codage (4040 par défaut). On peut également permettre seulement à certaines personnes de visualiser les présentations servies, en précisant leurs adresses IP ainsi que les numéros de  ports d’accès pour les protocoles RTSP, PNA et HTTP. Les clients qui ne sont pas autorisés, recevront un message d'erreur indiquant que l’URL est incorrecte. Les informations, concernant chaque adresse ou plage d’adresses qu’on désire autoriser ou non, sont stockées dans des règles. Une règle est un ensemble d'instructions décrivant la manière dont le serveur doit se comporter vis à vis de certaines adresses IP. Chaque règle est identifiée par un nombre qui lui sera assigné lors de sa création. Une règle contient les informations suivantes : Numéro de la règle : il identifie la règle.  Accès : client autorisé ou non.  Adresse IP du client : individuelle ou bien une plage d’adresses.  Adresse IP du serveur : l’adresse du RealServer.  Numéros de Ports .  Lorsqu’un client essaie de jouer une présentation ou bien d’env oyer des médias compressés, le serveur compare son adresse et le port demandé aux adresses et aux ports énumérés dans les règles. Si l’adresse IP du client et le numéro de port n’apparaissent dans aucune règle, le serveur refuse l’accès. Par exemple, pour permettre à un codeur d’envoyer ses données au serveur, on créera une règle qui spécifiera l'adresse IP du client et le port de codage 4040. Lors de la vérification des règles, RealServer commence par les règles ayant les plus petits identificateurs. C’est pourquoi, les règles ayant des numéros petits, doivent être les plus strictes. Le contrôle d’accès est basé sur les adresses IP et les ports requis. RealServer possède également un autre dispositif plus sélectif en matière de restriction d’accès aux donné es servies et reçues. Ce dispositif est l’authentification.  L’authentification Elle permet de contrôler l’accès des utilisateurs aux services du RealServer, qu’ils soient codeurs, administrateurs distants ou clients désirant visualiser des présentations qu ’ils ont payées. En utilisant l'authentification, l'identité des utilisateurs ou logiciels, qui ont lancé des 76 Chapitre 5 Solution et réalisation requêtes vers le serveur, sera vérifiée avant le commencement du dialogue. Pour les codeurs, il sera exigé de fournir un nom et un mot de passe av ant d’envoyer leurs données. Si l’identité est non correcte le transfert n’aura pas lieu. En ce qui concerne l’administration, pour protéger  le serveur contre des changements, seules les personnes ayant des identités valables pourront accéder au «  RealSystem Administrator », outil d’administration des serveurs de RealNetworks. Quant aux clients en plus des identités exigées, l’accès pourra être limité à un certain nombre de répertoires ou de présentations. Les noms des utilisateurs autorisés pour chaque catégorie (codeurs, administrateurs et clients), sont enregistrés dans des bases de données séparées. RealServer permet plus qu’une simple authentification lorsqu’il s’agit de visualiser des présentations. A partir de l’URL demandée et de l’identité de l’u tilisateur, il détermine le type d’accès aux données. En fait lors de l’ajout d’un utilisateur à la base de données, on définit ses droits d’accès pour chaque fichier et répertoire du contenu sécurisé. Les types d’accès sont présentés par le tableau 33 : Figure 33 : Type de permission Les termes Event , Calendar , Duration et Credit  sont les paramètres utilisés au niveau du «   RealSystem Administrator » pour définir le type d’accès.  Cryptage Real Networks fournit un autre mécanisme pour sécuriser les médias transmis en chiffrant le flux de données entre le serveur et le client. Le chiffrement est réalisé par des plug-ins qui permettent de crypter les données au niveau du serveur et de décrypter le flux reçus au niveau du client. Ces plug-ins échangent des messages à travers le canal de contrôle. Ces messages peuvent par exemple contenir les clés publiques de cryptage. Le serveur cryptera les données avec une clé publique du client, ensuite le résultat sera transmis. Une fois le flux chez le 77 Chapitre 5 Solution et réalisation client, il sera déchiffré, en utilisant la clé privée de ce client. Ensuite la visualisation commencera. Le processus entier, cryptage/décryptage, est transparent à l'utilisateur. Actuellement, le cryptage peut être utilisé seulement pour les connexions point à point. Puisque chaque flux est chiffré pour un client spécifique, il ne peut être déchiffré que par ce client. Le canal de données est utilisé pour fournir le contenu crypté. C’est un canal avec pertes, il n’y a aucune garantie que les paquets arriveront à leur destination. Le chiffrement employé par RealServer, a été spécifiquement conçu pour fournir une sécurité forte dans ce type d'environnement afin d’éviter les problèmes au niveau du déchiffrement. Ainsi, la méthode employée, consiste à crypter les paquets de manière indépendante. Par conséquent, si un paquet est détruit, déformé ou perdu, il n’influencera pas le processus de décryptage. 3.3 RealPlayer 3.3.1 Fonctionnement RealPlayer peut communiquer avec un serveur Web ou un RealServer. Il est capable de lire les médias aussitôt qu’une partie sera reçue. Ainsi, il commence la présentation tout en continuant à recevoir les données. Pour éviter au maximum les interruptions qui peuvent avoir lieu lors de la lecture des médias, RealPlayer utilise la notion de « bufferisation ». En effet il se sert d’un buffer pour stocker un certain nombre de paquets qui vont être joués par la suite. Cependant, si le réseau est congestionné, il se peut que la réception soit en retard par rapport à la présentation. Dans ce cas RealPlayer, doit attendre le remplissage de buffer pour jouer les données qui y sont stockées. De cette manière la continuité du flot sera sur des séquences et non pas pour toute la présentation. RealPlayer gère aussi la synchronisation des données. En fait lorsqu’il s’agit d’une vidéo, le son et les images sont transmis sur des différents paquets. A la réception, RealPlayer réorganise les données avant de les présenter. 3.3.2 Transport des données RealPlayer permet à son utilisateur de spécifier le protocole de transport qui sera utilisé lors de la communication avec le serveur. La figure 34 présente les différents 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 Solution et réalisation l’utilisateur l’initiative de spécifier certains paramètres pour les protocoles RTSP et PNA. Dans ce dernier cas, la figure 35 illustre les différentes options possibles. Figure 34 : Préférences de transmission Figure 35 : Options de transport pour le protocole RTSP 79 Chapitre 5 3.3.3 Solution et réalisation Autres configurations Pour des raisons de sécurité, des serveurs proxys peuvent être imposés pour communiquer avec les serveurs. RealPlayer peut être configuré pour passer par ces proxys, il suffit d’indiquer leurs adresses IP ainsi que les ports qu’ils utilisent. Figure 36 : Utilisations des proxys RealPlayer permet de régler d’autres paramètres qui sont en relation avec les performances du système. Dans ce sens, l’utilisateur peut optimiser l’utilisation de son processeur ainsi que la mise en cache des fichiers consultés. 80 Chapitre 5 Solution et réalisation 4 Plate-forme réalisée 4.1 Schéma de la plate-forme réalisée En tenant compte des informations que je viens de présenter, ainsi que des mesures de sécurité que nous devons prendre, le schéma de la plate-forme réalisée se présente comme suit: Figure 37 : Plate-forme réalisée Une requête qui vient de l’extérieur, arrivera tout d’abord au réseau local du DSI, en passant par son routeur. Elle sera ensuite acheminée vers la machine protectrice « machine P ». Cette dernière appliquera des mesures de sécurité, puis si le flux est accepté, il sera redirigé vers les serveurs « machine S ». Les réponses des serveurs prendront le chemin inverse. A noter que pour des raisons d’efficacité, il serait mieux de mettre le serveur Web et le serveur vidéo sur des machines différentes. Les machines S et P sont des ordinateurs Linux, dont la version du noyau est 2.2. Sur la première, j’ai installé un RealServer et un serveur  Web Apache alors que sur la deuxième, j’ai mis en place un RealProxy et un proxy HTTP « Squid ». De plus la machine P dispose de deux interfaces réseau : deux cartes Ethernet, une est reliée au réseau local du DSI alors que l’autre est connectée directement à la machine S. 81 Chapitre 5 Solution et réalisation La machine S qui offre un service Web et un service vidéo, doit être accessible de l’extérieur, à travers Internet. Autrement dit, elle doit disposer d’une adresse IP publique, de la forme 194.204.209.x. Une requête extérieure, arrivera au routeur qui doit l’acheminer vers la machine 194.204.209.x. Pour ce faire, il a besoin de l’adresse matérielle « adresse MAC  » de cette machine. La solution est une requête ARP ( Address Resolution Protocol). Dans ce sens, le routeur enviera, à toutes les machines de son réseau, un message demandant à la machine d’adresse IP 194.204.209.x de lui envoyer son adresse MAC. C’est à ce niveau que nous devons intervenir. En fait, si la machine S est connectée directement au réseau local de la direction, elle répondra à la requête ARP et le paquet provenant de l’extérieur arrivera aux serveurs sans contrôle. Une solution est de séparer la machine S du réseau local et de la connecter seulement à la machine P qui doit être configurée de telle sorte à répondre aux requêtes ARP destinées à l’adresse IP 194.204.209.x. C’est la notion d’ARP Proxy. Une fois les paquets sont au niveau de la machine P, ils seront redirigés, grâce à l’utilitaire « ipchains » contenu dans les systèmes Linux, vers les applications proxys, pour appliquer les mesures de sécurité. Les réponses des serveurs prendront le chemin inverse, mais pour cela, la machine S doit être configurée de telle sorte à avoir la machine P comme passerelle par défaut. 4.2 Principe de l’ARP Proxy Pour mettre en place mon architecture, j’ai crée un sous réseau « R1 » du réseau local du DSI « R0 ». 82 Chapitre 5 Solution et réalisation Figure 38 : Création du sous réseau R1 Pour R1, j’ai choisi un masque, de 30 bits (255.255.255.252), qui permet de définir deux adresses IP sur ce réseau. La machine P sera connectée à  R0 à travers l’interface Ethernet « eth0 » et à R1 par l’intermédiaire de l’interface « eth1 ». Supposons qu’une machine L (routeur ou ordinateur) de R0 veuille envoyer un paquet à la machine S. Puisque l’adresse IP de cette dernière laisse croire à la machine L que S est sur le même réseau physique, la machine L utilisera le protocole de résolution d'adresse ARP pour envoyer un message de diffusion sur R0, demandant à la machine qui a l’adresse IP de S de répondre avec son adresse matérielle (adresse Ethernet ou MAC). La machine S ne verra pas cette requête, puisqu'en réalité elle n'est pas sur  R0, par contre la machine P, qui est sur les deux réseaux, la verra. Lorsque le noyau Linux de la machine P est configuré en ARP Proxy, il détermine qu’une requête est arrivée sur l'interface eth0, et que l’adresse IP à résoudre est dans l'intervalle du  R1. La machine P envoie alors sa propre adresse Ethernet à la machine L dans un paquet de réponse ARP. La machine L met alors à jour son cache ARP en y ajoutant une entrée pour la machine S, mais avec l'adresse matérielle de la machine P. La machine L peut alors envoyer le paquet, qui sera reçu 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 d’acheminer ce paquet vers la machine S en cherchant dans ses tables de routage pour savoir 83 Chapitre 5 Solution et réalisation quelle interface contient l’adresse de S. Maintenant P doit trouver la vraie adresse matérielle de la machine S, en supposant qu'elle ne l'a pas déjà dans son cache ARP. P utilisera une requête ARP, à travers l’interface eth1, la machine S répondra par conséquent en donnant sa propre adresse Ethernet. P peut alors envoyer le paquet, qui venait de  L, vers la machine S. 4.3 L’utilitaire ipchains « ipchains » est un outil de filtrage des paquets IP, intégré dans le noyau Linux à partir de la version 2.1. En effet tout le trafic circulant dans un réseau est envoyé sous formes de paquets. Le début de chaque paquet précise son type, sa source, sa destination et divers autres détails. ipchains, comme tout filtre de paquet, est un programme qui regarde l’entête des paquets et décident de leur destin. Il peut alors les refuser (les supprimer comme s’ils n’ont jamais été reçus), de les rejeter (ef fet identique au refus, mais il est précisé à la source que le paquet n’a  pas été accepté), de les accepter ou de les rediriger vers d’autres ports. 4.4 Configuration requises du noyau Pour pourvoir utiliser l’utilitaire ipchains le noyau Linux doit supporter certaines configurations réseau. Donc, sous le répertoire «  /usr/src/linux/  », la commande « make  xconfig » permet de lancer un utilitaire de configuration de tout le système Linux. Dans le menu « Options réseau », il faut alors activer les options suivantes :   Réseau TCP/IP : il est hautement recommandé d’activer cette option, les protocoles  utilisés dans Internet seront ainsi chargés et reconnus par le noyau.   IP routeur avancé : la machine P servira comme routeur, qui transmet et redirige les  paquets réseau. En activant cette option, plus de fonctionnalités 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 activée 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 l’entré de la table de routage pour leur adresse source ne correspond pas à l’interface réseau par laquelle ils arrivent. Cela est un avantage pour la sécurité, dans la mesure où « rp_filter  » prévient les attaques d’ IPspoofing , présentées dans le premier chapitre.  IP passage par barrière coupe feu  : cette option est nécessaire pour utiliser une machine Linux comme un firewall filtre de paquet. Le code de firewalling ne fonctionne que si la transmission IP est activée dans le noyau. 84 Chapitre 5 Solution et réalisation   IP proxy transparent : cette option permet au firewall de rediriger de manière  transparente tout trafic réseau vers un serveur proxy local. Cela fait que les ordinateurs  pensent communiquer avec le serveur distant alors qu’ils sont connectés au proxy. La redirection est utilisée en définissant des règles de barrière pare- feu à l’aide de l’utilitaire ipchains . Il est à noter que pour un bon fonctionnement de la machine P, il serait préférable de choisir l’option « Optimiser comme un routeur et non comme hôte » dans les options réseau du noyau. D’autre part, puisque le but est de sécuriser notre plate -forme, il serait très utile d’activer l’option «  Protection contre l’inondation SYN  ». En fait le fonctionnement normal en TCP/IP est victime d’une attaque connue sous le nom d’inondation SYN. Cette attaque qui est de type déni de service (voir chapitre 1), empêche les utilisateurs légitimes de se connecter à l’ordinateur. En activant l’option «  Protection contre l’inondation SYN  », la couche TCP/IP utilisera un protocole cryptographique, connu sous le nom de « SYN cookies », pour permettre aux utilisateurs légitimes de continuer de se connecter même si la machine subit des attaques. 4.4 Logiciels utilisés 4.4.1 Le serveur web apache Les communications sur le Web sont régies par un protocole, nommé HTTP, Hypertext Transfer Protocol. Elles font appel à une architecture client-serveur fondée sur un système de requêtes et de réponses. Fondamentalement un serveur HTTP n’est rien d’autre qu’un serveur  de fichiers à l’écoute sur un port TCP (généralement le port 80). Lorsqu’il reçoit une demande de connexion suivie d’une requête, il répond en expédiant 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 bénéficie d’une richesse d’options impressionnante et en constante évolution. C’est de surcroît l’un des serveurs les plus performants disponibles à l’heure actuelle. Certaines fonctions disponibles avec Apache ne sont pas directement intégrées au serveur, mais proposées sous forme de modules rattachés lors de la compilation. Apache, peut fonctionner avec « inetd » ou en mode « standalone ». La différence se situe dans le fait qu’en mode « inetd  », un nouveau serveur sera lancé à chaque requête. Ce mode est acceptable si le site est de taille raisonnable avec une fréquentation acceptable, mais il peut représenter une charge machine trop importante dès lors que le nombre de connexions augmente. En mode « standalone », Apache gèrent au mieux le nombre de processus qu’il lance, ainsi démarre 85 Chapitre 5 Solution et réalisation d’emblée un nombre minimal de processus afin de répondre à quelques requêtes sans devoir  démarrer un nouveau serveur à chaque fois. Afin de ne pas trop occuper la mémoire 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 répertoire commun, dont le nom dépend de l’installation. Dans le répertoire racine, là où Apache a été installé, se trouve un dossier « conf  ». Ce répertoire comporte quatre fichiers, dont trois sont directement responsables de la configuration du serveur. Le quatrième contient une liste de types MIME . Les noms de ces fichiers sont les suivants : httpd.conf  : c’est le fichier de configuration principal d’Apache. Il est lancé en premier   et contient les paramètres de base nécessaires à l’exploitation du serveur Web. access.conf  : ce fichier règle les questions de sécurité d’accès. Il permet d’indiq uer  quels répertoires sont accessibles à tous les utilisateurs, de définir des restrictions pour d’autres répertoires plus sensibles, voire d’en interdire complètement l’accès à toutes les machines qui ne ferait pas partie d’un domaine donné. srm.conf  : il permet de définir les configurations qui concernent les ressources. Dans ce  sens ce fichier précise, les options de configuration relatives à l’organisation du site, qu’il s’agisse des répertoires contenant les documents ou des types de fichiers qu’ils représentent. mime.conf  : il précise au serveur comment retrouver le type MIME d’un document à  partir de son action. Conclusion Dans ce chapitre, nous avons pu voir les différents outils composant la plate-forme logicielle, qui a été mise en place au niveau de l’ONEP, pour permettre la vidéo surveillance dans la direction de system informatique. Cette plate-forme logicielle présente certains avantages très important, mais également quelques limites en matière d’interactivité et d’insertion d’o utils  pour le codage, l’indexation et la mesure de qualité. 86 Conclusion Conclusion Générale L’implémentation d’un serveur vidéo, qui fait l’objet de mon projet de fin d’étude, est une  partie intégrante de la réalisation d’une plate -forme de vidéo surveillance. J’ai donc posé, dès le départ, deux questions majeurs, à savoir : Comment réaliser un serveur de streaming ?  Comment compresser le flux vidéo ?  Vu les contraintes imposées en termes de système d’exploitation (Linux), nous avons opté  pour la solution RealSystem de RealNetworks. Cette dernière s’avère le meilleur non seulement sur Linux mais aussi sur les autres plates-formes. Elle comprend un ensemble complet d’outils pour créer l’architecture (serveur, proxy, codeur, client). En matière de sécurité, le système d’exploitation Linux, nous a permis de réaliser le control d’accès. Par ailleurs, grâce à des fonctionnalités propres à RealServer et RealProxy, concernant le cryptage et l’authentification, nous avons pu atteindre un niveau assez élevé de sécurité. 87 Conclusion Bibliographie [1] D.pam , a tutorial on MPEG/vidéo 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 vidéo pour IP », Réseaux & Télécoms, N°162, 7 avril 2006. [5] : Etudiants de l'option Ingénierie et Informatique pour le multimédia, « Recueil des exposés », 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 vidéo http://fr.wikipedia.org/wiki/Compression_video [13]: compression video, MPEG4 http://fr.wikipedia.org/wiki/MPEG-4 88