Make it possible to query the supported options of a bufferpool and enable
options. This is a bit more generic than the API to enable metadata. The purpose
is to make it possible to add new custom config options to the configuration of
the bufferpool when supported.
After we allocated a new buffer, call the release_buffer vmethod to put the new
buffer in the pool instead of assuming that the pool uses the default
release_method implementation.
Add a function to retrieve an array of supported metadata apis from the the
bufferpool.
Add functions to configure and query the configured metadata apis in a
bufferpool configuration.
Add an index to gst_buffer_take_memory() so that we can also insert memory at a
certain offset. This is mostly interesting to prepend a header memory block to
the buffer.
Rename the GstMemoryImpl to GstMemoryAllocator because that's really what it is.
Add an alloc vmethod to the allocator members.
Improve registration of allocators.
Add methods to get and set the default allocator
Always use an allocator to allocate memory, use the default allocator when NULL
is passed.
Add user_data to the allocator Info so that we can pass extra info to the
allocator new method.
The most common case is to not specify any flags when doing the allocation. Make
the allocation from a pool with a maximum amount of buffers block by default for
this reason.
Keep a pointer to the bufferpool. Release the buffer to the pool when
finalizing. Make sure the pool sets itself as the pool member of buffers that it
sends out.
Move some methods around.
Make sure we check for config parsing errors.
Increment the outstanding buffers before calling acquire so that we can be sure
that set_active() doesn't free the pool from under us.
Add start/stop methods to allow for bulk allocation of buffers.
Free buffers only when all outstanding buffers returned.
Make things more threadsafe wrt flushing and starting/stopping by
keeping track of start and stop method calls.
Use a lock to protect concurrect execution of set_config and set_active.
Start freeing the buffers when flushing and all buffers are returned to the
pool.
Make a copy of the config to avoid crashing with concurrent access.
Keep track if the buffer is configured and block activation when not configured
yet.
Keep track of outstanding buffers and disallow configuration when not all
buffers are returned to the pool. We need to do this or else we might end up
with wrong buffers in the pool.
Add return value to set_active.
Small cleanups. Fix finalize.
Use a GstStructure to provide the pool with the right configuration. Also
provide some helper methods to configure such a structure.
don't pass the config in alloc_buffer, pool implementation will already have
parsed it during set_config.
Update defs
Original commit message from CVS:
- Removed bufferpool code and move that to gstbuffer.c
- implemented refcounting on GstData
- implemented new buffer code based on Company's work in the EVENTS2 branch
- added boxed types for GstData/GstEvent/GstBuffer/GstBufferPool
- added refcounting to bufferpools and events
- use lockfree allocation for buffers
- simplified the clock, use lockfree allocation
- use GQueue in GstQueue for faster access to the tail element
- update core plugins to the new event API
Original commit message from CVS:
API docs.
revived _buffer_ref_by_count
fast types for scheduler and bin.
error checking on plugin features;
removed some prototypes that were not implemented (gst_pipeline_iterate
comes to mind)
remove gst_pad_event until we know what it's supposed to do.
remove sinesrc, it wasn't compiles anymore, so...
updates to various elements that used the old event API.
Original commit message from CVS:
1. Add more warnings for the gst core only. Various trival fixes
to quiet the warnings.
2. Fix GstBufferCopyFunc prototype.
3. Re-apply the reverted type!=0 assertion in gst_elementfactory_new.
Original commit message from CVS:
The bufferpool api has changed. Check gstbufferpool.h to see the updated
interface.
Also, the default bufferpool implementation has been finished somewhat. Take a
look at speed.c to see an example of its use, when I get the plugins committed.
