GStreamer-devel

rtspsrc - pad-added signal - correct handling

classic Classic list List threaded Threaded
♦
♦
 3 messages Options
logidelic
Reply | Threaded
Open this post in threaded view
♦
♦
|

rtspsrc - pad-added signal - correct handling

logidelic
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)?

  • 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)?

  • 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?
Thank you!

- Bill

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Nicolas Dufresne-5
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: rtspsrc - pad-added signal - correct handling

Nicolas Dufresne-5


Le lun. 4 nov. 2019 15 h 10, Bill Klein <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Bill Klein
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: 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 <[hidden email]> wrote:


Le lun. 4 nov. 2019 15 h 10, Bill Klein <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Free forum by Nabble Edit this page