1 There are a number of different ways of coding a GstSrc. I'll try to
2 outline them and how the function here:
4 1a) Simple push-function based with single output
13 This is the style that all the existing sources use. There is a single
14 output pad, and a _push function that's global to the whole element. The
15 _push function simply constructs buffers and pushes them out the pad.
17 Chained (current implementation):
20 bin src pad1 pad2 plugin
33 ! pad1->chainfunc (pad1->peer)
34 !------------------------------->!
39 !<-------------------------------!
48 Typically this will be the/an entry into the Bin. The Bin's iterate
49 function simply calls the Src's _push function. When the _push function
50 pushes a buffer out it's pad, the chain function of the peer pad is
51 called, presumably causing a push out the other side of that element, and
52 eventually data gets to the other end. The stack unrolls, and the
53 iteration ends for that Src.
55 chained (alternative implementation)
57 bin src pad1 pad2 plugin
67 !------------------------------------------------>!
69 !<------------------------------!
74 !------------------------------>!
77 !<------------------------------------------------!
80 !------------------------------------------------------------------->!
85 !<-------------------------------------------------------------------!
95 Again, the source would generally be an entry into the Bin. A loopfunc
96 will be constructed around it, which will simply loop calling the Src's
97 _push function as in the non-cothreaded case. When the _push function
98 pushes a buffer, it finds a pushfunc attached to the pad, drops the buffer
99 in the pen, and calls the pushfunc provided by the Bin. This causes a
100 switch to the next element, then the next, to the end, at which point a
101 buffer pull will travel back down the chain. The _push function gets
102 context and finishes, at which point the loopfunc wrapper simply calls it
103 again in the next iteration.
105 (current implementation):
108 bin cothread1 src pad1 pad2 cothread2 plugin
109 ! (src) (= pad1->peer) (plugin)
120 ! gst_pad_push (pad1)
122 !--------------------!
126 ----------------------->!
127 ! gst_pad_pull (pad2)
131 ! (get buffer from bufpen)
141 ! gst_pad_pull (pad2)
146 !<-------------------------------------! cothread switch
163 ! gst_pad_push (pad1)
165 !--------------------!
170 ! (get buffer from bufpen)
180 ! gst_pad_pull (pad2)
185 !<-------------------------------------! cothread switch
193 (alternative implementation):
196 bin cothread1 src pad1 pad2 cothread2 plugin
197 ! (src) (= pad1->peer) (plugin)
203 !---------------->! gst_pad_pull
204 !------------------------------------------------>!
206 !<------------------------------!
211 !------------------------------>!
214 !<------------------------------------------------!
217 !--------------------------------------! cothread switch
218 |---------------------->!
219 ! gst_pad_pull (pad2)
223 ! (get buffer from bufpen)
233 ! gst_pad_pull (pad2)
239 !<------------------------------------!
246 -----------------------------------------------------------------------------------------------
247 1b) Simple push-function based with multiple output
251 Similar to the single output variant, except several chains are spawned
252 off, one per push, hanging off whichever pad the buffer is pushed off of.
253 The stack will grow and unwind as many times as buffers are pushed out.
257 Also similar to the single output variant. When the pull winds its way
258 back from the first push, execution returns to the Src's _push function,
259 which simply goes off and pushes out another buffer, causing another
260 series of context switches. Eventually the loopfunc wrapper starts over,
261 round and round we go.
265 -----------------------------------------------------------------------------------------------
266 2) Pull-function based with single output
268 Similar to a regular filter with a chain function associated with each
269 pad, this kind of source doesn't provide a src-wide push function, but
270 does provide pullfuncs for its pad. A pullfunc puts a buffer in the pen
275 As usual, is likely to be an entry into a Bin. The Bin iterate code must
276 explicitely pull a buffer and pass it on to the peer.
281 ---- ok, I'll finish this tomorrow when my brain's working again.... ----