GstMeta buffers

[jpoet]

In the example for creating a new meta info type:

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-allocation-meta.html

It says

> Lastly, you implement a gst_buffer_add_*_meta() that adds the metadata implementation to a buffer and sets the values of the metadata.

And the example just show assigning values to local variables in the structure.  It does not show any memory allocation, so I assume that is not necessary.  In that structure I would like it to hold a c++ class:

struct _VANCMeta {
  GstMeta       meta;
  AncillaryPacket packet;
};

AncillaryPacket would have various methods as well as data.  Will that work, or do I need to use more "base" types in my metadata structure?  There are only a few data elements in there, so just having those elements in the VANCMeta struct would be easy, but it would be nice to have the methods automatically available by whatever reads the metadata.

If I do need to just have 'simple' data types, and one of those types is an array of uint16_t, is there a preferred way of allocating the memory for it?  I assume I would use a GArray rather than a GstBuffer, right?   Or would I just use a basic C style array of uint16_t?

struct _VANCMeta {
  GstMeta       meta;

  // primary data id.
  int data_id;
  // data block number (type 1), or secondary data id (type 2).
  int dbn_sdid;
  // number of words of data.
  int data_count;
  // actual data.
  uint16_t* buf;

};

I would like to understand how the memory is deallocated after the life of the struct is over.  Who is responsible for that deallocation, and how do they know how to deallocate the memory?

Thanks,

John

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jpoet]

I forgot to ask another related question.   When reading Ancillary data embedded in the frame for a Decklink source, there can be multiple VANC packets in a a single frame.  Do I need to combine those into a single GstMeta object, or can I have several _VANCMeta objects attached to a video frame buffer?  If I can have several, do I need to do anything special to maintain serialization, so they are parsed in the correct order?

Thanks,

John

On Thu, Sep 29, 2016 at 4:21 PM John P Poet <[hidden email]> wrote:

In the example for creating a new meta info type:

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-allocation-meta.html

It says

> Lastly, you implement a gst_buffer_add_*_meta() that adds the metadata implementation to a buffer and sets the values of the metadata.

And the example just show assigning values to local variables in the structure.  It does not show any memory allocation, so I assume that is not necessary.  In that structure I would like it to hold a c++ class:

struct _VANCMeta {
  GstMeta       meta;
  AncillaryPacket packet;
};

AncillaryPacket would have various methods as well as data.  Will that work, or do I need to use more "base" types in my metadata structure?  There are only a few data elements in there, so just having those elements in the VANCMeta struct would be easy, but it would be nice to have the methods automatically available by whatever reads the metadata.

If I do need to just have 'simple' data types, and one of those types is an array of uint16_t, is there a preferred way of allocating the memory for it?  I assume I would use a GArray rather than a GstBuffer, right?   Or would I just use a basic C style array of uint16_t?

struct _VANCMeta {
  GstMeta       meta;

  // primary data id.
  int data_id;
  // data block number (type 1), or secondary data id (type 2).
  int dbn_sdid;
  // number of words of data.
  int data_count;
  // actual data.
  uint16_t* buf;

};

I would like to understand how the memory is deallocated after the life of the struct is over.  Who is responsible for that deallocation, and how do they know how to deallocate the memory?

Thanks,

John

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2016-09-29 at 22:21 +0000, John P Poet wrote:

> In the example for creating a new meta info type:
>
> https://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/se
> ction-allocation-meta.html
>
> It says
>
> > Lastly, you implement a gst_buffer_add_*_meta() that adds the
> metadata implementation to a buffer and sets the values of the
> metadata.
>
> And the example just show assigning values to local variables in the
> structure.  It does not show any memory allocation, so I assume that
> is not necessary.  In that structure I would like it to hold a c++
> class:
>
> struct _VANCMeta {
>   GstMeta       meta;
>   AncillaryPacket packet;
> };
>
> AncillaryPacket would have various methods as well as data.  Will
> that work, or do I need to use more "base" types in my metadata
> structure?  There are only a few data elements in there, so just
> having those elements in the VANCMeta struct would be easy, but it
> would be nice to have the methods automatically available by whatever
> reads the metadata.

You can use a C++ class but you will have to store it as a pointer, and
make sure that you call delete on it when the meta is freed.

Storing C++ classes directly in C structs causes memory leaks as their
destructor can't be called.

> If I do need to just have 'simple' data types, and one of those types
> is an array of uint16_t, is there a preferred way of allocating the
> memory for it?  I assume I would use a GArray rather than a
> GstBuffer, right?   Or would I just use a basic C style array of
> uint16_t?

You could use either of those 3 options, whichever is easier to use in
your case.


> I would like to understand how the memory is deallocated after the
> life of the struct is over.  Who is responsible for that
> deallocation, and how do they know how to deallocate the memory?

You're responsible for deallocating everything that you allocated
yourself in the free_function you passed to gst_meta_register().

Also make sure to initialize all your fields in the init_func().

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Thu, 2016-09-29 at 22:26 +0000, John P Poet wrote:
> I forgot to ask another related question.   When reading Ancillary
> data embedded in the frame for a Decklink source, there can be
> multiple VANC packets in a a single frame.  Do I need to combine
> those into a single GstMeta object, or can I have several _VANCMeta
> objects attached to a video frame buffer?  If I can have several, do
> I need to do anything special to maintain serialization, so they are
> parsed in the correct order?

You can add multiple metas of the same type. It's basically like a
linked list, and adding a new one is appending it.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jpoet]

On Fri, Sep 30, 2016 at 1:16 AM Sebastian Dröge <[hidden email]> wrote:

You can use a C++ class but you will have to store it as a pointer, and
make sure that you call delete on it when the meta is freed.

Storing C++ classes directly in C structs causes memory leaks as their
destructor can't be called.

The problem I forgot about with using C++, is there is no direct way to call a C++ method from C.  Can I rename:

 gst-libav/ext/libav/gstavvidenc.c

to
 gst-libav/ext/libav/gstavvidenc.cpp

? 

Assuming the answer is no, means that I need to change my C++ methods to just be C functions.  It is probably time for me to get a better handle on glib (GObject) stuff.  Until I started working on this gstreamer stuff, I had not written straight C in a couple of decades.  Do you happen to know of a good guide to "GObject for C++ programers"?

Thanks,

John

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Mon, 2016-10-03 at 23:15 +0000, John P Poet wrote:

> On Fri, Sep 30, 2016 at 1:16 AM Sebastian Dröge <[hidden email]> wrote:
> > You can use a C++ class but you will have to store it as a pointer, and
> > make sure that you call delete on it when the meta is freed.
> >
> > Storing C++ classes directly in C structs causes memory leaks as their
> > destructor can't be called.
>
>
> The problem I forgot about with using C++, is there is no direct way
> to call a C++ method from C.  Can I rename:
>
>  gst-libav/ext/libav/gstavvidenc.c
> to
>  gst-libav/ext/libav/gstavvidenc.cpp
>
> ?  

What do you want to add there? You *could* rename it of course, but
that's nothing we would ever accept upstream.

> Assuming the answer is no, means that I need to change my C++ methods
> to just be C functions.

That's indeed the preferred way :)

>   It is probably time for me to get a better handle on glib (GObject)
> stuff.  Until I started working on this gstreamer stuff, I had not
> written straight C in a couple of decades.  Do you happen to know of
> a good guide to "GObject for C++ programers"?

The tutorial in the GObject docs is quite good IMHO:
  https://developer.gnome.org/gobject/stable/pt02.html

In my experience, the biggest obstacles for people who (only) know C++
is to accept that writing GObject C code requires writing a lot of
boilerplate code (basically similar to what the C++ compiler does
behind your back), that the compiler does not know about GObject and
thus can't help you much, and that there is only single inheritance but
multiple implementations of interfaces (basically like in Java, C#,
etc)

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel