[Michael Wells]

That would probably work. We typically will add a signal that has a stronger implulse like a click from a metronome as if produces an audio waveform that is easier to reference than random pink noise.

[Michael Wells]

Rich,

Our video engineer developed a test clip that incorperated the following features:

6 frame sequence of alternating primary/secondary colors that repeats every 6 frames.

We overlaid a vertical line of marks on the side of the images every 10 scan lines or so.

We duplicated this for 5 minutes then overlaid a time code display on top of it.

The timecode gives us a frame accurate reference and the color pattern and vertical marks allows us to see sub-frame accuracy in interlaced scanning as you can see when the new color is being re-drawn on the screen and coorelate that along with the vertical line graph to determine teh approx. number of lines of delay.

We took this clip and laid it to HDcam tape. We then played back the HDCAM tape through several different reference monitors along with a direct timecode connection to an ESE timecode display from the tape machine. Then we would snap pictures with a camera of the timecode display and the monitor under test. We were able to compare the numbers on the ESE Timecode display with the Timecode number and scan line transition with the monitor under test to determine the latency of the monitor.

We then built a database of all our monitors so we could use them for comparion testing against other signal patchs without needing a timecode display.

Now we just take a KiPro or other playback device and run it directly to a monitor with a known amount of latency as our reference display. We also run the test signal through whatever piece of equipment is under test, and on to another monitor with a known (or identical) amount of latency.

Then we snap pictures of both displays and calculate the latency difference between them.

Attached is one such photo where we were actually testing the end to end latency of a camera encoded to MPEG2, then decoded and sent to a display.

In the photo, the center CRT is our control reference. The other two displays are testing the relative decode latency of two different MPEG decoders.

[Michael Wells]

Very interesting that the same issue exists using the SAN. Is it a fiber channel SAN or something over Ethernet?

[Michael Wells]

We have one. Bought teh switcher first, then added the control panel later. I can’t recommend using a crossover cable directly from a PC to operate the unit via IP. I seemed to be less reliable (needed rebooting every couple of weeks) this way. No problems since we installed the control panel.

First off, it’s a nice piece of hardware. The control panel feels just as solid as our Grass Valley 4ME HD Switcher…it is nice. THe multiview is good enough.

Haven’t used the tally box yet, but plan to integrate one soon. Overall switcher latency is a bit less than two frames using an un-syncronized source(we developed a pretty awesome in house test pattern and measurement scheme that allows us to test latency with about 10 lines of accuracy). Two frames is about twice what I would like to see, but given that the switcher was automatically frame syncing the incoming signal, it ain’t bad. By the way, it was 2 frames whether you wnet in HD-SDI or HDMI via a blackmagic converter, so that is cool. Sometime we will test a timed source and see if the latency is reduced.

DSK and transitions are effective enough, and the still store is fine. Haven’t messed with the DVE or main keyers.

The biggest thing I wish it had was a redundant PSU option on the switcher frame. In the future, I will probably buy the 2 ME unit just to get a redundant power supply capability.

All in all, it is a heck of a switcher, and cheap to boot.