For example if downstream wants a new width/height and color format and
there's first a videoscale and then a ffmpegcolorspace. ffmpegcolorspace
could do the color format conversion, but not the width/height and the
other way around.
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
Fixes negotiation taking a ridiculous amount of
time (multiple 10s of seconds on a core2) when
there are duplicate entries in lists.
Could have a negative performance impact on other
scenarios because we now have to iterate the
dest list to avoid duplicates, but we don't
have a lot of lists any more these days, and
they tend to be small anyway. The negatives
are hopefully countered by the positive effects
of reducing the list length early on in the
process. And in any case, it's the right thing
to do.
Based on patch by Andre Moreira Magalhaes.
https://bugzilla.gnome.org/show_bug.cgi?id=684981
Fix race that could cause data corruption when seeking in ring buffer
mode.
In perform_seek_to_offset(), called from the demuxer's pull_range
request, we drop the lock, tell upstream (usually a http source)
to seek to a different offset, then re-acquire the lock before we
do things to the ranges. However, between us sending the seek event
and re-acquiring the lock, the source thread might already have pushed
some data and moved along the range's writing_pos beyond the seek
offset. In that case we don't want to set the writing position back
to the requested seek position, as it would cause data to be written
to the wrong offset in the file or ring buffer.
Reproducible doing seek-emulated fast-forward/backward on 006653.
Elements such as the GstIirEqualizerNBands would so far not store the properties
of their children. Now we also grab the properties of child elements and try to
restore them.
Ensure that when multiple threads try to block a pad, only one of the threads
calls the callback. We do this by checking if the callback was already called.
The previous version unconditionally called the callback and then checked if it
was already called...
Also only call the unblock callback once from the first thread that unblocks.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=679950
This has undergone significant changes in implementation and
design in 0.11, and we're just not going to backport this to
0.10, so let's just remove it again and continue to fix this
up in master/1.0.
when we have a new step event with a -1 amount, make sure that we follow the
regular code path so that the stop_end handler is called as usual. This takes
care of flushing the buffer in case of a flushing step and also posts a step end
message.
See https://bugzilla.gnome.org/show_bug.cgi?id=679378
Without using AC_INCLUDES_DEFAULT explicitly,
certain platforms will complain that the header
was found, but not usable by the compiler.
This happens for instance on Solaris where certain
headers are needed to pull in proper defines.
Also upgrade to newer autoconf syntax and use proper quoting.
https://bugzilla.gnome.org/show_bug.cgi?id=667293
Add option to avoid build binaries. When building for platforms like
android, you might want to not link any "final" binary, mostly because
it requires special link flags or other parts of code that aren't
in the C library.
https://bugzilla.gnome.org/show_bug.cgi?id=677621
Save the value of the pad's got_eos in gst_funnel_release_pad,
before calling gst_element_remove_pad. This is because
gst_element_remove_pad may free the pad.
https://bugzilla.gnome.org/show_bug.cgi?id=678017
Release the object lock before we get the time of the clock because that code
might take other locks.
Fix potential clock refcount error because we released the object lock but
didn't ref the clock.
Context: Latency configuration should not be
messed up because of not-linked pads. In general,
one return FALSE on latency distribution causes
the "overall" pipeline latency configuration to
fail. This shows up as noise in logs (warning).
instead of just checking if the pad template caps would allow the caps.
The actually supported caps can be far more restrictive than the
template caps and only checking for the template caps can cause
incompatible caps to be set on a pad.
Fixes bug #677335.
The core will do this during dataflow already and additionally
does compatibility checks then. Let it be handled by the core
as for every other pad too.
Fixes bug #677335.
