Embed Size (px)
Citation preview
1
Sommaire :
Liste des figures :..................................................................................................................................... 4
Liste des tableaux :.................................................................................................................................. 5
Liste des équations :................................................................................................................................ 6
Liste des abréviations : ........................................................................................................................... 7
Introduction Générale ............................................................................................................................ 8
CHAPITRE I : Le projet ENTHRONE.............................................................................................. 10
1. Introduction................................................................................................................................... 11
2. Les supporteurs du projet ............................................................................................................ 11
3. Architecture du Terminal ENTHRONE..................................................................................... 12
3.1 Conception du Terminal......................................................................................................... 12
3.2 Architecture Client/Server Distribuée .................................................................................. 14
3.3 Gestion des articles numériques ............................................................................................ 16
3.4 Point de départ pour le développement du Terminal ENTHRONE .................................. 17
4. Le projet VLC ............................................................................................................................... 18
4.1 Introduction à VLC ................................................................................................................ 18
4.2 Logiciels de la solution VideoLan .......................................................................................... 19
4.3 Client VLC............................................................................................................................... 19
4.4 Serveur VLC............................................................................................................................ 20
5. Conclusion ..................................................................................................................................... 21
CHAPITRE II : Technologies de communication avec les différents modules............................... 23
1. Introduction................................................................................................................................... 24
2. Communication par le protocole SOAP...................................................................................... 24
2.1 Qu'est-ce que SOAP?.............................................................................................................. 24
2.2 Messages SOAP ....................................................................................................................... 27
2.3 Utilisation de l’implémentation gSOAP ................................................................................ 29
2.4 Implémentation de SOAP dans ENTHRONE...................................................................... 34
3. Communication par socket .......................................................................................................... 34
2
3.1 Introduction aux sockets ........................................................................................................ 34
3.2 Position des sockets dans le modèle OSI ............................................................................... 35
3.3 Création d'une socket ............................................................................................................. 37
3.4 Implémentation de socket dans ENTHRONE...................................................................... 38
4. Le protocole RTSP ........................................................................................................................ 38
4.1 Pourquoi RTSP ? .................................................................................................................... 38
4.2 Les fonctions de RTSP ............................................................................................................ 39
4.3 Fonctionnement de RTSP....................................................................................................... 39
4.4 Méthodes RTSP....................................................................................................................... 39
4.5 Exemple.................................................................................................................................... 40
4.6 API de streaming utilisé dans le lecteur ENTHRONE........................................................ 43
5. Conclusion ..................................................................................................................................... 43
CHAPITRE III : Mesure de la qualité de service vidéo.................................................................... 45
1. Introduction................................................................................................................................... 46
2. Outil de surveillance de la qualité vidéo perçue : MQM (TDF) ............................................... 46
2.1 Objectifs du surveillant de PQoS de TDF............................................................................. 46
2.1.1 Introduction à PQoS ........................................................................................................ 46
2.1.2 Objectifs d'outil MQM .................................................................................................... 47
2.2 Approche de mesure de PQoS vidéo de MQM..................................................................... 47
2.3 Implémentation du MQM ...................................................................................................... 48
2.4 Exemples de résultats du MQM ............................................................................................ 48
2.5 Intégration de MQM dans le lecteur LaBRI ........................................................................ 49
2.5.1 Exécution de MQM .......................................................................................................... 49
2.5.2 Format du fichier image .................................................................................................. 50
2.5.3 Construction d’une image ............................................................................................... 51
3. QoS Probe pour le trafic multimédia .......................................................................................... 52
3.1 Présentation d’évaluation subjective..................................................................................... 52
3.2 Impact de perte de paquet...................................................................................................... 52
3.3 Impact de largeur de bande ................................................................................................... 53
3.4 Impact du nombre d'images par seconde ............................................................................. 55
3.5 L'impact du retard.................................................................................................................. 56
3.6 Modèle proposé ....................................................................................................................... 56
3
3.7 L’API du module de mesure .................................................................................................. 56
3.8 Intégration de l’API dans le lecteur ENTHRONE .............................................................. 57
4. Conclusion ..................................................................................................................................... 57
CHAPITRE IV : Les outils utilisés...................................................................................................... 58
1. Introduction................................................................................................................................... 59
2. Outils utilisés ................................................................................................................................. 59
2.1 Poste Linux .............................................................................................................................. 59
2.1.1 Caractéristique du système Linux .................................................................................. 59
2.1.2 Raisons du choix de Linux .............................................................................................. 59
2.2 Poste Windows......................................................................................................................... 60
2.3 PDA .......................................................................................................................................... 60
2.3.1 Définition........................................................................................................................... 60
2.3.2 Utilité du PDA .................................................................................................................. 60
2.3.3 Système d'exploitation ..................................................................................................... 61
3. La cross compilation ..................................................................................................................... 62
3.1 Principe .................................................................................................................................... 62
3.2 Compilateur ............................................................................................................................. 62
3.3 Installation des dépendances.................................................................................................. 62
3.4 Compilation de la version ENTHRONE Player................................................................... 63
3.4.1 Configuration de l’environnement ................................................................................. 63
3.4.2 Configuration du projet .................................................................................................. 64
3.4.3 Construction du lecteur ................................................................................................... 65
4. Conclusion ..................................................................................................................................... 65
Conclusion Générale ............................................................................................................................. 66
BIBLIOGRAPHIE................................................................................................................................ 68
4
Liste des figures :
Figure 1 - Vue globale des composants du Terminal......................................................................... 13
Figure 2 - Conception du Terminal ENTHRONE ............................................................................. 14
Figure 3 - Architecture globale du Terminal ENTHRONE.............................................................. 15
Figure 4 - La distribution du terminal ................................................................................................ 16
Figure 5 - Interaction entre le terminal et le serveur de contrôle..................................................... 17
Figure 6 - URL RTSP du client VLC .................................................................................................. 20
Figure 7 - Diagramme de service SOAP ............................................................................................. 25
Figure 8 - Conception de service SOAP.............................................................................................. 25
Figure 9 - Communication par socket en mode connecté.................................................................. 36
Figure 10 - Communication par socket en mode non connecté ........................................................ 36
Figure 11 - fonctionnalité de PQoS probe, et l'échelle de PQoS dans ENTHRONE ...................... 46
Figure 12 - Architecture du TDF MQM ............................................................................................. 47
Figure 13 - Interfaces de MQM ........................................................................................................... 48
Figure 14 - Résultats des PQoS en fonction de l’image affichée....................................................... 49
Figure 15 - Lancement de MQM ......................................................................................................... 50
Figure 16 - Perte de paquet pour 900 kbps......................................................................................... 53
Figure 17 - Courbes de perte de paquet.............................................................................................. 54
Figure 18 - Qualité basée sur le nombre d'images par seconde........................................................ 55
Figure 19 - PDA..................................................................................................................................... 60
5
Liste des tableaux :
Tableau 1 - Fichiers générés par gSOAP............................................................................................ 32
Tableau 2 - Position des sockets dans le modèle OSI......................................................................... 35
Tableau 3 - Vue d'ensemble des méthodes de RTSP ......................................................................... 40
6
Liste des équations :
Équation 1 - Modèle de perte de paquet ............................................................................................. 53
Équation 2 - Modèle générique de perte de paquet ........................................................................... 54
Équation 3 - Modèle de largeur de bande........................................................................................... 54
Équation 4 - Modèle de perte de paquet et de largeur de bande...................................................... 55
Équation 5 - Modèle de nombre d'images par seconde ..................................................................... 56
Équation 6 - Modèle de QoS proposé .................................................................................................. 56
7
Liste des abréviations :
AAC Advanced Audio Coding
API Application Programming Interface
AVC Advanced Video Coding DDI Distributed DI DI MPEG 21 Digital Item
DIA MPEG-21 Digital Item Adaptation
DID MPEG 21 Digital Item Declaration
DRM Digital Right Management
DVB Digital Video Broadcasting
EIMS ENTHRONE Integrated Management Supervisor
GUI Graphical User Interface
HTTP Hypertext Transfer Protocol
IP Internet Protocol
IPMP Intellectual Property Management and Protection
TDM Terminal Device Manager
MPEG Moving Picture Experts Group
MQM Media Quality Monitor
PDA Personal Digital Assistant
PQoS Perceived Quality of Service
QoS Quality of Service
REL Rights Expression Language
RPC Remote Procedure Call
RTP Real-time Transport Protocol
RTSP Real Time Streaming Protocol
SDP Session Description Protocol
SVC Scalable Video Coding
TCP Transmission Control Protocol
UED Usage Environment Description
URL Uniform Resource Locator
XML Extensible Markup Language
8
Introduction Générale
Les systèmes multimédia, également appelés terminaux, sont les arènes de communication directes
pour les consommateurs. Ils avaient évolué à partir des télévisions (TVs), des ordinateurs (PC), aux
dispositifs mobiles tels que les PDAs, les téléphones intelligents, etc... Les applications capables de
s’exécuter sur ces dispositifs peuvent changer considérablement en fonction de la puissance de calcul,
la résolution d'affichage et les possibilités de décodage. En outre, les terminaux peuvent se connecter
avec différents réseaux et systèmes de transmission, par exemple, Digital Video Broadcasting (DVB-
t/h), réseaux IP, Universal Mobile Telecommunications System (UMTS). Ils peuvent traiter plusieurs
formats de contenu, que ce soit standard ou non.
En même temps, l'Internet se développe d'un réseau simple de données à un réseau multiservices. Dans
cet environnement, les différents acteurs comme les fournisseurs de contenus, les fournisseurs de
services et les fournisseurs de réseaux, peuvent efficacement coopérer à offrir des services à valeur
ajoutée. Un exemple est le déploiement des services audiovisuels en temps réel avec une qualité de
service (QoS) contrôlée de bout en bout. L'introduction de la mesure de la QoS constitue une approche
très prometteuse comme dans le projet ENTHRONE.
Il est bien connu que les appareils de communication permettent également à des individus d'accéder à
l'information et la reproduire illégalement. Par exemple, le piratage du copyright de contenu
multimédia en utilisant des applications de peer-to-peer comme Bit Torrent et Emule, est susceptible
d'altérer les droits des propriétaires de contenus. Ce problème impose le développement des systèmes
de la gestion des droits numérique, pour la protection de la consultation des articles numériques. Le
projet ENTHRONE permet d’offrir une consultation légale de contenu multimédia.
Le projet ENTHRONE porte sur la génération et protection de contenu à grande échelle, sur
l'adaptation dynamique, la distribution et l'utilisation de contenu multimédia dans des environnements
géographiquement distribués. Ce modèle de distribution motive l'intérêt d'ENTHRONE à contrôler la
performance de la QoS de bout en bout.
9
J’ai partagé ce rapport sur 4 chapitres. Le premier chapitre fournit une présentation du projet
ENTHRONE et de l'architecture du terminal. Les critères de sélection d'un lecteur multimédia capable
de suivre la spécification de ce projet sont également étudiés dans ce chapitre. Le deuxième chapitre
présente les différentes technologies utilisées pour assurer la communication entre les entités
d'ENTHRONE. Le troisième chapitre présente les modules de mesure de la qualité de service intégrés
pendant la période de ce stage. Le dernier chapitre présente l'environnement de développement de la
nouvelle version du lecteur ENTHRONE.
10
CHAPITRE I : Le projet ENTHRONE
11
1. Introduction
ENTHRONE est un projet intégré dans le prioritaire thématique « technologies de la société de
l'information » dans le cadre du programme européen de la recherche et du développement. Une
première phase du projet connue sous le nom « ENTHRONE I » est déjà terminée, la deuxième phase
connue sous le nom « ENTHRONE II » a commencé le 1/9/2006 pour une durée de 24 mois.
Le projet ENTHRONE propose une solution de gestion intégrée qui couvre la totalité de la chaîne de
distribution du service audiovisuel, y compris l'opération de protection du contenu, la distribution à
travers les réseaux et la réception au niveau du terminal de l'utilisateur. L'objectif n'est pas d'unifier ou
d'imposer une stratégie sur chaque entité de la chaîne, mais d’harmoniser leurs fonctions.
Ce chapitre présente les participants dans le projet ENTHRONE, et détaille l’architecture du projet. Le
lecteur multimédia constitue l’entité la plus importante de ce projet et pour cela la sélection d’un
lecteur du monde d’Open Source reste une tache critique qui doit obéir à des critères bien déterminées.
Ce chapitre décrit les critères de choix du lecteur et fournit sa description et sa manière d’utilisation.
2. Les supporteurs du projet
Le consortium d'ENTHRONE est un ensemble d'organismes commerciaux et de services aussi bien que
des établissements et des universités de recherches qui ont une connaissance spécifique et une
expérience de valeur inestimable pour le projet ENTHRONE. Le consortium a été formé pour
introduire l'expertise et les qualifications nécessaires dans le projet.
Les associés dans le consortium représentent tous les acteurs impliqués dans la chaîne de livraison des
services multimédia, y compris les fournisseurs de contenu, les opérateurs de réseau, les constructeurs
des systèmes et des équipements et les instituts de recherches. Leurs efforts consistent à réaliser des
nouvelles activités de recherches et de développement proposées par le concept d'ENTHRONE.
Le consortium courant du projet se compose de 28 associés qui sont en majorité Européens. Ce
consortium géographiquement dispersé évoque une grande occasion d'échanger la connaissance et
l'expertise parmi les différents pays, recueillant les points de vue spécifiques de chaque associé pour
réaliser un ensemble complet et utile de résultats qui peuvent être transférés facilement au marché.
Au-dessous est la liste des associés dans le consortium actuel d'ENTHRONE :
• Ville de Metz (City of Metz)
• Electronics and Telecommunications Research Institute
• Siemens Aktiengesellschaft
• P&T Consulting
12
• Telecompare S.A
• BSoft SRL
• TDF
• Rohde and Schwarz
• Klagenfurt University
• Telefonica
• Tampere University of Technology
• Expway
• Rundfunk Berlin-Brandenburg
• Optibase Ltd
• Deutsche Telekom
• Institut for Rundfunktechnik GmbH
• Lancaster University
• NEC Europe Ltd
• Thales Research & Technology
• Universite de Versailles Saint-Quentin-en-Yvelines / PRiSM lab
• Ecole Polytechnique Federale de Lausanne
• Instituto de Engenharia e Sistemas de Computadores do Porto
• France Telecom
• Thomson Broadcast & Multimedia
• National Centre for Scoetific Research (Demokritos)
• Universitatea Politehnica din Bucuresti
• Universite Bordeaux 1 / LABRI lab
• University of Surrey
3. Architecture du Terminal ENTHRONE
3.1 Conception du Terminal
Le projet ENTHRONE vise à développer un terminal utilisateur conforme avec la norme MPEG-21 et
avec l'appui d’un surveillant de gestion intégré (ENTHRONE Integrated Management Supervisor
EIMS). Le nouveau terminal comporte plusieurs composants avec les nouvelles fonctionnalités
suivantes :
13
• gestion et traitement du contenu multimédia (gestion et protection des articles numérique,
configuration des paramètres du flux) ;
• surveillance et signalisation des paramètres de la qualité de service à l'EIMS pour effectuer les
actions nécessaires permettant de fournir le meilleur service à l'utilisateur.
QoSPackets
Terminal sideServer side
DID Server
GUIGeneration
(HTML)
WEBBrowserHTTP request (over IP)
Video (over IP/RTP/UDP)
DRMEngine
Network
RendererVideo
Audio Decoders
REL ENGINE
UDP
RTP
Terminal Metadata Formatter
Transmitter
MPEG-2 TS
QoSYUV/Audio
UCD (Universal Constraint
Description)
UED (Usage Environment Description)
Terminal Metadata Receiver
DRMEngine
IPMP Tools
Distributed DID Browser
TDM Web Services
Distributed TDM
TCP/IP Socket
DI MetadataReceiver
transmitter
Figure 1 - Vue globale des composants du Terminal
L'architecture représentée sur la Figure 1 donne une vue globale des composants du terminal et de leurs
relations. Le terminal se compose de EIMS TDM, DID Browser, QoS Probes, et du lecteur.
EIMS TDM, en temps que noyau du terminal, se communique avec tous les modules externes, exceptés
du module de streaming, puisque le flux multimédia doit être transmis directement du serveur aux
lecteurs multimédia. Les protocoles les plus utilisés pour la transmission du flux sont : IP, RTP et UDP.
La Figure suivante donne une autre vue du terminal, en termes de modules centralisés autour du TDM.
14
MPEG-21 Digital Items
TDM
EIMS
Network
MPEG-7 Description
MPEG-4 Media
IPMP Protection
QOS
Figure 2 - Conception du Terminal ENTHRONE
Le schéma fonctionnel ci-dessus montre l’interaction entre les différents modules du terminal ainsi que
les différentes normes mises en application :
• MPEG-21 pour la description des articles numériques ;
• MPEG-7 pour la configuration du flux ;
• MPEG-4 pour le flux multimédia ;
• IPMP pour la gestion et la protection de propriété intellectuelle
Le module de contrôle de la QoS est un composant non standard lié aux concepts spécifiques
d'ENTHRONE.
3.2 Architecture Client/Server Distribuée
La figure 3 illustre l'architecture globale du terminal ENTHRONE. Cette figure sépare l'affichage du
traitement des données. Par conséquent, le bloc marqué avec l'ellipse fourni l'affichage des données à
l’intermédiaire d’un navigateur web. Les modules restants : lecteur, EIMS TDM et DI Browser - sont
responsables du traitement. Dans la figure il est également possible de voir que l'EIMS TDM est
responsable de relier l'ensemble de modules composant le terminal.
15
Figure 3 - Architecture globale du Terminal ENTHRONE
La Figure 4 vise à illustrer la nature distribuée du terminal, ce qui offre au terminal une architecture
flexible. Lors de la conception du terminal, différents scénarios peuvent être implémenté :
• Tous les modules seront installés sur le terminal utilisateur.
• Un nombre minimal de modules sera installé sur le terminal utilisateur et le reste sera installé
sur une machine distante.
Un nombre minimal de modules sera installé sur le terminal utilisateur et les modules restant seront
dispersés sur plusieurs machines.
Ce qui suit sont les points essentiels à maintenir:
• Un ensemble minimal de modules est exigé pour être installé sur le dispositif terminal, à savoir
le lecteur et une partie de l'EIMS TDM (représenté comme TDM côté client), une partie du DI
Browser peut être également installé sur le dispositif terminal, surtout pour effectuer certaine
traitements des articles numérique; tous ces modules devraient être installés comme un seul
paquetage transparent
• L'EIMS TDM est en lui-même un module distribué.
• L'EIMS TDM relie tous les modules du terminal et est responsable des interactions avec
l'EIMS.
• Le TDM côté serveur et le DDI Browser ne sont pas exigés pour être installés sur la même
machine que l'EIMS.
16
Figure 4 - La distribution du terminal
Avec cette architecture distribuée, nous comptons agrandir la gamme des dispositifs soutenus. La
flexibilité d'une telle architecture permet la modification des modules (et de l'addition des autres
modules) tout en obéissant aux restrictions imposées par les terminaux, puisqu'elle permet une remise
en ordre qui peut aller jusqu'à avoir un nombre minimal de modules installés sur le terminal client à la
place d'avoir tous les modules installés sur ce dispositif.
3.3 Gestion des articles numériques
La conception du terminal sépare l'affichage du traitement des données. De cette façon, la gestion des
articles numériques peut être divisée sur deux étapes :
• Consultation des tous les articles disponibles sur tous les serveurs de distribution mises en
service ;
• Lecture des articles sélectionnés.
La deuxième étape ne peut pas être exécuté que si l’utilisateur dispose des droits nécessaires pour
consulter les articles sélectionnés. La figure suivante détaille les étapes de consommation du contenu.
17
Figure 5 - Interaction entre le terminal et le serveur de contrôle
Selon la figure 5, les étapes d’établissement d’une session sont les suivantes :
• GetDI : demande du DI Browser la liste des articles disponibles. Cette demande est
implémentée par le protocole SOAP détaillé dans le deuxième chapitre ;
• Le terminal reçoit une liste des articles disponibles et leurs adresses ;
• Selon le choix de l’utilisateur, le navigateur web envoi une demande de lecture des articles
sélectionnés. Les adresses des articles seront transmises en paramètres de la fonction d’appel ;
• StartSession : permet au lecteur de demander au TDM coté client de commencer une nouvelle
session basée sur la liste des articles transmise en paramètre ;
• CheckLicense : cette fonction est appelée par le TDM client pour se communiquer avec le TDM
serveur afin de vérifier si le client dispose de l’autorisation nécessaire pour consulter un article ;
• Si le client dispose du droit de consultation d’un article, alors le TDM serveur va envoyer la clé
correspondante, sinon une proposition d’inscription s’offrira au client.
3.4 Point de départ pour le développement du Terminal ENTHRONE
Le module le plus grand dans cette architecture sera sans doute le lecteur multimédia. Cette
caractéristique est due aux opérations que doivent être réalisée par ce module :
18
• Opérations imposées par le type de support d’accès à l’information : signalisation client/serveur,
contrainte temps réelle pour un support de la gamme best effort etc.…;
• Opérations imposées par l’architecture du projet ENTHRONE : vérification de droits
d’utilisation, mesure de la qualité de service perçue côté client, échange de données de
notifications avec les modules de l’architecture du projet ENTHRONE etc.…;
• Fonctionnalités traditionnelles d’un lecteur multimédia : codage Audio Vidéo, décodage
Audio/Vidéo, synchronisation de l’affichage des images etc.…
L’opération de développement d’un tel lecteur à partir de zéro peut constituer en elle-même un grand
projet à part. Mais dans un monde plein des projets Open Source, la tâche de trouver un lecteur muni
des fonctionnalités de base d’un lecteur multimédia ne constitue pas un grand souci, mais ce qui import
est de trouver le lecteur le plus convenable pour constituer le point de départ pour un futur lecteur
ENTHRONE. Pour cela, les critères suivants doivent être satisfaites :
• Open source ;
• Performant et à consommation optimale de ressource ;
• Développé en langage C/C++ ;
• Projet bien organisé et bien documenté ;
• Un lecteur multi plateforme ;
Parmi les projets disponibles, le projet VLC satisfait le mieux aux critères mentionnés. Et pour cela le
lecteur VLC à été choisi par LaBRI comme point de départ pour obtenir à la fin un lecteur
ENTHRONE.
4. Le projet VLC
4.1 Introduction à VLC
VideoLAN est une solution complète pour la lecture et la diffusion de vidéo par réseau, développée par
des étudiants de l'Ecole Centrale de Paris et des développeurs du monde entier, sous licence GNU
General Public License (GPL). VideoLAN est conçu pour diffuser des vidéos MPEG sur des réseaux
haut débit.
VideoLAN a été historiquement conçu pour la diffusion sur réseau, mais le principal logiciel du projet,
VLC media player, est devenu un lecteur multimédia tout en un multi plateformes.
Historiquement appelé VideoLAN Client, VLC media player est le principal logiciel de la solution
VideoLAN. VLC tourne sur de nombreux systèmes d'exploitation : Linux, Windows, Mac OS X,
BeOS, BSD, Solaris, Familiar Linux, Yopy/Linupy et QNX. Il peut lire :
19
des fichiers MPEG-1, MPEG-2 et MPEG-4 / DivX depuis un disque dur, un lecteur de CD-
ROM, ...
des DVDs, VCDs, et des CDs audio
depuis des cartes d'acquisition satellite (DVB-S),
De nombreux types de flux réseau: UDP Unicast, UDP Multicast (MPEG-TS), HTTP,
RTP/RSTP, MMS, etc.
Depuis des cartes d'acquisition ou d'encodage (sur GNU/Linux ou Windows seulement)
VLC peut également être utilisé comme serveur de diffusion de flux.
4.2 Logiciels de la solution VideoLan
La solution de diffusion VideoLAN comprend :
VLS (VideoLAN Server), qui peut diffuser des fichiers MPEG-1, MPEG-2 et MPEG-4, des
DVDs, des chaînes numériques satellite, des chaînes de télévision numérique terrestre et des
flux vidéos réseau en unicast ou multicast.
VLC (à l'origine dénommé VideoLAN Client) peut être utilisé comme un serveur pour diffuser
des fichiers MPEG-1, MPEG-2 et MPEG-4, des DVDs et des flux vidéo réseau en unicast ou
multicast ; ou comme un client pour recevoir, décoder et afficher des flux MPEG sous de
nombreux systèmes d'exploitation.
La solution utilisée le long de ce stage est celle offerte par VLC. Comme déjà dit, VLC est un projet
Open Source multi plateforme et capable de jouer le rôle d’un client ainsi qu’un serveur. Pendant la
phase de développement du projet ENTHRONE, LaBRI a développé des nouvelles versions de VLC
(client et serveur) avec des fonctionnalités supplémentaires, pour obéir aux besoins du projet.
Heureusement le mode d’emploi des versions de LaBRI reste identique à celui des versions de VLC
originaux.
4.3 Client VLC
Le client VLC utilisé pendant ce stage est destiné pour s’exécuter sous Windows CE. Son utilisation est
comme suit :
• Compilation de VLC à partir du code source ;
• Transférer le fichier construit « vlc.exe » sur un PDA ou n’importe quel périphérique
20
fonctionnant sous Win CE (Il n’y a pas de contraintes de choix de l’emplacement) ;
• Lancement de l’application ;
• Sélectionner le menu : File->Open Network Stream…
• Sélectionner l’onglet « Network » et cocher le bouton radio « RTSP » ;
• Suite à ce choix l’url va prendre la forme suivante :
Figure 6 - URL RTSP du client VLC
• Le format d’une URL RTSP est le suivant : « rtsp:// » + « adresse du serveur » + « nom du
fichier ». Par exemple : « rtsp://127.0.0.1/video ».
Le nom du fichier choisi doit référencer nécessairement un fichier disponible sur le serveur. Ce ficher
ne doit pas obligatoirement avoir le même nom que le nom de référence, mais le serveur peut faire une
liste de raccourcis de noms pour désigner un ensemble de fichiers disponible.
La partie suivante va expliquer plus en détaille le référencement de fichiers au niveau du serveur.
4.4 Serveur VLC
Le serveur VLC va servir pour diffuser le flux vidéo. Il est capable de fonctionner en plusieurs modes
de diffusion :
• Diffusion HTTP ;
• Diffusion RTP ;
• Diffusion RTSP.
En ce qui nous intéresse est de lancer le serveur VLC en mode de diffusion RTSP. Lancement du
serveur :
VLC : le nom du programme ;
-vvv : option pour l’affichage de tous les messages de VLC ;
-I : Interface à utiliser. Pour cet exemple c’est l’interface « telnet » ;
VLC -vvv -I telnet --rtsp-host 127.0.0.1 --vlm-conf vod.txt
21
--rtsp-host : l’adresse IP de l’interface que le serveur doit utilisé. Pour cet exemple l’adresse IP
utilisée est : 127.0.0.1 ;
--vlm-conf : indique l’emplacement du fichier de configuration. Pour cet exemple c’est le fichier
vod.txt ;
Le fichier « vod.txt » contient les liens URL à appeler par les clients. Un lien doit représenter un
fichier valide. Le nom du lien peut être différent que celui du fichier. Une autre remarque, un fichier
peut être représenté par plusieurs liens, mais un lien ne doit représenter qu’un seul fichier.
Maintenant on va voir le contenu de notre fichier « vod.txt » :
Chaque vidéo doit être configuré par un ensemble de lignes de configurations séparées par un seul
retour à ligne. Un retour supplémentaire à ligne indique qu’on a terminé la configuration du dernier
fichier.
Le serveur de diffusion est installé sous un système d’exploitation Linux. Pour cela on a choisi
d’utiliser un scripte pour sauvegarder la commande de lancement : on va créer un fichier nommé
« lancementServeur », ensuite on va y écrire la commande :
Pour le rendre exécutable, on fait appelle à la fameuse commande « chmod » :
Comme c’est remarquable, la commande « --vlm-conf » est suivit seulement par le nom du fichier de
configuration sans aucun chemin absolu. Cela veut dire que le fichier de configuration « vod.txt » est
enregistré dans le même répertoire que le script de lancement de serveur.
5. Conclusion
L’importance du projet ENTHRONE traduit la valeur technique des contributeurs ainsi que
l’importance des moyens et ressources alloués pour assurer une implémentation réussite. Dans le cadre
#chmod lancementServeur 755
vlc -vvv -I telnet --rtsp-host 127.0.0.1 --vlm-conf vod.txt
new robot vod enable setup robot input /root/robot.avi new science vod enable setup science input /root/science.avi new “la nature” vod enable setup “la nature” input “/root/la nature.mpg”
22
de ce projets deux types d’études ont été réalisés : études collectives pour le développement de
l’architecture globale du projet ENTHRONE ; et études individuelles réalisées pour la création d’un
modèle ou d’une architecture d’un module. Le but des travaux individuels est d’argumenter le projet
par les expériences et le savoir faire des participants. Mais pour arriver à travailler dans un milieu si
encombré, ainsi que pour réaliser un projet à très grande valeur, il est nécessaire de bien concevoir
l’architecture globale.
De ce principe l’architecture réalisée pour ce projet contribue énormément à sa réussite et à la bonne
collaboration entre les différentes équipes de recherches. Cette architecture est basée sur la notion de
modularité, où chaque module est développé par un ou plusieurs contributeurs selon leurs besoins et
leurs spécifications toute en assurant une façon transparente de communication avec les autres
modules.
Le chapitre suivant va introduire les technologies employées pour assurer la communication entre les
différents modules étudiés pendant ce stage.
23
CHAPITRE II : Technologies de communication avec les différents
modules
24
1. Introduction
L’architecture du projet ENTHRONE est constituée par plusieurs modules. Ces modules sont
développés généralement par plusieurs équipes, et pour cela on peut trouver plusieurs implémentations
différentes d’un seul module. La diversité des versions est justifiée par la différence du besoin de
chaque équipe. Mais le principe reste d’obéir au concept général du projet et d’assurer l’indépendance
de chaque module.
Pour assurer la communication d’un module avec les autres, chaque contributeur offre ça
documentation conjointement avec son module. Et puisque chaque module est capable de subir des
modifications et des mises à jour, il est indispensable de réaliser une interface inchangeable de
communication avec l’extérieur.
A partir de ce principe plusieurs protocoles standardisés sont utilisés par les modules de ce projet, mais
aussi il y a des autres protocoles utilisés qui sont développés par les participants. Les nouveaux
protocoles implémentés dans ce projet ont eu naissance suite à :
• l’absence d’un protocole standard capable de fournir l’ensemble des moyens nécessaires ;
• un besoin d’optimisation des ressources utilisées (utilisation optimale de la bande passante).
Pour montrer la façon d’intercommunication entre les différents modules, ce chapitre va expliquer les
techniques et les protocoles utiliser pour assurer un dialogue unique.
2. Communication par le protocole SOAP
2.1 Qu'est-ce que SOAP?
SOAP est un protocole de transmission de messages. Il définit un ensemble de règles pour structurer
des messages qui peuvent être utilisés dans de simples transmissions unidirectionnelles, mais il est
particulièrement utile pour exécuter des dialogues requête-réponse RPC (Remote Procedure Call). Il
n'est pas lié à un protocole de transport particulier mais HTTP est populaire. Il n'est pas non plus lié à
un système d'exploitation ni à un langage de programmation, donc, théoriquement, les clients et
serveurs de ces dialogues peuvent tourner sur n'importe quelle plate-forme et être écrits dans n'importe
quel langage du moment qu'ils puissent formuler et comprendre des messages SOAP. Il s'agit donc d'un
important composant de base pour développer des applications distribuées qui exploitent des
fonctionnalités publiées comme services par des intranets ou internet.
Prenons un exemple. Imaginez que vous ayez une base de données très simple d'une entreprise,
comprenant une table spécifiant le numéro de référence, le nom et le numéro de téléphone des
employés. Vous voulez offrir un service qui permet à d'autres systèmes de votre compagnie de
25
consulter ces données. Le service retourne un nom et un numéro de téléphone (un tableau de chaînes de
caractères à deux éléments) pour un numéro de référence d'employé donné (un entier). Le prototype de
service ressemble à :
Voici un diagramme de ce service:
Figure 7 - Diagramme de service SOAP
Face à ce genre de problème, l'approche du développeur SOAP est d'encapsuler la logique de requête
de la base de données, destinée à ce service, dans une méthode (ou fonction) en C ou VB ou Java etc. et
ensuite, de démarrer un processus qui écoute les requêtes adressées à ce service (un process listener),
ces requêtes étant formulées dans un format SOAP et contenant le nom du service et les paramètres
requis. Comme mentionné, la couche transport peut être HTTP mais pourrait tout aussi bien être SMTP
ou autre chose. Puis, le listener, typiquement écrit dans le même langage que la méthode du service
pour plus de simplicité, décode la requête SOAP entrante et la transforme en un appel de la méthode. Il
récupère le résultat de l'appel de la méthode, l'encode dans un message SOAP (la réponse) et le renvoie
au demandeur. Conceptuellement, cela donne:
Figure 8 - Conception de service SOAP
char ** getEmployeeDetails( int employeeNumber );
26
Alors que de nombreuses architectures spécifiques différentes sont possibles pour implémenter cet
arrangement, afin d'illustrer le propos, nous n'allons résumer qu'une seule possibilité spécifique.
Il existe bien sûr d'autres façons de construire un même service sans utiliser SOAP. Une façon évidente
est d'autoriser votre client à avoir un accès direct à une procédure stockée dans la base de données via
ODBC ou JDBC. Voici quelques raisons pour lesquelles vous voudriez choisir plutôt une solution
basée sur SOAP:
1. Avec une solution de type procédure stockée, vous ne pourrez pas envoyer ou recevoir des
structures de données complexes comme paramètre ou valeur de retour. Ceci est dû à la nature
des appels de procédures des bases de données relationnelles. Les paramètres de tels appels sont
limités à une liste de valeurs de type primitif (entiers, flottants, chaînes de caractères etc.). De
même pour les données retournées. Dans notre exemple simplifié de numéros de téléphone
d'entreprise, ce n'est pas un problème. Nous envoyons un numéro d'employé (un entier) et
recevons un nom et un numéro de téléphone (une paire de chaînes de caractères). Mais que se
passe t-il si votre service doit fournir le numéro de téléphone usuel de l'employé, plus une liste
d'autres numéros de téléphone valides pendant certaines périodes? Ce serait le cas si votre base
de données suivait les modifications de numéros de téléphone des employés lorsqu'ils partent en
voyages d'affaires. Maintenant, votre service doit retourner un type complexe de la forme:
Où le type TemporaryPhoneNumber défini par l'utilisateur est défini comme suit:
Notez que le nombre d'enregistrements de numéros de téléphone temporaires de l'employé en
question n'est pas limité. Le prototype de votre service ressemble maintenant à:
Le protocole SOAP est, lui, suffisamment puissant pour vous permettre d'encoder des structures
typedef struct EmployeeContactDetail { char *employeeName; char *phoneNumber; TemporaryPhoneNumber[] tempPhoneNumber; } EmployeeContactDetail, *p_EmployeeContactDetail;
typedef struct TemporaryPhoneNumber { int startDate; int endDate; char *phoneNumber; }TemporaryPhoneNumber, *p_TemporaryPhoneNumber;
EmployeeContactDetail getEmployeeDetails ( int employeeNumber );
27
de données de tous niveaux de complexité.
2. Le protocole SOAP permet d’appeler les fonctions distante par leurs nom, exactement comme si
elles sont des fonctions implémentées localement, et par conséquence le client n’est plus obligé
d’insérer un entête particulier pour faire différencier la méthode appelée des méthodes
disponible coté serveur.
3. Les APIs SOAP disponibles se chargent de l’encapsulation et de la décapsulation des messages
SOAP, alors ni le client ni le serveur n’est obligé de faire des traitements additionnels pour
l’envoie ou l’extraction des informations échangées.
2.2 Messages SOAP
Un message SOAP valide est un document XML au bon format. Le message doit utiliser l'enveloppe
SOAP et les namespaces d'encodage SOAP, et doit avoir la forme suivante:
• Une déclaration XML (optionnelle), suivie de :
• une Enveloppe SOAP (l'élément racine) qui est composée de:
• Une En-tête SOAP (optionnel) ;
• Un Corps SOAP.
Un dialogue RPC encodé par SOAP contient un message de requête et un message de réponse.
Considérons la méthode d'un service simple qui double la valeur d'un entier donné :
Prototype de la méthode :
Requête:
int doubleAnInteger ( int numberToDouble );
<?xml version="1.0" encoding="UTF-8" standalone="no" ?> - <SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> - <SOAP-ENV:Body>
- <ns1:doubleAnInteger xmlns:ns1="urn:MySoapServices"> <param1 xsi:type="xsd:int">123</param1> </ns1:doubleAnInteger> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
28
Réponse :
Le langage XML contient seulement une déclaration XML spécifiant la version de XML et l'encodage
des caractères du message XML :
Le tag de l'Enveloppe SOAP dans le message de requête est le suivant :
Il spécifie tout d'abord que le style d'encodage de ce message SOAP suit le schéma défini dans
http://schemas.xmlsoap.org/soap/encoding/. L'Enveloppe SOAP contient également des définitions
de namespaces. Les identifiants des namespaces sont standards et la spécification SOAP demande à ce
que ces namespaces soient définis correctement ou pas du tout (c à d qu'un message SOAP dans lequel
manquent des définitions de namespaces est correct et peut être exploité mais un message contenant
des définitions incorrectes, c à d non standards, est mauvais et refusé).
Vient ensuite le tag SOAP « Body » :
Ce tag n'a rien de remarquable en lui-même mais encapsule un unique tag de méthode qui porte le nom
de la méthode elle-même (ou, le même nom suivi du mot "Response" dans le cas du message de
réponse) :
Notez que le tag de la méthode reçoit typiquement le namespace correspondant au nom du service,
pour assurer l'unicité, dans notre cas :
<ns1:doubleAnInteger …>
<SOAP-ENV:Body>
- <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<?xml version="1.0" encoding="UTF-8" ?>
<?xml version="1.0" encoding="UTF-8" ?> - <SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> - <SOAP-ENV:Body>
- <ns1:doubleAnIntegerResponse xmlns:ns1="urn:MySoapServices"> <return xsi:type="xsd:int">246</return> </ns1:doubleAnIntegerResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
29
Le tag de méthode encapsule à son tour n'importe quel nombre de paramètres dans l'enveloppe de
requête, tel que le tag :
Les noms des tags de paramètres peuvent être n'importe quoi, sont typiquement autos générées et n'ont
pas de namespace. Dans le message de réponse, il n'y a qu'un seul tag de paramètre (représentant la
valeur de retour de la méthode) et il est typiquement appelé :
2.3 Utilisation de l’implémentation gSOAP
gSOAP est une implémentation du protocole SOAP en C/C++. Un des atouts de cette bibliothèque est
sa compatibilité avec plusieurs plateformes (dont Linux mais aussi Unix, Windows, Mac, Pocket PC,
QNX et PalmOS).
Cette collection d'utilitaires téléchargeables sur le site http://sourceforge.net/projects/gsoap2 va servir
pour argumenter le lecteur multimédia de LaBRI par une interface de communication avec le DI
Browser, ce qui veut dire que le lecteur va jouer le rôle de client SOAP et le DI Browser est le serveur
SOAP.
Dans cette partie je vais donner des exemples de code c/c++ faisant appel à l’implémentation gSOAP
pour montrer sa manière d’utilisation et pour montrer comment elle permet de générer une grande
partie du code source utile et nécessaire afin de réaliser un serveur SOAP ainsi que toutes ses interfaces
clientes. Il ne va pas rester que complété le corps des fonctions invoquées à distance : On peut
difficilement faire plus simple.
Avant de mettre en oeuvre un service web avec gSOAP, il faut disposer au moins d’un des éléments
suivants :
• Un fichier d'en-tête (.h) qui donne le prototype de chaque fonction appelée à distance,
• Un fichier WSDL qui spécifie les interfaces d'entrées et de sorties du service.
Un fichier WSDL sert à la création d’un fichier d’en-tête pour un service existant et ce fichier servira
par la suite au développement d’un client capable de communiquer avec le service. L’utilisation du
fichier WSDL reste optionnelle.
Nous allons ensuite partir du fichier d'en-tête pour générer tous les fichiers qui, après la compilation et
l'édition de liens avec notre propre code, nous permettra de disposer d'un serveur autonome et d'un (ou
<return …>
<param1 …>
xmlns:ns1="urn:MySoapServices"
30
plusieurs) client(s) SOAP (en utilisant soapcpp2).
Outre sa facilité de prise en main, ce framework offre de multiples avantages qui placent gSOAP dans
le peloton de tête de la liste des outils de développement SOAP disponibles sous Linux :
• Support des langages C et C++ (classes, polymorphisme, classes dérivées, certains objets de la
STL, ...),
• Support des implémentations 1.1/1.2 du protocole SOAP-RPC,
• Support des pièces jointes au format DIME permettant d'échanger des données binaires,
• Support du format de description de service WSDL 1.1,
• Support des cookies et des en-têtes SOAP,
• Support par défaut du protocole HTTP/1.1,
• Support de la compression des données avec la zlib (gzip) en natif avec HTTP,
• Support de l'invocation du service en mode fastCGI sur un serveur web (par exemple Apache),
• Support des transactions sécurisées en mode SSL (HTTPS),
• Support de l'ajout de nouvelles fonctionnalités par l'intermédiaire de plugins (en particulier,
dans les phases de sérialisation/dé sérialisation des données XML),
• Support et translation de tous les types standards (caractère, chaîne, entier, flottant, tableau et la
plupart des conteneurs majeurs de la STL : string, list, vector, ...).
• Faible signature mémoire : Idéal pour les équipements embarqués (90 à 150Ko !),
• L'implémentation en C est très efficace et minimise au maximum le temps de traitement d'une
requête SOAP,
• L'utilisation du multi-threading permet de produire des architectures d'une rare élégance,
Installation :
Récupérez l'archive gsoap-2.7.tar.gz (ou la dernière version stable) et installez-là de façon
traditionnelle :
# tar xzvf gsoap-2.7.tar.gz
# cd gsoap-2.7
# ./configure
# make
# make install
31
Premier client/serveur
Nous allons commencer par réaliser un service web en langage C.
Éditez un fichier service.h et copiez le morceau de code suivant :
gSOAP utilise des directives au début du fichier d'inclusion afin de récupérer certaines informations
comme le nom du service (messg), le type du service (rpc), la localisation (http://localhost:8060) ou
encore l'espace de nommage utilisé (messg).
Nous allons ensuite faire appel au pré processeur gSOAP afin de générer le squelette de la nouvelle
application:
Nous avons utilisé les options [-n] pour forcer l'utilisation d'un espace de nom, [-c] pour générer du
code source exclusivement en langage C et enfin [-p] afin de préciser le préfixe des fichiers générés
(sinon, les fichiers seraient tous préfixés par « soap »).
La fonction des principaux fichiers est résumée dans le tableau suivant :
# /usr/local/bin/soapcpp2 -n -c -pmessg service.h
[...]
# ls
messgC.c messgClientLib.c messgH.h messgmessgProxy.h
messgServer.c messg.test1.req.xml messg.wsdl service.h
messgClient.c messgmessgObject.h messg.nsmap messgServerLib.c
messgStub.h messg.test1.res.xml ns.xsd
//gsoap ns service name: messg
//gsoap ns service style: rpc
//gsoap ns service encoding: literal
//gsoap ns service location: http://localhost:8060
//gsoap ns schema namespace: urn:messg
int ns__test1( int code, char *message, struct ns__noResponse {} *out );
32
messgC.c Cœur de l’encodage/décodage des trames SOAP
messgServer.c Partie serveur du service web
messglient.c Partie cliente du service web
messgH.h Principal fichier d’inclusion du service
messg.nsmap Détail de tous les espaces de nom utilisés dans le service
messg.wdsl Description du service web dans le langage descriptif WSDL
Tableau 1 - Fichiers générés par gSOAP
Le moteur de ce nouveau service web est en place, il faut maintenant réaliser le coeur de l’application
serveur (la réception et le traitement des appels ainsi que le corps de la fonction distante ns__test1).
Le code suivant est à enregistrer dans un fichier serveur.c :
La structure "struct soap" contient le contexte d'un service SOAP ce qui explique pourquoi elle
apparaît à la fois dans la partie de réception des requêtes (serveur) et dans chaque fonction de
#include<stdio.h> #include<stdlib.h> #include "messgH.h" #include "messg.nsmap" struct Namespace *namespaces; int ns__test1(struct soap *p_soap, int p_code, char *p_chaine,
struct ns__noResponse *p_out){ int i; printf("Test1\n"); for (i=0; i<p_code; i++) { printf("%s\n", p_chaine ); } return SOAP_OK; } int main(int p_argc, char *p_argv[]){ struct soap v_soap; soap_init( &v_soap ); soap_set_namespaces( &v_soap, messg_namespaces ); if (soap_bind(&v_soap,NULL,8060,100) < 0) { return -1; } for (;;){ v_soap.accept_timeout = 1; if (soap_accept(&v_soap) < 0) { continue; } messg_serve( &v_soap ); soap_destroy( &v_soap ); soap_end(&v_soap ); } soap_done( &v_soap ); }
33
traitement d'une requête (premier champ obligatoire dans la fonction ns__test1).
La mise en place d'un serveur SOAP répond à la logique suivante :
• Initialisation du contexte SOAP avec soap_init,
• Assignation d'un espace de nom particulier avec soap_set_namespaces,
• Création de la socket mère de connexion sur le port 8060 avec soap_bind,
• Dans une boucle infinie de connexion :
o On accepte une connexion cliente avec soap_accept,
o On traite la requête avec messg_serve,
o On libère les données temporaires réservées pour le traitement de la requête avec
soap_destroy,
o Fermeture de la connexion socket avec soap_end,
o On ferme les connexions sockets clientes et serveur et on enlève les fonctions callback
avec soap_done (donné à titre indicatif dans l'exemple puisque l'on n'y arrive jamais).
Compilons maintenant le serveur :
Dans un autre terminal, on exécute le serveur afin de valider que le service tourne bien sur le port 8060
en TCP :
Passons à la réalisation de notre client SOAP en éditant un fichier client.c :
#include "messgH.h" #include "messg.nsmap" struct Namespace *namespaces; int main( int p_argc, char *p_argv[] ){ struct ns__noResponse out; struct soap v_soap; soap_init( &v_soap ); soap_set_namespaces( &v_soap, messg_namespaces ); soap_call_ns__test1( &v_soap, "http://localhost:8060", "", atoi(argv[1]),
argv[2], &out ); if (v_soap.error) { soap_print_fault(&v_soap, stderr); } soap_end( &v_soap ); return(0); }
# ./serveur &
# netstat -ntap | grep 8060
tcp 0 0 0.0.0.0:8060 0.0.0.0:* LISTEN 14380/serveur
# gcc -Wall -c messgC.c messgServer.c serveur.c
# gcc -o serveur serveur.o messgServer.o messgC.o -lgsoap
34
Peu de nouveautés dans ce code en dehors de la convention d'appel de la fonction distante (préfixée par
soap_call_), l'adresse du serveur et du port où se trouve le serveur SOAP (en HTTP) et le traitement
des erreurs (variable v_soap.error et fonction soap_print_fault).
La convention d'appel d'une fonction distante SOAP impose que le résultat se trouve dans le dernier
paramètre de la fonction : Lorsque l'on souhaite renvoyer plusieurs valeurs, il faut alors les encapsuler
dans une structure ou une classe.
Compilons maintenant le client:
2.4 Implémentation de SOAP dans ENTHRONE
ENTHRONE fait appel à la technologie SOAP pour assurer la communication entre le TDM Server et
le DDI Browser. Cette interface est basée sur le Web Services, où le DDI Browser joue le rôle du client
et TDM Server est le serveur. Elle fournit au DDI Browser les fonctionnalités exigées pour la
présentation complète des fonctionnalités de MPEG-21 DI.
Le DDI Browser est séparé en deux modules :
• DDI Browser display imbriqué dans le lecteur multimédia ;
• DDI Browser coté serveur,
Cette séparation minimise les fonctionnalités imposées sur le DDI Browser display.
Pendant ce stage j’ai assuré le développement d’un « DDI Browser display » intégré au lecteur LaBRI.
Pour cela j’ai utilisé la technologie SOAP.
La méthode SOAP utilisée est :
GetDI : Quand l’utilisateur veut consulter la liste des articles numériques disponible, il fait appel d’une
manière invisible à la méthode SOAP GetDI. Cette méthode sera acheminer vers le DDI Browser pour
recevoir la liste des articles disponibles sur les différents serveurs mises en service.
3. Communication par socket
3.1 Introduction aux sockets
La notion de sockets a été introduite dans les distributions de Berkeley (un fameux système de type
UNIX, dont beaucoup de distributions actuelles utilisent des morceaux de code), c'est la raison pour
laquelle on parle parfois de sockets BSD (Berkeley Software Distribution).
# gcc -c messgC.c messgClient.c client.c
# gcc -o client client.o messgClient.o messgC.o -lgsoap
# ./client 3 "Hello World"
35
3.2 Position des sockets dans le modèle OSI
Les sockets se situent juste au-dessus de la couche transport du modèle OSI (protocoles UDP ou TCP),
elle-même utilisant les services de la couche réseau (protocole IP / ARP).
Modèle des sockets Modèle OSI
Application utilisant les sockets Application
Présentation
Session
UDP/TCP Transport
IP/ARP Réseau
Ethernet, X25, ... Liaison
Physique
Tableau 2 - Position des sockets dans le modèle OSI
Il s'agit d'un modèle permettant la communication inter processus (IPC - Inter Process Communication)
afin de permettre à divers processus de communiquer aussi bien sur une même machine qu'à travers un
réseau TCP/IP.
On distingue ainsi deux modes de communication:
• Le mode connecté utilisant le protocole TCP.
• Le mode non connecté utilisant le protocole UDP.
Voici le schéma d'une communication en mode connecté:
36
Figure 9 - Communication par socket en mode connecté
Voici le schéma d'une communication en mode non connecté:
Figure 10 - Communication par socket en mode non connecté
37
Les sockets sont généralement implémentés en langage C, et utilisent des fonctions et des structures
disponibles dans le fichier header <winsock2.h>.
Une socket est une interface de communication introduite par les systèmes Unix pour la
communication réseau. Il s'agit d'un point d'accès aux services de la couche transport, c'est-à-dire TCP
ou UDP. La communication par sockets sur un réseau adopte un modèle client serveur ; en d'autres
termes pour communiquer il faut créer un serveur prêt à recevoir les requêtes d'un client. Une socket
peut être vue comme un descripteur identique à un descripteur de fichier dans lequel on peut lire ou
écrire des données. La configuration de l'ouverture de connexion permet de spécifier comment seront
transmise les données envoyées ou lues dans ce descripteur de fichier.
Dans tous les cas, avant d'utiliser une socket il faut la créer, c'est-à-dire créer un descripteur associé à
l'ensemble des informations constituant la socket (registres, adresse, port, état, etc.). Ensuite il est
possible de l'attacher à une adresse représentant l'adresse locale qui sera indiquée dans la
communication.
Côté serveur, la création de la socket est suivie d'une mise en attente de messages dans le cas d'une
communication UDP, ou de mise en attente de connexion dans le cas d'une communication TCP. Dans
le cas d'une communication TCP, il est généralement profitable de permettre au serveur de gérer
plusieurs connexions simultanées ; dans ce cas un nouveau processus sera créé pour chaque connexion.
Côté client, la communication se fait tout d'abord en renseignant l'adresse du serveur à contacter.
Ensuite peut avoir lieu l’envoi proprement dit de données ou la demande de connexion.
3.3 Création d'une socket
La création d'une socket se fait par la fonction socket dont la déclaration se trouve dans <winsock2.h>.
Cet appel permet de créer une structure en mémoire contenant tous les renseignements associés à la
socket (registres, adresse, etc.), il renvoie un descripteur de fichier permettant d'identifier la socket
créée (-1 en cas d’erreur).
Une fois la socket créée, il est possible de lui attacher une adresse qui sera généralement l'adresse
locale ; sans adresse une socket ne pourra pas être contactée (il s'agit simplement d'une structure qui ne
peut pas être vue de l'extérieur). L'attachement permet de préciser l'adresse ainsi que le port de la
socket. On attache une adresse à une socket à l'aide de la fonction « bind » qui renvoie 0 en cas de
int socket ( int domain, /* AF_INET pour l'internet */ int type, /* SOCK_STREAM pour une communication TCP */ int protocole /* 0 pour le protocole par defaut */ );
38
succès et -1 sinon.
3.4 Implémentation de socket dans ENTHRONE
Pendant ce stage, j’ai utilisé la technologie socket pour assurer la communication entre le TDM Client
le lecteur. Les fonctions échangées lors de cette communication sont :
• StartTDM : Commence une connexion entre le lecteur et le TDM. Cette fonction a besoin en
argument l’identifiant du lecteur, et elle donne en retour la socket connecté au TDM client.
• StartSession : Permet au lecteur de demander au TDM client d’ouvrir une session RTSP ;
• StopTDM : Termine la connexion entre le lecteur et le TDM.
• SendUED : Envoi des données de configuration spécifié par l’utilisateur ; ces données sont
utiles pour la négociation de la QoS.
Le TDM Client doit informer le TDM Serveur de toutes les activités du client. De cette façon,
l’administrateur peut contrôler l’activité de ses clients.
4. Le protocole RTSP
4.1 Pourquoi RTSP ?
Un des intérêts majeurs de l'Internet Multimédia est de pouvoir effectuer un Streaming du flux de
données.
Le Streaming consiste à découper les données en paquets dont la taille est adaptée à la bande passante
disponible entre le client et le serveur. Quand le client a reçu suffisamment de paquets, l'application
cliente commence à jouer un paquet, décompresse un autre et reçoit un troisième. Ainsi l'utilisateur
peut avoir le flux multimédia sans avoir à télécharger tout le fichier.
RTSP (Real Time Streaming Protocol) permet de contrôler la distribution de flux multimédias sur un
réseau IP. C'est un protocole de niveau applicatif prévu pour fonctionner sur des protocoles tels que
RTP/RTCP et RSVP.
Les flux peuvent provenir soit de clips stockés soit d'une source temps réel (caméra, micro).
RTSP a été développé par Real Networks, Netscape et l'Université de Columbia. Il est implanté sur les
produits de ces sociétés.
Le protocole RTSP est le protocole utilisé pour assurer la réception du flux multimédia par les lecteurs
int bind ( int descr, /* descripteur de la socket */ struct sockaddr *addr, /* adresse a attacher */ int addr_size /* taille de l'adresse */ );
39
ENTHRONE. Les parties suivantes vont décrire plus en détaille ce protocole.
4.2 Les fonctions de RTSP
RTSP offre des fonctions de type magnétoscope à distance (lecture, pause, avance rapide, rembobinage
rapide, arrêt...). Il peut être utilisé pour consulter un média sur un serveur de médias, inviter un serveur
de médias à rejoindre une conférence (dans le e-learning par ex), ou ajouter un média à une
présentation existante (formation d’une liste d’articles à lire successivement). RTSP peut être utilisé
aussi bien dans des applications unicast que multicast.
RTSP peut contrôler et synchroniser plusieurs flux audio ou vidéo. Il ne fournit pas lui-même le flux
qui est à la charge d'autres protocoles comme RTP.
RTSP est similaire, au niveau de la syntaxe et des fonctionnalités, à HTTP. Il utilise les URL et les
mécanismes complémentaires de HTTP peuvent être utilisés. Mais il y a deux différences essentielles:
• RTSP est un protocole à états nécessaire pour pouvoir corréler les demandes RTSP avec un flux
et dans RTSP le client et le serveur peuvent exprimer des requêtes.
• Il n'y a pas de notion de connexion dans RTSP, bien que le serveur maintient une session ayant
un identificateur. Une session RTSP ne correspond pas à une connexion de transport comme
TCP. Durant une session, RTSP peut ouvrir et fermer plusieurs connexions de transport à
chaque requête. Il est aussi possible d'utiliser un protocole de transport tel que UDP.
4.3 Fonctionnement de RTSP
Chaque présentation et chaque flux média est identifié par une URL RTSP. Une URL RTSP est de la
forme suivante :
Où :
• « host » doit représenter un domaine Internet valide ou une adresse IP ;
• « port » représente le port à utiliser. C’est paramètre optionnel.
• « chemin absolu » représente le chemin absolu du fichier à consulter. C’est paramètre optionnel.
4.4 Méthodes RTSP
Le tableau suivant décrit quelques méthodes utilisées par RTSP :
“rtsp:” + “//” + host [:port] [chemin absolu]
40
method direction object description
DESCRIBE C->S P,S recommended
GET_PARAMETER C->S, S->C P,S optional
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S, S->C P,S optional
TEARDOWN C->S P,S required
Tableau 3 - Vue d'ensemble des méthodes de RTSP
Noté sur le tableau ci-dessus : PAUSE est recommandée, mais pas exigée parce qu'on peut construire
un serveur entièrement fonctionnel qui ne soutient pas cette méthode, par exemple, pour les
alimentations de phase. Si un serveur ne soutient pas une méthode particulière, il DOIT renvoyer "501
Not Implemented" et un client NE DEVRAIT PAS essayer cette méthode encore pour ce serveur.
Parmi les méthodes ci-dessus, seulement 5 contribuent à définir l'état de la session:
• SETUP: Le client demande au serveur l'allocation des ressources pour un flux et commence
une session RTSP;
• PLAY: Le client demande la transmission des données d'un flux alloué selon SETUP;
• RECORD: Le client initie l'enregistrement selon les paramètres de la description de la
présentation;
• PAUSE:Le client arrête temporairement le flux sans libérer les ressources du serveur;
• TEARDOWN: Le client demande de libérer les ressources associées au flux. La session RTSP
cesse d'exister sur le serveur;
Les méthodes ci-dessus utilisent une entête Session pour identifier la session RTSP dont l'état est en
train d'être manipulé. Le serveur génère un identificateur session en réponse à la requête SETUP.
4.5 Exemple
Le client C demande un film des serveurs de médias A (audio.example.com) et V
(video.example.com). La "media description" est stockée sur un serveur web W. La "media
41
description" contient des descriptions de la présentation et de tous ses streams, y compris les codecs qui
sont disponibles, dynamic RTP payload, le protocol stack, et l'information contenu telle que la langue
ou les restrictions de copyright. Dans cet exemple, le client est seulement intéressé par la dernière
partie du film :
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057; server_port=5000-5001
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
V->C: RTSP/1.0 200 OK
42
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059; server_port=5002-5003
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
A->C: RTSP/1.0 200 OK
43
CSeq: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
Même si la voie audio et vidéo soient sur deux serveurs différents, et puissent commencer à des instants
légèrement différentes et puissent dévier l'un par rapport à l'autre, le client peut synchroniser les deux
en utilisant des méthodes RTP, en particulier l'échelle de temps contenue dans les rapports RTCP.
4.6 API de streaming utilisé dans le lecteur ENTHRONE
Le protocole RTSP est utilisé pour établir des sessions RTP entre le serveur de streaming et le lecteur
ENTHRONE de LaBRI. L’implémentation de ce protocole est assurée par l’API « live555 ». Cette API
est composée d’un ensemble de classes écrites en langage C++. Les deux classes les plus importantes
de la bibliothèque sont :
• RTSPClient : C’est la classe principale appelée par le terminal client. Elle permet l’instanciation
d’une session RTP et l’échange des messages RTSP pour contrôler la session en cours.
• RTPSource : Cette classe représente la session RTP en cours. Cette classe dispose d’un
ensemble de méthodes permettant le contrôle de la session : tailles des images, perte paquet,
durée de l’affichage d’une image sur l’écran du client etc. Cette classe est utilisée par le module
de mesure développé par Telefonica pour mesurer la qualité de service vidéo.
5. Conclusion
La communication entre les modules de l’architecture du projet ENTHRONE est réalisée à base de
plusieurs techniques et protocoles. La synchronisation lors de l’échange des données ne constitue plus
un souci dans le cadre d’une utilisation des APIs sûrs.
Ce projet est caractérisé par sont grand besoin à une connectivité entre ses modules, et le terminal
ENTHRONE est une organe très active capable d’ouvrir plusieurs connexions en même temps. Ces
connexions sont classées en deux familles :
• Connexions simples ;
44
• Connexions en parallèles.
La connexion avec le DI Browser est classée dans la classe des connexions simples puisque elle se
lance jusqu’à la réception des DI disponibles avec une indication sur les adresses des serveurs
correspondants. En ce qui concerne la connexion avec le serveur de streaming, elle se fait en parallèle
avec une deuxième connexion avec le module TDM Probe, et pour cette raison ces deux connexions
sont classées dans la famille des connexions en parallèles.
La connexion établit entre le lecteur et le TDM Probe doit être toujours maintenu tant qu’il y a
réception de flux multimédia. Cette nécessité est due à cause du besoin de EIMS TDM d’avoir une
information en continu sur le niveau de la qualité de service offerte au client.
Le chapitre suivant va traiter le principe de mesure de la qualité vidéo reçu par le client.
45
CHAPITRE III : Mesure de la qualité de service vidéo
46
1. Introduction
La deuxième mission à réaliser pendant ce stage consiste à intégrer un module de mesure de la qualité
de service vidéo perçu par l’utilisateur. Les modules disponibles sont développés par des participants
dans le projet ENTHRONE. Pendant ce stage deux modules de mesure sont intégrés avec succès dans
le lecteur multimédia développé par LaBRI. Ces deux modules sont :
• Media Quality Monitor (MQM) développé par TDF ;
• Le QoS Probe développé par Telefonica.
Ces deux modules sont représentés plus en détails dans la suite de ce chapitre.
2. Outil de surveillance de la qualité vidéo perçue : MQM (TDF)
Cette section présente l'outil développé par TDF pour évaluer la qualité des signaux vidéo utilisés dans
ENTHRONE, aussi bien que ses exemples d'exécution et de mesure de qualité. L'outil s'appelle MQM
(Media Quality Monitor).
2.1 Objectifs du surveillant de PQoS de TDF
2.1.1 Introduction à PQoS
PQoS (Perceived QoS) est l'évaluation de la qualité d'un service multimédia, comme elle est perçue
par une population utilisant le service. Une telle qualité est habituellement exprimée en utilisant des
valeurs numériques entre 0..100 comme définies dans la recommandation ITU-R BT.500, et indiqués
sur la figure 11. Des mesures de PQoS devraient être effectuées en utilisant un petit ensemble
d'utilisateurs du service, représentant la population des utilisateurs. Ces essais basés sur l'impression
humaine sont dites subjectifs et fournissent les seules mesures de référence de la PQoS, tandis que
n'importe quelle autre méthode employant des moyens de calcul serait objective.
Figure 11 - fonctionnalité de PQoS probe, et l'échelle de PQoS dans ENTHRONE
47
Le but des PQoS probes d'ENTHRONE telles que le MQM de TDF est de prévoir le PQoS des flux
multimédia. La performance d'un probe est exprimée par des paramètres statistiques tels que le
coefficient de corrélation entre les mesures de probe et les mesures subjectives.
2.1.2 Objectifs d'outil MQM
L'objectif de TDF MQM est de prévoir la qualité visuelle (PQoS) fonctionnant au niveau élevé de
l'application, c à d en utilisant les échantillons vidéo décodés. Il couvre les vidéos codées par MPEG-4,
transmis à travers n'importe quel réseau. Le MQM est conçu pour être mis en application dans un
terminal de surveillance, typiquement employée par un opérateur de service ou un opérateur de réseau.
Il peut également être mis en application dans n'importe quelle terminal d'utilisateur capable de
supporter la puissance de calcul exigée. Le MQM est également conçu pour se connecter à
ENTHRONE EIMS, spécifiquement le TDM.
2.2 Approche de mesure de PQoS vidéo de MQM
L'approche de mesure vidéo de TDF MQM est basée sur des développements précédents effectués pour
des formats de MPEG-2 et de MPEG-4 AVC. Dans ENTHRONE II, ces outils existants ont été
prolongés pour couvrir le format de MPEG-4 SVC, qui a présenté des changements significatifs du
codage vidéo.
La mesure de MQM PQoS est basée sur la mesure de plusieurs objets qui sont typiques pour des vidéos
codées en MPEG-4 et transmises sur un réseau. Un bas débit de codage ou une transmission avec perte,
mène à des erreurs non corrigées sur les blocs ou sur les données estimées de mouvement. Des erreurs
plus graves peuvent mener aux pertes de plus grandes parties de l'image et accomplir la perte des
images.
P1 (t)Videopictures Integra-
tion PQoS
Temporalintegration
P2 (t)
P3 (t)
Figure 12 - Architecture du TDF MQM
Le schéma ci dessus décrit l'architecture de TDF MQM. Elle calcule plusieurs paramètres pour détecter
le codage et le découpage en blocs adapté, et les distorsions. La métrique utilise un modèle perceptuel
pour calculer l'impact collectif de ces paramètres sur la qualité perçue globale, en tenant en compte la
48
sensibilité humaine: réaction, mémoire, réponse retardée.
2.3 Implémentation du MQM
Le MQM est une application autonome, qui est indépendante du lecteur car la mesure de PQoS est
basée sur la vidéo décodée. Le MQM ne fournit aucune interface utilisateur puisqu'il fonctionne
silencieusement dans l'arrière plan, en synchronisation avec le lecteur.
Le MQM se connecte d'une part au lecteur en utilisant des images en format YUV, et d' autre part à
l'EIMS-TDM (schéma suivant).
IP stream
PQoS meter
PQoS measurements
Video player
Decodedvideo
EIMS-TDM
Figure 13 - Interfaces de MQM
Le MQM est actuellement mis en application pour des plateformes Windows et les terminaux de type
PC. Il n’est pas possible de le mettre en application sur des petits terminaux telles que les PDAs, pour
des raisons de puissance de calcul. Le MQM est intégré avec terminal de BSoft, et suite à ce stage il est
intégré avec le terminal de LaBRI.
2.4 Exemples de résultats du MQM
Le MQM a été employé et examiné en utilisant des vidéos à basse résolution, correspondant aux
contraintes de la distribution vidéo en temps réel aux dispositifs mobiles, et des programmes typiques
de divers genres de contenu (documentaires, nouvelles, sports, annonces, films).
Le MQM fournit des valeurs instantanées de PQoS, chaque second, comme montré sur le schéma ci-
dessous pour une durée d’une minute. La vidéo utilisée est du genre documentaire avec un mélange des
ordres immobiles et modérés de mouvement. Car le débit de codage est constant, le PQoS change selon
le contenu. L'impact de réduire le débit binaire de codage est également remarquable, changeant de 85
(qualité très bonne) à 10 (très mauvais).
49
0
10
20
30
40
50
60
70
80
90
100
0 10 20 30 40 50 60
Time (s)
PQ
oS
64k_25fps128k_25fps256k_25fps320k_25fps512k_25fps
Figure 14 - Résultats des PQoS en fonction de l’image affichée
A partir de la courbe, on peut conclure que la valeur moyenne de PQoS est suffisante pour donner un
indice sur le niveau de la QoS perçue par l’utilisateur. Et par contre les mesures instantanées ne sont
pas suffisantes pour signaler une chute de la qualité : l’exemple le plus remarquable est les mesures
effectuées entre 15 et 18 secondes. Cette baisse considérable de PQoS n’est pas nécessairement due à la
mauvaise qualité vidéo reçu mais elle peut être expliqué par la nature de la séquence d’images incluse
dans la vidéo.
2.5 Intégration de MQM dans le lecteur LaBRI
L’intégration de MQM dans le lecteur LaBRI est réalisée sur la version PC. Cette version est
exécutable sur des plateformes Windows. La puissance de calcule exigée par le MQM empêche son
intégration sur la version PDA du lecteur.
2.5.1 Exécution de MQM
Le MQM est conçu pour tourner en arrière plan avec le lecteur, mais pour des raisons de
démonstration, on peut l’exécuter dans une console Windows :
50
Figure 15 - Lancement de MQM
Le nom de l’application de MQM est « tdf_qm.exe ». Cette application peut être installé n’import où
sur la machine. Comme c’est indiqué dans la Figure 15, l’application prend deux arguments en
paramètre :
• « 127.0.0.1 » : représente l’interface du PC que le MQM doit contrôler ;
• « 20000 » : pour dire que l’application doit contrôler des images.
Cette application est capable de faire des mesures même sur des flux RTP, mais notre intérêt pendant
ce stage est de profiter de ses mesures appliquées sur des images. Pour cela on introduit toujours
l’adresse « 127.0.0.1 ».
Pour calculer la qualité vidéo d’un flux, cette application commence par chercher un ficher nommé
« ipc.img » enregistré directement sur « C:\ ». Et par la suite elle calcule la qualité de l’image
enregistrée dans ce fichier. Mais ce fichier doit obéir à un format bien déterminer.
2.5.2 Format du fichier image
Pour bien traiter l’image, TDF impose qu’elle doit être enregistré sous un format bien déterminé. Ce
format est de la forme suivante :
• 32 octets à l’entête pour représenter les informations suivantes :
o II420 : code imposé par TDF ;
o Espace vide pour la séparation des champs ;
o width : largeur de l’image codée sur 8 octets, par exemple « 00000576 » pour une
image de largeur égale à 576 pixels ;
o Espace vide pour la séparation des champs ;
o height : hauteur de l’image codée sur 8 octets, par exemple « 00000240 » pour une
image de largeur égale à 240 pixels ;
o Espace vide pour la séparation des champs ;
o seq : ordre de l’image actuelle parmi les images reçues par le lecteur. Cette valeur est
codée sur 8 octets ;
51
• la représentation binaire de l’image. Cette représentation contient l’image dont les
caractéristiques obéissent aux données déjà fournis à l’entête. Sa taille doit être obligatoirement
égale à width × height × 1.5 octets. Elle doit être construite par le lecteur sous format YUV.
2.5.3 Construction d’une image
Le lecteur VLC utilise une structure en langage C pour sauvegarder les images. Cette structure est
déclarée dans le fichier header « include/vlc_video.h ».
Cette structure est définit comme suit :
Le pointeur p_data pointe sur les données de l’image sans aucune indication sur la taille. Toutes les
informations nécessaires sur la taille de l’image sont enregistrées dans la variable « format ». Pour
sauvegarder une image il suffit d’ouvrir un fichier avec le nom « ipc.img » en mode binaire, ensuite
utiliser la fonction « fprintf » pour y enregistrer les données.
struct picture_t { video_frame_format_t format; uint8_t *p_data; void *p_data_orig; plane_t p[ VOUT_MAX_PLANES ]; int i_planes; int i_status; int i_type; vlc_bool_t b_slow; int i_matrix_coefficients; int i_refcount; mtime_t date; vlc_bool_t b_force; vlc_bool_t b_progressive; unsigned int i_nb_fields; vlc_bool_t b_top_field_first; picture_heap_t* p_heap; int (* pf_lock) ( vout_thread_t *, picture_t * ); int (* pf_unlock) ( vout_thread_t *, picture_t * ); picture_sys_t * p_sys; void (*pf_release)( picture_t * ); struct picture_t *p_next; };
52
3. QoS Probe pour le trafic multimédia
La mesure du QoS du trafic multimédia est une tâche importante quand vous devez fournir un bon
PQoS. Dans des réseaux hétérogènes, le trafic multimédia peut souffrir des impairments multiples à
travers son chemin à la destination qui peut produire la dégradation de la PQoS, ainsi il est nécessaire
d'avoir quelques mécanismes qui peuvent traduire ces insuffisances en une seule mesure.
Le problème qui surgit quand vous traitez des mesures de la PQoS est la subjectivité. Les différents
utilisateurs auront différents avis pour le même flux multimédia, donc, l'opinion moyenne d'un grand
groupe d'utilisateurs est exigée.
Une bonne approche, généralement utilisée, est obtenir l'opinion de plusieurs utilisateurs et de calculer
l'opinion moyenne de la population. Le Mean Opinion Score (MOS) est une balance de 1 à 5 qui donne
une valeur de 5 quand la qualité est parfaite et 1 quand elle est vraiment mauvaise.
3.1 Présentation d’évaluation subjective
Quand nous traitons les flux vidéo, il y a des paramètres multiples qui peuvent changer entre deux
vidéos même si elles sont codées avec le même codec. La plupart des mises à jour définie différents
profils avec plusieurs résolutions, images par seconde, débits binaires, etc. Cette étude, consiste à
analyser la qualité perceptuelle pour la transmission vidéo avec différentes gammes des paramètres.
Deux séquences vidéo différentes ont été employées, qui ont été codées avec H.264 et un taux de 6,25 à
25 images par seconde. La largeur de bande des vidéos utilisées est entre 150 et 1500 kbps, et enfin, on
a présenté des pertes aléatoires simulées jusqu' à 10%.
Toutes les pertes de paquet présentées dans les vidéos d'essai ont été faites avec des pertes aléatoires
distribuées selon une fonction uniforme de densité de probabilité, ce qui signifie que tous les paquets
ont la même probabilité de se perdre.
Pendant la procédure d'évaluation subjective, chaque personne a observé un minimum de 10 vidéos
aléatoirement choisis parmi le dépôt et a évalué la qualité de la vidéo entre une valeur de 1 pour une
mauvaise qualité et 5 pour une qualité parfaite.
3.2 Impact de perte de paquet
La première étape pour traiter toutes les données recueillies était d'enlever les valeurs atypiques ; toutes
les données qui ont été déviées du moyen plus de 3/2 de l'écart type ont été enlevées. De cette façon
une relation directe estimée subjectivement entre les pertes de réseaux et le MOS est dérivée comme
représenté sur la figure suivante :
53
Figure 16 - Perte de paquet pour 900 kbps
Les équations obtenues pour les différentes valeurs de la largeur de bande analysée, peuvent être
modelées par :
( )
( )
( )
( )
( )6336.0
012.373.221.05391.0
5.2496.21757.05274.0
342.2333.21591.04721.0
041.2061.21343.0447.0
719.1545.106914.0
2
1500
2
900
2
600
2
300
2
150
++⋅+⋅−
=
++⋅+⋅−
=
++⋅+⋅−
=
++⋅+⋅−
=
++⋅+⋅−
=
llllf
llllf
llllf
llllf
llllf
Équation 1 - Modèle de perte de paquet
3.3 Impact de largeur de bande
Un autre facteur qui peut influencer sur la qualité du flux vidéo est la largeur de bande (débit binaire).
Pour cette raison, plusieurs largeurs de bande ont été étudiées. Les équations de l'Equation 1 vont servir
pour obtenir un modèle qui adapte toutes les courbes produites.
54
Figure 17 - Courbes de perte de paquet
( )1
321 2
qlplplplfL +
+⋅+⋅=
Équation 2 - Modèle générique de perte de paquet
La variation des valeurs des constants p1, p2, p3 et q1 pour les différents débits binaires, peut être
rapproché par les fonctions suivantes :
( )
( )
( )
( ) 3876.01019.4
10327.4
1075.11
307.195.13
125.2154.22
2823.01387.01
47
2
10
3
1000414.9
10000887.2
10008.7
10000584.1
1000885.8
10000721.2
+⋅
+⋅
−⋅
=
⋅−⋅=
⋅−⋅=
⋅+⋅−=
⋅−⋅
⋅−⋅
⋅−⋅
brbrbrbrQ
eebrP
eebrP
eebrP
brbr
brbr
brbr
Équation 3 - Modèle de largeur de bande
De cette façon nous pouvons décrire le rapport entre le débit binaire et la perte de paquet et comment
ils influencent dans l'obtention de la qualité perçue par les utilisateurs, dans l'équation suivante :
55
( ) ( ) ( ) ( )( )brQl
brPlbrPlbrPbrlfL 1321,
2
++⋅+⋅
=
Équation 4 - Modèle de perte de paquet et de largeur de bande
3.4 Impact du nombre d'images par seconde
Une étude intéressante de la façon de variation de la qualité perçue en fonction du nombre d'images par
seconde est montrée dans [4]. On a appliqué cette étude au cas du scénario de vidéo sur demande en
considérant que 30 images par seconde est le meilleur taux. Le résultat est représenté sur la figure
suivante :
Figure 18 - Qualité basée sur le nombre d'images par seconde
L'équation qui décrit la courbe de la dégradation de la qualité en fonction du nombre d'images par
seconde et réduit au minimum l'erreur quadratique moyenne est :
56
[ ]30 ,5 714.5
704.1164.100102.0)(2
∈∀+
+⋅+⋅−=
fpsfps
fpsfpsfpsf R
Équation 5 - Modèle de nombre d'images par seconde
3.5 L'impact du retard
Le retard est seulement important quand une interactivité élevée est exigée, comme dans la
vidéoconférence, tandis que dans des scénarios comme le vidéo streaming où un espace de sauvegarde
est créé et les données peuvent être téléchargées à l'avance, l'influence de ce paramètre disparaîtra
pratiquement.
3.6 Modèle proposé
La qualité perçue par l'utilisateur sera obtenue principalement à partir des valeurs du débit binaire et
des paquets perdus dans le réseau, cette valeur maximum sera influencée proportionnellement par le
nombre d'images par seconde. Par conséquent la formule finale employée pour obtenir la qualité perçue
du flux vidéo sera :
( ) ( ) ( )[ ][ ][ ]30 ,5
kbs 1500 ,150 01 ,0
,,,
∈∀∈∀
∈∀⋅=
fpsbrl
fpsfbrlffpsbrlMOS RL
Équation 6 - Modèle de QoS proposé
3.7 L’API du module de mesure
L’API développée par Telefonica est organisée de façon à ce qu’une seule classe reste en interaction
avec le lecteur. Le nom de cette classe est « TIDQoS ». Les méthodes utilisées pour la gestion du
module sont :
Cette méthode donne un pointeur sur l’instance unique de « TIDQoS ». Ce pointeur est unique
puisqu’une seule instance de « TIDQoS » doit contrôler la qualité de service du flux vidéo transmis au
client. Si cette méthode est appelée pour la première fois, alors une nouvelle instance de « TIDQoS » se
crée et le pointeur de cette instance sera renvoyé. Sinon, le pointeur de l’instance existante sera renvoyé
par la méthode.
static TIDQoS* createNew();
57
Une fois l’instance de « TIDQoS » est crée avec la méthode « createNew », la méthode « start » sera
utile pour commencer la mesure de la QoS. Cette méthode prend en argument une instance de la classe
« RTPSource » définit dans l’API « live555 ».
Cette méthode permet d’arrêter le contrôle de la qualité de service.
3.8 Intégration de l’API dans le lecteur ENTHRONE
L’organisation professionnelle du projet VLC facilite énormément l’opération d’intégration de l’API de
Telefonica dans le lecteur de LaBRI. Les modules intégrés dans VLC sont sauvegardés dans le fichier
« modules ». En ce qui concerne le module RTSP, il est implémenté dans le fichier
« modules/demux/livedotcom.cpp ». L’intégration du module de mesure s’effectue à partir du fichier
source « livedotcom.cpp ».
La compilation du lecteur reste sans changement. Cette opération est décrite plus en détaille dans le
chapitre suivant.
4. Conclusion
Les deux modules de mesure de la QoS décrits dans ce chapitre sont basés sur deux approches
totalement différentes, et ils sont développés par deux partenaires dans le projet ENTHRONE.
Pendant ce stage j’ai réussi à intégrer ces deux modules dans deux versions différentes du lecteur
multimédia développées par LaBRI. La réussite de ce stage est due à la bonne collaboration de TDF et
de Telefonica ainsi qu’aux outils mises à ma disposition.
Le chapitre suivant représentera les outils utilisés pour la réalisation de ce projet.
void stop();
void start( const RTPSource& source );
58
CHAPITRE IV : Les outils utilisés
59
1. Introduction
L’intérêt majeur de ce stage est d’intégrer des nouvelles fonctionnalités dans le lecteur multimédia de
LaBRI. Afin de progresser dans la phase de réalisation de ce projet, un ensemble de moyens matériels
ainsi que logiciels ont été mise à ma disposition.
Ce chapitre indiquera l’ensemble d’outils utilisés et expliquera le principe de la compilation croisée.
2. Outils utilisés
2.1 Poste Linux
2.1.1 Caractéristique du système Linux
Ces systèmes assurent une gestion asynchrone des processus qui permet d’exécuter les processus
concurremment. Pour assurer l’exécution « simultanée » de plusieurs processus ces systèmes utilisent
le temps partagé afin d’allouer des intervalles de temps d’utilisation CPU qui permettent d’exécuter
les processus à tour de rôle en plusieurs étapes.
Ces systèmes assurent une gestion des droits d’accès qui permet à plusieurs utilisateurs de travailler en
même temps sur la même machine. Ces systèmes assurent l’authentification des utilisateurs et contrôle
l’accès aux ressources de la machine. Ces ressources peuvent être les répertoires ou les fichiers présents
dans l’arborescence de la machine, mais aussi l’espace mémoire associé aux processus qu’exécute
l’utilisateur. Un tel système est un système multi-utilisateurs.
Les processus qui s’exécutent concurremment peuvent donc être des processus qui appartiennent à un
même utilisateur ou à plusieurs utilisateurs différents.
2.1.2 Raisons du choix de Linux
La majorité des systèmes linux appartient au monde des Open Source, ce qui donne une liberté de faire
des modifications sur des versions existantes pour les rendre plus convenables aux besoins du
développeur.
Le système Linux est jugé comme étant un système plus stable que les systèmes Windows disponibles,
sachant que la stabilité est indispensable pour le monde informatique.
Le système Linux est fortement favorisé par rapport aux systèmes Windows par une gamme complète
d’outils de développement. En plus de sa gratuité, la majorité des outils de cette gamme fait partie du
monde de l’Open Source.
La majorité des projets Open Source est développée sous une distribution Linux, ce qui fait de Linux le
meilleur système pour continuer le développement de ces projets.
Une poste de développement Linux peut être équipée d’un « système Linux sur mesure », c à d qu’on
60
peut concevoir un système Linux avec le minimum d’utilités pour garantir le maximum de performance
pour les taches principaux.
Linux dispose d’une gamme d’outils de compilation et de cross compilation pour plusieurs autres
systèmes. Ce qui fait qu’à partir d’un environnement de développement sous Linux, on peut compiler
des applications capables de s’exécuter sous Linux, Windows, PDA, Smart Phone, systèmes embarqués
et même sur des cartes à puce. Et tenant compte que la majorité des projets existants est développée
pour des systèmes Linux, l’opération d’utiliser un système Windows pour développer un même projet
sera très complexe.
En conclusion, le système Linux constitue l’environnement de développement le plus idéal.
2.2 Poste Windows
Une poste Windows était sacrifiée pour le bon déroulement de la réalisation de ce projet. Son utilité
consiste à jouer le rôle d’une interface entre la poste Linux et le PDA. Cette poste est équipée par le
logiciel « Activesync » de Microsoft. Ce logiciel sert pour configurer la synchronisation sur les
appareils compatibles Windows Mobile, des emails, du calendrier et des contacts avec le serveur via
GPRS.
2.3 PDA
2.3.1 Définition
Un PDA (Personal Digital Assistant, littéralement assistant numérique personnel, aussi appelé
organiseur) est un ordinateur de poche composé d'un processeur, de mémoire vive, d'un écran tactile et
de fonctionnalités réseau dans un boîtier compact d'extrêmement petite taille.
Figure 19 - PDA
2.3.2 Utilité du PDA
Le PDA est un ordinateur de poche dont l'usage est prévu originalement dans un but d'organisation. Un
assistant personnel fournit donc généralement en standard les application suivantes :
61
• Un agenda, pour l'organisation de l'emploi du temps, avec des mécanismes de rappel visuels ou
auditifs. Les rendez-vous et événements planifiés dans l'agenda peuvent être organisés, afin de
répondre à des besoins tant professionnels que personnels, grâce à une classification adaptable
(bureau, privé, etc.)
• Un gestionnaire de tâches faisant office d'aide-mémoire pour les tâches à effectuer. Une
priorité, des dates limites ou des mécanismes de rappel peuvent être affectées à chaque tâche.
• Un carnet d'adresses (gestionnaires de contacts), permettant d'avoir à tout moment sous la
mains les coordonnées de ses contacts (numéro de téléphone, adresse postale, adresse de
messagerie, etc.).
• Un logiciel de messagerie, rendant possible la consultation de ses mails ainsi que la rédaction
de nouveaux messages.
Les assistants personnels proposent des outils de bureautique allégés tels qu'un traitement de texte, un
tableur, une calculatrice, des visualiseurs pour un grand nombre de formats de fichiers (fichiers PDF,
images, etc.).
En plus de ces fonctions de base, de plus en plus de PDA proposent des outils multimédias avancés
permettant de lire des vidéos (dans les différents formats, y compris le format DivX), des musiques
(notamment au format mp3) ou des animations Flash.
Les PDA sont également de plus en plus utilisés pour des usages de géo localisation, de cartographie et
de navigation routière lorsqu'ils sont couplés à un dispositif de géo localisation (GPS, Global
Positionning System). En effet, pour un faible coût il est possible de disposer d'un système GPS
embarqué très performant permettant une navigation routière à l'aide d'une carte indiquant en
permanence sa position, la vitesse et une représentation visuelle de la route (éventuellement en 3D)
avec des instructions à l'écran et dictées par une voix de synthèse.
2.3.3 Système d'exploitation
Les PDA possèdent des systèmes d'exploitation dont la définition est adaptée à la résolution d'affichage
de l'écran et dont les fonctionnalités correspondent aux caractéristiques de ce type d'appareil.
Il existe plusieurs systèmes d'exploitation pour PDA, correspondant la plupart du temps à des types de
PDA différents et portés par des constructeurs différents. Les deux principaux systèmes sont :
• PalmOS, promu par la société Palm.
• Windows Mobile ou Windows CE (ou aussi Pocket PC), promu par la société Microsoft.
Ces deux systèmes possèdent à peu près les mêmes caractéristiques et les mêmes fonctionnalités avec
une prise en main différentes mais surtout des applications incompatibles entre les deux systèmes.
62
3. La cross compilation
3.1 Principe
La cross compilation (ou aussi la compilation croisée) consiste à compiler une application sous un
système Linux pour s’exécuter par la suite sur des autres systèmes d’exploitation. Une gamme de
compilateurs est disponible sous Linux pour construire des applications orientées pour différents
systèmes.
3.2 Compilateur
GCC est le nom générique de la suite d'outils de développement contenant, entre autres, le compilateur
C/C++ GNU développé par la Free Software Foundation. Cet ensemble est très souple et peut être
utilisé pour les différentes phases de production des binaires : prétraitement des fichiers sources,
compilation, assemblage et édition de liens. Il dispose d'un grand nombre d'options, et peut être
paramétré à l'aide d'un fichier de configuration.
GCC existe en plusieurs versions. La dernière version officielle disponible est la 3.0.3. Cette version
comprend un compilateur C/C++ et un compilateur Java. Le compilateur C++ est capable de
comprendre la plupart des constructions de ce langage, excepté le mot-clé export. Il existe également
une version plus ancienne mais nettement plus stable, la version 2.95.3, que l'on utilisera donc de
préférence si l'on ne recherche pas les dernières fonctionnalités du langage et de la norme C++. Cette
version ne comprend pas de compilateur Java.
La suite de développement GNU est certainement l'une des plus portables qui soit. Fondamentalement,
elle a été conçue pour être utilisée sous UNIX. Cependant, il en existe également des versions pour
d'autres systèmes d'exploitation.
3.3 Installation des dépendances
Pendant ce stage, l’intégration des nouvelles fonctionnalités était réalisée sur une version modifiée du
lecteur VLC. Mais cette version reste dépendante de plusieurs autres projets. Les bibliothèques les plus
importantes sont les suivantes :
• Codecs Audio/Video :
o liba52 - décodeur audio ATSC A/52 (aka AC3)
o libmad - MPEG
o libmpeg2 - décodeur vidéo MPEG1/2
o libavcodec (ffmpeg) - bibliothèque de codec audio/vidéo qui soutient plusieurs formats
comme MPEG4, H263, WMV/A etc.
63
o libvorbis - décodeur audio Vorbis
o libflac - décodeur audio FLAC (Free Lossless Audio Codec)
o libspeex - décodeur audio Speex (Free speech codec)
o libtheora - décodeur vidéo Theora
o libfaad2 - décodeur audio AAC
o libdv - décodeur vidéo DV
• Bibliothèques GUI :
o wxWidgets - un framework de GUI C++ multi plateforme qui garde le regard et la
sensation de chaque plateforme
o QT4 - un framework C++ multi plateforme
• Bibliothèques Audio/Video output :
o libsdl - une bibliothèque de multimédia multi plateforme conçu pour fournir un accès
bas niveau audio et vidéo
• Bibliothèques diverses :
o libdvdcss - une bibliothèque pour accéder aux DVDs chiffrés
o libdvdnav - une bibliothèque pour la navigation dans un DVD
o libdvdread - une bibliothèque pour la lecture des DVDs
o libdvbpsi - une bibliothèque conçu pour le décodage et la génération des tables de
MPEG TS et de DVB PSI
o fribidi - Une exécution libre de Unicode Bidirectional Algorithm
o liveMedia - Bibliothèques en C++ pour le multimédia streaming (RTP/RTCP, RTSP,
SIP)
La liste complète des bibliothèques utilisées par VLC est disponible sur [7].
3.4 Compilation de la version ENTHRONE Player
Comme la majorité des projets écrits en C/C++ sous Linux, l’opération de compilation de la nouvelle
version du lecteur ENTHRONE consiste à suivre les étapes suivante :
3.4.1 Configuration de l’environnement
Le système Linux peut servir comme environnement de compilation des projets en C/C++ pour
différentes plateformes. Cela est grâce à la disponibilité des outils de compilation capables de tourner
sous Linux pour générer des exécutables pour différents systèmes d’exploitation. Ce qui veut dire que
sur la même poste de travail Linux, on peut trouver une gamme d’outils de compilation pour les
systèmes Windows, Windows Mobile, Mac, Linux et même pour des systèmes embarqués. Et par la
64
suite, il est nécessaire de commencer par sélectionner les outils à utiliser.
Pour cela, on dispose de trois fichiers de configuration :
• ennwince : contient les options nécessaires pour rendre le système Linux prêt pour compiler
des applications pour Win CE ;
• ennlinux : contient les options nécessaires pour rendre le système Linux prêt pour compiler des
applications pour Linux ;
• ennwindows : doit contenir les options nécessaires pour rendre le système Linux prêt pour
compiler des applications pour Windows.
Etudiant le fichier « ennwince », ce fichier contient le code suivant :
Il est appelé de la manière suivante :
Après l’exécution de cette commande, notre système est prêt pour compiler des applications pour Win
CE.
3.4.2 Configuration du projet
Exécution du script de configuration « configure » avec les fonctionnalités nécessaires : l’activation ou
la désactivation d’une fonctionnalité s’effectue à l’intermédiaire de la commande « --disable-
<option> » ou « --enable-<option> ». Pour consulter la liste des fonctionnalités disponible, il faut
exécuter la commande suivante à partir d’une console Linux :
#. /configure --help
La commande de configuration exécutée pour la compilation du projet est la suivante :
Il claire que cette commande permet en plus d’ajouter et de désactiver des fonctionnalités, de
#source ennwince
export PATH=/usr/local/wince/cross-tools/bin:$PATH export CFLAGS="-D__stdcall= -D_OFF_T_ -I/usr/local/wince/cross-tools/include" export CFLAGS="$CFLAGS -I/usr/local/wince/contrib-xscale/include" export LDFLAGS="-L/usr/local/wince/cross-tools/lib -L/usr/local/wince/contrib-xscale/lib" export CC="arm-wince-pe-gcc -mcpu=xscale"
#./configure --host=arm-wince-pe --target=arm-wince-pe --build=i686-linux --prefix=/usr/local/wince/cross-tools --disable-sdl --disable-gtk --disable-dvdnav --disable-dvdread --disable-nls --disable-wxwindows --disable-a52 --disable-libmpeg2 --disable-freetype --disable-fribidi --disable-mad --disable-plugins --disable-sout --enable-optimize-memory --with-freetype-config-path=/usr/local/wince/contrib-xscale/bin --with-fribidi-config-path=/usr/local/wince/contrib-xscale/bin --enable-tremor --enable-faad --disable-vlm --enable-livedotcom --with-livedotcom-tree=/root/yousri/pfe/developpement/wince/live_wince/ --enable-realrtsp --disable-gnomevfs
65
sélectionner le compilateur et de spécifier le chemin des bibliothèques à intégrer.
3.4.3 Construction du lecteur
Suite à la configurer du projet, un fichier « Makefile » sera crée. Ce fichier est utilisé pour l’étape de
compilation, et il est exécuté par l’outil « make ».
Pour lancer l’opération de construction du projet il suffi de lancer la commande suivante à partir d’une
console Linux :
# make
Il est clair que « make » est appelé sans aucun argument, mais le bon fonctionnement de cette
commande nécessite la présence du fichier « Makefile » sous le même répertoire à partir duquel
« make » est exécuté. Cela est expliqué par la convention utilisée par la commande « make » de faire
appelle au fichier « Makefile » présent sous le répertoire en cours.
Plus de détailles de la commande « maker » peuvent être consultés à l’aide de la commande suivante :
# man make
4. Conclusion
L’utilisation de la compilation croisée est justifiée par la performance du système Linux et sa capacité
de construire des applications capables de tourner sur différents systèmes d’exploitations. Un système
Linux représente un système flexible capable de s’orienter pour n’importe quel fonctionnalité ; pour ce
stage on a utilisé un système Linux orienté développement. Et pour cet intérêt on a installé une gamme
de logiciels capables de satisfaire à tous les besoins.
Les différentes versions réalisées pendant de stage sont partagées sur un serveur FTP dédié aux
membres du projet ENTHRONE.
66
Conclusion Générale
Pendant ce stage une nouvelle version ENTHRONE Player a été développée pour obéir à toutes les
spécifications du projet ENTHRONE. A ce stade la tâche de développement d'un lecteur multimédia a
bien été achevée convenablement. En ce qui concerne les différents modules du projet ENTHRONE,
des travaux de recherche sont en train de s'effectuer dans le but d'offrir de meilleurs résultats. Le
développement du module de mesure de la qualité de service vidéo constitue l’étape la plus critique
parmi les étapes de conception des modules de ce projet Européen. Cette particularité est due à la
diversité des principes utilisés pour concevoir un modèle de mesure, sans oublier que la diversité des
normes vidéo utilisées ajoute encore un peu plus de complexité au modèle. Et puisque la satisfaction
relative à un service visuel dépend en premier lieu de la perception des utilisateurs, alors le modèle de
mesure doit nécessairement se baser sur les techniques de sondage, et cela avec une large catégorie
d'utilisateurs.
La complexité de développement d'un modèle de mesure de la qualité de service vidéo peut donc être
résumée par les points suivants :
• plusieurs approches sont disponibles,
• diversité des normes vidéo utilisées.
Le traitement de chacun des deux points précédents, pose une problématique relative à un ensemble de
sujets à étudier. D’abord concernant la variété des approches disponibles, on peut classer ces approches
dans deux catégories : approches simples et approches complexes :
• Pour une approche simple, une information sur le nombre de paquet perdu pendant une période
de temps sera suffisante comme input du modèle, pour offrir en output une valeur de mesure. La
simplicité de cette approche est évidente, puisque l'information sur les paquets perdus est très
facile à consulter et chaque librairie de distribution des flux multimédia offre les outils
nécessaires pour consulter les pertes. Mais une information du type “perte des paquets” est
insuffisante, puisque il n'y aura pas prise en considération du type relatif au paquet perdu et, par
conséquent, un modèle basé sur cette approche ne pourra pas offrir une satisfaction complète
mais peut, néanmoins, être utilisé pour donner une vue globale sur la qualité de service.
• Pour une approche complexe, une valeur de mesure ne va pas dépendre seulement d'une seule
67
donnée en input mais de plusieurs informations prises en considération de manière simultanée.
L’on peut citer, à titre d’exemple, le cas du format MPEG : une mesure significative de la
qualité de service doit dépendre du type de l'image du paquet perdu et de la longueur du GOP
auquel appartient l'image. Si le terminal utilisé est à mémoire limité (PDA ou appareil
téléphonique) alors le problème de manque de mémoire est un problème récurrent, et il influe
énormément sur la qualité vidéo. Un modèle de mesure idéal doit, aussi, prendre en
considération ce problème. Ce qui veut dire qu'une implémentation réussie d'un modèle basé sur
cette approche consiste à faire des modifications dans plusieurs modules du lecteur et assurer la
synchronisation entre ces modules en vue de fournir la bonne mesure de la qualité vidéo : tout
ceci se révèle donc très compliqué mais reste possible.
En ce qui concerne la diversité des normes vidéo utilisées, alors l'influence d'une perte d'un paquet sur
la qualité vidéo ne sera pas identique pour toutes les normes, ce qui veut dire qu'un modèle parfait doit
tenir compte de toutes les normes utilisées.
Pendant ce stage j'ai réussi à intégrer un module de mesure capable de mesurer la qualité vidéo à partir
du nombre de paquets perdus. J’ai également réussi à intégrer un autre module basé sur la qualité de
l’image reçu. Par la suite, j'ai pu commencer le développement d’un autre module plus complexe. Mais
celui-ci a besoin d’encore plus de temps et de travail afin d’y intégrer la prise en charge de la diversité
des normes vidéo utilisée dans le cadre du projet ENTHRONE.
68
BIBLIOGRAPHIE
[1] ENTHRONE I Deliverable 29 “MPEG-21 Terminal Implementation”, July 2005.
[2] Lionel Tricon : Initiation aux Services Web et mise en oeuvre en C/C++ avec gSOAP.
[3] Recommandation UIT-T H.262 : Technologies de l'information – Codage générique des images
animées et du son associé: données vidéo.
[4] Apteker RT, Fisher JA, Kisimov VS, Neishlos H., “Video acceptability and frame rate”, IEEE
Multimedia, 1995.
[5] Johannesson NO. The ETSI computation model: a tool for transmission planning of telephone
networks. IEEE Communications Magazine 1997;35:70-9.
[6] Rix AW. Perceptual speech quality assessment - a review. Proceedings of IEEE International
Conference on Acoustics, Speech, and Signal Processing, Montreal, 2004. p. 1056-9.
[7] www.videolan.org
[8] www.soapuser.com
