Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: VideoCapture to drop frames for low latency still capture #13145

Open
crackwitz opened this issue Nov 13, 2018 · 5 comments
Open

Proposal: VideoCapture to drop frames for low latency still capture #13145

crackwitz opened this issue Nov 13, 2018 · 5 comments

Comments

@crackwitz
Copy link
Contributor

Use case: someone wants to capture still images. However the camera API, trying not to drop any frames, buffers several frames. This results in a pipeline of "stale" images when frames are read at less than full configured frame rate.

Those who don't know of this behavior, are often puzzled and don't know how to solve it.

The usual solution is to spawn a thread to read from VideoCapture without delay, and keep the most recent frame around for whatever requests it. This is often implemented from scratch by whoever needs this functionality.

Idea: introduce a property/flag to cv::VideoCapture that would enable the described solution. A VideoCapture::read() should not return the same frame twice, i.e. it should block if the most recent frame was already read. This is usually implemented using std::condition_variable.

This might interact with #12077.

Some example code for the principle (and direct access to v4l) can be found here:

@alalek
Copy link
Member

alalek commented Nov 13, 2018

I believe this make sense for cameras only. Or live video streams (from cameras).
Saved video streams from storage should not be affected (OpenCV doesn't add delays between frames - it is processed like images sequence).

Currently this behavior is VideoIO backend implementation specific. Some backends has builtin low-latency support via frame drops (see #11768 for MSMF).

Please note:

  • there is .retrieve() method. This call waits for the next frame.
  • .read() has stream parameter (it is used for stereo cameras, IR channel, RGBD depth channel, etc). Need to specify somehow which channels to "keep".
  • .read() method decodes (converts to BGR format if necessary) frames.

@ghost
Copy link

ghost commented Nov 19, 2018

Using CAP_PROP_BUFFERSIZE can also be useful. If the buffers are full, next frames are dumped

@yyf1986
Copy link

yyf1986 commented Dec 30, 2019

Using CAP_PROP_BUFFERSIZE can also be useful. If the buffers are full, next frames are dumped

how to use CAP_PROP_BUFFERSIZE?

@eltonfernando
Copy link

cap=cv2.cv2.VideoCapture(0)
size=10
cap.set(cv2.CAP_PROP_BUFFERSIZE,size)

@fisakhan
Copy link

fisakhan commented Feb 6, 2020

Can I set backend to DC1394 [Firewire] v 2.x backend in python-opencv 4.1.2 on Ubuntu 18.04?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants