This flag is to indicate to child elements that they can add and
remove pads at any point in time without re-adding existing ones.
Elements should post before-hand a GST_MESSAGE_STREAM_COLLECTION
https://bugzilla.gnome.org/show_bug.cgi?id=772741
When we get GST_ITERATOR_RESYNC, we need to call gst_iterator_resync()
otherwise we will always get GST_ITERATOR_RESYNC (and that loop would
run forever).
gst/gstprintf unit test would fail on 32-bit x86 with:
gstprintf.c:83:printf_I32_I64:0: 'str' (64-bit x value = b5a6978f) is not equal to '"64-bit x value = f1e2d3c4b5a6978f"'
This reverts commit cfc565e2d8.
The commit was redundant since gst_gen_sources already contains
gstenum_h. We're still investigating why some people are still seeing
a racy build failure.
This forces gstenumtypes.h to be built whenever something uses gst_dep
as a subproject dependency. This is needed since gst/gst.h includes
gstenumtypes.h
Closes https://github.com/mesonbuild/meson/issues/714 which is not
actually a Meson bug.
Earlier we were only using __declspec(dllexport/import) when we were
built with MSVC because when built with MinGW and linking with MinGW we
don't need it (and we get linker errors because of it).
However, when we're built with MinGW and someone wants to link to us
with MSVC, we still need the prototypes to have __declspec(dllimport)
since MSVC cannot do auto-import like GCC can.
https://bugzilla.gnome.org/show_bug.cgi?id=771029
When using seek_simple() in combination with other kinds of seeks, this
becomes problematic. seek_simple() does not reset the stop position to
GST_CLOCK_TIME_NONE but keeps whatever a previous seek did. So for example
when doing a seek_simple() after a rate=-1 seek, we would usually get
assertions that start>stop (and stop being the old stop from the rate=1 seek).
https://bugzilla.gnome.org/show_bug.cgi?id=771104
In many parts of the code we raise streaming error when the flow
goes wrong, and each time we create more or less similare error
message. Also that message does not let the application know what
has actually gone wrong. In the new API we add a "flow-return" detail
field inside the GstMessage so that the application has all the information
if it needs it.
API:
GST_ELEMENT_FLOW_ERROR
https://bugzilla.gnome.org/show_bug.cgi?id=770158
We only use GST_EXPORT consistently when building with MSVC by using the
visual studio definitions files (win32/common/*.def), so always disable
it when building with Autotools and only enable it with Meson when
building with MSVC.
This allows you to use MinGW to link to a GStreamer built with MSVC and
get the correct function prototypes to find functions and variables in
DLLs.
Fixes g-i warning "Gst: Constructor return type mismatch
symbol='gst_element_message_new_details' constructed='Gst.Element'
return='Gst.Structure'".
This is a newly-added function in git that has not been in a stable
release yet, so it's fine to rename it. It's also only used indirectly
via macros.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.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.
This makes gstconfig.h completely arch-independent. Should cover all
compilers that gstreamer is known to build on, and all architectures
that I could find information on. People are encouraged to file bugs if
their platform/arch is missing.
A new event which precedes EOS in situations where we
need downstream to unblock any pads waiting on a stream
before we can send EOS. E.g, decodebin draining a chain
so it can switch pads.
https://bugzilla.gnome.org/show_bug.cgi?id=768995
Redirection messages are already used in fragmented sources and in
uridecodebin, so it makes sense to introduce these as an official message
type.
https://bugzilla.gnome.org/show_bug.cgi?id=631673
In some corner cases, the error 'code' part passed to
GST_ELEMENT_ERROR() is a valid define as well, in which
case it won't survive two levels of macro expansion, but
only one. Fixes:
oss4-sink.c: In function ‘gst_oss4_sink_open’:
error: ‘GST_RESOURCE_ERROR_0x00000002’ undeclared (first use in this function)
GST_ ## domain ## _ERROR_ ## code, __txt, __dbg, __FILE__,
which is from GST_ELEMENT_ERROR(el,RESOURCE,OPEN_WRITE,..)
and OPEN_WRITE happens to be defined to 2 here.
https://bugzilla.gnome.org/show_bug.cgi?id=756806https://bugzilla.gnome.org/show_bug.cgi?id=769117
gst_structure_id_get() returns a new reference so the returned object is
actually (transfer full).
The unit tests was already unreffing the objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
gst_structure_id_get() returns a new reference so the returned device is
actually (transfer full).
The code using this API was already correct but the code example in
comments was not.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
We don't free this from gst_deinit() but from gst_task_cleanup_all(),
so more GStreamer API may be called. In particular makes unit tests
work again with CK_FORK=no.
https://bugzilla.gnome.org/show_bug.cgi?id=768577
This ensures that all async operations (started from gst_element_call_async())
have been completed and so there is no extra thread running.
Fix races when checking for leaks on unit tests as some of those
operations were still running when the leaks tracer was checking for
leaked objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768577
gcc 6 has problems detecting and avoiding throwing
a warning for tautological compares in macros (they
should only trigger for compares outside macros).
Avoid them with a nasty cast of one parameter to void *
https://bugzilla.gnome.org/show_bug.cgi?id=764526
Especially if multiple threads are waiting for buffers to be available again,
the current code was wrong. Fix this and document clearly how the GstPoll is
supposed to be used.
Also fix some potential races with reading from the GstPoll before writing
actually happened.
https://bugzilla.gnome.org/show_bug.cgi?id=767979
It might happen that we popped the message before writing of the control
happened. In this case we just have to retry again a bit later, and failure to
do so will cause an additional byte in the control and the GSource /
gst_poll_wait() to always wake up again immediately.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
And also mention what the expected values of errno are going to be.
write_control() will only ever return FALSE if there was a critical error. It
will never return because of EINTR, EAGAIN or EWOULDBLOCK.
read_control() will return FALSE if there was no byte to read, in which case
errno would be EWOULDBLOCK.
In all other cases there was a critical error.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
On timer GstPolls it will cause the control socket state to become
inconsistent as now one less read_control() than write_control() be would
needed.
Similarly, read_control() and write_control() are only valid on timer
GstPolls.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
This might fail even under correct usage, e.g. if read_control() is called
from another thread before write_control() finished in another. It has to be
retried then, or other measures have to be taken, depending on how it is used
by the surrounding code.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
This addresses slightly different race conditions on Linux and Windows, and
fixes gst_poll_read_control() when control_pending == 0.
On Linux, the socketpair() used for control should not be made O_NONBLOCK.
If there's any propagation delay between set->control_write_fd.fd and
set->control_read_fd.fd, even the mutex now held will not be sufficient to
prevent a race condition. There's no benefit to using O_NONBLOCK, here.
Only liabilities.
For Windows, it's necessary to fix the race condition between testing
set->control_pending and performing WAKE_EVENT()/RELEASE_EVENT(). This is
accomplished by acquiring and holding set->lock, for both of these operations.
We could optimize the Linux version by making this Windows-specific.
For consistency with the Linux implementation, Windows' RELEASE_EVENT()
has also been made to block, although it should never happen.
Also, changed release_wakeup() to return TRUE and decrement control_pending
only when > 0. Furthermore, RELEASE_EVENT() is called only when
control_pending == 1.
Finally, changed control_pending to use normal, non-atomic arithmetic
operations, since it's now protected by set->lock.
Note: even though the underlying signaling mechanisms are blocking,
release_wakeup() is effectively non-blocking, as it will only attempt to read
from control_read_fd.fd after a byte has been written to control_write_fd.fd
or WaitForSingleObject() after it's been signaled.
https://bugzilla.gnome.org/show_bug.cgi?id=750397
GCC emits an error for this with -Werror:
plugin.c:22:1: error: 'gst_plugin_desc' initialized and declared 'extern' [-Werror]
This matches how glib does symbol exporting.
https://bugzilla.gnome.org/show_bug.cgi?id=767463
If the prototypes in the public API have dllimport in them when building
statically on Windows, the compiler will look for symbols with symbol
mangling and indirection corresponding to a DLL. This will cause a build
failure when trying to link tests/examples/etc.
External users of GStreamer also need to define -DGST_STATIC_COMPILATION
if they want to link to static gstreamer libraries on Windows.
A similar version of this patch has been committed to all gstreamer
repositories.
https://bugzilla.gnome.org/show_bug.cgi?id=767463
We already had a _full() version, but having that alone seems inconsistent.
Add a non-full version that mirrors the behaviour of gst_pad_link() vs
gst_pad_link_full().
For GST_EXPORT define and also things like GST_DISABLE_REGISTRY.
Hopefully fixes the following build failure on cerbero-cross-mingw32:
helpers/gst-plugin-scanner.c:50: undefined reference to `_imp___gst_disable_registry_cache'
This static library gets included directly into libgstreamer-1.0.so, so it needs
the same GST_EXPORTS definition as the rest of the code that's compiled into
that otherwise it will try to find the constants it uses from gstinfo via DLL
importing (__declspec(dllimport)).
Fixes https://ci.gstreamer.net/job/cerbero-cross-mingw32/4393/
__declspec(dllexport/import) are supported by GCC and are needed for
properly generating code that fetches the values of constants from DLLs
built with __declspec(dllexport) which happens when anything using
GST_EXPORT is built with MSVC.
See: https://msdn.microsoft.com/en-us/library/619w14ds.aspx
Essentially, if you built gstreamer with MSVC and then tried to use
constants from it (such as GST_TYPE_CAPS) in a plugin, GCC would
retrieve the address of the value instead of the value itself.
This means applications and bin sub-classes can easily track when
a new child element is added to the pipeline sub-hierarchy or
removed.
Currently doesn't signal deep added/removed for elements inside
a bin if a bin is added/removed.
https://bugzilla.gnome.org/show_bug.cgi?id=578933
Make it explicit that the pad is only blocked while the callback is running,
and the pad will be unblocked again once the callback returned.
If BLOCK and IDLE behaviour is needed, both need to be used.
https://bugzilla.gnome.org/show_bug.cgi?id=766002
When doing a transition from PLAYING to PLAYING, we will fail
to forward an EOS message on the bus, and noone else will ever
send it because there'll be no actual state changed message.
Allow EOS through directly in that case.
If there is only one pad in the internal pads, when folding for
LATENCY queries it will just drop the response if it's not live.
This is maybe not the proper fix, but it will just accept the first
peer responses, and if there are any other pads, it will only take
them into account if the response is live.
This *should* properly handle the aggregation/folding behaviour of
multiple live peer responses, while at the same time handling the
simple one-pad-only-and-forward use-case
https://bugzilla.gnome.org/show_bug.cgi?id=766360
A lot of debug categories are declared in element class_init
functions, which don't get run until the element is first created
(not just registered in the plugin load function). This means
that --gst-debug-help doesn't print out a lot of categories.
Creating an instance of each element from the element factory
makes them visible, at some extra cost - 2-3 times longer, which can
be a full second or two of extra waiting. Yikes!
https://bugzilla.gnome.org/show_bug.cgi?id=741001
When activating a pad in PULL mode, it might already be in PUSH mode. We now
first try to deactivate it from PUSH mode and then try to activate it in PULL
mode. If the activation fails, we would set the pad to flushing and set it
back to its old mode. However the old mode is wrong, the pad is not in PUSH
mode anymore but in NONE mode.
This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream
actually fails to go into PULL mode after first PUSHING data to typefind.
This calls a function from another thread, asynchronously. This is to be
used for cases when a state change has to be performed from a streaming
thread, directly via gst_element_set_state() or indirectly e.g. via SEEK
events.
Calling those functions directly from the streaming thread will cause
deadlocks in many situations, as they might involve waiting for the
streaming thread to shut down from this very streaming thread.
This is mostly a convenience function around a GThreadPool and is for example
used by GstBin to continue asynchronous state changes.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
Passing years > 9999, months > 12 or days > 31 to gst_date_time_new() will
cause an assertion and generally does not make much sense. Instead consider it
as a parsing error like hours > 24 and return NULL.
This previously caused uninitialized memory unless something else was
initializing all the fields explicitly to something.
To be on the safe side, we also allocate metas without init function to all
zeroes now as it was relatively common.
https://bugzilla.gnome.org/show_bug.cgi?id=764902
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
