Debian packaging fixes and variable fps fixes #70
Conversation
Signed-off-by: Maarten Lankhorst <[email protected]>
This allows bumping exposure time to 10 seconds when using variable fps. I'm using this in my own webcam to allow night vision to work better. Signed-off-by: Maarten Lankhorst <[email protected]>
| @@ -939,7 +939,7 @@ raspi_capture_fill_buffer(RASPIVID_STATE *state, GstBuffer **bufp, | |||
|
|
|||
| /* FIXME: Use our own interruptible cond wait: */ | |||
|
|
|||
| buffer = mmal_queue_timedwait(state->encoded_buffer_q, 500); | |||
| buffer = mmal_queue_timedwait(state->encoded_buffer_q, 10500); | |||
There was a problem hiding this comment.
Looks like we need to make the timeout a bit better calculated. Arbitrarily increasing it to 10 seconds will annoy @staroselskii. I think the ideal will be something based on expected frame time + startup-delay-for-first-frame + 100ms or so, but for now just 500ms + when-variable-fps-add-1/shutter_speed might do
|
Op 28-11-17 om 15:11 schreef Jan Schmidt:
***@***.**** commented on this pull request.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In src/RaspiCapture.c <#70 (comment)>:
> @@ -939,7 +939,7 @@ raspi_capture_fill_buffer(RASPIVID_STATE *state, GstBuffer **bufp,
/* FIXME: Use our own interruptible cond wait: */
- buffer = mmal_queue_timedwait(state->encoded_buffer_q, 500);
+ buffer = mmal_queue_timedwait(state->encoded_buffer_q, 10500);
Looks like we need to make the timeout a bit better calculated. Arbitrarily increasing it to 10 seconds will annoy @staroselskii <https://github.com/staroselskii>. I think the ideal will be something based on expected frame time + startup-delay-for-first-frame + 100ms or so, but for now just 500ms + when-variable-fps-add-1/shutter_speed might do
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#70 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPXIDHYUX0OTbiSKIWJmiTyo-0xOwsrks5s7BSfgaJpZM4Qr-q9>.
When variable fps add shutter speed / 1000 since it's in us, if it's completely unset use 10 seconds?
|
|
If by 'if it's completely unset use 10 seconds?' you mean 500ms, then yes. The normal timeout should remain at 500ms |
|
Hey, I think not using the 10s timeout will fail if you change shutter_speed, there will be 2 or more frames with the old shutter speed after changing it. So if you change shutter-speed to 0 after it was 5 seconds, you get a massive timeout because only .5 seconds was expected, but the next 2 frames still taking 5 seconds.. |
|
The problem being solved by the timeout was detecting that the connector had been unplugged quickly (for a device that wasn't the standard RPi camera), so the pipeline could be restarted and capture resumed as quickly as possible |
|
Could we set a reasonable timeout based on initial settings (FPS and shutter-speed), and then only ever increase it if either is changed? |
No description provided.