dimanche 9 août 2009

A la recherche du codec perdu !

Pour changer un peu, voici aujourd'hui un post orienté "Flux de production". Etant passé depuis peu graphiste indépendant, j'utilise pour la première fois de ma vie dans mes propres productions des méthodes de travail que j'étais chargé de gamberger avant pour les autres.

Me voilà donc enfin libre de définir, sans la moindre restriction "politique", le workflow qui me parait le plus adéquat, visant toujours à utiliser le plus possible des logiciels libres, fonctionnant également sous des OS libres (GNU/Linux en tête). Et comme je ne suis pas radin pour un sous (sauf si éventuellement on est plusieurs sur le coup pour finir une bouteille de Coca), je vous fais part ici du fruit de mes recherches.

J'utilise de plus en plus le module "Video Sequence Editor" de Blender comme principal logiciel de montage. Là encore, cela demande au début un petit effort d'adaptation vu le coté inhabituel et déroutant de ce module, mon cerveau ayant comme bon nombre d'entre nous j'imagine, été habitué à la façon américano-canadienne de faire de la prod depuis plus de 15 ans. Sachons par conséquent nous ouvrir à des méthodes plus "inédites" sans pour autant renier les autres qui ont fait leurs preuves depuis des années. Qui sait, nous y gagnerons peut-être en efficacité. ;o)

En ce qui me concerne, un des points les plus importants lorsque l'on décide de travailler avec plusieurs logiciels dans une même chaîne de prod est le choix du format utilisé afin de faciliter l'échange des données.

Cela inclut d'abord le type d'encapsulage (ou "container"), tel que l'AVI, le Quicktime, le MKV, l'OGG, le MXF et j'en passe.

Vient ensuite le choix des codecs, aussi bien pour la vidéo que pour l'audio. Là encore, les listes interminables de codecs disponibles est un véritable problème. Même pour une personne s'intéressant au sujet depuis de nombreuses années, comme j'essaye de le faire humblement à mon niveau, l'envie de se jeter la tête sur une dalle de béton se fait rapidement ressentir.

Afin de mieux aiguiller mes recherches et mes nombreux tests, je me suis imposé une sorte de cahier des charges dont voici les points les plus importants :

  • Le container qui englobe les codecs se doit d'être constant quel que soit le logiciel qui lit le fichier. Un pixel dont les valeurs RVB sont initialement de 20/180/70 ne devra en aucun cas être altéré par une quelconque manipulation maligne du player ou du décodeur, transformant ces valeurs en un approximation du style 18/170/75. Je vais revenir sur ce point en détails par la suite.


  • Le codec vidéo utilisé doit-être de type "compressé non-destructif" et qu'il est le meilleur rapport entre son poids sur le disque-dur et le temps d'encodage/décodage par les divers softs qui l'utiliseront. Ce point est particulièrement important lors de la lecture des médias par le réseau. Une bonne balance "temps de transfert" contre "temps de traitement" est primordiale dans le choix d'un codec.


  • Le format doit supporter une couche Alpha, que celle-ci soit enregistrée en mode directe ou premultipliée.


  • Le codec audio multiplexé dans le container ne doit pas produire de décalage son/image, comme c'est souvent le cas par exemple lors de multiplexages avec des buffers trop longs sur les fichiers MKV encodés en X264 / AAC.


  • Les codecs utilisés se doivent si possible d'être "Open Source". Ce n'est pas une contrainte technique, mais plutôt une volonté personnelle. Quoique, en ayant accès au code on est toujours à même d'adapter le format à ses besoins. Donc en fait ... c'est idéologique ET technique. ;o)


  • L'ensemble se doit impérativement d'exister et d'être compatible sur toutes les plates-formes les plus souvent utilisées en prod, à savoir Windows, MacOS et GNU/Linux.


La question est ... cette merveille peut-elle exister ? Hmmmm ???? !!!!


Bon ben vous imaginez bien que si je vous tartine tout ça depuis 20 minutes, ce n'est pas pour vous dire que vous pouvez rentrer chez vous les mains dans les poches ! Donc pour le suspens, ça tombe à l'eau.

Reprenons donc point par point afin d'apporter des réponses progressives (à ben si alors ... y a du suspens quand même) :


  • En ce qui concerne le container, je me suis tourné vers le bon vieux AVI après avoir rejeté l'idée d'utiliser le Quicktime. La raison vient des problèmes liés à la gestion des Gammas dont le traitement par Quicktime est souvent incompréhensible et changeant selon les versions. Je ne compte plus les questions du style "pourquoi mon quicktime n'a pas les mêmes couleurs entre mon PC et mon Mac" ou encore "pourquoi quicktime player m'affiche mon quicktime plus lumineux que lorsque je le charge dans After Effects ?". Et je ne suis pas le seul à le dire, même Trish et Chris Mayer qui ne sont quand même pas des tâches dans le genre on fait un post assassin sur leur blog sur ce point, avec pour conclusion : "Utilisez des séquences d'images, c'est plus sur". Selon moi, ce problème vient du fait que Quicktime cherche à linéariser les médias encodés afin de leur donner un Gamma de 1. Parellement, le format embarque une LUT qui une fois décodé par Quicktime redonnera aux médias leur gamma de 2.2 (si celui-ci est dans un espace sRGB, bien sûr). Cela part d'une très bonne intention quand on sait les avantages que peut avoir la linéarisation sur la précision des calculs (notamment au moment du compositing). Mais l'application de ces LUT fait tout bonnement n'importe quoi en fonction du logiciel qui les utilise et le résultat change à chaque version de quicktime ! Voilà pourquoi je me suis orienté vers le container AVI qui est vraiment le plus basique du monde, ce qui dans le cas présenté ici est un véritable avantage car sans surprise.


  • Parlons à présent du coté "non destructif" du codec tout en tenant compte du niveau de compression. Beaucoup de gens considèrent que compression signifie obligatoirement une perte de données. Pourtant, un écrivain qui viendrait à compresser un fichier Word au format Zip n'aura perdu aucun paragraphe lors de sa décompression. Cela prouve bien qu'il est possible de compresser des données sans aucune perte. Il en va de même pour le son (grâce au format FLAC, par exemple), l'image (format PNG, TIFF, PSD ou EXR parmi beaucoup d'autre) ou encore l'animation via de nombreux codecs dont celui qui va être décrit ici.

    Utiliser un codec non destructif permet le passage du fichier dans un grand de nombreux logiciels sans se soucier d'éventuelles dégradations lors des réencodages successifs. Le container AVI ne propose pas en natif (comprenez, fourni avec Windows) de codecs véritablement performants. J'entends par ce mot un bon compromis entre vitesse de transfert/lecture et le poids que prend le fichier sur le disque dur. Le codec RAW (non compressé) représente la seule artillerie efficace pour ce qui du non destructif mais celle-ci est un peu lourde quand il s'agit d'économiser de la place au niveau stockage.

    Après de nombreuses recherches, je suis tombé sur un codec véritablement merveilleux qui pourtant ne date pas d'hier. Son nom (attention, soignez la prononciation), le "HuffYUV" !

    Celui-ci est non destructif dans tous les cas sauf un. En effet, malgré son nom le HuffYUV peut enregistrer les données en YUV mais aussi en RGB. Dans le premier cas, les conversions successives YUV >> RGB ou RGB >> YUV peuvent engendrer une dégradation de la chrominance. Dans le deuxième cas, le fait de rester dans le même espace colorimétrique aussi bien pour l'encodage que pour le décodage, permet de garantir la conservation des couleurs. Pour toute personne qui souhaiterait tout de même travailler en mode YUV (en toute connaissance de cause), sachez que celui-ci permet de traiter les enregistrements en 4:2:2, 4:2:0 ou 4:1:1 et donc économiser de la place sur le disque dur sans enregistrer des informations inutiles (notamment pour les sources DV, HDV, DVCPRO, DVCPRO HD ou HDCAM non SR).

    Par rapport à des codecs plus récents, comme le Lagarith par exemple (dont le HuffYUV est la base) le HuffYUV prend un peu plus de place sur le disque dur (mais bien moins que le format RAW, non compressé). Là où il tire son épingle du jeu, c'est qu'il demande très peu de temps de traitement, aussi bien à la compression qu'à la décompression. Un petit exemple pour étayer mes dires. Sous Blender, il permet de lire 4 pistes simultanément sans le moindre ralentissement, le tout en synchronisation parfaite avec l'audio. L'encodage d'un montage de 30 secondes prend aux alentours de 6 secondes, soit environ 5 fois le temps réel ! Une aubaine lorsque l'on doit passer un montage de Blender à After FX par exemple ! Tout cela sur un processeur quad core Q6600, mais quand on sait que tout le processus n'est pas mutli-core, on peut calculer qu'un seul processeur de 2,4 Ghz permet ce type de traitement. Les lectures en direct à distance suivent également la cadence sur un réseau Gigabyte (voir 100 Mb/s si on réduit le nombre de flux simultanés).

    Rappelons que Blender dispose d'un système de proxy intégrés, permettant de travailler sur une version base résolution avant de conformer le tout en full def (très pratique pour les montages en HD). Là encore, l'utilisation du HuffYUV pour les Proxies est un véritable atout.

    Le HuffYUV permet donc d'allier rapidité de traitement et espace réduit sur le disque. D'autres codecs permettent de limiter l'espace occupé par le fichier, mais ceux-ci sont souvent destructifs. Le Lagarith, beaucoup plus récent, compresse bien mieux le fichier mais les temps de traitement ne permettent pas (sur ma machine en tout cas) de lire ne serait-ce que deux flux en même temps pour faire un simple fondu. Pour ceux qui voudraient compresser à nouveau le fichier final (pour l'envoyer par exemple sur un serveur FTP), je vous conseille d'utiliser la compression 7z. Ce format très performant, opensource et mutliplaforme vous permettra de diviser encore la taille du fichier par 3 ou 4 selon les cas !


  • Le codec HuffYUV permet de stocker une couche Alpha, que les données RVB soient enregistrées en mode direct ou prémultiplié (à la différence du codec PNG pour une raison que je ne m'explique pas ... si quelqu'un à la réponse). Sous Blender ou tout autre logiciel de montage, un habillage avec couche alpha peut donc être stocké et ajouté au-dessus de la pile (logos, bandeaux, mentions quelconques, sous-titres, etc ...). Le tout en temps réel ( en tout cas sur ma machine pour de la vidéo SD).


  • En ce qui concerne le son, je préfère rester dans le domaine du nom compressé (de type PCM), en l'absence malheureuse du codec FLAC dans les distributions officielles de Blender. Ce codec très performant permet de diminuer de plus de la moitié le poids d'un fichier habituellement enregistré en WAV ou AIFF, sans aucune perte ! Si vous avez l'occasion de l'utiliser, n'hésitez pas. Tout autre codec audio présent dans Blender est de type destructif (MP2, MP3, AC3, AAC) et peut produire des décalages image/son sur certaines plateformes. Mieux vaut donc rester prudent, le son prenant tout de même moins de place que l'image et permettant de se cantonner au PCM. Petite information, une fois le mode PCM choisi dans Blender (via le type de sortie FFMPEG), la valeur de Bitrate ne sert absolument à rien, le PCM n'étant pas compressé. La fréquence de celui-ci se conformera à ce que vous avez choisi dans les paramètres "Sequencer" de Blender, à savoir 44,1 kHz ou 48 kHz.


  • Le HuffYUV est Open Source. Le code est donc ouvert et modifiable à volonté si vous en ressentez le besoin. Tel qu'énoncé précédemment, le codec Lagarith découlant du HuffYUV est plus optimisé en terme de stockage mais beaucoup plus gourmand en temps de traitement.


  • Le HuffYUV est multiplateforme, ce qui n'est pas le cas du Lagarith (par manque de temps selon son auteur, celui-ci n'existe que pour Windows). Le HuffYUV est directement implémenté dans Blender via FFMPEG qui est directement accessible. Il est également possible de l'installer sous Windows pour qu'il soit accessible à tous les logiciels capables de lire ou d'encoder en AVI (voir un peu plus loin pour les systèmes 64 bits). Sous Linux, une simple installation de FFMPEG via un apt-get ou via un gestionnaire de paquets tel que "Synaptic" permet de l'utiliser sur tout le système. Sous MacOS, l'ajout du couteau suisse pour Quicktime "Perian" permet d'ajouter la lecture du container AVI et du codec HuffYUV de manière complètement gratuite, ce qui permet de ne pas sortir du container QT et ainsi être compatible avec "Final Cut".


En bref, le HuffYUV dans un container AVI avec un multiplexage du son en PCM permet d'être lu partout, sur n'importe quelle plateforme et en temps réel sous réserve d'installer les bons outils sur toutes les machines entrant dans la chaîne de prod !


Voilà, j'espère que cette petite description de ce que sont depuis quelques mois mes codecs et formats de travail pourront vous être utiles !

Afin de pouvoir également utiliser ces éléments dans votre flux de production, voici quelques liens utiles.


  • Le codec HuffYUV pour Windows :

http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html


  • Pour l'installation du codec sur les systèmes Windows 64 bits :

http://www.dvinfo.net/conf/what-happens-vegas/126319-installing-huffyuv-vista-64-bit.html


  • Pour l'installation de Perian sous MacOS :

http://perian.org/


  • Le compresseur/décompresseur 7z pour Windows / Linux / MacOS :

http://www.7-zip.org/download.html


  • Blender !!! Il est toujours bon de rapeller où le trouver :

http://www.blender.org/


  • Filezilla, mon logiciel de transfert FTP favori (pour MacOS, Linux et Windows) :

http://www.filezilla.fr/


N'hésitez pas à régir à ce post, qui reste ouvert à toutes suggestions.

Bonne prod à vous chers amis !!!! Non destructive, compressée et Open Source !


Edit : La lecture de ce post à donner lieu à une discussion très enrichissante sur le forum "Blender Clan". Vous pourrez la retrouver ici


EDIT :==> N'hésitez pas à consulter les commentaires de ce post, les précisions et discutions qui en découlent sont très instructives (enfin, j'espère).

5 commentaires:

PBRN a dit…

Bonjour,
Article très intéressant et j'adhère pleinement à son contenu !
C'est vrai que souvent les Codecs sont un réel problème d'un machine, d'un OS, d'un logiciel à l'autre..
Tant que chacun voudra faire son codec "propriétaire", on sera confronté à ce genre de situation !
J'apprécie cet article très détaillé qui permettra à certains d'y voir plus clair...
@++

CoyHot a dit…

Content que cela vous plaise et que cet article puisse vous être utile ;o)

Narann a dit…

Heay! Enfin un article qui parle de "prod"!
La méthodologie manque un peu en France! ^^

A mon tour de donner mon avis! :D
Le PNG surement le meilleur format pour l'infographie. Avant il y avait le TGA (compression RLE, un peu "has been"), et le Tiff mais ce dernier se révèle assez spécial tant il est possible d'y compresser des images différemment. Il n'est donc pas "pratique" car il faut se mettre d'accord sur tout les paramètres de compressions des différents softs à tout les niveau de la chaine pour pouvoir avoir quelque chose de cohérent (Et ça, c'est si on ne considère pas le facteur erreur/homme...). Le PNG a, pour moi, tout pour lui. La compression est très efficace et c'est du RGB, RGBA ou rien (comparé au Tiff ou l'on peut écrire tout et n'importe quoi).

Concernant le HuffYUV... C'est quand même quelque chose qui montre que des codecs orienté "GC prod" sont inexistants. Au point qu'on se rabat souvent sur des vieux codec...

A titre personnel, je rêve d'un codec vidéo multiplateforme, 32 et 64bits qui compresse en PNG (aucune perte)... Quicktime le fait... Mais c'est Quicktime. Lisible uniquement dans Quicktime... Maya ne peut pas sortir de Blast en .mov par exemple...

Un autre gros problème auquel j'ai été confronté durant la production actuelle fut les codecs sur les OS x64... Alors que sous Linux ce genre de problème semblent ne plus exister depuis longtemps (les applis Linux ait toujours leur équivalent en x64, l'open source ayant "obligé" les builds en x64), mais sous Windows x64, c'est la croix et la bannière. Si vous utilisez un Maya 32 vous n'aurez aucun soucis... Mais si vous lancez un Maya x64, c'est simple: Il n'y en a que trois... MS RLE, MS Vidéo1, Codec Intel IYUV.

Ce genre de problématique est quand même bien lié à Windows et je trouve dingue qu'aucune solution n'émergent (Si j'avais le temps et les compétence, je ferait mon codec magique compression PNG loseless...

Je me pose une question d'ailleurs... Si je récupère les sources de HuffYUV... Tu pense que je pourrais faire une build en 64? J'aimerai bien tenter en fait. Je sais que tu bosse sous Blender. Tu utilise la version x64 ou non? Et si c'est le cas, tu à réglé le problème des codecs? ^^

Sinon les prods sous Linux, implique quoi? (Ça serait intéressant un billet comme ça tiens ^^ )

CoyHot a dit…

Un grand merci pour ce commentaire véritablement constructif ! Je suis très content que ce "dossier" éveille des discutions sur les codecs, trop peu nombreuses en France, comme tu l'as justement soulevé.

Comme toi, je suis un grand fan du PNG et c'est justement ce que j'utilise pour le rendu en séquence d'images (avec l'EXR), notamment pour le rendu multi-machine sous AfterFX permettant de lancer 20 machines (ou plus) en réseau sur le même rendu ! On peut juste lui reprocher une légère latence lors de la compression par rapport au Tiff. Sinon, j'adore !

Alors ... deux choses. Il est tout à fait possible d'installer un codec 32 Bits sous une version 64 bits de Windows (ce qui est le cas chez moi, étant sous Vista 64). Voici la marche à suivre, en partant du principe que tes fichiers se trouve par exemple dans C:\codec

Dans ce dossier se trouve le fichier *.inf qui contient les infos pour l'install. Par exemple monCodec.inf

Voilà ce qu'il faut faire :

- Touche Windows+R afin d'appeler la fenêtre "Executer".

- Taper "cmd" (sans les guillemets) puis valider via les touches Ctrl+Shift+Enter (pour lancer la commande en Mode Admin ... ce n'est pas toujours obligatoire, mais on ne sait jamais).

- Taper ensuite "cd C:\Windows\SysWOW64"

- Puis taper "rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 0 c:\codec\monCodec.inf"

Et voilà, le codec est dispo dans la liste de tous tes softs linké via vfw (Video For Windows). Je bosse également sous Maya et Max et ça roule ! ;o)

Le HuffYUV peut-être installé sur un machine 64 bits de cette manière (ce qui est mon cas).


Ensuite, en ce qui concerne le codec PNG dans de l'AVI et bien il existe déjà mon ami !!! C'est le CorePNG !

http://www.jory.info/serendipity/archives/28-CorePNG-v0.8.2.html

http://en.wikipedia.org/wiki/CorePNG

Il est donc installable également sur du 64 bits via la méthode que je viens de te donner.

Il y a justement un comparatif avec le HuffYUV sur la page principale.

Sur la page du codec MSU (efficace mais propriétaire et non portable ailleurs que sur Windows), on peut voir un Graph qui place le CorePNG au dessus du panier (bien évidemment en dessus du MSU, non mais ... :o) :

http://compression.ru/video/ls-codec/index_en.html

J'espère que tu trouveras ton bonheur avec ça ! ;o)

Je te conseil de jeter un œil sur cette page :

http://en.wikipedia.org/wiki/Comparison_of_audio_codecs

C'est pas super exhaustif à 100% mais ça peut donner des bons repères pour savoir qui est Lossless et surtout qui est CrossPlatform ! Ce qui n'est malheureusement pas le cas du CorePNG.

Comme je le disais dans mon "dossier", il existe des codecs plus efficaces que le HuffYUV (le CorePNG fait partie de ceux-là).
Mais pour répondre à la quadruple problématique Lossless / Poids réduit / Rapidité accrue / Crossplateform, je ne vois que celui-là ... ;o)

Narann a dit…

Merci pour le CorePNG, je vais regarder ça de plus près...

Concernant les codecs, la méthode donné met le codec dans syswow64 (qui est en fait le dossier des fichiers système 32bits).

Et system32 est le dossier des fichiers système 64bits...

Mais quand j'ouvre maya 2009 x64 (ou virtualdub x64) et que j'ouvre le panel vfw, je n'ai que la liste des codecs 64bits. Donc, que ceux compilé avec windows x64... Donc, quasiment aucun. Sous maya 32 je n'ai aucuns soucis!

Va falloir tenter de compiler HuffYUV en 64 à la mains...