Los ticks del archivo .prproj de Premiere se desvían 1/1000 en comparación con los códigos de tiempo

Soy programador y estoy procesando .prprojarchivos de Adobe Premiere. Leo los datos XML contenidos para averiguar dónde <Media>comienza el archivo de video de un elemento.

Tengo un video que se grabó con un código de tiempo que comienza a las 10:00:00:00, es decir, exactamente 10 horas o 36000 segundos. Ese código de tiempo es lo que muestra Premiere para el inicio del archivo.

Los datos correspondientes en el archivo del proyecto son:

<Media ...>
    ...
    <Start>9153720576000000</Start>
</Media>

Ese valor usa ticks como unidad.

Ahora, asumo que un segundo equivale a 254016000000 tics. Eso es porque, cuando tengo, por ejemplo, una secuencia con 25 FPS, su elemento FrameRate en el XML especifica 10160640000 tics, y eso es exactamente una 25ª parte de un segundo.

Pero cuando divido el <Start>valor 9153720576000000 por 254016000000, obtengo 36036 segundos y no, como se esperaba, 36000 segundos.

Entonces, al leer los valores XML, aprendo que el video comienza a las 10:00:36:00.

Curiosamente, esa diferencia es exactamente la relación 1001/1000 de la sincronización de fotogramas eliminados de NTSC, ¿verdad?

Ahora, ¿cómo doy sentido a los datos en el archivo de proyecto de Premiere? Por un lado, su base de ticks de 254016000000 está identificando precisamente las frecuencias de cuadro utilizadas en el mismo archivo, por lo que debe ser el valor correcto para los ticks por segundo . OTOH, está apagado para códigos de tiempo por 1 ms por segundo.

¿Cómo debo interpretar los valores de ticks en el archivo? ¿Debería ajustarlos todos por un factor de 1.001 para obtener el código de tiempo real, o dónde está mi error en todo esto?

¿O es un hecho conocido que los códigos de tiempo no se basan en segundos reales sino en 1.001 segundos?

En otras palabras, ¿10:00:00:00 significa que en realidad comienza en 36036 segundos?

Actualizar

Parece que sí hay una deriva con los códigos de tiempo frente al tiempo real, pero solo si la grabación utiliza FPS fraccionarios como 29,97 o 23,976 (= 23,98), según este artículo .

Y, de hecho, el archivo multimedia en cuestión se grabó a 23,98 FPS.

Entonces, ¿estoy en lo cierto al suponer que cada vez que interpreto un código de tiempo, también necesito mirar el FPS involucrado, y si es fraccionario, tengo que agregar 1 ms por segundo al tiempo calculado para ser más preciso a largo plazo? ? (No me importa la precisión de un solo cuadro, por lo que no importa cuándo aplico la corrección de deriva, es solo una cuestión de cuándo aplicarla).

Respuestas (1)

Primero, permítanme decir que no tengo idea de qué está haciendo Premiere con sus valores o qué significa un 'tic' en sus términos. Sólo puedo hablar en general.

La velocidad de fotogramas del video debe coincidir con la velocidad del código de tiempo, pero para los códigos de tiempo de 'caída de fotogramas', la relación no es perfectamente lineal. Hay ciertos números de código de tiempo que nunca aparecen en la secuencia, los que se 'caen'. Entonces, para tales códigos, no puede simplemente realizar un cálculo simple, debe considerar las gotas.

En el transcurso de 1 hora hay 108000 fotogramas a 30 fps, pero el código de eliminación de fotogramas producirá solo 107892 números únicos. Ambos relojes coincidirán en que "la hora" es la 1:00:00:00.

Si solo está utilizando códigos de tiempo para etiquetar cada cuadro con un número único, cualquier esquema servirá. Si necesita hacer coincidir la hora del día, debe tener en cuenta los números caídos. ¿Qué necesitas hacer con tus valores?

Debería haber notado que la hora de inicio de 10 horas no es una duración, solo un marcador, por lo que se trata como una constante o una compensación. El video no comenzó en 36036 segundos, comenzó en 0 segundos. El primer cuadro tiene la etiqueta 10:00:00:00, pero eso es todo, los TC son: etiquetas.
Lo que estoy tratando de hacer es esto: encuentro marcadores de comentarios en el proyecto de Premiere y luego ubico los clips de video correspondientes. Luego, tengo que averiguar qué tan lejos en el clip está establecido este marcador, y usar ese desplazamiento para extraer una captura de pantalla del video con un programa diferente (por ejemplo, ffmpeg). Para un video que comienza a las 10 h, Premiere XML me dice que son 36036 segundos. Utilizo ese valor en el cálculo de desplazamiento de mi marcador y termino 36 s demasiado temprano en el archivo de video. Con un video de 24 fps no tengo este problema. Probablemente debería proporcionar más datos en mi pregunta.
@ThomasTempelmann: lo siento, no sé cómo Premiere anota las duraciones internas, etc. porque esto debería ser fácil de resolver con esa información. Probablemente necesite identificar cuándo un video está codificado a una velocidad de fotogramas no entera y aplicar la corrección DF (1000/1001), pero el problema está en los detalles. Si pudiera proporcionar ejemplos de todos los valores constantes que puede extraer de un conjunto de metadatos de 30 fps y 29.97 ('ticks', etc.), luego también algunos valores de duración de cada uno y los códigos que indican, estoy seguro de que podemos desentrañar la información
Ahora me di cuenta de que omití información importante, y esa también es la solución a mi problema: el problema se debe a que también leí una EDL creada por Premiere, y a esa EDL le falta la información si un clip es DF o NDF. Entonces, cuando me dice que el clip de 23.976 FPS comienza a las 10:00:00:00 y el archivo de proyecto de Premiere dice que es a las 10:00:36:00, tengo una discrepancia. Estaba buscando una solución en el lugar equivocado. La solución es ignorar la EDL por completo, entonces no hay problema.