gst_v4l2_open() is called by gst_v4l2_device_provider_probe_device(),
where the GstV4l2Object is created without an associated GstElement.
If gst_v4l2_open() fails, it raises a bus message, but without an
element, a precondition check fails on
gst_element_message_full_with_details() generating a crash if running
with fatal-warnings debug mode.
GstV4l2Error is a helper to raise error bus messages when it is
appropiated. This patch changes the direct bus messages to this
helper, and the elements will actually send the error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/694>
We claim output buffers are nal-aligned, but that wasn't
actually true: We would push out a partial nal in case
the nal doesn't fit into the max encoder-selected output
buffer size, and then the next buffer would not start
with a sync marker. That's not right and makes h264parse
unhappy.
Instead accumulate buffers until we have a full frame
(we can't rely on the NAL_END flag, it's always set).
Fixes#768
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/682>
Make extra sure all the required mmal libs such as libmmal_vc_client.so
actually get linked and stay linked. Otherwise the above error happens
it seems.
buster (10.4) with meson 0.55 and pi ref 2020-05-27
pi-gen, 825107f04027269db77426046f5085475b1ea22f, stage5
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/682>
mmal_queue_timedwait() might spuriously return immediately
if called at exactly the wrong instant due to an internal
off-by-one bug. Attempt to work around that and just retry.
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.
The text annotation colour properties take an integer value
corresponding to a VUY colour, not a text string like
the copy-pasted description from raspivid suggests.
Fixes https://github.com/thaytan/gst-rpicamsrc/issues/59
make sure outgoing buffers have at least some duration set,
otherwise it leads to strange situations, like qtmux writing
out a file that doesn't include the final frame inside the
playable segment, because no-duration = 0 duration there.
The JPEG codec hangs, not sure why yet. The MJPEG
codec doesn't provide a quality setting, and sometimes
freezes on shutdown, but otherwise seems more
reliable
Don't unref the passed event when handling events via
the GstBaseSrc src pad event handler - basesrc does
the unref. That breaks handling of upstream
force-key-unit events by unreffing twice.
Fixes https://github.com/thaytan/gst-rpicamsrc/issues/43
