blob: 74a094449c6902df5858ee7d62410cd3574c253e [file] [log] [blame]
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