MOG2_CUDA

[ceewanna]

I get this message when I tried using MOG2_CUDA.

[DVR-Scan] Method MOG2_CUDA is not available. To enable it, install a version of the OpenCV package cv2 that includes support for it.

I had pip install opencv-python already but it seems not working. Please help.

[Breakthrough]

Hi @ceewanna, the opencv-python package on PyPI does not include CUDA support. I don't think anyone provides pre-built packages including CUDA support, so you may have to build it from source including GPU support (there are some tutorials online that can guide you through the process, for example this one for Ubuntu 20.04/22.04). If you are on Windows, you can also use the portable EXE including CUDA support already. Thanks!

[ceewanna]

It seems CUDA is only applicable to NVIDIA, right? So I might have to give up as I have only AMDGPU. :(

[Breakthrough]

That's correct... Sorry about that. I hope one day there's a Vulkan equivalent so it works on AMD and Intel GPUs too.

[ceewanna]

I have seen a number of debates on which gpu is best for linux but never come across this issue. Now it seems this could be one of the answers.

There is also an issue on hardware vs software decoder/encoder and one of the arguments was software offers better outcome. I still have no idea on this issue but guessing from my simple ffmpeg saving filter motion video based on libx265 and vaapi h265. Software does offer a much smaller file size with undetectable viewing quality.

I came across your DVR-Scan while I was setting up another motion detection. It was working fine with undetectable CPU load. It's an online detection, reading rtsp while passing through motion video. It was able to detect motion from low resolution feed while pumping out video from high resolution feed. Overall it works fine and is simple to manage and config. The only issue I found was the developer turns off voice claiming it's illegal to record voice.

DVR-Scan works great (I am still trying to fine tune it to get rid of noise and other fake motion signals). However, when I look at CPU load it is nasty. I have 6 cameras now and it eats up 70% load on 60 duty cycle on day-off but during normal day the graph hits the roof all the time. This is based on scaling down two 4M & 4 2M cameras by 3 plus skipping one frame.

[Breakthrough]

Have you tried -b CNT as well? It is typically much more efficient than the default MOG2. Unfortunately like you said, right now DVR-Scan is very CPU-bound. Video encoding is also CPU bound, but this can be improved somewhat by using the ffmpeg output mode.

In the future, I also want to explore different frame skipping modes in #82, which will also have a big impact on scanning performance. One idea is to only use frame skipping outside of motion events, which would allow the use of higher skip values without penalty (other than missing the first few frames of the event).

What's your workflow for DVR-Scan look like out? What options / config params are you using other than downscaling/frame skipping? Do you process live camera feeds, or process videos out of some shared drive? Any information you can share is useful, in order to help me understand how people are using the software. This in turn will help to improve it.

[ceewanna]

I did try -b CNT and it performed faster but then it was hit by free event detected in every file.

Frame Skipping
On frame skipping, based on my experience so far, skipping should be used while scanning and then once motion is detected it is best to just simply pass through motion video to the output (I use ffmpeg -c:v copy -c:a copy) otherwise we would need to encode it again for output. That's my idea from from a non-technical view.

My Config
My config so far focuses on these:
_bg-subtractor = MOG2
output-mode = ffmpeg

ffmpeg-input-args = -v error
ffmpeg-output-args = -preset ultrafast -crf 32 -c:v libx265 -c:a copy
#ffmpeg-output-args = -preset ultrafast -crf 32 -c:v copy -c:a copy

min-event-length = 0.2s
threshold = 0.10
kernel-size = 19

time-before-event = 2s
time-post-event = 8s

downscale-factor = 3
frame-skip = 1_

I use both frame-skip and downscale, hoping that it would save cpu workload. I use a slightly larger min-event-length, hoping that it would filter out noise (e.g. night time bugs flying around camera). I use ffmpeg copy to save workload and may use libx265 to save file storage. time pre & post event to me helps smooth out the output video. Pre-time helps get video before event, particularly in my case where rough scanning is adopted. Essentially, I guess I have squeeze almost every option to save workload.

On threshold & kernel-size, I am gathering some tests on detection. At this stage, it seems to me that the product of these 2 options is an indication how sensitive it is to motion. Kernel-size seems to be something like how blur it would like into the video. In my view 3 factors: threshold, kernel and min-event-length are critical to tuning. That's what I feel from my hands-on with DVR-Scan. I would appreciate if you could correct my understanding.

DVR-Scan Flows
Every one minute

1. Cron job run ffmpeg pass-through copy of all the cameras in parallel and store the videos in staging area.
2. Cron job running DVR-Scan on the staging area and get the motion video stored for viewing. The originals in the staging area is then moved to archive.

Right now, running the first cron job alone hardly causes any load on cpu. The 2nd cron job (DVR-Scan) causes substantial load on cpu.