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
passing argument 1 of 'g_mutex_lock' discards 'const' qualifier from pointer target type
passing argument 1 of 'g_mutex_unlock' discards 'const' qualifier from pointer target type
