gstreamer/docs/design/draft-buffer2.txt

GstBuffer^2
-----------

This draft document describes a possible design for arbitrary per-buffer
metadata.

The proposed changes in this document are not ABI/API compatible with the 0.10
version of GStreamer and should thus only be considered for upcomming unstable
versions.

Buffer metadata typically includes properties that give more information about
the buffer contents. These properties are usually not negotiated and are thus
not inside the caps.

Some examples of metadata:

 - timestamp, duration
 - offset, offset_end
 - interlacing information
 - video alignment, cropping, panning information
 - extra container information such as granulepos, ...
 - extra global buffer properties


Requirements
------------

 - It must be fast
    * allocation, free, low fragmentation
    * access to the metadata fields, preferably not much slower than directly
      accessing a C structure field
 - It must be extensible. Elements should be able to add new arbitrary metadata
   without requiring much effort. Also new metadata fields should not break API
   or ABI.
 - It plays nice with subbuffers. When a subbuffer is created, the various
   buffer metadata should be copied/updated correctly.
 - We should be able to pass metadata in pad_alloc() and get_range() functions
   to specify extra allocation parameters.
 - We should be able to attach statically allocated metadata to a buffer. This
   is for metadata that does not change much.


GstMiniObject
-------------

We make GstMiniObject a simple refcounted C structure and also a GLib boxed
type. The following fields will be in the structure:

struct _GstMiniObject {
  GType type;

  /*< public >*/ /* with COW */
  /* refcounting */
  gint       refcount;
  guint      flags;

  GstMiniObjectCopyFunction copy;
  GstMiniObjectFreeFunction free;
}

We will use the regular GSlice allocator or custom object pooling for allocating
instances of the mini object.

We use the well known refcounting mechanisms to manage the lifetime of the
objects.


GstEvent, GstCaps, GstQuery, GstMessage
---------------------------------------

Have the new GstMiniObject be the first field in these objects. They will probably
also replace the copy and free functions with their own implementations.

Allocation of the objects will use the regular gst_*_new() functions that will
allocate and initialize a parent GstMiniObject of the required size and setting up
the custom functions.


GstBuffer
---------

A GstMiniObject will be the parent instance of the GstBuffer object, which is a
regular C structure.

struct _GstBuffer {
  GstMiniObject          mini_object;

  gsize                  free_size;

  GstCaps               *caps;
  GstBuffer             *parent;

  gpointer _gst_padding[10];
};

The Buffer object will contain a pointer to the parent buffer to allow for subbuffers
as a first class feature of a GstBuffer.

Allocation of the GstBuffer structure will result in the allocation of a memory region
of a customizable size (512 bytes). Only the first sizeof (GstBuffer) bytes of this
region will initially be used. The remaining bytes will be part of the free metadata
region of the buffer. The size of the free region is kept in the free_size field.

Buffers point to a GstCaps structure that contains the caps of the buffer data.


GstBufferMeta
-------------

A GstBufferMeta is a structure as follows:

  struct _GstBufferMeta {
    GstBufferMetaInfo *info;  /* tag and info for the meta item */
    GstBufferMeta     *next;  /* pointer to the next item */
  }

The purpose of the this structure is to serve as a common header for all metadata
information that we can attach to a buffer. Specific metadata, such as timing metadata,
will have this structure as the first field. For example:

  struct _GstBufferMetaTiming {
    GstBufferMeta  meta;        /* common meta header */
 
    GstClockTime   dts;         /* decoding timestamp */
    GstClockTime   pts;         /* presentation timestamp */
    GstClockTime   duration;    /* duration of the data */
    GstClockTime   clock_rate;  /* clock rate for the above values */
  };

Or another example for the buffer memory region

  struct _GstBufferMetaMemory {
    GstBufferMeta      meta;
   
    /* pointer to data and its size */
    guint8            *data;
    guint              size;
    guint8            *malloc_data;
    GFreeFunc          data_free;
    gpointer           data_user;
  };

GstBufferMetaInfo will point to more information about the metadata and looks like this:

  struct _GstBufferMetaInfo {
    GQuark                     tag;       /* tag name */
    gsize                      size;      /* size of the structure */

    GstMetaInitFunction        init_func;
    GstMetaFreeFunction        free_func;
    GstMetaCopyFunction        copy_func;
    GstMetaSubFunction         sub_func;
    GstMetaSerializeFunction   serialize_func
    GstMetaDeserializeFunction deserialize_func
    GstMetaConvFunction        conv_func;
  }

Tag will contain a GQuark of the metadata name. We will be able to refer to specific
metadata by name or by its (cached) GQuark.  A repository of registered MetaInfo
will be maintained by the core. We will register some common metadata structures
in core and some media specific info for audio/video/text in -base. Plugins can
register additional custom metadata.

Along with the metadata description we will have functions to initialize/free (and/or refcount)
a specific GstBufferMeta instance. We also have the possibility to add a custom subbuffer
function that can be used to modify the metadata when a subbuffer is taken.

We also add serialize and deserialize function for the metadata in case we need special
logic for reading and writing the metadata. This is needed for GDP payloading of the
metadata.

We add a conv function to the Info structure that will be called when a buffer
should be converted to an old-style buffer for backward compatibility.

The purpose of the separate MetaInfo is to not have to carry the free/init functions in
each buffer instance but to define them globally. We still want quick access to the info
so we need to make the buffer metadata point to the info.

Technically we could also specify the field and types in the MetaInfo and
provide a generic API to retrieve the metadata fields without the need for a
header file. We will not do this yet.
 
The complete buffer with metadata would then look as follows:

                         +-------------------------------------+
GstMiniObject            |     GType (GstBuffer)               |
                         |     refcount, flags, copy/free      |
                         +-------------------------------------+
GstBuffer                |     caps, parent, subfunc           |
                         +.....................................+
                      +- |     info                           ------> GstBufferMetaInfo
GstBufferMetaTiming   |  |     next                           ---+
                      |  |                                     | |
                      |  |     dts                             | |
                      |  |     pts                             | |
                      |  |     duration                        | |
                      +- |     clock_rate                      | |
                         + . . . . . . . . . . . . . . . . . . + |
                      +- |     info                           <--+ -> GstBufferMetaInfo
GstBufferMetaMemory   |  |     next                           ---+
                      |  |                                     | |
                      |  |     data                            | |
                      |  |     size                            | |
                      |  |     mallocdata                      | |
                      |  |     data_free                       | |
                      +- |     data_user                       | |
                         + . . . . . . . . . . . . . . . . . . + .
                         .                                       .

API examples
------------

Buffers are created using the normal gst_buffer_new functions. The standard fields
are initialized as usual. A memory area that is bigger than the structure size
is allocated for the buffer metadata. The remaining free area is stored in the
free_size field.

  gst_buffer_new ();

After creating a buffer, the application can set caps. and add other metadata
information. 

In order to modify metadata, a reference to the MetaInfo should be obtained.
This can be done like this:

  GstBufferMetaInfo *info;

  info = gst_buffer_meta_get_info (GQuark tag);

Usually the info will be obtained only once in order to avoid lock contention on
the global pool of meta info. The core will also provide convenience functions
for the core metainfo.

Once a reference to the info has been obtained, the associated metadata can be
added or modified on a buffer.

For example, to modify the timing info on a buffer, one could use the following
sequence:

  GstBufferMetaInfo *info;
  GstBufferMetaTiming *timing;

  info = gst_buffer_meta_get_info (GST_META_TIMING_QUARK);
  
  timing = gst_buffer_get_meta (buffer, info, TRUE); /* TRUE = create if absent */
  timing->timestamp = 0;
  timing->duration = 20 * GST_MSECOND;

The _get_meta() function returns a pointer to the metadata structure associated
with the GST_META_TIMING_QUARK info.

For the core meta info, we will provide convenience code that uses the cached
GstBufferMetaInfo, making the above code a little more simple.

  GstBufferMetaTiming *timing;

  timing = gst_buffer_get_meta_timing (buffer, TRUE); /* TRUE = create if absent */
  timing->timestamp = 0;
  timing->duration = 20 * GST_MSECOND;
 
Note that for each of the metadata that we will add to buffers, we need a struct
definition and a registered MetaInfo. 


We will also provide an API to iterate the different metainfo structures. A
possible simple API would look like this:

 GstBufferMeta *current = NULL;

 /* passing NULL gives the first entry */ 
 current = gst_buffer_meta_get_next (buffer, current);

 /* passing a GstBufferMeta returns the next */
 current = gst_buffer_meta_get_next (buffer, current);



Memory management
-----------------

* allocation

  We will initially allocate a reasonable sized GstBuffer structure (say 512
  bytes) and we will set the free_size to the maximum amount of metadata we can
  store.

  Since the complete buffer structure, including a large area for metadata, is
  allocated in one go, we can reduce the number of memory allocations while still
  providing dynamic metadata.

  When adding metadata, we need to call the init function of the associated
  metadata info structure. Since adding the metadata requires the caller to pass
  a handle to the info, this operation does not require table lookups.

  Per-metadata memory initialisation is needed because not all metadata is
  initialized in the same way. We need to, for example, set the timestamps to
  NONE in the MetaTiming structures.

  The init/free functions can also be used to implement refcounting for a metadata
  structure. This can be useful when a structure is shared between buffers.

  When the free_size of the GstBuffer is exhausted, we will allocate new memory
  for each newly added BufferMeta and use the next pointers to point to this. It
  is expected that this does not occur often and we might be able to optimize
  this transparently in the future.

* free

  When a GstBuffer is freed, we potentially might have to call a custom free
  function on the metadata info. In the case of the Memory metadata, we need to
  call the associated free function to free the memory.
  
  When freeing a GstBuffer, the custom buffer free function will iterate all of
  the metadata in the buffer and call the associated free functions in the
  MetaInfo associated with the entries. Usually, this function will be NULL.


Subbuffers
----------

Subbuffers are a first class feature of the GstBuffer. 

Creating a subbuffer from a GstBuffer will allocate a new GstBuffer and ref the
parent buffer. It will then iterate all of the metadata entries for the parent
buffer and call the associated sub_func in the MetaInfo.

This allows each metadata structure to implement the actions needed to update
the metadata of the subbuffer. 

A pointer to the old and new memory location of the metadata is passed to the
sub_func. The default implementation will simply copy the metadata. Custom
implementations can adjust the values. For example, when making a subbuffer, the
timing metadata needs to be reset to NONE when the start offset is different.


Serialization
-------------

When buffer should be sent over the wire or be serialized in GDP, we need a way
to perform custom serialization and deserialization on the metadata.

For this we add the serialize and deserialize functions to the metadata info.
Possible use cases are to make sure we write out the fields with a specific size
and endianness.


Transformations
---------------

After certain transformations, the metadata on a buffer might not be relevant
anymore.

Consider, for example, metadata that lists certain regions of interest
on the video data. If the video is scaled or rotated, the coordinates might not
make sense anymore. A transform element should be able to adjust or remove the
associated metadata when it becomes invalid. 

We can make the transform element aware of the metadata so that it can adjust or
remove in an intelligent way. Since we allow arbitrary metadata, we can't do
this for all metadata and thus we need some other way.

One proposition is to tag the metadata type with keywords that specify what it
functionally refers too. We could, for example, tag the metadata for the regions
of interest with a tag that notes that the metadata refers to absolute pixel
positions. A transform could then know that the metadata is not valid anymore
when the position of the pixels changed (due to rotation, flipping, scaling and
so on).


Other use cases
---------------

Making the GstBufferMetaMemory (for making the buffer point to the associated
memory region) as metadata on a GstBuffer, as opposed to making it an integral
part of GstBuffer, allows for some more interesting ways to transfer data.

We could for example make a new GstBufferMetaIOVec metadata structure like this:

  struct _GstBufferMetaIOVec {
    GstBufferMeta  meta;
   
    /* pointer to data and its size */
    GFreeFunc       data_free;
    gpointer        data_user;
    guint           len;
    struct iovec   *iov;
  };

This would allow us to transfer data in a scatter/gather array. Since the fields
in the buffer metadata are now explicit, elements that don't support this kind
of metadata can gracefully degrade.

Another use case for not having the Memory metadata in the buffers would be for
_pad_alloc() and get_range(). We can pass a GstBuffer with the requested
metadata fields to those functions and have the _get_range() or pad_alloc()
implementations add (or use, in the case of a file reader) the memory metadata. 


Relationship with GstCaps
-------------------------

The difference between GstCaps, used in negotiation, and the metadata is not
clearly defined. 

We would like to think of the GstCaps containing the information needed to
functionally negotiate the format between two elements. The Metadata should then
only contain variables that can change between each buffer.

For example, for video we would have width/height/framerate in the caps but then
have the more technical details, such as stride, data pointers, pan/crop/zoom
etc in the metadata.

A scheme like this would still allow us to functionally specify the desired
video resolution while the implementation details would be inside the metadata.


Compatibility
-------------

We need to make sure that elements exchange metadata that they both understand,
This is particulary important when the metadata describes the data layout in
memory (such as strides).

Currently the only way to communicate buffer formats between elements is by
using caps. We would like to use the caps system to negotiate the metadata that
will be put on buffers.

We would like to add to the caps on the buffer (and pad) an array of metadata
structures (as strings) that is on the buffer. This way, an element can
quickly know what metadata to look for.

In order to remain compatibility with older plugins we need to convert buffers
that use metadata to specify a non-standard data layout to the old format. We
need to do this before handing buffers to old elements. We will require elements
that are metadata aware to set a flag on their pads; any buffer passed on that
pad will be converted to the old layout when the flag is not set.


Notes:
------

Some structures that we need to be able to add to buffers.

  Clean Aperture
  Arbitrary Matrix Transform
  Aspect ratio
  Pan/crop/zoom
  Video strides

Some of these overlap, we need to find a minimal set of metadata structures that
allows us to define all use cases.