Qué dice de verdad un punto y coma en el código de tiempo
Cuando el último tramo de un código de tiempo pasa de dos puntos a punto y coma, normalmente está avisando de que «esa cadena se muestra con notación de salto de fotogramas». Lo que aborda es el desvío de largo recorrido entre el conteo de fotogramas y el reloj humano en ciertas tasas de fotogramas fraccionarias. Pero al recibir un archivo de entrega, el punto y coma solo sirve como aviso, y por sí solo no prueba que la posición de fotogramas ya se haya convertido con la regla de salto de fotogramas. La notación de visualización y el algoritmo de conteo hay que comprobarlos por separado.
El punto y coma dice «esta cadena quiere expresar la escritura con salto de fotogramas»; no dice automáticamente «esta posición de fotogramas ya está calculada con la regla de salto».
Por qué existe un conteo con salto de fotogramas
Una tasa de fotogramas fraccionaria como 29.97 no avanza al mismo ritmo que una numeración de código de tiempo construida sobre el entero 30. Si se muestra una secuencia continua de números enteros de fotograma sin ninguna compensación, la lectura del código de tiempo se va quedando atrás respecto al reloj de pared.
Calculando con la fórmula, un conteo continuo como 29.97 acumula cada día un desvío del orden de un minuto y medio. Por eso el conteo con salto de fotogramas no elimina fotogramas de vídeo reales: omite ciertos números dentro de la numeración del código de tiempo según una regla, para volver a acercar el reloj mostrado al tiempo realmente transcurrido.
La convención de texto habitual escribe el separador del último tramo como punto y coma, por ejemplo 01:00:00;00. Ese símbolo resulta útil porque permite al receptor reconocer de un vistazo que el archivo está expresando una notación de salto de fotogramas. Pero el símbolo sigue siendo una parte de la cadena.
La notación visible y la conversión de la posición de fotogramas son dos cosas
El cálculo real del salto de fotogramas exige ejecutar la regla de omisión al convertir entre el número de fotograma y los campos de hora, minuto, segundo y fotograma. Cambiar simplemente el último : por un ; solo altera la apariencia, y no modifica la posición de fotogramas que expresaban aquellos números.
En los archivos de entrega de SlateX, esas dos convenciones ocupan celdas distintas. Sobre una cadena de punto de entrada o de salida que ya está registrada hay dos caminos: una lectura captada por la cadena de grabación en el momento del cierre se reescribe como una dirección drop-frame válida, porque cambiar solo el separador produciría valores como ;00 o ;01 que SMPTE no define; una lectura transcrita de la pantalla de la cámara o de un panel queda dígito a dígito intacta, y solo se cambia el separador del último tramo por punto y coma. Cuando la fuente no está declarada no se adivina: los dígitos no se tocan y la tabla Reconcile del cierre nombra la declaración que falta como TC_SOURCE_UNDECLARED. Duration es la diferencia exacta en fotogramas entre las dos lecturas, sin contar el fotograma final; en las filas que declaran DF, esa celda se escribe en forma de punto y coma.
Ahí está la frontera dura de este artículo: al ver un ; puede saberse que la capa de entrega ha marcado esa cadena como escritura con salto de fotogramas; pero solo con ese símbolo no puede juzgarse si esos números se obtuvieron antes aplicando la regla de salto.
Un valor cercano a 29.97 no declara salto de fotogramas
Una tasa de fotogramas cercana a 29.97 no basta, por sí sola, para afirmar que toda la cadena usa una misma convención de conteo. Los valores en el borde merecen especial cuidado: lo que muestra la pantalla y lo que escribe el archivo de entrega pueden caer en clasificaciones distintas. Lo que sí puede comprobarse es qué dice al final esa celda del archivo, y si el FPS real de la fila, la cadena de código de tiempo y el material encajan entre sí.
Lo que el receptor tiene que verificar es cómo encaja un material real con su código de tiempo, no solo qué forma tiene el separador.
La visualización en tiempo real de la aplicación y el archivo de entrega no son la misma representación
El código de tiempo en vivo que se muestra en pantalla es una cadena con todos los separadores de dos puntos, sin punto y coma. Por eso, lo que aparece en vivo en la app y lo que puede aparecer después en un archivo de entrega siguen reglas de representación distintas.
Que más tarde aparezca un punto y coma en un archivo de entrega no permite deducir que la visualización en vivo ya siguiera la misma regla de conteo.
Al recibir hay que mantener separadas esas dos capas: qué cadena se leyó en pantalla, qué cadena escribe el archivo de entrega, si en una cadena existente solo se sustituyó el separador y si las posiciones finales del material encajan de verdad. Si falta una de esas comprobaciones, el punto y coma no basta como conclusión de aceptación.
Cómo comprobar de verdad un código de tiempo con punto y coma
Mire primero si el FPS de esa fila coincide con el material y con el registro del rodaje, elija después un material localizable y compare su punto de entrada real con el tiempo transcurrido. La salida es una lectura transcrita, así que en esa celda lo que se comprueba es «si fue transcrita o no»; la diferencia calculada es Duration, y comprobarla obliga a volver a las dos lecturas de inicio y fin y a la regla de conteo con la que se leyeron.
Si el punto de entrada o de salida es una cadena que ya existía, no basta con mirar si lleva punto y coma. El receptor debe verificar que la posición de fotogramas encaja con el material. Una cadena a la que solo se le ha cambiado el símbolo puede parecer visualmente un código de tiempo con salto perfectamente correcto, y que sus números sigan viniendo de otro modo de conteo.
Por eso el punto y coma encaja como aviso de «aquí hay que comprobar el criterio de salto de fotogramas», y no como etiqueta de «esta cadena ya está verificada».
FAQ
¿Si el último tramo del código de tiempo lleva punto y coma, puede confirmarse que se calculó con la regla de salto?
No. El punto y coma puede ser solo un símbolo de la capa de visualización. En el camino de entrega actual, una cadena de código de tiempo ya existente puede recibir únicamente la sustitución del separador del último tramo, sin recalcular la posición de fotogramas.
¿El salto de fotogramas elimina fotogramas de vídeo reales?
No en el sentido del que aquí se trata. El conteo con salto ajusta la regla de numeración del código de tiempo, para compensar en tasas fraccionarias el desvío de largo recorrido entre la numeración continua y el reloj de pared.
¿Por qué un mismo valor de tasa de fotogramas puede caer de forma distinta?
La pantalla y el archivo de entrega pertenecen a dos fases distintas, así que un valor en el borde puede caer de manera diferente. Compruebe el archivo y el material reales, y lea qué dice al final esa celda.
¿El código de tiempo en tiempo real de la pantalla de la aplicación también usa punto y coma?
Hoy la cadena en tiempo real emite cadenas con todos los dos puntos y no produce ninguna representación con punto y coma. El punto y coma de un archivo de entrega pertenece a otra fase de la representación, y no permite deducir a la inversa que el camino en tiempo real use el mismo conteo con salto.
Axiom One LLC — SlateX