gst-rpicamsrc icon indicating copy to clipboard operation
gst-rpicamsrc copied to clipboard

Debian packaging fixes and variable fps fixes

Open mlankhorst opened this issue 7 years ago • 5 comments

mlankhorst avatar Nov 27 '17 17:11 mlankhorst

Op 28-11-17 om 15:11 schreef Jan Schmidt:

@thaytan commented on this pull request.


In src/RaspiCapture.c https://github.com/thaytan/gst-rpicamsrc/pull/70#discussion_r153501852:

@@ -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 https://github.com/thaytan/gst-rpicamsrc/pull/70#pullrequestreview-79515582, 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?

mlankhorst avatar Nov 28 '17 14:11 mlankhorst

If by 'if it's completely unset use 10 seconds?' you mean 500ms, then yes. The normal timeout should remain at 500ms

thaytan avatar Dec 04 '17 03:12 thaytan

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.. Won't 10.5 seconds still be better than 'indefinite', which was the problem being solved? ~Maarten

mlankhorst avatar Dec 06 '17 11:12 mlankhorst

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

thaytan avatar Dec 11 '17 16:12 thaytan

Could we set a reasonable timeout based on initial settings (FPS and shutter-speed), and then only ever increase it if either is changed?

mlankhorst avatar Dec 11 '17 16:12 mlankhorst