mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-10 19:31:12 +00:00
30 lines
1.2 KiB
Text
30 lines
1.2 KiB
Text
Mutability is the property of an object that defines whether or not you
|
|
are allowed to modify it. In the context of GST, that means that if you
|
|
want to mutilate a buffer, say to do an audio effect, you may have to do
|
|
this on a copy of the buffer, if someone else has a reference on it.
|
|
|
|
The simplest sequence of events in a decoder pipeline is as follows:
|
|
|
|
1) create buffer
|
|
2) allocate and fill data region, attach to buffer
|
|
3) pass to next element
|
|
4) decode the data into new buffer, free original buffer
|
|
5) pass to next element
|
|
6) buffer gets copied to output device (sound, video, whatever)
|
|
|
|
Both of these buffers are created from malloc()'d memory, are referenced
|
|
by one and only one element at a time, and are never modified in place.
|
|
They have no special flags, and when ref==0, they're simply free()'d.
|
|
|
|
An optimization in the case of the sound card or video double buffering,
|
|
where the output buffer actually comes from the output device. In that
|
|
case the element will be aware of such things.
|
|
|
|
A more complex example is where the data is teed after being decoded, sent
|
|
to an effects or visualization object.
|
|
|
|
1) create buffer, fill from source
|
|
2) hand to decoder
|
|
3) create new buffer, decode into it, free old buffer
|
|
4) hand to tee
|
|
5) ref++, hand off to
|