Member Discussion

Lag Or Delay In Live Video Viewing?

Let me preface this question by saying that this is my first attempt at designing/setting-up a custom video system. I also do not expect a complete solution since I am a firm believer in solving things on your own. With that said, I would appreciate some input on this issue.

I set-up a simple test system running off a custom PC I built (i7 based) & a PoE Cisco 300 series switch and two Hikvision dome ip cameras. I installed a trial version of HD Witness (actually Digital Watchdog version) and for now just using the software for live viewing to play around with the system. Everything is set-up & works great except for a ~1/2 second lag or delay from the movement occurring in the FoV to the image on the screen (live viewing only). I've searched IPVM for articles/discussions on this matter, but cannot pinpoint the issue.

First, I'd like to ask if this time lag in live viewing is normal? (system not in record mode) If this is not normal, I would love any suggestions on possible directions to focus my research/training.

So not to bore you, I limited the amount of details, but will be more than happy to supply whatever info needed.

~1/2 second of delay when displaying an IP camera feed on a VMS client is fairly common.

Usually people do not notice nor care for fixed cameras in surveillance. Obviously, PTZ controls is an important exception.

Oops! I read it as 1-2 seconds of lag, not .5 seconds! Agreed .5 is pretty normal, but you can still profile if you want...:)

Start by profiling your lag: Lag, of course, is made up of several components and therefore breaking out the individual segments the lag can help to identify those areas that your time is best spent improving. Fancy tools and analyzers can do a real-good job at this, but usually just a couple informal tests will reveal the problem.

First thing to do is dedicate a ipad or smartphone to being a digital timepiece (many free apps) because some accuracy is helpful. The best situation is where you can have one of the cameras (staying on the same switch the camera was already on if possible) in the same room as your VMS monitor. Position the smartphone so that it leans up against the side beze of your VMS monitor. Have the poe cam pointed at smartphone (with the stopwatch running) as well as the live VMS output, avoid feedback by angling poe cam. Use a digital camera to take a picture of the stopwatch phone and VMS ouput screen in the same frame. Subtract the times in the photo to get an accurate total lag time. Take several measurements in a row to see what the variance is. Then take measurements by changing out parts of the system and snapping new photos to see their effect.

Some of the obvious things to try would be

  1. Have only the POE camera a switch and the computer on the network while viewing the VMS
  2. ditto above except now go to the native hikvision software or vlc
  3. try a laptop instead of computer
  4. swap your switches
  5. swap your cameras

This should give you an idea where to concentrate...

Post the pics...

Thanks John & Rukmini.

One more thing I can strike off my list to figure-out.

It still seems strange to me that a live feed would have lag though. Is the lag from the H264 encoding process? If so, does this mean if I send uncompressed video to the VMS there would much less or no lag in live viewing?

Does your admin screen look like this?

You could try that "Shortest Delay Mode" if you are not already...

If so, does this mean if I send uncompressed video to the VMS there would much less or no lag in live viewing?

So maybe its more than .5 seconds if its bothering you this much... Just get the stop watch phone like I mentioned and then you can check out the difference between MJPEG set to the least compression vs. H.264 set to the most. But without actually testing the lag accurately, its hard to judge 300ms from 500ms even though its a big difference. Post some timings...

Not really a bother, it's only half a second. I was just trying to understand why there is a lag in the first place.

Latency / lag is due to a combination of a factors:

  • Time to encode the video in the camera
  • Time to transmit it from the camera to the client computer
  • Time to decode / display it on the client computer

1 and 3 tend to be the bigger factors.

Yep. I beginning to realize that I knew the answer to my question all along. I was just over-thinking things and skimmed right over the three points you just made. Sometimes you get so engulfed in trying to understand that you miss the obvious....oops.

Thanks to all for the great suggestions.


Lag, or latency, is usually caused by the encoder portion of the camera but occasionally can be exacerbated by other components of the system like the network, client or VMS. If you want to investigate further, you can use the method proposed by Rukmini to measure the latency and change out or bypass system components to determine their effect.

Try accessing the camera's Web page directly to eliminate the VMS or establish a direct connection to the camera via a PoE injector to eliminate the switch, etc. but most likely the camera is the source of the majority of the latency.

" send uncompressed video to the VMS "

from HIK IP camera

How do you do that ?

This was a hypothetical question.

I wonder if anybody else has experienced a similar lag issue to what I'm experiencing.

I have a Hikvision rebranded NVR running 4 x 4MPx cameras. I have a single camera spot out from one of the NVR's video out ports (HDMI). This HDMI runs through a 'HDMI over Cat' converter for approximately 20 metres and then displays direct onto a monitor through a HDMI input.

I've noticed that following a NVR reboot, there is lag of approx. 0.5 to 1 second. After approximately 2 months, this lag has increased and grown to approximately 10 seconds.

I've reduced resolution and avoided codec intensive processing such as H265. The NVR processor is running at below 30 percent capacity.

Does anybody know whether it is possible for an NVR to cause lag of up to 10 seconds?



TCP is delayed in situations where there is a lot of packet loss.
Changed to UDP.