| 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 |