When we were seeking the same stack without a logic that gurantees that we actually
saw the seek with the new seqnum set, we could have ended up with an EOS set with
the right seqnum even if it was actually not the case.
Co-Authored by: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Avoiding to take the OBJECT_LOCK when recieving EOS. The computation is
based on the GstEvent.seqnum to make sure that the EOS we receive
corresponds to the right sequence.
In that patch we tweak seqnums so that they are correctly computed
avoiding to depend on all elements to do it properly as it might pretty
much not be the case!
Co-Authored by: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Starting from now we will not claim that we support GnlObject that have
several source pads as this is
1- Not true at all;
2- the design of priorities in the GnlComposition tree does not allow that;
3- Not very useful in most of the cases and it complexifies quite a lot the code
in the composition.
Conflicts:
configure.ac
tests/check/Makefile.am
This causes races when seeking, reverting for now even if we will
probably want to bring something like that back.
This reverts commit 3549e745a8f0de3977b83c60e9b447afaf55d8a0.
