mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-11 09:55:36 +00:00
26a69ef7f8
Original commit message from CVS: Code Cleanups Added use cases for the source elements.
66 lines
2.5 KiB
Text
66 lines
2.5 KiB
Text
There are a number of different ways of coding a GstSrc. I'll try to
|
|
outline them and how the function here:
|
|
|
|
1a) Simple push-function based with single output
|
|
|
|
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.
|
|
|
|
Chained:
|
|
|
|
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
|
|
pushes a buffer out it's pad, the chain function of the peer pad is
|
|
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.
|
|
|
|
Cothreaded:
|
|
|
|
Again, the source would generally be an entry into the Bin. A loopfunc
|
|
will be constructed around it, which will simply loop calling the Src's
|
|
_push function as in the non-cothreaded case. When the _push function
|
|
pushes a buffer, it finds a pushfunc attached to the pad, drops the buffer
|
|
in the pen, and calls the pushfunc provided by the Bin. This causes a
|
|
switch to the next element, then the next, to the end, at which point a
|
|
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.
|
|
|
|
|
|
1b) Simple push-function based with multiple output
|
|
|
|
Chained:
|
|
|
|
Similar to the single output variant, except several chains are spawned
|
|
off, one per push, hanging off whichever pad the buffer is pushed off of.
|
|
The stack will grow and unwind as many times as buffers are pushed out.
|
|
|
|
Cothreaded:
|
|
|
|
Also similar to the single output variant. When the pull winds its way
|
|
back from the first push, execution returns to the Src's _push function,
|
|
which simply goes off and pushes out another buffer, causing another
|
|
series of context switches. Eventually the loopfunc wrapper starts over,
|
|
round and round we go.
|
|
|
|
|
|
|
|
2) Pull-function based with single output
|
|
|
|
Similar to a regular filter with a chain function associated with each
|
|
pad, this kind of source doesn't provide a src-wide push function, but
|
|
does provide pullfuncs for its pad. A pullfunc puts a buffer in the pen
|
|
and exits.
|
|
|
|
Chained:
|
|
|
|
As usual, is likely to be an entry into a Bin. The Bin iterate code must
|
|
explicitely pull a buffer and pass it on to the peer.
|
|
|
|
Cothreaded:
|
|
|
|
|
|
---- ok, I'll finish this tomorrow when my brain's working again.... ----
|
|
|