Added asci art control flow diagrams

Original commit message from CVS:
Added asci art control flow diagrams
This commit is contained in:
Wim Taymans 2000-11-25 16:00:39 +00:00
parent 26a69ef7f8
commit d8e23920eb

View file

@ -3,11 +3,47 @@ outline them and how the function here:
1a) Simple push-function based with single output
*------* *------
! ! !
! src !--->--! plugin
! ! !
*------* *------
This is the style that all the existing sources use. There is a single
output pad, and a _push function that's global to the whole element. The
_push function simple constructs buffer and pushes them out the pad.
_push function simply constructs buffers and pushes them out the pad.
Chained:
Chained (current implementation):
bin src pad1 pad2 plugin
! (= pad1->peer)
gst_bin_iterate
!
! (find entry)
!
! gst_src_push
!---------------->!
! (create buffer)
!
! gst_pad_push
!---------------->!
!
! gst_pad_chain (pad1->peer)
!------------------------------->!
! !
: :
(more chaining)
: :
!<-------------------------------!
!<----------------!
!<-----------------!
!
iteration ends
!
---
-
Typically this will be the/an entry into the Bin. The Bin's iterate
function simply calls the Src's _push function. When the _push function
@ -16,6 +52,44 @@ called, presumably causing a push out the other side of that element, and
eventually data gets to the other end. The stack unrolls, and the
iteration ends for that Src.
chained (alternative implementation)
bin src pad1 pad2 plugin
! (= pad1->peer)
gst_bin_iterate
!
! (find entry)
!
! (find src pad
! of entry element)
!
! gst_pad_pull
!------------------------------------------------>!
? !
!<------------------------------!
!
! (create buffer)
!
! gst_pad_push
!------------------------------>!
! (bufpen filled)
(return buffer) !
!<------------------------------------------------!
!
! gst_pad_chain
!------------------------------------------------------------------->!
!
:
(more chaining)
:
!<-------------------------------------------------------------------!
!
iteration ends
!
---
-
Cothreaded:
Again, the source would generally be an entry into the Bin. A loopfunc
@ -28,7 +102,95 @@ buffer pull will travel back down the chain. The _push function gets
context and finishes, at which point the loopfunc wrapper simply calls it
again in the next iteration.
(current implementation):
bin cothread1 src pad1 pad2 cothread2 plugin
! (src) (= pad1->peer) (plugin)
gst_bin_iterate
!
! (first entry)
!
! cothread_switch
!---------------->!
! gst_src_push
!---------------->!
! (create buffer)
!
! gst_pad_push (pad1)
!
!--------------------!
! (fill bufpen)
!
! cothread switch
----------------------->!
! gst_pad_pull (pad2)
!
!<----------!
!
! (get buffer from bufpen)
!
!---------->!
! pad2->chainfunc
!------------->!
!
:
:
!<-------------!
! gst_pad_pull (pad2)
!<----------!
!
! (bufpen empty)
!<----------!
!<-------------------------------------! cothread switch
!<----------------!
!
iteration ends
!
:
:
!
next iteration
!
! cothread_switch
!---------------->!
! gst_src_push
!---------------->!
! (create buffer)
!
! gst_pad_push (pad1)
!
!--------------------!
! (fill bufpen)
!
! cothread switch
!---------->!
! (get buffer from bufpen)
!
!---------->!
! pad2->chainfunc
!------------->!
!
:
:
!<-------------!
! gst_pad_pull (pad2)
!<----------!
!
! (bufpen empty)
!<----------!
!<-------------------------------------! cothread switch
!<----------------!
!
iteration ends
!
:
-----------------------------------------------------------------------------------------------
1b) Simple push-function based with multiple output
Chained:
@ -47,6 +209,7 @@ round and round we go.
-----------------------------------------------------------------------------------------------
2) Pull-function based with single output
Similar to a regular filter with a chain function associated with each