added two more cases of eos reasoning

Original commit message from CVS:
added two more cases of eos reasoning
This commit is contained in:
Thomas Vander Stichele 2001-06-13 09:51:27 +00:00
parent 80fdb9475e
commit d3b914ad91

View file

@ -131,3 +131,76 @@ case 4)
case 5)
(--------) (--------) (--------)
! disksrc! ! mad ! !disksink!
! src ----- sink src ---- sink !
(--------) (--------) (--------)
disksrc detects the end of stream. It just sent the last buffer
and sets the srcpad to EOS with gst_pad_eos ().
the eos handler returns false because mad returns false on the
eos request. the parent removes mad as an EOS provider.
mad was responsible for the EOS delay and so it gets added to the bin
as a possible EOS provider.
After mad has sent its last buffer, it performs gst_pad_eos on its
src pad.
the parent already has mad in the list of EOS providers so it does not
get added twice.
mad finally fires the EOS signal. This time, disksink returns false on
the eos request. the parent removes mad as an EOS provider.
disksink was responsible for the EOS delay and gets added to the bin
as a possible EOS provider.
When disksink has written all of it's data and closed the output file,
it fires EOS.
The parent already has disksink in the list of EOS providers so it does
not get added twice.
The parent removes the EOS provider
from its list, and since the list is empty, the parent fires EOS.
case 6)
(--------) (--------) (--------)
!disksrc1! ! mad1 ! ! mixer !
! src ----- sink src ---- sink1 ! (--------)
(--------) (--------) ! ! !disksink!
! src ---- sink !
(--------) (--------) ! ! (--------)
!disksrc2! ! mad2 ! ! !
! src ----- sink src ---- sink2 !
(--------) (--------) (--------)
In this case, we want to make sure the pipeline keeps running after one
of the two sources reaches eos. Suppose in this case that disksrc1 will
reach eos first.
disksrc1 detects the end of stream. It sets eos, mad1 will return false,
and mad1 will be responsible for eos. When mad1 had sent out the last
buffer, it sends out eos.
The mixer intercepts eos and returns false. mad1 is removed from the
eos providers and mixer is added.
(At this point, the mixer might choose to disconnect mad1->src and
mixer->sink1 pads, since it's received eos on mad1->src)
mixer will not send out eos since it hasn't received eos from
mad2->src.
After a while, disksrc2 will detect end of stream, and eos will finally
propagate to mixer. mixer might disconnect mad->src2, and after
realizing all of it's sources have reached eos, it sends out the final
buffer and fires EOS.
At this point, disksink will return false, mixer will be removed as an
eos provider, and disksink will write out it's final buffer and close
the file on disk. At this point, it fires eos, and since it's the last
eos provider, the parent can fire eos.