These work the same way as the corresponding properties on queue and
allow to control the internal buffer size of the appsrc in a more
flexible way.
Unlike in queue the max-buffers and max-time properties are 0 (i.e.
disabled) by default for backwards compatibility reasons.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1133>
Add property "handle-segment-change" for user to allow pushing
custom segment event. For now, this property can work only for
time format GstSegment.
This property can be useful in case application controls timeline
of stream such as there is timestamp discontinuity but playback is
expected to be continuous. Multi-period scenario of MPEG-DASH is an
example of this use case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/663>
Previously we would simply use them without any locking at all, while
using the object lock for setting them. Nothing prevented new callbacks
to be set in the meantime, potentially calling a callback with already
freed user_data.
To prevent this move the callbacks into a reference counted struct and
use the appsrc/appsink mutex to protect access to it, which is used in
all functions calling the callbacks already anyway.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/729
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
It is possible that both application and the stream are waiting
currently, if for example the following happens:
1) app is waiting because no buffer in appsink
2) appsink providing a buffer and waking up app
3) appsink getting another buffer and waiting because it's full now
4) app thread getting back control
Previously step 4 would overwrite that the appsink is currently waiting,
so it would never be signalled again.
https://bugzilla.gnome.org/show_bug.cgi?id=795551
Performance optimisation: Keep track whenever the streaming
thread or the application thread are waiting on the GCond for
more space or new data, and only signal on the GCond if someone
is actually waiting. Avoids unnecessary syscalls and thus
context switches.
Initialize min and max _get_property() to gets rid of these
compiler warnings:
gstappsrc.c:741:7: error: 'max' may be used uninitialized in this function
g_value_set_int64 (value, max);
^
gstappsrc.c:733:7: error: 'min' may be used uninitialized in this function
g_value_set_int64 (value, min);
^
Which happens because gcc doesn't know that GST_IS_APP_SRC will never
fail here.
https://bugzilla.gnome.org/show_bug.cgi?id=752052
The EOS event can be propagated to the downstream elements when
is_eos flag remains set even after leaving the flushing state.
This fix allows this element to normally restart the streaming
after receiving the flush event by clearing the is_eos flag.
https://bugzilla.gnome.org/show_bug.cgi?id=759110
Otherwise the application might push new buffers into the queue while we're
flushing, potentially causing the GQueue data structure to become inconsistent
and causing crashes soon after.
https://bugzilla.gnome.org/show_bug.cgi?id=754597
