Implement the same behaviour as gst_pad_push_event when pushing sticky events
fails, that is don't fail immediately but fail when data flow resumes and upstream
can aggregate properly.
This fixes segment seeks with decodebin and unlinked audio or video branches.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=687899
In flush-on-eos=true mode any data remaining in the queue is
discarded when an EOS event is received, and the EOS passed
downstream as soon as possible (instead of waiting for all
buffers in the queue to get processed by downstream first).
May or may not be useful in capture/encoding scenarios.
Basetransform should not try to negotiate in passthrough mode but
respect the order of what we return in the transform_caps method.
A typical case is that you specify some specific new caps in the
caps property but also allow the current caps to pass.
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.
