Optimisation de la bande passante pour le broadcast vidéo sur

Optimisation de la bande passante pour le broadcast
vidéo sur réseau IP
Rapport bibliographique
Isabelle Hurbain
Soutenu le 12 Mai 2003
Table des matières
Introduction
2
1 Principe de l’encodage MPEG et de la diffusion de vidéo sur réseau
1.1 Introduction : les interfaces de téléopération . . . . . . . . . . . .
1.2 La compression MPEG . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Décomposition d’un fichier MPEG . . . . . . . . . . . . . .
1.2.2 Compression temporelle . . . . . . . . . . . . . . . . . . .
1.2.3 Compression spatiale . . . . . . . . . . . . . . . . . . . . .
1.3 La diffusion de video sur réseau . . . . . . . . . . . . . . . . . . .
1.3.1 La préparation des flux MPEG . . . . . . . . . . . . . . . .
1.3.2 RTP et RTCP . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
6
7
7
7
8
2 Mesure de la qualité vidéo
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Indicateurs subjectifs . . . . . . . . . . . . . . . . . . .
2.3 Indicateurs objectifs . . . . . . . . . . . . . . . . . . .
2.3.1 Remarques préliminaires . . . . . . . . . . . . .
2.3.2 Indicateurs basés sur la qualité du signal image
2.3.3 Indicateurs basés sur la vision . . . . . . . . . .
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
10
12
12
13
13
15
.
.
.
.
.
16
16
16
17
19
20
.
.
.
.
.
.
.
3 Mesure de la qualité du réseau
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Problèmes généraux de la mesure de paramètres réseau
3.3 Mesure de la bande passante . . . . . . . . . . . . . . .
3.4 Mesure des retards . . . . . . . . . . . . . . . . . . . . .
3.5 Mesure du taux de paquets perdus . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
22
Bibliographie
24
1
Introduction
Ce rapport bibliographique a pour vocation de présenter les méthodes, outils et notions utilisables dans le cadre du sujet de DEA “Optimisation de la bande passante pour
le broadcast vidéo sur réseau IP”.
La téléopération de systèmes robotiques dans le cas d’un sous-marin ou d’un engin de
travaux publics pose le problème du retour d’informations pour l’opérateur. Ces retours
peuvent être de plusieurs types : visuels, haptiques, données numériques de distance...
L’être humain a tendance à considérer le visuel comme un élément clé de son travail,
il est donc important de fournir à l’opérateur d’un système téléopéré un retour visuel de
bonne qualité.
Se pose donc le problème suivant : comment garantir un retour vidéo de qualité
correcte à un ou plusieurs utilisateurs sur le même canal, sachant que la taille de ce
canal est limitée ?
Ce problème se rapproche beaucoup des travaux actuels sur la diffusion numérique
de vidéo par voie terrestre (DVB-T) ou satellite (DVB-S).
Les développement récents des technologies des télécommunications permettent à
l’heure actuelle d’envisager des services de diffusion vidéo par l’intermédiaire d’un réseau IP.
Une vidéo standard dans une résolution moyenne nécessite par seconde de vidéo
320 ∗ 200(résolution)∗3(couleurs)∗25(nombre d’images par seconde)=480000 octets soit
environ 4M o (mega-octets).
À titre de comparaison, une liaison “haut-débit” standard actuelle (type ADSL) propose des débits de l’ordre de 70Ko/s au maximum.
Il est néanmoins possible à l’heure actuelle de proposer des services vidéo tels que
la téléconférence, la diffusion de bandes-annonces de cinéma, etc. sur des équipements
de ce type.
Cela est majoritairement rendu possible grâce à la compression de la vidéo. Un fichier vidéo donné doit subir un prétraitement avant sa diffusion par le biais d’un réseau
IP pour diminuer les temps et débits nécessaires de téléchargements et donc les coûts
associés.
Cette compression se fera principalement par le biais d’algorithmes MPEG qui seront
détaillés au chapitre 1. Cette compression est une compression avec perte (à la différence d’une compression sans perte permettant la reconstitution parfaite des données
initiales). Cela n’est pas forcément génant au sens où l’oeil humain qui perçoit la vidéo
2
peut ne pas se rendre compte des pertes générées par la compression/décompression de
la vidéo. En toute logique, la qualité de la vidéo décroit avec le taux de compression.
Cette diminution de qualité vidéo n’est pas uniforme en raison des méthodes de compression utilisées. Nous verrons en particulier qu’une vidéo de faible dynamique (météo,
nouvelles, film avec peu d’action) sera visuellement moins dégradée à taux de compression égal qu’une vidéo à dynamique forte (film d’action par exemple). Nous présenterons
au chapitre 2 les différentes approches permettant d’estimer la qualité visuelle d’une vidéo.
L’utilisation de cette qualimétrie vidéo pourra être utilisée pour l’allocation de bande
passante au niveau de la diffusion. En effet, une vidéo à faible dynamique pourra être
compressée à des taux plus élevés et il sera donc possible de lui allouer moins de bande
passante.
Le chapitre 3 s’intéressera plus particulièrement aux problèmes de qualimétrie au
niveau du réseau. En effet si la qualité ou la bande passante du réseau utilisé viennent à
décroître ou à augmenter, cela changera les paramètres de compression des vidéos pour
les adapter à ces nouveaux paramètres.
La validation se fera par l’intégration de la plateforme “robot mobile’ et de sa boucle
vidéo dans le projet européen REPOSIT.
Il est à noter qu’on se limitera dans ce rapport à l’aspect vidéo, en laissant de côté l’aspect audio. Ceci donne lieu à d’autres problématiques, en particulier de synchronisation
son/image, qui sont au-delà du cadre de cette étude.
3
Chapitre 1
Principe de l’encodage MPEG et de
la diffusion de vidéo sur réseau
1.1
Introduction : les interfaces de téléopération
La téléopération de système robotiques nécessite un retour d’information important.
En effet, on voit mal comment effectuer une opération chirurgicale ou explorer des fonds
sous-marins en aveugle.
Les retours d’information peuvent prendre plusieurs formes, souvent associées. Par
exemple, dans un environnement parfaitement connu (atelier) l’utilisation d’un robot
manipulateur peut se faire par le biais d’une reconstruction 3D du robot à partir de
son modèle et du retour des paramètres articulaires. Dans un environnement critique
(téléchirurgie) un retour haptique sera probablement nécessaire. Et dans le cas d’un
robot d’exploration, on appréciera un retour visuel le plus complet possible et/ou une
évaluation des obstacles présents.
Dans tous les cas, l’être humain a beaucoup de mal à travailler en aveugle (avec
uniquement un retour haptique ou des informations partielles sur l’environnement par
exemple). Un retour vidéo correct est une approche naturelle dans ce cas. Cela pose
en particulier le problème de la taille des données considérées : il est normal qu’une
information visuelle complète soit plus lourde en termes de taille qu’une information
sur les 6 coordonnées articulaires d’un robot manipulateur 6 axes.
1.2
La compression MPEG
L’intérêt de la compression des données informatiques est immédiat : la taille des
données s’en trouve réduite, ce qui implique en particulier moins de place de stockage
utilisée et moins de transferts réseau.
Dans une application de retour vidéo pour la télérobotique, on peut se permettre
d’utiliser une compression avec pertes. En effet il n’est pas nécessaire d’avoir une qualité
de vidéo parfaite pour que l’information soit exploitable. L’information peut donc être
dégradée dans une certaine mesure tout en restant acceptable.
4
Une des formats de compression les plus utilisés en vidéo est le format MPEG (Motion
Pictures Expert Group) qui s’appuie sur une compression spatiale des images et une
compression temporelle inter-images.
Ce type de compression a fait preuve de son efficacité par rapport à d’autres mécanismes. Par exemple, une compression sans perte comme la compression de type Huffman n’est pas suffisante. Elle est basée sur le nombre d’occurences d’un caractère dans
une série de données. Plus le caractère en question est fréquent, plus la séquence l’encodant sera petite. La décompression se fait par l’application de la grille d’encodage
inverse et se fait donc sans perte. Il est logique qu’une telle compression soit moins
efficace qu’une compression présentant une perte d’informations acceptable. D’autres
compression se basent sur la compression image par image, indépendamment, de la vidéo. C’est le cas par exemple du format MJPEG. Cette compression n’est pas optimale
non plus car la redondance entre des images d’une même scène vidéo est forte, et ce fait
peut être exploité, ce qui est fait avec la compression MPEG.
Voyons en détail à l’aide de [Eise95] et [Tekt02] les mécanismes utilisés dans la compression MPEG.
1.2.1 Décomposition d’un fichier MPEG
Les données dans une séquence vidéo sont hiérarchisées.
La séquence vidéo commence par une en-tête contenant des données d’identification
et d’encodage. Elle contient un ou plusieurs groupes d’images, et se termine par un code
permettant de détecter la fin de la séquence.
Un groupe d’images (Group of Pictures - GOP) contient une en-tête et plusieurs
images. C’est l’entité qui permet l’accès aléatoire à une partie de la vidéo.
Une image est l’entité élementaire encodée. Elle est composée de trois matrices Y ,
Cr et Cb comme l’explicite [Prat91] (où elles sont notées Y , U , V ). Y correspond à
la luminance de l’image : c’est en quelque sorte la quantité de lumière de la couleur,
une “distance” de la couleur par rapport au noir. Ainsi, sur la figure 1.1 on peut voir le
même rouge à des luminances croissantes. C r et Cb sont des composantes chromatiques.
On peut estimer qu’une couleur peut être repérée suivant les deux axes rouge/vert et
bleu/jaune. Cr représente la distance de la couleur à la couleur rouge. C b représente la
distance de la couleur à la couleur bleue. L’intérêt de cette représentation chromatique
pour la compression est que l’oeil humain est moins sensible aux légères différences au
niveau de la chrominance qu’à des différences équivalentes au niveau de la luminance.
Il est donc possible de représenter les matrices C r et Cb moins finement que la matrice
Y . Ceci est un avantage par rapport au système RGB (red green blue - rouge vert bleu)
qui lui réclame la même quantité de données pour les trois composantes de la couleur.
Ces images sont elles-mêmes découpées en tranches (slice), qui sont principalement
utilisées dans la gesion d’erreurs (de compression, de décompression, de transmission).
5
F IG . 1.1 – Luminance : exemple
Les tranches sont composées de macroblocs qui regroupent eux-mêmes des blocs de
pixels représentés par leurs valeurs Y , C r et Cv . Les blocs sont de dimension 8x8 pixels,
les macroblocs sont de dimension 2x2 blocs.
1.2.2 Compression temporelle
La compression temporelle repose sur le fait que la différence entre deux images
consécutives d’une vidéo est faible. Ceci est exploité en considérant des groupes d’images, les images étant de types différents. Il existe trois types d’images dans le format
MPEG :
– les images I (I-frames pour infracoded frames – images intracodées)
– les images P (P-frames pour predicted frames – images prédites)
– les images B (B-frames pour bidirectional frames – images bidirectionnelles)
Les images I sont encodées indépendamment du reste de la vidéo (nous verrons comment en 1.2.3). L’image compressée contient de l’information absolue, plus ou moins
dégradée en fonction de la qualité finale voulue de la vidéo.
Les images P sont encodées par rapport à des images de référence : on calcule leur
différence par rapport à cette référence. L’encodage se fait ici au niveau des macroblocs.
Si un macrobloc correspond à un élément nouveau par rapport à l’image de référence
(arrivée d’un élément nouveau dans une scène, changement de scène), le macrobloc
inconnu est encodé comme un macrobloc d’une image I.
Sinon, le mouvement entre l’image de référence et l’image actuelle est prévisible. Les
données sont alors stockées sous la forme d’un vecteur de mouvement (motion vector)
qui détermine la position du macrobloc par rapport à son équivalent dans l’image de
référence.
Il est à noter que cette image P peut être utilisée comme référence pour un autre
calcul relatif. L’inconvénient est donc la propagation inévitable des erreurs.
Les images de type B sont encodées avec une double référence : une image précédente
et une image suivante, selon le même principe que les images P. Les images B ne sont
pas utilisées comme référence pour un autre calcul relatif.
6
1.2.3 Compression spatiale
Les images de type I sont les plus volumineuses car elles contiennent plus d’information, c’est pourquoi il est nécessaire de les compresser beaucoup. Le principe général
de cette compression est que l’oeil humain est plus sensible au bruit dans les fréquences
spatiales basses que dans les fréquences spatiales hautes.
Pour tenir compte de ce fait, l’image doit être décomposée fréquentiellement, ce qui se
fait par le moyen d’une transformée discrète en cosinus bidimensionnelle(DCT - Discrete
Cosine Transform). Pour chaque bloc (i, j) on calcule
−1
N
−1 N
X
X
2x − 1
1
2y − 1
Sxy cos iπ
Ci ∗ C j ∗
D(i, j) =
cos jπ
4
2N
2N
x=0 y=0
(
√1
si
n=0
2
Cn =
0 sinon
avec N la taille du bloc (soit ici 8) et S xy la valeur (Y , Cb ou Cr ) de la matrice considérée
au point (x, y) du bloc.
En pratique, ce n’est pas cette formule qui est directement utilisée, mais une version
optimisée (algorithmiquement parlant) pour accélérer la compression.
Ceci en soit n’est pas une compression : on passe d’une valeur entière à une valeur
décimale, ce qui est a priori plus volumineux. Il faut donc quantifier les valeurs de DCT
obtenues suivant une grille de quantification. Cette grille sera plus fine en hautes fréquences, plus large en basses fréquences. La quantité d’information est donc réduite.
Une compression standard (de type Huffman par exemple) permet de compresser sans
perte cette information. Globalement, la perte d’information de la compression est uniquement liée à la quantification des composantes fréquentielles de l’image.
Pour décompresser l’image, il suffit de décompresser les données quantifiées, d’appliquer la grille définie (et présente dans les informations du flux vidéo), et d’appliquer une
transformée discrète en cosinus inverse. Les images de type P sont ensuite reconstruites
à partir des images I décompressées (ou des images P précédentes) et des informations
contenues dans les macroblocs. Finalement, les images B sont reconstruites à partir des
images existantes.
1.3
La diffusion de video sur réseau
1.3.1 La préparation des flux MPEG
La transmission de données sur un réseau se fait par paquets et non par flux continus.
Il faut donc diviser le flux de vidéo en paquets pour permettre leur envoi par le biais d’un
réseau IP1 [Tryf96].
1
Le protocole IP est le protocole bas niveau actuellement le plus utilisé pour transmettre des données
informatiques sur un réseau.
7
Pour ce faire, on utilise les Transport Stream (TS) qui sont utilisés pour la transmission multiple dans un environnement sujet aux erreurs. Les flux vidéos sont divisés
en paquets, les PES (packetized elementary streams - flux élémentaires découpés). Ces
PES sont, dans le cadre du TS, de taille constante, et ne sont donc pas corrélés avec les
différentes images du flux car une image P ne fait pas la même taille qu’une image I par
exemple.
Un paquet de transport est composé de 188 octets, et contient 4 octets d’entêtes et les
données du flux. Comme un paquet au sens du réseau ne peut contenir les données que
d’un seul PES à la fois, celui-ci contiendra aussi souvent du “remplissage” pour convenir
à cette contrainte.
Les entêtes du paquet de transport sont composées de
– un code de début de paquet, pour faciliter la synchronisation et l’identification
d’un nouveau paquet
– un code indiquant le début d’un nouveau PES, ou la transmission de données hors
flux
– un numéro d’identification du flux (utilisé dans le cas de plusieurs flux multiplexés)
– un indicateur de priorité de transmission
– un compteur de continuité, incrémenté à chaque fois qu’un nouveau paquet de
transport est généré pour un flux donné, utilisé pour détecter la perte de paquets.
1.3.2 RTP et RTCP
Dans le cadre de la téléopération, le retour doit se faire autant que possible en temps
réel, c’est-à-dire que le retour doit se faire à des vitesses comparables aux vitesses d’exécution de la tâche. Cela ne pose pas forcément de problème dans le cadre d’un véhicule
d’exploration lent, mais peut en poser plus dans le cadre de la téléchirurgie. Or, il est
difficile de garantir un trafic donné pour le retour vidéo. Bien évidemment, on dispose
en général pour les applications critiques de réseaux dédiés et sécurisés. Mais la surveillance de la transmission est d’autant plus nécessaire que le canal est peu fiable, ce
qui est le cas d’un réseau IP comme Internet.
Ainsi, comme on le verra au chapitre 3, les transmissions sur Internet peuvent être
sujettes à des retards dus au routage et à des pertes qui sont le plus souvent des retards
trop importants. La bande passante allouable au retour vidéo peut aussi être modifiée au
cours du temps. Ces paramètres modifient la qualité de la vidéo retransmise et doivent
donc faire partie intégrante de la boucle de téléopération.
C’est pourquoi il est nécessaire d’encapsuler la vidéo dans une entité plus large contenant aussi ces informations.
RTP (real-time transport protocol) et RTCP (RTP control protocol) sont définis dans
[RFC1]. RTP permet d’encapsuler les données vidéo ou audio dans un format valide pour
la transmission réseau, mais n’offre pas de garanties quant à la qualité de la transmission
réseau. RTCP permet de contrôler la bonne marche de la transmission par RTP.
8
RTP divise les données à envoyer (dans le cas qui nous intéresse, de la vidéo MPEG)
en paquets. Ces paquets contiennent les entêtes RTP et la vidéo MPEG comme traité en
(1.3.1). Les entêtes RTP contiennent principalement des informations de synchronisation et de datage. Des entêtes supplémentaires peuvent également être définis suivant
les besoins de l’application considérée. Mais RTP ne garantit pas la délivrance des paquets, ni l’ordre d’arrivée des paquets, ni la qualité du réseau sous-jacent.
C’est précisément à cela que sert RTCP, qui ne transporte pas de données au sens qui
nous intéresse (vidéo) mais qui propose un certain nombre de mécanismes :
– Retour sur la qualité des données reçues – ce qui peut être intéressant dans le
cadre d’une compression adaptative ou dans pour le diagnostic de problèmes de
connection
– Gestion des identifiants des clients : chaque client reçoit un identifiant unique,
qui peut également servir à associer des flux multiples (par exemple assurer la
synchronisation vidéo/audio).
– Contrôle du nombre de paquets RTCP que les clients doivent envoyer. Ce nombre
peut être plus élevé si le nombre de clients est faible pour assurer un meilleur suivi
de l’état des connections, mais doit être plus faible si le nombre de clients est élevé
pour ne pas surcharger le réseau.
– Stockage d’informations de session minimales, qui sans pouvoir se substituer à
un réel contrôle des sessions au niveau applicatif, permet un contrôle de base
relativement simplement.
Comme les entêtes RTP, les paquets RTCP sont constitués d’un certain nombre de
champs fixes et de champs supplémentaires utilisables selon l’application.
La combinaison des protocoles RTP et RTCP permet donc la diffusion vidéo en boucle
fermée au sens de l’automatique, avec un retour possible par RTCP de la qualimétrie réseau finale, et, par l’intermédiaire des entêtes supplémentaires, de la qualimétrie vidéo
finale. Il est tout de même à noter que ce retour induit forcément un retard non négligeable (à cause des temps de transmissions réseau) par rapport aux contraintes temps
réel de la compression vidéo.
9
Chapitre 2
Mesure de la qualité vidéo
2.1
Introduction
Le retour vidéo d’une boucle de téléopération doit être maintenu à une qualité minimale que l’opérateur soit en mesure de l’exploiter. S’il n’est par exemple pas possible de
faire la différence entre le sol et un obstacle, il sera difficile de piloter un robot mobile
dans l’environnement considéré. Comme la vidéo subit une dégradation au cours de la
compression nécessaire à sa transmission, la mesure de la qualité finale est essentielle
au bon déroulement des opérations, quitte à pouvoir les annuler automatiquement si
elle passe en-dessous d’un certain seuil critique.
Cette problématique est encore plus importante dans le cadre plus large de la DVBT/DVB-S. En effet, la qualité de la vidéo perçue par le client final est non seulement
un argument commercial, mais fait partie des obligations de résultats (ou au moins de
moyens) de tout fournisseur de services vidéo.
Mais ce problème est complexe : comment quantifier la qualité d’une vidéo ? Un être
humain pourra parler d’une “bonne qualité”, d’une “mauvaise qualité”, d’une “bonne
qualité dans l’ensemble”... L’association d’une échelle numérique à ces critères peut être
une idée valable, mais reste fortement dépendante de la sensibilité du spectateur. Cela
reste tout de même le meilleur moyen de savoir si la vidéo est visuellement acceptable
ou non.
Inversement, un critère “automatisé” pose le problème de la cohérence avec la vision
humaine, mais il serait a priori plus facilement quantifiable.
Nous allons donc passer en revue les différentes méthodes de qualimétrie vidéo.
2.2
Indicateurs subjectifs
Étant donné que la qualité vidéo est estimée au final par les utilisateurs du service, une mesure subjective, c’est-à-dire basée sur l’avis d’un échantillon de population,
semble le plus naturel.
10
Échelle
5
4
3
2
1
Distorsion
Imperceptible
Perceptible sans être gênante
Légèrement gênante
Gênante
Très gênante
TAB . 2.1 – Echelle de mesure subjective
Une échelle de 1 à 5 est communément utilisée pour quantifier la distorsion perçue
par les utilisateurs [ITU95], comme le présente 1 le tableau 2.1.
[ITU95] propose une méthodologie en ce qui concerne la mesure de qualité de la
vidéo destinée à la télévision. Cette méthodologie recouvre aussi bien l’environnement
d’expérimenation que le choix des observateurs et les protocoles de test.
Les directives concernant l’environnement d’expérimentation (luminosité externe, luminosité de l’écran, taille de l’écran) ont pour objectif une reconstitution légèrement
défavorable par rapport à un environnement considéré comme standard pour l’utilisateur final.
Les observateurs constituent de préférence un groupe d’au minimum 15 personnes
n’ayant pas de lien avec l’étude de la qualité vidéo. Ils doivent être informés des types
de distorsion recherchés.
[Tekt97] explicite quelques protocoles de tests de vidéo, parmi lesquels on peut distinguer :
– les méthodes à stimulus simple :
– discret : des échantillons de test, indépendants ou non, sont projetés et jugés
par les observateurs.
– continu : une video continue est projetée et les mesures sont prises à des instants
donnés de cette vidéo
– les méthodes à stimulus double :
– comparaison par rapport à une référence : deux images sont présentées à l’observateur. La première est considérée comme la référence, la seconde est jugée
par rapport à la première.
– comparaison entre deux scènes de qualité différentes : la référence et l’image
dégradée sont projetées dans un ordre aléatoire et les deux images sont jugées.
L’analyse des résultats se fait par rapport à la différence de notation entre les
images.
– les méthodes comparatives : l’image de référence et l’image dégradée sont présentées en même temps sur des écrans similaires et sont jugées en absolu (une note à
chaque image) ou en relatif (une image est meilleure ou moins bonne que l’autre).
1
Selon les auteurs, cette échelle peut être inversée.
11
[Tekt97] cite les avantages et les inconvénients des indicateurs subjectifs. En particulier :
– les résultats obtenus sont valides pour des vidéos compressées ou non
– une moyenne des mesures de plusieurs observateurs est un indicateur valide quant
à la qualité globale des vidéos ou images.
Mais
– les méthodes et critères de tests sont nombreux
– la configuration matérielle (conditions “réelle”) est lourde et difficilment reproductible
– de nombreux observateurs doivent être sélectionnés et surveillés
– la complexité générale est énorme et pose surtout des problèmes de temps.
Quoi qu’il en soit, il est facile de voir qu’un indicateur subjectif est difficile à mettre
en place dans le cadre d’un stage DEA, et que son utilisation dans le cadre qui nous
intéresse est tout à fait irréalisable.
2.3
Indicateurs objectifs
2.3.1 Remarques préliminaires
Les indicateurs subjectifs étant clairement trop complexes pour une utilisation courante, le développement d’indicateurs objectifs s’impose. [Wolf90], en particulier dans
sa section 2.2, propose un ensemble de recommandations pour les indicateurs de qualité
objectifs :
– Cohérence avec les indicateurs subjectifs, puisque le but d’un indicateur objectif
est précisément de remplacer un indicateur subjectif.
– Automatisation totale : le gain de performance éventuel est fortement diminué si
une intervention humaine est nécessaire.
– Résultats exploitables sur tous types de vidéo, ce qui est particulièrement important dans notre cas car la vidéo diffusée n’est pas forcément connue a priori.
– Application locale de l’indicateur possible : l’oeil humain a tendance à se focaliser,
pour l’estimation de la qualité, sur les détails tels que les angles, arrêtes, formes
caractéristiques. Pour être cohérent avec un indicateur subjectif, un indicateur objectif doit prendre en compte cette caractéristique.
– Complexité algorithmique réduite : la rapidité de l’algorithme doit être prise en
compte pour l’évaluation d’un indicateur. L’idéal serait de pouvoir évaluer la qualité de la vidéo en temps réel par rapport à sa compression.
– Robustesse par rapport aux différences image de référence / image dégradée.
On peut diviser les indicateurs objectifs en deux catégories. La première catégorie part
du principe que si le signal composant une image est différent / dégradé par rapport
à celui d’une image de référence, alors l’image sera dégradée, avec une dépendance
plus ou moins directe. La deuxième catégorie s’appuie sur un modèle de la perception
humaine pour dégager des critères facilement distinguables par un ordinateur.
12
2.3.2 Indicateurs basés sur la qualité du signal image
Une image peut être considérée comme un signal (image en niveaux de gris) ou
un ensemble de signaux bidirectionnels (image couleur) F (x, y) (voir [Adji01]). Ces
signaux peuvent être donnés dans différents systèmes de couleurs : RGB, Yuv... (voir
[Prat91] pour ces différents systèmes).
Les indicateurs de la première catégorie quantifient la différence du signal bidirectionnel de l’image compressée puis décompressée par rapport au signal de référence.
En particulier, un indicateur très utilisé est le PNSR (Peak Signal to Noise Ratio –
rapport ) défini dans [Adji01]. Si on considère une image F (x, y) de dimensions N × M
et sa reconstituée après compression et décompression F̂ (x, y), on peut définir l’erreur
moyenne par pixel par
v
u
N X
M
u 1 X
| F (i, j) − F̂ (i, j) |2
RM SE = t
NM
x=1 y=1
Le M SE (mean signal error - erreur moyenne du signal) = RM SE 2 peut être considéré en soi comme un indicateur.
Si F est monosignal
(image en niveaux de gris), F est un scalaire. Sinon, on consiPP
dère en général F =
| Fi (x, y)− F̂j (x, y) |2 , où les i et j représentent les différentes
i
j
composantes de l’espace de couleurs choisi. On peut également travailler indépendamment sur ces composantes.
On définit alors le PNSR par
P N SR(F → F̂ ) = 20 log 10
valeur maximale d’un pixel
RM SE
où la valeur maximale d’un pixel est la valeur maximale de la plage de valeurs de la composante d’un pixel. Ainsi, dans le système RGB, on utilisera 255 comme valeur maximale
des trois composantes R, G et B.
Ces indicateurs sont assez largement utilisés car leur complexité algorithmique est
très faible. Néanmoins, ils reflètent en général assez mal la qualité réelle de la vidéo ou
de l’image. En effet, l’oeil humain n’est pas forcément sensible aux mêmes distorsions
(c’est-à-dire à un PNSR égal) selon le type de la distorsion ou selon la zone de l’image
considérée. Ainsi, à PNSR égal, une distorsion est en général moins gênante à l’arrièrefond qu’à l’avant-plan.
2.3.3 Indicateurs basés sur la vision
Les indicateurs basés sur le signal étant assez peu satisfaisants, on se penche aujourd’hui sur des indicateurs utilisant un modèle de la vision humaine pour évaluer des
images et/ou des vidéos.
13
Description des artefacts de compression
La baisse de qualité induit des artefacts sur la vidéo compressée. On peut distinguer,
comme l’explique [Geni02], plusieurs types d’artefacts gênants détaillés ci dessous.
Saccades (jerkiness) Le fait que la vidéo ait l’air saccadée peut provenir de plusieurs
causes. Si la vidéo a été transmise par réseau, cela peut être dû à des pertes de données.
Si la vidéo a été compressée à un taux très bas, l’encodeur peut avoir répété une image
plusieurs fois pour gagner de la place. Des saccades partielles peuvent aussi apparaître
comme conséquence des blocs.
Blocs (blockiness) Les blocs apparaissent comme conséquence directe du découpage
en blocs comme vu en (1.2.3). La DCT est appliquée et quantifiée indépendamment aux
différents blocs 8 × 8 et on peut voir apparaître des lignes horizontales ou verticales
suivant les séparations de ces blocs.
Flou (bluriness) On parle de flou lorsque les détails fins et la netteté des bords disparaissent. Cet artefact apparaît peu en compression MPEG.
Bruit (noise) Le bruit représente les distorsions hautes fréquences, qui peut apparaître
principalement sur des problèmes matériels (acquisition, transmission).
Dans le cas de la vidéo MPEG, on observe surtout des saccades et des blocs.
Deux approches pour l’évaluation de la gêne visuelle peuvent être trouvées : les approches intrinsèques à un type de compression (s’intéressant aux artefacts induits par
ladite compression) et les approches plus générales.
Détection d’artefacts de compression
[Wink01] résume 3 algorithmes de détection de blocs.
Par exemple, l’algorithme de Wang, Bovik et Evans modélise l’image finale sous la
forme d’une image non bruitée à laquelle s’ajoute un bruit en blocs. L’utilisation de
transformées de Fourier sur les signaux horizontaux et verticaux de l’image permet de
déterminer des pics dans les spectres horizontaux et verticaux. L’image non bruitée est
approximée, et l’indicateur est calculé par le biais de la différence entre la valeur mesurée et la valeur estimée des spectres à hauteur des pics.
Ce genre d’algorithme est plutôt plus intéressant que les algorithmes type PNSR car
ils prennent en compte le type de distorsion. Nous pensons que les distorsions les plus
gênantes au niveau de la compression MPEG sont celles de type bloc, c’est pourquoi ce
genre d’approche paraît prometteuse.
Néanmoins, il faut signaler que les outils décrits ici sont également indépendants au
niveau par exemple de l’arrière-fond/avant-plan. Une compression MPEG4 implémentant la norme au niveau de la différence arrière-fond/avant-plan ([ISO02]) permettrait
peut-être une pondération efficace.
14
Métriques “générales”
[Li98] compare deux métriques plus générales : le Daly Visible Differences Predictor
(VDP) et le Sarnoff Visual Discrimination Model (VDM).
Le VDP produit, à partir de deux images, une carte de différences et une probabilité
de détection de ces différences par un oeil humain. Les deux images sont d’abord transformée à travers un filtre non linéaire pour prendre en compte la réponse des neurones
rétinaux à la luminance de l’image.
Les images sont ensuite converties dans le domaine fréquentiel. Les données ainsi
obtenues sont pondérées par la fonction de sensibilité humaine au contraste (contrast
sensivity function - CSF). Cette fonction permet de prendre en compte la sensibilité de
l’oeil humain aux différentes fréquences spatiales.
Les images sont alors décomposées suivant 31 canaux qui représentent différentes
composantes de la sensibilité de l’oeil humain. Les canaux résultants sont retransformés
dans le domaine spatial.
Tous les canaux sont associés à un masque de contraste fonction de l’endroit dans
l’image. Une carte de valeurs est calculée par rapport à ce masque. On a donc 31∗2 cartes
(31 canaux, 2 images). Les masques sont associés canal par canal pour les deux images
afin d’obtenir une carte globale de seuil de détection pour chaque canal de l’image.
La probabilité de détection est alors calculée en fonction des différences canal par
canal des deux images (normalisées par le seuil précédemment calculé).
Le VDM travaille, à l’inverse de la méthode précédente, uniquement dans le domaine
spatial. La méthode utilise le même type d’outils : décompositions en canaux, transformations diverses, et donne au final une carte de différences notables (Just Noticeable
Differences - JND).
2.4
Conclusion
La qualimétrie vidéo est encore un champ très vaste. En particulier, on commence
à disposer de métriques plus ou moins utilisables pour des images, mais le champ de
la vidéo en temps que suite continue d’images est assez peu exploitée. La détection
d’artefacts de compression (en particulier les blocs) nous semble un bon compromis
“calculabilité/efficacité”. De plus elle permet une qualimétrie non relative à une image
de référence, ce qui peut être intéressant pour une qualimétrie en fin de chaîne (après
transmission) où l’image de référence n’est pas disponible.
15
Chapitre 3
Mesure de la qualité du réseau
3.1
Introduction
La qualité de la vidéo ne dépend pas que du facteur de compression appliqué. Elle
dépend également dans une large mesure de la qualité du réseau sous-jacent. Deux
phénomènes peuvent principalement affecter cette qualité : les pertes de paquets et les
retards de paquets.
Les pertes de paquets correspondent à une perte directe de l’information correspondante. Si cette information concerne une image de type I, cela peut provoquer la perte
d’un groupe complet d’images puisque les images P et B la prenant pour référence seraient perdues aussi.
Les retards de paquets peuvent induire des saccades dans la vidéo résultante. Ile est
possible de compenser ce fait par l’introduction d’un tampon vidéo à l’arrivée, mais cela
implique un retard correspondant à la taille du tampon dans la vidéo finale. Il faut donc
gérer le compromis taille du tampon/retard possible.
Les pertes de paquets sont estimées en termes de probabilités qu’un paquet arrive ou
non à destination. Le retard est exprimé en terme de retard moyen entre l’émission et la
réception des informations, et est exprimé en général en millisecondes ms.
Il est à noter qu’un paquet est rarement “perdu” au sens premier du terme, il arrive
plus souvent qu’il soit tellement retardé qu’il soit considéré comme tel.Les notions de
pertes et de retards sont donc intimement liées.
3.2
Problèmes généraux de la mesure de paramètres réseau
Il existe en général deux méthodes de mesure : les mesures à sens unique et les
mesures à double sens [Jian99]. Les mesures à sens unique s’intéressent au temps de
parcours des données entre deux points A et B, dans le sens A → B ou B → A. Les
mesures à double sens s’intéressent au temps d’aller-retour A → (B) → A. Mais, de
manière générale, on a une bonne estimation de la mesure “double sens” en associant
les mesures obtenues pour chacun des sens.
16
Pour mesurer le retard ou les pertes de paquets, on utilise, dans le cadre d’une mesure
à sens unique, la différence entre la date de départ d’un paquet et la date d’arrivée de
ce même paquet. Un paquet est considéré comme perdu s’il n’arrive pas au bout d’un
temps t donné (la numérotation des paquets s’impose donc pour cette application). Dans
le cadre d’une mesure à double sens, on s’intéresse au temps de parcours total de A vers
A en passant par B.
La mesure à sens unique pose un certain nombre de problèmes, en particulier de
synchronisation d’horloges. En effet, pour que la mesure soit valide, il faut que les horloges des points A et B soient synchrones à la milliseconde près. De plus, la dérive des
horloges est non négligeable (de l’ordre de 100 µs par seconde), ce qui implique une resynchronisation régulière des horloges. Finalement se pose le problème de la résolution
des horloges : certains systèmes (matériels et logiciels) ne permettent pas de mesure
sur un échantillonage de temps inférieur à 10ms. C’est un point auquel il faut faire attention, mais qui en pratique est largement contourné par les processeurs et systèmes
d’exploitation actuels. Le protocole NTP (Network Time Protocol) largement utilisé pour
gérer l’heure sur des serveurs ne peut ici pas être utilisé car il utilise le réseau pour transmettre les données et est donc sujet aux mêmes erreurs qu’estimées précédemment – ce
qui ne pose pas de problème dans le cadre d’une utilisation “standard” de la base de
temps, mais qui est inexploitable dans le cas qui nous intéresse.
Pour pallier ces problèmes, il existe plusieurs solutions :
– utiliser une mesure à double sens comme estimation du double de la mesure à sens
unique, ce qui n’est pas forcément précis, le temps d’aller peut être par exemple
beaucoup plus court que le temps de retour car dans un réseau de type Internet
les routes aller et retour ne sont pas forcément les mêmes
– utilisation du réseau téléphonique, qui a un retard mesurable et sensiblement
constant, comme base de comparaison pour la synchronisation.
– utiliser le système GPS comme base de temps absolu – cette solution est néanmoins
limitée par son coût.
La qualité de service d’un réseau se mesure par le taux de paquets perdus et le retard
moyen de transmission.
3.3
Mesure de la bande passante
On définit la bande passante comme le débit maximum (en octets/seconde) qu’une
connection réseau peut allouer à un flux sans réduire le traffic des autres données transitant par cette connection. Elle est donc directement liée au taux de compression minimal
de la vidéo à transmettre : plus la bande passante est réduite, plus la vidéo devra être
compressée.
Dans le cas d’une transmission point à point (c’est-à-dire directe), la question de la
mesure de bande passante ne se pose pas. Elle est égale au minimum des bandes passantes allouables par les deux points de la connection. Cette information est connue par
les deux points et peut donc être utilisée telle quelle.
17
À l’inverse, dans le cas d’un réseau routé (comme Internet), le chemin utilisé n’est
pas connu a priori par l’émetteur ni par le récepteur. Il est donc difficile de connaître ses
capacités.
On peut mesurer la bande passante de plusieurs manières. Nous présenterons ici plusieurs approches, citées ou développées dans [Lai99] et [Jain02].
La bande passante du goulot d’étranglement et la bande passante disponible sont
définies dans [Lai99]. La bande passante du goulot d’étranglement est, pour une route
donnée, la bande passante idéale du lien de la route ayant la plus petite bande passante.
La bande passante disponible est la bande passante maximale entre un point et un autre.
La bande passante disponible et la bande passante du goulot d’étranglement des
différents chemins sont liées ; on peut donc se contenter d’analyser la bande passante
des goulots d’étranglement.
[Lai99] présente différentes manières de mesurer cette bande passante, et propose sa
solution qui consiste en l’amélioration d’une solution existante.
L’approche la plus fréquente est d’évaluer la bande passante par la sortie du réseau,
c’est-à-dire le nombre d’octets par seconde que la sortie délivre. Mais cela n’est pas
forcément très fiable car d’autres facteurs, comme les pertes de paquets, peuvent influer
sur cette mesure. De plus il est difficile de savoir de cette manière comment exactement
se comporte le système face à des données ou des protocoles particuliers.
Le transfert par TCP fait appel à une autre méthode : on envoie de plus en plus de
paquets jusqu’à ce que l’un d’eux ne soit pas transmis. On évalue alors que la taille
de la bande passante se situe entre le taux de transmission courant et la moitié de ce
taux. Cette méthode présente l’inconvénient de saturer le réseau pour la mesure, ce qui
peut être problématique. De plus, l’augmentation du taux de transmission doit se faire
progressivement, au risque de surévaluer la bande passante disponible.
Le logiciel offre une réelle mesure de bande passante. Il envoie des paquets
de données de différentes tailles et attend leur retour. Mais cette méthode est lente (car
il faut attendre le retour des paquets) et envoie beaucoup de données sur le réseau.
L’algorithme “Packet Pair” (paire de paquets) s’appuie sur le postulat que deux paquets
adjacents sont séparés à l’arrivée par le temps t = s 2 /b où s2 est la taille du second
paquet et b la bande passante. Les deux paquets doivent avoir la même taille, car deux
paquets de taille différentes n’ont pas forcément la même vitesse. Cette méthode en
elle-même présente des problèmes de robustesse. Ainsi, il est impossible de garantir
que les deux paquets se trouveront exactement l’un derrière l’autre : si des paquet tiers
s’insèrent entre les deux, la mesure est faussée. [Lai99] propose un filtrage de cette
mesure pour augmenter sa robustesse.
18
[Jain02] propose une métrique basée sur l’envoi de flux périodiques de paquets. Le
flux est composé de K paquets de L bits, transmis en T secondes. Le taux de transmission est alors R = L/T .
Tous les paquets sont datés avant la transmission - ils encapsulent donc une date
de départ ti . La machine à l’arrivée calcule Di = ai − ti où ai est la date d’arrivée du
paquet. Di présente un décalage car les deux machines ne sont pas synchronisées, mais
cela n’est pas un problème pour cette méthode car elle s’intéresse aux variations de D i
et non pas à sa valeur absolue.
Lorsque R est plus grand que la bande passante A, le flux induit une surcharge de
la transmission. Pendant cette surcharge, la file d’attente du goulot d’étranglement du
chemin va grandir, et cela se répercutera par une croissance des retards de transmission
Dk . A l’inverse, si R < A, les Dk sont sensiblement constants.
Les deux points (envoi et réception) doivent communiquer par un canal supplémentaire pour assurer la convergence itérative de R vers A.
3.4
Mesure des retards
Une mesure des retards est nécessaire au niveau de la boucle de téléopération car
elle permet de gérer le compromis taille du tampon vidéo/contraintes temps réel de
l’application. Si la taille du tampon devient trop élevée, on considère alors que les paquets sont perdus. On peut alors estimer que, si la transmission réseau se dégrade trop,
le contrôle distant peut être coupé et le robot devrait revenir à un état sauf.
Les retards peuvent être considérés comme des réalisations d’une variable aléatoire d
[Jian99]. Ils ne sont pas non plus indépendants les uns par rapports aux autres car sont
souvent dûs à la même congestion (encombrement) réseau. Cette dépendance a une
conséquence importante sur la qualité des services vidéo. En général, lorsqu’un paquet
excède un certain retard, le paquet est considéré comme perdu. Mais ce retard influe
avec une probabilité forte sur le paquet suivant, qui peut alors être perdu lui aussi. Ceci
implique des retards/pertes consécutifs, qui sont difficiles à corriger.
On peut estimer l’autocorrélation de la variable d par
ρ(d, l) =
n−l
P
i=1
¯ i+l − d)
¯
(di − d)(d
n
P
i=1
¯2
(di − d)
l est le décalage de l’autocorrélation, d i est la mesure du retard du ie paquet, d¯ est le
retard moyen. L’autocorrélation donne une valeur sur [−1, 1]. Si elle est proche de 0, la
dépendance est faible. Si elle est proche de 1, elle est fortement corrélée (un long retard
sera suivi d’un long retard). Si elle est proche de -1, la dépendance sera inverse (un long
retard sera suivi d’un retard plus faible).
En général, l’autocorrélation est plus grande pour l = 0 et baisse lorque l augmente,
ce qui est conforme à l’intuition : des retards temporellement proches sont plus corrélés
que des retards temporellement éloignés.
19
Mais l’autocorrélation, si elle peut être un bon indicateur de dépendance, est difficile
à utiliser en temps que mesure. C’est pouquoi on utilisera de préférence la ccdf (conditional cumulative delay distribution – distribution cumulative de retards conditionnels),
définie par :
f (t) = P [di ≥ t | di−l ≥ t], l = 1, 2, 3, . . . ,
avec l le décalage.
[Jian99] présente également des résultats expérimentaux de mesure de ccdf. Comme
conforme à l’intuition et au calcul d’autocorrélation, la ccdf décroît avec le décalage.
Mais elle augmente brusquement après un seuil des durées de retards considérées avant
de re-décroître. Ce seuil se situe aux alentours du retard moyen. Ceci n’est pas une information déductible du simple calcul de l’autocorrélation, mais est également conforme à
l’intuition : plus les retards sont grands, plus ils influent sur les retards suivants.
3.5
Mesure du taux de paquets perdus
Les pertes de paquets correspondent soit à une perte pure d’information, soit à un
retard correspondant au renvoi du paquet et à son insertion dans le tampon vidéo. C’est,
comme la mesure des retards, un bon indicateur de la qualité du réseau sous-jacent
permettant le cas échéant l’arrêt des opérations.
On calcule le taux de paquets perdus par un modèle probabiliste. [Jian99] utilise
un modèle de Gilbert pour modéliser les pertes de paquets sur un réseau. En effet,
les pertes de paquets ne sont pas indépendantes : les pertes à l’instant précédent et à
l’instant courant sont corrélées car sont dues en général à une congestion réseau.
On note p la probabilité qu’un paquet soit perdu, sachant que le précédent est arrivé.
On note q la probabilité que le paquet arrive, sachant que le précédent a été perdu. On
note 1 et 0 respectivement les états : “le paquet est perdu” et “le paquet est arrivé”. On
a donc l’automate à états finis de la figure 3.1.
F IG . 3.1 – Automate à états finis du modèle de Gilbert
20
On peut alors calculer π0 et π1 les probabilités des états 0 et 1 respectivement. On
peut déduire, par un simple calcul de probabilités conditionnelles, que
q
p+q
p
p+q
π0 =
π1 =
Reste donc à estimer p et q. Si on note o i le nombre de suite de i pertes de paquets
et o0 le nombre de paquets délivrés, on peut obtenir une estimation de p et q par
p =
n−1
P
oi
i=1
o0
q = 1−
n−1
P
oi (i
i=2
n−1
P
− 1)
oi i
i=1
On peut donc en déduire π0 et π1 correspondant aux probabilités d’arrivée ou non
d’un paquet.
Ce qui précède est un modèle simplifié du modèle de Markov, où la probabilité conditionnelle est calculée sur tous états précédents et non pas uniquement sur le dernier. Le
modèle de Markov présente l’inconvénient de nécessiter un nombre exponentiel d’états
en fonction du nombre de paquets.
Un bon compromis est alors d’utiliser un modèle de Gilbert étendu, qui tient compte
des n derniers paquets, n fixé.
21
Conclusion
Nous avons présenté dans ce rapport bibliographique les méthodes et outils qui serviront à traiter le problème de l’optimisation de bande passante dans le cadre de diffusion
vidéo multiple.
Ainsi, le format de fichiers vidéo MPEG et les protocoles RTP/RTCP, sur lesquels nous
nous focaliserons pour l’implémentation, ont été définis et expliqués. Le problème de la
qualimétrie vidéo a été posé, et reste pour le moment en suspens faute de méthodologie
réellement établie pour la qualimétrie objective. La théorie de la qualimétrie réseau a
été développée, mais nécessite un approfondissement au niveau pratique (qui sort du
cadre de cette phase documentaire).
La suite de ce projet de DEA consistera en la mise en oeuvre pratique (implémentation) des outils présentés et la résolution du problème posé.
22
Bibliographie
[Adji01]
C. Adjih. Multimedia et accès à l’Internet haut-débit : l’analyse de la filière
câble. Thèse de doctorat, Université de Versailles - Saint-Quentin en Yvelines,
June 2001, p. 137–138.
[Eise95]
B. Eisert.
Was ist MPEG ? Ein erklärung von Björn Eisert, 1995.
"! "
"#$""
%&'("
)# *! .
URL :
[Geni02] Genista. Video quality metrics. Rap. tech., Genista Perceptual Quality Metrics,
2002.
[ISO02]
ISO. MPEG-4 Overview. Rap. tech. ISO/IEC JTC1/SC29/WG11 N4668, ISO International Organisation for Standardisation, Mars 2002.
[ITU95]
ITU. Recommendation ITU-R BT.500-7 - Methodology for the Subjective Assessment of the Quality of Television Pictures. Rap. tech., October 1995.
[Jain02] M. Jain et C. Dovrolis. Pathload : A measurement tool for end-to-end available
bandwidth. Dans Passive and Active Measurements (PAM) Workshop. 2002.
[Jian99] W. Jiang et H. Schulzrinne. QoS Measurement of Internet Real-Time Multimedia Services. Décembre 1999.
[Lai99]
K. Lai et M. Baker. Measuring Bandwidth. Dans {INFOCOM} (1)", p. 235–
245". 1999.
[Li98]
B. Li, G. W. Meyer et R. V. Klassen. A Comparison of Two Image Quality Models.
Dans SPIE Conf. on Human Vision and Electronic Imaging III,Vol. 3299, San
Jose. Janvier 1998.
[Prat91] W. K. Pratt. Digital Image Processing, Second edition, chap. 3.
Interscience, 1991.
[RFC1]
Wiley-
RTP : A Transport Protocol for Real-Time Applications. Rap. tech. RFC 1889,
Network Working Group.
[Tekt97] Tektronix. A Guide to Picture Quality Measurement for Modern Television Systems, 1997.
[Tekt02] Tektronix. A Guide to MPEG Fundamentals and Protocol Analysis, chap. 2.
Tektronix, 2002.
[Tryf96]
C. Tryfonas. MPEG-2 Transport over ATM Networks, 1996.
[Wink01] S. Winkler, A. Sharma et D. McNally. Perceptual Video Quality and Blockiness
Metrics for Multimedia Streaming Applications. Dans 4th International Symposium on Wireless Personal Multimedia Communications, p. 553–556. Septembre 2001.
23
[Wolf90] S. Wolf. NTIA Report 90-264 - Features for Automated Quality Assessment of
Digitally Transmitted Video. Rap. tech., U.S. Department of Commerce, June
1990.
24