Churches Using VT4

[sc73]

Need help from VT 4 Community to help me to find out how many churches around the world using VT4? If there are, do they use it for live switching and do they experience video delay?

What are the solutions to this delays? Do they use Audio delay to sync the video projected on the screen?

The reason I'm asking this is that I've a client who threatens to return back VT4 because the of the video delays. They are using broadcast camera and high end projectors which should not produce delay more that 1/2 secs.
The only way to convince them the accept VT4 is that I'm able to get other churches out there to share their experience on how to solve this problem and what are the acceptable delays (how many frames) to them.

Urgent!!! :help:

[SystemsEng]

I use the VT4 to broadcast a live show each morning. Are you speaking of the audio delay? If so use the live feed from your sound mixer to a sound system for the live audience. Send and aux feed to record audio on the VT4.
The audio through to the VT4 is slightly delayed. The Video passed through the VT4 will seem much closer in sync to the live audio feed from the mixer. I have Four Broadcast locations that operate this way. Schools not churches.

[Cineman]

Need help from VT 4 Community to help me to find out how many churches around the world using VT4?:
Yes. Church.

If there are, do they use it for live switching
Yes.

and do they experience video delay?
Yes.

What are the solutions to this delays?

1. If camcorders, use composite out from the camera section.
2. Genlock cameras to the VT.
3. Advance the cameras vertical sync to to the maximum prior to glitching video.

Do they use Audio delay to sync the video projected on the screen?
Yes.

The reason I'm asking this is that I've a client who threatens to return back VT4 because the of the video delays. They are using broadcast camera and high end projectors which should not produce delay more that 1/2 secs.
Under the above criterion, the delay at the projection screens should be less than one tenth of a second (3 frames). The congregation should never even notice it.

Nes Gurley

[Danic101]

The customer must have something else that is causing the delay, such as a distribution Amp or the scaler in the projector. My VT only has 2 frames of delay from component in to component output and 3 frames from component input to VGA output

[TRCC]

We use the VT for our 3,000 seat auditorium, and 2 20' screens on both sides of the stage. There is a noticable delay, more than 3 frames, closer to 5 or 6, which to the lay person is rarely noticable, only with fast movement, and a direct line of the speaker or subject and the screen to make a comparison. A delay of 15 frames is not normal from the VT, one way we tested the amount of delay we had for each of the components, was we filmed the program out with a camera signal on the TV looking at the TV, when we switched, we counted the frames it took from the camera to the TV, it was 3 which meant that our system was delaying 3 frames, pretty decent. On the other hand, our matrix, and scalers, and different distribution amps, hike our delay up to 5-6 frames.

Do they use any Matrix switchers?
Distribution amps?
Are the frame syncing their cameras?
Do they use a video scaler/upconverter?
D-A/A-D converters?

These can cause delays.

Luke

[nevmoor]

We use VT for live switching, butwe use an MX30 for IMAG. The point is that we have screen delays caused by the sum of all the processing that happens to the signal thru each piece of gear. Just like Luke said. Thereare other factors that they have to look at. If you want them to talk to someone independantly contact me. I would have not problem talking to you/them about it.

[Dato_Chua]

They do use a Matrix Switcher. No distribution amp. Yes the do sync their camera. No video scaler or D-A.

[Dato_Chua]

Sorry guys for the long silence. Is me SC73. I was not able to log on to the Forum in spite of resetting my account for more than 10 times and no replies from Newtek for my new password. So i had to resort to using a now user name.

In a church setting, do the singers and musicians complain if an audio delay system is introduce to sync the VT output with the audio system? If there anyone from this forum are working in a church using VT4? I might need help to explain the delay to my client(church) .

[Cineman]

In a church setting, do the singers and musicians complain if an audio delay system is introduce to sync the VT output with the audio system?.
Not at all. They should not hear the delay. The house mix doesn't apply the delay to the foldback and ear systems. If they did not have such, and the singers and musicians could hear the house mix, it would be as reflected back to them from the back wall. The sound would be traveling out and back from that and would be delayed whether or not additionally for the VT video. That would seriously disturb them.

If there anyone from this forum are working in a church using VT4? I might need help to explain the delay to my client(church) .
Yes, of course, but you should have everything that you need to tell them from this thread.

While here, I'll thank Dani for adding DAs, (something important that I forgot), in the very next post after mine. We removed on over 300 foot runs and couldn't see a difference in the video quality. Could have saved a frame of delay. Don't know if I would have ever caught the omission in my post, on my own.

Nes Gurley

[Henzzz]

Need help from VT 4 Community to help me to find out how many churches around the world using VT4? If there are, do they use it for live switching and do they experience video delay?

What are the solutions to this delays? Do they use Audio delay to sync the video projected on the screen?

The reason I'm asking this is that I've a client who threatens to return back VT4 because the of the video delays. They are using broadcast camera and high end projectors which should not produce delay more that 1/2 secs.
The only way to convince them the accept VT4 is that I'm able to get other churches out there to share their experience on how to solve this problem and what are the acceptable delays (how many frames) to them.

Urgent!!! :help:


are you from Clickgrafix ?? :D


there is one in indonesia, do live switching, and yes... there is little delay :D

but i think this because their computer hardware is not capable enough.

[tonyvdb]

Video delay is normal for all live switching in the digital world the only way to get around this is to use an older analogue video switcher that has external TBC's this will reduce the delay but not eliminate it. Syncing video via hardware inside the PC requires allot of processing power and this causes a delay.
Up until recently my home church was using an Amiga 4000 with a Toaster but we moved to a new location and bought all new equipment (sadly not the VT4)

[TAV Media]

We use VT4 here with no problems...delay may be around 2-3 frames, nothing to complain about. We use 4 cameras, the CCUs output SDI and Component video and everything is genlocked.

Signal Flow:
CCU - SDI - Program Switcher - Component Matrix - Recording Decks
- Component - VT4.6 - Component Matrix - IMAG/Web Stream

Most of the time we just feed the program switcher through the matrix to the VT and just use the VT to overlay graphics for IMAG...VT is also on standby just in case there is a problem with the program switcher.

For some reason, in our setup, the audio is the only thing we've had problems with from the VT...we send audio separate from the VT, directly from our recording mix, with delay to match it with the video coming from VT.

Overall, no complaints, works fine each service.
Tell-A-Vision Media Ministry

[billmi]

Signal Flow:
CCU - SDI - Program Switcher - Component Matrix - Recording Decks
- Component - VT4.6 - Component Matrix - IMAG/Web Stream

Most of the time we just feed the program switcher through the matrix to the VT and just use the VT to overlay graphics for IMAG...VT is also on standby just in case there is a problem with the program switcher.


Interesting, most times when folks talk about a switcher with the VT they are running the switcher in standby in case the VT has a problem - based on the belief that a pure hardware switcher will be inherrently more stable than one running Windows.

Why the choice to primarily use the switcher, rather than switch in VT?

[TAV Media]

Interesting, most times when folks talk about a switcher with the VT they are running the switcher in standby in case the VT has a problem - based on the belief that a pure hardware switcher will be inherrently more stable than one running Windows.

Why the choice to primarily use the switcher, rather than switch in VT?

Well, exactly for the reason you said. I've only had one service where I had a problem with the hardware switcher.

There was a time when we constantly had to reset the VT due to some challenges with video drivers. It seemed like an update was out every few weeks...so I decided to stick with the hardware switcher mostly.

We've had no problems lately, and I've been pleased with the purchase. I believe all of the minor challenges I've had would have been solved with the purchase of the SX-84, as I'm still using the SX-8 from the old VT3 system. I've found that the way we run things now minimizes our chances to experience problems in our service production.

[jsanfilippo]

We use VT 4.6 weekly in our church productions. We run 3 CCU'd sony cams, multiple DDRs with videos, lower 1/3s, preservice slides, and DSK Easyworship running on the VT machine itself. We record Type 2 DV back to the array. We are now 99% stable. A few issues occassionaly. (it hiccuped yesterday for the second time on the capture) :P

Still fighting latency issues. I would *estimate* 6 - 8 frames. Everything is locked to an external BBG. Speaking of - I once saw a screenshot of some utility (looked like a command prompt window) that showed if VT was locking to the blackburst... but I can't find that utility, or the post. Anyone know about that. Sometimes I wonder if VT is actually syncing properly.

[Cineman]

Still fighting latency issues. I would *estimate* 6 - 8 frames. Everything is locked to an external BBG.
Man, that is an easy fix Jamie. Quit making your VT wait to genlock to the BBG. Drop that out of the system. Genlock your cameras to the VT. Advance the vertical sync on the cameras until they glitch, and back off the minimum.

Cut your latency to half of what you report.

Nes Gurley

[jsanfilippo]

I did that at one point and saw a "slight" improvement in latency. Not as dramatic as you suggest.

However, several months ago, Jef Kethley was up at my location doing some onsite repairs to my VT (Jef's the man!), but after he left, I was having sync issues. The DSK would flicker whenever changing cameras on the preview bus.

We figured it was a sync issue, and when I switched it from syncing off the VT to syncing off the BBG, that sync issue went away. I noticed a SMALL increase in latency, but nothing significant. I've never been able to reduce it to nearly imperceptible. It's not in the DA's or projectors much - I've tested straight from camera direct to DA and on to projectors, and there is virtually no perceivable delay.

I know you are the guru Nes.... any ideas on this?

[Cineman]

The DSK would flicker whenever changing cameras on the preview bus.
I have never seen flickering on Program Out from the DSK except when using 3rd Channel, and I would call that flashing. And it didn't require switching cameras on Preview to see it.

My CPU cycles would be maxing out during this time. Did you ever check your CPU utilization when you had the flickers, or switched cameras on Preview.

We figured it was a sync issue, and when I switched it from syncing off the VT to syncing off the BBG, that sync issue went away.
Well it definitely reads like a sync issue, but of such magnitude to indicate that your cameras were both tremendously maladjusted, vertical sync delayed instead of advanced, and definitely not genlocked to the VT.

Where did you tap video out from the VT to genlock the cameras? How did you connect video out from the VT to the cameras? Did you or Jef advance the vertical sync on the cameras?

I noticed a SMALL increase in latency, but nothing significant.
Another indication that your cameras were not genlocked, but Jef would have surely noted that.

But, and this is from your other post, if you are going to solve this, you are really going to have to test, and quit relying on your perception. You can test to the nearest field.

I've never been able to reduce it to nearly imperceptible.
See above. " Imperceptible" is a relative term as well.

For what I said, you gave me an out by saying "6 - 8 frames". I have never, ever, failed to genlock a VT to more than 4 frames. I have got stuck at four sometimes when NewTek now says I should get less. I think that they are addressing video in to video out, not through a projector.

Four frames is not imperceptible if you are studying it, looking for it; especially with fast motion. I have done a lot of observing and totally agree with what Tim Jenison first told me: "Generally an audience will not perceive anything under six frames."

It's not in the DA's or projectors much -.
But I submit there is some. And I'm going to assume that you are estimating.

I've tested straight from camera direct to DA and on to projectors, and there is virtually no perceivable delay.
"Perceivable" this time? One DA. But you use plural above. Do you use a DA between the camera and the VT, and another between the VT and projector? How are you distributing, and why? I have done three hundred foot composite cable runs without using a DA. I have removed DAs with no "perceptible" loss of signal using "Blue Only" on the master monitor.

Let's see. There was one other thing. Oh. Do you have the separate genlock card, or the later VT Card with genlock.

We'll get it if you want to dig in. I can come to Toronto. I have only been to Matrox in Montreal.

Nes Gurley

[jsanfilippo]

I have never seen flickering on Program Out from the DSK except when using 3rd Channel, and I would call that flashing. And it didn't require switching cameras on Preview to see it.


My CPU cycles would be maxing out during this time. Did you ever check your CPU utilization when you had the flickers, or switched cameras on Preview.

Thanks for the thoughtful response, Nes.

No I didn't specifically. But at other points when Jef and I were watching system stats, the CPUs never maxed.


Well it definitely reads like a sync issue, but of such magnitude to indicate that your cameras were both tremendously maladjusted, vertical sync delayed instead of advanced, and definitely not genlocked to the VT.


Where did you tap video out from the VT to genlock the cameras? How did you connect video out from the VT to the cameras? Did you or Jef advance the vertical sync on the cameras?


Another indication that your cameras were not genlocked, but Jef would have surely noted that.


I'm not sure. I'm not a timing/scopes expert. To be fair to Jef, we weren't looking at latency. We were fixing hardware problems on the VT itself. While I know he was inside the menu's on my CCUs, I don't think I saw him change anything in terms of timing. Which is the wierd thing. He changed graphics cards and drivers, had Newtek supply a new VT card, and did some BIOS tweaks. What in that process could throw off timing????


But, and this is from your other post, if you are going to solve this, you are really going to have to test, and quit relying on your perception. You can test to the nearest field.


See above. " Imperceptible" is a relative term as well.

For what I said, you gave me an out by saying "6 - 8 frames". I have never, ever, failed to genlock a VT to more than 4 frames. I have got stuck at four sometimes when NewTek now says I should get less. I think that they are addressing video in to video out, not through a projector.

Four frames is not imperceptible if you are studying it, looking for it; especially with fast motion. I have done a lot of observing and totally agree with what Tim Jenison first told me: "Generally an audience will not perceive anything under six frames."


But I submit there is some. And I'm going to assume that you are estimating.


I am estimating. I will test today and post my results. I'll use the "flash onstage, second camera recording the flash and the IMAG screens" method and then measure it in Vegas. It is definately perceptible to the general audience. I've had a few people comment on it. If I could get it to "nearly imperceptible" as you suggest, I would be very very happy.

"Perceivable" this time? One DA. But you use plural above. Do you use a DA between the camera and the VT, and another between the VT and projector? How are you distributing, and why? I have done three hundred foot composite cable runs without using a DA. I have removed DAs with no "perceptible" loss of signal using "Blue Only" on the master monitor.


1 RGB DA going from SX-84 out up to the projectors. No DAs from CCU to VT - straight from the CCU.

"Let's see. There was one other thing. Oh. Do you have the separate genlock card, or the later VT Card with genlock.

It is the latest card with Genlock. The card was replaced in December.

"We'll get it if you want to dig in. I can come to Toronto. I have only been to Matrox in Montreal.

Nes Gurley
I would be interested in discussing the idea of bringing you up here. Like I said, I will test how many frames delayed it is, and will post here this afternoon. In the meantime, do you wanna drop me an email (address listed below) and we can kick the can about having you come up to look at this issue with me?

Peace,
jamie

[Cineman]

I'm not a timing/scopes expert.
Seeing the results of having advanced the vertical sync too far is the easy part. You only have to look at the video output. I suppose one could see flashing/glitching video if a step hit the right spot. In that case, one more would show bad output, probably the top of the frame moving down about a quarter of the screen. The top area may seemingly show the bottom part that was cut off. You are actually seeing parts of two frames.

The hard part is actually finding the place to adjust. Seems every camera has its own place for adjusting, usually called "advanced menus". Prosumer camcorders may only have these available at the service center level.

To be fair to Jef, we weren't looking at latency. We were fixing hardware problems on the VT itself.
Maybe you could E-mail me details of exactly what hardware problems you were fixing and how they manifested themselves.

While I know he was inside the menu's on my CCUs, I don't think I saw him change anything in terms of timing. Which is the wierd thing.
See above. I think that you would have noticed. As far as his not doing that, I can certainly see his not concerning himself if you were not chasing latency at all.

It still seems to me to be so backwards of anything that I can imagine. Are you absolutely positive that you did not have the VT genlock connected to the BBG when you had the cameras genlocked to the VT, and had the problem with the DSK signal flickering.

I can really visualize having the flicker problem that way. The VT is not using its own clock. Instead it is timing itself from the BBG output. I can really see it struggling to time its computer generated sources (on DSK), while, at the same time, trying to genlock the cameras (the preview switching) to itself (the BBG, in this case).

EITHER EVERYTHING, OR NOTHING, SHOULD BE CONNECTED (GENLOCKED) TO THE BBG.

second camera recording the flash and the IMAG screens" method and then measure it in Vegas.
Sounds like you are using a camcorder and ingesting that into another editor. That would induce more latency than actual from the camcorder processing. You could record using one of your service cameras on the VT and measure by scrubbing that footage in VT Edit.

Either way, could you also record the flash and the display of that on your master monitor connected directly to the VT? That would allow us to measure the difference in delay through the VT and at the projection screen.

1 RGB DA going from SX-84 out up to the projectors. No DAs from CCU to VT - straight from the CCU.
All good news in your second sentence. I suppose that the RGB DA may be necessary for feeding the projectors as you are doing it. Have you ever fed the projectors video and have them apply the scaling? The VT is a video appliance. It outputs video, which must be scaled at some point, prior to being projected.

Could you test with feeding video to a projector and allowing that to do the scaling instead of the VT computer? I could show less latency. Taking video for each projector from the SX-84 would eliminate the need for the DA.

drop me an email (address listed below) and we can kick the can about having you come up to look at this issue with me?
I posted from my E-mail before starting this, but want to say a word to anyone reading along. There are many times that I think that I could solve a problem if I could just be on site. At the same time, I really want to have confidence that I can fix, before anything more than time is spent. That often results in such long exploration as here, finding the problem through discourse, and getting fixed that way, eliminating the necessity for travel and opportunity to learn on site, be new places, and meeting some great people.

Success is its own reward. I have both experienced the sadness of worship being ruined from latency in IMAG, and video being a great reinforcement when it works. It has become an important part of my life.

Nes Gurley

[jsanfilippo]

Seeing the results of having advanced the vertical sync too far is the easy part. You only have to look at the video output. I suppose one could see flashing/glitching video if a step hit the right spot. In that case, one more would show bad output, probably the top of the frame moving down about a quarter of the screen. The top area may seemingly show the bottom part that was cut off. You are actually seeing parts of two frames.


It's hard to say what was happening, because it was lower thirds that would flicker in the DSK - not another camera source. The DSK would flicker ONCE nearly every time I would change cameras in Preview. When changing computer generated sources in Preview, it was fine.


The hard part is actually finding the place to adjust. Seems every camera has its own place for adjusting, usually called "advanced menus". Prosumer camcorders may only have these available at the service center level.


My cameras are are DSR-390 ENG cameras with D-50 CCUs

Maybe you could E-mail me details of exactly what hardware problems you were fixing and how they manifested themselves.


General system instability, GUI lockups, blue screens, etc. Turned out to be primarily a graphic cards/drivers issue.

See above. I think that you would have noticed. As far as his not doing that, I can certainly see his not concerning himself if you were not chasing latency at all.


I don't THINK we discussed latency at all. We spent alot of time on other stuff.... an extra 8 hours beyond what was planned. Jef was good enough to delay his flight.


It still seems to me to be so backwards of anything that I can imagine. Are you absolutely positive that you did not have the VT genlock connected to the BBG when you had the cameras genlocked to the VT, and had the problem with the DSK signal flickering.

I can really visualize having the flicker problem that way. The VT is not using its own clock. Instead it is timing itself from the BBG output. I can really see it struggling to time its computer generated sources (on DSK), while, at the same time, trying to genlock the cameras (the preview switching) to itself (the BBG, in this case). EITHER EVERYTHING, OR NOTHING, SHOULD BE CONNECTED (GENLOCKED) TO THE BBG.



I am 99% certain that everything was locked to the VT. I'll go look at cabling again when I'm down there. It's simple to figure out. It should now all be tied to the BBG. I'll note who everything is tied together and post again with details.


Sounds like you are using a camcorder and ingesting that into another editor. That would induce more latency than actual from the camcorder processing. You could record using one of your service cameras on the VT and measure by scrubbing that footage in VT Edit.

Either way, could you also record the flash and the display of that on your master monitor connected directly to the VT? That would allow us to measure the difference in delay through the VT and at the projection screen.


Hmmm - not sure I follow. I understand what you are saying about the DVCam camcorder inducing it's own latency. But if I, as you suggest, record to the VT and check it out there, how do I do that? If I'm using VT to show one camera image on screen, how do I record ANOTHER camera to the VT? Can I record the Preview channel?


All good news in your second sentence. I suppose that the RGB DA may be necessary for feeding the projectors as you are doing it. Have you ever fed the projectors video and have them apply the scaling? The VT is a video appliance. It outputs video, which must be scaled at some point, prior to being projected.

Could you test with feeding video to a projector and allowing that to do the scaling instead of the VT computer? I could show less latency. Taking video for each projector from the SX-84 would eliminate the need for the DA.


Sorry - miscommunication. It's component (which is what I meant by RGB) - NOT VGA, which I think you interpreted. I'm coming out of the SX-84 as component, into a component DA and then a homerun to each projector.


I posted from my E-mail before starting this, but want to say a word to anyone reading along. There are many times that I think that I could solve a problem if I could just be on site. At the same time, I really want to have confidence that I can fix, before anything more than time is spent. That often results in such long exploration as here, finding the problem through discourse, and getting fixed that way, eliminating the necessity for travel and opportunity to learn on site, be new places, and meeting some great people.

Success is its own reward. I have both experienced the sadness of worship being ruined from latency in IMAG, and video being a great reinforcement when it works. It has become an important part of my life.

Nes Gurley

[jsanfilippo]

Just measured using a strobe, recording back to the VT (never knew you could record Preview bus!)

5 frames from strobe on stage to strobe on-screen, regardless of syncing to BBG or to VT. That would include any latency introduced by DA's or projectors.

Now the question - is either of those ACTUALLY syncing, or is it all just floating? I'm not an expert - but I will post the signal path of genlock cabling later so others can weigh in.

So if all is syncing properly, then that means that I am actually probably getting the 4 that Nes suggests from VT, and picking up 1 in projector scaling, right?

That 5 isn't EXACTLY 5 - it's pretty tough to nail it down EXACTLY when measuring the flash on screen (variance is within a few hundredths of frames). It just isn't as clear cut as the real one.

Now - interesting... i noticed that there seems to be some, for lack of better term (excuse my ignorance - i'm sure there is a proper term).... phasing in the flash being picked up by the camera. It's as if the strobe happens too quickly for the refresh of the camera or the VT or something. You can see that sometimes it just doesn't appear on camera. And you can sorta see a vertical "glitch" in the program feed. It's like the Strobe accentuates this.

I recorded the program feed where this is obvious and will post either screen shots, or better yet, a compressed version of the video for others to give their thoughts.

more later.

[Cineman]

I can't keep pace with you Jamie. I know that from it seeming that I had only taken a deep breath after posting my last until there was already a reply from you. And now there is another. Forgive the ole guy Jamie. Somehow I have to keep up with the rest of my life as well.

It's hard to say what was happening, because it was lower thirds that would flicker in the DSK
Good to know.

- not another camera source.
Well, I had assumed it a computer source, and said so. There has never been a camera source available from DSK unless you consider DVCamera. That was put in, taken out, put in again, removed again. DVCamera is actually a computer source, and I don't even consider it because of the extreme latency.

The DSK would flicker ONCE
That is important news. I would normally think repeating. It supports my current theory.

nearly every time I would change cameras in Preview. When changing computer generated sources in Preview, it was fine.
As I surmised and stated.

My cameras are are DSR-390 ENG cameras with D-50 CCUs
That turned out to be real important to me. In fact, most all my time since reading this post has been spent studying this camera and CCU on the web. It is integral to my theory and everything I have read about them supports.

General system instability, GUI lockups, blue screens, etc. Turned out to be primarily a graphic cards/drivers issue.
Had guessed it and almost said. Pretty common problem. Been there, have that. Yes, said have... on my personal VT. Don't think I ever blue screened, but yes to GUI lockups, loosing video on Program, or Preview and Program, or having the video go bad on Program, or both. Shutdown VT and on restart ends up telling me "Drivers Problem". Have reinstalled drivers, same from Nvidia sometimes, but restarting the system usually works.

One mystery. You have always said graphic cards... plural. Would expect that you have dual head, but do you really have multible video cards in your VT computer?

I am 99% certain that everything was locked to the VT. I'll go look at cabling again when I'm down there. It's simple to figure out. It should now all be tied to the BBG. I'll note who everything is tied together and post again with details.
Good. Would you tell me just one thing in reply to this post... When you had the cameras genlocked to the VT, for each, you took a video output from the SX-84 and connected it to something. What was that something? Besides disconnecting genlock from the VT card to the BBG, did you do anything else?

I understand what you are saying about the DVCam camcorder inducing it's own latency.
Good, except that I now think that I am wrong about this. So what, if it adds latency? What we are trying to measure is the difference in time from the camera seeing the strobe to its being displayed on the projection screen. Any latency should apply equally to both, and not matter. Right?

But if I, as you suggest, record to the VT and check it out there, how do I do that? If I'm using VT to show one camera image on screen, how do I record ANOTHER camera to the VT? Can I record the Preview channel?
Not what I've always done. Put one of your regular cameras on Main framed to show the actual strobe and it displayed on the projection screen. Set "Input" to "Main In". Name and record a clip of the strobe (several iterations).

Now open VT-Edit and load the clip. Step through it frame by frame with the right arrow key and count. Measure from strobe on to projection screen strobe on. Check yourself by doing same from strobe off to projection screen strobe off. Doesn't that work?

I may be able to explain if you get a one frame difference. I may be able to explain if your first iteration is different than the others.

Sorry - miscommunication. It's component (which is what I meant by RGB) - NOT VGA, which I think you interpreted. I'm coming out of the SX-84 as component, into a component DA and then a homerun to each projector.
Sorry - miscommunication. Don't know who was wrong, if anyone. Think that we were bound to do it at some point.

I am going to resist the temptation Jamie to get into your other post. I'll do the same with my belief that I have your problem solved. Which problem? Both. Both the flicker on DSK, and the IMAG latency. Just tell me correctly and completely how you genlocked your camera to the VT. If what you say supports my theory and I don't get a different revolution over night, or in the shower; I'll explain it. We'll test it at your site.

If all holds true, I can tell you that we have helped Jef, NewTek, and a lot of people, those with, at least, Sony CCUs. This is bigger than the both of us, and isn't that the Church way?

Nes Gurley

[Cineman]

I really didn't type those two sentences in five minutes? Since it appears that I may be saying "Mother may I" into next week, would you please consider that the following should be inserted after the first line below, near the end of the original, into my last previous post.

were bound to do it at some point.

I would sure like for you to get rid of that DA. If you are short of Component Video outputs, I would rather that you put a T Connector on each of the three BNCs that your using already and send each side (assuming that you have two) to a projector.

Nes Gurley

[jsanfilippo]

Wow - can't wait to dig into this more Nes!
I'll get to it later today.

Peace,
jamie

[jsanfilippo]

I can't keep pace with you Jamie. I know that from it seeming that I had only taken a deep breath after posting my last until there was already a reply from you. And now there is another. Forgive the ole guy Jamie. Somehow I have to keep up with the rest of my life as well.

Many people have trouble keeping up with me! I'm extremely energetic and ADD! :)


Well, I had assumed it a computer source, and said so. There has never been a camera source available from DSK unless you consider DVCamera. That was put in, taken out, put in again, removed again. DVCamera is actually a computer source, and I don't even consider it because of the extreme latency.


Just to be clear - the DSK is always a computer source. I either put lower thirds in a DDR and key them, or I run Easyworship on the VT, chromakey it and put it in the DSK using VTCapture utility. Works slick. I NEVER NEVER use DV on my VT.


That is important news. I would normally think repeating. It supports my current theory.

...

As I surmised and stated.

...

That turned out to be real important to me. In fact, most all my time since reading this post has been spent studying this camera and CCU on the web. It is integral to my theory and everything I have read about them supports.


The suspense of waiting for your theory is killing me!

Had guessed it and almost said. Pretty common problem. Been there, have that. Yes, said have... on my personal VT. Don't think I ever blue screened, but yes to GUI lockups, loosing video on Program, or Preview and Program, or having the video go bad on Program, or both. Shutdown VT and on restart ends up telling me "Drivers Problem". Have reinstalled drivers, same from Nvidia sometimes, but restarting the system usually works.

One mystery. You have always said graphic cards... plural. Would expect that you have dual head, but do you really have multible video cards in your VT computer?


I have (2) dual-head cards. I use three monitors. 1 for Easyworship program (it is then captured as mentioned before). 1 for VT desktop. 1 for Easyworship control screen.


Good. Would you tell me just one thing in reply to this post... When you had the cameras genlocked to the VT, for each, you took a video output from the SX-84 and connected it to something. What was that something? Besides disconnecting genlock from the VT card to the BBG, did you do anything else?


When genlocking to the VT....
1 line from Composite output of SX-84 into vectorscope input, loop through to waveform input, loop through to cam 1 input, loop through to cam 2 input, loop through to cam 3 input, loop through to DVcam input, terminator on DVcam.


When genlocking to the BBG (this is the current config)....
BBG has multiple outputs. 1 line went from BBG to scopes and on through the path the same as above.
Second line went from BBG directly to SX-84 Genlock in. Termination set in preferences.


The problem is that I'm not 100% certain that scopes, BBG, VT, CCUs are all set properly! I am very happy with my installer, but this may have been out of their range of expertise, and they didn't have anything to do with VT itself, so they didn't go into that.


Good, except that I now think that I am wrong about this. So what, if it adds latency? What we are trying to measure is the difference in time from the camera seeing the strobe to its being displayed on the projection screen. Any latency should apply equally to both, and not matter. Right?


Very true!


Not what I've always done. Put one of your regular cameras on Main framed to show the actual strobe and it displayed on the projection screen. Set "Input" to "Main In". Name and record a clip of the strobe (several iterations).

Now open VT-Edit and load the clip. Step through it frame by frame with the right arrow key and count. Measure from strobe on to projection screen strobe on. Check yourself by doing same from strobe off to projection screen strobe off. Doesn't that work?


Yes - I understand. I made it more difficult than necessary by using two cameras.

I may be able to explain if you get a one frame difference. I may be able to explain if your first iteration is different than the others.


Sorry - miscommunication. Don't know who was wrong, if anyone. Think that we were bound to do it at some point.

I am going to resist the temptation Jamie to get into your other post. I'll do the same with my belief that I have your problem solved. Which problem? Both. Both the flicker on DSK, and the IMAG latency. Just tell me correctly and completely how you genlocked your camera to the VT. If what you say supports my theory and I don't get a different revolution over night, or in the shower; I'll explain it. We'll test it at your site.

If all holds true, I can tell you that we have helped Jef, NewTek, and a lot of people, those with, at least, Sony CCUs. This is bigger than the both of us, and isn't that the Church way?

Nes Gurley

Again - the suspense is killing me. Can't wait to keep digging together. Thanks SO MUCH for the time spent already Nes. Come on up to Toronto and let me treat you! :)

[timjenison]

Oops. Forum ate my reply. I'll try again.
Nes, I should have said 6 fields, not frames. 4 fields, 2 frames, is perceived as perfect lip sync, anything more starts to get noticable.

Distribution amps and cable length will not affect latency. Their delay is in the billionths of seconds. One foot of cable gives you a delay of about 1 billionths of a second (1 nanosecond).

Latency is measured in thousandths of a second, milliseconds. 2 frames is 66.6 milliseconds.

To delay video enough to see latency, you need memory chips. Memory chips are found in modern cameras, time base correctors, VTs, scalers and projectors.

When thinking about audio delay in a large hall, note that in the time of one video field, sound travels about 18 feet.

So, if you had 6 fields of latency, you could move your chair back 36 feet and you would be back under 4 fields difference between audio and video.

PAL is a little worse.

[jsanfilippo]

So Nes.... had any time to consider my reply? I'm sure you are ready to work some serious magic for me!

[Cineman]

Oh my goodness Tim, I really can't express my appreciation for you spending some of your busy time to post on this. Since I have become so involved with helping Churches on their latency issues with IMAG, I really did need to be straightened out on it.

I also must try and make things right with Andrew since he has told me exactly the same as what you now have. I stood my ground, partially based on what you had said, but, hope/pray that I had the good sense not to say: "but Tim told me...". Instead, I argued from my test findings which seemed to nearly fit the 6 frame paradigm.

For a long time I, sometimes found 3, but mostly found 4 frames of delay in testing camera image of the strobe light through same on the projection screen with genlocked cameras. Poor video engineer that I am, it took some time before I thought of the fact that I could measure the scaler delay by also shooting the strobe and its reproduction on the master monitor. It also took some time to realize that I could scrub/recognize a field error on the VT (half bright strobe + every other scan line).

You may remember Tim, that we also talked about how, once perception of delay is recognized by the viewer, how impossible it is to stop noting it. I had many silent arguments with you about how I definitely could perceive 3 & 4 frames of latency. I dismissed that, once the genlocking was accomplished and the base delay of VT halved to (I think) 66.6 milliseconds, same as on the Amiga Toaster, and the congregation stopped complaining.

And lastly, it is sadly funny that I have basically had most all the things you say about audio below in my pocket, and never did the math to know that such would be a major disconnect with the field, frame video delay.

Nes, I should have said 6 fields, not frames. 4 fields, 2 frames, is perceived as perfect lip sync, anything more starts to get noticable.
Dear Gentle Reader,

I hope you wouldn't, but don't make the mistake that I did on first reading the second line above. Of course, 0 fields would be actual lip sync. Tim is addressing the point where perception will start.

Distribution amps and cable length will not affect latency. Their delay is in the billionths of seconds. One foot of cable gives you a delay of about 1 billionths of a second (1 nanosecond).
I basically knew about cable length. When you visited my facility here at Army, Redstone Arsenal, if you had stepped behind the racks in the control room you would have found that the whole section below the shelf full of coiled coax. That was basically just to delay the cameras vertical interval to the old original delay bricks that did most of it. I used to kid engineering that they should have left the cable on the purchase reels and just cut some off if necessary.

Being generally comfortable with long cable length, that allowed me to pull off DAs in an attempt to remove latency. Am afraid that I was just coming to the realization that they caused little (now known to be none). Guess I should have known when pulling two from a single coax camera cable run I still couldn't find even a frame, or interpreted field, of difference.

To delay video enough to see latency, you need memory chips. Memory chips are found in modern cameras, time base correctors, VTs, scalers and projectors.
Please note Jamie, "time base correctors" in the above statement. That is exactly what caused me to start to my new theory about latency and also the glitch you were getting when switching cameras on Preview on the VT. That came to eye while studying the new TriCaster STUDIO specifications, and makes me worry that the STUDIO might have more latency than the other TriCasters and current VTs.

Studying TriCaster STUDIO is part of what I have been doing while not posting, along with studying your cameras and CCUs on the Sony web site.

For this post I'll just say Thanks Again to Tim. I think the timing was good to save Jamie some time from his willingness to test all that I've asked. Perhaps it will also lead to fixing a problem with, particularly, Sony CCU use and flashing when switching cameras on Preview during a VT (even TriCaster) Live Switch.

Nes Gurley

[Cineman]

OK, I was going to work with Jamie off forum, and see if we could modify and test his system by remote, and then get back here if we had positive results. But I just can't resist commenting a couple of things here. Maybe someone else might add something about any advantage he gains from having the scopes where he does.

When genlocking to the VT....
1 line from Composite output of SX-84 into vectorscope input, loop through to waveform input, loop through to cam 1 input, loop through to cam 2 input, loop through to cam 3 input, loop through to DVcam input, terminator on DVcam.
:( I didn't quite get the answer that I was looking for, although I think it is obvious from what you did say. I also got zapped by your signal path, some of the equipment you loop through, though high falutin in nature, seems totally useless at the point used and totally redundant to your system. I think that I can get back to that below and hopefully make it less confusing.

I'll get back to the original question.

loop through to cam 1 input, loop through to cam 2 input, loop through to cam 3 input, loop through to.....
You can split at the "Genlock In" connector on the camera, but not loop through. They are terminated at the camera. You could loop through by then taking video out from the camera to "Genlock In" on another camera. (Not recommending here.)

I have this nagging memory that you have said that you were genlocking to the CCUs (which do have a loop through {a part of my theory}) at some point but could not find it on this thread. I have same memory of having replied to that with the suggestion to move the genlock in to the camera heads themselves.

BBG has multiple outputs.
So does the SX-84. Remember that any unused component outputs will provide multiple composite outputs.

The problem is that I'm not 100% certain that scopes, BBG, VT, CCUs are all set properly! I am very happy with my installer, but this may have been out of their range of expertise, and they didn't have anything to do with VT itself, so they didn't go into that.
Now I can get back to the concern I had with your signal routing. What possible advantage can there be for having a vectorscope and waveform monitor after the VT output? I wouldn't dare adjust a camera at that point as, for instance, raising the gain, might blow out your next DDR still or clip. It is too late for using them for anything, that I can think of.

Besides you already have both vectorscope and waveform monitor on the VT, positioned so that they can be used to adjust anything needed. This is why I would suggest to anyone to have a good dealer, such as Jef, design their whole system. A major part of my consulting is designing systems for Live Switch, so that folks will have what they need and not buy things they don't.

Again - the suspense is killing me. Can't wait to keep digging together. Thanks SO MUCH for the time spent already Nes. Come on up to Toronto and let me treat you!

First Jamie; I never conceived that a planned "most of one day" out of the facility would turn into three of four, but probably should have. I also didn't think about the fact that my compatriots would be returning from NAB and posting about things NewTek and otherwise that they saw and heard about. I kinda consider TriCaster my baby, having dreamed up, at least a "OneCaster" version well before anything came out of NewTek about it. I returned after the first day out to over 150 new posts on new NewTek new and more, and haven't come close to catching up with those added since.

Promise that this hasn't been some promotional tease, though my hand is sore from back patting at having thought it up. I have calmed down now, but not lost faith that it may work. And yes, I still think that we should prove it or not in your facility before sharing. No point in reams from Nes if it doesn't work.

[PIZAZZ]

I can shed some insight into Jamie's situation. I have seen the system first hand and it is configured correctly. The Genlock signal is routed correctly along with the Output Signal.

From my experience not only installing VTs but also using VTs/TCs in MANY live IMAG situations, I believe unfortunately Jamie is at the lowest Latency he will be able to achieve.

His Signal path is at the bare minimum with no extra signal processors inline.

Cameras to VT to YUV distribution amplifier to Projectors.

He can eliminate the YUV DA but I don't feel like he will gain anything by doing that. I use the multiple outputs of the SX84 instead of a DA. It is worth a shot to at least bypass it for a test. Just time not money.

I suspect that the Projectors are adding in a couple frames of Latency. I have seen some projectors add more than others. Much depends on the projector and whether or not the internal scaler is engaged. Sometimes you can turn it off and sometimes you can't.

Due to some issues that Jamie was having with the component YUV video out of his cameras into the VT, he had to fall back to composite from the CCU to the VT. Unfortunate but necessary. I worked with Tim and Kevin in Newtek Engineering trying to figure out what was going on with his inability to accept YUV from the Sony CCUs. This is a documented problem that we tried to solve but it basically came down to having to invest into special filters for each connection. We did not work on Latency issues since I was concentrating on making his setup more reliable and getting the best video input possible.

I wish there was a simple solution to this latency situation but there isn't. I wish I could be proved wrong for Jamie's sake.



Well there is a simple solution. A $39 Radio Shack push button switcher has ZERO latency in it.