Local realtime person detection for RTSP cameras

Are you using a Coral TPU? Do you see a message about it being detected or not detected on Frigate startup?

No, I have no Coral (yet). I try to use CPU only.

Just to give you a benchmark, I was using an ~2015 i7 and 640x480 or thereabout substream with 4 cameras@ 5fps and it used up the entire CPU. And that was only 8 zones. With the new dynamic zones, I find itā€™s often analyzing many more zones than that now (maybe double or more).

Itā€™s extremely CPU intensive to run. Thereā€™s a reason no one does it that way, because the $70 for the Coral is so much more cost effective. So, I think what you are seeing with CPU utilization on an old CPU sounds well within what could be expected, especially when itā€™s virtualized and sounds like not set up for accessing all CPU resources.

How many cameras and what resolution are your camera feeds?

Just one 720p (4-5 later). I can assign up to I think 13 cores (threads?) and as much RAM as it need for Frigate machine (one core for HA, 2 for Xeoma which I need now and 13 is ā€œfreeā€) till I donā€™t get Coral - itā€™s very hard here in Poland. But itā€™s pointless when it uses only one core. And I think @scstraus clearly explained my problem. But on the other hand, assuming (with cpubenchmark.net) that average i7 from 2015 is twice more powerful than my Xeon, I have two of it so if Iā€™ll manage to use multithread it could work until my Coral come. I think that 0.5 fps is enough for me now. And in fact, I have second machine with E3-1220 but because of mess with ubuntu there I couldnā€™t manage to run Frigate properly there.

I doubt you have 13 actual physical cores on an old CPU like that. It sounds like you are talking about vCPUā€™s in your VM which will actually hurt performance if you assign more than the physical cores you have. Better to assign a similar number of vCPUā€™s as the actual physical cores you have (you can include hyperthreads as CPU cores). When I used the CPU version a long time ago, it would use as many cores as I gave it, so I donā€™t think thatā€™s your issue unless itā€™s a config problem.

Itā€™s that CPU: https://ark.intel.com/content/www/us/en/ark/products/40200/intel-xeon-processor-e5520-8m-cache-2-26-ghz-5-86-gt-s-intel-qpi.html - two of them in fact - I made mistake in previous post. So summary 8 cores / 16 threads I think.

EDIT:
And proxmox says it is: 16 x IntelĀ® XeonĀ® CPU E5520 @ 2.27GHz (2 Sockets)

EDIT2:
I made a short video with the problem - https://streamable.com/in1lvi
The htop is on proxmox machine, not VM. Have a look what happens to time of camera when I back inside and there is no motion. I think it could be motion detection, not object recognition issue.
As I said - I know that my CPU is old and not made for this. If there is no solution I will just wait for the Coral :slight_smile:

Okay fair enough, then you do actually have 16 threads to play with. But it may indeed be the fact that your CPU is just too old and lacks the features. I tried it on a 2009 mac mini and I couldnā€™t get it to run at all on that CPU. I got CPU features missing errors in the log. But if itā€™s doing something, then it seems like you should be able to throw more cores at it and get it to work better. Not sure if frigate can support hyperthreading to use 2 separate threads per core, but you should be able to throw some more whole cores at it and get better performance.

The detection runs in a single python process, so it is limited to a single CPU core. It is a separate process from motion detection and decoding, but a single process. That is because the Coral can only be used by a single process. If you are not using a Coral, you can use a separate container for each camera to use multiple cores for detection (just make sure they have different client ids for mqtt). 0.5 fps is about what I would expect with a 600ms detection speed.

1 Like

Ah, so I stand corrected. Was the reason I was able to use all my cores because I had 4 cameras or because something changed from the version I was on?

The original CPU version was very different and used a detection process per camera. That isnā€™t possible with the Coral.

2 Likes

same here :slight_smile:

Hi Kyle / @blakeblackshear

Are you able to please advise which branch the dev image relates to? The latest I can see on github is 0.5.1-rc4. I run on a Pi so need to rebuild.

I have Reolink cameras and it sounds like this would fix my issue too. Hopefully this will allow me to undo my workaround which was to switch from RTMP to RTSP

1 Like

Iā€™m running the blakeblackshear/frigate:dev image.

Specifically this one: https://hub.docker.com/layers/blakeblackshear/frigate/dev/images/sha256-f4f9909c1b4e973008d3f794097f47e4bc2a4a5be4967d234b7c0099f61aca39?context=explore

1 Like

Thanks, but I mean which code branch was used to build this image. Iā€™m beginning to think maybe this particular dev branch was not pushed to Github., which is why I cannot find it

@blakeblackshear - I have another one question. Or feature request. I ran trough docs but couldnā€™t find it. Is (or will be) possible to define two areas but with two different MQTT topics? What Iā€™d try to achieve is turning my stupid old PTZ camera to smart camera with (very) basic human tracking. It should be possible with HA automations like human detected in left area, call service onvif.ptz with data pan left. Of course it wonā€™t be perfect solution but in fact I think it could work.

Just posting a solution I had in case someone else runs into a similar problem. My Amiccom camera kept erroring out with ā€œInvalid data found when processing inputā€. After a bunch of trials I notice FFMPEG was listing the resolution as 1088 instead of 1080. When I called out the resolution dimensions in the config it worked.

Also note that currently the example in the config has the width and length backwards.

1 Like

Not possible to define different areas yet, but that is coming in a future release. I have the exact same use case for PTZ. Eventually I plan to add the ability to track a subject with PTZ based on static cameras.

1 Like

I get a crazy amount of false positives for people. It seems just about every cat, bird, and dog is recognized as a person and frequently at 90%+. Is the code sometimes mislabeling what it identifies? Is there a different set of pretrained models that only looks for people and vehicles? I know I could eliminate a lot of these false positives by increasing the minimum area but I like the fact it can recognize someone 150 feet away. Sorry for all the grief I really do love it.

If you can capture some sample clips I can incorporate them into my testing. One of the next things I am going to focus on is reducing false positives. I want to see how much I can reduce without needing to train custom models.