Una introducción rápida:
la televisión estadounidense se transmitía originalmente a 30 fotogramas por segundo. Para acomodar la información de color sin perder la compatibilidad con versiones anteriores de los televisores en blanco y negro, la velocidad de fotogramas se redujo en un factor de 1000/1001, a aproximadamente 29,97 FPS.
El metraje de 29,97 todavía estaba etiquetado como 30 FPS; sin embargo, la diferencia en la velocidad de fotogramas provocó que el código de tiempo se desviara un minuto y medio por día, lo que provocó problemas de sincronización para las emisoras. Para contrarrestar esto, se desarrolló el código de tiempo "dropframe". A 30 FPS, hay 18000 cuadros por diez minutos; a las 29.97 exactamente , hay 17982 fotogramas por diez minutos. Para tener en cuenta la diferencia de dieciocho fotogramas, "saltamos" dos fotogramas en cada minuto que no sea divisible por 10. Por ejemplo:
30 FPS
00:00:59:29 + 1 frame = 00:01:00:00
00:04:59:29 + 1 frame = 00:05:00:00
00:09:59:29 + 1 frame = 00:10:00:00
29.97 FPS, dropframe
00:00:59;29 + 1 frame = 00:01:00;02
00:04:59;29 + 1 frame = 00:05:00;02
00:09:59;29 + 1 frame = 00:10:00;00
La pregunta:
las matemáticas dan exactamente 29,97, pero la velocidad de fotogramas es un poco más rápida: 30*(1000/1001) da como resultado 29,97002997002... La diferencia es insignificante para una sola pieza de metraje; el error aquí solo funciona alrededor de dos cuadros y medio por veinticuatro horas. Pero , ¿cómo un generador maestro de sincronización da cuenta de estos fotogramas adicionales? No existe un esquema de etiquetado para ellos, y la medianoche no ocurrirá en un marco limpio.
Según el Libro de referencia del ingeniero de radiodifusión , p. 203
Esta corrección hará coincidir el tiempo de DF con el tiempo real dentro de aproximadamente 2,6 fotogramas por día; para eliminar el error residual, el generador de código de tiempo se puede restablecer cada medianoche.
Entonces, aparentemente nada.
En cuanto a los marcos "extra", dice Charles Poynton ,
Si se va a mantener una secuencia de código de tiempo durante más de 24 horas, el código de tiempo debe bloquearse diariamente para hacer referencia a la hora del reloj en un momento inocuo. Ningún estándar recomienda cuándo esto debe ocurrir; sin embargo, la técnica habitual es insertar números de código de tiempo duplicados 00:00:00;00 y 00:00:00;01. El equipo de edición trata los códigos duplicados como una interrupción del código de tiempo.
La información hasta el momento: está adquiriendo contenido de video continuamente a exactamente 29.97 sin interrupciones nunca, para siempre. Además, A) cada cuadro de video debe tener una etiqueta única y B) estas etiquetas siempre deben coincidir exactamente con la hora real del día, dentro de un pequeño épsilon que promedia cero.
Dadas esas condiciones, no existe una solución utilizando solo la sincronización de video estándar y el código de tiempo. Debes comprometer/personalizar algo.
Algunas posibilidades son:
1 - Resincronice TC a TOD en cada pausa en la grabación. Sé que asumimos que no hay pausas, pero ningún medio de grabación tiene una duración infinita. Podrían ser posibles pausas programadas o puntos de resincronización.
2 - Jam el TCG a TOD cada "n" horas y vivir con las consecuencias.
3 - Almacene tanto el TOD exacto en mSec como el TC (o el delta acumulado) en el CMS, y utilícelos en la recuperación de un marco dado. Combine esto con un reinicio a 0 siempre que sea posible.
4 - Utilice los bits de usuario del TC para codificar el TOD exacto en mSec, en lugar de almacenarlo en la base de datos de CMS. Sin embargo, el delta no sobrevivirá al doblaje/edición.
5 - De forma similar a lo que sugiere @Mulvya, personalice la generación de TC para que no se eliminen tres etiquetas de fotogramas normalmente omitidas cada día. Eso cambiaría la deriva de -2,589 fotogramas/día a +0,411 fr/día. Esto se puede corregir aún más omitiendo una de las no caídas cada 2 días, haciendo que el término de error promedio sea de -0.02 fr/día, etc. Puede continuar esto con la precisión que desee. Esto solo es posible si su TC no tiene que usarse fuera de su propio contexto. Los sistemas "normales" de edición, etc. no lo entenderán.
Gian