4.1 Introduction
Notre système est destiné à être déployé dans un environnement de stations légères. D’ailleurs, le système est appelé à communiquer dans un environnement très hétérogène. En effet, les utilisateurs de notre système de streaming peuvent posséder divers équipements (Smartphone, ordinateurs portables, assistants personnels, etc.) fonctionnant sous différents systèmes d’exploitation (en ce qui concerne le serveur). Nous nous sommes donc attachés à ce que le code du système soit portable, en vue de faciliter son déploiement.
Aussi, le système emploie-t-il de manière interne plusieurs modes de communication, à savoir l’appel de procédure à distance (RPC) ainsi que la transmission de données audiovisuelles en temps réel. Afin de faciliter la mise en œuvre de la communication au sein de notre prototype, l’utilisation de bibliothèques appropriées nous a semblé nécessaire. En outre, des bibliothèques permettant la manipulation des données multimédias sont également indispensables pour l’adaptation de celles-ci.
Par ailleurs, nous avons décidé de bâtir le prototype sur l’utilisation de processus légers (threads). Ceci est motivé d’une part par le fait que d’un point de vue système, un thread consomme moins de ressources à sa création qu’un processus ordinaire. D’autre part, les communications basées sur une architecture émetteur/récepteur sont bien adaptées à l’utilisation de threads.
4.2 Description formelle du système
Nous travaillons ici dans un environnement de réception constitué d’équipements légers, dotés des caractéristiques limitées. Dans cette sous-section nous présentons les différentes problématiques auxquelles nous sommes confrontées et les solutions envisagées pour y palier. Nous présentons notre architecture de système de streaming vidéo adaptatif en environnement réseaux instables et légers.
Les temps morts : Les temps morts en streaming vidéo représentent les moments de privation des données au lecteur. Ceci se manifeste par l’observation d’une image figée sur l’écran, et sont causés par la dégradation des conditions réseaux qui entraîne l’absence de fluidité dans la transmission des données audiovisuel du serveur vers le client. Pour résoudre ce problème, notre système garantit qu’il y aura toujours suffisamment de données dans le buffer de réception du lecteur client. Ceci grâce au modèle d’encodage en couche qui permet d’envoyer des couches d’images de taille réduite mais proche d’un point de vue visuel de l’image original.
Bande passante faible : Le streaming vidéo est une application réseau aux exigences énormes en terme de bande passante. Ceci est dû au caractère volumineux des fichiers vidéos et leur contrainte en terme d’isochronisme (exigence en cadence d’affichage des images d’une séquence vidéo). Afin de contourner cette difficulté, notre système préconise la décomposition de la vidéo en couches superposables, de telle sorte qu’en fonction des fluctuations des capacités du réseau, la vidéo est transmise sous forme d’images de petites tailles mais proche en terme visuel des images normales de la vidéo. Celles-ci sont progressivement améliorées suivant la qualité du réseau. On a au moins la garantie qu’une qualité, même si pas assez bonne, pourra être transmise dans ces conditions.
Communication client-serveur pour l’estimation de la qualité appropriée : Afin de déterminer la qualité ou plus précisément les couches à transmettre, le serveur échange périodiquement des données de services (taux de perte, gigue, débit) avec les clients. Ceci permet au serveur de déterminer quelle portion de la vidéo en terme de niveau et de nombre de couches doit être transmise à un instant donné, sans risque d’inadaptation aux conditions réseaux (les conditions réseaux peuvent fluctuer énormément dans un réseau sans fil de station légère.)
4.2.1 Fonctionnalités offertes par le serveur
Afin d’illustrer les différentes tâches que notre serveur effectue en réponse à des requêtes demandant l’accès en streaming à des séquences vidéos, nous utilisons un modèle fonctionnel à six composants : un système de stockage stable, un gestionnaire de bande passante,un encodeur, un synchroniseur, un système d’horloge virtuelle et un gestionnaire de transmission. Ces composants travaillent en collaboration dans le processus d’acheminement des données audiovisuelles (voir Figure 4.1).
Mémoire stable : La mémoire du serveur est l’endroit où sont stockés les fichiers multimédias faisant partie de la base de données multimédia du serveur de streaming. À cause de son caractère critique, cet espace de stockage doit être stable afin de garantir qu’un fichier multimédia demandé par un client sera effectivement diffusé pour ce dernier. Plusieurs techniques permettent de rendre une mémoire stable. On peut citer entre autres, LVM et RAID.
Encodeur : Ce module est chargé de récupérer les fichiers vidéo en mémoire stable et de les encoder en couches superposables. Ceci afin de permettre à notre serveur de streaming de pouvoir assurer la diffusion des couches en fonction des conditions réseaux.
GBP (Gestionnaire de Bande Passante) : Ce module est en charge de l’estimation des conditions réseaux. Les informations de synchronisation avec le client passent également par ce module. Par exemple lors de la création de l’horloge virtuelle associée à un client dans le serveur (décrite à la sous section IV), les données de synchronisation des horloges passent par ce module.
Synchroniseur : le module de synchronisation a un impact interne et externe au serveur. Interne dans la mesure où, c’est lui qui est chargé de réguler les différents fux (audio, vidéos, soustitre) de façon à les rendre cohérents ; mais aussi c’est lui qui est en charge de l’élection des couches à transmettre afin de respecter les spécifications de notre système de streaming adaptatif. Le module de synchronisation dans son impact externe contrôle l’évolution du lecteur client sous la cadence d’une horloge synchronisée avec l’horloge locale du client.
Ceci dans le but d’éviter de transmettre une portion de vidéo qui n’aurait plus de raison d’être transmis car ne pouvant plus être traité par le lecteur client (ce sont les exigences du temps réel).
FIGURE 4.1 – Serveur de streaming
Horloge virtuelle : Le serveur entretient une horloge virtuelle associée à chaque client. Cette horloge est réglée à la même heure que celle du client (processus décrite à la section IV), et permet une lisibilité de l’évolution synchrone du lecteur client.
Module de diffusion : Ce module est en charge de la diffusion proprement dite c’est avec ce module que le client interagit pour la réception du contenu audio-visuel. Le module serveur est à l’image de celui présenté à la Figure 1.12 (Composants d’un serveur de streaming), à la différence que le gestionnaire de stockage interagit avec le système de stockage des vidéo encodées en couches superposables.
Notre système comme tout d’application de streaming, fonctionne selon le modèle client/serveur. Cela signifie que des clients (stations légères dans un réseau sans fil) contactent un serveur qui leur fournit le service de réception en continu d’un flux audiovisuel immédiatement décodable. Le client est l’élément chargé de recevoir le streaming vidéo. Dans notre cas, nous avons à faire aux équipements légers (smartphones) dans un réseau sans fil. L’ensemble des modules du client (cf Figure 4.2) concours a la bonne marche du streaming et la minimisation des coûts en calcul.
4.2.2 Fonctionnalités offertes par le client
Dans notre système de streaming, la partie qui est en contact direct avec les utilisateurs est le lecteur audiovisuel. Dans la terminologie du génie logiciel, le lecteur audiovisuel est appelé client. Le client est l’application permettant de lire des données audiovisuelles ; il permet de les décoder et de les restituer. En plus, il comporte une interface utilisateur qui prend en compte certains désirs des usagers par le biais d’un certain nombre d’interactions. Dans la suite, nous introduisons les trois composants principaux du client : le gestionnaire de bande passante, le gestionnaire de buffer et le lecteur proprement dit. La figure 4.2 donne une représentation de notre client.
FIGURE 4.2 – Architecture du client de streaming.
En raison de leur nature extrêmement volumineuse, les données audiovisuelles sont emmagasinées et transmises sous forme compressée. Le décodeur est le composant chargé de décompresser (décoder) les données avant leur restitution. Un décodeur est souvent spécialisé dans la décompression de données audio ou vidéo. On parle alors de décodeur audio et décodeur de vidéo. Plus les décodeurs disposent d’algorithmes de décodage, plus le lecteur est capable de lire de formats de données différents.
GBP (Gestionnaire de Bande Passante) : La gestion de bande passante est essentielle dans une application de streaming vidéo. C’est le gestionnaire de bande passante qui a pour mission d’évaluer cette ressource cruciale pour l’adaptabilité du streaming.* Dans notre système, il est également en charge de l’établissement de la connexion avec le serveur.
Gbuffert (Gestionnaire de buffer) : C’est le module en charge de la manipulation du buffer de réception du streaming et d’adapter le contenu de ce buffer au lecteur interne en s’occupant de la fusion des couches avant lecture effective. En effet, les données en provenance du réseau sont stockées dans la première partie du buffer de réception (8 premières secondes). Le gestionnaire de buffer s’occupe de la décompression et de la production de la deuxième partie du buffer en image lisible par lecteur. Les couches décompressées dans la première partie du buffer peuvent éventuellement subir, des opérations supplémentaires telles que la fusion des couches issues d’une même image.
Module client : Ce module encore appelé lecteur, est chargé de restituer les images à l’utilisateur. Il lit principalement les données dans la deuxième partie de buffer (2 dernières secondes). Il est à noter que ce buffer est tournant car, une fois que la tête de lecture du lecteur a parcouru cette portion du buffer dans son intégralité, cette tête de lecture retourne en début de la zone des 2 secondes pour lire la suite de la vidéo (cf figure 4.3).
FIGURE 4.3 – Buffer tournant
4.3 Mise en oeuvre
Notre principal objectif, lors de la mise en oeuvre du système de streaming, était de fournir une implémentation efficace de ces différents modules, tout en garantissant une bonne ergonomie à ces interfaces graphiques. Dans ce qui suit, nous détaillons l’implémentation des différents composants de notre prototype, à savoir l’encodeur et le diffuseur pour ce qui est du serveur, et le Lecteur pour le client
4.3.1 Serveur
Le serveur étant décomposé en 6 modules, nous exposons ici les deux principales : l’encodeur et le diffuseur.
Encodeur : C’est un module indépendant chargé de produit des vidéos répondant aux spécifications de notre idée (séquences d’images issues de la décomposition des images originaux en couches superposables).
Le diagramme de classe de ce module est donné par la figure 4.4.
FIGURE 4.4 – Diagramme de classe du module d’encodage vidéo.
L’algorithme d’encodage est donnée ci-après :
Les fichiers encodés par cet algorithme repondent aux spécifications de l’encodage multicouche proposé dans ce mémoire.
Diffuseur :
Comme nous l’avons vu dans la Section 4.1, le diffuseur est le module responsable de la diffusion en continu des données audiovisuelles entre le serveur et les clients. Ce moteur de streaming possède une architecture multithreadée. Un des objectifs que nous nous sommes imposés lors de l’implantation du diffuseur est de le gratifier d’une interface graphique (GUI) permettant aux usagers de le configurer facilement. Cette interface s’affiche au lancement du serveur. L’usager est ainsi appelé à paramétrer son moteur de streaming en fonction de ses besoins. En fixant le nombre maximal de flux simultanés, un usager peut éviter que son matériel ne soit submergé par la charge de streaming. Le diffuseur est ensuite démarré et attend qu’un client lui soit attribué par le Gestionnaire de bande passante qui détient les paramètres d’identification de chaque client nouvellement connecté. Le diffuseur s’occupe alors de la transmission du flux demandé vers le client, suivant l’algorithme du gestionnaire d’indexation décrit ci-dessous.
4.3.2 Langages et Outils
Choix du langage : Les langages utilisés sont le C/C++. Ces langages disposent de bibliothèques riches, et sont supportés par la plupart des architectures et systèmes d’exploitation existants (Windows, Linux, Unix, …). C’est un langage proche du système, l’encodage de la vidéo et la diffusion des paquets sera donc plus rapide qu’avec un langage de plus haut niveau tel que JAVA. De plus les communautés autour de ces langages sont nombreuses ce qui nous permettra de bénéficier d’une documentation assez importante. Ce langage nous offre généralement la possibilité d’utiliser la bibliothèque LibVLC qui contient l’ensemble des fonctions nécessaires à l’implémentation de la partie streaming de notre projet. De plus cette bibliothèque est compatible avec la bibliothèque Qt qui nous a permis de créer notre interface graphique.
Choix des bibliothèques : après des multiples recherches et tests, notre choix s’est porté sur les bibliothèques suivantes :
Manipulation de la vidéo : FFMPEG et AVCON ont été choisis pour leur bonne intégration aux langages C/C++. il est à noter que ces bilbiothèques sont écrites en C/C++.
Manipulation des images : La bibliothèque OPENCV offre un large éventail de fonctions pour la manipulation des images au pixel prêt
Diffusion multimédia : Live555 sous Gstreamer et LibVLC offfrent des fonctionnalités pour une diffusion sous un protocole standard RTP,RTSP, RTCP). Leurs caractéristiques modulaires, open source et libre nous procurent l’opportunité d’integrer notre protocole à l’ensemble de ceux déjà supportés par ces bibliothèques.
4.3.3 Interface du serveur
L’interface du serveur a été réalisé par la bibliothèque Qt[55]
FIGURE 4.5 – Interface du serveur de streaming.
4.3.4 Client
Le lecteur est le composant qui permet la restitution de données audiovisuelles, que la provenance de celles-ci soit un fichier local ou un flux audiovisuel d’un serveur dans le système. Or, comme cela a été mentionné dans le chapitre précédent, lors d’une diffusion en continu d’un flux multimédia, une désynchronisation peut se produire entre le flux audio et les images qui lui sont associées. Dans de tels cas, le Lecteur est capable de resynchroniser les deux flux et par conséquent peut garantir une qualité de service acceptable dans notre système (voir Figure 4.6).
FIGURE 4.6 – Synchronisation entre une vidéo et son discours audio dans un thread de réception.
Le module CLIENT contiendra toutes les fonctions nécessaires au fonctionnement du client.
Il permettra de recevoir le flux depuis le serveur et de le lire. Il assure donc la liaison entre les modules de type réseau et les modules de type graphique. C’est le coeur de l’application cliente. Les principales fonctions de ce module seront :
– recevoir_flux() ;
– lire_vidéo() ;
– interrompre_video() ;
FIGURE 4.7 – Interface du client de streaming.
Les actions réalisées dans le processus de connexion entre un serveur et un client sont présentées sur la figure 4.8.
Une socket est un point de communication par lequel un processus peut émettre ou recevoir des données. Pour mettre en oeuvre ce mécanisme dans notre application, nous utiliserons les fonctions suivantes :
– creer_socket() ;
– attacher_port() ;
– recevoir_flux() ;
– envoyer_flux() ;
– fermer_connexion() ;
Les sockets créées peuvent être de deux types :
SOCK_STREAM utilisée avec le protocole TCP. Dans notre système, ce type de socket est utilisé pour les communications de service (echange d’informations sur l’etat des communications, des clients et du réseau).
SOCK_DGRAM utilisée avec le protocole UDP. Notre système utilise ce type de socket pour le transfert effectif de la vidéo du serveur aux clients. l’absence des mécanismes de qualité de service dans UDP est comblée par des rapports de niveau applicatif (le module de gestion de bande passante récupère les acquitements des pacquets reçus par le client).
4.4 Évaluation
Le décodage de données audiovisuelles doit être très rapide afin de respecter leurs contraintes temporelles intrinsèques. Il nécessite donc une puissance de calcul relativement élevée. D’ailleurs, la puissance requise pour décoder un contenu donné dépend de son format. À titre d’exemple, le format H.264 est plus compliqué que MPEG-2 et requiert plus de puissance de calcul pour être décodé tout en respectant l’isochronisme des données. Ainsi, la machine hébergeant un lecteur audiovisuel doit être dotée d’une puissance de calcul suffisante pour décoder les différents formats de données audiovisuelles. Cette contrainte semble être dépassée par l’avancée technologique que l’on vit actuellement. En effet, même les terminaux mobiles possèdent aujourd’hui une capacité de traitement suffisante pour décoder les contenus audiovisuels qui leur sont destinés : des contenus de petite résolution pour être affichés sur des écrans de petites dimensions.
FIGURE 4.8 – Diagramme de séquence : Connexion client/serveur.
Le diffuseur de notre système de streaming est alimenté par les fichiers prétransformés selon les spécifications de notre idée par l’encodeur. Après l’implémentation du module d’encodage, notre constat est le suivant :
– Ce module prend un temps important (environs 15 minutes pour un fichier vidéo de 5 min en 24bps et une résolution de 620×340), pour effectuer la tâche qui lui a été attribuée ;
– Mais ceci n’est véritablement pas un problème car tous les programmes d’encodage en font presque autant. En plus l’encode est fait une fois pour toute ;
– L’avantage d’encoder les couches image par image est qu’on peut faire une réservation d’espace mémoire pour y mettre les images ;
– L’accès direct aux images permet d’éviter les va-et-vient dans la mémoire : on lit en une seule opération ;
– Les opérations de traitement d’images sont effectuées par le serveur.
Conclusion et Perspectives
L’informatique de demain, telle que nous la percevons aujourd’hui, sera distribuée et multimédia. Dans cette optique, le streaming des données audiovisuelles apparaît comme un champ d’application particulièrement prometteur, à condition de disposer des matériels et logiciels susceptibles de répondre aux contraintes très sévères imposées par ce type d’applications : volume de données gigantesques, forte charge transactionnelle et conditions d’exécution temps réel.
Dans ce mémoire, nous avons donné des solutions, dont la pertinence a été validée par implémentation et tests, à une problématique à deux volets. D’une part, nous avons apporté un nouvel éclairage dans la perception d’une image du point de vue de la chrominance (partie de l’image vidéo correspondant à l’information sur les couleurs). Notre démarche consiste à fonder cette perception sous la forme d’une matrice de pixels décomposables en blocs superposables. Le système de superposition progressif des couches d’une image (enrichissement de l’image en qualité) a été mis en oeuvre. En superposant les 4 premières couches, on obtient une image de qualité visuelle quasi équivalente à la qualité de l’image originale. D’autre part, concernant la problématique de la disponibilité des données dans un système de streaming, nous avons contribué à lever ce verrou technologique en proposant d’utiliser un buffer à double compartiments pour la gestion de la réception des flux vidéos et la lecture.
L’état d’avancement de ces travaux de recherche laisse ouvert plusieurs perspectives. Pour la réalisation d’un système complet de streaming, la conception et la réalisation du module d’encodage doit nous conduire à l’implémentation complète d’un CODEC vidéo, intégrable aux lecteurs existants ; Le client de notre système devra intégrer ce CODEC sur un système d’exploitation pour équipements légers comme ANDROID. Les modules d’encodage et de diffusion devrons être plus
éprouvés afin de déterminer les caractéristiques (resources requises) optimales de base pour le déploiement de notre serveur de streaming.