¿El control de versiones tiene una parte en el flujo de trabajo de producción de video?


20

Soy desarrollador de software y también estoy interesado en la fotografía (durante cuatro años) y la producción de video (solo durante unos meses).

■ En el desarrollo de software, hay una regla importante que cada desarrollador sigue en cada proyecto: todo debe estar bajo control de versión : código fuente, archivos de configuración, esquema de base de datos, documentación, todo lo que permite construir el proyecto desde cero. Esto tiene dos consecuencias agradables:

  1. En caso de un desastre cuando pierde todo excepto el repositorio de control de versiones, debe poder continuar como si nada hubiera pasado.

  2. En caso de algún cambio estúpido que afecte negativamente al proyecto, el desarrollador puede volver a una revisión anterior.

■ En fotografía, cada cambio que realizo en las fotos se almacena para siempre en el catálogo de Lightroom , lo que hace posible volver al estado anterior en cualquier momento. Con la función de copias virtuales, Lightroom también permite hacer lo que se llama una rama en el control de versiones: la capacidad de probar algo diferente y conservar ambos resultados o eliminar uno de ellos más tarde.

El catálogo no almacena las fotos RAW, pero no cambian de todos modos.

■ En la producción de video, las cosas parecen diferentes. Trabajo con Premiere Pro, After Effects y Soundbooth.

  • Ninguno parece almacenar el historial de forma permanente: si hago una acción por error y lo noto solo al día siguiente, no hay forma de recuperar la versión anterior.

  • Soundbooth también cambia directamente los archivos WAV, lo que requiere un esfuerzo adicional para mantener separadas las grabaciones originales de las modificadas.

  • El control de versiones rara vez se menciona, y no he encontrado a nadie que diga cómo usa realmente el control de versiones en su flujo de trabajo. Además, nadie menciona qué control de versión debe usarse, y dado que la mayoría de los sistemas de control de versión están optimizados para archivos de texto, no binarios, esto crea un desafío adicional.

  • Video.SE no tiene etiquetas de o .

Por lo tanto, tengo dos preguntas:

  1. ¿El control de versiones tiene una parte en el flujo de trabajo de una persona que trabaja con la producción de video? ¿Cómo se integra?

  2. ¿Sería útil migrar a Adobe Creative Cloud? ¿Existen características específicas que permitan, en Creative Cloud, rastrear revisiones sucesivas de un proyecto Premiere Pro o After Effects?

Observación: para evitar respuestas fuera del tema, destaco que mi pregunta no está relacionada con las copias de seguridad , y es específicamente sobre el almacenamiento de revisiones sucesivas de mi trabajo, no tener una copia de seguridad de los datos en el sitio / fuera del sitio.

Respuestas:


10

El control de versiones en el sentido de Git no es muy práctico en el mundo del video. Necesitaría crear una herramienta de control de versiones específica para cada herramienta de audio y video, ya que todas funcionan con sus propios formatos de proyecto. Pero poder leer estos formatos es solo una cosa, entonces también necesitas el motor de renderizado de esa herramienta para mostrar los diff.

Aunque todas estas herramientas funcionan de una manera no destructiva a menos que pre-renderice algunas cosas (compárelo con compilar un dll / lib de una parte de su código y trabaje con eso de ahora en adelante), por lo que generalmente puede regresar a una revisión anterior haciendo ctrl + z o usando la herramienta de historial en algunos programas.

Aunque guardar sub versiones suele ser el camino a seguir. Como stib descrito en su respuesta o haciéndolo manualmente.

Algo que me gusta hacer y funciona bien con cada software es poner mis archivos de proyecto (sin metraje fuente) en Dropbox. Si tiene una velocidad de carga algo rápida (~ 1 Mbit / s) y su archivo de proyecto no tiene más de 100MB, puede cargar su proyecto antes de guardarlo la próxima vez. Un proyecto promedio de Premiere / AE / FCP es de alrededor de 10-20 MB, por lo que sus archivos guardados recientemente se cargarán en 1-2 minutos. Incluso más rápido si tiene más ancho de banda de carga.

Luego, si tiene que regresar, puede acceder al historial de Dropbox de sus archivos y descargar o restaurar esa revisión. Dropbox guarda las revisiones de archivos para siempre * en una cuenta paga (* al menos cuando tenían la opción de paquete de ratas, creo que ahora es un año) y durante 30 días con una cuenta gratuita. Estoy seguro de que hay otros servidores de nube que ofrecen características similares. Es un poco como usar una versión súper limitada de git que maneja muy bien los archivos binarios y no tiene dolor de cabeza. Esto tiene la ventaja de que no abarrota la carpeta con toneladas de archivos y tiene una copia de seguridad al mismo tiempo.

La mayoría de los proveedores de alojamiento en la nube también ofrecen Membresías de equipo para que pueda trabajar con varios editores. O comparte la carpeta del proyecto con otros miembros del equipo.


¿Dropbox almacena revisiones de archivos para siempre? Entonces, ¿qué pasaría si tuviera un archivo de video de 5 GB con 800 revisiones?
Pacerier

Edité la respuesta un poco. Con la antigua opción de paquete de ratas, era realmente para siempre, ahora es un año, y sí, puedes hacer lo que acabas de describir, pero como escribí en mi respuesta, no incluyas archivos fuente (por ejemplo, video / imagen / audio), solo archivos de proyecto A menos que tenga una conexión gigabit que sería muy poco práctico para mantener versiones de fuente cambiante o archivos de renderizado.
PTS

1
Solo necesita su VCS para comprender los formatos si necesita diferencias. Eso es mucho esperar.
Peter Cordes

1
Por lo tanto, puede controlar fácilmente la versión de sus archivos de proyecto, ya que 10-20MB de datos binarios no son un problema para git. Solo necesita escribir mensajes de confirmación útiles para describir en qué estado estaba su archivo guardado cuando lo confirmó. Si tiene suerte, los pequeños cambios de edición a menudo no cambian la mayoría de los bits en el archivo del proyecto, y la compresión delta de git usará mucho menos que los 10 MB completos para cada confirmación. Y luego las copias de seguridad son tan fáciles como git pushpara su servidor de copias de seguridad. (con algún otro método para realizar un seguimiento de qué maestros de video van con qué proyecto, ¿quizás md5sums de los archivos fuente?)
Peter Cordes

Bueno, ese es el caso ideal, si su proyecto termina con un archivo de proyecto más grande, simplemente no puede cargar revisiones con tanta frecuencia dependiendo de su conexión. Un software de almacenamiento en la nube escala perfectamente, git eventualmente se encontrará con problemas. Sin embargo, los mensajes de confirmación son definitivamente una ventaja para git.
PTS

6

Solo para agregar a las respuestas anteriores: si bien no hay nada como Git para el mundo del video, existen herramientas de Administración de activos digitales / Administración de activos de medios que pueden hacer más o menos lo mismo: control de versiones y permisos / administración de usuarios (también lo hacen mucho más, ya que realmente están construidos como bibliotecas para sus medios). Durante años, utilicé la aplicación Final Cut Server de Apple (ahora obsoleta) que se integró con Final Cut Suite (Final Cut Pro 7, Soundtrack Pro, etc.) en una pequeña instalación de correos.

Lo usamos para el control de versiones y la ramificación en los archivos del proyecto, lo que permitió que varios editores trabajen en un solo proyecto de manera relativamente fluida. Debido a que este era un producto de Apple, fue diseñado para usarse con Final Cut Pro y, por lo tanto, podía leer y trabajar con archivos de proyecto FCP con mucha facilidad. Incluso dado esto, el control de versión de Final Cut Server se basó en guardar versiones anteriores de todo el archivo del proyecto, no usó diffs. No conozco ningún DAM que lo haga por la misma razón que una respuesta anterior ya señaló: hay demasiados formatos propietarios (aunque, irónicamente, muchos de ellos ahora confían en XML como la columna vertebral para esos formatos de archivo de proyecto )

FCS fue genial porque era relativamente asequible. Nunca hubo realmente nada análogo para Premiere Pro. Hoy en día, desafortunadamente, necesitarás repartir una buena parte del cambio para obtener capacidades similares, principalmente porque estas herramientas están realmente diseñadas para instalaciones de publicación, no para un solo editor. También requieren una integración / configuración potencialmente significativa.

Aquí hay algunas opciones (no tengo relaciones con ninguna de estas empresas, esto se basa únicamente en mi investigación en busca de una solución similar):


5

El control de versiones realmente no tiene tanto lugar en la edición de video porque, por naturaleza, no es destructivo. En el núcleo de cualquier NLE (editor de video no lineal), la salida es en realidad algo conocido como una Lista de decisiones de edición o EDL. Esto es extremadamente análogo al historial de Lightroom, ya que ese historial es un registro de todos los cambios que se han aplicado en orden.

Los NLE funcionan a partir de clips de origen. Toman los puntos de inicio y finalización de esos clips para colocarlos en una línea de tiempo y luego los efectos se pueden aplicar a esos activos en un orden determinado (según la ubicación de los efectos), sin embargo, todas estas son decisiones de edición y se aplican sobre la marcha ( o posiblemente presentado en archivos de vista previa temporales). El renderizado de salida final es el resultado de aplicar todo el EDL a los clips de origen.

Puede guardar una versión del proyecto para poder volver a una versión anterior de la EDL si lo desea, pero esto generalmente no es necesario a menos que esté bifurcando intencionalmente para intentar un enfoque alternativo para editar una secuencia ( en cuyo caso, una copia de esa línea de tiempo suele ser una mejor opción de todos modos).


¿Qué quieres decir con "no destructivo" y NLE aquí?
Pacerier

Un NLE es un editor no lineal (nombre técnico para la mayoría del software de edición de video). No destructivo significa que los cambios no resultan en la destrucción de los activos. Está formando una lista de cambios para hacer, que es básicamente lo mismo que hace el control de versiones. Cuando realiza cambios en el código, eso es destructivo porque sus nuevas alteraciones destruyen la anterior. Con un NLE, todos sus activos permanecen inalterados y solo está modificando una lista de secciones para usar y filtros para aplicar.
AJ Henderson

Entonces, ¿quiere decir que podemos decirle al programa de edición de video "volver a la versión 2.5", editar un poco, luego decirle "volver a la versión 7" y es capaz de hacerlo?
Pacerier

1
No, quiere decir que siempre tienes tu video maestro. La suposición es que reproducir los efectos / cortes que tenía anteriormente no es difícil, o que guardar archivos de proyectos con un VCS sería más trabajo que simplemente volver a ingresar las decisiones de edición. Si ese no es el caso, entonces seguro, la versión controla los archivos de su proyecto. Aunque sin la capacidad de fusionar cambios de diferentes ramas, probablemente sea más útil simplemente escribir los números de fotograma exactos que le tomó mucho tiempo descubrir que era el lugar correcto para un corte, o algo así.
Peter Cordes

3

Si lo habilita en las preferencias, After Effects y Premiere realizan automáticamente guardados incrementales de los archivos del proyecto. preferencias de autoguardado

Estos guardados incrementales podrían usarse para volver a versiones anteriores, que es como una implementación muy básica del control de versiones (aunque es posible que desee aumentar el número de versiones de 5). FCP tiene una función de "restaurar desde la versión anterior" incorporada, que es buena para cuando manipula los archivos de su proyecto. Después de los efectos tiene (pero Premiere no tiene, vaya) la capacidad de guardar un proyecto de forma incremental. Lo uso todo el tiempo cuando hago grandes cambios en un proyecto y quiero poder volver al tronco principal, por así decirlo.

Para un mayor control, me imagino que podría usar el software de control de versiones para administrar las carpetas donde guarda sus archivos de proyecto y guardar automáticamente, para que los editores revisen los cambios actuales y confirmen los cambios, siempre y cuando todos los medios estén centralmente accesibles o copiados en las máquinas de todos en el mismo camino relativo. No le permitiría bifurcar y fusionar las ediciones de otras personas, como puede hacerlo con el código; esa sería una característica interesante (diría que podría implementarse con la secuencia de comandos extendcript de Adobe, siempre y cuando sus habilidades estén listas para volver a escribir Git o SVN en Javascript).


1
sí, para diferenciar y fusionar, su VCS debe comprender los archivos guardados de su NLE o el NLE debe proporcionar diff / merge. (Por ejemplo, dado un programa que puede combinar cambios en un archivo de proyecto, dado un antepasado común, creo que podría configurar git para usarlo git mergetool, para poder fusionar confirmaciones de árboles que contienen archivos de proyecto modificados).
Peter Cordes

Posiblemente podría usar extendcript para 'guardar' su proyecto actual al obtener todas las propiedades de todos los elementos de su proyecto y guardar los datos en un archivo. Pero incluso para un proyecto moderadamente grande que podría llevar mucho tiempo. Si hiciera eso, posiblemente podría construir un sistema de control de versiones.
stib

3

Como profesional de video a largo plazo, puedo dar fe del hecho de que la necesidad de una forma ligera, robusta, transparente y abierta de un VCS es muy escasa en la mayoría de los flujos de trabajo de medios. Sin embargo, el problema es multifacético y es tanto cultural como técnico.

Tradicionalmente, hemos estado trabajando en una fábrica de salchichas de la misma manera en que un proyecto recibe luz verde del guión, pasa a la producción, una vez envuelto, pasa a la postproducción y luego se entrega una salida final al brazo de distribución, que luego entrega las salidas del dispositivo / plataforma .

Hoy en día, este enfoque de fábrica es una ilusión en la que la transferencia entre la postproducción y la distribución específicamente nunca es clara. Hay muchos cambios de ida y vuelta con cortes / ediciones para diferentes idiomas / mercados sin importar volver y masterizar para el último formato, por ejemplo. Luego está la necesidad de acceder a las versiones finales con fines de marketing ... Como resultado, la necesidad no solo de partes remotas sino de personas que tal vez nunca se reúnan para tener una comprensión catalogada y definitiva de en qué versión deben trabajar es clave. Esto se extiende no solo a las codificaciones maestras sino a todas las versiones de ese maestro para diferentes mercados, así como a las versiones de los activos que se usaron para crear cada maestro.

Solo ahora la comunidad de tecnología de medios está participando en lo que realmente es una versión y se debate regularmente debido a la gran cantidad de diferentes flujos de trabajo y preocupaciones. Lo desgloso como una versión funcional y una versión de distribución. Hay esfuerzos para remediar esto dentro de la distribución creando un formato de archivo que rastree versiones dentro de sí mismo (para combatir el hecho de que hay múltiples herramientas, plataformas, etc.), esto se llama el formato maestro interoperable (FMI) que no debe confundirse con el banco) y está siendo dirigido a través de SMPTE. Lo bueno de esto es que se está moviendo para proporcionar interoperabilidad entre la miríada de sistemas de administración de activos digitales (aquellos que quieren respaldarlo) que existen: algunos estudios que conozco tienen sistemas de administración de activos que suman cientos. ayúdelos internamente y mucho menos para transferencias externas. Por supuesto, no se ha utilizado dentro de un entorno de producción, ya que está diseñado como un formato de nivel de archivo (Netflix ahora lo utiliza). También es un archivo muy pesado sin una forma fácil de crearlo, a menos que tenga el capital necesario para invertir en las herramientas. Netflix lanzó un conjunto de herramientas de código abierto que proporciona capacidad de lectura, lo cual es bueno. También es un archivo muy pesado sin una forma fácil de crearlo, a menos que tenga el capital necesario para invertir en las herramientas. Netflix lanzó un conjunto de herramientas de código abierto que proporciona capacidad de lectura, lo cual es bueno. También es un archivo muy pesado sin una forma fácil de crearlo, a menos que tenga el capital necesario para invertir en las herramientas. Netflix lanzó un conjunto de herramientas de código abierto que proporciona capacidad de lectura, lo cual es bueno.

En cuanto a la versión de trabajo o al nivel de producción, creo que es necesario proporcionar un VCS (tal vez una forma modificada de git) que cualquiera pueda utilizar sin importar cuán grande o pequeño sea para facilitar el trabajo remoto. Los archivos multimedia son, por supuesto, mucho más grandes que el intercambio de código o bibliotecas, pero las decisiones tomadas sobre esos archivos son el componente clave. Por mi parte, me gustaría probar trabajar de forma remota a través de git commits solo para evitar las convenciones de nomenclatura de las convenciones de nomenclatura 'file_Final_FINAL_MASTER_version3.mxf' que se intercambian de un lado a otro.


2

Tenía la misma pregunta, también era ingeniero de software de profesión, pensando en el trabajo de Photoshop.

¿podemos decirle al programa de edición de video "volver a la versión 2.5", editar un poco, luego decirle "volver a la versión 7" y puede hacerlo?

Descubrí que Photoshop me permite establecer una versión con nombre en el historial, y creo que está guardada en el archivo ... Para las revisiones (entradas en la lista del historial) que no tienen nombre, los nodos se pierden de la pantalla cuando se realiza una edición en un lugar anterior (bifurcación) y no se expone ningún registro.

Las nuevas versiones de Premiere parecen tener un registro de historia similar y supongo que está evolucionando hacia la misma arquitectura interna, donde cada cambio es otra copia del proyecto que comparte la mayor parte del estado con el anterior. Si el historial tiene puntos de control guardados, es muy parecido a una tienda git: cada versión contiene referencias (compartidas) a elementos subyacentes en las definiciones de segmento. Como el video en sí no está en el archivo, se presta bien para crecer cada vez más versiones con poco aumento de tamaño.

Vi un seminario donde alguien en el equipo de desarrollo de Photoshop explicó la arquitectura. Parece que las entradas del historial que ve son análogas a las versiones de git, como las pantallas de gitk. Nombrar la versión es lo mismo que una etiqueta git. Puede restablecer a cualquier revisión visibles apuntando hacia él, y restablecer la espalda también. Pero hacer cualquier cambio que se ponga en el historial es como hacer una actualización completa (shift o ctrl F5): se pierde todo lo que no está encadenado desde el encabezado de la rama actual o la etiqueta con nombre (pero creo que cosas como referencias de fuentes de clones todavía apunte a la versión ahora invisible).

Pero eso no es lo que estoy escribiendo para sugerir. Configuré el volumen NAS donde reside mi proyecto para hacer una instantánea cada 3 horas. Windows tiene un mecanismo de punto de control, pero creo que no es configurable; Mac Time Machine hace algo similar.

En general, puede archivar todas las versiones guardadas del archivo y, en Premiere, que no contiene todos los activos importados (constantes), por lo que es razonable guardarlos todos, incluso sin poder utilizar deltas para guardar solo lo que cambió.

Solo volviendo a aprender Premiere y volviéndome más agresivo al probar cosas, estoy seguro de que puedo volver si la próxima vez que lo trabajo me arrepiento de lo que hice o encontré una mejor manera y quiero volver a hacerlo. Ese es un sistema de control de versiones efectivo. Al hacerlo en el NAS, también estoy protegido contra un BSOD que destruye todo el proyecto al guardar. :)

actualizar el historial es de corta duración, el valor predeterminado es de 32 entradas. Está vacío cuando se carga el proyecto. Sin embargo, el guardado automático no solo guarda sobre el mismo archivo como vemos en la mayoría de los programas; más bien los numera y los guarda. Entonces, puedo ver las marcas de tiempo del archivo y cargar una copia anterior, lo que me da un historial de versiones de puntos de control de 15 minutos. En mi caso, cada archivo es de 44K, que no es nada comparado con el tamaño del activo, es el tamaño de 76 milisegundos de audio, o 1/7 de un cuadro de material de archivo de tarjeta SD de clase 10 .

Si tiene la presencia en mente para mantener un punto de control con un nombre significativo, simplemente guarde la copia como. Pero el autoguardado, configurado en una frecuencia alta, puede usarse para volver a visitar cualquier estado (hasta ese momento, granulatidad) sin planificación previa, con poco esfuerzo.

Una nota para aquellos que no son ingenieros que no están familiarizados con el control de versiones: además de la capacidad de retroceder su trabajo de la manera obvia, a menudo también lo uso para verificar lo que acabo de cambiar, o compararlo con el estado de antes de comenzar la tarea actual , o comparar con la última versión que se ha compartido con el grupo.

Dado que Premeire ahora admite la apertura de múltiples proyectos en el espacio de trabajo, sería factible tener una configuración de espacio de trabajo de disposición de ventanas para comparar dos líneas de tiempo. Es decir, haga un uso más efectivo de tener esas versiones, no solo para copias de seguridad. A menudo les digo a los programadores que no usan git cómo se convierte en una herramienta de propósito general, como un editor de texto.

Me pregunto cómo los cineastas profesionales manejan el control de versiones, si es algo más que ad-hoc. El diseño de autoguardado parece bastante útil, y la herramienta integrada de trabajo en grupo de escritura de guiones tiene un seguimiento de revisión visible explícito.


0

No es práctico tener control de versiones para los archivos de video porque, en primer lugar, son enormes, en segundo lugar se están moviendo (¿vas a preservar cada fotograma?), En tercer lugar, son inmutables. Es decir, los archivos originales nunca cambian durante la edición.

Pero el control de versiones para archivos de proyecto tiene mucho sentido. Actualmente, después de cada cambio significativo, creo un nuevo archivo de proyecto y le doy un nombre descriptivo: qué hice, qué agregué y qué eliminé. En esencia, tengo que mantener el historial manualmente mediante nombres de archivo. Tener archivos de proyecto bajo control de versiones es una gran idea, ¡por qué no he pensado en esto antes!

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.