Lorsque je me suis lancé dans l’idée d’effectuer le montage de cette captation en une journée, cela me paraissait être une durée tout à fait normale pour la réalisation de ce type de projet. Et puis je me suis revu il y a 3-4 ans où il m’aurait probablement fallu une semaine pour arriver à peu près au même résultat mais avec beaucoup moins de souplesse de travail. Tout le matériel utilisé lors de captation (sauf la GoPro) était déjà disponible sur le marché en 2010 et même si les composants informatiques ont évolué en 4 ans ce sont plutôt les optimisations et les nouveaux développements des logiciels qui ont permis ce gain de temps pour le montage.
Le matériel de montage utilisé :
Macbook Pro 15 pouces early 2011 :
• Intel Core i7 2,3 GHz
• 8 Go de RAM DDR3
• 1 To de stockage monté en Fusion Drive (256 Go de SSD + 750 Go en HDD)
• GPU ATI Radeon HD 6750M avec 1 Go de mémoire
• Ecran 15 pouces Anti-Reflet avec affichage en 1680 x 1050 (ce qui ne change rien à la vitesse de la configuration mais qui apporte un confort de travail non négligeable)
• Et un second moniteur 20 pouces en 1680 x 1050 qui date de 2007 pour le multi-écran.
• Final Cut Pro X 10.1.1
• PluralEyes 3.3.4
• Intel Core i7 2,3 GHz
• 8 Go de RAM DDR3
• 1 To de stockage monté en Fusion Drive (256 Go de SSD + 750 Go en HDD)
• GPU ATI Radeon HD 6750M avec 1 Go de mémoire
• Ecran 15 pouces Anti-Reflet avec affichage en 1680 x 1050 (ce qui ne change rien à la vitesse de la configuration mais qui apporte un confort de travail non négligeable)
• Et un second moniteur 20 pouces en 1680 x 1050 qui date de 2007 pour le multi-écran.
• Final Cut Pro X 10.1.1
• PluralEyes 3.3.4
La captation de la soirée :
J’avais réalisé la captation du concert des Whitebox, il y a quelques mois, avec des étudiants de Studio M lors d’un tremplin musical organisé par l’école. La soirée était organisée autour de 6 concerts de 20 minutes qu’il fallait capter intégralement.
Le dispositif technique mis en place s’organisait autour :
Le dispositif technique mis en place s’organisait autour :
- 4 caméras JVC HM100 + 1 JVC HM150 réparties de la façon suivante :
o une caméra côté court de la scène,
o une caméra côté jardin de la scène,
o une caméra au balcon qui dominait la scène,
o une caméra au niveau de la console avec un cadre fixe et large de l’ensemble de la scène pour être assuré d’avoir un plan exploitable à chaque moment du concert,
o une seconde caméra au niveau de la console pour faire des plans de face plus resserrés,
o une caméra côté jardin de la scène,
o une caméra au balcon qui dominait la scène,
o une caméra au niveau de la console avec un cadre fixe et large de l’ensemble de la scène pour être assuré d’avoir un plan exploitable à chaque moment du concert,
o une seconde caméra au niveau de la console pour faire des plans de face plus resserrés,
- une GoPro Hero 3 Black Edition fixée sur un pied de micro et orientée sur la batterie, pilotée par Wifi mais dont il fallait changer la batterie entre chaque passage de groupe.
- un Canon 5D Mark II couplé avec un Zoom H4n pour les interviews en backstage.
Donc que du matériel réglé en 1920 x 1080 mais avec des codecs différents… et surtout les codecs préférés des monteurs avec des bons gros GOP que les logiciels de montage n’aiment pas trop ingurgiter ! Chaque cadreur avait pour impératif de ne pas couper l’enregistrement pendant les prestations de chaque groupe pour n’avoir à faire qu’une synchro pour l’ensemble des caméras.
Pour couronner le tout, parce que sinon c’est pas drôle, l’ensemble des caméras JVC créait un nouveau fichier toutes les 12 minutes environ car la carte mémoire n’encaisse pas des fichiers de plus de 4 Go… pas trop gênant sur le papier mais ça le devient en réalité : il y a quelques images de latence entre les deux fichiers qui obligent à reprendre la synchro caméra par caméra.
Pour couronner le tout, parce que sinon c’est pas drôle, l’ensemble des caméras JVC créait un nouveau fichier toutes les 12 minutes environ car la carte mémoire n’encaisse pas des fichiers de plus de 4 Go… pas trop gênant sur le papier mais ça le devient en réalité : il y a quelques images de latence entre les deux fichiers qui obligent à reprendre la synchro caméra par caméra.
Les étapes du montage :
Importation des rushs de la soirée dans une bibliothèque dédiée.
Labellisation des rushs nécessaires au montage du groupe des Whitebox.
Copie des rushs utiles.
Classement des rushs dans des collections de mots-clés.
Synchronisation du multicam dans Plural-Eyes puis export XML vers FCPX.
Conversion du multicam en Proxy.
Montage du multicam avec 3 passages pour l’ensemble du concert.
Ajout des éléments graphiques.
Bascule de l’affichage en pleine qualité.
Vérification du montage en ProRes 422.
Export puis compression H264 puis Upload sur Viméo.
Je charge ensuite l’ensemble des rushs de la soirée sur FCPX en prenant le soin de bien conserver les fichiers à leur emplacement d’origine.
Ensuite, et c’est là que rentre en compte la magie de FCPX, j’avais environ 200 rushs pour la soirée mais je ne souhaitais garder que ceux qui concernaient le groupe des Whitebox. Avec un affichage dans les évènements paramétrés avec une vignette par fichier, je survole simplement tout mes rushs grâce au skimmer (outil de survol) en les prévisualisant un par un. Dès que j’identifie un rush avec le groupe à l’intérieur, je le labellise comme favori avec le raccourci clavier « F ».
En gros main droite sur la souris pour piloter le skimmer, main gauche sur le clavier pour mettre en favori les rushs et les yeux sur l’écran pour identifier les membres du groupe.
Tous les plans qui m’intéressaient étaient marqués comme favori. Je bascule l’affichage pour n’afficher que les favoris et j’ai donc à l’écran que les rushs qui m’intéressent. Je créé un nouvel évènement et je glisse dedans tous les rushs que j’ai à l’écran.
Je me retrouve donc avec un événement qui contient tous les rushs concernant le groupe mais éparpillés physiquement sur le bordel du disque externe. Pour accélérer le processus de montage grâce au SSD, et puis je suis pas fan de bosser sur des supports externes quand c’est pas utile, je lance une consolidation des fichiers à l’intérieur de ma bibliothèque sur mon disque interne.
Environ 25 Go de rushs soit 20 min de copie donc premier café !
A l’intérieur de mon événement, je créé différentes collection de mots-clés : « interview », « balance », « backstage » et « concert ». Je refais glisser la quarantaine de rushs de mon événement dans chaque catégorie pour bien les isoler.
J’ai donc à l’intérieur de ma collection « concert », les images des 6 caméras avec deux fichiers par caméra à cause de la scission des rushs.
Le son du concert avait été capté en sortie de console mais sur un seul fichier couvrant l’ensemble de soirée et qui durait donc plus de 3h. J’ai donc fait un export en wav uniquement de la prestation du groupe pour ne pas avoir à gérer un fichier trop lourd à la fois pour la synchro et pour la création des waveforms. Donc export du fichier wav et reimport dans FCPX uniquement de l’audio de la prestation du groupe et consolidation pour tout garder au même endroit.
Dans ce cas-ci, pour utiliser la synchronisation automatique sous FCPX il aurait été nécessaire de nommer une part une les caméras alors que PluralEyes est beaucoup souple.
La force de PluralEyes est qu’il peut accéder aux fichiers contenus à l’intérieur des bibliothèques FCPX.
Donc depuis la collection « concert », je clique sur « afficher dans le finder » ce qui m’ouvre le dossier contenant uniquement les rushs de la prestation. Je fais tout glisser dans PluralEyes et grâce au nom unique des fichiers, j’ai pu identifier chaque caméra.
J’attends 5 minutes le temps de la création des waveforms pour l’ensemble des rushs, je clique sur « synchronise ». Au bout de 15 secondes je peux exporter un XML de mon multicam avec mes 6 angles vidéos synchronisés parfaitement avec le son de la console.
Pour accélérer la vitesse de traitement du montage, je lance une conversion de l’ensemble des rushs en Proxy à la fois pour soulager FCPX mais pour aussi pour avoir un codec unique au montage et donc assurer une stabilité des performances.
2ème café !
Premier visionnage de l’ensemble du concert pour m’imprégner de la musique, de l’ambiance et pour voir globalement le type d’image pour chaque caméra.
Suite à ce visionnage, j’organise mes angles de caméras pour avoir les plans d’ensemble et la GoPro en dessous des plans fait par les cadreurs sur le côté de la scène.
Pause déjeuner suivi d’un café, et déjà rien que les étapes du matin m’auraient probablement occupées 2-3 jours en devant inspecter un par un et trier tous les rushs de la soirée puis en devant faire la synchro à la main.
Avec l’outil multicam, j’ai l’impression à chaque fois d’avoir un jouet dans les mains et d’être vraiment productif. A chaque erreur de montage en direct, quand par exemple un cadreur change de cadre alors que son plan est sélectionné, j’ai toujours le doigt sur le raccourci pour placer un marquer sur la Timeline. Cela permet, une fois arrivé en fin de montage, de pouvoir revenir sur les erreurs détectées lors de l’édition du multicam.
L’élaboration du montage a pris environ 2h avec 3 passages au total et un retour sur les marqueurs à la fin de chaque passage.
Au cours de l’édition, je me suis aperçu qu’une des caméras centrales était sous-exposée, probablement à cause du « ramping » de l’objectif, sur les gros plans. J’ai donc légèrement rehaussé la luminosité de l’ensemble de l’image via une correction colorimétrique à l’intérieur du multicam. En une retouche j’ai modifié l’ensemble du rushs à la source et donc l’ensemble de ses apparitions dans le multicam. L’image est encore sombre mais il y a déjà eu une partie de compensée, sans avoir généré de bruit vidéo.
Comme j’ai un peu de marge, je teste à 2-3 effets d’apparition de texte et d’animation de logo pour ajouter un petit plus au montage. FCPX propose un panel assez large des effets visibles en temps réel.
Ensuite, je rebascule l’affichage en « médias originaux » pour afficher les rushs à la bonne résolution et je laisse se lancer le rendu automatique de la timeline en ProRes 422. L’avantage de cette étape est d’obtenir une timeline dans un codec unique pour assurer au maximum la fluidité de la lecture. Cela permet aussi de casser les GOP des codecs pour l’ajout d’éléments graphiques. Enfin cette conversion préalable permet au moment de l’export en ProRes de ne pas avoir de calcul à effectuer sur la Timeline et donc de sortir un fichier master très rapidement.
Après cette conversion qui aura durée 9 minutes, je visionne le projet une dernière fois en intégralité pour la dernière vérification avant de lancer un export définitif en ProRes.
Dernier café de la journée durant l’encode.
Labellisation des rushs nécessaires au montage du groupe des Whitebox.
Copie des rushs utiles.
Classement des rushs dans des collections de mots-clés.
Synchronisation du multicam dans Plural-Eyes puis export XML vers FCPX.
Conversion du multicam en Proxy.
Montage du multicam avec 3 passages pour l’ensemble du concert.
Ajout des éléments graphiques.
Bascule de l’affichage en pleine qualité.
Vérification du montage en ProRes 422.
Export puis compression H264 puis Upload sur Viméo.
9h :
Début de la journée avec la création sous FCPX d’une nouvelle bibliothèque dédiée au projet. Je connecte sur l’ordinateur le disque dur qui contient l’ensemble des fichiers de la soirée soit environ 250 Go de rushs. Je m’attendais à trouver un dossier avec tous les éléments concernant le groupe. Je me rends vite compte que tous les rushs des caméras JVC avaient été classés avec un dossier par groupe, mais que j’avais un dossier « GoPro » sans tri et un autre dossier avec des images d’interview, de backstage et de balance… bref du bon gros bordel pas trié avec les noms de fichiers directement issus des caméras et rien d’exploitable de manière visuelle.Je charge ensuite l’ensemble des rushs de la soirée sur FCPX en prenant le soin de bien conserver les fichiers à leur emplacement d’origine.
Ensuite, et c’est là que rentre en compte la magie de FCPX, j’avais environ 200 rushs pour la soirée mais je ne souhaitais garder que ceux qui concernaient le groupe des Whitebox. Avec un affichage dans les évènements paramétrés avec une vignette par fichier, je survole simplement tout mes rushs grâce au skimmer (outil de survol) en les prévisualisant un par un. Dès que j’identifie un rush avec le groupe à l’intérieur, je le labellise comme favori avec le raccourci clavier « F ».
En gros main droite sur la souris pour piloter le skimmer, main gauche sur le clavier pour mettre en favori les rushs et les yeux sur l’écran pour identifier les membres du groupe.
10h :
Fin de la session de dérushage.Tous les plans qui m’intéressaient étaient marqués comme favori. Je bascule l’affichage pour n’afficher que les favoris et j’ai donc à l’écran que les rushs qui m’intéressent. Je créé un nouvel évènement et je glisse dedans tous les rushs que j’ai à l’écran.
Je me retrouve donc avec un événement qui contient tous les rushs concernant le groupe mais éparpillés physiquement sur le bordel du disque externe. Pour accélérer le processus de montage grâce au SSD, et puis je suis pas fan de bosser sur des supports externes quand c’est pas utile, je lance une consolidation des fichiers à l’intérieur de ma bibliothèque sur mon disque interne.
Environ 25 Go de rushs soit 20 min de copie donc premier café !
10h30 :
Reprise du travail, suppression de l’événement qui contenait tous les rushs du disque externe, éjection du disque et lancement du boulot depuis le disque interne.A l’intérieur de mon événement, je créé différentes collection de mots-clés : « interview », « balance », « backstage » et « concert ». Je refais glisser la quarantaine de rushs de mon événement dans chaque catégorie pour bien les isoler.
J’ai donc à l’intérieur de ma collection « concert », les images des 6 caméras avec deux fichiers par caméra à cause de la scission des rushs.
Le son du concert avait été capté en sortie de console mais sur un seul fichier couvrant l’ensemble de soirée et qui durait donc plus de 3h. J’ai donc fait un export en wav uniquement de la prestation du groupe pour ne pas avoir à gérer un fichier trop lourd à la fois pour la synchro et pour la création des waveforms. Donc export du fichier wav et reimport dans FCPX uniquement de l’audio de la prestation du groupe et consolidation pour tout garder au même endroit.
Dans ce cas-ci, pour utiliser la synchronisation automatique sous FCPX il aurait été nécessaire de nommer une part une les caméras alors que PluralEyes est beaucoup souple.
La force de PluralEyes est qu’il peut accéder aux fichiers contenus à l’intérieur des bibliothèques FCPX.
Donc depuis la collection « concert », je clique sur « afficher dans le finder » ce qui m’ouvre le dossier contenant uniquement les rushs de la prestation. Je fais tout glisser dans PluralEyes et grâce au nom unique des fichiers, j’ai pu identifier chaque caméra.
J’attends 5 minutes le temps de la création des waveforms pour l’ensemble des rushs, je clique sur « synchronise ». Au bout de 15 secondes je peux exporter un XML de mon multicam avec mes 6 angles vidéos synchronisés parfaitement avec le son de la console.
11h :
Je récupère donc un projet à partir du XML avec à l’intérieur de la timeline, mon plan multicam parfaitement synchronisé.Pour accélérer la vitesse de traitement du montage, je lance une conversion de l’ensemble des rushs en Proxy à la fois pour soulager FCPX mais pour aussi pour avoir un codec unique au montage et donc assurer une stabilité des performances.
2ème café !
11h30 :
Retour devant l’ordinateur et l’ensemble de la conversion est déjà finalisé. J’ai relancé le test plus tard, il a fallu 16 min à FCPX pour convertir les images des 6 caméras soit près de 2h de rushs en Proxy pour le montage.Premier visionnage de l’ensemble du concert pour m’imprégner de la musique, de l’ambiance et pour voir globalement le type d’image pour chaque caméra.
Suite à ce visionnage, j’organise mes angles de caméras pour avoir les plans d’ensemble et la GoPro en dessous des plans fait par les cadreurs sur le côté de la scène.
Pause déjeuner suivi d’un café, et déjà rien que les étapes du matin m’auraient probablement occupées 2-3 jours en devant inspecter un par un et trier tous les rushs de la soirée puis en devant faire la synchro à la main.
13h30 :
Lancement du montage avec l’outil multicam de FCPX qui permet une édition en direct lors de la lecture. La lecture est fluide, sans accro grâce aux fichiers Proxy même si mon ordinateur aurait supporté le montage avec les codecs d’origine. Selon mes essais cela fonctionne en lecture mais pas sûr que ça aurait encaissé les 20 minutes de lecture et d’édition en simultanée.Avec l’outil multicam, j’ai l’impression à chaque fois d’avoir un jouet dans les mains et d’être vraiment productif. A chaque erreur de montage en direct, quand par exemple un cadreur change de cadre alors que son plan est sélectionné, j’ai toujours le doigt sur le raccourci pour placer un marquer sur la Timeline. Cela permet, une fois arrivé en fin de montage, de pouvoir revenir sur les erreurs détectées lors de l’édition du multicam.
L’élaboration du montage a pris environ 2h avec 3 passages au total et un retour sur les marqueurs à la fin de chaque passage.
Au cours de l’édition, je me suis aperçu qu’une des caméras centrales était sous-exposée, probablement à cause du « ramping » de l’objectif, sur les gros plans. J’ai donc légèrement rehaussé la luminosité de l’ensemble de l’image via une correction colorimétrique à l’intérieur du multicam. En une retouche j’ai modifié l’ensemble du rushs à la source et donc l’ensemble de ses apparitions dans le multicam. L’image est encore sombre mais il y a déjà eu une partie de compensée, sans avoir généré de bruit vidéo.
15h30 :
Création du générique avec le texte défilant de FCPX en changeant la police et la taille puis insertion des différents logos.Comme j’ai un peu de marge, je teste à 2-3 effets d’apparition de texte et d’animation de logo pour ajouter un petit plus au montage. FCPX propose un panel assez large des effets visibles en temps réel.
Ensuite, je rebascule l’affichage en « médias originaux » pour afficher les rushs à la bonne résolution et je laisse se lancer le rendu automatique de la timeline en ProRes 422. L’avantage de cette étape est d’obtenir une timeline dans un codec unique pour assurer au maximum la fluidité de la lecture. Cela permet aussi de casser les GOP des codecs pour l’ajout d’éléments graphiques. Enfin cette conversion préalable permet au moment de l’export en ProRes de ne pas avoir de calcul à effectuer sur la Timeline et donc de sortir un fichier master très rapidement.
Après cette conversion qui aura durée 9 minutes, je visionne le projet une dernière fois en intégralité pour la dernière vérification avant de lancer un export définitif en ProRes.
17h :
Compression du fichier Master en H264 pour un upload sur Vimeo grâce au logiciel Handbrake. Il existe une fonction de conversion et d’upload sur Vimeo automatique dans FCPX, mais qui peut poser problème sur des projets assez long comme celui-ci si on ne dispose pas d’un compte Premium à l’arrivée. En gros FCPX a du mal à rentrer dans les normes pour l’upload en terme de taille de fichier.Dernier café de la journée durant l’encode.
18h :
Fin d’upload du fichier de 450 Mo sur Viméo (merci Free et la fibre optique). Pendant le calcul par Viméo du fichier, je copie le texte du générique, choisis ma vignette de prévisualisation et commence à envoyer quelques mails avec le lien de la vidéo.Où se situe l’apport de Final Cut Pro X dans cette journée de travail ?
Le premier apport est l’outil de survol du logiciel qui permet une prévisualisation instantanée des rushs. Dans mon cas, j’étais plus en détection visuelle qu’en recherche précise d’un plan comme ce peut être le cas en fiction avec plusieurs prises pour un seul angle. Le fait de pouvoir ajouter des tags dynamiques « de tri » associés aux collections de mots-clés ou à l’affichage apporte un confort supplémentaire dans le travail car un rush peut-être présent à plusieurs endroits. Sur FCP7 il fallait glisser les rushs dans des chutiers, éventuellement les labelliser avec des couleurs mais ils ne pouvaient pas être présent à plusieurs endroits.
Même si ici j’ai utilisé Plural-Eyes, avec 15 minutes de plus, j’aurai parfaitement pu utiliser la fonction automatique de synchronisation de FCPX. Faire une synchro à la main des 6 angles était envisageable mais c’est toujours plus long, surtout ici avec les caméras qui coupent les rushs au delà d’une certaine durée ce qui implique le double de travail.
L’un des apports les plus importants de FCPX, même si j’ai tendance à l’oublier tellement c’est transparent, c’est la possibilité de lancer des calculs et des transcodage sur le GPU (la carte graphique). Cette externalisation hors du processeur permet d’arriver à des temps très courts (et impressionnants) de transcodage dans les différents ProRes tout en laissant une certaine disponibilité des ressources de la machine pour d’autres tâches.
La possibilité de basculer entre Proxy et médias originaux est un des points forts de FCPX qui assure une fluidité constante dans le travail. Il m’arrive souvent de bosser en Proxy même sur des projets basiques pour garder le temps réel en permanence, même en empilant les plans ou les titres.
Le dernier point fort est sur les fonctions d’export. J’aurai été à même de graver un DVD à la fin du montage ou même un Blu-ray directement depuis le logiciel, pendant un éventuel export sur Vimeo et Youtube en simultané. Même si j’ai gardé une méthode de travail où je gère mes presets de compression en H264, j’aurai pu laisser FCPX faire le travail tout seul.
Même si ici j’ai utilisé Plural-Eyes, avec 15 minutes de plus, j’aurai parfaitement pu utiliser la fonction automatique de synchronisation de FCPX. Faire une synchro à la main des 6 angles était envisageable mais c’est toujours plus long, surtout ici avec les caméras qui coupent les rushs au delà d’une certaine durée ce qui implique le double de travail.
L’un des apports les plus importants de FCPX, même si j’ai tendance à l’oublier tellement c’est transparent, c’est la possibilité de lancer des calculs et des transcodage sur le GPU (la carte graphique). Cette externalisation hors du processeur permet d’arriver à des temps très courts (et impressionnants) de transcodage dans les différents ProRes tout en laissant une certaine disponibilité des ressources de la machine pour d’autres tâches.
La possibilité de basculer entre Proxy et médias originaux est un des points forts de FCPX qui assure une fluidité constante dans le travail. Il m’arrive souvent de bosser en Proxy même sur des projets basiques pour garder le temps réel en permanence, même en empilant les plans ou les titres.
Le dernier point fort est sur les fonctions d’export. J’aurai été à même de graver un DVD à la fin du montage ou même un Blu-ray directement depuis le logiciel, pendant un éventuel export sur Vimeo et Youtube en simultané. Même si j’ai gardé une méthode de travail où je gère mes presets de compression en H264, j’aurai pu laisser FCPX faire le travail tout seul.
Les manques de FCPX ?
La version 10.1.2 vient d’apporter la suppression des fichiers Proxy depuis FCPX et une meilleure gestion des bibliothèques qui sont des fonctions bienvenues.
J’aurais juste aimé pouvoir utiliser l’outil de stabilisation à l’intérieur de certains plans du multicam. Pour l’instant ce n’est pas possible mais ça serait vraiment une bonne idée !
J’aurais juste aimé pouvoir utiliser l’outil de stabilisation à l’intérieur de certains plans du multicam. Pour l’instant ce n’est pas possible mais ça serait vraiment une bonne idée !
