multi-cpu support?

[aardvark82]

I'm curious if drv-scan can be run to utilize all CPU's available or if it already does?

[Breakthrough]

Currently, DVR-Scan is entirely single-threaded. I did just check and there are a few background subtraction algorithms which do support parallelization (CNT). Performance could also be increased by performing the video input/output in separate threads, but this is something I want to pursue after the next release, where I plan to allow the use of ffmpeg to split the input video (rather than relying on OpenCV's VideoWriter as is currently done). I was also considering trying CUDA support, but that would also require that I compile and distribute the opencv-python package with GPU support enabled, which poses a distribution challenge in itself. One alternative is to write the core algorithm of DVR-Scan in C++, although I still need to see if the benefits there are really worth it. Thanks!

…

On Fri, Mar 5, 2021 at 2:53 PM aardvark82 ***@***.***> wrote: I'm curious if drv-scan can be run to utilize all CPU's available or if it already does? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#48>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA6TBEZC6HN2ZUW4L44LKTTCEZE5ANCNFSM4YVZQSOA> .

[aardvark82]

Thanks for the (quick!) update, Brandon.

• Splitting original file in chunks might be a good way.
• Although I think for many use cases we have a large collection of small (e.g. 1-min) files to process.

Just curious - there's another thread about processing files in subfolders - would there be a good way to specify a number of parallel tasks and launch them using a for

Example in this example - how could we launch 24 file conversions concurrently?

for inputfile in /my_videos/**/*.mp4 ;
do echo $input_file & dvr-scan -t 0.65 --min-event-length 48 -i "$inputfile" -o "$inputfile"_motion.avi
done

Curious if a quick win would be to add folder support to the tool and parallelize internally by launching NUM_PROCESSORS*2 threads.

[Breakthrough]

That's certainly possible - I've added a note on the Wiki to consider doing that. At this point I think the biggest performance gain would be moving to allow GPU support, and getting rid of doing the video encoding in the same thread as the processing is done.

Knowing now that there are other algorithms as drop-in replacements, I might be able to allow selecting different ones via command line to improve performance in the meantime. Will look into this, thank you!

Edit: Did a quick test, and indeed there is a new detector which runs in parallel and is faster. The results are slightly different, but for most use cases it should be acceptable given the right event window sizes. Moving this up to the next release!

[Breakthrough]

With DVR-Scan v1.3, you can specify -b CNT and it will use the new parallelized background subtractor.

[aardvark82]

Brandon this is great! I'll make sure to give it a try next time I have videos to process.

[myscho15]

Hay, the new CNT Command is cool. Than you verry much.

[ocram]

Just to give some feedback here, CNT works fine, is indeed a little faster than MOG (~1.4× for SD to ~2.1× for Full HD), has more problems with brightness changes and lens flares, and for the closest results to MOG, seems to require a doubling of the kernel size (kernelSize = kernelSize * 2 + 1).

[Breakthrough]

Thanks for the feedback - I'll look into doubling the default kernel size when switching to CNT.