Just disable the camera component when it fails to start. The
most common reason is that the camera device is already in use,
and if we just disable the mmal component correct cleanup
will happen later
rpicamsrc on a normal rpi camera doesn't start up fast enough,
and always fails the new 100ms timeout. A better solution
might be to have a longer timeout for the first frame, but
shorter once frames are running - but this quick fix will at
least make rpicamsrc work again.
If an external camera was disconnected, there were no feedback in an
application. It seems reasonable to wait on mmal_queue no longer than
100ms. If it's stuck we just return a FLOW_ERROR and let the application
decide what to do later.
If use-stc=false, then rpicamsrc won't apply
the camera timestamping to outgoing buffers, instead
relying on real-time timestamping by the
GStreamer clock. It means slightly less accuracy
and more jitter in timestamps, but might help on some
CSI inputs with broken timestamping.
Make sure to update the captsure config before starting
capture. Since the capture component now keeps a local
copy of the config, it's not updated automatically.
Use memset on the stack allocated MMAL_PARAMETER_VIDEO_INTRA_REFRESH_T
struct. Apparently mmal_port_parameter_get() doesn't retrieve all
parameters, causing random failures when we set the intra-refresh
param on the encoder.
Fixes https://github.com/thaytan/gst-rpicamsrc/issues/22 for me.
Don't apply timestamps based on output time from the encoder,
but use the MMAL STC and capture PTS to generate a GStreamer
timestamp that more accurately resembles the input (and would
preserve reordering should the encoder ever add B-frames).
Fixes https://github.com/thaytan/gst-rpicamsrc/issues/16
