rtspsrc - pad-added signal - correct handling

[Bill Klein]

Nicolas,

> > Sometimes gst_pad_link returns GST_PAD_LINK_NOFORMAT. Is that
expected/normal? Do I need to perform additional handling in that case (ex
unrefing the element)?

> Means the link failed. There was not matching formats on these pads. You
are doing something incorrect. Trace the caps on both ends to debug.

>> Sometimes gst_pad_link returns GST_PAD_LINK_WAS_LINKED. Is that
expected/normal? Do I need to perform additional handling in that case (ex
unrefing the element)?

> You are trying to link twice a pad, this is a programming error. If you
need to relink, the make sure to unlink first.

Keep in mind that this is just an rtspsrc pipeline where I am listening on
the pad-added signal to handle the dynamic linking... If I tried to link to
the same pad twice, it was only because the pad-added signal was called
twice using the same pad (I've confirmed that this is in fact the case).
Wouldn't that indicate a but in rtspsrc (or, more likely, rtp manager and
its friends)? Or is there something I'm not understanding?

Appreciate the response. I will trace the caps as you suggest, but I'm
unsure what I could be doing differently here, as my example is pretty
simple...

Thanks much!

- Bill


On Mon, Nov 4, 2019 at 10:24 AM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

>
>
> Le lun. 4 nov. 2019 15 h 10, Bill Klein <bill at orbit.org> a écrit :
>
>> I am using a pipeline with an rtsp src in C code. Everything has been
>> working mostly wonderfully, but recent issues have led me to believe that I
>> am doing something wrong in certain situations. Specifically, I am
>> wondering if I am handling the *pad-added* signal correctly.
>>
>> My pad-added handler is something simple like (simplified for the sake of
>> readability):
>>
>> void on_pad_added(GstElement* element, GstPad* pad, void *data) {
>>     GstPad* sinkpad = gst_element_get_static_pad(depay_el, "sink");
>>     if(!sinkpad) ... // handle error
>>
>>     auto r = gst_pad_link(pad, sinkpad);
>>
>>     auto padnm = gst_pad_get_name(pad);
>>     log("on_pad_added - "+padnm+" result:"+getPadLinkRespStr(rs));
>>     // free paddnm...
>>
>>     gst_object_unref(sinkpad);
>> }
>>
>>
>> A few questions about this:
>>
>>    - Is the above correct/sufficient?
>>
>>    - Sometimes gst_pad_link returns GST_PAD_LINK_NOFORMAT. Is that
>>    expected/normal? Do I need to perform additional handling in that case (ex
>>    unrefing the element)?
>>
>>
> Means the link failed. There was not matching formats on these pads. You
> are doing something incorrect. Trace the caps on both ends to debug.
>
>
>>    -
>>    - Sometimes gst_pad_link returns GST_PAD_LINK_WAS_LINKED. Is that
>>    expected/normal? Do I need to perform additional handling in that case (ex
>>    unrefing the element)?
>>
>> You are trying to link twice a pad, this is a programming error. If you
> need to relink, the make sure to unlink first.
>
>>
>>    -
>>    - For some networks/rtsp cameras, I see only a few pad-added signals
>>    called. In others, I see 100s (recv_rtp_src_***). Is that normal?
>>
>> Most cameras will expose two streams, audio and video. This seems rather
> strange to see so many pads, would need more data.
>
> Thank you!
>>
>> - Bill
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191104/42668237/attachment.html>