Clean up the prepare_output_buffer function.
Reuse the input buffer when it is writable and when doing an
in-place but non-passthrough transform.
Move the copy-metadata function call to the prepare_output_buffer default
function. If subclasses implement a custom prepare_output_buffer, they must also
copy the metadata themselves.
Remove a useless memory copy because prepare_output_buffer already did that.
Place the allocator object in the ALLOCATION query instead of the name. This
allows us to exchange allocators that are not in the global pool of allocators.
Update elements for the new api
Add refcounting to the GstAllocator object.
Remove const from functions because the allocator is refcounted now.
Rename the vmethods for consistency
Expose the constructor for GstAllocator and add a destroy notify for the
user_data. This should make it possible to create allocators that are not
registered and shared globally along with the possibility to destroy them
properly.
Update defs with new symbols.
And only forward the allocation query if we're working in
passthrough mode if no ::propose_allocation is implemented.
In place buffer transformations will change the buffer
content and require explicit handling of all metas.
When _clear gets called between _map and _unmap, buffers
will be unreffed. If the adapter was mapped, memory leaks
may occur.
While calling _clear between _map and _unmap does not seem
like such a great idea, this is possible in the audio
encoder base class, as _clear may be called in _finish_frame.
Since the audio encoder relies on flushing to keep track of
timestamps, delaying flushing till after handle_frame seems
dangerous.
So, we unmap on clear, as the next unmap will do nothing.
This makes _clear safe to call between _map and _unmap,
while avoiding leaking the mapped buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=664133
GstBaseParse was not clearing its adapter on reset causing
problems when a pipeline went for example from PLAYING to NULL
state and then back to PLAYING again. The data from the last
stream would be used in the parser.
https://bugzilla.gnome.org/show_bug.cgi?id=667444
There are many good use cases for GstIndex and we want
to add it back again in some form, but possibly not with
the current API, which is very powerful (maybe too powerful),
but also a bit confusing. At the very least we'd need to
make the API bindings-friendly.
Conflicts:
libs/gst/base/gstbasetransform.c
libs/gst/controller/gstinterpolationcontrolsource.c
libs/gst/controller/gstlfocontrolsource.c
plugins/elements/gstfilesrc.c
Dit not merge controller or basetransform changes.