Réduire le débit vidéo des installations temps réel grâce au codec HAP

alt

M’intéressant de plus en plus aux applications de projection en temps réel et au vidéo mapping, je suis toujours confronté en fonction des projets auxquels je participe à un problème récurrent : comment gérer l'énorme bande passante requise par une application de ce genre.

La place requise par une vidéo sur un disque dur ne représente qu'un problème économique. Il n'est pas technique. Si un projet requiert de lire 10 vidéos en même temps de manière synchronisée, à destination de 10 vidéo-projecteurs dans le but par exemple de projeter une animation sur un building, on peut tout à fait envisager d'acheter 10 disques durs supplémentaires pour assurer le stockage, en le prévoyant dans le budget. Il est alors possible d'encoder 10 vidéos en RAW (RGB ou YUV), dans des containers tels que l'AVI, le Quicktime, le MXF, le MPG ou le MKV et via l'utilisation de codecs comme le YUV422 ou le QT-Animation. La lourdeur n'est ici pas un soucis technique en soit.

La gestion des cartons et du camion

Cependant, en fonction des codecs utilisés, on peut distinguer deux problèmes principaux :

  • Lire une vidéo FullHD de 3,5Go dont la durée est d'environ 1 minute indique que le débit en Mbits/seconde va être assez élevé. C'est comme essayer de vider tout seul un camion de déménagement en moins de 5 secondes. Au bout d'un moment, les amis qui attrapent les cartons en bas du camion vont finir par vous attendre. Et bien pour votre disque dur (même les SSD dans bien des cas) c'est pareil, il y a des chances que ceux qui attendent derrière lui (processeur, mémoire, etc), l'attendent longtemps. Dans ce cas, la lecture se bloque. Pas parce que le processeur n'en peut plus ... mais parce qu'il attend que les données arrivent.

  • Si vous avez montez vos disques durs en grappes de type RAID 0+1, RAID 5 ou RAID 6, vous êtes maintenant à plusieurs dans le camion et vous pouvez lancer vos cartons en moins de 5 secondes comme des torpilles. Le problème à présent est que ceux qui attendent dehors sont limiter dans leur capacité à acheminer les cartons jusque dans l'appartement (les escaliers, tout ça). De plus, votre processeur a besoin de faire plein de choses tout en montant les escaliers. Il doit gérer le reste de la machine, demander aux infos venant du disque de prendre le BUS mémoire jusqu'à la RAM, qui elle même n'est pas forcément assez rapide pour traiter autant de cartons à la seconde, avant de la renvoyer vers le mémoire de la carte graphique, etc, etc ...

Bref, même avec un énorme budget, on ne peut pas se permettre de monter un workflow ridicule gonflé à la testostérone. Nous ne sommes plus dans le problème économique, mais bien dans un problème technique. Aussi puissantes que soient nos machines, le problème du débit d'informations est toujours quelque chose de complexe à gérer.

Réduire le débit sur le disque mais pas pour le CPU

Il est bien sur possible de réduire le débit à la source. Depuis l'apparition du MPEG, la réduction de débit via l'utilisation de la redondance temporelle est clairement LA solution pour réduire le poids d'un fichier sur le disque dur. On envoie moins de cartons à l'étage parce qu'on a réussi à mieux les remplir, en tout cas de manière plus intelligente.

Mais la contrepartie, c'est que le déballage demande plus de temps, car une fois sortie du carton et stockée dans la mémoire, il faut décompresser les données avant des les envoyer à la carte graphique. Le processeur (dont le petit nom est CPU) doit se coltiner cette décompression tout seul. Et ça lui prend du temps ... beaucoup de temps ! Surtout qu'il n'a pas que ça a faire, comme nous l'avons déjà précisé.

Ce qu'il faudrait, c'est que cette opération de décompression soit effectuée par une bande de copains sympas, à qui on donnerait les données compressés brutes et qui se chargeraient de décrypter/décompresser ces données, afin de les afficher à l'écran.

Le GPU à la rescousse

Dans un ordinateur, le processeur utilise de la mémoire RAM pour stocker les données sur lesquelles il travaille. La carte graphique (dont le petit nom est GPU) a elle aussi sa propre mémoire (VRAM), pour stocker tout un tas de textures, de buffers et bien sûr l'image qui est finalement affichée sur votre écran. Transférer des données entre ces deux types de mémoires est un processus assez lent, à l'échelle de la machine. Une trop grosse quantité de donnée devant transiter entre ces deux entités pourrait à nouveau générer un blocage.

Le mieux est donc de limiter les données qui transitent par le BUS graphique (de type PCI-Express par exemple), véritable autoroute reliant les deux composants. Il serait utile que cette décompression se fasse plutôt après le transfèrt que avant, du coté de la carte graphique et non du processeur.

Les cartes graphiques depuis une dizaine d'années ont bien changé. On peut maintenant programmer leurs comportements, afin de définir ce qu'elles doivent faire des données après les avoir reçu, via l'utilisation du concept des shaders et du GPGPU. De plus, une carte graphique est constituée non pas d'un seul processeur, mais de plusieurs centaines de mini-processeurs (nommée cores), capable de traiter chacun un morceau d'image, ou plusieurs images en parallèle dans le cas d'une animation. Si on reprend l'image carton, on peut considérer que tout ces cores sont les centaines de copains sympas qui s'occupent de décoder chacun une partie de l'image.

Afin d'optimiser l'utilisation des disque/CPU/mémoire/bus/GPU, il faut donc encoder sa vidéo avec un codec spécialement conçu afin d'utiliser ces concepts :

  • Réduire la taille de la vidéo sur le disque, en utilisant les principes de compression classique (redondance spatiale et temporelle, entropie, etc ..)
  • Cette réduction va permettre une diminution du débit sur le disque, les bus mémoire et le CPU
  • La décompression est assurée non plus par la CPU mais pas les cores du GPU, qui sont vraiment très performants dans le traitement parallèle des tâches.

HAP, le codec OpenSource dédié au Live

"Ah ben voilà !" me direz-vous, Grassard il fallait bien qu'il claque de l'OpenSource quelque part. Je vais donc vous parler du codec HAP qui répond à ces besoins.

Dans le domaine de l'installation temps réel et du Vidjing, VidVox est un acteur assez important, notamment via son logiciel VMDX. De la même manière que l'OpenEXR est venu d'une volonté de différents studios de fluidifier les échanges d'images, VidVox s'est dit que les codecs existants ne répondaient pas à la problématique du débit dans les conditions du live, où la machine d'authoring n'est la plupart du temps qu'un ordinateur portable aux capacités réduites. Leur métier n'étant pas de vendre des codecs, le choix de l'OpenSource permettant à n'importe quel prestataire d'encoder dans ce format tombait sous le sens. Un logiciel comme VDMX transpirant bien moins avec lui, le soft est donc plus réactif et plus vendeur. On ne peut que les saluer pour ce choix. Merci à eux !

La famille HAP se décompose donc en trois enfants utilisant le container Quicktime :

  • HAP : le codec de base qui s'occupera d'encoder les couches RGB
  • HAP Alpha : Qui prend en charge la couche Alpha en plus (je conseille de traiter les couches RGB en mode direct plutôt que pré-multipliées, afin de réduire la charge sur le GPU en évitant une division des couches RGB par l'Alpha).
  • HAP Q : identique à HAP, mais avec un plus fort débit sur les images Intra, offrant une meilleure qualité. Attention, la couche Alpha n'est pas supportée pour le HAP Q.

On peut trouver le codec HAP ici :

https://github.com/vidvox/hap-qt-codec/releases/

Une fois installé, il est possible d'encoder en HAP avec n'importe application supportant l'export Quicktime. Aucun paramètre n'est disponible à part le type de codec utilisé. Cependant, les différentes utilisations que j'en ai faites n'ont produites que très peu d'artéfacts, en tout cas pas plus qu'une video encodée en X.264 via un Quality Quantizer autour de 20. Pour l'utilisateur final, l'action se limite donc à encoder et c'est tout.

Utilisation du HAP dans Touch Designer

Afin de tester le codec en condition réel, j'ai intégré dix animations 1920x1080/25fps utilisant une couche Alpha dans un projet Touch Designer, histoire de tester si la lecture brute pouvait tenir la route. La HAP Alpha a passé le test haut la main, permettant ainsi de réduire la charge CPU en le limitant à l'analyse du graph et la redirection vers les sorties, soit environ 10% sur un Core i7 4770K.

Exemple d'insertion des dix animations dans un projet Touch Designer

La carte graphique a bien sur son importance dans cette opération. Ayant toujours une préférence pour les cartes NVIDIA, je ne peux pas vraiment me prononcer pour les cartes AMD. Il est à noter que l'utilisation de plusieurs cartes en parallèle est possible, augmentant d'autant plus les capacités de décodage.

N'hésitez donc pas à intégrer ce codec dans vos applications temps-réel, installations interactives, vidéo mapping ou Vijing, vous aurez ainsi la possibilité d'intégrer bien plus de flux vidéos précalculées. Cerise sur le gâteau, la vidéo étant décompressée par le GPU, le buffer image issu de sa décompression est déjà dans la VRAM, ce qui permet de l'utiliser pour du mapping sur des surfaces 3D, voir de modifier l'image via des shaders Cg, HLSL ou GLSL.