This avoids ending up with plenty of pending data (since we'll only
try to parse/push one frame from the incoming buffer).
Fixes increasing memory consumption when parsers aren't linked
We reset all the waiting streams, let them push another buffer to
see if they're now active again. This allows faster switching
between streams and prevents deadlocks if downstream does any
waiting too.
Also improve locking a bit, srcresult must be protected by the
multiqueue lock too because it's used/set from random threads.
Otherwise we might block forever because upstream (e.g. multiqueue) is waiting
for the previously active stream to return forever (which is waiting here
in inputselector) before pushing something on the newly selected stream.
Might fix issues with missing symbols for people who install GStreamer
from source and at some point jumped back and forth between git master
and the 0.10.36 release (or 0.10. branch).
Should reproduce 'GStreamer-WARNING **: wrong STREAM_LOCK count 0'
warnings (with make pipelines/seek.torture or pipelines/seek.forever
anyway, since it appears to be racy).
https://bugzilla.gnome.org/show_bug.cgi?id=670846
Previously only the last would be pushed, which would cause
invalid running times downstream. This also fixes the handling
of update newsegment events.
The segment start adjustment code in pull mode should never trigger
anymore because the bisection code earlier would have already made
sure that we're at the desired position.
Also move the gap handling some lines below after sending the currently
configured segments. Otherwise we might fill gaps in a segment that is
not configured downstream yet.
Account for rounding errors in some places, and that two nows are
not always entirely identical, so allow some leeway when comparing
microseconds and seconds. Ran into this too often, esp. when the
system is under load.
lseek() returns the offset if successful, and this is != 0 and
does not indicate an error. And if it does actually fail, don't
return FALSE (0) as an int, but -1. None of these things are
likely to have made a difference, ever. I don't think the offset
seek can ever actually happen, the current file position and the
current offset should always be increased in lock step, unless
there was an error in which case we'd just error out.
... since that is already handled by _update_duration, or should not be done
altogether if the duration is determined by non-estimated means.
Fixes#669502.
