V4L performance divide by two when starting stream

I found the catch:

Calling stream.next push internal buffers to v4l then call stream.start. By default with new buffer count is 4.
121 directly call stream.start, without setting any buffer. This result in v4l only having 1 buffer (I guess), so because there is no double buffer (or more), 1 frame out of two is skipped.

My suggestion is that nokhwa shouldn't call stream.start, or put it behing a feature flag. So by default performance are normal. On raspberry PI performance can be downgraded in order not to crash.

l1npengtul / nokhwa

V4L performance divide by two when starting stream #128

121 directly call `stream.start`, without setting any buffer. This result in v4l only having 1 buffer (I guess), so because there is no double buffer (or more), 1 frame out of two is skipped.

l1npengtul / nokhwa

V4L performance divide by two when starting stream #128

121 directly call stream.start, without setting any buffer. This result in v4l only having 1 buffer (I guess), so because there is no double buffer (or more), 1 frame out of two is skipped.

121 directly call `stream.start`, without setting any buffer. This result in v4l only having 1 buffer (I guess), so because there is no double buffer (or more), 1 frame out of two is skipped.