[time-nuts] Measuring TV delays

[Magnus Danielson]

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