Le contrôle de version fait-il partie du flux de production vidéo?

Je suis développeur de logiciels et je m'intéresse aussi à la photographie (depuis quatre ans) et à la production vidéo (pour quelques mois seulement).

■ Dans le développement logiciel, il y a une règle importante que chaque développeur suit sur chaque projet: tout doit être sous contrôle de version : code source, fichiers de configuration, schéma de base de données, documentation - tout ce qui permet de construire le projet à partir de zéro. Cela a deux conséquences agréables:

1. En cas de sinistre lorsque vous perdez tout sauf le référentiel de contrôle de version, vous devriez pouvoir continuer comme si de rien n'était.

2. En cas de changement stupide qui affecte négativement le projet, le développeur peut revenir à une révision antérieure.

■ En photographie, chaque modification apportée aux photos est stockée pour toujours dans le catalogue Lightroom , ce qui permet de revenir à tout moment à l'état précédent. Avec la fonction de copie virtuelle, Lightroom permet également de faire ce qu'on appelle une branche dans le contrôle de version: la possibilité de tester quelque chose de différent, et de conserver les deux résultats ou d'en supprimer un plus tard.

Le catalogue ne stocke pas les photos RAW elles-mêmes, mais elles ne changent pas de toute façon.

■ Dans la production vidéo, les choses semblent différentes. Je travaille avec Premiere Pro, After Effects et Soundbooth.

• Aucun ne semble stocker l'historique de façon permanente: si je fais une action par erreur et que je ne la remarque que le lendemain, il n'y a aucun moyen de récupérer la version précédente.

• Soundbooth modifie également directement les fichiers WAV, ce qui nécessite un effort supplémentaire pour séparer les enregistrements originaux des enregistrements modifiés.

• Le contrôle de version est rarement mentionné, et je n'ai trouvé personne dire comment il utilise réellement le contrôle de version dans son flux de travail. De plus, personne ne mentionne quel contrôle de version doit être utilisé, et puisque la plupart des systèmes de contrôle de version sont optimisés pour les fichiers texte, pas les fichiers binaires, cela crée un défi supplémentaire.

• Video.SE n'a pas de balises de contrôle de version ou de révision .

J'ai donc deux questions:

1. Le contrôle de version fait-il partie du flux de travail d'une personne qui travaille avec la production vidéo? Comment est-il intégré?

2. La migration vers Adobe Creative Cloud serait-elle utile? Existe-t-il des fonctionnalités spécifiques qui permettent, dans Creative Cloud, de suivre les révisions successives d'un projet Premiere Pro ou After Effects?

Remarque: pour éviter les réponses hors sujet, je souligne que ma question n'est pas liée aux sauvegardes , et concerne spécifiquement le stockage des révisions successives de mon travail, sans avoir de sauvegarde sur site / hors site des données.

Le contrôle de version au sens de Git n'est pas très pratique dans le monde de la vidéo. Vous devez créer un outil de contrôle de version spécifique pour chaque outil audio et vidéo, car tous fonctionnent avec leurs propres formats de projet. Mais être capable de lire ces formats n'est qu'une chose, alors vous avez également besoin du moteur de rendu de cet outil pour afficher les différences.

Bien que tous ces outils fonctionnent de manière non destructrice à moins que vous ne pré-rendiez certaines choses (comparez cela à la compilation d'une dll / lib d'un morceau de votre code et travaillez avec cela à partir de maintenant), vous pouvez donc généralement revenir en arrière à une ancienne révision en faisant ctrl + z ou en utilisant l'outil d'historique dans certains programmes.

Bien que l'enregistrement des sous-versions soit généralement le chemin à parcourir. Comme stib décrit dans sa réponse ou en le faisant manuellement.

Quelque chose que j'aime faire et qui fonctionne bien avec tous les logiciels, c'est de mettre mes fichiers de projet (pas de métrage source) dans Dropbox. Si vous avez une vitesse de téléchargement quelque peu rapide (~ 1 Mbit / s) et que votre fichier de projet n'est pas de 100 Mo +, vous pouvez télécharger votre projet avant d'enregistrer la prochaine fois. Un projet Premiere / AE / FCP moyen se situe entre 10 et 20 Mo. Vos fichiers récemment enregistrés seront téléchargés en 1 à 2 minutes. Encore plus rapide si vous avez plus de bande passante de téléchargement.

Ensuite, si vous devez revenir en arrière, vous pouvez accéder à l'historique de Dropbox de vos fichiers et télécharger ou restaurer cette révision. Dropbox enregistre les révisions de fichiers pour toujours * sur un compte payant (* au moins quand ils avaient l'option pack rat, maintenant c'est un an je pense) et pendant 30 jours sur un compte gratuit. Je suis sûr qu'il existe d'autres hébergeurs cloud qui offrent des fonctionnalités similaires. C'est un peu comme utiliser une version super limitée de git qui gère très bien les fichiers binaires et est sans maux de tête. Cela a l'avantage de ne pas encombrer le dossier avec des tonnes de fichiers et d'avoir une sauvegarde en même temps.

La plupart des hébergeurs cloud proposent également des abonnements d'équipe afin que vous puissiez travailler avec plusieurs éditeurs. Ou vous partagez le dossier du projet avec d'autres membres de l'équipe.

Juste pour ajouter aux réponses précédentes: Bien qu'il n'y ait rien de comparable à Git pour le monde de la vidéo, il existe des outils de gestion des actifs numériques / de gestion des actifs multimédias qui peuvent plus ou moins faire la même chose - contrôle de version et gestion des autorisations / utilisateurs (ils le font également beaucoup plus, car ils sont vraiment construits comme des bibliothèques pour vos médias). Pendant des années, j'ai utilisé l'application Final Cut Server d'Apple (désormais obsolète) qui s'intégrait à Final Cut Suite (Final Cut Pro 7, Soundtrack Pro, etc.) dans une petite installation de publication.

Nous l'avons utilisé pour le contrôle de version et la création de branches sur des fichiers de projet, ce qui a permis à plusieurs éditeurs de travailler sur un même projet de manière relativement transparente. Comme il s'agissait d'un produit Apple, il a été conçu pour être utilisé avec Final Cut Pro et pouvait donc lire et travailler avec les fichiers de projet FCP très facilement. Même compte tenu de cela, le contrôle de version de Final Cut Server reposait sur l'enregistrement des versions précédentes de l'intégralité du fichier de projet, il n'utilisait pas de différences. Je ne connais aucun DAM qui le fasse pour la raison même d'une réponse précédente - il y a beaucoup trop de formats propriétaires (même si, ironiquement, beaucoup d'entre eux s'appuient désormais sur XML comme colonne vertébrale pour ces formats de fichiers de projet ).

Le FCS était génial car il était relativement abordable. Il n'y avait jamais vraiment rien d'analogue pour Premiere Pro. De nos jours, malheureusement, vous devrez distribuer une bonne partie du changement pour obtenir des capacités similaires - principalement parce que ces outils sont vraiment conçus pour les installations de publication, pas un seul éditeur. Ils nécessitent également une intégration / configuration potentiellement importante.

Voici quelques options (je n'ai aucune relation avec aucune de ces sociétés, ceci est basé uniquement sur mes recherches à la recherche d'une solution similaire):

• Cantemo: http://www.cantemo.com/premiereprocs6.html
• CatDV: http://www.squarebox.com/

Le contrôle de version n'a pas vraiment sa place dans le montage vidéo car il est par nature non destructif. Au cœur de tout NLE (éditeur vidéo non linéaire), la sortie est en fait quelque chose connu sous le nom de liste de décision d'édition ou EDL. Ceci est extrêmement analogue à l'historique de Lightroom car cet historique est un enregistrement de toutes les modifications qui ont été appliquées dans l'ordre.

Les NLE fonctionnent à partir des clips source. Ils prennent les points de début et de fin de ces clips pour les placer dans une chronologie, puis les effets peuvent être appliqués à ces actifs dans un ordre donné (en fonction du placement des effets), mais ce sont toutes des décisions d'édition et appliquées à la volée ( ou éventuellement rendu dans des fichiers d'aperçu temporaires). Le rendu de sortie final est le résultat de l'application de la totalité de l'EDL aux clips source.

Vous pouvez enregistrer une version du projet afin de pouvoir revenir à une version précédente de la liste EDL si vous le souhaitez, mais cela n'est généralement pas nécessaire, sauf si vous vous connectez très intentionnellement pour essayer une autre approche pour éditer une séquence ( dans ce cas, une copie de cette chronologie est souvent un meilleur choix de toute façon.)

Si vous l'activez dans les préférences, After Effects et Premiere effectuent automatiquement des sauvegardes incrémentielles des fichiers de projet.

Ces sauvegardes incrémentielles pourraient être utilisées pour revenir aux versions précédentes, ce qui est comme une implémentation très basique du contrôle de version (vous voudrez peut-être augmenter le nombre de versions à partir de 5). FCP a une fonction "restaurer à partir de la version précédente" intégrée, ce qui est bon quand il gomme vos fichiers de projet. Après que les effets aient (mais pas Premiere, allez comprendre) la possibilité d'enregistrer de manière incrémentielle un projet. Je l'utilise tout le temps lorsque j'apporte de gros changements à un projet, et je veux pouvoir revenir au tronc principal, pour ainsi dire.

Pour un contrôle supplémentaire, vous pourriez imaginer utiliser un logiciel de contrôle de version pour gérer les dossiers dans lesquels vous conservez vos fichiers de projet et vos enregistrements automatiques, afin que les éditeurs vérifient les modifications de coupe et de validation actuelles, tant que tous les médias sont accessibles ou copiés de manière centralisée sur les machines de chacun dans le même chemin relatif. Cela ne vous permettrait pas de bifurquer et de fusionner les modifications d'autres personnes, comme vous pouvez le faire avec du code - ce serait une fonctionnalité intéressante (je dirais qu'elle pourrait être implémentée avec les scripts Adobe Extendcript, tant que vos compétences sont à réécrire Git ou SVN en Javascript).

En tant que professionnel de la vidéo à long terme, je peux attester du fait que le besoin d'une forme légère, robuste, transparente et ouverte d'un VCS fait cruellement défaut dans la majorité des workflows multimédias. Le problème est cependant multiforme et est à la fois culturel et technique.

Traditionnellement, nous travaillons dans une usine de saucisses comme un projet est éclairé par le script, passe à la production, une fois emballé, il passe à la post-production, puis une sortie finale est livrée au bras de distribution qui délivre ensuite les sorties de l'appareil / de la plate-forme .

De nos jours, cette approche de type usine est une illusion où la transition entre la post-production et la distribution en particulier n'est jamais claire. Il y a beaucoup de va-et-vient avec des coupes / éditions pour différentes langues / marchés, que ce soit pour revenir en arrière et faire du remastering pour le dernier format par exemple. Ensuite, il y a la nécessité d'accéder aux versions finales à des fins de marketing ... Par conséquent, il est essentiel non seulement pour les parties distantes, mais aussi pour les personnes qui ne se rencontrent jamais, d'avoir une compréhension définitive et cataloguée de la version sur laquelle ils doivent travailler. Cela s'étend non seulement aux encodages principaux, mais à toutes les versions de ce maître pour différents marchés ainsi qu'aux versions des actifs qui ont été utilisés pour créer chaque maître.

Ce n'est que maintenant que la communauté des médias est engagée sur ce qu'est vraiment une version et elle est régulièrement débattue en raison de la multitude de flux de travail et de préoccupations différentes. Je le décompose en une version de travail et une version de distribution. Il y a des efforts pour remédier à cela au sein de la distribution en créant un format de fichier archive qui suit les versions en lui-même (pour lutter contre le fait qu'il existe plusieurs outils, plates-formes, etc.) - c'est ce qu'on appelle le format maître interopérable (IMF) à ne pas confondre avec le banque) et est piloté par SMPTE. La bonne chose à ce sujet est qu'il évolue pour assurer l'interopérabilité entre la myriade de systèmes de gestion des actifs numériques (ceux qui veulent le prendre en charge) qui existent - certains studios que je connais ont des systèmes de gestion des actifs qui se comptent par centaines - ce serait les aider en interne et encore moins pour les transferts externes. Bien sûr, il n'a pas encore été utilisé dans un environnement de production car il est conçu comme un format de niveau archive (Netflix l'utilise maintenant). C'est aussi un fichier très lourd sans moyen facile de le créer à moins d'avoir le capital nécessaire pour investir dans les outils. Netflix a publié un ensemble d'outils open source qui offre une capacité de lecture agréable. C'est aussi un fichier très lourd sans moyen facile de le créer à moins d'avoir le capital nécessaire pour investir dans les outils. Netflix a publié un ensemble d'outils open source qui offre une capacité de lecture agréable. C'est aussi un fichier très lourd sans moyen facile de le créer à moins d'avoir le capital nécessaire pour investir dans les outils. Netflix a publié un ensemble d'outils open source qui offre une capacité de lecture agréable.

En ce qui concerne la version de travail ou le niveau de production, j'estime qu'il est nécessaire de fournir un VCS (comme une forme modifiée de git peut-être) que tout le monde peut utiliser, quelle que soit sa taille, afin de faciliter le travail à distance. Les fichiers multimédias sont bien sûr beaucoup plus volumineux que l'échange de code ou de bibliothèques, mais les décisions prises sur ces fichiers sont l'élément clé. Pour ma part, je voudrais tester le travail à distance via git commits, ne serait-ce que pour éviter les conventions de dénomination des conventions de dénomination 'file_Final_FINAL_MASTER_version3.mxf' qui sont échangées d'avant en arrière.

J'avais la même question, étant également ingénieur logiciel de métier, pensant au travail de Photoshop.

nous pouvons dire au programme de montage vidéo "revenir à la version 2.5", éditer un peu, puis lui dire "revenir à la version 7" et il est capable de le faire?

J'ai trouvé que Photoshop me permet de définir une version nommée dans l'historique, et je pense que c'est enregistré dans le fichier ...? Pour les révisions (entrées dans la liste d'historique) qui ne sont pas nommées, les nœuds sont perdus de l'affichage lorsqu'une modification est effectuée à un emplacement précédent (branchement) et aucun reflog n'est exposé.

Les nouvelles versions de Premiere semblent avoir un journal d'historique similaire et je suppose que cela évolue vers la même architecture interne, où chaque modification est une autre copie du projet qui partage la plupart des statuts avec les précédents. Si l'historique contient des points de contrôle qui sont enregistrés, cela ressemble beaucoup à un magasin git: chaque version contient des références (partagées) aux éléments sous-jacents jusqu'aux définitions de segment. Comme la vidéo elle-même n'est pas dans le fichier, elle se prête bien à de plus en plus de versions avec peu d'augmentation de taille.

J'ai vu un séminaire où un membre de l'équipe de développement Photoshop a expliqué l'architecture. Il semble que les entrées d'historique que vous voyez soient analogues aux versions de git, comme les affichages de gitk. Nommer la version équivaut à une balise git. Vous pouvez remettre à toute révision visible en pointant, et réinitialiser arrière aussi. Mais faire n'importe quel changement qui est lui-même mis dans l'histoire, c'est comme faire un rafraîchissement complet (shift ou ctrl F5) - vous perdez tout ce qui n'est pas enchaîné à partir de la tête de branche actuelle ou de la balise nommée (mais je pense que des choses comme les références de source de clone restent pointer vers la version désormais invisible).

Mais ce n'est pas ce que j'écris pour suggérer. J'ai défini le volume NAS où réside mon projet pour créer un instantané toutes les 3 heures. Windows a un mécanisme de point de contrôle mais je pense qu'il n'est pas configurable; Mac Time Machine fait quelque chose de similaire.

En général, vous pouvez archiver toutes les versions enregistrées du fichier et, dans Premiere, qui ne contient pas tous les actifs importés (constants), il est donc raisonnable de les enregistrer tous, même sans pouvoir utiliser des deltas pour enregistrer uniquement ce qui a changé.

Je réapprenais simplement Premiere et devenais plus agressif en essayant des choses, je suis confiant que je peux revenir en arrière si la prochaine fois que je travaille dessus, je regrette ce que j'ai fait, ou j'ai trouvé une meilleure façon et je veux le faire à nouveau. Il s'agit d'un système de versionnage de révision efficace. En le faisant sur le NAS, je suis également protégé contre un BSOD qui jette tout le projet lors de l'enregistrement. :)

la mise à jour de l'historique est courte, par défaut à 32 entrées. Il est vide lorsque le projet est chargé. Cependant, l'enregistrement automatique ne se contente pas d'enregistrer sur le même fichier comme nous le voyons dans la plupart des programmes; il les numérote plutôt et les garde. Ainsi, je peux voir les horodatages du fichier et charger une copie plus ancienne, ce qui me donne un historique de version des points de contrôle de 15 minutes. Dans mon cas, chaque fichier fait 44 Ko, ce qui n'est rien comparé à la taille de l'actif - c'est la taille de 76 millisecondes d'audio, ou 1/7 d'une image de métrage de carte SD de classe 10 .

Si vous avez l'intention de garder un point de contrôle avec un nom significatif, enregistrez simplement la copie sous. Mais la sauvegarde automatique, réglée sur une fréquence élevée, peut être utilisée pour revoir n'importe quel état (jusqu'à cette granularité à ce moment-là) sans planification préalable, avec peu d'effort.

Une note pour les non-ingénieurs qui ne sont pas familiers avec le contrôle de version: Outre la possibilité de revenir en arrière de manière évidente, je l'utilise souvent pour vérifier ce que je viens de changer, ou comparer avec l'état d'avant de commencer la tâche en cours , ou comparer avec le dernier verson qui a été partagé avec le groupe.

Étant donné que Premeire prend désormais en charge l'ouverture de plusieurs projets dans l'espace de travail, il serait possible d'avoir un paramètre d'espace de travail de disposition des fenêtres pour comparer deux chronologies. C'est, d' utiliser plus efficacement d' avoir ces versions, non seulement pour la sauvegarde. Je dis souvent aux programmeurs qui n'utilisent pas git comment il devient un outil à usage général, comme un éditeur de texte.

Je me demande comment les cinéastes professionnels gèrent le contrôle de version, si ce n'est plus qu'ad-hoc? La conception de sauvegarde automatique semble très utile, et l'outil de groupware d'écriture de script intégré a un suivi de révision visible explicite.

Il n'est pas pratique d'avoir le contrôle de version pour les fichiers vidéo eux-mêmes parce que premièrement, ils sont énormes, deuxièmement ils se déplacent (allez-vous conserver chaque image?), Troisièmement, ils sont immuables. Autrement dit, les fichiers d'origine ne changent jamais lors de l'édition.

Mais le contrôle de version pour les fichiers de projet a beaucoup de sens. Actuellement, après chaque changement important, je crée un nouveau fichier de projet et lui donne un nom descriptif - qu'est-ce que j'ai fait, qu'est-ce que j'ai ajouté et qu'est-ce que j'ai supprimé. En substance, je dois maintenir l'historique manuellement au moyen des noms de fichiers. Avoir des fichiers de projet sous contrôle de version est une excellente idée, pourquoi je n'y avais pas pensé auparavant!