Referencia horaria en televisión
Ing. J. Daniel Rodríguez Vega¿Qué hora es?
Una pregunta cuya respuesta parece sencilla. Rara
vez nos preguntamos – “¿cómo se determina la hora
correcta? ¿Quién la determina? ¿Es exacta? ¿Es real?”
Para saber la hora simplemente preguntamos o consultamos cualquier dispositivo que nos proporcione dicha información. Actualmente esto es algo muy trivial. Más aun, normalmente y para los fines prácticos cotidianos, no es necesario contar con una referencia horaria demasiado exacta y precisa.
En la industria de la televisión el establecimiento de la hora correcta no es una tarea trivial. Los sistemas de automatización requieren de una referencia exacta para su operación confiable. Si bien actualmente resulta relativamente sencillo y barato el establecer una referencia horaria maestra, el desconocimiento de la relación que existe entre el tiempo y la tasa de transmisión de cuadros de video puede provocar confusiones y problemas inesperados en los sistemas de automatización, o en cualquier otro sistema sensible al tiempo.
La hora correcta
La determinación de la hora correcta involucra a varios organismos y sistemas. Debemos comenzar por identificar cada uno de ellos, entendiendo su función específica dentro de lo que denominaremos aquí como
sistema global (figura 1).
Tiempo Universal Coordinado (UTC –
temps universel coordonné
)Es una escala de tiempo atómico que se aproxima al Tiempo Universal (UT1). Es el estándar internacional en el que se basa la hora civil. Marca los segundos tal y como éstos se definen por el Sistema Internacional de Unidades (SI). La marcación de los segundos se hace en sincronía con el Tiempo Atómico Internacional (TAI).
El Tiempo Universal Coordinado usualmente consta de 86,400 segundos por día, pero se mantiene dentro de
un margen de ±0.9 segundos con respecto al UT1, mediante la introducción ocasional de segundos bisiestos.
A la diferencia entre el tiempo UT1 y el UTC se le conoce como DUT1:
DUT1 = UT1 – UTC
Y el DUT1 se mantiene en el intervalo:
−0.9 s < DUT1 < 0.9 s
Tiempo Universal versión 1 (UT1 –
Universal Time 1
)Es la forma principal del Tiempo Universal (UT – Universal Time), siendo éste un estándar de tiempo basado en
la rotación de la Tierra.
Conceptualmente, es el tiempo solar medio en la longitud 0° de la Tierra. Sin embargo, las mediciones precisas con respecto al sol son difíciles de realizar. Por tal motivo el tiempo solar medio se calcula a partir de:
1) Observaciones de cuasares distantes.
2) Mediciones a base de rayo láser hacia la Luna y hacia algunos satélites artificiales.
3) La determinación de las órbitas de los satélites GPS.
El horario UT1 es el mismo en cualquier punto del planeta, y es proporcional al ángulo de rotación de la Tierra con respecto a cuasares distantes, tomándose en consideración el Marco de Referencia Celeste
Internacional (ICRF – International Celestial Reference Frame). Las observaciones permiten determinar el ángulo
de la Tierra con respecto al ICRF, al cual se le llama “Ángulo de Rotación de la Tierra” (ERA – Earth Rotation
Angle).
Dado que el Tiempo Universal es síncrono con la noche y con el día, y dado que los estándares basados en frecuencias atómicas se alejan continuamente del Tiempo Universal, es necesario introducir una corrección (llamada segundo bisiesto) en los horarios atómicos. De este modo se obtiene una forma de horario civil que exhibe una precisión atómica. Es por esta razón que los estándares civiles para tiempo y frecuencia usualmente siguen de cerca el Tiempo Atómico Internacional (TAI), pero ocasionalmente se introducen correcciones para evitar una gran discrepancia entre dichos horarios civiles y el tiempo solar medio.
Tiempo Atómico Internacional (TAI –
Temps atomique international
)Es un estándar de tiempo atómico coordinado de muy alta precisión, basado en el transcurso hipotético del tiempo propio en el geoide terrestre.
El concepto de tiempo propio es necesario en las teorías de la relatividad de Albert Einstein, para describir efectos tales como la dilatación del tiempo.
En las teorías de la relatividad, el tiempo propio es el tiempo transcurrido entre dos eventos, tal y como dicho
tiempo es medido por un reloj que pasa a través de los dos eventos. El tiempo propio depende no solo de los
comparación con el tiempo propio que mediría otro reloj que no es acelerado (inercial), pasando ambos relojes a través de los mismos dos eventos.
El TAI se emplea como base para definir tanto el UTC (usado como horario civil en toda la superficie de la Tierra), como el Tiempo Terrestre (empleado en cálculos astronómicos).
El TAI fue sincronizado con el Tiempo Universal al comienzo del año 1958, y desde entonces ambos horarios han ido divergiendo de manera paulatina, debido a la rotación no uniforme de la Tierra.
Desde el 30 de junio de 2012, cuando fue añadido el último segundo bisiesto, el TAI ha estado adelantado con respecto al UTC por exactamente 35 segundos. Esta discrepancia es el resultado de la diferencia inicial de 10 segundos, registrada al comienzo del año 1972, más 25 segundos bisiestos en el UTC acumulados desde 1972. Se añadirá al UTC un segundo bisiesto adicional al final de junio de 2015, fecha a partir de la cual el TAI estará adelantado por 36 segundos.
Tiempo del Sistema Global de Posicionamiento (GPS Time –
Global Positioning System Time
)Es una escala de tiempo implementada por los relojes atómicos ubicados tanto en las estaciones terrenas de control como a bordo de los satélites GPS. El tiempo GPS se sincronizó con el UTC a las 00:00:00 horas del 6 de enero de 1980. Desde entonces, y debido a que el tiempo GPS no es compensado para corresponder con la rotación de la tierra, ambos horarios han ido divergiendo de manera paulatina. La falta de correcciones se traduce en una discrepancia constante entre los tiempos GPS y TAI, que es igual a 19 segundos:
TAI – GPS = 19 segundos
Los relojes a bordo de los satélites son corregidos periódicamente para mantenerlos sincronizados con los relojes de las estaciones terrenas. La señal horaria GPS incluye información que indica la diferencia entre el tiempo GPS y el UTC. De esta manera, el receptor GPS toma en cuenta esta discrepancia y realiza una corrección, obteniendo así la hora correcta y los valores de compensación correspondientes a husos horarios específicos.
Husos horarios (
Time Zone
)Un huso horario es una región que tiene definido un tiempo estándar uniforme para fines legales, comerciales y sociales.
La mayoría de los husos horarios en tierra son definidos a partir del UTC, mediante un número entero de horas de diferencia, desde el UTC–12 hasta el UTC+14. Algunos otros husos se definen mediante diferencias de 30 o 45 minutos.
Horario de Verano (DST –
Daylight Saving Time
)La figura 1 muestra un diagrama que ilustra y resume la relación entre los diversos sistemas que definen la hora
correcta, llamada a veces también tiempo real.
Figura 1. Sistema global: relación entre las diversas entidades que definen la hora correcta.
Referencia horaria en televisión
La referencia horaria en televisión se proporciona mediante un sistema maestro de reloj, el cual por un lado se
sincroniza con algún sistema de definición horaria (como por ejemplo el tiempo GPS), y por el otro lado deriva señales de referencia necesarias para la sincronización en frecuencia de varios componentes en la cadena de transmisión. Los siguientes son ejemplos de señales de referencia comúnmente empleadas en la transmisión de televisión:
1) Señal de referencia “negro y ráfaga” (Black Burst).
2) Señal de referencia “de tres niveles” (Tri Level Sync).
3) Código de tiempo lineal (LTC – Linear Time Code).
4) Señal de referencia de audio digital (DARS – Digital Audio Reference Signal).
5) Señal de reloj para sincronización (Word Clock).
6) Señal de reloj “pulso por segundo” (PPS – Pulse Per Second).
Tradicionalmente, la señal de referencia y sincronización empleada para el procesamiento y administración de contenidos (programas de audio y video) es el código de tiempo lineal (LTC).
La hora correcta y su relación con la tasa de transmisión de cuadros de video
Esencialmente, el código de tiempo lineal busca etiquetar con la hora del día cada cuadro de video de algún
Y es aquí precisamente en donde aparece una “pequeña” dificultad: ¿cómo etiquetar con la hora correcta un
cuadro de video cuya tasa de transmisión no resulta en un número entero de cuadros por segundo?
Conviene en este punto recordar rápidamente el origen de la actual tasa de transmisión de cuadros para la señal de televisión a color NTSC.
La señal de televisión a color incluye información de luminancia, crominancia y sincronización. Esta información se transmite por un canal de 6 MHz (figura 2) que originalmente se definió para transmisiones monocromáticas (televisión en blanco y negro).
Figura 2. Espectro de un canal de televisión a color NTSC.
Para minimizar la interferencia entre la señal de luminancia y la señal de crominancia, la frecuencia de la subportadora de crominancia se escogió como un múltiplo non de la mitad de la frecuencia de exploración horizontal:
h h
sc f f
f
2 1
227 +
=
h
sc f
f
2 455
=
en donde,
fsc – frecuencia de la subportadora de crominancia
fh – frecuencia de exploración horizontal
De manera similar, para minimizar la interferencia entre la señal de audio y la señal de crominancia, se decidió hacer a la subportadora de audio un múltiplo entero de la frecuencia de exploración horizontal. Fue así como dicha subportadora se definió como la 286va armónica de la frecuencia de exploración horizontal:
h f n .5×106 = ⋅
(
15750)
10 5
4. × 6 =n ,
750 15 10 5 4 6 , . n = ×
286 714 . 285 ≈ = n en donde,
n – múltiplo de la frecuencia de exploración horizontal
Lo anterior definió una nueva frecuencia de exploración horizontal, que es igual a:
( )
286 =4.5×106fh Hz 27 734 15 286 10 5 4 6 . , .
fh = × ≈
Y consecuentemente, la frecuencia de repetición de campos se modificó a un valor ligeramente distinto al del estándar original: segundo campos . as e lín . campo segundo as e lín . 94 59 5 262 1 286 10 5 4 6 ≈ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ×
Y la tasa de transmisión de cuadros quedó finalmente definida con el valor:
segundo cuadros . , pos m ca cuadro as e lín . po m ca segundo as e lín . 97 29 1001 000 30 2 1 5 262 1 286 10 5 4 6 ≈ = ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / / ×
El hecho de tener una tasa de transmisión de cuadros fraccionaria plantea una seria dificultad, si lo que se desea es encontrar una correspondencia única y exacta entre cada cuadro de video y la hora del día.
Para comenzar a entender en qué consiste dicha dificultad, considérense las siguientes interrogantes:
a) ¿Cuántos segundos tiene un día?
b) ¿Cuántos cuadros de video se trasmitirían en ese tiempo?
Un día civil dura usualmente 86,400 segundos del Sistema Internacional de Unidades (SI), más, o menos un posible segundo bisiesto; y en algunas localidades, ocasionalmente una hora más o una hora menos cuando hay un ajuste debido al Horario de Verano.
Por lo tanto, en un día común se transmitirían:
Lo anterior muestra claramente que, para el sistema NTSC, no puede haber una relación exacta entre la hora del día y el número de cuadros de video transmitidos. La evolución a la televisión digital en alta definición no elimina este problema, por lo menos para quienes adoptamos el estándar de exploración SMPTE ST 274:2008, en su formato 1080i 59.94.
Diferencia entre el t empo real y el t empo de video
i
i
El tiempo de video es aquel en el cual se completa un número entero de cuadros, con la cuenta de cuadros coincidiendo con la cuenta de segundos (figura 3).
Figura 3. Definición de tiempo de video – ejemplo para una cuenta de 7 cuadros.
El tiempo de video esta basado en la tasa de transmisión de 29.97 cuadros por segundo. El tiempo real puede indicarse mediante un LTC configurado a 30 cuadros por segundo.
La diferencia entre el tiempo real y el tiempo de video puede definirse mediante una función lineal de la forma:
b mx ) x (
f = +
La variable independiente será el tiempo real, medido en segundos; y la diferencia será una función del tiempo real. Entonces podemos escribir:
b mt ) t (
d = +
en donde,
d(t) – diferencia entre el tiempo real y el tiempo de video.
m – constante de proporcionalidad.
t – tiempo real, medido en segundos del Sistema Internacional de Unidades (SI).
b – constante de compensación (offset).
La constante m se puede determinar a partir de una proporción que relacione el tiempo real con el número de cuadros transmitidos:
1001 000 30
30
1 ,
c =
Aquí, c representa el tiempo necesario para transmitir 30 cuadros a una tasa de 29.97 cuadros por segundo.
segundos c
1000 1001
=
Por lo tanto, por cada segundo, la diferencia entre el tiempo real y el tiempo de video será de 1 milisegundo.
segundos segundo
cada por diferencia
1000 1 1 1000 1001− = =
El valor 0.001 define entonces la constante de proporcionalidad m:
1000 1
= m
El valor de la constante de compensación b es cero, dado que la cuenta de segundos y la cuenta de cuadros la estamos comenzando en el mismo instante y a la misma hora.
Por lo tanto, la función que determina la diferencia entre el tiempo real y el tiempo de video queda definida así:
t )
t ( d
en donde,
d(t) – diferencia entre el tiempo real y el tiempo de video.
t – tiempo real, medido en segundos del Sistema Internacional de Unidades (SI).
Se puede utilizar esta función para estimar la discrepancia que habrá entre el tiempo marcado por un conteo
non–drop frame (definido más adelante) y el tiempo real.
El código de tiempo SMPTE
El código de tiempo SMPTE (Society Of Motion Picture and Television Engineers, documento ST 12–1:2014) sirve para establecer una relación entre la hora del día y los cuadros de video. Lo hace mediante la generación de “etiquetas” que tienen el siguiente formato:
HH:MM:SS:FF
en donde,
HH – Hora del día, normalmente especificada en un formato de 24 horas (00–23) MM – Minutos (00–59)
SS – Segundos (00–59)
FF – Cuadros de video (00–29)
Aquí comienzan los problemas. Según esta especificación, las etiquetas se generan como si se estuviesen transmitiendo 30 cuadros por segundo, dado que hay 30 etiquetas disponibles para cada segundo de video, numeradas de la 00 a la 29. Sin embargo, hemos visto con anterioridad que la tasa real de transmisión es de aproximadamente 29.97 cuadros por segundo, no de 30.
¿Qué sucede si se pretende registrar un programa de 29.97 cuadros por segundo con 30 etiquetas para cada segundo?
Veámoslo.
Supongamos, para comenzar, que efectivamente estamos transmitiendo en blanco y negro y tenemos una tasa de 30 cuadros por segundo. En un caso así, la correspondencia (establecida por el código de tiempo) entre la hora del día y el cuadro de video es trivial:
•
Figura 5. Correspondencia entre el código de tiempo y los cuadros de video: 1 segundo.
•
•• En un minuto se tienen exactamente 1,800 etiquetas para 1,800 cuadros de video (figura 6).
uto min cuadros , uto min ndos u seg ndo u seg cuadros 800 1 1 60
30 ⎟=
⎠ ⎞ ⎜ ⎝ ⎛ / ⋅ /
Figura 6. Correspondencia entre el código de tiempo y los cuadros de video: 1 minuto.
•
•• En una hora se tienen exactamente 108,000 etiquetas para 108,000 cuadros de video (figura 7).
hora cuadros , hora tos u min to u min ndos u seg ndo u seg cuadros 000 108 1 60 1 60
30 ⎟=
⎠ ⎞ ⎜ ⎝ ⎛ / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ /
Figura 7. Correspondencia entre el código de tiempo y los cuadros de video: 1 hora.
•
•• En un día se tienen exactamente 2,592,000 etiquetas para 2,592,000 cuadros de video (figura 8).
día cuadros , , día as r ho ra o h tos u min 60 uto n mi ndos u seg ndo u seg cuadros 000 592 2 1 24 1 1 60
30 ⎟=
Figura 8. Correspondencia entre el código de tiempo y los cuadros de video: 1 día.
Si el primer cuadro de video se empieza a transmitir al comienzo del día, entonces en todos los casos anteriores el código de tiempo corresponderá exactamente con la hora correcta.
Analicemos ahora el caso real, en el que se transmite video a una tasa aproximada de 29.97 fps.
•
•• En un segundo se transmiten casi 30 cuadros. El cuadro número 30, que tardará un poco más de un segundo en completarse (figura 9), será etiquetado con el código de tiempo 00:00:01:00. Sin embargo, el tiempo mostrado por dicho código tendrá un retraso de exactamente 1 milisegundo con respecto al tiempo real.
( )
. segundos )t (
d 1 0001
1000
1 ⋅ =
=
Figura 9. Retraso del código de tiempo a 29.97 fps con respecto al tiempo real.
•
•• En un minuto se transmiten 1,798.2 cuadros:
uto min cuadros .
, uto min
ndos u seg ndo
u seg cuadros ,
2017982 798
1 1
60 1001
000 30
= ⎟ ⎠ ⎞ ⎜
⎝
⎛ /
Esto significa que en un minuto se habrán etiquetado solo 1,798 cuadros, en lugar de los 1,800 que se transmitirían a una tasa de 30 fps. Lo anterior provoca una discrepancia mas notable entre la hora indicada por el código de tiempo y la hora real (figura 10).
( )
. segundos )t (
d 60 006
1000
1 ⋅ =
=
Figura 10. Código de tiempo a 29.97 fps para 1 minuto.
El código de tiempo para el cuadro número 1,798 es 00:00:59:28, lo que equivale a un retraso de aproximadamente 0.06 segundos con respecto al tiempo real.
•
•• En una hora se transmiten 107,892.107892 cuadros:
hora cuadros . , hora tos u min uto n mi ndos u seg ndo u seg cuadros , 107892 892 107 1 60 1 60 1001 000 30 = ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ /
(
)
. segundos )t (
d 3600 36 1000
1 ⋅ =
Figura 11. Código de tiempo a 29.97 fps para 1 hora.
Y la discrepancia entre la hora indicada y el tiempo real sigue aumentando: ¡ahora es de 3.6 segundos!
Es evidente que este esquema de etiquetado NO SIRVE. Sólo como ejercicio, veamos lo que sucede en el último caso, en donde consideramos un intervalo de 1 día.
•
•• En un día se transmiten 2,589,410.58941 cuadros:
día cuadros . , , día ras o h ra o h utos n mi uto n mi ndos u seg ndo u seg cuadros , 58941 410 589 2 1 24 1 60 1 60 1001 000 30 = ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ /
(
,)
. segundos )t (
d 86400 864
1000
1 ⋅ =
El retraso de la hora indicada con respecto al tiempo real es totalmente inaceptable: ¡86.4 segundos!
Hasta ahora, yo pensaba que para experimentar una dilatación del tiempo había que viajar a velocidades cercanas a la de la luz. Pero ya vi que no es necesario – ¡basta con no entender bien los conceptos básicos y ajustar mal tu generador de código de tiempo! Y entonces empezarán a ocurrir cosas inesperadas a tu alrededor...
El esquema de conteo “drop frame”
Se debe encontrar algún modo de hacer coincidir el tiempo real con las etiquetas de los cuadros de video. ¿Qué se puede hacer?
Empecemos por ver lo que NO podemos hacer:
1. Alterar el paso del tiempo propio, medido por lo que nosotros llamamos “la hora correcta”. 2. Modificar la tasa de transmisión de cuadros.
3. Truncar los cuadros de video.
Sólo queda el meditar sobre el código de tiempo.
Sabemos que el código de tiempo es solamente un “conteo”, es decir, es un proceso relativamente abstracto, en el sentido de que esta “separado” de los dos eventos “inamovibles” que nos interesa relacionar: el paso del tiempo y la tasa de transmisión de cuadros. Esto abre la puerta para encontrar la solución al problema.
El paso del tiempo es indicado y medido correctamente por el código de tiempo, siempre y cuando se “transmitan” 30 cuadros en un segundo. La tasa real de transmisión de cuadros de video es de aproximadamente 29.97 fps. Si observamos el transcurso de ambos eventos (el tiempo real y la transmisión de video) en forma simultánea y paralela, podremos descubrir algo interesante: en ciertos instantes el desalineamiento entre ambos eventos es mínimo.
Ilustremos esta idea mediante la siguiente figura, en donde el paso del tiempo es modelado por la sucesión de cuadros inferior y la transmisión de video es modelada por la sucesión de cuadros superior:
Figura 13. Comparación de dos eventos: el paso del tiempo y la transmisión de video.
Si queremos que la cuenta de cuadros coincida con la cuenta de tiempo, ¿por qué no omitir la etiqueta “11” de la sucesión superior y pasar directamente a la etiqueta “12”? Finalmente, no es más que una etiqueta; y no estamos modificando realmente ni la tasa de transmisión de cuadros ni mucho menos el paso natural del tiempo. Bajo este esquema, obtendríamos la siguiente cuenta de cuadros:
Figura 14. Omisión de la etiqueta “11” en el conteo de cuadros de video.
En la figura 14 se han pintado de distinto color las etiquetas “12”, para recalcar dos hechos importantes:
1) Los cuadros son coincidentes (suceden en instantes iguales). 2) Los cuadros tienen ahora la misma etiqueta.
Esta operación de omitir una etiqueta nos ayuda a corregir momentáneamente la discrepancia entre la cuenta de los cuadros de video y el tiempo real. A esta operación se le conoce como “conteo drop frame” (drop frame: tirar un cuadro). Obsérvese que lo que se “tira” no es el cuadro de video, sino solamente la “etiqueta.”
El conteo drop frame omite periódicamente la cuenta de cuadros, de tal manera que aunque la transmisión de video y el tiempo real difieran en frecuencia, la discrepancia entre ellos será mínima y se corregirá periódicamente.
El conteo drop frame para video a 29.97 fps se rige por el siguiente par de reglas:
1. Se omite el conteo de los dos primeros cuadros del primer segundo de cada minuto. Ejemplo:
01:57:59:28 01:57:59:29 01:58:00:02 01:58:00:03
2. Esta omisión de conteo no se realizará para múltiplos enteros de 10 minutos. Ejemplo:
Bajo este nuevo esquema de conteo, analicemos ahora la discrepancia entre el código de tiempo y la hora correcta:
•
•• En un día, el generador de código de tiempo crea 2,592,000 etiquetas:
día etiquetas , , día ras o h ra o h utos n mi uto n mi ndos u seg ndo u seg etiquetas 000 592 2 1 24 1 60 1 60
30 ⎟=
⎠ ⎞ ⎜ ⎝ ⎛ / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ /
Si cada minuto omito 2 de ellas, entonces para un día completo contaré con solo 2,589,120 etiquetas: día etiquetas , , uto n mi etiquetas día utos n mi día etiquetas ,
,592000 1440 2 2589120
2 =
/ ⋅ / −
Esta cifra es menor a los 2,589,410.58941 cuadros de video que habría que etiquetar por día. La omisión de dos etiquetas por cada minuto no basta por sí sola para lograr una correspondencia adecuada entre las etiquetas y los cuadros de video. Es por este motivo que se decidió no omitir el conteo de cuadros en cada intervalo de diez minutos. De este modo se restituyen 288 etiquetas al día, con lo que la diferencia entre el número de etiquetas disponibles y el número de cuadros a etiquetar es ahora mínima.
día etiquetas utos min diez e d ervalo int etiquetas ndos u seg utos min diez e d ervalo int día ndos u seg
, 2 288
600 1 400 86 = / ⋅ ⎟ ⎠ ⎞ ⎜ ⎝ ⎛ / / ⋅ / día etiquetas , , día etiquetas día etiquetas ,
,589120 288 2589408
2 + =
Esto significa que bajo el esquema de conteo drop frame se cuenta con 2,589,408 etiquetas para 2,589,410 cuadros. Por lo tanto, al final del día se tendrá una discrepancia de solo dos cuadros entre el código de tiempo y la hora correcta.
Al código de tiempo que omite la cuenta de cuadros en conformidad con el esquema descrito anteriormente, se le llama código de tiempo SMPTE drop frame (DF); y al que no omite la cuenta de cuadros se le llama código de tiempo SMPTE non–drop frame (NDF). Para distinguir entre ambos, se adopta la convención de separar el conteo de cuadros mediante un punto y coma (;), o mediante un punto (.), cuando se está generando un código de tiempo drop frame.
Ejemplo,
02:34:48:17 → código de tiempo non–drop frame
02:34:48;17 → código de tiempo drop frame
Ilustremos y comparemos ambos esquemas de conteo para varios intervalos, tomando como referencia el código de tiempo a 30 fps (el cual indica la hora correcta.)
•
•• Intervalo de 1 segundo:
Figura 15. Comparación de códigos de tiempo para un intervalo de 1 segundo.
•
•• Intervalo de 1 minuto:
•
•• Intervalo de 10 minutos:
Figura 17. Comparación de códigos de tiempo para un intervalo de 10 minutos.
•
•• Intervalo de 1 hora:
•
•• Intervalo de 1 día:
Figura 19. Comparación de códigos de tiempo para un intervalo de 1 día.
Obsérvese que la discrepancia entre el código de tiempo drop frame y la hora correcta es en todos los casos de dos cuadros o menos, y a veces hasta nula. De cualquier manera, en un intervalo de un día siempre habrá un error residual, el cual se puede eliminar mediante sincronización por interferencia (jam sync).
El error residual por día se puede calcular así:
error residual = [número de cuadros transmitidos en un día] – [número de etiquetas disponibles en un día]
día cuadros . día cuadros día etiquetas , , día ndos u seg , ndo u seg cuadros , residual
error 26
1001 2592 408 589 2 400 86 1001 000 30 ≈ = ⎥⎦ ⎤ ⎢⎣ ⎡ − ⎥ ⎦ ⎤ ⎢ ⎣ ⎡ ⋅ / / = día os milisegund . día segundos . día segundos dro a cu segundos , día dros a cu residual
error 00864 864
625 54 000 30 1001 1001 2592 = = = / ⋅ / =
En los cálculos anteriores se trató a las etiquetas y a los cuadros como una sola unidad, dada la correspondencia
única y exacta que hay entre ellos, es decir, a cada cuadro se le asigna una etiqueta que es única y los cuadros y las etiquetas nunca son fraccionarios.
Sincronización por interferencia (jam sync)
interfiriendo momentáneamente la salida del generador con la señal de la fuente horaria, de modo que el generador continúe por su cuenta, ya alineado nuevamente a la hora correcta, una vez retirada la señal interferente.
El proceso jam sync puede hacerse de manera manual o programada. En caso de que se esté generando un código de tiempo drop frame, normalmente la sincronización se hace cada 24 horas, de manera programada. De este modo al final del día siempre se corregirá automáticamente el error residual, y el código de tiempo indicará en todo momento, con una exactitud razonable, la hora correcta.
Algoritmo para el cálculo del código de tiempo SMPTE drop frame
Personalmente encontré que para uno ayudarse a asimilar bien el concepto de conteo drop frame, es muy buen ejercicio el tratar de construir una hoja de cálculo que determine correctamente el código de tiempo SMPTE
drop frame, a partir de un número determinado de cuadros de video transmitidos a 29.97 fps.
Las herramientas matemáticas necesarias para desarrollar un algoritmo que realice la tarea mencionada son, afortunadamente, muy sencillas. La mayor dificultad esta en establecer correctamente la lógica del conteo, lo cual solo puede lograrse cuando se ha entendido a plenitud el concepto de conteo drop frame, y las reglas bajo las cuales dicho conteo se rige. Antes de construir el algoritmo, es conveniente recordar algunos conceptos básicos de aritmética.
División Euclidiana
En aritmética, la división Euclidiana es el proceso convencional de la división de dos enteros, lo cual produce un cociente y un residuo. Existe un teorema, conocido como el teorema de la división, que establece la existencia de un cociente y un residuo únicos, los cuales tienen ciertas propiedades. Este teorema es la base matemática del algoritmo que aquí se propone.
Teorema de la división
Dados dos enteros a y b, con b≠ 0, existen enteros únicos q y r tales que:
r bq a= +
en donde,
b r< ≤
0 ; b es el valor absoluto de b
Los cuatro enteros que aparecen en este teorema llevan nombres específicos:
a – dividendo
b – divisor
q – cociente
División entera
La división entera es una operación en la cual el residuo es descartado. En el presente documento se indicará la división entera mediante el mnemónico IntDiv.
Operación “modulo”
El resultado de la operación “modulo” es el residuo de la división Euclidiana. Dicha operación se indica mediante el mnemónico mod.
Ilustremos las definiciones anteriores mediante la siguiente figura:
Figura 20. El teorema de la división.
Para exponer la utilidad de la operación mod, seguimos aquí la discusión de Stein [2].
Dos números enteros A y B son equivalentes en modulo m si, cuando ambos son divididos por m, resultan con residuos iguales:
m B
A = mod
m B
m
Amod = mod
La operación “modulo” esta relacionada con la periodicidad. Dado un entero A, la “reducción modulo” m de A,
B m Amod =
significa que se debe encontrar el número entero B mínimo, para el cual A es equivalente en módulo m.
Ejemplo,
y
30 mod 61 31=
(se lee “31 es igual a 61 en modulo 30”), dado que,
1 30 mod
31 =
y
1 30 mod
61 =
Si A dividido por m no produce ningún residuo (A mod m = 0), entonces se dice que m es un factor de A.
La operación modulo es parte fundamental del algoritmo aquí propuesto, pues nos permitirá contar desde 0 hasta 29 (cuadros de video), desde 0 hasta 59 (minutos o segundos) o desde 0 hasta 23 (horas) de manera cíclica
(o periódica, como se prefiera llamarle).
Estructura del algoritmo
En discusiones previas se ha dejado ver claramente que la hora indicada por un código de tiempo SMPTE non– drop frame tiende siempre a retrasarse, cuando dicho código se asocia a un video transmitido a 29.97 fps. Por otro lado, hemos visto que un código de tiempo SMPTE non–drop frame, asociado a un video transmitido a 30 fps, siempre indicará correctamente la hora.
Lo anterior nos puede dar una muy buena idea de cómo estructurar nuestro algoritmo – se debe encontrar algún modo de restituir el “tiempo perdido” por el conteo a 29.97 fps. Adicionalmente, se deben vigilar las transiciones alrededor de cada minuto, para tomar en cuenta las dos reglas del conteo drop frame.
Se propone pues, un algoritmo basado en tres operaciones fundamentales:
1) Compensación de conteo.
2) Supervisión de transiciones alrededor de cada minuto. 3) Posible corrección de conteo.
La compensación de conteo permite hacer corresponder correctamente la hora del día con cada cuadro de video transmitido. Es importante aclarar que esta operación no “inventa” ni “introduce” cuadros de la nada; simplemente crea una cuenta virtual que servirá única y exclusivamente para determinar la hora correcta. Recuérdese también que el código de tiempo es solo “una etiqueta”. Dicho de otro modo, la compensación convertirá, virtualmente hablando, una cuenta de video a 29.97 fps en una cuenta de video a 30 fps. Ya se ha visto que el código de tiempo derivado de una cuenta a 30 fps siempre corresponde con la hora correcta.
1) Por cada intervalo de un minuto, se deben restituir 2 cuadros de video. 2) Por cada intervalo de diez minutos, se deben restituir 18 cuadros de video.
Se busca restituir los cuadros omitidos por el esquema de conteo drop frame, dado que se requiere obtener una cuenta que permita determinar correctamente la hora del día, para así poder asociarla con cada cuadro de video que se transmite a 29.97 fps.
Antes de terminar de calcular el código de tiempo a partir de una cuenta compensada de cuadros, es necesario verificar si dicha cuenta corresponde o no a una transición de minuto. La rutina de compensación de cuadros y el posterior cálculo de código de tiempo fallan miserablemente en las transiciones de minuto. Esto se ilustra en la siguiente tabla, que muestra el código de tiempo SMPTE drop frame para una cuenta de cuadros específica, cuando se calcula sin una rutina de supervisión de transiciones.
1797 cuadros 00 : 00 : 59 ; 27 10787 cuadros 00 : 05 : 59 ; 27 1798 cuadros 00 : 01 : 00 ; 00 10788 cuadros 00 : 06 : 00 ; 00 1799 cuadros 00 : 01 : 00 ; 01 10789 cuadros 00 : 06 : 00 ; 01 1800 cuadros 00 : 01 : 00 ; 02 10790 cuadros 00 : 06 : 00 ; 02
3595 cuadros 00 : 01 : 59 ; 27 12585 cuadros 00 : 06 : 59 ; 27 3596 cuadros 00 : 02 : 00 ; 00 12586 cuadros 00 : 07 : 00 ; 00 3597 cuadros 00 : 02 : 00 ; 01 12587 cuadros 00 : 07 : 00 ; 01 3598 cuadros 00 : 02 : 00 ; 02 12588 cuadros 00 : 07 : 00 ; 02
5393 cuadros 00 : 02 : 59 ; 27 14383 cuadros 00 : 07 : 59 ; 27 5394 cuadros 00 : 03 : 00 ; 00 14384 cuadros 00 : 08 : 00 ; 00 5395 cuadros 00 : 03 : 00 ; 01 14385 cuadros 00 : 08 : 00 ; 01 5396 cuadros 00 : 03 : 00 ; 02 14386 cuadros 00 : 08 : 00 ; 02
7191 cuadros 00 : 03 : 59 ; 27 16181 cuadros 00 : 08 : 59 ; 27 7192 cuadros 00 : 04 : 00 ; 00 16182 cuadros 00 : 09 : 00 ; 00 7193 cuadros 00 : 04 : 00 ; 01 16183 cuadros 00 : 09 : 00 ; 01 7194 cuadros 00 : 04 : 00 ; 02 16184 cuadros 00 : 09 : 00 ; 02
8989 cuadros 00 : 04 : 59 ; 27 17979 cuadros 00 : 09 : 59 ; 27 8990 cuadros 00 : 05 : 00 ; 00 17980 cuadros 00 : 10 : 00 ; 00 8991 cuadros 00 : 05 : 00 ; 01 17981 cuadros 00 : 10 : 00 ; 01 8992 cuadros 00 : 05 : 00 ; 02 17982 cuadros 00 : 10 : 00 ; 02
Tabla 1. Análisis de transiciones de minuto para un intervalo de 10 minutos.
Fue difícil diseñar la parte del algoritmo que verifica las transiciones de minuto, sobre todo porque es muy escasa la literatura que describe el código de tiempo SMPTE con este nivel de detalle. Se llegó a la conclusión de que había que incluir una rutina de corrección que actuase únicamente en los casos en los que el resultado de las rutinas previas es erróneo. Como ya se ha mencionado, éstos casos están indicados en la tabla anterior mediante celdas sombreadas en gris.
Se muestra aquí un diagrama a bloques que ilustra la estructura final del algoritmo propuesto:
Figura 21. Estructura final del algoritmo propuesto.
Diagrama de flujo
A continuación se define propiamente ya el algoritmo, ilustrando el flujo del mismo, con la inclusión de las tres rutinas principales anteriormente discutidas: compensación de conteo, supervisión de transiciones de minuto y
corrección de conteo.
Definición y descripción de variables
Variables de entrada
CUADINI. Entero que indica un número determinado de cuadros de video que se han transmitido a una tasa de 29.97 fps.
Variables de salida
HH. Entero que indica la hora, con un intervalo de valores de 00 a 23. Forma parte del código de tiempo de salida.
00 ≤HH≤ 23
MM. Entero que indica los minutos, con un intervalo de valores de 00 a 59. Forma parte del código de tiempo de salida.
00 ≤MM≤ 59
SS. Entero que indica los segundos, con un intervalo de valores de 00 a 59. Forma parte del código de tiempo de salida.
00 ≤SS≤ 59
FF. Entero que indica el número de cuadros, con un intervalo de valores de 00 a 29. Forma parte del código de tiempo de salida.
00 ≤FF≤ 29
Variables de proceso
IDM. Entero que determina un número de conjuntos de 17,982 cuadros. Cada conjunto corresponde a un intervalo de diez minutos. Este entero indica el número de intervalos de diez minutos que han transcurrido para la cuenta de cuadros dada por la variable CUADINI.
IDM = CUADINI IntDiv 17982
CSOB = CUADINI mod 17982
0 ≤CSOB≤ 17981
IMSOB. Entero que determina un número de conjuntos de 1,798 cuadros. Cada conjunto corresponde a un intervalo de un minuto. Esta variable se determina a partir de los cuadros sobrantes indicados por CSOB.
IMSOB = CSOB IntDiv 1798
CRIDM. Entero que determina el número total de cuadros que serán restituidos a partir de cada intervalo de diez minutos que se haya contabilizado.
CRIDM = IDM x 18
CRIMSOB. Entero que determina el número total de cuadros que serán restituidos a partir de cada intervalo de un minuto que se haya contabilizado. Esta variable se determina a partir del número de conjuntos de 1,798 cuadros indicados por IMSOB.
CRIMSOB = IMSOB x 2
CUADTOT. Entero que representa la compensación de conteo, es decir, determina el número total de cuadros a partir del cual se calculará el código de tiempo. Es la suma de las variables CUADINI, CRIDM y CRIMSOB.
CUADTOT = CUADINI + CRIDM + CRIMSOB
MSOBMM. Entero de verificación que representa la reducción modulo 10 de la variable MM. Si MM dividido por diez no produce ningún residuo, entonces diez es un factor de MM. Esta variable determina el número de minutos que sobrarían si se forman conjuntos de diez minutos a partir de MM. Un valor distinto de cero para MSOBMM hará que el algoritmo ejecute de inmediato la rutina de corrección.
Rutina de compensación de conteo
Figura 23. Rutina de compensación de conteo.
Rutina de corrección de conteo
Figura 25. Rutina de corrección de conteo.
Código fuente
Las rutinas anteriormente descritas se probaron en primera instancia usando una hoja de cálculo de Excel. Posteriormente se creó un programa (archivo ejecutable) que implementa el algoritmo completo, usando el compilador Code::Blocks, release 12.11 [3].
Incluyo aquí el código fuente básico, escrito en lenguaje de programación C++:
#include <iostream> using namespace std; int FF = 0;
int SS = 0; int MM = 0; int HH = 0;
void print (int hours, int minutes, int seconds, int frames) {
cout << '\n';
cout << '\t' << hours << ":" << minutes << ":" << seconds << ";" << frames; cout << '\n';
cout << '\n' << "Presiona <Enter> para terminar..."; cin.ignore();
cin.get(); }
int correction (int IM, int CU, int CR) {
NWCUADTOT = CU+CR+NWCRIMSOB; FF = NWCUADTOT%30;
SS = (NWCUADTOT/30)%60; MM = (NWCUADTOT/1800)%60; HH = (NWCUADTOT/108000)%24; return HH, MM, SS, FF; }
int main() {
int CUADINI = 0; int IDM = 0; int CSOB = 0; int IMSOB = 0; int CRIDM = 0; int CRIMSOB = 0; int CUADTOT = 0; int MSOBMM =0;
cout << "Numero de cuadros de video: "; cin >> CUADINI;
IDM = CUADINI/17982; CSOB = CUADINI%17982; IMSOB = CSOB/1798; CRIDM = IDM*18; CRIMSOB = IMSOB*2;
CUADTOT = CUADINI+CRIDM+CRIMSOB; FF = CUADTOT%30;
SS = (CUADTOT/30)%60; MM = (CUADTOT/1800)%60;
if ( SS==0 && FF==0 || SS==0 && FF==1 ) {
if ( MM == 0 ) {
if ( CSOB > 17979 ) {
correction(IMSOB, CUADINI, CRIDM); print (HH, MM, SS, FF);
return 0; }
HH = (CUADTOT/108000)%24; print (HH, MM, SS, FF); return 0;
}
MSOBMM = MM%10; if (MSOBMM == 0) {
if (CSOB > 17979) {
correction(IMSOB, CUADINI, CRIDM); print (HH, MM, SS, FF);
return 0; }
HH = (CUADTOT/108000)%24; print (HH, MM, SS, FF); return 0;
}
correction(IMSOB, CUADINI, CRIDM); print (HH, MM, SS, FF);
return 0; }
HH = (CUADTOT/108000)%24; print (HH, MM, SS, FF); return 0;
Conclusiones
•
•• El código de tiempo SMPTE viene definido en dos variantes: non–drop frame y drop frame. En ninguna de las dos variantes se “tiran” cuadros de video.
•
•• Un generador de código de tiempo SMPTE siempre define 30 etiquetas para cada segundo de video, no importando si está en modo drop frame o en modo non-drop frame.
•
•• La única diferencia entre el código de tiempo SMPTE drop frame y el non-drop frame es que el primero omite la cuenta de algunos cuadros y el segundo no.
•
•• Un código de tiempo SMPTE que se esté generando a 30 cuadros por segundo, indicará correctamente la hora pero no estará sincronizado con el video.
•
•• Un código de tiempo SMPTE que se esté generando a 29.97 cuadros por segundo en modo non–drop frame estará sincronizado con el video pero no indicará correctamente la hora.
•
•• Un código de tiempo SMPTE que se esté generando a 29.97 cuadros por segundo en modo drop frame estará sincronizado con el video e indicará correctamente la hora.
•
Referencias
[1] Strachan, David. “The Right Time”: Master Clocks. Evertz Microsystems, LTD.
[2] Stein, Jonathan Y. Digital Signal Processing: A Computer Science Perspective. John Wiley & Sons, Inc., 2000. Whirlwind Exposition Of Mathematics, A.2. Integers, pp. 783.
[3] http://www.codeblocks.org/
Bibliografía
1. Robin, Michael and Michel Poulin. Digital Television Fundamentals: design and installation of video and audio systems. McGraw – Hill, Video/Audio Professional, 2000. Basics of Television, pp. 1.
2. Tozer, E. P. J. Editor in chief. Broadcast Engineer’s Reference Book. Focal Press, 2004. Timecode, pp. 203.
3. Allain, Alex. Jumping Into C++. Cprogramming.com, 2013.
Páginas Web
http://en.wikipedia.org
http://www.imaginecommunications.com/
http://andrewduncan.net/timecodes/
http://www.ntp.org/