Subsequent EOS will push on the source pad that already received
EOS and that will make the event function return FALSE. It needs
only to push the first one and only return TRUE for the subsequent
ones.
gst_selector_pad_chain() was popping cached buffers out of the queue without
freeing those. Make sure we don't steal the GstBuffer as the cached buffer ref
has been passed to the pad chain function.
This can be reproduced by running the
validate.file.playback.switch_subtitle_track_while_paused.test5_mkv scenario
with Valgrind.
https://bugzilla.gnome.org/show_bug.cgi?id=747611
Signed-off-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
When determining whether the running_time of a pad can be
calculated, check if the segment is in TIME format instead
of using the 'active' field.
Since the latter is set through *any* activity, it's not a
reliable indicator of segment presence.
https://bugzilla.gnome.org/show_bug.cgi?id=739620
With the disappearance of the 'block' signal, this
flag cannot be set to TRUE.
gst_input_selector_wait disappears as it never waits
and just returns self->flushing.
https://bugzilla.gnome.org/show_bug.cgi?id=736891
This signal blocks the input-selector with no means of unblocking
other than a state change back to READY. It seems this signal was
part of an old way of synchronously switching the selector,
together with the already-removed 'switch' signal.
Removing the signal is safe, as attempting to use it could only
end in deadlocks. Attempting to emit an unknown signal just causes
g_criticals.
https://bugzilla.gnome.org/show_bug.cgi?id=736891
This apparently got broken by bc1ec4e. Since self->blocked is always
FALSE, gst_input_selector_wait never actually waits.
Using (!self->eos || self->blocked) && ... as the loop condition would
be incorrect as well, because then the other call to the function in
_chain would block until EOS, so the functions cannot be merged trivially.
Since blocking is obsolete, gst_input_selector_wait will get removed anyway.
As such, just inline the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=746518
... and only unblock when either a) the pad becomes active and the event
should be forwarded or b) the active pad went EOS itself.
Otherwise it can happen that we switch from a longer track that is not EOS yet
to a shorter track that already is EOS, but the shorter track won't have any
possibility to send its EOS event downstream anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=740949
TRUE is 1, but every other non-zero value is also considered true. Comparing
for equality with TRUE would only consider 1 but not the others.
Also normalize booleans in a few places.
Otherwise it would only be proxied for the active pad which can lead
upstream to use an incompatible caps for the downstream element.
Even if a reconfigure event is sent upstream when the pad is activated, this
will save the caps reconfiguration if it is already using an acceptable caps.
It is already stored inside the GstSegment struct and
was only duplicating information. Also removed some
weird positon if/else that would possibly change the
segment that was going to be pushed downstream
Use gap events to advance the selector's pad position.
This is relevant to keep sync_streams mode working when one of the
streams doesn't have data all the time.
A new active pad might not be notified in some cases, which results
in the current track number not being set in playbin.
The active-pad notification is only sent in the chain and sink_event
functions, and only when the buffer or event that triggered the active
pad selection is from the newly activated pad. So in the other case
the notification will never be sent.
https://bugzilla.gnome.org/show_bug.cgi?id=704691
Otherwise we might get deadlocks caused by lock order inversion:
During the chain function the stream lock is first locked and then the
inputselector lock. During pad release we first locked the inputselector
lock and then deactivating the pad would lock the stream lock.
There's no reason why the inputselector lock should be required while
deactivating and removing the pad, it's only needed before.
https://bugzilla.gnome.org/show_bug.cgi?id=704002
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.
