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.
The while loop should end when all buffers "and" the preroll
buffer are consumed but this means to continue waiting if there
are still some pending buffers "or" preroll buffer.
The unit test was correct but racy because of this mistake.
I.e. because of the wrong "and" the while could finish too early.
cd tests/check && GST_CHECKS=test_query_drain make elements/appsink.forever
https://bugzilla.gnome.org/show_bug.cgi?id=789763
If someone calls gst_app_sink_try_pull_sample they are
probably no longer interested in any preroll samples.
Useful if the user has not registered a preroll appsink callback.
Also added unit test 'test_do_not_care_preroll'
make elements/appsink.check
that fails without this patch.
https://bugzilla.gnome.org/show_bug.cgi?id=786740
There is no reason for appsink to hang onto the preroll buffer.
If needed, the application can just keep a ref on this buffer
after calling gst_app_sink_try_pull_preroll.
Also added unit test 'test_pull_preroll'
make elements/appsink.check
https://bugzilla.gnome.org/show_bug.cgi?id=786740
Rename function parameter and make sure the name in the
declaration matches the name in the implementation, to
avoid g-i warnings. Also add Since markers for gtk-doc.
gstappsink.c:1248: Warning: GstApp: gst_app_sink_set_buffer_list_support:
unknown parameter 'buffer_list' in documentation comment, should be 'drop'
The _pull_sample() and _pull_preroll() functions block
until a sample is available, EOS happens or the pipeline
is shut down (returning NULL in the last two cases).
This adds _try_pull_sample() and _try_pull_preroll()
functions with a timeout argument to specify the maximum
amount of time to wait for a new sample.
To avoid code duplication, wait forever if the timeout is
GST_CLOCK_TIME_NONE and use that to implement
_pull_sample/_pull_preroll with the original behavior.
Add also corresponding action signals "try-pull-sample"
and "try-pull-preroll".
https://bugzilla.gnome.org/show_bug.cgi?id=768852
last_segment is only being updated in dequeue_buffer(),
which is only called from _pull_sample(). _pull_preroll()
simply re-uses an old or dummy segment while the actual
one sits and waits in the queue.
https://bugzilla.gnome.org/show_bug.cgi?id=751147
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
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.
Replace g_thread_create() with g_thread_try_new().
Make appsink return a GstSample. Remove the pull_buffer_list method because it
is not very useful anymore.
Pass GstSample to the conversion function.
Update playbin2 and examples
