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

takePicture sometimes hangs waiting for the capture complete semaphore #14

Open
caprica opened this issue Mar 31, 2019 · 4 comments
Open

Comments

@caprica
Copy link
Owner

caprica commented Mar 31, 2019

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.

@caprica
Copy link
Owner Author

caprica commented Mar 31, 2019

Here is an example of what makes this issue very difficult to pin down. My latest test run is almost 13 hours and 0.25 million captures with no error.
picam-stress-test

@neklepat
Copy link

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.
I do now some changes in 1.x version of this library allowing video mode by adding videoport.
It looks that video mode can also significantly increase possible FPS rate. After adding videoport my test web service latency dropped from ~500ms to ~150ms.

@caprica
Copy link
Owner Author

caprica commented Jan 13, 2021

Would love to see some code... ;-)

@neklepat
Copy link

neklepat commented Jan 13, 2021

Ok, but its just my first attempt (few hours of work) to speed up camera captures, so the code is bit rusty :-)
My changes: picam-1.x...neklepat:picam-1.x

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.

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

2 participants