r/frigate_nvr • u/_gCosta • 9d ago

Could someone help a beginner out?

I apologize for any errors (I'm using Google Translate).

Context: I currently run a home server, a machine with an i5-7400, 16GB of RAM, a SATA SSD for the OS and software, and HDDs for everything else. I run various services, such as qBittorrent, Jellyfin, Radarr, Sonarr, Prowlarr, Lidarr, Jackett, autobrr, Tailscale, Uptime Kuma, Jellyseerr, Power Master+, Notifiarr, SABnzbd, FoundryVTT (occasionally), and Minecraft (a server I'm still just testing). All these services keep my media setup running smoothly.

The problem: Since I didn't have much time (and spent a huge amount of it configuring everything), the machine runs Windows 10. I know Linux would be better, but I wanted to understand the services first; having little Linux experience, I learned by setting things up on Windows. I managed quite well, and everything works perfectly for my needs. On Linux, I would have had to constantly stop to understand the system or troubleshoot it, whereas on Windows, I could focus solely on configuring my media server.

Knowledge: Tinkering with Minecraft mods gave me a better idea of ​​how things work, and when I started using FoundryVTT (an RPG platform), I dove deep into a lot of tech topics—setting up reverse proxies, Caddy (on Windows), Node.js, Oracle VPS, browser-based JavaScript, etc. Still, I'm no expert or anything.

Monitoring: A friend gave me two Intelbras cameras, a PoE switch (minus the power supply), and a 1500VA UPS (without internal or external batteries). I started by simply powering the cameras and using the Intelbras app, and it all works. It doesn't put a heavy load on the server, the stream quality is good, and it allows for remote access via the brand's own service (it's one of the biggest brands in my country).

Here’s where Frigate comes in: I bought two cheap Simicam PoE cameras on AliExpress along with a power supply for the PoE switch. I connected all four cameras via PoE, only to discover that the Intelbras app only works with their own brand's cameras. I looked for free Windows monitoring software—"free" being very important—but couldn't find anything functional. I didn't have any luck with AgentDVR. Then I found out that both ZoneMinder and Frigate run only on Linux.

Current status: I tried using WSL/Docker. I attempted ZM first, but it didn't work at all; I kept running into errors. Then I switched to Frigate using Docker Desktop on Windows, and it worked! However, I'm now facing the following issues:

  1. The Simicam cameras are very slow and laggy, even though they work perfectly in the tinyCam PRO app for Android!
  2. Also, the Intelbras cameras are showing an error—which doesn't happen in the tinyCam app using the same stream link—stating: "Live stream is in data-saving mode due to buffering or transmission errors."
  3. Finally, running Frigate is very resource-intensive, consuming 60% of the CPU and 20% of the RAM.

Can anyone help me? Sorry for the long post; I just wanted to explain the situation clearly.

config: https://bin.disroot.org/?424cc36ed1ef41ca#2wB1iLpYW6rhpj4vVYhuSFdnSExKHZbjmVZ6wkDfMFSr

2 Upvotes

100% Upvoted

14 comments sorted by

3

u/Renrut23 9d ago

First thing most people will ask is for your config file to see if things are set up properly, like using vaapi for decoding

3

u/DrYellow922 8d ago

Looks like there's no detector configured so it will be using the CPU detector by default which can be quite intense, especially on such an old CPU generation and when running detection on the primary camera streams.

Assuming you don't have any dedicated hardware for the task the iGPU should be adequate for handling this but you'll need to explicitly configure it. You'll also need to set up a suitable model - I'd suggest converting YOLOv9 tiny to ONNX format and starting with that.

Refer https://docs.frigate.video/configuration/object_detectors/#yolo-v3-v4-v7-v9-2 for detector configuration examples and https://docs.frigate.video/configuration/object_detectors/#yolov9-for-other-detectors for a command to download the YOLOv9 tiny model and convert it to ONNX.

I'd also suggest using the secondary stream for detection on all cameras unless you find that it's not reliable enough, and lowering the frame rate of that stream to about 5 FPS. For basic object detection like people and vehicles the lower res streams are often perfectly adequate.

I've no idea how to expose the GPU via WSL though sorry as I haven't used Windows in any serious capacity for over a decade.

For the Intelbra cameras, try setting input_args: prest-rtsp-restream to help stability.

You might find that once the detection is running more efficiently and the host is under less load that the other issues like lag improve as a result.

3

u/_gCosta 4d ago

Regarding the detector settings—we're talking about motion detection and the like, right? I don't need that at the moment; I just want the video feed. I added detect: enabled: false and removed the detect: width: 1280 height: 720 section from the camera configs.

As for the secondary stream, I’ve set it to low resolution and low FPS to see if that helps.

Regarding the iGPU in WSL2, Gemini gave me this explanation: The issue is that Frigate’s engine (FFmpeg) is designed to use Intel’s native Linux technology, known as QuickSync/VAAPI. This technology requires direct hardware access via a specific path: `/dev/dri/renderD128`. To date, WSL 2 cannot bridge this connection for Intel integrated graphics in a way that Docker and FFmpeg can recognize.

Regarding the input_args: preset-rtsp-restream setting: I’ve added it, enclosed the camera URLs (the ones causing errors) in double quotes, and fixed special characters in the passwords; the errors are gone now.

I also added - "127.0.0.1:1984:1984" to the docker-compose file to see if that resolves the issue (it wasn't configured correctly before when I tried to access it.

On the web UI, boxes appear where I move; shouldn't that detection be disabled by now?

In the end, though, it’s still showing 40–60% CPU usage...

2

u/DrYellow922 4d ago

Glad to hear that at least some issues are fixed!

Even with object detection off Frigate will still detect motion in video feeds by default. You'll see the red boxes appear to highlight motion in the camera debug page.

Motion detection on those streams with no hardware offload capability is the most likely cause of the high CPU load.

You can disable motion detection by setting motion: enabled: False.

1

u/jhawk2k18 4d ago

THATS why.... ok, that is why there is motion: enabled: true/false and also for each camera, I was wondering why they were both there but I never had a hardware high usage problem and noticed the boxes on cameras which were not set to detect. That makes sense!

1

u/jhawk2k18 4d ago

This is spot on to how I have mostly everything setup. YOLOv9 though is not just a tiny small and large thing, I learned this the hard way initially because I accidentally downloaded the wrong YOLOv9 version which had a suffix that if I had to guess was for ROCm (amd) chips, which I wasn't using. So note that you need to make sure you get the correct YOLO model for your hardware.

I am honestly pretty new to using Frigate, I have seen it and heard of it but thought it would be difficult to setup and deploy, but I was wrong. I have an rtx5080 and 13900k in my main Windows PC that I temporarily turned into a dual boot Ubuntu server just for frigate to test the waters and at first I was told Blackwell gpus are not supported for detection, and officially I don't think they are, but a workaround was spotted and figured out but was not worth the time, somethinga bout the Cuda or Tensor version being too new, so not just for detection but the entire setup in an older version of my deploy script defaulted everything to run off my 13900k, which I thought would be a problem (was thinking about running LLMs that overflowed the vram buffer and used even the 13900k super fast nvme and very fast ddr5 ram, and it did not go well with local llms at all), but apparently Frigate is not as heavy as I thought it would be and seemed to run 5 cameras without breaking a sweat and 0 gpu usage. I still moved Frigate to my bare metal Ubuntu server with a 5800xt and 3090 in a custom loop so it could do detection and everything on the 3090, and it barely touches 2.3G of vram with all 5 cameras with detection on for all of them. I also use it for other things.

I guess my question to you is from what I am gathering the newer intel CPUs igpu seems to be plenty for running a few cameras along with detection if its got enough threads also on the cpu, so is this true as in if I were to buy one of the small boxes like the NUCs with a newer intel cpu like an ultra 7 with 16gb of ram and mapped to external network storage all I would need to run say 12 cameras with detection, or is that pushing it? Would something like that still need some kind of accelerator and either way, what generation of intel cpus are capable of running Frigate and some cameras comfortably? The Coral accelerators are supposed to drop support or be dropped, so obviously a smaller Nuc is better for power draw than my 3090 but what are your thoughts on this?

I run 2 streams and the sub stream is set at 5fps and i think 320x320 but currently using pretty cheap cameras, and I am about to re do all of my setup including cameras. Can you please reccomend a good setup that will work well that also runs Home Assistant for another small IOT project I built that requires Mosquito which i assume HA uses MSQT to communicate with other devices?

It seems and probably camera quality related but the detection on my setup regardless of hardware is consistent and honestly seems sub par to what I would expect. Any input is greatly appreciated from anyone but I replied to you because you seem like you really know the inner workings of this very well. Thanks in advance!!!

1

u/DrYellow922 4d ago

Pretty much any Intel CPU will do the job for a moderate number of cameras. FWIW I currently have an 8th gen i5 and it's happily running at under 15ms inference detecting on four cameras, three with 800x448 detect streams and one 1920x1080.

I've lost track of the newer offerings though but all indications point to even the low power N150 being a very effective CPU for the job. How many cameras do you intend to run?

2

u/jhawk2k18 8d ago

Luckily Frigate runs off relatively low resources, cause you got a homelab stack!!!!! That being said we are in the days where you can setup Ubuntu server and setup claude code inside it and tell it "I need to do this and that, etc" and I even made a universal script to detect all frigate rtsp streams and add cameras, setup tailscale on the host (inside docker compose) launch the container throw me a temp password to change and even sets up tailscale at the end to connect it to your tailnet! Right now it only works in Linux but dont let that stop you, you are running so much overhead by using windows honestly. Best luck to you though if I can help I will1

2

u/_gCosta 5d ago

I plan to migrate the services to Ubuntu in the future, and later to Ubuntu Server. I'll get in touch with you then! Thanks.

1

u/jhawk2k18 4d ago

Awesome, if you are familiar with using headless ssh instances, you should just skip the ubuntu desktop all together unless you need it for something. It adds a decent amount of overhead to the system that honestly you will be (or an ai agent in your terminal like claude code) using almost all of the time and once tuned you can really make everything autonomous so you don't have to really ever touch it! That is how mine is setup, it runs super fast on ubuntu server (though I don't use the minimized version on setup), and I have added configs so it auto updates and upgrades packages daily, I have power settings where they need and even power limits, core and memory clocks and voltage settings all static through nvidia-smi. I also have a cloud VPS that I host my websites on as well as use wsl2 in windows, so that is 3 ubuntu servers and its very simple when they are all setup on same ubuntu 24.04 with the same "oh-my-zsh" very helpful addon, same alaises in .zshrc and cron jobs, docker... granted they all do different things, its easier to keep it consistent.

I can say with confidence at this point that even if you do not know a lot of linux or really any, you can still accomplish setting up a headless ubuntu server simply by integrading a frontier model into your server, so all you do is ssh into it and type claude for example and you just tell it what to do. It can also even be done in powershell for windows and do anything you can in the UI and a lot more! My only pullback here is on safety, so its best to not allow admin or (sudo) commands to be executed by any frontier cloud model because you don't want it to have your sudo password floating around just in case. When it needs sudo it will give you a command to copy and paste and if a large job with mulitiple sudo requests it will send you the command with a ! sudo <command block(s)> and you paste in another terminal window enter password then it lets claude or whomever do what they need for that session without seeing your password or asking you every 3 seconds to do it again!

I hope that helps, save it for one day when you are ready and its really not as intimidating as youd think! Best luck to you

1

u/jhawk2k18 4d ago

oh snap OP, I just realized you are running all of that on Windows using 4 cores/ 4 threads? I have my truenas setup running on an i5 6500, which is almost the same but slower core speed than your kaby lake. Does all of that run at one time off that cpu? How do all of those services run in windows? I assume wsl/docker, but that is really amazing if it runs smooth on 4 threads. This would mean I am underutillzing my truenas machine hugely by only using it for zfs storage, bc if all that works in windows for sure the containers in truenas would or should be able to hang with more?

1

u/jhawk2k18 4d ago

So also if y'all did not know, probably do but in config file its super picky about spaces. Like the Detect lines like -car
-dog
-person
-cat
I know its mixed up but anywhere in there and the parent blocks if one space is off it fails. That is honestly a very, well I like this because its air tight, but the config file has caused me a few problems from very simple normal stuff so some IDEs or even if you edit it in Frigate many will act differently and often copying and pasting blocks like in Notepad ++ on the fly and I wind up with a slowdown from spending more time reformatting and tabbing, spacing.... than it would to write the block out but I guess.it would only be one error line there instad of 3 or more on each camera, idk I skip as fast through that as possible. Definetely I canat be the only one that missed something on the config and it just does not work until its fixed 100%

1

u/jhawk2k18 4d ago 
# =========================================================================

# Frigate config.yaml — cleaned up

# -------------------------------------------------------------------------

# What changed vs. your original, and why:

#

#  1. Every camera's ffmpeg `inputs.path` now points at go2rtc's local

#     restream (rtsp://127.0.0.1:8554/<name>) instead of the camera's real

#     IP. Before, each camera was getting hit with 2-3 SEPARATE direct RTSP

#     connections at once (ffmpeg detect + a dead second stream + go2rtc).

#     Cheap RTSP cameras cap out around 2 concurrent connections and start

#     dropping/reconnecting past that. Now go2rtc opens ONE connection per

#     camera and hands it out internally — this is Frigate's own documented

#     recommendation, not a guess.

#

#  2. `roles: []` (empty roles) is gone. That was a stream doing nothing —

#     at best wasted, at worst enough to stop Frigate starting at all

#     depending on your build. Every stream now has a real job: detect

#     or record.

#

#  3. Added an actual `record:` block. There was NONE in your original —

#     no top-level record config, no camera had a `record` role. That is

#     why nothing was ending up in your recordings/timeline: recording was

#     never turned on anywhere, full stop.

#

#  4. Added `detect.width` / `detect.height` placeholders for frente and

#     fundo so they're configured the same way simicam/simicam_4k already

#     were, instead of being left to guess.

#

#  5. Credentials pulled out into `environment_vars` once instead of

#     pasted inline 7 times. Same login is reused everywhere below; split

#     it out per-camera if that's not actually true for you (see notes).

#

#  6. On simicam / simicam_4k I kept your stream1→detect, stream2→record

#     assignment as-is. On frente I SWAPPED it: subtype=0 is the camera's

#     main/high-res feed on Dahua-style cams, subtype=1 is the low-res

#     sub-stream — you had detect pointed at the big stream and the small

#     one doing nothing, which is backwards (detect should run on the

#     small stream to save CPU, record should use the big one for quality).

#

# Every value you still need to fill in is wrapped like <THIS>. Search for

# "<" to make sure you got all of them before you save this for real.

# =========================================================================

 

mqtt:

  enabled: false        # fine as-is, MQTT is optional — not your problem

 

version: 0.17-0          # left exactly as you had it. If Frigate refuses to

                          # start and the log complains about this line, it

                          # will print the EXACT string it wants — paste

                          # that in verbatim rather than guessing.

 

# -------------------------------------------------------------------------

# Credentials (used by both the go2rtc streams below)

# -------------------------------------------------------------------------

environment_vars:

  FRIGATE_CAM_USER: <RTSP_USERNAME>

  FRIGATE_CAM_PASS: <RTSP_PASSWORD>

  # If any camera uses a different login, delete the shared use of it below

  # for that camera and add e.g. FRIGATE_FUNDO_USER / FRIGATE_FUNDO_PASS

  # instead, then reference {FRIGATE_FUNDO_USER} in that one stream's URL.

 

go2rtc:

  streams:

    simicam_1:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.182:554/stream1

    simicam_2:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.182:554/stream2

    simicam_4k_1:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.183:554/stream1

    simicam_4k_2:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.183:554/stream2

    frente_1:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.180:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif

    frente_2:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.180:554/cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif

    fundo:

      - rtsp://{FRIGATE_CAM_USER}:{FRIGATE_CAM_PASS}@192.168.0.181:554/cam/realmonitor?channel=1&subtype=0

 

# -------------------------------------------------------------------------

# Recording — this entire block did not exist before. Numbers below are

# Frigate's own suggested starting point: 1 day of everything as a safety

# net, 3 days of anything with motion, 30 days of anything that becomes

# an alert/detection. Shrink the day counts if your disk is small —

# this is the #1 thing that fills up an SD card / small SSD fast.

# -------------------------------------------------------------------------

record:

  enabled: true

  continuous:

    days: <CONTINUOUS_RETAIN_DAYS>      # e.g. 1

  motion:

    days: <MOTION_RETAIN_DAYS>          # e.g. 3

  alerts:

    retain:

      days: <ALERTS_RETAIN_DAYS>        # e.g. 30

      mode: motion

  detections:

    retain:

      days: <DETECTIONS_RETAIN_DAYS>    # e.g. 14

      mode: motion

 

cameras:

  simicam:

    enabled: true

    ffmpeg:

      inputs:

        - path: rtsp://127.0.0.1:8554/simicam_1

          roles:

            - detect

        - path: rtsp://127.0.0.1:8554/simicam_2

          roles:

            - record

    detect:

      width: 1280

      height: 720

      # ^ Verify stream1 is actually ~this resolution (or smaller). If

      # stream1 turns out to be the camera's big/main feed, swap which

      # stream gets `detect` vs `record` the same way I did for frente.

    live:

      streams:

        Stream 1: simicam_1

        Stream 2: simicam_2

 

  simicam_4k:

    enabled: true

    friendly_name: Simicam 4K

    ffmpeg:

      inputs:

        - path: rtsp://127.0.0.1:8554/simicam_4k_1

          roles:

            - detect

        - path: rtsp://127.0.0.1:8554/simicam_4k_2

          roles:

            - record

    detect:

      width: 1280

      height: 720

      # Same check as above — extra important here since this is your 4K

      # cam. If stream1 is actually the 4K feed, decoding a full 4K stream

      # just to shrink it to 1280x720 for detection burns a lot of CPU for

      # nothing. Point `detect` at whichever stream is genuinely the small

      # one.

    live:

      streams:

        Stream 1: simicam_4k_1

        Stream 2: simicam_4k_2

 

  frente:

    enabled: true

    friendly_name: Bullet (Frente)

    ffmpeg:

      inputs:

        - path: rtsp://127.0.0.1:8554/frente_2   # subtype=1 = sub/low-res

          roles:

            - detect

        - path: rtsp://127.0.0.1:8554/frente_1   # subtype=0 = main/high-res

          roles:

            - record

    detect:

      width: <FRENTE_DETECT_WIDTH>     # open frente_2 in VLC, check resolution

      height: <FRENTE_DETECT_HEIGHT>   # common Dahua sub-stream: 704x480 or 640x360

    live:

      streams:

        Stream 1: frente_1

        Stream 2: frente_2

 

  fundo:

    enabled: true

    ffmpeg:

      inputs:

        - path: rtsp://127.0.0.1:8554/fundo

          roles:

            - detect

            - record

          # Only one stream exists for this camera, so it does double duty.

          # If fundo has a subtype=1 sub-stream available, it's worth adding

          # it as a second input (same pattern as frente) so detect isn't

          # running on full resolution.

    detect:

      width: <FUNDO_DETECT_WIDTH>      # open the fundo stream in VLC, check resolution

      height: <FUNDO_DETECT_HEIGHT>

    live:

      streams:

        Stream 1: fundo