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

[Toshick]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Matthew Waters]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Toshick]

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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Matthew Waters]

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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Toshick]

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Matthew Waters]

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Toshick]

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);

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? 

Best regards,

Anton.

On Tue, Oct 6, 2020 at 2:55 AM Matthew Waters <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[Matthew Waters]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

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

[coreykernel]

Hey Anton,

Did you ever resolve your issue. I'm getting a similar mline error when I
try to send a 2nd offer after adding the new stream:

webrtc_sink = gst_element_get_request_pad(webrtc, "sink_1");
ret = gst_pad_link(q3_src, webrtc_sink);
g_assert_cmphex(ret, ==, GST_PAD_LINK_OK);
promise = gst_promise_new_with_change_func(on_offer_created, NULL, NULL);
g_signal_emit_by_name(G_OBJECT(webrtc), "create-offer", NULL, promise);

The on_offer_created callback is never called and I get an error:

ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)
Bail out!
ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)

Do I need to remove the original stream that I am replacing? Or is it OK to
send two streams to the peer?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Toshick]

Hello,

As for now, as I understand, gstwebrtcbin is not support live reconfiguration. So, I was managed to change streams from one to another but it must have the same format (if initial negotiation was for ex. h264 you can change stream to any h264). 

To any other format, you need to reestablish connection again.

Best regards,

Anton.

On Sat, Jan 9, 2021, 15:00 coreykernel <[hidden email]> wrote:

Hey Anton,

Did you ever resolve your issue. I'm getting a similar mline error when I
try to send a 2nd offer after adding the new stream:

webrtc_sink = gst_element_get_request_pad(webrtc, "sink_1");
ret = gst_pad_link(q3_src, webrtc_sink);
g_assert_cmphex(ret, ==, GST_PAD_LINK_OK);
promise = gst_promise_new_with_change_func(on_offer_created, NULL, NULL);
g_signal_emit_by_name(G_OBJECT(webrtc), "create-offer", NULL, promise);

The on_offer_created callback is never called and I get an error:

ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)
Bail out!
ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)

Do I need to remove the original stream that I am replacing? Or is it OK to
send two streams to the peer?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
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

[Matthew Waters]

webrtcbin currently supports some reconfiguration scenarios.  Format changing (e.g. H264 to VP8) however is not one of those scenarios.

Cheers
-Matt

On 10/1/21 9:31 pm, Anton Pryima wrote:

Hello,

As for now, as I understand, gstwebrtcbin is not support live reconfiguration. So, I was managed to change streams from one to another but it must have the same format (if initial negotiation was for ex. h264 you can change stream to any h264). 

To any other format, you need to reestablish connection again.

Best regards,

Anton.

On Sat, Jan 9, 2021, 15:00 coreykernel <[hidden email]> wrote:

Hey Anton,

Did you ever resolve your issue. I'm getting a similar mline error when I
try to send a 2nd offer after adding the new stream:

webrtc_sink = gst_element_get_request_pad(webrtc, "sink_1");
ret = gst_pad_link(q3_src, webrtc_sink);
g_assert_cmphex(ret, ==, GST_PAD_LINK_OK);
promise = gst_promise_new_with_change_func(on_offer_created, NULL, NULL);
g_signal_emit_by_name(G_OBJECT(webrtc), "create-offer", NULL, promise);

The on_offer_created callback is never called and I get an error:

ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)
Bail out!
ERROR:../ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)

Do I need to remove the original stream that I am replacing? Or is it OK to
send two streams to the peer?



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
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

[coreykernel]

When you changed streams with the same format, what steps did you take?

Did you use the same sink on the webrtcbin? Did you need to trigger an event
on the webrtcbin after you changed the stream? (e.g. "create-offer")



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel