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 :
- 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 :
- Filezilla, mon logiciel de transfert FTP favori (pour MacOS, Linux et Windows) :
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).
