Moon Pie Drop Mobile, Alabama as watched in Birmingham 7 sec delay over the
air, 9 sec analog cable, digital cable not checked. In fact it maybe
possible the Satellite back feed is in the clear, something to check next
year. Now I need a high speed multi channel CCTV setup to Capture this with
predictable delays. Sure this will keep me busy till next year :-) Happy new
year to all ! ( sorry for the 32 hour delay )

Stanley
----- Original Message -----
From: "David J Taylor" david-taylor@blueyonder.co.uk
To: time-nuts@febo.com
Sent: Thursday, January 02, 2014 12:28 AM
Subject: Re: [time-nuts] Measuring TV delays

On 1/1/14 10:28 PM, David J Taylor wrote:

Rocket launches, although typically not on live TV any more. More likely
streamed (at least that's how I watch them).  In the "post launch
tracking" part, there's usually a display showing TAI/UTC along with
various parameters (perigee, apogee, etc).  I always wait until perigee
is >100km before really believing it's successful.

But if you can get a feed from China or India, they're pretty big on
publicizing their space program, so they might have live news feeds.

Typically, cable receives the signal off air or via fiber.
They decode the digital signal to baseband.
They reencode the signal to their distribution format.
They mux all the channels together.
All of this is transmitted as packets.
Each channel has a PID assigned in the header of the  packet.
Your TV or set top box decodes the packets and displays the ones for
the channel that you have selected.

The decode and encode time at the cable plant is part of this.
Most of the latency is that you would not pay for a fast enough
processor in your TV or set top box to process all of the packets faster.

The more channels in the cable system, the longer the latency.

73
Glenn
WB4UIV

At 08:31 AM 1/2/2014, you wrote:

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.

On Wed, Jan 1, 2014 at 10:28 PM, David J Taylor <
david-taylor@blueyonder.co.uk> wrote:

--

Chris Albertson
Redondo Beach, California

On 1/2/14 11:56 AM, Chris Albertson wrote:

Depends on how the "live" feed is derived. If it's an analog signal,
there's no "time setting" involved.  If it's B-roll from a GoPro, then
yes, it's based on the camera person's watch.

Unlikely that they'd fool with clocks in the background.  Why would they
care (except if they're faking the 1969 moon landing or something.. then
they've got enough budget for someone to make sure the clocks in the
fake mission control read correctly).

They DO have people to set the clocks in filming for subsequent editing:
it's just part of "continuity" like making sure cigarettes are the right
length, the ice in the glasses has melted the right amount, etc.

Not a job I would want.

On 03/01/14 10:04, David J Taylor wrote:

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.

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

On 03/01/14 15:05, David J Taylor wrote:

There are several potential time-signals, but I would say it would be a
bit hard to verify their traceability, which makes the exercise difficult.

The MPEG-2 Transport Stream have PID timestamps for every channel.
However, there is really no good TAI/UTC traceability in them. Also,
re-stamping is used to cover up for delay variations.

VITC might be present, and might provide local time, but for NTSC
countries there is a frequency error only partly covered in the
drop-frame compensation which causes a deviating display-time from
actual local time.

Caption can also carry time, but there is no guarantee it has a sane source.

Cheers,
Magnus

David,

On 03/01/14 16:28, David J Taylor wrote:

Thanks David, if you want to make delay measurement, you need to make
assumption about the correctness of time and I'm trying to point out
that there is a limit to how accurate it can be, and hence the
measurement can be fairly bogus. Essentially, in the TV business they
don't care very much about accurate time that much. If you have a hint
from your watch when to expect a particular program, then it's OKish.

If they did care, it would be not too hard to fix it, but it is becoming
harder than it used to be.

Cheers,
Magnus

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: