-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
takePicture sometimes hangs waiting for the capture complete semaphore #14
Comments
Have you thought about using video mode instead of a slills capture mode? Maybe one missing frame will be replaced by another one in EncoderBufferCallback.apply method. |
Would love to see some code... ;-) |
Ok, but its just my first attempt (few hours of work) to speed up camera captures, so the code is bit rusty :-) I have added new parameter useStills to configuration, which must be false in videomode. First frame takes some time, but next are fast. I plan to prepare continuous video capture with image double buffering. Then I wil be able to serve or stream images or MJPEG from web server to multiple clients. I need also some OpenCV processing. |
See #9.
When running repeated captures over long periods of time, sometimes the takeCapture method will hang waiting to acquire a semaphore permit that will never occur.
The semaphore is supposed to be released in the encoder buffer callback when the native code invokes that callback with the last frame of image data.
In my own tests, I ran approximately 15 hours of continuous captures, hundreds of thousands of captures, with no problem.
Other people have reported this hang after varying run-times.
The mitigation is to have the semaphore wait call timeout, and if the timeout occurs, destroy the camera and create a new one and then continue. This mitigation works, but ideally we would get to the bottom of the hang.
The present status of this issue is that as far as this library is concerned, I am unsure where to go next. It is possible there is a fault in this library, but it's also possible there's a fault in the underlying native code/driver/OS.
I am unsure if the native JNI picam-2 version shows the same issue or not. So far I have nearly 0.5m captures without incident. I had one inconclusive test that appeared to hang after 3 hours, but I had been dropping lots of code changes onto the Pi around the time that test was running.
Resolution is further frustrated by there not appearing to be much of any help in the native logs.
The text was updated successfully, but these errors were encountered: