We never run as a live element, even if upstream is live, and never
output any buffers with latency but immediately generate buffers as
fast as we can according to the negotiated framerate.
Passing the query upstream would proxy whatever mode of operation
upstream has, which has nothing to do with how we produce buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/653>
First of all get rid of the atomic seeking boolean, which was only ever
set and never read. Replace it with a flushing boolean that is used in
the loop function to distinguish no buffer because of flushing and no
buffer because of an error as otherwise we could end up in a
GST_FLOW_ERROR case during flushing.
Also only reset the state of imagefreeze in flush-stop when all
processing is stopped instead of doing it as part of flush-start.
And last, get a reference to the imagefreeze buffer in the loop function
in the very beginning and work from that as otherwise it could in theory
be replaced or set to NULL in the meantime as we release and re-take the
mutex a couple of times during the loop function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/580>
By default imagefreeze will still reject new buffers after the first one
and immediately return GST_FLOW_EOS but the new allow-replace property
allows to change this.
Whenever updating the buffer we now also keep track of the configured
caps of the buffer and from the source pad task negotiate correctly
based on the potentially updated caps.
Only the very first time negotiation of a framerate with downstream is
performed, afterwards only the caps themselves apart from the framerate
are updated.
The imagefreeze element can be handy for benchmarking downstream
elements because it re-uses the same buffer memory and introduces less
overhead compared to always creating new frames with videotestsrc.
However it's not possible to make imagefreeze send EOS when using
gst-launch-1.0.
Add a num-buffers property to make it look more like a source in the
above scenario.
Upstream elements like videoflip can transform caps, such as changing width and height.
When an imagefreeze downstream receives an ACCEPT_CAPS query it will NOW return
all caps that it can accept.
https://bugzilla.gnome.org/show_bug.cgi?id=778389
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
The downstream caps query with a filter alraedy gives us the possible
intersection so there is no need to check it again with downstream
if it is supported. Just try to set it directly.
This reverts commit d46631c5c7.
pad only handle EOS events but not EOS flow, and will push the buffer again
resulting in an assertion error. So we should not handle the buffer
and return EOS flow.
gst_buffer_ref and gst_buffer_writable is being used to create a writable copy of source buffer.
replacing the same with gst_buffer_copy as the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735880
Adding an extra condition while calling gst_caps_unref (templ)
and replacing gst_caps_make_writable (gst_caps_ref (caps)) with
gst_caps_copy (caps) in line 177, since the functionality is same.
https://bugzilla.gnome.org/show_bug.cgi?id=735795
We return EOS after the first buffer, and GstPad will make sure now that we
won't get any other buffer afterwards until a flush happens. No need to check
for it ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=735581
Since the initial decoded still image buffer will have dts=pts=0, and
we only set PTS on buffers we push out, all buffers pushed out would
have a DTS of 0. Sinks, however, will prefer DTS over PTS if both are
set, and will therefore always see a timestamp of 0 no matter what
the PTS is set to.
Fixes unit test too.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
