When requesting a pad from a template and it's already linked, this
means it was a static pad. Since we only want to return an *available*
pad, we must return NULL ... but we must also remove the reference
we got from getting that static pad.
The "No need to unref" message (which wasn't true for quite some time)
dates back from the very very very first commit introducing the 0.10
features.
The caller might pass arbitrary data here that caused the error, and
trying to set invalid UTF-8 in a GstStructure causes it to be not set at
all. Later when trying to parse it, the field will not exist and the
return value will point to invalid memory. Prevent this by storing NULL
instead.
Also print a g_warning(), the caller should never ever do this to begin
with.
gstpoll.c: In function 'release_event':
gstpoll.c:239:3: error: suggest parentheses around assignment used as
truth value [-Werror=parentheses]
if (status = WaitForSingleObject (set->wakeup_event, INFINITE)) {
^~
https://bugzilla.gnome.org/show_bug.cgi?id=774108
Fixes xgettext warnings when doing 'make update-po':
gst/parse/grammar.y:217: warning: Empty msgid. It is reserved by GNU gettext:
gettext("") returns the header entry with
meta information, not the empty string.
This flag is to indicate to child elements that they can add and
remove pads at any point in time without re-adding existing ones.
Elements should post before-hand a GST_MESSAGE_STREAM_COLLECTION
https://bugzilla.gnome.org/show_bug.cgi?id=772741
When we get GST_ITERATOR_RESYNC, we need to call gst_iterator_resync()
otherwise we will always get GST_ITERATOR_RESYNC (and that loop would
run forever).
gst/gstprintf unit test would fail on 32-bit x86 with:
gstprintf.c:83:printf_I32_I64:0: 'str' (64-bit x value = b5a6978f) is not equal to '"64-bit x value = f1e2d3c4b5a6978f"'
This reverts commit cfc565e2d8.
The commit was redundant since gst_gen_sources already contains
gstenum_h. We're still investigating why some people are still seeing
a racy build failure.
This forces gstenumtypes.h to be built whenever something uses gst_dep
as a subproject dependency. This is needed since gst/gst.h includes
gstenumtypes.h
Closes https://github.com/mesonbuild/meson/issues/714 which is not
actually a Meson bug.
Earlier we were only using __declspec(dllexport/import) when we were
built with MSVC because when built with MinGW and linking with MinGW we
don't need it (and we get linker errors because of it).
However, when we're built with MinGW and someone wants to link to us
with MSVC, we still need the prototypes to have __declspec(dllimport)
since MSVC cannot do auto-import like GCC can.
https://bugzilla.gnome.org/show_bug.cgi?id=771029
When using seek_simple() in combination with other kinds of seeks, this
becomes problematic. seek_simple() does not reset the stop position to
GST_CLOCK_TIME_NONE but keeps whatever a previous seek did. So for example
when doing a seek_simple() after a rate=-1 seek, we would usually get
assertions that start>stop (and stop being the old stop from the rate=1 seek).
https://bugzilla.gnome.org/show_bug.cgi?id=771104
In many parts of the code we raise streaming error when the flow
goes wrong, and each time we create more or less similare error
message. Also that message does not let the application know what
has actually gone wrong. In the new API we add a "flow-return" detail
field inside the GstMessage so that the application has all the information
if it needs it.
API:
GST_ELEMENT_FLOW_ERROR
https://bugzilla.gnome.org/show_bug.cgi?id=770158
We only use GST_EXPORT consistently when building with MSVC by using the
visual studio definitions files (win32/common/*.def), so always disable
it when building with Autotools and only enable it with Meson when
building with MSVC.
This allows you to use MinGW to link to a GStreamer built with MSVC and
get the correct function prototypes to find functions and variables in
DLLs.
Fixes g-i warning "Gst: Constructor return type mismatch
symbol='gst_element_message_new_details' constructed='Gst.Element'
return='Gst.Structure'".
This is a newly-added function in git that has not been in a stable
release yet, so it's fine to rename it. It's also only used indirectly
via macros.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
This makes gstconfig.h completely arch-independent. Should cover all
compilers that gstreamer is known to build on, and all architectures
that I could find information on. People are encouraged to file bugs if
their platform/arch is missing.
A new event which precedes EOS in situations where we
need downstream to unblock any pads waiting on a stream
before we can send EOS. E.g, decodebin draining a chain
so it can switch pads.
https://bugzilla.gnome.org/show_bug.cgi?id=768995
Redirection messages are already used in fragmented sources and in
uridecodebin, so it makes sense to introduce these as an official message
type.
https://bugzilla.gnome.org/show_bug.cgi?id=631673
In some corner cases, the error 'code' part passed to
GST_ELEMENT_ERROR() is a valid define as well, in which
case it won't survive two levels of macro expansion, but
only one. Fixes:
oss4-sink.c: In function ‘gst_oss4_sink_open’:
error: ‘GST_RESOURCE_ERROR_0x00000002’ undeclared (first use in this function)
GST_ ## domain ## _ERROR_ ## code, __txt, __dbg, __FILE__,
which is from GST_ELEMENT_ERROR(el,RESOURCE,OPEN_WRITE,..)
and OPEN_WRITE happens to be defined to 2 here.
https://bugzilla.gnome.org/show_bug.cgi?id=756806https://bugzilla.gnome.org/show_bug.cgi?id=769117
