EmpireTech PTZ425DB glitchy background?

[TuckNTruck]

Here's a video from my new PTZ425DB. Watch the trees far in the background and you'll see some kind of glitch that happens every second. Any idea what's causing that? Seems very grainy compared to the rest and almost like that section of the picture is at 1 FPS while the rest of the image is 20 or 30 FPS.

 

[wittaj]

It's not a glitch - it is your settings.

Looks like you are running H265 and it is macroblocking or your bitrate is too low.

Try H264 at 15FPS and 8192 bitrate and see if it improves.

 

[TuckNTruck]

It's not a glitch - it is your settings.

Looks like you are running H265 and it is macroblocking or your bitrate is too low.

Try H264 at 15FPS and 8192 bitrate and see if it improves.

Thanks. It was H264B for some reason - I would have sworn I had it set to H264 already. I try to run 20+ FPS and I've noticed something different with this camera I've never seen on my other 10+ various Dahua cameras. If I set the bitrate above 10240, I get a lost signal error in BI and it's like the cam goes through reboot cycles but never gets a signal restored. I can ping the camera and see it on my network, but there's no video until I change the bitrate back to 10240 or less. Trying to access the camera GUI is also difficult during these "cycles", almost like I only have a short period of time to access the settings to change the bitrate back and if I don't get it in that time, it reboots and I have to wait again. Very frustrating.

 

[bigredfish]

10240 is plenty for that camera

 

[wittaj]

That is strange. Are you using substreams in BI?

I just tried 12,000 and is going ok. Let me try thru the night.

Under BI camera status at the bottom, what is your MP/s number?

Did you do a factory reset when you got the camera? Many of us have seen that for some reason the cameras work better in BI after a factory reset.

 

[TuckNTruck]

That is strange. Are you using substreams in BI?

I just tried 12,000 and is going ok. Let me try thru the night.

Under BI camera status at the bottom, what is your MP/s number?

Did you do a factory reset when you got the camera? Many of us have seen that for some reason the cameras work better in BI after a factory reset.

I don't generally run substreams in BI just because I don't have any performance concerns running the main stream. Is there a reason to run substreams? I turned on the substream, and attached are my numbers from BI.

I have not done a factory reset on this one. Is that something to do in the GUI or a physical reset button inside the camera?

 

[wittaj]

Personally I prefer the reset button if it is easily accessible, but in theory doing the reset in the GUI should be the same.

BI will use substreams for things that can be used for substreams as it relates to motion detection, multi camera views, alert images, etc.

If it uses mainstream for all of that, you get triple or more CPU usage depending on camera resolution and number of cameras.

And more cameras equals more problems.

If substreams resulted in inferior performance, none of us would use it.

Keep in mind NVRs have used the substreams for years and BI was actually late to the game in implementing that feature.

There is no downside to substreams.

You can tell BI to record 24/7 mainstream or to save storage tell it to record continuous + triggers, which will record substream until triggered then go to mainstream during an event and then back to substream, but using substreams allows the computer to do so much more.

Post the BI camera status screenshot showing the total MP/s. It would look something like this example I found with a search (too lazy to screenshot mine LOL):

 

[TuckNTruck]

Personally I prefer the reset button if it is easily accessible, but in theory doing the reset in the GUI should be the same.

BI will use substreams for things that can be used for substreams as it relates to motion detection, multi camera views, alert images, etc.

If it uses mainstream for all of that, you get triple or more CPU usage depending on camera resolution and number of cameras.

And more cameras equals more problems.

If substreams resulted in inferior performance, none of us would use it.

Keep in mind NVRs have used the substreams for years and BI was actually late to the game in implementing that feature.

There is no downside to substreams.

You can tell BI to record 24/7 mainstream or to save storage tell it to record continuous + triggers, which will record substream until triggered then go to mainstream during an event and then back to substream, but using substreams allows the computer to do so much more.

Post the BI camera status screenshot showing the total MP/s. It would look something like this example I found with a search (too lazy to screenshot mine LOL):

Cool, I had no idea that substreams were used for anything other than saving CPU load. So I enabled substream on all the cams now except for one and here's the data. Looking through the GUI, I can't find a factory reset option. Do ya know where it is?

 

[TuckNTruck]

So, after more tinkering I found that I could increase the bitrate one step at a time: 10240>12288>14336 with no issues. If I try to go from 10240>14336 it cycles the camera. And no matter how I do it, if I go to 16384 it cycles. So as of right now I've got it H264, 30FPS, CBR 14336. It's stable and all seems to be working normally - I'll just have to see how it looks tomorrow in the daylight.

 

[looney2ns]

Cool, I had no idea that substreams were used for anything other than saving CPU load. So I enabled substream on all the cams now except for one and here's the data. Looking through the GUI, I can't find a factory reset option. Do ya know where it is?

View attachment 183056

Factory reset is available only in the cameras GUI, not in BI.

 

[TuckNTruck]

Well, no matter what frame rate or bitrate I run, I still get the macroblocking. It's more noticeable (like in the video in OP or even a little worse) with a "busy" image like when the lake is choppy. A calm scene with little movement results in less noticeable macroblocking. I did a factory reset from the GUI, no change. Here's a couple videos - a calm picture where you can still see the macroblocking happening ever so slightly in the background and a busy image with lots of water movement and the video looks terrible.

 

[tangent]

If I set the bitrate above 10240, I get a lost signal error in BI and it's like the cam goes through reboot cycles but never gets a signal restored. I can ping the camera and see it on my network, but there's no video until I change the bitrate back to 10240 or less. Trying to access the camera GUI is also difficult during these "cycles", almost like I only have a short period of time to access the settings to change the bitrate back and if I don't get it in that time, it reboots and I have to wait again. Very frustrating.

I'd be tempted to re-terminate your cable ends (also use dielectric grease in the connector) and / or try a different switch port.
Does your switch give an indication of the speed the camera is linking at?

You could also try a continuous / high number of pings a a crude check for packet loss eg. either "ping -t" end with ctrl-c or "ping -n 1000" to send 1000 pings.

Are there multiple clients on your network or the internet connecting directly to the camera? If you have multiple devices streaming video directly from the camera, typically each of those uses the stream bandwidth up to the point where the camera or your network link can't handle it.

 

[bigredfish]

Mine doesnt do that. I run it at 10240, h.264.h, CBR 30FPS - NVR is a 5216.
The camera uses a builtin PoE port of the NVR

As an NVR user, we use substreams to view multiple cameras live, but viewing a single camera is usually full res main stream as are all of the downloaded clips I post.
I can usually run main stream on 4-6 cameras simultaneous (4MP 8192-10240 all 30FPS CBR) on my laptop locally using SmartPSS with no problem

 

[MikeLud1]

What firmware are you on, before I upgraded to the below I had the same issue. Also below are my Encoding settings

General_SD-Gauss_MultiLang_PN_Stream3_V2.821.0000013.1.R.230704.bin

Shared with Dropbox

www.dropbox.com

 

[TuckNTruck]

I'd be tempted to re-terminate your cable ends (also use dielectric grease in the connector) and / or try a different switch port.
Does your switch give an indication of the speed the camera is linking at?

You could also try a continuous / high number of pings a a crude check for packet loss eg. either "ping -t" end with ctrl-c or "ping -n 1000" to send 1000 pings.

Are there multiple clients on your network or the internet connecting directly to the camera? If you have multiple devices streaming video directly from the camera, typically each of those uses the stream bandwidth up to the point where the camera or your network link can't handle it.

Reterminating the cable was next on my list, just way too cold outside to mess with it right now. Maybe by mid next week.

I've pinged it hundreds of times over the past few days, average 7 ms never over 18 ms maximum, no packet loss. This camera is connected via a P2P wireless bridge, but I don't see any indication that's the issue. I have 3 other cameras running on this wireless bridge/switch including a 45X 4 MP PTZ. I've also disabled all cameras on that switch except for the mini PTZ thinking it might be a bandwidth issue, but there's no improvement. With just the mini PTZ running, my bridge is showing a steady throughput of 15 mbps and I have the camera bitrate set to 14336 so that checks out. Signal strength on the bridge is -32 dbm, so no issues there, This bridge has been rock solid for a couple years now.

Just BI on one PC, nothing else connecting to the camera.

 

[TuckNTruck]

What firmware are you on, before I upgraded to the below I had the same issue. Also below are my Encoding settings

General_SD-Gauss_MultiLang_PN_Stream3_V2.821.0000013.1.R.230704.bin

Shared with Dropbox

www.dropbox.com

View attachment 183424
View attachment 183425

Interesting. Mine is different. When I do a manual check, it says I am using the latest version.
System Version:2.821.0000006.1.RBuild Date:2023-03-16
PTZ Version:V2.401.0000001.47.RHNDG_220906_42754

No variation of compression, frame rate, or bitrate has made any real difference, unfortunately.

 

[wittaj]

I would suspect the manual check is going to Dahua servers and Andy usually gets the firmware first for us to try.

 

[tangent]

I've pinged it hundreds of times over the past few days, average 7 ms never over 18 ms maximum, no packet loss.

There is a difference between mentally averaging hundreds of pings, and pinging it continuously. Pinging continuously is more likely to show packet loss.

This camera is connected via a P2P wireless bridge, but I don't see any indication that's the issue. I have 3 other cameras running on this wireless bridge/switch including a 45X 4 MP PTZ. I've also disabled all cameras on that switch except for the mini PTZ thinking it might be a bandwidth issue, but there's no improvement. With just the mini PTZ running, my bridge is showing a steady throughput of 15 mbps and I have the camera bitrate set to 14336 so that checks out. Signal strength on the bridge is -32 dbm, so no issues there, This bridge has been rock solid for a couple years now.

That network setup does introduce some additional complexity. If you can tell what speed the camera's port is linking at (10mpbs or 100mbps) do take note. You might want to use some network test software on a laptop to check performance through all of this equipment back to a device at the house.
When all 4 cameras are in use how much bandwidth are you using on your wireless link?

 

[tangent]

CBR or VBR?

 

[TuckNTruck]

There is a difference between mentally averaging hundreds of pings, and pinging it continuously. Pinging continuously is more likely to show packet loss.

That network setup does introduce some additional complexity. If you can tell what speed the camera's port is linking at (10mpbs or 100mbps) do take note. You might want to use some network test software on a laptop to check performance through all of this equipment back to a device at the house.
When all 4 cameras are in use how much bandwidth are you using on your wireless link?

Did a ping -n 1000 and here are the results:
Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 19ms, Average = 5ms

It's on a gigabit switch, but I don't know if it shows what speed the ports are working at...Recommend specific network software and what checks to run?

When all 5 boat dock cameras are on, bandwidth through the bridge is 60 mbps +- 1 mbps. No drops, nothing. I'm using TP link CPE 510 wireless bridge which is limited by its 10/100 ethernet port. I also have a wireless AP on the dock and speed tests pull 40 mbps with all cams running, so everything seems to work exactly as it should. Considering none of the other cams have any issues, I really doubt it's a problem with the network (though I'd put a failing cable/connection pretty high up on the list of possibilities).

I run everything on CBR and have it set to 14336 bitrate. The camera still goes into a continuous reboot cycle if I try to run the max 16xxx bitrate.

Maybe I'll get out in the cold tomorrow and try out a new ethernet cable.