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.
Conflicts:
plugins/elements/gstqueue2.c
Only one STREAM_START event should be let through, else it will
confuse downstream elements that think a new stream is starting
whereas in fact we are just switching to a different input.
In the future we might want to let them through but with the same
sequence number.
This guarantees a bit more consistency in which input stream will
be selected by default. It would previously be the first pad on which
an event/buffer/query was received ... which was racy and non-predictable.
The buffering-left field in the buffering message should contain a time estimate
in milliseconds about for long the buffering is going to take. We can calculate
this value when we do rate_estimates.
Only consider the queue empty if the minimum thresholds
are not reached and data is at the queue head. Otherwise
we would block forever on serialized queries.
This also makes sending of serialized events, like caps, happen
faster and potentially improves negotiation performance.
Fixes bug #679458.
Postpone the #ifdef to a point after glib.h (via gstfdsink.h) is included
so that the needed defines and header includes can be done correctly,
especially on Visual C++ builds.
https://bugzilla.gnome.org/show_bug.cgi?id=679112
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
If multiple sources are plugged into the funnel and one of the
sources emits an EOS, that event is propogated through the funnel
even though other sources connected to the funnel may still be
pushing data. This patch waits to send an EOS event until the
funnel has received an EOS event on each sinkpad.
Ported from d397ea97 in 0.10 branch.
