Soutenance mémoire
Problématique des transmissions multimédias sur IP
Services multimédias sur réseaux à qualité de service non garantie
L’Internet Protocol (IP) a été initialement conçu en tant que simple réseau de données. À l’origine, le fonctionnement “pour le mieux” ou best effort de ce réseau des réseaux pouvait convenir à un seul type de trafic. Avec la croissance du trafic multimédia sur IP, le réseau a dû évoluer pour s’adapter aux besoins des services multimédias. Généralement exigents en termes de délai et de bande passante, ces services souffrent de baisses de qualité sévères si les conditions de transmission se dégradent.
Qualité de service
Un réseau IP best effort traite tous les paquets transmis de la même façon. Il ne tient pas compte des contraintes que peuvent avoir quelques applications pour des services particuliers. Les réseaux best effort sont cohérents avec la philosophie initiale de l’Internet qui a été conçu comme un réseau très simple avec des applications plus ou moins évoluées. Mais, les services multimédias ont besoin du maintien des paramètres qui définissent la qualité de service.
Les paramètres de qualité de service
La QdS est une indication objective de la performance d’un réseau. Les paramètres caractérisant la QdS sont : la perte de paquets, le délai et la variation de délai (gigue) [Sus00, Tan03]. Les pertes de paquets sont chroniques et font partie intégrante de la transmission IP. Dans les moments de congestion extrême, le taux de pertes dépasse le seuil de tolérance et remet en cause la qualité et l’intégralité du flux transmis. À titre d’exemple, des taux de pertes compris entre 3% et 20% ont été enregistrés sur le backbone de l’Internet en 1999 [Wen99]. Actuellement, les taux de pertes journaliers moyens aux États-Unis sont généralement inférieurs à 1%. Le délai est le temps mis par un paquet pour arriver de la source à sa destination finale. Il est essentiellement dû au délai de propagation et au temps d’attente dans les files au niveau des routeurs.
Les applications sur IP ont des contraintes différentes en ce qui concerne les valeurs des paramètres de QdS. Par exemple, le mail ou le transfert de fichiers nécessitent une très haute fiabilité mais tolèrent des délais assez longs (de l’ordre de la seconde). C’est pour ce type de service nécessitant des délais élastiques que l’IP a été initialement conçu. D’autre part, les services multimédias sont généralement gourmands en bande passante mais acceptent jusqu’à un certain degré les pertes de paquets. Pour un service de visioconférence sur IP, un délai dépassant les 150 ms rend le service inutilisable.
Une solution aux problèmes du délai et de sa variation est l’utilisation d’une mémoire tampon (buffer) dans le décodeur pour la lecture du contenu multimédia. Cette mémoire tampon sert à assembler les paquets de données, éventuellement les réordonnancer, les décoder et compenser ceux qui sont perdus. Elle agit comme un véritable amortisseur des variations temporelles des paramètres de QdS. Le but de cette configuration est de permettre une lecture fluide du contenu décodé indépendamment de la variation du délai d’arrivée des paquets. La longueur de la mémoire tampon est généralement réglée de façon à largement couvrir la somme du délai de réception des paquets et de sa variation maximale. Dans un contexte de streaming de vidéos via TCP, une mémoire tampon de dix secondes au plus permet une lecture fluide de la vidéo [She09]. Il est communément acquis que les paramètres de QdS pour une session multimédia temps-réel peuvent généralement être réduits au délai et à la perte de paquets si une mémoire tampon de taille convenable est utilisée [Jia99].
La conséquence ultime d’une combinaison de mauvaises valeurs de ces paramètres QdS est la perte de paquets. En effet, une congestion de paquets à un nœud particulier cause l’élimination de paquets dans la file d’attente. De même, un paquet faisant partie d’un flux vidéo peut être considéré comme étant perdu par le décodeur s’il arrive après un délai supérieur à une limite fixée. Les motifs de pertes constatés sur l’Internet montrent que la probabilité de perte d’un paquet est plus grande si le paquet précédent a été perdu [Jia99]. Les pertes surviennent généralement en rafale. L’explication est la suivante : la perte d’un paquet laisse supposer la présence d’une congestion qui probablement va affecter un groupe de paquets. Ceci a conduit à la modélisation des pertes par des canaux à mémoire notamment par le modèle de Gilbert-Elliott.
Évolution de l’Internet multimédia
La transformation de l’Internet en un réseau capable d’offrir des services multimédias acceptables implique l’utilisation de protocoles pouvant relever les défis imposés par ce type de service. Une des contraintes majeures est le respect des contraintes de délai assez strictes. TCP garantit la réception des paquets par la retransmission des paquets non acquittés. Cependant, les services interactifs comme la visioconférence ne peuvent tolérer les délais de retransmission. Ceci nous mène à distinguer entre deux types de pertes : les pertes “directes” et “indirectes”.
Les pertes directes désignent les paquets perdus dans le réseau et qui n’atteignent pas leur destination. Cette définition se rapproche de la vision de la QdS par les moniteurs de réseaux. Les pertes indirectes, au niveau de l’application, représentent les paquets du flux qui ne sont plus considérés au moment du décodage. Ceci peut être dû à leur arrivée avec un délai conséquent ou bien à leur désordonnancement. Un décodeur qui attend un paquet donné pour poursuivre le décodage ne l’utilisera plus s’il arrive longtemps après. De même, le décodeur peut considérer un paquet comme perdu s’il arrive plus tôt que les paquets en cours de décodage. Le protocole UDP (User Datagram Protocol) formalisé dans la RFC (Request For Comments) 768 [Pos80b] est un autre protocole de transport (couche 4 du modèle OSI – Open System Interconnection). Contrairement à TCP qui nécessite l’établissement d’une connexion entre deux ordinateurs en communication, UDP est en mode non connecté. Il se présente comme un protocole de transport léger (en-tête cinq fois plus petite que celle de TCP) mais ne garantit pas la livraison des paquets de données. De plus, UDP n’offre aucune possibilité de régulation de flux. Son utilisation ne peut donc être généralisée sur tous les types de trafic. L’utilisation d’UDP a cependant été proposée pour les applications qui ne tolèrent pas les longs délais comme par exemple les applications multimédias. Pour assurer un service de qualité acceptable, il faut cependant le coupler avec un protocole de niveau supérieur capable de détecter les pertes de paquets et d’y réagir .
Le protocole RTP, standardisé dans la RFC 3550 [Sch03], a été introduit pour satisfaire aux contraintes de temps de certains services, en particulier les services de visioconférence multiutilisateurs. Il propose des fonctionnalités d’horodatage et des mécanismes de synchronisation de flux qui rendent possible le transport de données ayant des propriétés temps-réel. D’autre part, le protocole RTCP (Real-time Transport Control Protocol), qui assure le contrôle et la gestion de RTP, permet la mesure de la qualité de service à travers les rapports d’émission (SR pour Sender Report) et de réception (RR pour Receiver Report). RTP rend possible le réordonnancement du flux multimédia dans le cas de variation de délai des paquets et la détection d’éventuelles pertes de ces derniers. Il est indépendant des couches sous-jacentes. Toutefois, RTP est le plus souvent utilisé au-dessus du protocole UDP formant ainsi la pile RTP/UDP/IP dont l’en-tête globale a une taille égale à 40 octets (réductible à 2 ou 3 octets par compression d’en-tête [Bor01]).
La RFC 3984 définit l’encapsulation des NALU produites par un codeur H.264/AVC dans les paquets RTP pour des services multimédias variés (visioconférence, streaming, VOD pour Video On Demand). Les modes de mise en paquets comprennent la mise en paquet RTP d’une NALU individuelle, de plusieurs NALU et la fragmentation d’une NALU dans plusieurs paquets. La pile RTP/UDP/IP est utilisée dans plusieurs travaux de la littérature pour les services streaming de vidéos H.264/AVC comme par exemple dans [Hil06] et [Goh08].
|
Table des matières
Introduction générale
I Problématique des transmissions multimédias sur IP
1 Services multimédias sur réseaux à qualité de service non garantie
1.1 Qualité de service
1.1.1 Les paramètres de qualité de service
1.1.2 Évolution de l’Internet multimédia
1.1.3 Limitations
1.2 Qualité d’usage
1.2.1 Définition
1.2.2 Évaluation de la qualité d’usage
1.2.2.1 Méthodes subjectives
1.2.2.2 Métriques objectives
1.2.3 Relation entre qualité de service et qualité d’usage
1.3 La vidéo comme service multimédia
1.3.1 Les principes de codage H.264/AVC
1.3.2 Adaptation du flux H.264/AVC aux réseaux de paquets
1.3.3 Vulnérabilité du flux H.264/AVC aux erreurs de transmission
2 État de l’art des mécanismes d’amélioration de la qualité de service et de la qualité d’usage
2.1 Amélioration de la qualité de service
2.1.1 Classification de trafic
2.1.2 Codage réseau
2.2 Amélioration de la qualité d’usage
2.2.1 Codes correcteurs d’erreurs
2.2.1.1 Principe des codes correcteurs
2.2.1.2 Codes correcteurs d’erreurs avec protection inégale
2.2.2 Codage et décodage robustes
2.2.2.1 Codage vidéo H.264/AVC robuste
2.2.2.2 Méthodes de compensation
2.2.3 Approches hybrides de protection de contenus vidéos
2.3 Discussion générale
II Amélioration des qualités de service et d’usage par transformation Mojette
3 La transformation Mojette comme opérateur de codage réseau
3.1 Le mode d’opération du codage réseau
3.1.1 Codage et décodage
3.1.2 Applications du codage réseau
3.2 La transformation Mojette
3.2.1 Présentation
3.2.2 Application de la transformation Mojette au codage réseau
3.2.3 Performances et discussion
4 Protection inégale perceptuelle de flux hiérarchiques par transformation Mojette
4.1 Graduabilité du flux JPEG 2000
4.2 Allocation optimale de redondance
4.3 Contribution perceptuelle des incréments de qualité
4.4 Protection inégale par transformation Mojette
4.5 Évaluation de performances
4.6 Extension à la vidéo
III Vers une hiérarchie perceptuelle guidée par le contenu de sources vidéos
5 Caractérisation perceptuelle des effets de pertes de paquets
5.1 Impact perceptuel d’une perte de paquets
5.1.1 Travaux antérieurs
5.1.2 Discussion
5.1.2.1 Sur la caractérisation de l’effet perceptuel des pertes de paquets
5.1.2.2 Sur l’introduction des pertes de paquets
5.2 Simulation contrôlée de pertes de paquets
5.2.1 Caractéristiques du simulateur
5.2.2 Mise en œuvre du simulateur de pertes
5.3 Méthodologie générale des tests subjectifs
5.3.1 Les observateurs
5.3.2 L’environnement de test
5.3.3 Traitement des résultats
5.3.4 Classes de méthodologies
5.3.4.1 La méthodologie choisie pour nos travaux
5.4 Première caractérisation des effets perceptuels des pertes de paquets
5.4.1 Les séquences de test
5.4.2 Création des séquences dégradées
5.4.2.1 Codage et décodage
5.4.2.2 Motifs de pertes
5.4.2.3 Choix de la position temporelle des pertes
5.4.3 Résultats expérimentaux
5.4.3.1 Qualité visuelle sans pertes de paquets
5.4.3.2 Influence combinée du débit et des pertes sur la qualité
5.4.3.3 Qualité moyenne par débit en fonction du nombre de paquets perdus
5.4.3.4 Influence de la distribution des pertes sur la qualité visuelle
5.4.3.5 Impact perceptuel du changement de scène en présence de pertes de paquets
5.4.3.6 Impact perceptuel de la position spatiale de la perte dans l’image
5.5 Identification de la relation entre le taux de pertes et la qualité visuelle
5.5.1 Environnement de test
5.5.2 Séquences de test
5.5.2.1 Caractérisation de l’information spatiale
5.5.2.2 Caractérisation de l’information temporelle
5.5.2.3 Classification des contenus des séquences
5.5.3 Motifs de pertes
5.5.4 Résultats expérimentaux
5.5.4.1 Perte d’une partie de l’image I
5.5.4.2 Perte d’une image I entière
6 Étude du déploiement de l’attention visuelle en visualisation de séquences vidéos
6.1 L’attention visuelle
6.1.1 Les mouvements oculaires
6.1.2 Les mécanismes de sélection de l’attention visuelle
6.2 Saillance ou régions d’intérêt ?
6.3 Le test de suivi des mouvements oculaires
6.3.1 Objectifs du test
6.3.2 Le dispositif expérimental
6.3.3 Les séquences vidéos
6.3.4 Codage et motifs de pertes
6.3.5 Le déroulement de l’expérimentation
6.3.6 Des données oculométriques à la saillance
6.3.6.1 L’algorithme de création des séquences de saillance
6.3.6.2 Choix des valeurs des paramètres de l’algorithme
6.4 Résultats et discussion
6.4.1 L’impact d’une perte sur le déploiement de l’attention visuelle
6.4.2 Pertes, attention visuelle et qualité visuelle
Conclusion générale
