webrtc: Padname src_0 is not unique in element webrtcbin0, not adding

Matthew Waters ystreet00 at gmail.com
Tue Oct 6 23:46:43 UTC 2020


On 7/10/20 3:35 am, Anton Pryima wrote:
> Hello Matthew,
>
> Yes, you were right, I was adding pad instead of requesting it. But I
> still not clear about how to do it correctly. 
> Is it the correct way to request the pad?
> GstPadTemplate *templ =
> gst_element_class_get_pad_template(GST_ELEMENT_GET_CLASS(webrtc),
> "sink_%u");
> GstPad *pad = gst_element_request_pad (webrtc, templ, NULL, NULL);

That should work, there's also gst_element_get_request_pad().

> Then, I link this pad with payer, and start my pipeline. But right
> after that, I've got error inside of webrtc element:
> ERROR:../../../../opensource/gstreamer/vendor/gst-build2/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c:2291:sdp_media_from_transceiver:
> assertion failed: (trans->mline == -1 || trans->mline == media_idx)
> Bail out!
> ERROR:../../../../opensource/gstreamer/vendor/gst-build2/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c:2291:sdp_media_from_transceiver:
> assertion failed: (trans->mline == -1 || trans->mline == media_idx)
>
> Did I miss something?

Maybe, it depends on your exact function call flow as to whether that's
expected or not.  You would need to debug.

Cheers
-Matt

> Best regards,
> Anton.
>
> On Tue, Oct 6, 2020 at 2:55 AM Matthew Waters <ystreet00 at gmail.com
> <mailto:ystreet00 at gmail.com>> wrote:
>
>     How are you adding a pad?
>
>     If you're calling gst_element_add_pad() with a newly created pad,
>     that's wrong.  You need to request a sink pad from webrtcbin and
>     link to that.
>
>     On 6/10/20 4:27 am, Anton Pryima wrote:
>>     Hello Matthew.
>>
>>     I've tried to add one more sink pad to webrtcbin at my sending
>>     side. Linked it, but right after that, I have:
>>      */GStreamer-CRITICAL **: 20:16:08.832: chain on pad
>>     sendonly:pad0 but it has no chainfunction/*
>>
>>     Should I just add pad, or do something more?
>>
>>     Best regards,
>>     Anton.
>>
>>     On Sat, Oct 3, 2020 at 2:05 PM Matthew Waters
>>     <ystreet00 at gmail.com <mailto:ystreet00 at gmail.com>> wrote:
>>
>>         Add a new sink pad on the webrtcbin be requesting a new sink
>>         pad, wait for caps to reach the new pad and then perform
>>         another sdp negotiation cycle.
>>
>>         On 3/10/20 6:49 pm, Anton Pryima wrote:
>>>         Hello Matthew, 
>>>
>>>         Thanks for your quick response.
>>>
>>>         What is the best way to achieve this? Add one more
>>>         transceiver at the sending side for the same pipeline? Or I
>>>         need to create another pipeline with the same webrtc sink?
>>>
>>>         Best regards,
>>>         Anton.
>>>
>>>         On Sat, Oct 3, 2020 at 2:16 AM Matthew Waters
>>>         <ystreet00 at gmail.com <mailto:ystreet00 at gmail.com>> wrote:
>>>
>>>             It sounds like you're attempting a renegotiation of the
>>>             stream format for the same mline.  That is currently an
>>>             entirely unsupported reconfiguration scenario :).  For
>>>             now should add a new stream and remove the old stream if
>>>             you want to change formats.
>>>
>>>             Cheers
>>>             -Matt
>>>
>>>             On 3/10/20 4:09 am, Anton Pryima wrote:
>>>>             Hello all.
>>>>
>>>>             I have an issue with the webrtcbin and changing pipes. 
>>>>             My sender is:
>>>>
>>>>             appsrc->parser->payer->webrtcbin
>>>>
>>>>             My receiver is:
>>>>
>>>>             webrtcbin->depayer->parser->decodebin->autovideosink.
>>>>
>>>>             My app source can push 2 kinds of samples: H264 and
>>>>             H265. I start my send/recv pipelines on the H264 codec. 
>>>>             Then, when the pipeline is PLAYING and I have the h265
>>>>             sample, I put a blocking probe and dynamically
>>>>             reconfigure the sending pipe to
>>>>             *appsrc->h265parser->h265payer->webrtcbin*. And
>>>>             everything is fine and my sending pipe continues working.
>>>>             On the receiving side, I've got the signal through the
>>>>             data channel about codec change from the sending side
>>>>             and configure my receiving pipeline
>>>>             to*webrtcbin->h265depay->h265parse->decodebin->autovideosink*.
>>>>             But right after that, I hove:
>>>>              *GStreamer-CRITICAL **: 16:24:34.926: Padname src_0 is
>>>>             not unique in element webrtcbin0, not adding*
>>>>             Error and frames stop flowing through webrtc src_0 pad.
>>>>
>>>>             Can anyone suggest what am I doing wrong and how to
>>>>             resolve this?
>>>>
>>>>             Best regards,
>>>>             Anton.
>>>>
>>>>             _______________________________________________
>>>>             gstreamer-devel mailing list
>>>>             gstreamer-devel at lists.freedesktop.org <mailto: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/20201007/819d1fbd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201007/819d1fbd/attachment-0001.sig>


More information about the gstreamer-devel mailing list