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.
