Setting FPS on Windows and Mac OS not implemented

[markmaker]

Issue

The new OpenPNPCaptureCamera is a great improvement. I would first like to express my gratitude for sharing this, before turning to a minor issue:

The Windows port of openpnp-capture does not implement custom FPS setting…

openpnp-capture/win/platformstream.cpp

Line 508 in 1b2153d

bool PlatformStream::setFrameRate(uint32_t fps)

…nor does the mac port

openpnp-capture/mac/platformstream.mm

Line 302 in 1b2153d

bool PlatformStream::setFrameRate(uint32_t fps)

…only the Linux port does

openpnp-capture/linux/platformstream.cpp

Line 584 in 1b2153d

bool PlatformStream::setFrameRate(uint32_t fps)

Not being able to reduce the native streamed video bandwidth will prevent two fast hires cameras like the “6mm 2MP Full HD High Speed MJPEG USB” to share one root USB bus.

How to Reproduce

Connect two “6mm 2MP Full HD High Speed MJPEG USB” to a Windows system. Try to configure as OpenPNPCaptureCamera. One camera view will always stay black.

Conversely the same hardware on separate root USB hubs:

I reproduced this on Windows 7 / DELL Precision M4800 many times with different USB hubs, some brand new and including a USB 3.0 Hub.

Background

It should be noted that there are different ELP cameras. Mine are the “6mm 2MP Full HD High Speed MJPEG USB” (ebay listing no longer active) with these specs:

1920 (H) x 1080 (V) pixels MJPEG 30fps YUY2 6fps
1280 (H) x 1024 (V) pixels MJPEG 30fps YUY2 6fps
1280 (H) x 720 (V) pixels MJPEG 60fps YUY2 9fps
1024 (H) x 768 (V) pixels MJPEG 30fps YUY2 9fps
800 (H) x 600 (V) pixels MJPEG 60fps YUY2 21fps
640 (H) x 480 (V) pixels MJPEG 120fps YUY2 30fps
352(H) x 288 (V) pixels MJPEG 120fps YUY2 30fps
320 (H) x 240 (V) pixels MJPEG 120fps YUY2 30fps

There are slower ones like the “ELP 6mm 1.0MP 720P HD MJPEG USB Camera”

1280 (H) x 720 (V) pixels MJPEG 30fps YUY2 10fps
960 (H) x 720 (V) pixels MJPEG 30fps YUY2 15fps
800 (H) x 600 (V) pixels MJPEG 30fps YUY2 20fps
640 (H) x 480 (V) pixels MJPEG 30fps YUY2 30fps
352(H) x 288 (V) pixels MJPEG 30fps YUY2 30fps
320 (H) x 240 (V) pixels MJPEG 30fps YUY2 30fps
176(H) x 144 (V) pixels MJPEG 30fps YUY2 30fps
160 (H) x 120 (V) pixels MJPEG 30fps YUY2 30fps

Doubling the FPS on the same resolution explains for me why USB 2.0 can still be flooded by a single high speed hires cameras. If one could reduce the FPS this could perhaps be resolved for those who would like to share one USB connection.

Priority

I would like to comment that I reported this issue as suggested here. This is not a pressing priority for me. I rather benefit from high FPS and best resolution and use two seperate USB connectors on my computer.

As reported before, I just thought that the Wiki should perhaps be updated.

[vonnieda]

@markmaker and @trcwm I thought we might open a discussion about this since it's pretty relevant to what I am working on currently. The first question that comes to mind, for me, is: If a frame format is listed at 30 FPS, what happens when we tell the driver we want less? From https://www.kernel.org/doc/html/v4.9/media/uapi/v4l/vidioc-g-parm.html it seems like the answer is that the driver may skip or duplicate frames to meet the request.

I suspect that even in this case, the USB bandwidth will end up being the same, as the bandwidth seems to be part of the format descriptor rather than a dynamic value.

So, the second question is: Is this even important to have? Or should we just remove it from the API?

Jason

[trcwm]

I remember trying to implement it on Win and OSX. Those platforms do not allow a change in frame rate without closing the device and reopening it with the new parameters.

The reason to have it in the API (and working!) is when a user changes the frame rate in the OpenPNP GUI when the system is running. This is useful when optimizing or debugging, IMO.

Some UVC USB cameras have support for still image capture. I haven't experimented with this and I don't know how well this works, or even how many cameras support this. I also wonder how much latency there will be between the frame request and it being available at the API end. If the camera needs to focus or adjust its sensitivity on every frame, I suspect it will be too large to be of use.

[trcwm]

If we really want to solve the camera problems, adding an intelligent control module to each USB camera (Raspberry Pi zero or equivalent?) and serving the images over TCP/IP would go a long way.

[markmaker]

@vonnieda like I said, this is not a pressing priority for me. I rather benefit from high FPS(=low settle times) and best resolution (and use two separate USB connectors on my computer, if the bandwidth issue bites me).

With the cool "auto settle" and/or lighting related (portruding reflector or LED in camera view) frame sync you want the highest FPS available even more.

Ideally the FPS edit field could be removed/disabled on plattforms that don't support changing it. Or an error displayed if changing fails. So users won't waste time trying up and down to solve bandwidth and/or high CPU load problems with it (like I did :-)).

_Mark