Dahua/Loryta Latency

[kd4e]

I have an off-label Loryta Starlight that folks here told me is actually the same as the Dahua.
It's hardwired to an ASUS RT-AX58U that's set as a remote access point and is hardwired back to the central ASUS RT-AX58U.
When viewing the feed I'm observing some latency - frame delay and maybe some occasional dropped frames.
Without significantly reducing resolution (the application is to capture license plate #'s and/or other identifying detail) - how might the latency be reduced, please?
Thanks.

 

[wittaj]

Keep in mind all IP cameras have an inherent delay compared to analog - that is why backup cameras on cars are not IP cams.

This lag can be minimal to noticeable depending on the network topology.

Get the camera off the router and lower the FPS are two ways to fix this.

Cameras connected to Wifi routers (whether wifi cams or not) are problematic for surveillance cameras because they are always streaming and passing data. And the data demands go up with motion and then you lose signal. A lost packet and it has to resend. It can bring the whole network down if trying to send cameras through a wifi router. At the very least it can slow down your entire system.

Unlike Netflix and other streaming services that buffer a movie, these cameras do not buffer up part of the video, so drop outs are frequent as time goes by connected to a router. You would be amazed how much streaming services buffer - don't believe me, start watching something and unplug your router and watch how much longer you can watch NetFlix before it freezes - mine goes 45 seconds. Now do the same with a camera connected to a router and it is fairly instantaneous (within the latency of the stream itself)...

The same issue applies even with the hard-wired cameras trying to send all this non-buffer video stream through a router. Most consumer grade wifi routers are not designed to pass the constant video stream data of cameras, and since they do not buffer, you get these issues. The consumer routers are just not designed for this kind of traffic, even a GB speed router.

Most here have their cameras isolated off the router via dual NIC or VLAN and don't run more than 15FPS.

My LPR is running at 8FPS as an example.

 

[kd4e]

Keep in mind all IP cameras have an inherent delay compared to analog - that is why backup cameras on cars are not IP cams.

This lag can be minimal to noticeable depending on the network topology.

Get the camera off the router and lower the FPS are two ways to fix this.

Cameras connected to Wifi routers (whether wifi cams or not) are problematic for surveillance cameras because they are always streaming and passing data. And the data demands go up with motion and then you lose signal. A lost packet and it has to resend. It can bring the whole network down if trying to send cameras through a wifi router. At the very least it can slow down your entire system.

Unlike Netflix and other streaming services that buffer a movie, these cameras do not buffer up part of the video, so drop outs are frequent as time goes by connected to a router. You would be amazed how much streaming services buffer - don't believe me, start watching something and unplug your router and watch how much longer you can watch NetFlix before it freezes - mine goes 45 seconds. Now do the same with a camera connected to a router and it is fairly instantaneous (within the latency of the stream itself)...

The same issue applies even with the hard-wired cameras trying to send all this non-buffer video stream through a router. Most consumer grade wifi routers are not designed to pass the constant video stream data of cameras, and since they do not buffer, you get these issues. The consumer routers are just not designed for this kind of traffic, even a GB speed router.

Most here have their cameras isolated off the router via dual NIC or VLAN and don't run more than 15FPS.

My LPR is running at 8FPS as an example.

I'll have a look at the variables you've mentioned. Thanks.

 

[TonyR]

I'll have a look at the variables you've mentioned. Thanks.

Re: what @wittaj said about the "remote access point", try subbing a switch (preferably gigabit) in place of it to see if cam latency improves (after implementing his suggestions). If it does, that "remote access point" can be plugged into the switch also, as in this:

 

[kd4e]

I'll have a look at the variables you've mentioned. Thanks.

UPDATE: Sub Stream quality is unusable. When I look at Settings I see Main Stream "Smart Codec - Off", "Resolution - 1920*1080(1080P)", "Frame Rate(FPS) - was 30, just changed to 15", "Bit Rate Type - VBR", "Quality - 4", "Reference Bit Rate - 1024-6144Kb/S", "Max Bit Rate - Customized 3072 (3-6144) (Kb/S)", "I Frame Interval - 30 (15-150)" Sub Stream "Encode Mode - H.264", "Resolution - 704*480(D1)", "Frame Rate(FPS) - 30", "Bit Rate Type - CBR", "Reference Bit Rate - 512-2048Kb/S", "Bit Rate - 1024 (Kb/S", "I Frame Interval - 60 (30-150)" Other than changing FPS in Main Stream is there anything else I might try, please?

 

[paul@austins.tv]

Use CBR (Constant Bit Rate) and increase bit rate to 6144 for starters.

 

[kd4e]

Re: what @wittaj said about the "remote access point", try subbing a switch (preferably gigabit) in place of it to see if cam latency improves (after implementing his suggestions). If it does, that "remote access point" can be plugged into the switch also, as in this:

View attachment 179445

Just checked and here's the chain ... MAIN ROUTER -> SMC EZswitch 10/100/1000 8508T -> REMOTE AP ROUTER -> POE -> IP CAMERA

 

[wittaj]

Everyone says substream is unusable when they first see it LOL. You can up the resolution/bitrate and make it look pretty good as this thread shows:

How much resolution is really needed for LPR

We have folks come here all the time thinking that more MP is better, whether it be for general purposes or for LPR. Those of us that have been around long enough know that sensor size is more important than MP. Those that have been here awhile know that I share a representative sample of...

ipcamtalk.com

So for kicks try this and see if the issues you are experiencing with latency/dropouts continue:

H264
FPS: 10
iframe: 10
Bitrate: 1024 mainstream, 215 substream
CBR instead of VBR

This is lower than you would want to go on a camera, so if it is issues with this, then the problem is in your network topology.

What camera model is it?

 

[steve1225]

H264
FPS: 10
iframe: 10
Bitrate: 1024 mainstream, 215 substream
CBR instead of VBR

decreasing FPS is not a solution for the delay.
All nowadays cameras works by getting full frame from sensor by ISP, processing it from raw to pixel data, compressing it and sending/writing compressed frame to network/disk.. Due fact all work is done on FULL frames and each step require some time - you always will have some delay - minimum 1-2 frames. There is extra delay by network - cctv cams are using usually 100 mbit/s ethernet which is slow - so sending full frame can take another 1-2 frames..

If you set FPS to 10 - one frame is taken to 1/10 second - so 0.1 second. 2-4 frames is 0.2-0.4 second.
If you increase FPS to 30 this time will be decreased.

I have an off-label Loryta Starlight that folks here told me is actually the same as the Dahua.
It's hardwired to an ASUS RT-AX58U that's set as a remote access point and is hardwired back to the central ASUS RT-AX58U.
When viewing the feed I'm observing some latency - frame delay and maybe some occasional dropped frames.
Without significantly reducing resolution (the application is to capture license plate #'s and/or other identifying detail) - how might the latency be reduced, please?
Thanks.

How You display the feed? If it is a web browser You can have any latency - this is a web browsers thing..
They try to buffer video - which works very well for Netflix/Youtube but not so much for cctv feeds..
If it is a dedicated app (like SmartPSS) - then you should only have latency at level of 2-4 video frames per second..
And if you decrease FPS, then this 2-4 frames will take more time...

 

[wittaj]

decreasing FPS is not a solution for the delay.
All nowadays cameras works by getting full frame from sensor by ISP, processing it from raw to pixel data, compressing it and sending/writing compressed frame to network/disk.. Due fact all work is done on FULL frames and each step require some time - you always will have some delay - minimum 1-2 frames. There is extra delay by network - cctv cams are using usually 100 mbit/s ethernet which is slow - so sending full frame can take another 1-2 frames..

If you set FPS to 10 - one frame is taken to 1/10 second - so 0.1 second. 2-4 frames is 0.2-0.4 second.
If you increase FPS to 30 this time will be decreased.



How You display the feed? If it is a web browser You can have any latency - this is a web browsers thing..
They try to buffer video - which works very well for Netflix/Youtube but not so much for cctv feeds..
If it is a dedicated app (like SmartPSS) - then you should only have latency at level of 2-4 video frames per second..
And if you decrease FPS, then this 2-4 frames will take more time...

And yet look at all the threads where people came here with a jitter in the video or video dropping signal or IVS missing motion or the SD card doesn't overwrite and they were running 30FPS and when people tell them to drop the FPS and they dropped the FPS to 15FPS the camera became stable. The goal of these cameras are to capture a perp, not capture smooth motion. When we see the news, are they showing the video or a freeze frame screen shot? Nobody cares if it isn't butter smooth...getting the features to make an ID is the important factor. As always, YMMV...

So the issues he could be seeing could be a result of the little camera processor being overloaded by running the camera at the max spec and it is pegging out at 100% and causing these issues...

If the issue essentially disappears at these lower numbers, then we know either the camera was overloaded or the network. If it doesn't work with this, then it is something else in the system - network topology, computer being used, browser, etc.

 

[bigredfish]

I truly have not found 30FPS to be a problem with ANY Dahua camera. Latency, dropped frames, etc have almost always been with another device in the chain.

 

[wittaj]

I truly have not found 30FPS to be a problem with ANY Dahua camera. Latency, dropped frames, etc have almost always been with another device in the chain.

Yeah I haven't thru a web browser either unless I am using s computer not up to the task.

So to the OP what are the specs on the computer you are using and what browser?

 

[kd4e]

How You display the feed? If it is a web browser You can have any latency - this is a web browsers thing..
They try to buffer video - which works very well for Netflix/Youtube but not so much for cctv feeds..
If it is a dedicated app (like SmartPSS) - then you should only have latency at level of 2-4 video frames per second..
And if you decrease FPS, then this 2-4 frames will take more time...

I'm using qutebrowser qutebrowser | qutebrowser via an inovato Quadra Inovato Home mini-pc.

 

[mat200]

I have an off-label Loryta Starlight that folks here told me is actually the same as the Dahua.
It's hardwired to an ASUS RT-AX58U that's set as a remote access point and is hardwired back to the central ASUS RT-AX58U.
When viewing the feed I'm observing some latency - frame delay and maybe some occasional dropped frames.
Without significantly reducing resolution (the application is to capture license plate #'s and/or other identifying detail) - how might the latency be reduced, please?
Thanks.

Hi @kd4e

As @wittaj noted, IP cameras all have some latency issues ..

Reducing latency :

1) Each network node produces some latency, thus:

A) Reduce the nodes
B) Ensure the nodes you have are able to process the ip packets as fast as you need.

Thus, this is why we want a quality IP switch between the camera and the NVR / VMS

this is also why we recommend NOT passing the video through the main router ..

2) Each camera has limited compute power .. if you ask the camera to do too much, it can take longer to process the packets.

A) H.264 vs H.265
Some cameras are good at processing H.265 others are better at H.264 .. so this can be an issue for added latency. You need to test it.

B) FPS - each frame takes time to process .. again, depends on the camera and it's load. If you are not doing any smart analytics in the camera on the frames, then the camera should be able to handle the max frames in the spec and code it to H.264 or H.265 and send at basically the fastest speed the camera can handle. When you have the camera doing additional processing you may see additional latency within the camera itself. ( each camera behaves differently .. so you do want to test the issue if this is a significant issue where you want minimal latency .. for most of us we're ok with the camera doing some analytics as that is the nice benefit of IP cameras which can do more heavy lifting )

Thus, check H.264 vs H.265 latency, and settings on camera for analytics ( or image enhancement even .. really depends on the cameras, newer more expensive cameras can do a lot more than older and cheaper cameras .. better compute in them )

3) Each recording device, viewing device in the setup needs to be checked also.

Decoding H. 264 or H.265 can add significant latency also .. some hardware software / systems are better with decoding H.264 .. so you need also check that.

For example some NVRs are good with recoding, but once you also it to also decode for display it adds significant latency.

 

[steve1225]

I'm using qutebrowser qutebrowser | qutebrowser via an inovato Quadra Inovato Home mini-pc.

So this is source of Your problem.

If you need low latency - use cctv app (like SmartPSS or SmartPSS lite).
If you linux user and don't want to play with Windows virtualization for SmartPSS, You can try linux VLC with RTSP network stream (check DahuaWiki)

If you need to use web browser - try to use normal web browsers (google chrome, Firefox) - there is big chance that they will do better.

PS. Is this Quadra Novato have enough power to decode stream in real time? is it supports hardware decoding.. try to use normal windows/Mac machine..

 

[kd4e]

So this is source of Your problem.

If you need low latency - use cctv app (like SmartPSS or SmartPSS lite).
If you linux user and don't want to play with Windows virtualization for SmartPSS, You can try linux VLC with RTSP network stream (check DahuaWiki)

If you need to use web browser - try to use normal web browsers (google chrome, Firefox) - there is big chance that they will do better.

Firefox couldn't handle the camera on the mini-PC - but qutebroswer can.

I'm guessing that Firefox was using too many resources. (I was familiar with qutebrowser from OpenBSD.)

 

[wittaj]

Yeah these cameras are browser sensitive.

Internet Explorer or Pale Moon browswrs are the best for these types of cameras. And yeah we know Explorer is dead blah blah blah LOL. But it is still available.

 

[kd4e]

Yeah these cameras are browser sensitive.

Internet Explorer or Pale Moon browswrs are the best for these types of cameras. And yeah we know Explorer is dead blah blah blah LOL. But it is still available.

I'll try Pale Moon. I'm Linux & OpenBSD-only.

 

[mat200]

I'll try Pale Moon. I'm Linux & OpenBSD-only.

Try VLC and compare with the browsers .. test H.264 vs H.265

 

[kd4e]

Try VLC and compare with the browsers .. test H.264 vs H.265

Just tried ... I'm going to have to fuss with the string variables a little to get it to work ...