Cada clip llegó con un fotograma de menos
Marcas la entrada y la salida en cuarenta clips, los envías a una línea de tiempo, y el montaje se ve bien. Semanas después, alguien que comprueba las duraciones te dice que todos y cada uno tienen un fotograma menos de lo que marcaste.
Un fotograma no es nada a la vista y lo es todo para una especificación de entrega. Y es fácil que se cuele, porque el sitio donde desaparece es una sola palabra en una API que nadie lee dos veces.
Dos formas de entender «salida»
Cuando marcas un punto de salida, quieres decir una de estas dos cosas, y ambas son razonables:
- Inclusivo — el fotograma de salida forma parte del clip. Esto es lo que muestran las aplicaciones de edición. Marca de 3 s a 8 s en material a 30 fps y esperas 151 fotogramas: cinco segundos, más el fotograma en el que aterrizaste.
- Exclusivo — el fotograma de salida es donde el clip se detiene. Las mismas marcas dan 150 fotogramas.
Ninguna de las dos está mal. El problema empieza cuando una parte de tu pipeline asume una y la siguiente asume la otra, porque la diferencia es exactamente un fotograma y un fotograma es invisible.
Adónde va realmente el fotograma
La API de scripting de Resolve recibe un fotograma de inicio y uno de fin
cuando añades un clip a una línea de tiempo. El fotograma de fin es
exclusivo: la duración que obtienes es endFrame - startFrame.
Así que si mantienes tu punto de salida como inclusivo — tal como la interfaz se lo presentó a la persona que lo marcó — y le pasas ese número directamente a la API, cada clip llega un fotograma corto. No el primero. No los complicados. Todos, en silencio, para siempre.
La solución es una línea: pasar outPoint + 1. Lo
difícil es saber que hace falta.
Hay un segundo caso límite que vale la pena conocer. Si el rango colapsa de forma que el fotograma de fin es igual al de inicio, la llamada de append devuelve false y el clip sencillamente no llega. Un rango de longitud cero tiene que fijarse en un mínimo de un fotograma antes de salir.
Por qué sobrevive a las pruebas
Los rangos salen de una app de material por más de una puerta, y las puertas
no están de acuerdo entre sí. Una API de línea de tiempo, un EDL, una
exportación de medios, un ALE — en los sistemas con los que he trabajado, son
cuatro conversiones distintas, y no todas siguen la misma convención. El EDL
y el ALE tratan el final como exclusivo. Una exportación que calcula la
duración como out - in también es exclusiva. Solo la interfaz en
la que la persona marcó de verdad era inclusiva.
Eso son cuatro oportunidades de convertir, y basta con que un solo lugar lo haga dos veces, o que un solo lugar no lo haga en absoluto, para mover un fotograma. La regla que lo mantiene manejable es guardar una única convención internamente y convertir exactamente una vez en cada salida — nunca a mitad de camino.
Cómo comprobar el tuyo
Esto no se puede comprobar a ojo. Tienes que cortar algo y contar lo que sale. Marca un rango con el que puedas hacer aritmética — 3.0 s a 8.0 s en material a 30 fps —, envíalo, y lee la duración en la línea de tiempo. Inclusivo da 151 fotogramas. Exclusivo da 150.
Ajusta la frecuencia de fotogramas de la línea de tiempo a la del clip antes de contar. Esta parte me costó una tarde entera. Pon material a 30 fps en una línea de tiempo a 24 fps y esos 151 fotogramas se convierten en 120 — el fotograma de más se redondea junto con varios otros, y la comprobación deja de serlo sin que te des cuenta. El punto de entrada se queda donde lo pusiste, así que nada parece estar mal.
Hay dos cosas más que evitaría. No hagas la aritmética en segundos: un valor que debería ser 121 fotogramas puede llegar como 5.041666…, y la conversión de vuelta a fotogramas lo trunca a 120. Trabaja en fotogramas enteros. Y no verifiques con la llamada de la API que devuelve el fotograma de fin de origen de un clip — en mis pruebas, su punto de referencia no era consistente entre elementos de la misma línea de tiempo, así que no puede zanjar una discusión sobre un solo fotograma. Lee en su lugar el offset y la duración.
Qué hace Divecut
Divecut mantiene los puntos de salida como inclusivos, porque eso es lo que
quiere decir la persona que los marca, y convierte una vez en cada salida.
Para el traspaso a Resolve eso significa endFrame = outPoint + 1,
con un mínimo de un fotograma para que un rango colapsado siga llegando.
Lo comprobé de la forma descrita arriba en vez de confiar en el código: 3.0 s a 8.0 s en material a 30 fps llegan como 151 fotogramas en una línea de tiempo con la misma frecuencia. Esa medición es la razón de que este artículo exista — encontré el desajuste leyendo los dos caminos uno junto al otro, antes de cortar ningún material, y el conteo es lo que confirmó la corrección.
Los clips llegan como Log, intactos, con la conversión aplicada como información de la línea de tiempo en lugar de grabada en la imagen. Eso es otro artículo.
Divecut es un navegador de material para macOS y iPad. Muestra los clips Log en el color con el que los grabaste, te deja buscarlos con palabras normales, y entrega tus seleccionados a DaVinci Resolve con el Log intacto — rangos incluidos. Ver todo lo que hace.