[gst-devel] How to handle the memory allocation after gst_caps_new_simple? How to use gst_caps_unref(caps) about this cases?
bilboed at gmail.com
Mon Feb 16 09:51:58 CET 2009
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.
> 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
'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?
> 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
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
> 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.
> Would you please judge which approach is correct? and why? thanks in
> 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
> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
More information about the gstreamer-devel