H.264 (suite)

Ensuite, il faut savoir que la plupart des codecs de compression vidéos ne travaillent pas directement sur les images, mais découpent celles-ci en blocs de pixels qui sont traités séparément. Le MPEG-2 travaille par blocs de 16x16 pixels (pour les images prédictives, contre 8x8 pixels pour les images initiales "Intra"), alors que le H.264 permet d’une part de mélanger des blocs de différentes tailles, et d’autres part de descendre à des blocs de 4x4 pixels. Ce découpage plus fin des images permet d’obtenir une meilleure qualité sur des détails (arbres d’une forêt par exemple), tout en utilisant de gros blocs là où cela n’est pas nécessaire (un ciel bleu) afin de ne pas gâcher de la puissance de calcul.

Lors de la compression, chaque bloc subit une transformée cosinus discrète (DCT), en clair une fonction mathématique transformant le bloc de pixels en bloc de cœfficients : on passe d’une représentation spatiale à une représentation fréquentielle. La plupart des pixels d’une image ayant une intensité (valeur) proche, ils auront alors une fréquence basse, contre une fréquence élevée pour les changements rapides. L’œil ayant tendance à moins voir les détails fins ainsi que les points isolés en comparaison des détails grossiers, la compression fait alors en sorte de diminuer les valeurs de haute fréquence afin d’annuler les détails les moins visibles. L’opération inverse (IDCT), reste nécessaire pour récupérer l’image d’origine qui sera plus ou moins dégradée.

L’étape In-loop deblocking enfin vise à éliminer un problème que l’on rencontre parfois sur les vidéos basse qualité (streaming), lorsque les blocs de pixels deviennent visibles. Le deblocking consiste dès lors comme son nom l’indique à lisser les bords entre les blocs adjacents afin de faire disparaître les séparations. ATI réalisait auparavant cette opération en post-process, car elle n’était pas comprise dans le MPEG-2 du fait de sa gourmandise en calculs. Le H.264 l’intègre, en rajoutant la notion de boucle : les images « déblockées » vont ainsi, après être affichées, servir à faciliter la décompression des images suivantes : elles sont donc prises dans la boucle de décompression, et permettent une meilleur qualité.

Résultat, avec une vidéo en 1080p et un processeur classique, nous arrivons effectivement au cas suivant au niveau de l’occupation processeur, qui provoque en pratique l’affichage d’à peine une image de la vidéo sur deux, et par conséquence des saccades bien pénibles.

Dans les locaux de Columbia Pictures à Londres, ATI a pu nous faire une démonstration similaire à celle du Computex. Celle-ci s’est faite sur un PC équipé d’un Pentium 4 3.4 GHz et d’un R520 (au refroidissement identique à celui des X850 XT).

La lecture d’un flux vidéo H.264 en 1080i et 25 mbits/s (ce qui autorise environ 2 H 15 sur un disque Blu-Ray simple couche) n’a pas fait monter l’occupation processeur à plus de 33 % de moyenne, en mode fenêtré. Soit environ 2,5 fois moins que sans accélération. Impressionnant.

A noter que si le R520 et RV530 supporteront la décompression du H.264 dans toutes ses résolutions, il reste à voir si le RV515 ne sera pas limité au SD (576p/i). Quand aux puces R4xx, c’est certain : elles ne bénéficieront pas de la décompression du H.264, ATI se justifiant derrière la nécessité (notamment marketing…) d’une nouvelle architecture pour le support matériel de cette décompression.

Questionné au sujet de la possibilité d’utiliser cette capacité de décompression H.264 pour visualiser les films HD sur ordinateur portable, le canadien est là encore resté assez pessimiste. Le problème principal viendrait de l’arrivée de Windows Vista faisant perdre aux constructeurs une partie du contrôle de leur puce, donc des fonctions de désactivation des parties inoccupées du GPU, et finalement de la possibilité de préserver une autonomie correcte lors de la lecture d’un film HD.