gst_buffer_set_qdata() will leak the structure passed to it
when called incorrectly (e.g. on a non-metadata-writable buffer).
This is expected, but we must avoid doing that in valgrind.
Try to avoid floating point maths for each pixel to be blended in
inner loop, and try to avoid the multiplication entirely for the
most common case of the global alpha being 1. Could probably be
refactored a bit more.
extract_alpha and apply_global alpha always return TRUE really,
so just do away with the return value. Convert a g_return_if_fail()
into a g_assert(), since this is only to check internal consistency
and not a guard for public API. Add some locking.
https://bugzilla.gnome.org/show_bug.cgi?id=668483
If we are asked to (un)premultiply,we need to create the new rectangle
with the right flags, so we can find it properly on subsequent cache
lookups (also because it's wrong otherwise).
https://bugzilla.gnome.org/show_bug.cgi?id=668483
We need to copy the pixels before messing with them, not least
because the buffer creation code below assumes it's ok to take
ownership.
Fixes crash caused by double-free.
https://bugzilla.gnome.org/show_bug.cgi?id=668483
Even if watch->messages->length is 0 there may still be some
data from a message that was only written partially at the
previous attempt stored in watch->write_data, so check for
that as well. We don't want to write data into the middle
of another message, which could happen when there wasn't
enough bandwidth.
https://bugzilla.gnome.org/show_bug.cgi?id=669039
... so subclass can also rely upon never being bothered with some NULL buffer
it can't do any interesting with, or with any data before it received
any format configuration (and setup properly).
If we don't get a duration right away, set the pipeline to playing
and sleep a bit, then try again. This is ugly, but the least worst
we can do right now. The alternative would be to make parsers etc.
return some bogus duration estimate even after only having pushed
a single frame, for example.
Fixes discoverer showing 0 durations for some mp3 and aac files
(e.g. soweto-adts.aac).
This is necessary in order to match what the caps strings in
video.h contain for 16-bit rgb formats and also to match how
gst_video_format_parse_caps expects them.
https://bugzilla.gnome.org/show_bug.cgi?id=667681
Fix building of the libgstvideo module on Android by adding the
missing and needed $(DEFAULT_INCLUDES) to CFLAGS for the
androgenizer call on gst-libs/gst/video/Makefile.am
Before this change, building was failing due to gst-plugins-base/
and gst-plugins-base/gst-libs/gst/video being left out of the
include path.
Not that I have ever seen these in practice, but if they
can't happen we may just as well just assign the new tag
list. Merge properly to be on the safe side, and also
avoid a useless tag list copy in the normal case where
there is no tag list yet.