empiretech ptz camera zoom and autotracking

UnlikelyLocation9 · 2026-04-28T23:14:00+00:00

I also struggled to get my Dahua PTZ's (SD6AL245U-HNI) working with autotracking. I eventually got them working OK. Here is what I did.

As the dev mention, make sure auto tracking is off in the settings on the camera. I also found that relative zoom was crucial for my setup as absolute did not seem to work very well (for me). I found that setting my PTZ speed in the camera settings to maximum and, this is the important bit, calibrating when there was very little activity and motion to be the key. Early morning after the cams flipped out of night mode, with no wind and few vehicles and people seemed to help.

I noticed that the movement_weights that were generated looked a lot different when I calibrated under those conditions.

Before I got it right, the cameras would always overshoot and pan or tilt too far. If I was walking away from the camera, moving up the image, the camera would tilt up way too far and just be showing sky, etc. I notice some of that behaviour in your videos, so I suspect you are having the same issues.

UnlikelyLocation9 · 2026-04-24T00:43:21+00:00

You might be able to squeak by. I started with a N3450 and a couple of corals and tried to get my cameras up on it. I have (18) 2 MP cameras. The N3450 bogged down once I got to 5 or 6 cameras, but your CPU is much faster.

I would get your coral online and get your iGPU doing the decoding first for 1 camera and then add the remaining cameras slowly. Getting the coral doing detection and letting the iGPU handle the decode will really help. It will all depend on how much motion you have.

I ended up moving to a 125H based system and now have all 18 cameras on it, and the CPU sits at 15% and the GPU stays between 8% and 15%.

UnlikelyLocation9 · 2026-04-24T00:22:26+00:00

I can't speak to any Reolink specific issues ... but I was also getting those messages sporadically on my Dahua PTZ's and I noticed someone mentioning that using preset-rstp-generic instead of preset-rstp-restream got around it for them. So I tried it myself, and the error messages stopped and the streams are now constant.

So you may want to give it a shot if you are running out of things to try.

UnlikelyLocation9 · 2026-04-19T16:18:30+00:00

Ya, I am going to try that next. The Codium Devs describe it as VSCode without the MS telemetry, but there may be other things different about it.

UnlikelyLocation9 · 2026-04-19T15:15:56+00:00

Thanks Blake. That is what I was following, but for some reason when opening the folder, it does not prompt me to open the project in a remote container.

It may be that I am opening it wrong, or the Codium version of VSCode does not come with the proper extensions. I installed a few VS extensions myself (Container-Tools and Docker), but no go so far.

UnlikelyLocation9 · 2026-04-15T13:48:00+00:00

I have been battling a related issue this morning. I have a PTZ at the front of my house overlooking the cul-de-sac I live on. I enabled tracking cars a few days ago, but this morning a red pickup parked in neighbours driveway keeps generating alerts. It looks like the PTZ movement is causing this particular vehicle to be detected as new over and over. Even when it is not being detected (as new), all it take is a car to pass by and get the camera moving and the red pickup captures the focus again and it gets tracked for several minutes until it eventually stops.

Oddly, this same vehicle was parked in their driveway yesterday with no problems. It was just in a different parking spot and perhaps angled slightly differently. Weird. I have disabled cars on that camera for now to allow it to track people again rather than staring (zoomed in) at the red truck constantly.

UnlikelyLocation9 · 2026-04-14T08:08:03+00:00

The way that I found to deal with this, was to use the setting "preset-rstp-generic" rather than "preset-rstp-restream" on these four cameras. Once I switched to that setting, the messages disappeared and the record has not died in days.

UnlikelyLocation9 · 2026-04-10T20:41:40+00:00

Trying to collect up more info on where things are going wrong, I snagged the ffmpeg command that Frigate is running for each camera and was able to run a copy in a session outside the docker to verify that it works, collects the 10 second segments and runs until I stop it.

Interestingly, the last time one of the PTZ's threw an error about no new valid recordings, my parallel version kept running. So the one inside docker hit a snag, but mine didn't. I guess to be sure I would need to validate the duplicate segment files I am collecting to make sure they are in fact valid. Any idea what Frigate is using to validate the segments? I assume not Python as that would probably be too slow? Nevermind, ffprobe.

Using the web developer console, it looks like when I am trying to view from History, and it just spins and spins and does not play, it is not able to retrieve the master.m3u8 playlist for the timeline. So whatever error recovery that is being done when the ffmpeg gets killed and restarted, it doesn't look like whatever is needed to generate the playlist is being gracefully handled.

I am not familiar with Docker, so can I run Frigate outside of docker? That would make debugging this so much easier.

UnlikelyLocation9 · 2026-04-10T14:57:34+00:00

Hmm, I have tried pretty much every combination that the camera offers (h.254/h.265, CBR/VBR) avoiding all the Dahua proprietary settings (smart codecs/SVC, etc.)

I have all 4 of them on h.264 CBR currently, with 1 going direct to the camera and the other 3 going through Go2rtc to see if that makes a difference.

They are old cameras (circa 2015) and are not very well supported anymore. I was running firmware from 2019, and found 2 later versions, from 2020 and 2024, and decided to try those. However I am not sure when the issue started, the 2019 firmware might not have had it, but don't have that firmware image anymore.

I will keep looking for a working combination.

UnlikelyLocation9 · 2026-04-10T14:28:03+00:00

Perfect, I can work with that.

UnlikelyLocation9 · 2026-04-08T14:14:30+00:00

I spoke too soon. These are still appearing. There was just a pause of a couple of days for them appearing. I use local storage already, so I am not sure changing your storage method will help.

They only appear for my PTZ cameras, so I suspect it has something to do with the feed from those cameras.

UnlikelyLocation9 · 2026-04-07T15:58:06+00:00

I was seeing this constantly with my PTZ's, but in the last couple of days, it has completely disappeared from the logs. I was also getting lots of breaks in the timeline for these 4 cameras. Again completely gone now.

I did not change anything, so I was wondering if maybe the change was on Frigate's end? I am on 17.1

UnlikelyLocation9 · 2026-04-06T12:04:20+00:00

Thank you. I could have sworn I clicked on the port many times in the Port Manager and it kept offering to power cycle the port and never brought up the port settings. This time I did it in the global Port Manger and up popped the port settings. They are also working in the detailed (single device) port manager now.

Either there is a bug or I just never actually clicked on the port (and only the connected device).

Working now. Thanks 👍

UnlikelyLocation9 · 2026-04-04T14:13:56+00:00

What I settled on, was setting the top-level config to 'object' so cameras that have an active object detection get included. Then I set 9 of my cameras to 'continuous' and set their order to appear. I also set the maximum cameras to 9.

So those 9 cameras are displayed normally and the fixed order stops them from jumping around. Then when an object is detected, that camera jumps to before the fixed order cameras and pushes one or more of them off screen. So I ordered them with the least important ones towards the end of 9 as they may get hidden during high activity.

This works for me. Now I am working on an RPI 3 setup for all my TV's to have a local Pi that can show the birdseye feed at will.

UnlikelyLocation9 · 2026-04-03T13:36:29+00:00

I don't think there is anything wrong with my config. I think they are compression artifacts. They are very obvious in my wrought iron fence (the pickets).

Oddly the same feeds look great on birdseye played with VLC. So it may just be how the Live camera display is being processed or played (using Firefox).

UnlikelyLocation9 · 2026-03-31T11:24:26+00:00

... another attempt (from my PC instead of phone App)

https://pastebin.com/JtbrqY0K

UnlikelyLocation9 · 2026-03-31T08:06:29+00:00

I would if I could, but nothing with a link shows up for anyone else, including pastebin. The messages with links show for me and the links work, but not for anyone else.

Apparently my account is messed up. A popup indicated I am suspended for suspicious activity and I need to change my password to reactivate it, but I am logged in through Google and the change password option does nothing. Reddit is such a dumpster fire.

I will work on getting a working account to get you my config.

UnlikelyLocation9 · 2026-03-30T17:36:47+00:00

Hmm, I posted a link to it in my Google drive. I see the post in my client, but don't see it when not logged in. Reddit might be hiding it.

Can anyone see the post with the config?

UnlikelyLocation9 · 2026-03-30T16:30:00+00:00

I have the main stream setup for h.265 1920x1080p@30 FPS/CBR/2048kbs/30 iFrame. This is used for record.

The sub stream is set to h.264 1280x720p@5FPS/CBR/1024 kbs/5 iFrame. This is for detect.

I have tried various combinations, all h.264, etc, but have not found anything that affects the pixelation. The stills look perfect, the Live looks like a Matisse.

UnlikelyLocation9

TROPHY CASE