cpbx a écrit 21 commentaires

C'est amusant de tomber sur des gens qui bossent dans le milieu. :) Juste une précision: je n'utilise pas Belle Lumière. En tant qu'informaticien, je me contente de rendre la vie de ses utilisateurs insupportable.

Nous avons aussi obtenu le SDK de Belle Lumière, du moins si on parle bien du Belle Lumière d'avant le Résolveur de Vinci. Avant ça, nous bossions également avec Assembleur de Médias, mais l'intégration avait été réalisée par une société tierce. Ça fonctionnait assez bien, d'ailleurs.

Vous n'avez pas trop de problèmes avec le matériel qui vieilli? Les Constellation, EVO, $@#¤! de Xynergi, les interfaces SX-*..?

Chez nous, toujours, FFmpeg générait des fichiers MXF XDCAM HD422 qui n'étaient que moyennement appréciés par le diffuseur de régie finale et par l'outil de QA en amont… On aura plutôt tendance à employer FFmbc, même s'il est très probable que FFmpeg ait nettement progressé sur ce front. Mais, oui, c'est très probablement FFmpeg ou FFmbc qui wrappe les fichiers. C'est d'ailleurs FFmpeg qui était en partie derrière Codeur Carbone de Rosette. Il n'y a plus que très peu de boîtes qui développent des codecs (je ne vois vraiment que N00b et Concept Principal…)

Merci, j'ignorais cette subtilité! :) Par contre, je veux bel et bien que toutes les opérations se déroulent, même si une erreur survient quelque part. Dans mon secteur, il vaut mieux un AAF foireux arrivé à l'heure que pas d'AAF.

Et si vous cherchez un nouveau boîtier et bien regardez la concurrence

Par curiosité, quel concurrent aurait un format raw qui soit ouvert? Il y a bien Leica, qui utilise—je crois—le DNG, mais dont les prix sont généralement rédhibitoires. Tu en connais d'autres dans les gammes reflex, mirrorless, ou télémétrique 35 mm plein format?

Je me réponds à moi-même: c'est make metaSurface, et pas make metaSurface.bin.

Après avoir installé faust depuis le code source (en n'oubliant pas de compiler le backend sous forme de bibliothèque dynamique), et ajouté /usr/local/lib dans /etc/ld.so.conf.d/local.conf (suivi de sudo ldconfig), j'ai pu exécuter /usr/local/bin/metaSurface.sh.

Pour compiler Faust:

git clone https://github.com/grame-cncm/faust.git
cd faust
make all -j12 # pour s'assurer d'avoir la bibliothèque dynamique
sudo make install

Il faut là aussi installer des dépendances qui dépendront de ton système (j'ai dû installer llvm-devel sur Fedora 32, par exemple).

Je pense que le problème vient de la présence d'un fichier metaSurface.bin dans le repo git, qui est lié aux bibliothèques en question, et qui n'est pas recompilé par le Makefile:

ldd metaSurface.bin | grep -i 'not found'
ldd: attention : vous n'avez pas la permission d'exécution pour `./metaSurface.bin'
        libboost_system.so.1.62.0 => not found
        libboost_filesystem.so.1.62.0 => not found
        libfaust.so.2 => not found
        libsfml-graphics.so.2.4 => not found
        libsfml-window.so.2.4 => not found
        libsfml-system.so.2.4 => not found
        libOSCFaust.so.1 => not found

Il faut donc recompiler ce binaire:

# dans le répertoire source
$ rm metaSurface.bin
$ touch main.cpp # pour contourner le message make: « metaSurface » est à jour.
$ make metaSurface.bin

Et ensuite suivre les instructions de la dépêche. Je n'ai pas toutes les bibliothèques nécessaires (faust…), je ne peux donc pas aller jusqu'au bout de la compilation, et peut-être que tu rencontreras d'autres problèmes ensuite. ;)

Raisons de plus pour dire lui faire remarquer que des gens :
- lisent ses articles avec un regard critique,
- trouvent que son travail pourrait/devrait être mieux fait,
- ne sont pas d'accord avec ce type de journalisme à la chaîne, balancé sans réflexion.

On a tout à fait le droit de critiquer le travail des journalistes, qui sont souvent très ouverts à la chose, mais LinuxFr n'est probablement pas un endroit scruté quotidiennement par la plupart d'entre eux. Il me paraîtrait dès lors plus constructif de contacter la rédaction en expliquant en quoi mentionner le caractère libre des logiciels est dommageable à tes yeux. :-)

Tu donnes un cadre général, mais pas d'exemple pour le cas dont nous parlons ici.

J'ignore qui cette journaliste a contacté, et il est peu probable que ça se sache, à moins de lui poser la question (*), c'est donc difficile de fournir autre chose qu'une pure supposition, ce qui me paraît un exercice un peu inutile. Du coup, je ne suis pas certain de ce que attends précisément. Un exemple d'une conversation qui aurait pu mener à la conclusion qu'inclure le caractère libre des logiciels revêtait une importance?

(*) Je viens de contacter France Bleu par e-mail en fournissant l'adresse de cet article. Peut-être qu'ils prendront la parole ici, peut-être pas. :-)

Ce dont on ne dispose pas sur de tels supports, c'est justement de temps.

Nous sommes à peu près tous d'accord là dessus.
Est-il acceptable de continuer à nommer cela du journalisme ? De mon point de vue non, mais ce n'est pas moi qui décide de l'usage des mots.
Pour ma part j'ai opté pour « animateurs d'espaces publicitaires » qui me semble correspondre à leur travail principal.

Il s'agit bien entendu d'un point de vue défendable. :-)

Je crois que si le vegetarianisme n'a rien à voir avec l'idée d'être contre l'exploitation animale. Ça c'est le veganisme.

Les végétariens ne mangent pas de viande "terrienne" essentiellement par goût, par une sorte d'idéal de santé (essentiellement contre la viande rouge). Il y a plein de gens qui sont même à mi chemin vers le veganisme parce qu'ils refuseraient de manger certaines viandes soit parce qu'ils sont trop impliqués émotionnellement, soit pour des raisons futiles d'esthétique parce qu'ils seraient trop mignon ou dégoutant: cheval, lapin, chat, chien, bébé-phoque, cailles, cochon d'inde, pangolin ou des insectes.

Stricto sensu, un végétarien ne mange ni poissons, ni produits laitiers, ni œufs, ni rien d'autre qui soit d'origine animale. On distingue normalement les personnes qui en consomment des végétariens stricts en ajoutant respectivement les préfixes pesco-, lacto- et ovo-. Le miel fait débat même chez certains végans.

Le véganisme est lui aussi très varié, et la signification des termes change selon qu'on se trouve dans un pays anglophone ou francophone. Généralement, un(e) végan(e) en francophonie, c'est l'équivalent d'un(e) ethical vegan dans les pays anglophones. Les personnes qui suivent simplement un régime strictement végétal sont plus souvent appelés vegans dans les pays anglophones, et végétaliens dans les pays francophones… Mais pas toujours.

Peut-être qu'elle a demandé à quelqu'un et que ce quelqu'un lui a dit une connerie

Peux-tu donner un exemple ?

Je me permets de répondre à une question qui ne m'est pas adressée: ça arrive tout le temps. Les journalistes ne sont pas omniscients et se tournent donc vers des experts quand ils ne maîtrisent pas un sujet, ce qui est vraisemblablement souvent le cas pour les journalistes de société, dont le périmètre est très vaste. Reste à déterminer qui est un expert et à en comprendre les explications parfois absconses. Après quoi, il faut encore recouper ces dires avec l'avis d'autres experts, puisque juger de la pertinence des propos nécessiterait une expertise dont il est établi que les journalistes ne disposent pas. Ça prend du temps.

Pour ce qui est de la vérification des informations, et même si ça incombe effectivement aux journalistes, il faut prendre en compte la ligne éditoriale de l'entité pour laquelle ils travaillent, son comité de rédaction si elle en possède un, ainsi que le médium. La ligne éditoriale va généralement donner l'angle du traitement. Un comité pourrait désigner la mauvaise personne pour le mauvais sujet—et l'absence de comité va laisser la qualité d'une information à l'appréciation d'une unique personne. Le Web et les chaînes d'info 24/7 mettent une pression énorme sur les rédacteurs afin qu'ils soient les premiers à publier l'information. Ce dont on ne dispose pas sur de tels supports, c'est justement de temps.

Enfin, dans le cas présent, une fois qu'elle a eu terminé la publication de son article, il est probable que la journaliste se soit mise à la rédaction du suivant, sans le moindre point commun avec celui qui nous occupe ici. Les journalistes de la presse généraliste sont de plus en plus polyvalents et amenés à devoir travailler à la chaîne. C'est un mélange qui ne favorise pas le travail de fond.

Les logiciels sont rarement exempts de bugs, et il m'est arrivé pas plus tard que la semaine dernière d'intervertir des câbles dans une baie de brassage. C'est ce qui se passe quand on ne dort pas et qu'on doit toujours faire plus, plus vite: la qualité du travail baisse. C'est un problème de société, et le journalisme n'y fait pas exception, il est juste nettement plus exposé à la critique.

DCP n'est pas un algorithme de compression, ni même un format de conteneur. C'est plutôt une norme qui vise à organiser la structure des fichiers, à spécifier les algorithmes de compression tolérés, etc. On ne fournit pas un fichier DCP, on fournit "un DCP", qui, comme l'a dit Zenitram, est un disque dur contenant des fichiers organisés d'une manière bien définie. C'est destiné à être lu par un projecteur de cinéma numérique, et pas à être diffusé sur le Web ou même en télévision. C'est un peu comme un DVD.

On pourrait sans nul doute créer des fichiers de basse qualité, encodés en JPEG 2000, pour tenter d'arriver à une taille de fichier équivalente à celle d'une vidéo H.264 ("mp4"), mais, à ma connaissance, la qualité vidéo en souffrirait, l'audio resterait du PCM ("wav"), les conteneurs resteraient MXF, et la lecture du tout nécessiterait un lecteur comprenant la structure d'un DCP. Si ces vidéos devaient être diffusées sur le Web ou fournies à des tiers non professionnels, on devrait passer par un transcodage vers un format grand public, et on arriverait probablement vite à la norme MPEG-4.

S'il est en plus nécessaire d'archiver les vidéos, ça peut très vite réduire les choix. Indexer et archiver des DCP—1 disque dur physique ou une image disque par vidéo—c'est peu pratique et peut-être inexistant dans les solutions d'archivage vidéo actuelles. Qui plus est, la pérennité joue énormément dans ce domaine, où la préférence ira souvent à un algorithme breveté mais dont le décodage est formalisé, largement implémenté, et surtout standardisé par l'ISO, plutôt qu'à un algorithme non-breveté.

NB: je bosse pour la télévision, surtout dans le son, le cinéma n'est pas mon domaine, l'Europe et ses besoins encore moins. ;-)

Bizarre, on dirait que ce fichier n'a jamais été dans le repo (mais je suis une bille avec Git):

[cpbx@unit Ultracopier]$ git log --diff-filter=D | grep -i FacilityEngineVersion
[cpbx@unit Ultracopier]$

Si c'est juste pour tester l'outil comme c'est mon cas, il est possible de créer le fichier afin d'y ajouter la méthode FacilityEngine::version():

[cpbx@unit Ultracopier]$ cat > FacilityEngineVersion.cpp <<EOF
#include "FacilityEngine.h"

std::string FacilityEngine::version()
{
    return "2.3.0.5";
}
EOF

Hello cluster2600,

Comme mentionné dans l'article, je ne connais pas grand-chose à la partie graphisme, j'ai donc volontairement fait l'impasse sur cet aspect de la post-production, d'autant que son importance varie énormément d'une production à l'autre, en particulier lorsqu'il est question de films d'animation (si on parle de RenderMan, on est probablement dans ce cas de figure).

Qui plus est, et sauf erreur de ma part, Pixar RenderMan est bel et bien propriétaire (contrairement à l'interface RenderMan qui est ouverte, mais il ne s'agit que d'une spécification).

Si je ne me trompe, Maya ou 3DSMax ne couvrent pas tous les besoins non plus ?

La quantité d'outils supplémentaires présents au graphisme chez nous, et dans certaines de nos filiales, te donne entièrement raison. :-)

Une page pour compléter sur la partie diffusion : https://github.com/audionuma/awesome-broadcasting (et notamment CasparCG)

Merci, je ne connaissais pas, mais c'est intéressant. Concernant CasparCG, il est utilisé en production chez nous dans certains endroits, mais j'ignorais qu'il pouvait faire autre chose que de l'habillage d'antenne. C'est intéressant. On dirait qu'on approche du moment où on pourra faire de la production TV live libre, à condition de gérer les procotoles de vidéo et d'audio sur IP.

Par ailleurs, je serais curieux de voir comment l’écosystème libre va prendre en compte (ou non) l’adoption en cour du standard de transport audiovisuel sur IP : SMPTE 2110

Je suis curieux également, parce que ça semble être la direction que vont prendre les télévisions dans le futur proche, du moins celles qui en ont les moyens financiers.

Je me permet pour finir une petite digression sur la création sonore […]

Là encore, merci pour tous ces liens. :-) Je n'en connaissais pas la plupart. Pour la création sonore, je te rejoins: l'écosystème autour de Linux et Ardour est très abouti, et linuxmao est une véritable bible (ça n'est pas mon domaine, je ne peux donc pas approfondir, mais je suis preneur d'une dépêche sur le sujet ;-)).

C'est à dire qu'Autodesk et Sony pensent que leurs outils chers et propriétaires sont mieux. Tandis que les deux studios participant au débat ont présenté des films d'animation fabriqués avec Blender (un long métrage et une série pour France télévision).

Si tu ne fais référence qu'à l'outil de modélisation et d'animation 3D, nous sommes d'accord, mais ça ne couvre qu'une partie de la production, même pour un film d'animation. La production d'un film d'animation diffère par ailleurs un peu de celle d'un film live.

Merci! Je ne connaissais pas, mais j'en parlerai autour de moi à l'avenir. :-)

Effectivement, et ça paraît intéressant. Je ne connaissais pas, mais je vais me pencher là-dessus. Merci pour la découverte. :-)

Oups, merci d'avoir éclairé ma lanterne. C'est bien entendu d'accord. ;-)

Hello Thomas,

Merci pour ta réponse et pour ta suggestion.

Je n'ai malheureusement que très peu d'expérience dans le domaine du cinéma et/ou du documentaire, mes connaissances se limitant à la post-production TV et à 2 années de cours de niveau amateur, ainsi qu'à une certaine expérience en photographie, tout comme toi. Je rêvais d'être directeur photo ou étalonneur au cinéma, j'ai fini informaticien à la TV. Dit autrement, je vais devoir poser beaucoup de questions autour de moi pour ne pas raconter trop de bêtises. ;-)

Je tente l'expérience, mais je ne lis plus Linuxfr que sporadiquement (manque de temps), aussi ça pourrait prendre longtemps avant que je puisse en comprendre le fonctionnement éditorial et produire quelque chose de suffisamment qualitatif. Je propose de m'y mettre dès le début de la semaine prochaine. Si tu trouves le temps trop long, n'hésite pas à me harceler par message privé si c'est possible. J'avoue n'avoir eu que très peu de temps pour me renseigner sur les possiblités de Linuxfr ;-)

Hello freejeff,

Merci pour ta réponse et tes remarques très pertinentes. Je vais tenter d'apporter quelques précisions à mon message précédent. Gardons juste à l'esprit que je ne suis qu'un informaticien qui a suivi 2 ans de cours de "vidéaste". Autrement dit, je ne connais rien à l'audiovisuel au-delà de ce que je crois comprendre sur le terrain et de quelques travaux amateurs qui m'ont ouvert les yeux sur certaines réalités.

Avant toute chose, rappelons que la production audiovisuelle, c'est se mettre au service de la vision d'un réalisateur qui devra composer avec énormément de limites humaines, financières, techniques, temporelles, auxquelles ont essaiera d'éviter l'ajout de limites idéologiques. C'est normal que ça passe mal auprès des libristes, mais le but d'une œuvre n'est généralement pas d'en vanter les moyens de production, même si je comprends aisément qu'un docu sur le libre donne envie qu'il en soit le porte-étendard. Je ne prétends pas que le libre ne doive pas s'y retrouver, mais plutôt que ça n'est pas une préoccupation de la plupart des acteurs d'une telle entreprise, pour qui le fond et la forme priment généralement sur les moyens.

En ce qui concerne justement la production avec des moyens libres, je crois qu'il faut distinguer plusieurs approches, et mon commentaire précédent ne prenait en compte que l'une d'entre elles:

1. d'une part, le réalisateur-directeur photo-ingénieur du son-cadreur-monteur-étalonneur-mixeur, bien souvent auto-financé ou soutenu par un financement communautaire. Il y a fort à parier que pas mal de youtubers tombent dans cette catégorie;
2. d'autre part, le réalisateur-tout-court, qui travaille avec un producteur qui lui a trouvé des moyens financiers, techniques, et humains, et énormément de techniciens, délégués, chefs opérateurs, …;
3. enfin, bon nombre de réalisateurs qui se situent entre ces deux extrêmes.

Dans le premier cas, chacun fait ce qu'il lui plaît. La caméra ne sera sans doute pas libre, les formats vidéo d'acquisition et de distribution non plus, mais la chaîne de post-production pourra sans doute l'être à 100%. Par contre, elle sera—je crois—nettement moins complète, puisqu'il n'existe à ma connaissance aucun outil de compositing libre, ni d'ailleurs d'étalonnage dédié. Par ailleurs, les formats des caméras grand public, des smartphones, etc. ne contiennent généralement pas assez d'informations pour permettre un étalonnage approfondi (c'est généralement du 4:2:0), et les écrans grand public n'ont de toute façon pas le gamut d'un projecteur ou d'un moniteur de contrôle professionnel. Le son sera probablement également compressé. Tout transfert entre les différents postes sera vraisemblablement lossy (*). Je passe sur l'aspect tournage, où remplir tous les rôles aura une incidence très significative sur la qualité de la matière qui arrivera ensuite en post-production, et où les limitations du matériel se feront vite sentir. Ça marchera pour les plus petites productions, sans aucun doute (n'y vois aucun jugement, je ne parle que de la portée du projet et pas de sa qualité; je donne quelques détails plus loin).

Dans le second cas, que concernait ma réponse précédente, le réalisateur n'a ni le temps, ni les compétences pour maîtriser tous les outils, il travaille donc avec énormément de monde, chacun étant un professionnel qualifié dans un domaine déjà très vaste. Les prix sont élevés car le matériel est onéreux, les compétences se paient d'autant plus cher que ces personnes ont fréquemment travaillé bénévolement durant des années, et le marché est minuscule. On fait très régulièrement appel à des sociétés spécialisées, tels des studios d'enregistrement audio ou d'étalonnage vidéo, dont les tarifs horaires approchent parfois le salaire mensuel brut d'un ingénieur.

Le troisième cas est probablement celui qui concerne bon nombre de réalisateurs de documentaires. Souvent, ils vont remplir quelques rôles (par exemple réalisateur/monteur), et d'autres personnes porteront également plusieurs casquettes (cadreur/étalonneur, scripte/assistante, preneur de son/mixeur, …) Ça varie trop pour pouvoir établir des généralités, les seules constantes étant le manque de moyens et l'énorme bonne volonté des intervenants.

En production professionnelle, une chose importante est le support de diffusion. Pour un youtuber, c'est Youtube. Pour un réalisateur de documentaire appartenant à la 3e catégorie, c'est, potentiellement, les projecteurs de cinéma, la TV, le Web, le BluRay, … Chaque médium ayant ses spécificités (formats d'image, son, types de fichiers, balayage progressif ou entrelacé…) Par exemple, Youtube, c'est, à mon humble avis, du 16/9 4:2:0 progressif en stéréo 44.1 Hz dans la plupart des cas, voire du double mono, mais les autres supports sont plus variés (2.35:1 4:4:4, 16/9 4:2:2, 5.1, 7.1, …) Par ailleurs, un écran de cinéma va magnifier tous les détails, y compris les défauts qui deviennent très visibles alors qu'ils étaient invisibles sur un smartphone ou même sur un moniteur de PC. Même chose avec le son: on a quelque chose de "parfait" avec son casque chez soi, mais une fois diffusé avec quelque chose d'un peu plus puissant et/ou de plus neutre, les différences de niveau s'accentuent énormément, des sons parasites apparaissent, au point de rendre le travail impossible à faire passer en salles ou même en TV, et je ne parlerai pas de la spatialisation sonore, etc. Le youtuber ne se préoccupe pas forcément de tout ça, il peut donc travailler avec des moyens nettement plus légers, alors que le réalisateur qui produit pour une diffusion plus large devra passer par des étapes supplémentaires nettement plus techniques. A titre d'exemple, dans l'endroit où je travaille, un documentaire ne serait probablement pas diffusé s'il ne passait pas le test automatisé de contrôle qualité de BATON. Ça serait rejeté méchamment avec un simple rapport PDF expliquant quels sont les défauts du fichier, et ça peut aller très loin (pics audio, blancs trop haut, noirs trop bas, trop long, trop court, présence d'un silence trop long ou de trop d'images noires, …)

Il est très important également de noter qu'un documentaire peut être nettement plus complexe techniquement qu'il n'y paraît. Ainsi, il est fréquent d'employer plusieurs caméras dans des conditions lumineuses très variables, des micros divers dans des pièces à l'acoustique très hétérogène, et d'avoir à minimiser toutes ces différences en post-production afin d'éviter des sensations de "saut" d'un plan à l'autre (sauf quand c'est intentionnel). Ca dépendra là aussi des moyens à disposition.

Enfin, il faut noter que certains youtubers sont des professionnels qui utilisent des équipement professionnels ou semi-professionnels (e.g. la Blackmagic Pocket Cinema 4K), parfois même des studios sur fond vert, des équipes de production, etc. Bien souvent, il est dans leur intérêt de préserver l'illusion de l'auto-production pour masquer l'aspect lucratif de leur travail. Le plus souvent, leur chaîne de post-production n'est pas libre, même si je ne doute pas une seconde que de nombreux youtubers utilisent du 100% libre.

Si je résume ce (trop long) message, il est important de se rappeler qu'un produit audiovisuel n'est pas la somme de ses moyens de production, et que le but du jeu est de concrétiser la vision du réalisateur dans les limites des contraintes "obligatoires" (temps et argent), le travail des différents corps de métier étant aussi de jouer les tampons entre la technique et la réalisation. Le réalisateur n'est que très rarement celui qui décide des outils, et le producteur n'est pas toujours impliqué non plus dans des décisions de si "bas niveau". Le libre peut sans aucun doute se faire une place sur des productions légères et/ou autonomes, mais pour des productions plus lourdes, ça sera difficile car les outils sont verrouillés et fortement interdépendants. Il existe cependant de nombreux logiciels libres absolument pro dans ce domaine (je pense notamment à Jack, FFmpeg, Ardour, OpenDCP, OBS ainsi qu'à des SDK et bibliothèques comme le SDK AAF, PyAAF, OpenTimelineIO, mais il en existe vraisemblablement beaucoup d'autres).

* on perdra au moins la possibilité d'altérer le montage au cours du mixage ou de l'étalonnage, même si la vidéo et l'audio sont totalement lossless, sauf si les différents outils prennent en compte des formats comme AAF, certains formats XML, voire OMF, …

Sommaire

• La post-production est complexe
• L'interopérabilité et les formats
• Le matériel et les protocoles
• Les plugins
• Les normes

Bonjour,

Je me suis inscrit afin de pouvoir fournir quelques explications techniques, puisque je suis un informaticien travaillant pour la post-production (en TV, ceci dit, qui diffère du cinéma). Désolé de m'y prendre tard et pour la longueur de cette réponse.

La post-production est complexe

Quand on parle de post-production, il faut distinguer plusieurs postes techniques, dont l'acquisition, le montage, l'étalonnage vidéo, les effets spéciaux, le mixage audio, la conformation, … Chaque poste ayant souvent ses propres best practices et ses ténors logiciels, une partie du travail de l'informaticien est de faire en sorte que des logiciels ultra-propriétaires puissent échanger des données, en sachant que les allers-retours entre différents postes sont fréquents et qu'ils doivent être lossless. A titre d'exemple, on trouve généralement:

• montage: Premiere, Media Composer, peut-être Final Cut Pro;
• étalonnage: Da Vinci Resolve, Mistika Ultima, Nucoda, et de nombreux plugins pour outils de montage, comme Colorista;
• graphisme et VFX: After Effects, Nuke, Photoshop, Maya, V-Ray, … C'est le domaine que je connais le moins, et il est très vaste, puisqu'on y trouve des logiciels de graphisme, de compositing, des renderers et raytracers, etc.;
• mixage audio: Pro Tools est le "standard" de fait de l'industrie du son, mais on trouve probablement d'autres outils pour le mixage à l'image (Fairlight—désormais intégré à Resolve—me vient à l'esprit, ainsi que Pyramix et peut-être Sequoia).

Le libre doit donc réussir à se faire une place au milieu de ces logiciels extrêmement bien implantés, tout en résolvant les problèmes ci-dessous.

L'interopérabilité et les formats

Les éditeurs de logiciels propriétaires fournissent généralement un support plus ou moins complet de la spécification AAF, mais l'interopérabilité se passe rarement sans douleur. Dans les faits, on tend donc à se tourner vers des outils dont les formats d'échange comme AAF sont compatibles, et qui puissent être articulés autour des incontournables que sont, par exemple, Photoshop et Pro Tools, ce qui limite rapidement les choix.

En termes de formats, on trouve une gamme assez étendue de formats vidéo dits professionnels: AVC-Intra, XDCAM HD, … encapsulés dans un ou plusieurs conteneurs MXF, voire du raw encore plus propriétaire, dans des résolutions rarement inférieures au 1080p24 et régulièrement très supérieures. Ils viennent parfois avec des intermédiaires de moindre qualité (ProRes, DNxHD, …), et le son est souvent enregistré sur un autre support en BWF. La post-production—généralement le montage—doit donc pouvoir gérer ces formats et résolutions, ainsi que les timecodes des différents fichiers afin de réconcilier vidéo et audio, le tout de manière aussi automatisée que possible. Dans un souci de facilité et de rapidité, on trouve typiquement une fonction "Auto Sequence" dans les outils de montage, qui permet de créer une séquence reprenant tous les rushes sélectionnés, dans l'ordre chronologique, et pouvant gérer les vides laissés par du Time of Day Timecode et les superpositions de différents clips (c'est fréquent en multicam, par exemple).

Par ailleurs, en TV, il arrive qu'il faille débuter un travail de montage vidéo et de mixage audio alors qu'un direct n'est pas encore terminé. Il faut donc soit travailler avec des fichiers dits "ouverts", soit avec des flux vidéo/audio et du matériel d'acquisition, soit avec des protocoles de vidéo ou audio sur IP. Dans tous les cas, les logiciels doivent prendre en compte quelque chose de relativement peu commun.

Le matériel et les protocoles

Pour travailler rapidement de façon précise, il est commun dans certaines sociétés d'employer des surfaces de contrôle pour certains outils. Ainsi, on trouve régulièrement des surfaces S3 ou S6 pour les stations de travail Pro Tools, des contrôleurs Blackmagic pour l'étalonnage et l'audio dans Resolve, etc. Ces contrôleurs ne fonctionnent bien souvent qu'avec le logiciel pour lequel il a été conçu, les surfaces Avid étant une exception bien que restant à 100% propriétaire. Ce matériel coûtant une petite fortune, et les utilisateurs étant souvent très aguerris à leur utilisation, on réfléchit longtemps avant d'en changer.

Certains DAW n'intègrent pas la lecture vidéo nécessaire au mixage à l'image, ce qui requiert de disposer d'un PC pour l'audio et d'un autre pour jouer la vidéo, les deux étant synchronisés à l'aide d'une référence commune, le lecteur vidéo devant également comprendre les commandes GPIO envoyées par le DAW pour les fonctions de transport (play, stop, fast forward, …) On trouve donc un besoin pour des cartes spécifiques ainsi que pour des protocoles de synchronisation et d'entrée/sortie peu communs dans le monde de l'informatique dont est issu le libre. Ardour semble gérer ce cas de figure.

Autre point très important en post-production: le contrôle. Les logiciels de montage et d'étalonnage doivent pouvoir envoyer l'image directement vers une carte vidéo (AJA, Blackmagic, Bluefish444, …) afin de contrôler la fidélité des couleurs, du contraste, la fluidité de l'image, … sur un moniteur ou projecteur calibré. Dans l'audio, des interfaces AES10 sont régulièrement présentes, avec lesquelles le DAW doit communiquer, en partie afin de pouvoir in fine contrôler la qualité du son. Les pilotes et SDK pour ces cartes ne sont pas toujours disponibles pour les systèmes libres, et ne sont par conséquent pas utilisables dans les outils libres.

Dans le broadcast, il est également important de pouvoir distribuer un signal vidéo et/ou audio dans un bâtiment, ce qui implique des équipements vidéo et/ou audio prenant en charge certains protocoles de distribution et de contrôle (SDI, HDBaseT, SDVoE, Dante, Ravenna, AES70, …), que les logiciels de post-production doivent pouvoir prendre en charge, que ça soit directement ou via des plugins (protocoles réseaux, …) ou à l'aide d'équipements auxquels ils doivent s'interfacer (cartes SDI, …)

Les plugins

D'autres pierres d’achoppement sont les plugins, dont certains sont parfois aussi importants que le logiciel hôte, et qui ne sont fournis que pour les logiciels propriétaires connus (les plugins audio VST font figure d'exception, mais sont eux-mêmes propriétaires la plupart du temps). Certains éditeurs vendent des cartes DSP et/ou FPGA afin d'accélérer certains traitements/plugins, et ces cartes ne sont bien entendu pas utilisables par d'autres logiciels que les leurs. Quand il s'agit de traiter 200 pistes audio en temps réel, bourrées d'effets, tout en fournissant un retour audio et image sans latence à des personnes enregistrant leurs voix, ça devient précieux.

Les normes

Il existe de nombreuses normes en TV: normalisation audio, niveaux blanc et noir, … qui nécessitent des équipement de mesure qui sont de plus en plus souvent des… plugins ou des fonctions intégrées, ce qui est bien meilleur marché que les appareils de mesure matériels qui restent cependant nécessaires à certains postes. Je connais trop peu le domaine du cinéma pour pouvoir en parler, mais ça existe probablement. Ça n'est pas mon domaine, aussi je ne développerai pas.

J'aime me penser libriste, mais, à ce stade, intégrer du libre dans un workflow professionnel de post-production est très délicat. On en trouve de façon anecdotique, comme dans des grappes de transcodage vidéo où FFmpeg et FFmbc sont intégrés dans un outil propriétaire, et compilés avec la prise en charge d'algorithmes de compression propriétaires (et très concurrencés par Nablet et MainConcept). Si on tient compte du temps de formation, de l'envie compréhensible des utilisateurs d'employer des outils auxquels ils ont parfois consacré des années d'apprentissage, des contraintes budgétaires et des deadlines, de l'interdépendance très forte entre les postes, de l'inertie, du support et des SLA parfois nécessaires, du marché verrouillé, et qu'on les ajoute aux défis techniques déjà fréquemment rédhibitoires, force est de constater que le libre n'a aucune chance pour le moment, peu importe la qualité des outils proposés.