Should element's iterated pads be unref'ed?

[Alexey Chernov]

Hello,

I'm using iteration of element's source pads to block them in my
program the following way:

void block_src_pads(GstElement* element, gboolean block)
{
        GstIterator* it = gst_element_iterate_src_pads(element);
        GstIteratorResult result = GST_ITERATOR_OK;
        while (result == GST_ITERATOR_OK)
        {
                gpointer p;
                result = gst_iterator_next(it, &p);
                GstPad* pad = GST_PAD(p);
                gst_pad_set_blocked (pad, block);
                gst_object_unref(pad);
        }
        gst_iterator_free(it);
}

But I often receive this message in the output:

(<unknown>:6683): GStreamer-CRITICAL **:
Trying to dispose object "src", but it still has a parent "mountpoint".
You need to let the parent manage the object instead of unreffing the
object directly.


(<unknown>:6683): GStreamer-CRITICAL **:
Trying to dispose object "src", but it still has a parent "mountpoint".
You need to let the parent manage the object instead of unreffing the
object directly.

The element "mountpoint" is actually valve element and its pads are
("sink", "src", "src") according to gst_iterate_pads().

What could be the problem? Maybe I should't unref pads after usage?
But in all the code snippets I've seen there's unref for every used
pad.

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Luciana Fujii Pontello-2]

On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:

> What could be the problem? Maybe I should't unref pads after usage?
> But in all the code snippets I've seen there's unref for every used
> pad.

You probably need to check the result of gst_iterator_next right after
you call it. Even if the result is DONE or ERROR you are still using the
pad and unreferring it. Just use the example of GstIterator.

Regards,

Luciana Fujii


------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Alexey Chernov]

On Tuesday 08 February 2011 21:12:27 you wrote:
> On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:
> > What could be the problem? Maybe I should't unref pads after usage?
> > But in all the code snippets I've seen there's unref for every used
> > pad.
>
> You probably need to check the result of gst_iterator_next right after
> you call it. Even if the result is DONE or ERROR you are still using the
> pad and unreferring it. Just use the example of GstIterator.

Thanks, Luciana. I searched for an example code with little success so you
reference is quite helpful. The problem actually went away as I cleaned and
recompiled the application but I'd better find out what the reason was.

Thank you.

>
> Regards,
>
> Luciana Fujii
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Luis de Bethencourt]

On Fri, Feb 11, 2011 at 9:11 PM, Alexey Chernov <[hidden email]> wrote:

> On Tuesday 08 February 2011 21:12:27 you wrote:
>> On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:
>> > What could be the problem? Maybe I should't unref pads after usage?
>> > But in all the code snippets I've seen there's unref for every used
>> > pad.
>>
>> You probably need to check the result of gst_iterator_next right after
>> you call it. Even if the result is DONE or ERROR you are still using the
>> pad and unreferring it. Just use the example of GstIterator.
>
> Thanks, Luciana. I searched for an example code with little success so you
> reference is quite helpful. The problem actually went away as I cleaned and
> recompiled the application but I'd better find out what the reason was.
>
> Thank you.

So what cleans did you make, do you still have the faulty code?
Luciana's suggestion was something you should always do, check the
function was successful before continuing.
In some cases you might need to wait until an async Gst function
finishes before doing anything related.

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

[Alexey Chernov]

On Sunday 13 February 2011 21:38:08 Luis de Bethencourt wrote:

> On Fri, Feb 11, 2011 at 9:11 PM, Alexey Chernov <[hidden email]> wrote:
> > On Tuesday 08 February 2011 21:12:27 you wrote:
> >> On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:
> >> > What could be the problem? Maybe I should't unref pads after usage?
> >> > But in all the code snippets I've seen there's unref for every used
> >> > pad.
> >>
> >> You probably need to check the result of gst_iterator_next right after
> >> you call it. Even if the result is DONE or ERROR you are still using the
> >> pad and unreferring it. Just use the example of GstIterator.
> >
> > Thanks, Luciana. I searched for an example code with little success so
> > you reference is quite helpful. The problem actually went away as I
> > cleaned and recompiled the application but I'd better find out what the
> > reason was.
> >
> > Thank you.
>
> So what cleans did you make, do you still have the faulty code?

No, that time I meant only full rebuild and reinstall of the faulty code and
it used to fix the problem. Now I fixed the code as you and Luciana suggested.

> Luciana's suggestion was something you should always do, check the
> function was successful before continuing.
> In some cases you might need to wait until an async Gst function
> finishes before doing anything related.

How can I implement this? Is it necessary to call _async function to ensure
everything is blocked? The use case is to change pipeline branches dynamically
after start of the playback.

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

[Luis de Bethencourt]

On Mon, Feb 14, 2011 at 8:47 PM, Alexey Chernov <[hidden email]> wrote:

> On Sunday 13 February 2011 21:38:08 Luis de Bethencourt wrote:
>> On Fri, Feb 11, 2011 at 9:11 PM, Alexey Chernov <[hidden email]> wrote:
>> > On Tuesday 08 February 2011 21:12:27 you wrote:
>> >> On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:
>> >> > What could be the problem? Maybe I should't unref pads after usage?
>> >> > But in all the code snippets I've seen there's unref for every used
>> >> > pad.
>> >>
>> >> You probably need to check the result of gst_iterator_next right after
>> >> you call it. Even if the result is DONE or ERROR you are still using the
>> >> pad and unreferring it. Just use the example of GstIterator.
>> >
>> > Thanks, Luciana. I searched for an example code with little success so
>> > you reference is quite helpful. The problem actually went away as I
>> > cleaned and recompiled the application but I'd better find out what the
>> > reason was.
>> >
>> > Thank you.
>>
>> So what cleans did you make, do you still have the faulty code?
>
> No, that time I meant only full rebuild and reinstall of the faulty code and
> it used to fix the problem. Now I fixed the code as you and Luciana suggested.
>
>> Luciana's suggestion was something you should always do, check the
>> function was successful before continuing.
>> In some cases you might need to wait until an async Gst function
>> finishes before doing anything related.
>
> How can I implement this? Is it necessary to call _async function to ensure
> everything is blocked? The use case is to change pipeline branches dynamically
> after start of the playback.
>

I was just stating that it is good style to check for the return.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstIterator.html#gst-iterator-next
In this link you can read about the return values of
gst_iterator_next(): GST_ITERATOR_OK, GST_ITERATOR_DONE,
GST_ITERATOR_RESYNC, GST_ITERATOR_ERROR.
As you can see it makes sense to have your code act acordingly
depending on which return value you get.

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

[Alexey Chernov]

On Tuesday 15 February 2011 13:11:32 Luis de Bethencourt wrote:

> On Mon, Feb 14, 2011 at 8:47 PM, Alexey Chernov <[hidden email]> wrote:
> > On Sunday 13 February 2011 21:38:08 Luis de Bethencourt wrote:
> >> On Fri, Feb 11, 2011 at 9:11 PM, Alexey Chernov <[hidden email]> wrote:
> >> > On Tuesday 08 February 2011 21:12:27 you wrote:
> >> >> On Tue, 2011-02-08 at 15:26 +0300, 4ernov wrote:
> >> >> > What could be the problem? Maybe I should't unref pads after usage?
> >> >> > But in all the code snippets I've seen there's unref for every used
> >> >> > pad.
> >> >>
> >> >> You probably need to check the result of gst_iterator_next right
> >> >> after you call it. Even if the result is DONE or ERROR you are still
> >> >> using the pad and unreferring it. Just use the example of
> >> >> GstIterator.
> >> >
> >> > Thanks, Luciana. I searched for an example code with little success so
> >> > you reference is quite helpful. The problem actually went away as I
> >> > cleaned and recompiled the application but I'd better find out what
> >> > the reason was.
> >> >
> >> > Thank you.
> >>
> >> So what cleans did you make, do you still have the faulty code?
> >
> > No, that time I meant only full rebuild and reinstall of the faulty code
> > and it used to fix the problem. Now I fixed the code as you and Luciana
> > suggested.
> >
> >> Luciana's suggestion was something you should always do, check the
> >> function was successful before continuing.
> >> In some cases you might need to wait until an async Gst function
> >> finishes before doing anything related.
> >
> > How can I implement this? Is it necessary to call _async function to
> > ensure everything is blocked? The use case is to change pipeline
> > branches dynamically after start of the playback.
>
> I was just stating that it is good style to check for the return.
>
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst
> reamer-GstIterator.html#gst-iterator-next In this link you can read about
> the return values of
> gst_iterator_next(): GST_ITERATOR_OK, GST_ITERATOR_DONE,
> GST_ITERATOR_RESYNC, GST_ITERATOR_ERROR.
> As you can see it makes sense to have your code act acordingly
> depending on which return value you get.

Yes, thanks for the reference, so with necessary checks my code must be
correct now. So, the result is like this:

void block_src_pads(GstElement* element, gboolean block)
{
        GstIterator* it = gst_element_iterate_src_pads(element);
        gpointer p;
        while (gst_iterator_next(it, &p) == GST_ITERATOR_OK)
        {
                GstPad* pad = GST_PAD(p);
                gst_pad_set_blocked (pad, block);
                gst_object_unref(pad);
        }
        gst_iterator_free(it);
}

Thanks to all for help.
 
> Luis
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel