This was a misguided effort to try and guarantee the buffers of
the sink pads would not change during aggregate, when an upstream
branch is seeked independently, however this is simply incorrect
as downstream has not necessarily been flushed, or the aggregate
function might be waiting to receive buffers on other pads.
In !159 , we switched to sending flush_start ourselves from the
do_seek implementation. If no flushing seek successfully made its
way upstream, we need to send flush_stop ourselves as well.
Releasing a GRecMutex from a different thread is undefined
behaviour.
There should be no reason to hold the stream lock from the
moment aggregator receives a flush_start until it receives
the last flush_stop: the source pad task is stopped, and can
only be restarted once the last flush_stop has arrived.
I can only speculate as to the reason why this was done,
as it was that way since the original commit. My best
guess is that aggregator originally didn't marshall events
and queries to the aggregate thread, and this somehow
helped work around this.
Instead of tracking "pending_flush_*" on the pads and the
aggregator, we now simply track the last seqnum for flush start
and flush stop events on the pads, and use it to determine whether
we should enter or exit our flushing state.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/977
Since we started depending on GLib 2.44, we can be sure this macro is
defined (it will be a no-op on compilers that don't support it). For
plugins we should just start using `G_DECLARE_FINAL_TYPE` which means
we no longer need the macro there, but for most types in core we don't
want to break ABI, which means it's better to just keep it like it is
(and use the `#ifdef` instead).
Not that it matters, since we don't check the return value
anyway. Unclear why the aggregator pad flush function should
have a return value at all really, and perhaps it should be
called reset anyway. Spotted by dv on irc.
* Making sure that `static inline` function are in the GIR (by first
defining them, and make sure to mark as skiped)
* Do not try to link to unexisting symbols
* Also generate GIR information about gst_tracers
The signal will be emitted when a buffer was consumed on
a pad, if the newly-added "emit-signals" property has been
set to TRUE.
Handlers connected to the signal will receive a valid reference on
the consumed buffer, allowing for example the retrieval of metas in
order to forward them once an output buffer is pushed out.
Fixes flaky appsrc unit test where depending on scheduling
the submitted list might not be writable if submitted via
an action signal from the application thread.
Fixes gst-plugins-base#522
baseparse internally uses a 64kb buffer for pulling data from upstream.
If a 64kb pull is failing with a short read, it would previously pull
again the requested size.
Doing so is not only inefficient but also seems to cause problems with
some elements (rawvideoparse) where the second pull would fail with EOS.
Short reads are only allowed in GStreamer at EOS.
Closes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/294
gst_queue_array_clear will clear the GstQueueArray,
gst_queue_array_set_clear_func will set a clear function for each
element to be called on _clear and on _free.
https://bugzilla.gnome.org/show_bug.cgi?id=797218
This is exposed as a solution to the use case of plugging in
sources with a higher latency after the aggregator has started
playing with an initial set of sources, allowing to avoid resyncing.
https://bugzilla.gnome.org/show_bug.cgi?id=797213
Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
The avg_bitrate is an unsigned int, so the gst_util_uin64_scale() function can't
be used for it, as it expects signed integers for the fraction parts arguments.
https://bugzilla.gnome.org/show_bug.cgi?id=797054
Don't return a value from a function that doesn't
return a value using the returned value from a
function that also doesn't return a value.
gstbitwriter.h(265): warning C4098: 'gst_bit_writer_align_bytes_unchecked': 'void' function returning a value
And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
