VideoIn Source conversion: less work, more CPU

vvvv gamma question
1

here’s something that goes agains my intuition. in the following patch, CPU usage goes UP when deactivating work.

cpu_spike

how can this be explained? tooltip timings don’t show any abnormalities…

cv_tracking.vl (22.8 KB)

2

@motzi with gamma 6? with seven the node is broken

image
image503×476 7.31 KB

3

Try running the observable in the foreground.
One theory I have is that the Marker Detector keeps running without receiving data and while it doesn’t output anything its trying to execute and maybe throwing errors

That said, I don’t see the same usage spike:

image
image2231×1434 339 KB

image
image2412×1293 250 KB

4

cannot confirm - i’m on gamma 7 with latest VL.OpenCV (4.0.2)

that’s not my understanding how the markerdetector works here - i’m pretty sure there is no background magic involved and it just executes with each new incoming observable.

true, with the VideoIn from OpenCV the spikes don’t occur to me either.

but reducing and deducing further the CPU spike can be reduced to this simple setup:

grafik
grafik430×265 3.13 KB

disabling the camera will make the CPU go up. i suspect that without a video source the VideoSourceToCvImage node just processes default images every frame (which appears to be heavy - but that’s just wild guessing).

5

HI @motzi, what I meant was that you’ve put the markerdector into another thread (Background>Observable.Foreach),
The behaviour reminds me of when I used Parallel Regions in the past, in that that region would try to execute the function as quickly, as often as possible, regardless of what was inside.It could be throwing an error, or not completing the task to yield a result, so in the background maybe it doesn’t stop.

6

The problem seems to be a generic VideoIn + [any source converter] problem.

Here is the VideoIn for Stride helppatch
cpu_spike2

I will change the name of this thread accordingly.

7

Hi, can not reproduce the issue here. Tested with 7.1-0076.

Does the behaviour change if you disable Prefer Push on the VideoSourceToTexture node?

8

Interesting, turns out an internal scheduler.Sleep call didn’t do what it was supposed to do. Increased the sleep time from 1 ms to 16 ms, looks good now. Fixed in upcoming.

2 Likes
9

Yes, when disabling Prefer Push the behaviour is different in the following way:

  • VideoIn Enabled:
    • Low CPU but patch FPS is reduced to camera fps (VideoSourceToTexture is blocking)
  • VideoIn Disabled:
    • similar CPU utilization and patch FPS is up to Mainloop rate again

I’ve tried this with 2 different webcams to rule out a driver issue.

10

ah, one second too late with my previous post.

Thanks @Elias !