Send FLUSH_STOP right after forwarding the seek event upstream if necessary.
This makes sure that adder->srcpad is not left flushing if seeking fails or if
upstream is blocked.
The same fix was already applied to videomixer in 49b2a946.
Adder was using always incrementing timestamps. Seeking was done by setting the
position in the newsegment event. This was failing when doing segmented seeks
with rate<0.0, as offset (and thus timestamp) would go below 0.
Now we take both cur and end from the seek event. We construct newsegment events
depending including cur and end from the seek event. We set position to the
start of the segment. Timestamp is set to start or end of segment depending on
rate. Offset is recalculated.
Decrement sample counter when playing backwards. Set proper segment when playing
backwards (0..cur instead or cur..-1). Add more logging and fix a format string.
Detect EOS faster.
Try to reuse one of the input buffer as the output buffer. This usually works
and avoids an allocation and a memcpy.
Be smarter with GAP buffers so that they don't get mixed or cleared at all. Also
try to use a GAP buffer as the output buffer when all input buffers are GAP
buffers.
There's not much point in using GST_DEBUG_FUNCPTR with GObject
virtual functions such as get_property, set_propery, finalize and
dispose, since they'll never be used by anyone anyway. Saves a
few bytes and possibly a sixteenth of a polar bear.
Also use the capsfilter if there is no src-peer as the caps constrain what
we can do. Don't create any_caps as a default, as we check for NULL to skip the
filtering. This is a (small) performance regression as we always intersect
otherwise.
Adder can only handle one common format accross the pads. Thus one needed to add
a capsfilter afterwards and manage the caps. Now one can simply set the caps on
the property.
This ensures that collectpads' cookie is properly updated so that when the streaming
threads will restart and be checking for the flushing status of all pads there will
be no inconsistent state.
When a seek failed upstream, make sure the adder sinkpad is set unflushing again
so that streaming can continue.
We only have a pending segment when we flushed.
Set the flush_stop_pending flag inside the appropriate locks and before we
attempt to perform the upstream seek.
Add some more comments.
Use the right lock to protect the flags in flush_stop.
See #585708
At least do the fix to sent the flush_stop when seeking failed to ensure we
keep no pads flushing. before it was send when the seeking worked which is just
plain wrong and was not the intention.
When no flush-stop has been sent by upstream, we have to send one ourselves to
continue playback. Do this as soon as the collect function is called instead of
after we possibly pushed segment events (that got then flushed out)
Adder was relying that something else sends a flush stop. When using adder with
a livesource it was not getting a flush_stop and thus all pads downstream where
keept flushing. Mark a pending flush_stop and send it when we are working on
the new segment back in the streaming thread.
