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
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
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'
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
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
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
gir include search directories should respect PKG_CONFIG_PATH,
just like we do everywhere else. Makes g-i pick up the right
paths when using ./configure --with-pkg-config-path=
https://bugzilla.gnome.org/show_bug.cgi?id=755494
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
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
