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
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
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.
On OSX, GStreamer might be built as a 'fat/universal' binary containing
both 32-bit and 64-bit code. We must take care that gst-plugin-scanner
is executed with the same architecture as the GStreamer core, otherwise
bad things may happen and core/scanner will not be able to communicate
properly.
Should fix issues with (32-bit) firefox using a 32-bit GStreamer core
which then spawns a 'universal' gst-plugin-scanner binary which gets
run in 64-bit mode, causing 100% cpu usage / busy loops or just hanging
firefox until killed.
https://bugzilla.gnome.org/show_bug.cgi?id=615357
As GST_SCHEDULING reports when buffers pass through pads due to
gst_pad_push calls, they are a good way of tracking the progress of
buffers through pipelines. As such, adding output of the buffer pointers
to these messages allows tracking of specific buffers, easing debugging.
Remove the android/ top dir
Fixe the Makefile.am to be androgenized
To build gstreamer for android we are now using androgenizer which generates the needed Android.mk files.
Androgenizer can be found here: http://git.collabora.co.uk/?p=user/derek/androgenizer.git
Even if we currently do not have a duration yet, assume seekable if
it looks like we'll likely be able to determine it later on
(which coincides with needed information to perform seeking).
Fixes#641047.
Rather than a fixed default frame count, estimate frame count to aim for
an interval duration depending on fps if available, otherwise use old
fixed default.
Also add a format flag to signal baseparse that subclass/format can provide
(parsed) timestamp rather than an estimated one. In particular, such "strong"
timestamp then allows to e.g. determine duration.
Don't unref the event if it hasn't been handled, because the caller
assumes it is still valid and might reuse it.
I ran into this problem when transcoding an AVI (with mp3 inside)
to gpp.
https://bugzilla.gnome.org/show_bug.cgi?id=639555
That is, as such formats allow subclass to extract position from frame,
it is possible to extract duration (if not otherwise provided)
from (near) last frame, and a seek can fairly accurately target the required
position.
Fixes#631389.
Arrange for upstream as well as downstream flushing when seeking.
Also determine upstream size as well as seekability. Adjust some comments
to reality and employ debug statement in proper order.
This reverts commit b5a3d60363.
Reverting this for now, since no one really seems to remember why this
property exists or what it could possibly be good for. It seems to have
been in the original mp3parse since the beginning of time and was back-
ported from there.
Seekability, like duration, etc is unlikely to change (frequently), and
the default assumption covers most cases, so let subclass set when needed.
At the same time, allow subclass to indicate if it has seek-metadata (table)
available, and possibly have it provide an average bitrate.
This allows the child class to chain its event handler with
GstBaseParse, so that subclasses don't have to duplicate all the default
event handling logic.
https://bugzilla.gnome.org/show_bug.cgi?id=622276
We wait to parse a minimum number of frames (10, arbitrarily) before
emiting bitrate tags so that our early estimates are not wildly
inaccurate for streams that start with a silence. If the stream ends
before that, we just emit the tags anyway.
While it _would_ be nicer to be specify the threshold to start pushing
the tags in terms of duration, this would introduce more complexity than
this merits.
https://bugzilla.gnome.org/show_bug.cgi?id=614991
This makes baseparse keep a running average of the stream bitrate, as
well as the minimum and maximum bitrates. Subclasses can override a
vfunc to make sure that per-frame overhead from the container is not
accounted for in the bitrate calculation.
We take care not to override the bitrate, minimum-bitrate, and
maximum-bitrate tags if they have been posted upstream. We also
rate-limit the emission of bitrate so that it is only triggered by a
change of >10 kbps.
Perform sanity check on type of seek, and only perform one that is
appropriately supported. Adjust downstream newsegment event
to first buffer timestamp that is sent downstream.
In particular, consider DISCONT == !sync, and allow subclass to query
sync state, as it may want to perform additional checks depending
on whether sync was achieved earlier on.
Also arrange for subclass to query whether leftover data is being drained.
In particular, (optionally) provide baseparse with a notion of frames per second
(and therefore also frame duration) and have it track frame and byte counts.
This way, subclass can provide baseparse with fps and have it provide default
buffer time metadata and conversions, though subclass can still install
callbacks to handle such itself.
After all, stream is as-is, and there is little molding to downstream's
taste that can be done. If subclass can and wants to do so, it can
still override as such.
Also handle the case gracefully where the subclass decides to drop
the first buffers and has no caps set yet. It's still required to
have valid caps set when the first buffer should be passed downstream.
Sending the flush-start event forward before taking the stream lock actually
works, in contrast to deadlocking in downstream preroll_wait (hunk 1).
After that we get the chain function being stuck in a busy loop. This is fixed
by updating the minimum frame size inside the synchronization loop because the
subclass asks for more data in this way (hunk 2).
Finally, this leads to a very probable crash because the subclass can find a
valid frame with a size greater than the currently available data in the
adapter. This makes the subsequent gst_adapter_take_buffer call return NULL,
which is not expected (hunk 3).
Baseparse internaly breaks the semantics of a _chain function by calling it with
buffer==NULL. The reson I belived it was okay to remove it was that there is
also an unchecked access to buffer later in _chain. Actually that code is wrong,
as it most probably wants to set discont on the outgoing buffer.
This allows to only create the socketpair when it is really required instead
of always creating it and immediately destroying it again for child buses.
https://bugzilla.gnome.org/show_bug.cgi?id=647005
This is used by GstBin to create a child bus without
a socketpair because child buses will always work
synchronous. Otherwise too many sockets could be
created and the limit of file descriptors for the
process could be reached.
Fixes bug #646624.
if set->control_pending is set to 0 but we didn't not succed reading
the control socket, future calls to gst_poll_wait() will be awaiken
by the control socket which will not be released properly because
set->control_pending is already 0, causing an infinite loop.
This caused "re-declaration" problems.
./clutter-gst-video-sink.c: In function ‘clutter_gst_video_sink_init_interfaces’:
./clutter-gst-video-sink.c:231:1: warning: declaration of ‘ClutterGstVideoSink’ shadows a global declaration [-Wshadow]
./clutter-gst-video-sink.h:64:44: warning: shadowed declaration is here [-Wshadow]
https://bugzilla.gnome.org/show_bug.cgi?id=646531
Some applications are requesting the same pad name multiple times
and the behaviour is undefined and different from element to element
but we don't want to break applications that work just fine.
In 0.11 this check should be an assertion again, although elements
have to do manual checking if the pad already exists again because
it can't be done in a threadsafe way here.
basesrc's default event handler returns TRUE regardless of whether the
event is handled or not. This fixes the handler to conform with the
expected behaviour (which is to only return TRUE when the event has
actually benn handled). gst_bin_do_latency_func() depended on this
(incorrect) behaviour, and is now modified as well.
(Remaining 1-liner change in gstbasesrc.c is to keep gst-indent happy)
Just like gst_caps_intersect, but adds a new parameter 'mode'
that allows selecting the intersection algorithm to use.
Currently we have GST_CAPS_INTERSECT_MODE_ZIG_ZAG (default) and
GST_CAPS_INTERSECT_MODE_FIRST.
API: gst_caps_intersect_full
API: GstCapsIntersectMode
API: GST_CAPS_INTERSECT_MODE_ZIG_ZAG
API: GST_CAPS_INTERSECT_MODE_FIRST
https://bugzilla.gnome.org/show_bug.cgi?id=617045
Adding a buffer to the end of a GstBufferList is supposed to be a fast
operation, but it was not since the iterator does not advance its
nextpointer when adding buffers and GList does not have a tail pointer.
Using a GQueue to store the buffers makes it easier to add buffers to
the end of the list and this operation will now be much more efficient.
Adding an entire GList of buffers using
gst_buffer_list_iterator_add_list() will however have to iterate over
the list being added to be able to update the tail pointer in the
GQueue.
GST_DISABLE_DEPRECATED should only affect visibility of declarations in headers,
not actually remove symbols. See GitDeveloperGuidelines and DeprecatingAPI
pages in wiki.
https://bugzilla.gnome.org/show_bug.cgi?id=402141
Add new functions to clarify how the caps are compared to the template caps of
the element factory. Improve the docs to point out the difference.
Deprecate: gst_element_factory_can_{src|sink}_caps
API: add gst_element_factory_can_{src|sink}_{any|all}_capps
https://bugzilla.gnome.org/show_bug.cgi?id=402141
Check if structure has been created before appending it to the caps. Free the
caps in the case of an error to not conceal it be returning empty caps.
Fixes#642271
Add function that (unlike the GLib equivalent) also accepts paths that
aren't absolute and will clean up relative markers such as ./ and ../
before forming a URI.
Fixes warnings with e.g. filesrc location=foo ! typefind caused by the
recent switch to g_filename_to_uri(), but also actually creates valid
URIs for the first time.
Windows code paths could need some more work, e.g. we don't clean up
the relative markers there for now (because path could have \ and /
as separators).
API: gst_filename_to_uri()
This was required to add a new MEDIA4 buffer flag for indicating
progressive/mixed telecine video buffers. There is no space for
additional flags in GstBuffer, so steal one from GstMiniObject.
https://bugzilla.gnome.org/show_bug.cgi?id=642671
This commit changes the request pad behaviour for plugins and applications.
Reopens Bug #402562
The proper fix for that bug is to keep track of created request pads.
This reverts commit a5e44ffffa.
Use new GstPoll functionality to wakeup the mainloop.
Use an atomic queue on the writer side to post the messages.
The reader side it protected with the lock still because we don't want multiple
concurrent readers.
Add an atomic queue. The queue can be used from multiple threads simultaneously
and without taking any locks or doing any blocking operations. This makes it
highly scalable for things like the bus, bufferpools and object recycling.
We need to ensure we call gst_pad_check_link() with the two pads in the correct
order. The order depends on wheter we iterate src or sink pads.
Signed-off-by: Chen Rui <rui.chen@tieto.com>
Check the sinkpad for the flushing state before calling the chainfunction on the
pad. We do this by checking the cache (which is also cleared on the srcpad when
the sink is set to flushing).
Fixes#641928
Failing to do so in the Windows case (implicitly triggered otherwise)
would have a subsequent _wait return immediately leading to high CPU
usage timeout loops.
Fixes#640675.
Make adding/removing gst_debug_log_default() work reliably in all
circumstances. The problem was that depending on platform and linker
flags the function argument might resolve to different addresses,
which made it impossible to remove the default log function added
in gst_init() from application code (because the pointer values
didn't match). The new approach should keep things simple by passing
NULL for the default function, which the code in libgstreamer can
then handle.
https://bugzilla.gnome.org/show_bug.cgi?id=625396https://bugzilla.gnome.org/show_bug.cgi?id=640771
Makes gst_bus_add_watch(), gst_bus_add_watch_full(), gst_bus_add_signal_watch(),
and gst_bus_add_signal_watch_full() convenience functions automatically pick up
any non-default main contexts set for the current thread via
g_main_thread_push_thread_default().
gstelement.c: In function ‘gst_element_get_request_pad’:
gstelement.c:1052:18: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
https://bugzilla.gnome.org/show_bug.cgi?id=640850
The description string was changed to an inlined string a while back.
(But: no need to intern the const strings here, we just use the interning
to avoid allocating duplicates and make memory management easier,
since the strings will be around for the life-time of the app anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=640071
Only replace existing plugins by blacklisted ones if they correspond
to the exact same plugin. If they're not the same, keep the existing
valid one.
Fixes#638941
Ignore plugins which have been moved into coreelements, so it's
still possible to just upgrade GStreamer core without having to
upgrade the whole stack.
This reverts commit f9039c2204.
We use -DG_DISABLE_ASSERTS for releases and pre-releases, but
don't want to disable pad name checking for releases in general,
I think. Need a better solution here. Fixes pad unit test in
pre-release/release mode.
Avoid unnecessary malloc/free to get the file basename on MSVC to avoid
unnecessary overhead when doing GST_DEBUG=foo:5 or so (since it would be
done before the category log level filtering).
The new request_new_pad_full vmethod provides an additional caps field,
which allows elements to take better decision process.
Also, add a gst_element_request_pad() function to allow developers to be
able to specify which pad template they want a pad of.
Convert gstutils to use that new method instead of the old one when more
efficient.
This is useful for being able to request pads in a more flexible way,
especially when the element can provide pads whose caps depend on
runtime configuration and therefore can't provide pre-registered
pad templates.
API: GstElement::request_new_pad_full
API: gst_element_request_pad
https://bugzilla.gnome.org/show_bug.cgi?id=637300
We need to reset the revents field of each pollfd when reading the results
from select else we'll end up with stray info from previous calls to
select.
Fix freeing of partially-inited list value when both values
passed are equal and we want to return a single non-list
value as result. Fixes unit test. Also fix up docs a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=637776
The -Bsymbolic change causes us to get a different address when internaly
looking up the function than what application would get when the use the symbol
that they see. This made removing the default loghandler to fail, as it is set
internally and removed externaly.
