This is now bindings firendly as _new is just a classic c convenience and all
the work is done in a constructor. As a side effect _new never fails.
Fix the tests.
int and int64 ranges can now have an optional step (defaulting to 1).
Members of the range are those values within the min and max bounds
which are a multiple of this step.
https://bugzilla.gnome.org/show_bug.cgi?id=665294
We introduced our own when GLib didn't want to add a GType
for GError. But now that there is one, we can use GLib's
unconditionally and remove our version.
It's reasonable to build from git, but not want to turn all compiler
warnings into fatal errors. For example, GNOME's jhbuild helps people
get newer versions of software than came from their distribution, but
they may not necessarily want to hack on it.
Make the memory object simply manage the data pointer and the maxsize and move
the offset and size handling to common functionality.
Use the READONLY flag to set a readonly lock.
Remove the data and size fields from the unmap method. We need an explicit
resize operation instead of using the unmap function.
Make internal helper lock and unlock functions.
Update unit test and users of the old API.
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.
This has to be handled explicitely by elements to
make sure that they support all the metas passed
in the allocation query.
Metas have to supported explicitely, otherwise the
query will fail. All elements in a chain need to
support a specific meta to allow its usage.
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
