VideoCapture::read returns false on unresponsive stream without distinguishing timeout from device failure
0 reputation · 14 Jan 2024, 02:27 UTC
Goal
Determine whether a blocked cv::VideoCapture::read (or grab) can be abandoned from another thread or after a deadline without leaving the camera backend locked or in an inconsistent state.
Constraints
OpenCV 4.x exposes no cancellation token, deadline, or timeout parameter for VideoCapture or most blocking algorithms. read returns false when no frame is available, but the return value does not distinguish a read timeout from end-of-stream or a backend device error. Blocking behavior depends on the backend (FFmpeg, GStreamer, MSMF) and camera state, and OpenCV does not document portable resource cleanup after an interrupted read. Abandoning the call or terminating the thread may leak native handles or leave FFmpeg/GStreamer in an inconsistent state.
Is it safe to destroy the VideoCapture object while a read is blocked on another thread? Does OpenCV guarantee that backend resources are released when the object goes out of scope during a blocked read? Are there backend-specific, OpenCV-stable ways to bound read time without modifying OpenCV source?
