GStreamer status 0.11

[Wim Taymans]

0.11 status 1-apr-2011
----------------------

Hello fellow hackers,


This is the very first status update of the 0.11 branch, the branch that 
will
eventually lead to the 1.0 release of GStreamer. I would like to send 
out such
a status mail every couple of weeks like we did for the 0.9 series. 
We'll see
how it goes.


Core Changes
------------

One of the first changes since the 0.11 branch was made in december, was to
remove all deprecated symbols that we accumulated. This makes it easier to
focus on only the relevant bits of the API for the next steps. We also
finally use GInitiallyUnowned for the GstObject base class and got rid
of our own FLOATING flag.

The second biggest change was to make the miniobject a simple boxed type
allocated with the slice allocator. Caps could then also be based on 
this new
base type.

A GstBufferPool object got merged to unify the pool handling in various 
objects
such as ximagesink. This object might eventually also be used to 
negotiate the
specifics of memory allocation and data passing but that part is not yet 
done.
For now it's sitting there as a nice helper object for elements.


Buffer Metadata
---------------

In a next step, the buffermeta branches were merged. It took some 
tweaking and
experimenting to find an API that looked reasonable. The end result is 
that it's
now possible to efficiently attach arbitrary extra data to a buffer and have
that extra metadata be taken into account when doing various buffer 
operations.
The api and functionality looks a bit like dynamic interfaces on buffer 
objects.

Some elements like v4lsrc and ximagesink in -base were ported to use the
metadata feature to keep track of resources as a replacement for their 
buffer
subclasses.


Buffer and memory handling
--------------------------

One of the biggest new changes are found in GstBuffer and in how it 
handles the
memory associated with buffers. It started out with an experiment to use the
metadata features to store the buffer memory. It turned out that this 
was not so
easy to use for the many use cases we wanted to solve.

One of the requirements was to merge the GstBufferList group feature 
into the
main GstBuffer object. This means that a GstBuffer should be able to contain
multiple chunks of disjoint memory. This feature is really handy when 
you need
to construct buffers from different chunks (like prepending headers for 
the RTP
cases). Some hardware devices also store the raw video data in multiple 
chunks
of memory (for Y and CrCb planes).

A normal result of this was to make the memory handling as a separate system
from the buffers. This resulted in the GstMemory objects that manages a
piece of memory in a refcounted way. The GstBuffer object then has an 
array of
these memory blocks as the data member.

Interestingly, this makes it much easier to control writability of the 
buffer
metadata and the buffer data. Compared to the GstBufferList, it's also much
easier to automatically deal with the disjoint pieces of memory.

This resulted in GstBufferList to degrade to a simple array of buffers 
that can
be passed as before. The API is now much easier to handle and faster too.

Docs for all of these new things can be found in the usual places. Some 
of the
buffer design still needs to be fleshed out a bit.


Meanwhile, Back At The Ranch
----------------------------

Or, notable activity in the plugins modules. All of the -core and -base 
plugins
and unit test are updated for these new API changes. Some of the API for
libraries needed to be changed to deal with the new memory objects.

For all you crazy shooters out there, now's the time to put the pistol 
back in
the holster and get your hands dirty. Yes, maintainers of -good and -ugly
plugins, it's time to see how it goes with porting your plugins to the 
new 0.11
API. A lot of API changed and it would be good to get some feedback.

It's also a good idea to see how far you can get with improving the 
opengl and
libva plugins. The new metadata and memory handling should make things 
much more
simple and more performant.

What's next
-----------

More -base library improvements to deal with the new API. Similarly, 
GstAdapter
totally doesn't optimize for the different memory chunks in GstBuffer 
and could
use some loving.

Next up will be changes to the events to make them sick to pads. It'll 
also make
it easier to change the way we handle the timing in the pipeline. The 
end goal
would be to make it much easier to dynamically change the pipeline.


Allright, that's it for now. Have a very nice weekend.

Wim