How to handle the memory allocation after gst_caps_new_simple? How to use gst_caps_unref(caps) about this cases?

[xiupeng xie]

 Hi All, i have one question about

How to handle the memory allocation after gst_caps_new_simple? How to use gst_caps_unref(caps) about this cases?

 

From GstCaps spec, Setting this property takes a reference to the supplied GstCaps object,

I think this comment didn't mention that it will free this object if there is no chance for g_object_unref() being called even under gobject memory framework.

 

For example, let 0x12345678 as the address of new allocated GstCaps object in your bbpack. We consider two approach:

 

1.approach:

GstCaps *caps;

Caps = gst_caps_new_simple(....);  // for example, let 0x12345678 be the address of memory.

g_object_set(G_OBJECT(caps_filter), "caps", Caps // it will be 0x12345678.

gst_caps_unref(caps); // the purpose of caps has finished, since the all detailed parameter  under property "caps" of "caps_filter" has been assigned.

For case1, distinctly we have to call gst_caps_unref() to release?

 

 

2.approach:
don't use local pointer,

g_object_set(G_OBJECT(caps_filter), "caps", gst_caps_new_simple(....), // it will also 0x12345678.

 

In above two cases, 3^rd parameter will always be 0x12345678 during runtime.

g_object_set(,, 0x12345678.)

 

In case 2, How can your codes to notify g_object_set() to call g_object_unref() so that to release this memory?

 

Would you please judge which approach is correct? and why? thanks in advance.

 

Xiupeng.

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Donny Viszneki]

On Sun, Feb 15, 2009 at 8:14 PM, xiupeng xie <[hidden email]> wrote:

> 1.approach:
>
> GstCaps *caps;
>
> Caps = gst_caps_new_simple(....);  // for example, let 0x12345678 be the
> address of memory.
>
> g_object_set(G_OBJECT(caps_filter), "caps", Caps // it will be 0x12345678.
>
> gst_caps_unref(caps); // the purpose of caps has finished, since the all
> detailed parameter  under property "caps" of "caps_filter" has been
> assigned.
>
> For case1, distinctly we have to call gst_caps_unref() to release?

This is how I believe it is done in the documentation, but assuming
that the GstCaps structure never gets modified indirectly in any way,
I cannot think of a reason you can't keep "reusing" it throughout your
application.

> In case 2, How can your codes to notify g_object_set() to call
> g_object_unref() so that to release this memory?

gstreamer code (or any other glib-related code) is responsible for
respective gobject reference counting semantics. When you "give" the
GstCaps (or any gobject instance) to any other piece of code, it is
responsible for incrementing the reference counter so that it will
remain allocated, and then decreasing its reference counter whenever
it is finished using it, so that it may be freed.

If the GstCaps (or any similar gobject in a similar usage scenario)
will remain present throughout your application, you can either leave
it (it will be deallocated when your process exits) or you can
g_object_unref() whenever it is logical to do so (whenever you no
longer need it) and you generally should not worry about whether or
not another piece of code (ie. gstreamer) needs to hold on to a
reference to that gobject instance or not.

The only rule is that you should never decrement the reference count
of a gobject instance before you are finished with it, and always do
so at the moment you are finished with it. If "someone else" is not
finished with it, they will keep a reference to it on their own, and
you don't have to concern yourself with it.

--
http://codebad.com/

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

Hi,

  First of all, don't use yellow... really... reading a mail like that
in the morning makes me want to scoop my eyes out of their sockets !


On Mon, 2009-02-16 at 09:14 +0800, xiupeng xie wrote:
>  Hi All, i have one question about
>
> How to handle the memory allocation after gst_caps_new_simple? How to
> use gst_caps_unref(caps) about this cases?
>  
> From GstCaps spec, Setting this property takes a reference to the
> supplied GstCaps object,

  It's not from the GstCaps spec, it's from the documentation of the
'caps' property of the 'capsfilter' element.

  What it means is that internally capsfilter will increment the
refcount (it takes an extra reference on the caps).

> I think this comment didn't mention that it will free this object if
> there is no chance for g_object_unref() being called even under
> gobject memory framework.
>
>  
>
> For example, let 0x12345678 as the address of new allocated GstCaps
> object in your bbpack. We consider two approach:
>
>  

  I'l comment the refcount of the caps object.

>
> 1.approach:
>
> GstCaps *caps;
>
> Caps = gst_caps_new_simple(....);  // for example, let 0x12345678 be
> the address of memory.

  Newly created caps, refcount == 1.

>
> g_object_set(G_OBJECT(caps_filter), "caps", Caps // it will be
> 0x12345678.

  'capsfilter' takes a reference on the provided caps, refcount == 2.

>
> gst_caps_unref(caps); // the purpose of caps has finished, since the
> all detailed parameter  under property "caps" of "caps_filter" has
> been assigned.

  You have removed a reference (the one you were given because *YOU*
created that caps), refcount == 1.

  At this point you are no longer entitled to use the caps, since you
removed your reference. The only person that has a reference on the caps
is the capsfilter element which will remove its reference when it is no
longer being used.

>
> For case1, distinctly we have to call gst_caps_unref() to release?
>  
>  
>
> 2.approach:
> don't use local pointer,
> g_object_set(G_OBJECT(caps_filter), "caps",
> gst_caps_new_simple(....), // it will also 0x12345678.

  No, you are a leaking a reference here.

  gst_caps_new_simple() create a new caps (refcount == 1).
  When you set the property capsfilter creates a new reference (refcount
== 2).
  When capsfilter is no longer used it will remove its reference
(refcount == 1)...
... and nobody clears the last reference (therefore leaking that caps).

>
>  
>
> In above two cases, 3rd parameter will always be 0x12345678 during
> runtime.
>
> g_object_set(,, 0x12345678.)
>
>  
>
> In case 2, How can your codes to notify g_object_set() to call
> g_object_unref() so that to release this memory?

  Don't use case 2, use the first case.

     Edward

>
>  
> Would you please judge which approach is correct? and why? thanks in
> advance.
>  
> Xiupeng.
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel