When a pad is added the need-parent flag is set to true, so when
they are removed the flag should be set back to false
This was preventing GstPads to be reused in elements (removed and
later re-added). A unit tests was added to verify that this is
working now.
The use case is tsdemux that has a program-number property and
allows the user to switch programs. In order to do that tsdemux
will remove the pads of the current program and add from the new
ones. The removed pads are kept in the demuxer for later if the
user selects the old program again.
Stores the last result of a gst_pad_push or a pull on the GstPad and provides
a getter and a macro to access this field.
Whenever the pad is inactive it is set to FLUSHING
API: gst_pad_get_last_flow_return
https://bugzilla.gnome.org/show_bug.cgi?id=709224
Currently there is no other way to unlock a buffer pool other then
stopping it. This may have the effect of freeing all the buffers,
which is too heavy for a seek. This patch add a method to enter and
leave flushing state. As a convenience, flush_start/flush_stop
virtual are added so pool implementation can also unblock their own
internal poll atomically with the rest of the pool. This is fully
backward compatible with doing stop/start to actually flush the pool
(as being done in GstBaseSrc).
https://bugzilla.gnome.org/show_bug.cgi?id=727611
When we call gst_buffer_pool_set_config() the pool may return FALSE and
slightly change the parameters. This helper is useful to do the minial required
validation before accepting the modified configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=727916
According to the documentation, when set_config() return false, it should be
possible to read the modified version of the config. This patch fixes the
implementation so it is now according to the documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=727916
If a pool config is being configured again, check if the configuration have changed.
If not, skip that step. Finally, if the pool is active, try deactivating it.
https://bugzilla.gnome.org/show_bug.cgi?id=728268
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Currently we set TAG_MEMORY as soon a resize changes the size of one
of the memory. This has the side effect that buffer pool cannot know if
the memory have simply been resized, or if the memorys has been replaced.
This make it hard to actually implement _reset(). Instead, only set the
TAG_MEMORY if one or more memory has been replaced, and do a light
sanity check of the size.
https://bugzilla.gnome.org/show_bug.cgi?id=727109
We might not have reached PAUSED yet because of an async error,
but nonetheless we want to make sure that the pads are always
deactivated in READY state.
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
CID #1037132
This should allow for more meaningful errors. Dereferencing NULL
is more useful information than dereferencing a random address
happened to be on the stack.
We want to iterate over items idx to idx + length
We use the len variable as the corrected number of memory to iterate
and then properly go over all items.
Fixes the issue where specifying any idx different from 0 had no effect
Spotted by clang static analyzer
Events passing through #GstPads that have a running time
offset set via gst_pad_set_offset() will get their offset
adjusted according to the pad's offset.
If the event contains any information that related to the
running time, this information will need to be updated
before usage with this offset.
GST_DEBUG_BIN_TO_DOT_FILE() would cause a segfault whenever it encountered an
element's caps that had a field value being NULL. Such fields are successfully
handled e.g. by GST_*_OBJECT(), and with this patch so does
GST_DEBUG_BIN_TO_DOT_FILE(). Even if string fields with a NULL value are
not supposed to be valid in caps, such caps can be created.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727701
The step can end up being zero if the underlying value isn't a valid
range GValue.
In those cases, return FALSE.
We don't use g_return*_if_fail since it will already have been triggered
by the above-mentionned _get_step() functions.
Spotted by Coverity.
Every instance of calling bin_do_message_forward() first took the
object lock, so that bin_do_message_forward() could drop it and
then reclaim. Instead, only take the object lock afterward where
needed.
Add loop_type and repeat_count fields to GstTocEntry plus setters and getters.
This allows to represent edit-lists in a toc as well as loops in instruemnts (wav, xi).
API: gst_toc_entry_set_loop
API: gst_toc_entry_get_loop
This ensures that the lock of the internal pad is held while referencing
it's peer (= the target pad), which ensures that the peer is not
going to be unlinked/destroyed in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=725809
This was plain text that had all list items one after the other (including a
repeated number). Now it will atleast look good when processed with gtk-doc
1.20.
Tag allocated buffers with TAG_MEMORY. When they are released later,
only add them back to the pool if the tag is still there and the memory
has not been changed, otherwise throw the buffer away.
Add unit test to check various scenarios.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=724481
Use the technique that is now done in GTK+ so that the plugins do not have
to be installed in c:\gstreamer\lib\<debug>\gstreamer-$(GSTApiVersion),
but can be installed in
<parent_folder_of_gstreamer_main_dll>\lib\<debug>\gstreamer-$(GSTApiVersion),
or as per g_win32_get_package_installation_directory_of_module() allows.
https://bugzilla.gnome.org/show_bug.cgi?id=679115
... instead of returning a reference to a global instance. The caller might
want to change the global instance otherwise, which causes funny effects like
all global instances being changed and at the same time nothing in the caps
being changed.
As the caps might be immutable while we do this we have to do some magic
with atomic operations.
https://bugzilla.gnome.org/show_bug.cgi?id=723236
Keep an extra write ref on the control socket. This ensures that we
avoid a read/write on the socket when going from non-empty->empty->not-empty.
We remove the write ref only when we actually are empty and we need to
wait for flushing or a new buffer.
This makes the bufferpool benchmark about 30% faster than the pure
malloc implementation.
This way we make sure that a) the lock is always taken when checking
the cookie and calling the iterator's next functions and b) it is
not taken while calling any of the iterator filter functions.
https://bugzilla.gnome.org/show_bug.cgi?id=711138
events_foreach adds an extra ref when giving the event to the
user function. In case it was unrefed by the user, this extra ref
disappeared, but events_foreach still should unref again to
lose its own ref before removing the event from the array.
https://bugzilla.gnome.org/show_bug.cgi?id=722467
Make this work again:
audiotestsrc ! tee name=t t.src_0 ! queue ! fakesink t.src_1 ! queue ! fakesink
and this fail again:
audiotestsrc ! tee name=t t.src_1 ! queue ! fakesink t.src_0 ! queue ! fakesink
as tee just counts itself and does not care about the pad names we request
from it.
This allows blocking a pad, add a new blocking probe, removing
the first probe and then having the second probe called. Which
could then decide that data-flow should actually continue
instead of blocking now.
https://bugzilla.gnome.org/show_bug.cgi?id=721289
Also only check the data types for non-IDLE probes. When we
are idle, we have no data type obviously.
Previously we were calling IDLE probes during data flow whenever
a non-blocking probe would be called. The pad was usually not idle
at that time.
Checking twice the lower bound is great (you never know, it might change
between the two calls by someone using emacs butterfly-mode), but it's a bit
more useful to check the higher bound are also identical.
Detected by Coverity
If a category with the same name is found when creating a new
one, the found category is returned instead of an invalid pointer.
Fixes issue with gst-vaapi (which uses an internal copy of the
codec parsers) caused by commit ccba9130.
https://bugzilla.gnome.org/show_bug.cgi?id=720036
Make a new flag on the pad that tweaks the default behaviour of the
accept-caps function. By default it will check for a subset of the
query-caps result but this is not always desirable. The query-caps
result contains all the constraints to make a good caps decision
upstream but sometimes, like for parsers, not all the constrained caps
fields are known upstream and then a subset check would fail. Switching
to an intersection makes this work again.
See https://bugzilla.gnome.org/show_bug.cgi?id=705024https://bugzilla.gnome.org/show_bug.cgi?id=677401
* add many missing declarations to sections
* GstController has been removed, update docs
* skip GstIndex when generating documentation
* rephrase so gtkdoc doesn't imagine return value
* add missing argument description for gst_context_new()
* document GstOutputSelectorPadNegotiationMode and move to header-file
https://bugzilla.gnome.org/show_bug.cgi?id=719614
* fix typo GstBufferFlag -> GstBufferFlags
* fix typo GstFeatures -> GstCapsFeatures
* fix typo GstAllocatorParams -> GstAllocationParams
* fix typo GstContrlSources -> GstControlSource
* do not refer to gstcheck as an object
* make references gtk_init() and tcase_set_timeout() not be references
* gst_element_get_pad() renamed gst_element_get_static_pad()
* gst_clock_id_wait_async_full() renamed gst_clock_id_wait_async()
* _drop_element() is really gst_queue_array_drop_element()
* gst_pad_accept_caps() was removed, do not refer to it
* separate GST_META_TAG_MEMORY_STR declaration from description
* do not describe removed gst_collect_pads_collect()
* correctly link to GstElementClass' virtual set_context()
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=719614
Older versions of flex (before 2.5.36) don't add the prototype, so it must
be added manually. We can't check by the version number, because Debian/Ubuntu
patched it into their 2.5.35 at some point.
This reverts commit 8162a583a4.
Automatically copying the sticky events makes it impossible for apps
and elements to filter the events with event probes. This causes
regressions (See #719437). The best option is to let the app/element
copy and filter the events themselves after the ghostpad target is
set.
Update the sticky events on SRC ghostpads when retargeting. This ensures
that the ghostpad has the exect same sticky events as the target pad. We
don't want to do this for SINK ghostpads, they got the events from
downstream and we don't want to overwrite them with the target pad
events.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=707621
gstutils.c:3659:41: error: format string is not a string literal
[-Werror,-Wformat-nonliteral]
gchar *expanded = g_strdup_vprintf (stream_id, var_args);
https://bugzilla.gnome.org/show_bug.cgi?id=710621
gst_parse_launchv, gst_parse_launchv_full and gst_parse_launch_full
all return floating refs, the same as gst_parse_launch, which just
calls gst_parse_launch_full internally anyway.
Add a unit test assertion to check it's true.
Spotted by nemequ on IRC.
Wrap caps strings so that it can handle serialization and deserialization
of caps inside caps. Otherwise the values from the internal caps are parsed
as if they were from the upper one
https://bugzilla.gnome.org/show_bug.cgi?id=708772
It was unintuitive that GstContext was actually a list of different
contexts. GstContext now is only a type string and a structure to
contain the actual context.
Non-persistent contexts are removed when elements go back
to NULL state, persistent contexts are not. Applications
most likely want to set persistent contexts.
Since the default number of max unused threads in GThreadPool has been
changed from 0 to 2 it needs to be set to 0 to stop all threads or
valgrind will report them as memory leaks.
This makes gst_parse_bin_from_description() return an element instead of
a bin if there's only one element. Also changed gstparse.c to use this,
so gst-launch won't create superfluous bins.
https://bugzilla.gnome.org/show_bug.cgi?id=703405
The current documentation is controverse, while it states that the
returned value is valid only while the query is is valid, which presumes
a 'transfer none' policy. But the tooltip for the 'out' annotation
states the default is 'transfer-full'.
Add the missing 'transfer none' annotations to fix this.
Tweak the documentation slightly to clarify that the estimated-total in
a a Buffering query the total remaining time of a download, not the
total time for the complete download. Also indicate the unit used.
https://bugzilla.gnome.org/show_bug.cgi?id=704934
If all stream-start messages had a group id (for backwards compatibility),
we only consider a stream started if all had the same group id.
In 2.0 we should make the group id mandatory.
All streams that have the same group id are supposed to be played
together, i.e. all streams inside a container file should have the
same group id but different stream ids. The group id should change
each time the stream is started, resulting in different group ids
each time a file is played for example.
This makes sure that no bin misses the clock-lost messages, independent
of the state, and could return an old, non-working clock from
gst_bin_provide_clock_func().
https://bugzilla.gnome.org/show_bug.cgi?id=701997
Fixes compiler warnings such as
gstallocator.c:61:8: error: conflicting types for 'gst_memory_alignment'
../gst/gstallocator.h:52:18: note: previous declaration of 'gst_memory_alignment' was here
Renegotiation and reconfiguration will fail because all queries
and events won't be accepted by the pad if it's flushing. In the
best case this just causes unneeded work and spurious warnings in
the debug logs, in the worst case it causes elements to fail completely.
When appending/prepending tags, avoid re-creating (and copying) lists if we already
have one and instead just append/prepend the GValue to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=702545
Before this patch gst_init would intercept --help, causing for example
cheese's --help to look like this:
[hans@shalem cheese]$ cheese --help
Usage:
cheese [OPTION...] - GStreamer initialization
Help Options:
-h, --help Show help options
--help-all Show all help options
--help-gst Show GStreamer Options
gst_init is the only gfoo_init function which does this.
https://bugzilla.gnome.org/show_bug.cgi?id=702089
API: gst_value_array_append_and_take_value
API: gst_value_list_append_and_take_value
We were already using this internally, this makes it public for code
which frequently appends values which are expensive to copy (like
structures, arrays, caps, ...).
Avoids copies of the values for users. The passed GValue will also
be 0-memset'ed for re-use.
New users can replace this kind of code:
gst_value_*_append_value(mycontainer, &myvalue);
g_value_unset(&myvalue);
by:
gst_value_*_append_and_take_value(mycontainer, &myvalue);
https://bugzilla.gnome.org/show_bug.cgi?id=701632
But do this only for events that are not dropped by flushing,
i.e. do it only for everything except SEGMENT and EOS.
Without this we might drop a CAPS event if flushing happens
at an unfortunate time and nobody is resending the CAPS event.
https://bugzilla.gnome.org/show_bug.cgi?id=700806
If a pad block was triggered from sending a sticky event downstream, it
could happen that the pad block is relinking pads, which then requires
to resend previous sticky events.
Previous patch was inforcing a complete ordering of the sticky events, while
in fact, only STREAM_START, CAPS and SEGMENT events need proper ordering.
See: https://bugzilla.gnome.org/show_bug.cgi?id=688188
We can prevent buggy element from causing other elements to fail or crash
by sorting sticky event at insertion. In this case, we also warn as this
is not supposed to happen.
See: https://bugzilla.gnome.org/show_bug.cgi?id=688188
Fixes abort when the old specifiers are used. Fix up the conversion
specifier, it would get overwritten with 'c' below to the extension
format char, which then later is unhandled, leading to the abort.
Also fix up and enable unit test for this.
https://bugzilla.gnome.org/process_bug.cgi
Source elements with limited bandwidth capabilities and supporting
buffering for downstream elements should set this flag when answering
a scheduling query. This is useful for the on-disk buffering scenario
of uridecodebin to avoid checking the URI protocol against a list of
hardcoded protocols.
Bug 693484
API: GST_PLUGIN_STATIC_DECLARE()
API: GST_PLUGIN_STATIC_REGISTER()
Based on a patch by Håvard Graff <havard.graff@tandberg.com>.
This now allows GST_PLUGIN_DEFINE() to create a static plugin if
GST_PLUGIN_BUILD_STATIC is defined. The resulting plugin can be
statically linked or dynamically linked during compilation but
can't be dynamically loaded during runtime.
Also adds GST_PLUGIN_STATIC_DECLARE() and GST_PLUGIN_STATIC_REGISTER(),
which allows to register a static linked plugin easily.
It is still required to manually register every single statically linked
plugin from inside the application as this can't be automated in a portable
way.
A new configure parameter --enable-static-plugins was added that allows
to build all plugins we build here as static plugins.
Fixes bug #667305.
The gst_plugin_feature_rank_compare_func() should return
negative value, if the rank of both PluginFeatures are equal and
the name of first PluginFeature comes before the second one.
https://bugzilla.gnome.org/show_bug.cgi?id=697990
Don't use snprintf(), but use sprintf instead and do our own
length calculations, because glibc may complain about us passing
%n in a format string if the string is in writable memory, and
here the format string is always in writable memory since we
construct it on the fly. This happens if glibc has been compiled
with _FORTIFY_SOURCE=2, which seems to be the case on some
distros/systems). On the upside, we now use the sprintf code path
on all systems which should be better from a maintenance point
of view.
https://bugzilla.gnome.org/show_bug.cgi?id=697970
Make GST_PLUGIN_DEFINE use G_STRINGIFY() to convert the name argument
into a meaningful string. The advantage of this is that `name' can be
expanded from other macros defined in the plug-in element.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=697872
Don't use just GLIB_HAVE_ALLOCA_H to check if alloca is available,
that's just for the header. GLib may define alloca for us otherwise
too irrespective of GLIB_HAVE_ALLOCA_H.
Fixes compiler warning with mingw32:
gst/printf/vasnprintf.c:73:0: warning: "alloca" redefined
Does not do anything yet. On a sidenote, we can't just use
%p\001 or so to signal the extension because g-i complains
about an invalid ascii character then, so have to resort to
something more elaborate, such as %p\aA etc.
https://bugzilla.gnome.org/show_bug.cgi?id=613081
and remove all the printf extension/specifier stuff for
the system printf. Next we need to add back the custom
specifiers to our own printf implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=613081
We will add support for our own printf modifiers, so we can
get nice debug log output on all operating systems irrespective
of the specific libc version used.
https://bugzilla.gnome.org/show_bug.cgi?id=613081
Iterate over the fields of the superset instead of those of the subset.
This way we can check the presence of the subset field and do the subset check
in one iteration.
Very often, when the end of a segment is detected by demuxer, the position
is slightly outside the segment boundaries. Currently, if that is the case
the base will be set to NONE instead of normal accumulation. This would
break non-flushing seeks in oggdemux and most likely other demuxers.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=696899
This is equal to any other caps features but results in unfixed caps. It
would be used by elements that only look at the buffer metadata or are
currently working in passthrough mode, and as such don't care about any
specific features.
These are meant to specify features in caps that are required
for a specific structure, for example a specific memory type
or meta.
Semantically they could be though of as an extension of the media
type name of the structures and are handled exactly like that.
Elements should override GstElement::set_context() and also call
gst_element_set_context() to keep this context up-to-date with
the very latest context they internally use.
When flushing, it is expected that upstream will send a SEGMENT
event afterwards.
This also avoids stray SEGMENT events from coming through after a
flush.
Unref the allocator *after* we have freed the memory. We also need to keep
a ref to the allocator around because following the now freed memory would
lead to crashes.
This reverts commit 1a1a9e143f.
This breaks the pipelines/tagschecking unit test for some reason
(fakesrc ! capsfilter ! qtmux linking fails now). It might be
a bug in the unit test of course, but someone will need to
investigate this. Reverting for now.
https://bugzilla.gnome.org/show_bug.cgi?id=692508
Only use the allocator of the copied memory when we can use the default
_alloc function on it. Otherwise we will have to use the default
allocator for the copy.
motivation comes from: /* FIXME: why not gst_pad_get_pad_template (pad); */
this code path is quite nicer, we now only revert to creating the template
if gst_pad_get_pad_template fails.
with this fork, we gain a non-allocation of GstCaps *templcaps
https://bugzilla.gnome.org/show_bug.cgi?id=692508
Set operations on the bitmasks don't make much sense and result
in invalid caps when used as a channel-mask. They are now handled
exactly like integers.
This functionality was not used anywhere except for tests.
https://bugzilla.gnome.org/show_bug.cgi?id=691370
gst_bin_query() now forwards the query to the source pads as well if
none of the sinks of the bin satisfied the query. This helps in the
case of DURATION queries done a bin containing a source element.
Fixes bug 638749
Under certain GST_STATE_CHANGED_PAUSED_TO_PLAYING transitions, a pipeline with
a NULL clock will fail an assertion due to an unchecked call to gst_object_ref().
This is fixed by simply adding a check and only ref-ing if the clock is not NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=693065
Add gstenumtypes.h/c for inclusion with g-ir-scanner. This fixes
problems where introspection based bindings think GstState is
typeless due to the GType not being included as an annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=691185
the code ifed a debug statement, that can't be right. anyway, the way it is,
we don't really need that branch, as we set the flag to unset only if set
(and that can't fail) hence the end result is always to unset the flag.
Signed-off-by: Niv Sardi <xaiki@evilgiggle.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=691985
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
Avoid unnecessary value copying, and unnecessary init/unset
cycles which all go through the value table. There's a bunch
of places where we copy a value and then unset it in the next
line, instead of just taking over the source value.
Add a GST_BIN_FLAG_NO_RESYNC that disables a resync when an element is added,
removed or linked in the bin. This is interesting for complex bins that
dynamically add elements to themselves and want to manage the state of those
elements without interference from resyncs.
See https://bugzilla.gnome.org/show_bug.cgi?id=690420
We don't need to link to gthread-2.0 any longer, since all
the normal thread-related stuff is in GLib proper, and we
don't use g_thread_init() any more.
https://bugzilla.gnome.org/show_bug.cgi?id=689043
The function init_pre() in gstreamer/gst/gst.c calls setlocale(LC_ALL, ""),
which sets the locale to the values specified in the environment. This is
wrong for two reasons:
1. It is absolutely not the task of a library to decide on the correct locale
for a program. Some programs change the locale for various (good or bad)
reasons, and libraries should respect that. Programs where GStreamer's
overwriting of the locale causes bugs include Emacs [1, 2], Sublime Text [3],
and Lua [4].
[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12392
[2] http://bugzilla.novell.com/show_bug.cgi?id=779426
[3] http://www.sublimetext.com/forum/viewtopic.php?f=3&t=8543
[4] https://github.com/pavouk/lgi/issues/19
Note that setting the locale can cause problems for programs that are not even
linked against GStreamer. In the case of Emacs, for example, GStreamer seems
to be initialized through GTK via libcanberra.
2. Setting the locale is not thread-safe, and therefore should not be done in a
library.
https://bugzilla.gnome.org/show_bug.cgi?id=685650
