[time-nuts] Measuring TV delays

Glenn Little glennmaillist at bellsouth.net
Fri Jan 3 14:01:19 EST 2014


At the station that I worked at,  time code was recorded in the 
digital video stream in the camera, but, was only used for editing.
The editors would use this time code to mark the segment end points.
There was no correlation to the camera time code and actual time.
When we taped a show from a feed, we used internally generated time code.
This was used for the automation equipment.
If a recording had time code of 2359 - 0000 in the show, the show had 
to be redubbed with time code that did not cross the day boundary.
Our automation equipment did not understand day nor did it understand 
negative time.
I would guess that if the station were 100% automated, everything 
that was broadcast would have valid time code.
We broadcast Network, prerecorded syndicated shows, commercials, 
promos and locally produced programming.

Because of the in field switching between cameras and graphic sources 
for a live broadcast camera time code was not important as the 
switching was done manually (you cannot automate a live event).
There was probably continuos time code inserted at the output of the 
production switcher, but,this time code was not used at our station 
as we had to manually switch to a local source for promos, 
commercial, and locally prepared programming.

I do not think that there would be a reason to preserve the camera 
time code from camera to air.
I cannot see where it would be of much value as the camera would free 
run time code.
It could be preset, but, there was nothing to guarantee frame 
accuracy for the length of a live event that was shot with numerous 
field cameras.
The cameras were gen locked to allowing glitch free switching between 
sources at the production board, but, there is no way, that I know 
of, to sync time code.

This is how the station that I worked at operated.
Other stations my have operated differently.

The bottom line is I know of no way to derive accurate time from a 
present day TV signal without the station inserting time information 
in the stream.
This is how the VCR time auto set worked.
But the uncertainties in the coding and decoding times would make 
this less accurate than time derived from other available sources.

73
Glenn
WB4UIV










At 08:24 AM 1/3/2014, you wrote:
>On 03/01/14 10:04, David J Taylor wrote:
>>From: Chris Albertson
>>
>>When they broadcast "live" TV like from a sports vent I wonder if the time
>>code generated by the camera is preserved?  But then even if it were the
>>time might have been set manually to match the display on the camera
>>operator's cell phone.
>>
>>Same for scenes with clacks in the background.  Do you trust them to be
>>on-time?   They might even have ben intentionally set wrong to hide the
>>transmit delay.
>>=================================
>>
>>Can't comment on the camera time-code, Chris, but I would hope it was
>>centralised rather than being off the operator's phone!
>
>You try to lock up cameras with a "genlock" or "black-burst" signal, 
>which is a black signal with color-burst, and often VITC to get 
>production-time. Production time may be similar to local time. For 
>most live events I expect it to be, as it is very handy. Timing 
>generators can either be set manually or get time from GPS or such.
>
>The reason to lock cameras up is that you don't need frame-stores to 
>align them up but can use the video-mixers line-stores instead. In 
>the old analog days, all delays in a studio was aligned up so that 
>the signalas matched to within 20 ns. This meant long cable-runs to 
>cable-equalize all cameras.
>
>>The clocks I mentioned, F1 races, do appear to be accurate (observations
>>partially from being present at the event), and certainly /not/ skewed
>>to compensate for broadcast delay.  Other times are when you see "behind
>>the scenes" and a control-room clock is visible.  Usually these are
>>centrally synced, and can give a fair impression of the broadcast delays.
>
>Since you don't know the distribution and de-coding and trans-coding 
>delays, it's hopeless to come up with a skewed time to fit all. 
>Forget it. The mode is rather to live with the delay there is.
>
>Cheers,
>Magnus
>_______________________________________________
>time-nuts mailing list -- time-nuts at febo.com
>To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>and follow the instructions there.



More information about the time-nuts mailing list