Chaque clip arrivait avec une image en moins
Vous marquez les points d’entrée et de sortie sur quarante clips, vous les envoyez sur une timeline, et le montage a l’air bon. Des semaines plus tard, quelqu’un qui vérifie les durées vous dit que chacun d’eux est plus court d’une image que ce que vous aviez marqué.
Une image, ce n’est rien à regarder et tout pour des spécifications de livraison. Et c’est facile à laisser passer, car l’endroit où elle disparaît, c’est un seul mot dans une API que personne ne relit.
Deux façons de définir la « sortie »
Quand vous marquez un point de sortie, vous voulez dire l’une de deux choses, et les deux sont raisonnables :
- Inclusif — l’image de sortie fait partie du clip. C’est ce que vous montrent les logiciels de montage. Marquez 3,0 s à 8,0 s sur du matériel à 30 fps et vous attendez 151 images : cinq secondes, plus l’image sur laquelle vous avez atterri.
- Exclusif — l’image de sortie est l’endroit où le clip s’arrête. Les mêmes marques donnent 150 images.
Aucun des deux n’a tort. Le problème commence quand une partie de votre pipeline suppose l’un et la partie suivante suppose l’autre, parce que la différence est exactement d’une image, et qu’une image est invisible.
Où passe vraiment l’image
L’API de scripting de Resolve prend une image de début et une image de fin
quand vous ajoutez un clip à une timeline. L’image de fin est
exclusive : la durée que vous obtenez est
endFrame - startFrame.
Donc si vous gardez votre point de sortie comme inclusif — tel que l’interface l’a présenté à la personne qui marquait — et que vous transmettez ce chiffre tel quel à l’API, chaque clip arrive avec une image en moins. Pas seulement le premier. Pas seulement les cas compliqués. Tous, silencieusement, pour toujours.
La correction tient en une ligne : passer outPoint +
1. La partie difficile, c’est de savoir qu’il le faut.
Il y a ici un second cas limite à connaître. Si la plage s’effondre au point où
l’image de fin égale l’image de début, l’appel append renvoie
false, et le clip n’arrive tout simplement pas. Une plage de
longueur zéro doit être ramenée à une image avant de partir.
Pourquoi ça survit aux tests
Les plages quittent une appli de rushes par plus d’une porte, et les portes ne
sont pas d’accord entre elles. Une API de timeline, un EDL, un export média,
une ALE — dans les systèmes avec lesquels j’ai travaillé, ce sont quatre
conversions séparées, et elles ne suivent pas toutes la même convention. L’EDL
et l’ALE traitent toutes deux la fin comme exclusive. Un export qui calcule la
durée comme out - in est exclusif aussi. Seule l’interface où la
personne a réellement marqué était inclusive.
Ça fait quatre occasions de convertir, et il suffit qu’un seul endroit le fasse deux fois, ou qu’un seul endroit ne le fasse pas du tout, pour décaler une image. La règle qui rend ça viable, c’est de garder une seule convention en interne et de convertir exactement une fois à chaque sortie — jamais au milieu.
Comment vérifier la vôtre
Vous ne pouvez pas juger ça à l’œil. Il faut couper quelque chose et compter ce qui en ressort. Marquez une plage avec laquelle vous pouvez faire du calcul — 3,0 s à 8,0 s sur du matériel à 30 fps —, envoyez-la, et lisez la durée sur la timeline. Inclusif donne 151 images. Exclusif donne 150.
Réglez la fréquence d’images de la timeline pour qu’elle corresponde au clip avant de compter. Cette partie m’a coûté un après-midi. Posez du matériel à 30 fps sur une timeline à 24 fps, et ces 151 images deviennent 120 — l’image en trop est arrondie en même temps que plusieurs autres, et la vérification cesse silencieusement d’en être une. Le point d’entrée reste là où vous l’avez posé, donc rien n’a l’air faux.
Deux autres choses que j’éviterais. Ne faites pas le calcul en secondes : une valeur qui devrait faire 121 images peut arriver sous la forme 5,041666…, et la conversion inverse en images la tronque à 120. Travaillez en images entières. Et ne vérifiez pas avec l’appel d’API qui renvoie l’image de fin source d’un clip — dans mes tests, son point de référence n’était pas cohérent entre les éléments d’une même timeline, donc il ne peut pas trancher un débat sur une seule image. Lisez plutôt le décalage et la durée.
Ce que fait Divecut
Divecut garde les points de sortie comme inclusifs, parce que c’est ce que veut
dire la personne qui les marque, et convertit une fois à chaque sortie. Pour la
passation vers Resolve, cela donne endFrame = outPoint + 1, avec
un minimum d’une image pour qu’une plage effondrée arrive quand même.
Je l’ai vérifié de la façon décrite plus haut plutôt que de faire confiance au code : 3,0 s à 8,0 s sur du matériel à 30 fps arrivent en 151 images sur une timeline à la bonne fréquence. Cette mesure est la raison d’être de cet article — j’ai trouvé le décalage en lisant les deux chemins côte à côte, avant même qu’un seul rush soit coupé, et c’est ce comptage qui a confirmé la correction.
Les clips arrivent en Log, intacts, avec la conversion appliquée comme information de timeline plutôt qu’incrustée dans l’image. Ce qui est un autre article.
Divecut est un navigateur de rushes pour macOS et iPad. Il affiche les clips Log dans la couleur pour laquelle vous les avez tournés, vous permet de les retrouver en langage courant, et transmet vos sélections à DaVinci Resolve avec le Log intact — plages comprises. Voir tout ce qu’il fait.