Drop in old GstBus code for the release to play it safe, since
regressions that are apparently hard to track down and reproduce
have been reported (on windows/OSX mostly) against the lockfree
version, and more time is needed to fix them.
This reverts commit 03391a8970.
This reverts commit 43cdbc17e6.
This reverts commit 80eb160e0f.
This reverts commit c41b0ade28.
This reverts commit 874d60e589.
This reverts commit 79370d4b17.
This reverts commit 2cb3e52351.
This reverts commit bd1c400114.
This reverts commit 4bf8f1524f.
This reverts commit 14d7db1b52.
https://bugzilla.gnome.org/show_bug.cgi?id=647493
When a plugin file no longer exists, e.g. because it's been removed or
renamed, don't remove all features in the registry based on the *name*
of the plugin they belong to, but only remove those who actually belong
to that particular plugin (object/pointer).
This fixes issues of plugin features disappearing when a plugin .so file
is renamed.
https://bugzilla.gnome.org/show_bug.cgi?id=604094
... which happens in particular flushing a bus, possibly as part
of a state change, e.g. when having a pipeline in a pipeline
and then changing state back to NULL. The interior pipeline
will/might then flush the bus, which is a child bus from the
parent which does not have a poll anymore these days.
https://bugzilla.gnome.org/show_bug.cgi?id=648297
Protect index with its own lock. gst_index_get_writer_id() may take
the object lock internally (the default resolver, GST_INDEX_RESOLVER_PATH,
will anyway), so if we're using that to protect the index as well,
we'll deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=646811
Based on patch by: Daniel Macks <dmacks@netspace.org>
Earlier versions of OSX don't support proper multiarch and
trying to use /usr/bin/arch -foo with those versions would
just break things.
https://bugzilla.gnome.org/show_bug.cgi?id=615357
Change semantics of gst_base_parse_push_frame() and make it take
ownership of the whole frame, not just the frame contents. This
is more in line with how gst_pad_push() etc. work. Just transfering
the content, but not the container of something that's not really
known to be a container is hard to annotate properly and probably
won't work. We mark frames allocated on the stack now with a private
flag in gst_base_parse_frame_init(), so gst_base_parse_frame_free()
only frees the contents in that case but not the frame struct itself.
https://bugzilla.gnome.org/show_bug.cgi?id=518857
API: gst_base_parse_frame_new()
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
