We can have several CAPS event comming at any time and thuse we will
need to rely on elements to handle their seqnum properly as we can not
do a safe guard at our level
Co-Authored by: Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
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
