mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-03-13 15:12:58 +00:00
added two more cases of eos reasoning
Original commit message from CVS: added two more cases of eos reasoning
This commit is contained in:
parent
80fdb9475e
commit
d3b914ad91
1 changed files with 73 additions and 0 deletions
|
@ -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.
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue