View Full Version : Tricaster 850 Latency Test

10-25-2011, 03:53 AM
I finally had the time to do a little latency test with our Tricaster 850 and the new Rev3d Firmware. Actually I thought I would get some better results with this firmware but these are similar results compared to the old Rev2 firmware. The interesting part was that I was never able to get better results with synced sources. There was no difference to the unsynced tests that I made. I switched on Genlock at the Tricaster settings but I never got better results compared to the unsynced tests.

Please look at the attached images that were labled "ns" for non synced and "s" for synced.

The setup that I used was:

TC850 with Rev3d firmware.
HPX502EN Camcorder
Kramer Master Clock
Acer full HD Monitor connected to Multiview out of the TC

There was nothing else connected to the Tricaster than the camera on SDI input 1 and the monitor on the multiview output.

Here are the results:

In 1080p25 I got about 5 frames of latency with an unsynced camera.

In 720p50 it is a little bit difficult to explain the lantency because the camera still records a 25fps timecode. So what you actually see here is a latency of 6 frames (in50p) but the overall latency compared to the 1080p25 is better (3 frames compared to 5).

The last test was an SD test with 576p25 over 576i50. I got 4 frames latency with unsynced camera.

I saw that there is no caption or title under the images so here is the description:

Picture 1: SD 576i50 ns
Picture 2: SD 576i50 s
Picture 3: HD 720p50 ns
Picture 4: HD 720p50 s
Picture 5: HD 1080p25 ns
Picture 6: HD 1080p25 s (This picture is inside the next post #2)


10-25-2011, 03:54 AM
Last picture with 1080p25s.

10-25-2011, 06:22 AM
I wasn't able to locate info on the "Kramer Master Clock" online, but assume what we're looking at in your photos is a splitscreen (mid-wipe) shot of output from one TriCaster's outputs displayed on a downstream monitor, presumably with the clock display direct from the camera on program, and .. what, exactly, on Preview? (I'm sorry, I probably just need a coffee, but it's not really clear to me exactly what I'm looking at here.)

10-25-2011, 09:41 AM
Yes exactly - you are right. I superimposed the original camera timecode to the output. The camera was connected to SDI input 1 of the 850 then this signal was sent to PGM output. Then I pointed the camera towards the PGM monitor of the Tricaster and recorded inside the camera.

After that I played back the recorded file inside the camera and paused it. Then I took a photo of the LCD screen where the original recorded timecode (TCR) of the clip is shown in the upper part of the picture, and the same superimposed timecode that was coming out of the Tricaster is shown in the lower part.

The difference should be the throughput latency.

For 1080 i got 5 frames
720p50 6 frames
576 4 frames.

That is exactly what we experienced in our productions where it was nearly impossible to use the Tricaster for IMAG purposes.
3 frames are barely acceptable but 5 frames are out of discussion for our clients.

I used this unit:




10-25-2011, 09:55 AM
The difference should be the throughput latency.Well, I'm not 100% sure that's correct. I'll ask for a second opinion as these things can be convoluted, but it seems to me that in this setup, the difference displayed in your final photo includes the accumulation of a) TriCaster's own throughput latency (the camera's timecode display transiting TriCaster and appearing at its Program output) and b) latency added by the monitor connected to the Program output (which can be considerable).

There are other delays in the setup, but if I'm looking at this correctly, I think they are negligible in the end.

[Edit: I had added this earlier, not sure how it got lost, but anyway - just as a related thought, I want to quote something Dr. Cross wrote previously: "Genlocking does not assure you lowest possible latency, what it does is assure you absolutely constant latency (by making sure that all clocks are based on the same reference time). You can then use the phase controls associated with Genlock to get the minimum latency."]

10-25-2011, 10:42 AM
Just to let you know, the consensus here is that your test adds monitor latency in between the two timecode displays as captured. The amount of monitor latency can vary quite a bit - an LCD can be quite bad, or not so much, and a CRT doesn't add much. But our internal testing of TriCaster throughput latency alone consistently produces significantly lower results.

You might want to try this method (there are similar approaches, this is just one):

Drop a timecode clip into a DDR (make sure the clip is session format). Select the DDR on on Program and hit play.
Connect Program out back to a TriCaster input
Select that input on Preview.
Take a picture (or do a screengrab) of the Live Desktop showing the Preview and Program monitors.

10-25-2011, 11:35 AM
I'm curious about camera latency, too, from the lens to the sdi output.

10-25-2011, 11:38 AM
I'm curious about camera latency, too, from the lens to the sdi output.I agree it's another possible source of (non-TriCaster) latency in this scenario. (It may be quite negligible, or not, depending on internal design and active settings.)

10-26-2011, 02:26 AM
What you should do, is have 2 identical monitors:

- one connected directly to the SDI output of your Kramer unit
- one connected to the SDI PGM out of your Tricaster.

Then, connect the second SDI output of your Kramer-unit to one of the SDI inputs of the Tricaster. Now, put both monitors next to each other, and film/photograph that, with both monitors together in your shot. This way, you eliminate the variables, and have output from your source and going through the TC next to each other. If the monitor adds delay doesn't matter anymore in this setup: both will add an even amount amount of delay (if any), but the difference between source and output is still the same.

Key is: use 2 identical monitors next to each other, and make sure you do not add any converters. Straight SDI for the whole chain!

Please post images of these results!

10-26-2011, 04:54 AM
Key is: use 2 identical monitors next to each other, and make sure you do not add any converters.Yep, that's valid too, providing the monitors are configured identically. If you really want to confirm all variables have been accounted for, switch monitors and do it again. Another interesting thing to do would be to include the timecode generator's own display assuming it has one) in the photo. This would give you an idea how much latency the monitors are adding (this wouldn't be detectable otherwise).

12-12-2011, 01:23 PM
I did an event last week and we got quite a few complaints about the latency on the screens... so I decided to do a test. We were using XL-H1 cameras coming out HD-SDI. They were genlocked. In the test I did below, I do NOT have the camera genlocked... I'll run that test later. In any case... the first image is just the camera, straight HD-SDI to the monitor. This test shows about three frames of latency (IPad clock on the left, down stream monitor on the right). When I run through the Tricaster, I get 6-7 frames of latency, showing that the addition of the Tricaster into the chain added about 3-4 frames of Latency. I did notice that adding the Lens Stabilization added an additional frame of latency coming out of the camera.

Just thought I'd share.

12-12-2011, 01:30 PM
What app is that?

12-12-2011, 01:34 PM
It's called: "Take One"

12-12-2011, 01:58 PM
Excellent data - thank you!

I am especially interested to see that camera settings (electronic stabilization, in this case) will add additional latency, as that was a question I posed earlier in this thread.

It is definitely a challenge. If we're at 3 to 4 frames between camera and display device, and then we add three to four more frames in from the switcher, we're definitely above the threshold of what people will notice.

12-12-2011, 02:01 PM
I agree. The XF-305 Cameras I have are at 2 frames. I don't know where the latency is in the camera, but it's definitely there.

Does anyone know what amount of frames would be considered "acceptable" for a small hall?


12-12-2011, 02:34 PM
Phil nice test and all I can add is I use Movie Slate for iPad and iPhone. Sorry to disrupt your test thread :)

12-12-2011, 02:36 PM
And I was wondering what the difference is after you genlocked?

12-12-2011, 04:23 PM
100ms - 3 frames - is generally considered to be the threshold of human perception of lip sync.

12-12-2011, 04:40 PM
Hey Phil -

I'm going to do some experiments, too, with different output resolutions on the camera. Our HVX170s will let us shoot, record, and output in different resolutions. I'm betting, if I record and output in the native resolution of the sensor, I get the lowest latency out of the camera.

I also would like to test the VGA output, Component output, and SDI outputs of the Tricaster simultaneously. I don't have an SDI monitor, though, of all the things to not have...

12-16-2011, 02:50 AM
Hi all,

I had the chance to test the latency again with the suggested setup (movie slate app for IPad, SDI Monitor).

It turns out that my SDI Monitor and the camera has about 3 frames of latency. When I feed the camera to the Tricaster I get around 6-7 frames of latency. That means that the TC has a latency of 3-4 frames.

I had the chance to test the same setup with an ATEM TV-Studio recently. That switcher had a latency of 1 (ONE!) frame from input to output with exactly the same setup and unsynced cameras. I can post some screengrabs here if you like.



12-18-2011, 05:51 PM
My understanding with the Atem is that you can eliminate input and output scaling if everything is the same resolution throughout. If you start mixing resolutions, the scalers add a frame, just like the Tricaster. I also read one port that adding an overlay in the Atem would cost a frame. So I would like to know more about your full experience with the Atem... As BMD claims one LINE of delay.

But if the Atem really performs that quickly, it gives us a good comparison, even though it's not as full featured. Broadcastpix is closer, and currently equivalent.

12-19-2011, 01:56 AM

you are absolutely right in your assumption that the Atem does this low delay performance by only using a frame buffer at the input stage.

It has no scalers for the inputs so every input must be the resolution that you set in the switcher. You cannot mix resolutions.

If you use a DVE (f.e. an overlay) you loose another frame but only on the DVE not on the background. That would be 2 frames which is still really good.

So in regular switcher operations (cut/disolve/wipe) you only have a delay of one frame from input to output which is absolutely normal for a switcher that uses unsynced cameras. I think with genolocked cameras you can lower the delay even more and that is where the press info of BMD comes into play (delay: 1 line).

The Atem takes about 3-4 seconds to power up. After this time the switcher is ready to operate.

The big downside of the Tricaster is in my opinion the delay (3 frames) that cannot really be lowered. As I understand it the Tricaster does a framesync at the input stage (1 frame) AND a scale, no matter if you have the matching resolution (+1 frame). And there must even be another processing - maybe at the outputs that cause another frame of delay.
If you add 1 frame of delay from your camera (typical) and maybe 2 frames of delay for your projector you end up with 5 frames. That is not acceptable for me for imag purposes. 5-6 frames is what I typically get if I use the TC for imag. That is a real-life experience. In PAL land that means 40ms for 1 frame and 240ms in total. You can lower the absolute time of the delay by using a 720p50 (in PAL land) preset, that still gives 5-6 frames of delay but in this mode 1 frame is only 20ms long - that means 120ms in total.



12-21-2011, 10:38 AM
I guess I am missing something here, but why are we so concerned about latency? It is what it is and even at 5 frames it does not seem significant. And many things before and after the Tricaster add latency. Obviously you would not use Tricaster audio out for house sound if you are doing IMag. But I am pretty sure most, if not all, audiences would not really care too much about a few frames of latency.

12-21-2011, 10:40 AM
I haven't had the first lick of complaint or probably even recognition from an audience; it's always the event planner or the in-house AV provider that helpfully points it out. :-P

12-21-2011, 10:51 AM
Well actually if someone points out that it is not important if you get 5 frames of delay or not for imag - my opinion is that he has no idea how a professional imag job is done.

If 5 frames of latency aren't an issue then why do all the big imag productions for concerts or big venues only have little to no delay?

I have many complaints about lipsync issues when we do imag with our Tricaster. Not only from the event planner or the client but also from the audience. 5 frames are not acceptable to me. But we all have different opinions on how professional work is done.

And btw. there is absolutely no way to convince a sound man to run his house audio through (a computer based) Tricaster. That would be an absolut nightmare if I knew that the audio would run through my Tricaster.
Anyone with a little experience in big events would know this.



12-21-2011, 11:16 AM
And btw. there is absolutely no way to convince a sound man to run his house audio through (a computer based) Tricaster. That would be an absolut nightmare if I knew that the audio would run through my Tricaster.It's generally necessary to run the audio to the TriCaster for recording purposes, but normally running it through TriCaster would only be used to feed downstream broadcast needs (including streaming a/v, of course, but other offsite transmissions as well as remote monitoring as well). Local house audio in an IMAG setup would not run through TC as a rule.

12-21-2011, 11:42 AM
Well "Pro", I guess you can not use a Tricaster if the latency is a big issue with your clients and meeting planners. Honestly, I have done many "professional" iMAG jobs and have not found the latency to be an issue. And of course you would not run the audio through the Tricaster. If you have a "professional" solution to the Tricaster latency problems your event planner complains about, how about letting us all know. I am not sure how you can get the latency lower than it is in the Tricaster. But maybe you do. Please let us know. And, when you are doing iMAG for a concert you are usually in a large venue and there is automatically audio delay due the the physical distances sound has to travel and that its rather slow speed compared to the speed of light. So latency is everywhere in the environment you are working in. We primarily use the Tricaster for making the recording and the streaming of the event and some other entity does the iMAG with other switching equipment.

12-21-2011, 11:46 AM
I agree for the most part. The times we've been asked to go ahead and implement the delay have mostly been for big concerts, not spoken word. And then, we always use the console or a pro audio delay to do so.

These are absolutely NOT cases where the delay was made to compensate for the delay of the Tricaster; it was made to center the time alignment point in the middle of the audience. Designed intention versus making up for a slow piece of gear.

12-21-2011, 12:02 PM
The only "trick" that I have right now is to use a high fps preset like 720p50 or in your case 720p60 that lowers the delay to 50%. That causes about 120ms delay which is OK but not ideal. Everything under 100ms is perfect. That is something that all AV-Guys learn here in Germany. That would mean 2 frames from camera to projection.

I can only speak about our business and we had complaints in EVERY imag situation that we had with the TC. I know that the TC has only 3 frames of delay but in conjunction with beamers and cameras you get about 5-6 frames. In PAL land that is 240ms. Spoken word is not possible with this amount of delay.

But I agree with you when you say that "you cannot use a Tricaster" for that purpose. Maybe we will buy another little switcher with less delay for that kind of jobs.



05-01-2012, 03:20 PM
Hello, nobody speak about delay and latency improvement on 855 or 8000.
Someone has info about that? We want to use 855 for IMAG on Andrea Bocelli Worl Tour Show. Now with 850 Extreme latency is too high!!


05-01-2012, 03:27 PM
The latency in the Tricaster has been a HUGE issue for me, so I was really paying attention. At NAB, they were using Canon XF305 cameras (which I have tested to have 2 frames of latency) and I thought things looked really good! It's my understanding that Andrew has really done a lot of work on reducing latency in the 855 and 8000 and they are now sharing a spec of 1 - 1.5 frames (half of the 2-3 frames we were seeing before).

Last year, I remember looking at Don Ballance and Kiki and really noticing the latency on the screens and it was just unacceptable for iMag. This year, I watched it and said, "acceptable... not perfect, but acceptable".

NOTE: On the last day of the show, Thursday, there was a TON of latency. It is my understanding from some conversations that I had, that there was an issue with their monitors and the booth had to install new monitors and do numerous conversions in the cable to get to the new monitors. I'm not sure of all the details, but there was very noticeable latency. Had I not seen the first day, I would have been disappointed. However, since the explanation, I am confident that the latency has been cut in half.

Any one else experience the same? Any "official" latency tests out there?

Great job Andrew and team! :thumbsup:


05-01-2012, 06:29 PM
I wonder who did the booth this year. Seemed to have more problems than in the past.

I heard promises about the 8000 having less latency, but no such promises for the 855. Did I miss something?

05-01-2012, 08:08 PM
They did have a different company doing the booth this year than in past years.

In any case, it is my understanding that the latency has been reduced in both the 8000 and the 855. That is what I was told during several conversations during the week.

05-01-2012, 08:12 PM
That's good to know as I plan to own both at some point. I must have missed the bit about the 855. I'm a little surprised because the hardware isn't changing. But great coding can do wonders! I'm still amazed my kulabyte encoder can do 4 hd streams on a crummy windows xp machine with an old cpu.

05-01-2012, 10:49 PM
I got confirmation that the latency would be reduced in the 855 as well.

05-02-2012, 05:25 AM
Gravy! I will definitely be testing out that feature.