..and as a result gst_caps_is_equal() and others.
This now only checks if for every subset structure there is
a superset structure in the superset caps. Previously we were
subtracting one from another, creating completely new caps
and then even simplified them.
The new implemention now is about 1.27 times faster and doesn't
break the -base unit tests are anything anymore.
..and as a result gst_caps_is_equal() and others.
This now only checks if for every subset structure there is
a superset structure in the superset caps. Previously we were
subtracting one from another, creating completely new caps
and then even simplified them.
The new implemention now is about 1.27 times faster.
The feature name is not supposed to change over time anyway. In order to enforce
this parentize features to the registry and make the feature->name pointing to
GstObject:name. In 0.11 we could consider of removing the feature->name variable
(FIXME comment added).
Fixes: #459466
Some tests (e.g. elements/capsfilter) have pipelines with dangling
sinkpads and without a sink element. These pipelines can never post
an EOS message (because this is only valid by a sink) and as such
should never get an EOS message posted by the bin.
API: gst_mini_object_weak_ref()
API: gst_mini_object_weak_unref()
Add weak referencing functionality to GstMiniObject, which
allows to get notifications when an mini object is destroyed
but doesn't increase the real refcount. This is mostly
useful for bindings.
Fixes bug #609473.
API: GstElement::state_changed
This is always called when the state of an element has changed and
before the corresponding state-changed message is posted on the bus.
This allows to get the internal pad of ghostpads and
proxypads without using gst_pad_iterate_internal_links()
and is much more convenient.
The internal pad of a ghostpad is the pad of the opposite direction
that is used to link to the ghostpad target.
This prevents adding duplicates over and over again to the resulting
caps if they already describe the new intersection result.
While this changes intersection from O(n*m) to O(n^2*m), it results in
smaller caps, which in the end will decrease further processing times.
For example in an audioconvert ! audioconvert ! audioconvert pipeline,
when forwarding the downstream caps preference in basetransform
(see e26da72de25a91c3eaad9f7c8b2f53ba888a0394) this results in
16 instead of 191 caps structures.
Resetting the result is not necessary when resyncing because
pads that previously got the event will be skipped and we
need to consider the results of the previous pushes.
The refactoring of gst_debug_add_log_function() now causes build failure when
debug-logging is turned off. Just move it to the conditional part of the header.
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
