Analysing the callgraph of the tool shows that ~40% of execution time is spent blurring identified detections:
More detections (and the usage of the beautiful feather_edges option) can yet increase the amount of time spent on blurring. Also, faster inference times (especially when using GPUs, which wasn't done in this profiling run) would increase this share further, to ~75% in some cases.
With that in mind, a (simple) improvement is to process the blurring of identified regions in parallel, on a per-batch level. This comes with a few side effects:
processing time decreases dramatically, on my machine (M1 Max) by ~35% for a short test video with few detections and with 720p_small_mosaic weights
With this step done, the "limiting factors" remaining are:
batches are only processed once all frames are (sequentially) added
the 4 stages (reading frames, detecting objects, blurring frames and writing frames) only happen sequentially
However, each of these steps feature parallelisation in their own scope. For the most part (and depending on your hardware), this change should lead to significantly higher resource utilisation.
Analysing the callgraph of the tool shows that ~40% of execution time is spent blurring identified detections:
More detections (and the usage of the beautiful feather_edges option) can yet increase the amount of time spent on blurring. Also, faster inference times (especially when using GPUs, which wasn't done in this profiling run) would increase this share further, to ~75% in some cases.
With that in mind, a (simple) improvement is to process the blurring of identified regions in parallel, on a per-batch level. This comes with a few side effects:
With this step done, the "limiting factors" remaining are:
However, each of these steps feature parallelisation in their own scope. For the most part (and depending on your hardware), this change should lead to significantly higher resource utilisation.