3.1 Introduction
Le streaming vidéo en environnement limité est, comme on vient de le voir très, attractif, du fait de l’émergence de l’informatique ambiante. Toutefois il s’est montré difficile à mettre en oeuvre, du fait des nombreuses contraintes inhérentes à ces environnements, et toutes les solutions jusqu’alors ont des limites.
Dans cette partie, nous proposons une solution qui cherche à élimer principalement les temps morts pendant la lecture vidéo. Ces temps morts sont dus à des baisses du débit du réseau entre le client et le serveur, qui a pour conséquence que le cache client ne contient pas suffisamment de données au moment de la lecture.
Notre solution consiste en 4 points :
– Calcul dynamique des performances du réseau et adaptation de la qualité vidéo à ces performances;
– Encodage judicieux de la vidéo chez le serveur de façon à permettre l’extraction rapide et simple des trames nécessaires à un instant donné pour envoi au client.
– Maintien permanent chez le client de données vidéo suffisantes pour lecture pendant les temps de déconnexion ou de baisse du régime réseau.
– Maintien des tâches de calcul côté serveur pour alléger la charge client, celui-ci se limitant à la superposition et l’affichage de la vidéo.
Mireille Josiane DZIEGAING dans son mémoire de master 2 encadré par Dr. Jean Michel NLONG II a montré qu’avec quelques bits par pixel on pouvait avoir un rendu assez confortable d’une image[47].
Notre travail qui consiste à étendre [47] à une transmission vidéo continue nous a conduit à la proposition d’un modèle architectural dont l’illustration est donnée par la figure 3.1 : Cette architecture sera détaillée au chapitre 4 sur l’implémentation de notre modèle.
3.2 Encodage en couche
Pour une compréhension de cette solution, il est important de poser un certain nombres de bases dans le domaine de la vidéo et du traitement d’image.
FIGURE 3.1 – Architecture du système de streaming adaptatif multicouches.
La vidéo numérique représente l’information sous la forme d’un flux composé d’une succession d’images numériques. Le format vidéo décrit l’ordre et la structure de ces images. Les données du flux vidéo, qui peuvent être accompagnées de sons sous la forme de flux audio, sont très volumineuses : elles doivent impérativement être compressées (codées) à l’aide d’un codec pour être stockées (sur disque dur ou sur les supports d’enregistrement : CD, DVD) ou/et transmises (et donc être adaptées au débit des réseaux).
Les flux vidéo (et le(s) flux audio éventuellement associé(s)), une fois encodés, sont généralement encapsulés dans des fichiers conteneurs : ces derniers permettent, notamment, leur lecture simultanée [10].
3.2.1 Idée générale
Les algorithmes de streaming traditionnels pré-chargent une qualité de vidéo dans un tampon, à partir duquel les images sont lues et affichées [47]. Si le réseau est de mauvaise qualité, on perçoit des temps morts pendant la lecture, et le lecteur indique qu’il est en train de télécharger la suite de la vidéo(cf. Figure 3.2) . Notre travail consiste donc à éviter d’avoir ces périodes d’inactivité en fournissant à chaque instant des images au lecteur, quitte à ce que ceux-ci soient de qualité réduite.
FIGURE 3.2 – Lecteur de streaming et attente d’alimentation du buffer en données vidéos(bufferisation).
Pour parvenir à nos fins, nous proposons l’idée suivante :
Par un codage judicieux, une image peut être « enrichie » de façon incrémentale, partant d’une extrapolation des couleurs significatives de chaque pixel jusqu’aux couleurs vraies. Chaque image est donc décomposée en plusieurs blocs (cf Figure 3.3).
FIGURE 3.3 – Décomposition d’une image en bloc superposable par fragmentation de pixels.
Une image est un ensemble de pixels ayant chacune une couleur bien définie. Généralement une couleur est composée de trois éléments : composante rouge(R), composante verte (V) et composante bleue (B). Chaque composante étant codée sur huit bits, un pixel est donc codé sur trois octets. Afin de réduire le nombre de bit utilisé pour le codage des couleurs, tout en gardant une approximation des couleurs modifiées, on peut jouer sur chacune de ces trois composantes.
Pour chaque composante, on considère juste un certain nombre de bits sur l’ensemble représentant sa valeur. Les bits ignorés sont remplacés par des zéros. Nous avons ainsi pu définir huit (8) couches par image, chaque couche i étant définie comme suit :
– i : numéro du bit considéré ;
– pour chaque composante R, V, B, on considère le i-ème bits de poids fort, les autres bits sont mis à zéro. La couleur est en suite reconstituée en utilisant ces nouvelles valeurs (cf Figure 3.4).
FIGURE 3.4 – Fragmentation d’un pixel.
3.2.2 Superposition
Le principe de la décomposition d’une image en couches expliqué dans le paragraphe précédent, nous conduit à l’exposé de notre concept d’enrichissement progressif de la qualité des images issues d’une séquence vidéo.
FIGURE 3.5 – Fragmentation d’une image en couches superposables.
Chaque image de la séquence vidéo étant décomposée suivant le principe expliqué au paragraphe précédent et illustré par le figure 3.5, il est possible d’inverser le processus afin de retrouver l’image originale à partir des couches. Ceci est utile à plus d’un titre : par exemple, pour l’enrichissement progressif d’une séquence vidéo après transmission dans un réseau (streaming) aux caractéristiques (bande passante, gigue, débit etc.) variables.
Le caractère réaliste du concept de fragmentation d’image en couches superposables réside dans sa puissance à avoir une image proche de l’originale juste avec un certain nombre de couches.
À partir de la superposition des 3 premières couches d’une image, on atteint un niveau de qualité visuel acceptable (cf. Figure 3.6).
FIGURE 3.6 – Superposition progressive des couches d’une image.
3.2.3 Compression
La manipulation des pixels d’une image de façon efficiente (rapide) exige que cette image soit en un format à indexation de pixel. Le « Bit Map » est un format à accès direct aux pixels (sans transformation préalable comme c’est le cas pour les images compressées de type JPEG par exemple). Dans un BMP, l’image est une matrice dont les éléments sont les pixels. Mais malheureusement les « Bit Map » occupent énormément d’espace mémoire (près de 10 fois la taille d’une image de type JPEG). Nos algorithmes de fragmentation et de reconstruction des images requièrent donc de transformer les images en Bit Map.
Pour compresser les fragmentats (couches d’images) deux opérations sont appliquées aux fragments :
Factorisation : Cette opération consiste à factoriser tous les bits significatifs d’un pixel en bloc de trois bits (si un pixel est codé sur 24 bits, on gagne 21 bits d’espace par pixel avec le processus de factorisation). Elle n’est en aucun cas destructive car on ne fait qu’enlever les bits mis à « 0 » lors de la fragmentation. Il est à noter que l’image résultante de la factorisation n’a plus de grande signification visuelle mais le processus de saturation (restitution d’une image factorisé) permettra d’inverser le processus et donc, de revenir au fragment original.
La factorisation nous fait gagner en moyenne 9/10 de l’espace occupé par l’image (fragment) de départ ce qui nous permet de revenir à une taille d’image proche du « jpeg » source (sans fragmentation)
FIGURE 3.7 – Exemple d’épuration de la couche 2 d’un image.
Compression : Le fragment ainsi épuré va subir une compression standard de type jpeg par exemple afin d’en réduire encore la taille sans altération grave de la qualité visuelle (cf figure 3.7. La compression jpeg fait gagner en moyenne 9/10 d’espace (le poids d’une image compressée en jpeg est en moyenne 1/10 du poids de l’image originale, si cette dernière est un BitMap)
Il en ressort de cette expérimentation que le processus d’épuration permet d’avoir un gain théorique comparable au processus de compression JPEG. L’avantage de notre méthode est alors visible : en appliquant une compression JPEG au fichier issus du processus de factorisation, on gagne encore 9/10 d’espace. Ce qui nous permet d’avoir un gain théorique de 99% d’espace (la taille de l’image de départ se trouve considérablement réduite tout en gardant une bonne approximation visuelle).
3.3 Organisation de la vidéo côté serveur
3.3.1 Structure du fichier et mise en trame d’une seconde de vidéo
Le fichier vidéo est compilé dans un container à une piste vidéo. Cette piste contient une séquence d’images décomposées en couches superposables (1 à 8). Pour la manipulation du contenu vidéo par unité de temps correspondant à 1seconde, la vidéo est structurée en blocs d’images successives correspondant à une seconde de vidéo (25 images “couches” pour notre cas).
Ce nouveau container permet d’appréhender notre vidéo sous la forme d’une matrice dont les lignes représentent le fux vidéo correspondant à une séquence d’images issu de la même famille (ensemble d’images provenant du même niveau de couche. Par exemple, la piste 1 contiendra une séquence d’images, toutes issues de la couche 1 du processus de fragmentation). On a donc une représentation de notre vidéo donnée par la figure 3.8 la mise en trame d’une seconde de vidéo consiste à indexer une composante de cette matrice, suivant l’algorithme décrit au chapitre 4.
FIGURE 3.8 – Structure de la vidéo.
3.3.2 Gestion des clients
Chez le serveur, chaque client est entretenu par un gestionnaire d’indexation, qui crée le lien entre un vecteur d’indexation et le fichier vidéo demandé en streaming. Le système (vecteur d’indexation – gestionnaire d’indexation – fichier vidéo [cf figure 3.9]) permet de délivrer un streaming adaptatif personnalisé pour chaque client.
Le système d’indexation de la figure 3.9 est composé de 3 compartiments dont les deux principales sont décrites ici :
Un vecteur d’indexation adaptatif : Ce dernier est une structure de données contenant les temps (contenu de cellule) en fonction de la qualité (indice la cellule). Le couple (indice, contenu), constitue le point d’accès au fichier vidéo.
FIGURE 3.9 – Système d’indexation adaptatif d’un fichier vidéo
Gestionnaire d’indexation : c’est l’élément chargé de faire la relation entre le fichier vidéo et le vecteur d’indexation, en mettant à jour les cellules du vecteur et en informant le module serveur de notre système global de la façon d’accéder la vidéo afin de transmettre la portion exactement exigée par notre spécification.
Le serveur actualise en permanence le vecteur d’indexation (les cellules de ce vecteur sont mises à jour après chaque transmission). Ce vecteur permet de savoir quelle portion de vidéo doit être transmise à un instant donné. En effet, selon la qualité du réseau, le gestionnaire d’indexation calibre le vecteur d’indexation suivant l’algorithme de diffusion décrit au chapitre suivant, pour une extraction de séquence d’images adaptée à la qualité courante du réseau.
3.4 Calcul dynamique de la bande passante
Dans cette section, nous nous intéressons aux processus d’évaluation des paramètres influant la transmission vidéo, afin de proposer une solution d’adaptation de la diffusion tenant compte de ces paramètres.
3.4.1 Synchronisation
Sans une bonne synchronisation des horloges de tous les systèmes communiquant entre eux, certains services ne sont pas utilisables correctement. C’est ainsi que la nécessité de synchroniser les horloges s’est imposée. Il a été nécessaire de définir des méthodes permettant de synchroniser les horloges sur une heure de référence.
Plusieurs techniques sont proposées dans la littérature pour synchroniser un client et un serveur dans un système client-serveur. Dans notre travail, nous avons choisi d’utiliser la technique du « round trip » [65] pour la synchronisation client-serveur. Celle-ci est utilisée par la plupart des algorithmes de synchronisation.
En s’inspirant du modèle présenté dans[65] et en inversant les rôles on obtient les résultats suivants (cf Figure 3.10).
FIGURE 3.10 – Évaluation de l’écart des horloges.
Où :
T1 est l’instant d’émission du message d’interrogation du client sur son heure courante par le serveur.
T’1 l’instant de réception du message émis à l’instant T1.
T’2 l’instant d’émission du message de réponse du client au serveur ;
T2 l’instant de réception par le serveur du message émis à l’instant T’2 par le client ;
Le serveur entretient une horloge virtuelle pour chaque client. Cette horloge est réglée à la même heure que celle du client considéré. La mise à jour de cette horloge virtuelle est donnée par l’expression :
HServeur(new) = HServeur(now) + θ
où :
– HServeur(new) représente la mise à jour de l’heure du serveur ;
– HServeur(now) représente l’heure du serveur juste avant la mise à jour ;
– θ la dérivation ou l’écart entre les horloges(serveur et client).
3.4.2 Calcul des temps (délais) d’arrivées des trames
En utilisant une fois de plus le modèle proposé par [65] on détermine également le délai d’aller/retour d’un paquet comme indiqué par le tableau ci-dessous, l’utilisation d’un horodatage comme celui proposé par le protocole RTP permet d’étendre cette évaluation des délais à celle de l’arrivée des trames vidéo.
Ceci est proposé par le protocole RTCP qui fonctionne au dessus de RTP. Ayant une idée sur le débit réseau courant, le serveur peut estimer, sachant la taille des paquets à transmettre le temps qu’ils mettront.
FIGURE 3.11 – Évaluation du délais de transmission d’un paquet.
3.4.3 Sélection des données à transmettre
Dans le paragraphe précédent, nous avons exposé la méthode permettant non seulement de synchroniser les horloges clientes et serveur, mais également d’évaluer les délais de transmission des paquets entre le client et le serveur. Les résultats précédents permettent aussi de faire une première évaluation de la bande passante. En partant du fait que les paquets émis par le serveur vers le client et la réponse du client au serveur ont la même taille P (ce qui est le cas pour les paquets de synchronisation), il devient possible d’évaluer le débit comme suite : D=2P/δ où : D est le débit du réseau de transation, P est la taille du paquet émis et δ le délai d’allé/retour du paquet utilisé.
Ayant donc ce débit D, si on choisit d’envoyer t secondes de vidéo, la question est de savoir si ces t secondes vont arriver à temps (transmission->réception->décodage->affichage) ou non ? Soit q la quantité de données correspondant à t secondes de vidéo. On peut poser D=kS où k est le nombre d’images transmissible. La réponse à la question précédente revient donc à déterminer la relation entre S et q.
Cette relation est donnée par la formule suivant : k=D/q.
À chaque réception d’acquittements, le débit du réseau est évalué de nouveau et le calcul de k est mis à jour.
3.5 Lecture
Le cache client est l’espace réservé à la régulation du flux en provenance du serveur. En effet, le flux vidéo en provenance du serveur passe par un réseau qui désorganise la régularité des séquences d’images (cf figure 3.12 dont l’isochronisme de la vidéo. Dans cette section nous nous attaquons à la disponibilité constante des données vidéo chez le client et montrons les mécanismes mis en oeuvre pour une consommation efficace de ses données.
![Effet du réseau et rôle d’un buffer de régulation[49]](https://www.institut-numerique.org/wp-content/uploads/2013/05/Effet-du-réseau-et-rôle-d’un-buffer-de-régulation49.png "Effet du réseau et rôle d’un buffer de régulation[49]")
FIGURE 3.12 – Effet du réseau et rôle d’un buffer de régulation[49].
3.5.1 Hypothèse de disponibilité d’une vidéo de temps t
Afin de garantir que le client ne sera jamais à cours de donnée vidéo, notre système se propose de garantir la disponibilité constante d’au moins 10secondes de vidéo dans le cache client. Cette hypothèse sur la disponibilité est assurée par l’algorithme d’indexation décrit au chapitre 4.
3.5.2 Superposition des trames
Les trames reçues du serveur sont déchiffrées afin d’en extraire les différentes couches d’images contenue dans le paquet. Ces couches sont ensuite mises dans un emplacement réservé à la lecture directe (cet emplacement étant ici un buffer tournant).
3.5.3 Buffer double
Pour une lecture efficace du flux vidéo reçu par un client, notre système côté client implémentera un système de buffer dont le but est de faciliter la réception, le décodage et la fusion éventuelle des couches, les mécanismes d’usage seront expliqués dans cette section.
Système de buffer et décompression : Les données vidéos encodées en couches superposables sont transmises par bloc d’images correspondant à une seconde de vidéo. Pour une gestion efficace et instantanée de la réception et du décodage des images (superposition de couches), le client entretient un buffer décomposé en deux compartiments : un en charge de la réception des couches individuellement décodable, et l’autre des couches décompressées et immédiatement lisibles par le lecteur (cf figure 3.13) .
FIGURE 3.13 – Système de buffer.
Dans ce système, le lecteur du client est chargé de lire les 2 secondes de vidéo se trouvant à l’extrémité droite du buffer. Pendant cette lecture, les couches non encore décompressées se trouvant dans la portion gauche du buffer (représenté par 8s dans le schéma 3.13) ,sont décodées (transformées en bitmap) et superposée si nécessaire. Ces couches superposées remplacent les images déjà lues dans la deuxième partie du buffer. Lorsque la tête de lecture arrive au bout de 2 secondes de vidéo, elle revient immédiatement en début de la zone des deux secondes pour lire la suite de la vidéo, celle-ci ayant été au préalable décodée depuis la zone de réception des couches et mise à jour dans la zone de lecture effective. Ceci nous donne un système de deux buffers communicant (la zone de réception met à jour la zone de lecture effective) et tournant (pour la zone de lecture effective).
Superposition intelligente : les images transmises du serveur aux clients sont compressées en JPEG pour des besoins d’optimisation de l’utilisation de la bande passante des liens de communications. À leur réception, le client doit pouvoir fusionner certaines images si celles-ci représentent des couches d’une même image, avant de pouvoir les lire. La superposition consiste à récupérer les couches faisant parties d’une même image (cf chapitre 4 dans [47] pour l’identification des couches depuis un paquet reçu) et d’appliquer ’algorithme de superposition décrit au chapitre suivant.
3.6 Conclusion
Dans ce chapitre, nous avons mis l’accent sur le problème de la disponibilité des données dans les systèmes de streaming adaptatif, qui provient principalement des déconnexions fréquentes induites par les réseaux sans fil et de la limitation de la bande passante dans ces réseaux. En effet, ce problème est tel qu’il est indispensable d’y remédier de manière aussi efficace et pertinente que possible. Nous avons donc modélisé cette problématique, et proposé une solution permettant de nuancer les effets de la déconnexion des clients et de limitation de la bande passante. Il s’agit de précharger suffisamment les couches d’un contenu en cours d’accès. Le préchargement des couches d’une vidéo limite le gaspillage des ressources du réseau car les couches sont de tailles réduites et représentatives des contenus originaux. Nous avons opté pour une architecture à deux buffers communicants et tournants afin d’optimiser les opérations de réception, décodage et lecture. D’ailleurs, nous avons élaboré une nouvelle stratégie adaptative pour gérer ce buffer décomposé.
Cette stratégie s’appuie sur un système asservi pour ajuster, fusionner les couches reçus du serveur, mettre à jour le compartiment du buffer réservé pour la lecture et libérer les espaces inutiles (les données déjà lues ou dépassées dans le temps) de sorte que le buffer soit exploité au maximum. Comme l’attestent les résultats de nos expérimentations, notre approche est adéquate pour un environnement de stations légères en réseaux sans fil instable.
Dans le prochain chapitre, nous portons un regard plus profond sur les aspects fonctionnels de notre système et les outils de développement multimédia utilisés son implémentation. Nous y décrivons les choix d’implémentation de notre système de streaming adaptatif et exposons quelques résultats des tests.