<div dir="ltr">Hi Olivier,<div><br></div><div>I have some follow up questions regarding your advice.</div><div><br></div><div>I've tried creating GstWebRTCICEStream objects ahead of time and using them when gst_webrtc_ice_add_stream() was called. But when I tried to use these pre-created GstWebRTCICEStream objects to gather ICE candidates, I couldn't gather any reflexive candidates without gst_webrtc_ice_add_stream() being called. According to Libnice logs, component_io_cb() was not triggered until then.</div><div><br></div><div>I suspected it was because nicesrc element was not created thus component_io_cb() was not triggered. So I tried pre-creating TransportStream objects instead of GstWebRTCICEStream objects. And this time, reflexive candidates could be pre-gathered before gst_webrtc_ice_add_stream() being called. But I'm not sure if this is the correct direction to go, as we would need to properly configure the pre-created TransportStream objects so they could be used later (such as in _get_or_create_data_channel_transports() and _get_or_create_rtp_transport_channel()). Or maybe the original GstWebRTCICEStream approach would work and I just missed something. Any suggestions?</div><div><br></div><div>Also, I'm a bit confused about your suggestions with the freezing/unfreezing candidates. When I read the <a href="https://datatracker.ietf.org/doc/html/rfc5245#section-2.4">RFC for frozen candidates</a>, my understanding is frozen candidates is a mechanism for candidate pairs, not for individual candidates. In our scenarios, ice candidate pooling is only used before SDP negotiation happens, which means there won't be any remote candidates at the point and no candidate pairs are created yet. Could you elaborate more on how the freezing/unfreezing candidates fit in the picture here?</div><div><br></div><div>Thanks a lot!</div><div>Sherrill</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 May 2021 at 16:01, Sherrill Lam <<a href="mailto:sherrill.lam@gmail.com">sherrill.lam@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Olivier and Mathieu,<div><br></div><div>Thanks a lot for your reply! When I think more more on it, I think Olivier is right that the implementation is more a webrtc level issue. I'm going to start from pre-allocating streams and caching ice candidates, and see how it goes.</div><div><br></div><div>Thanks again for your great suggestions!</div><div><br></div><div>Regards,</div><div>Sherrill</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 3 May 2021 at 15:54, Olivier Crête via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div>Hi,</div><div><br></div><div>Giving this a bit more though, I guess one could create those unallocated streams hidden inside libnice and expose them when nice_agent_add_stream() is called, but it's a bit trickier as that means forcing eveyr stream to have the same number of components, which isn't standard in ICE (but it's always true for webrtc as rtcp-mux is mandated now).</div><div><br></div><div>Olivier</div><div><br></div><div>On Mon, 2021-05-03 at 15:42 -0400, Olivier Crête via gstreamer-devel wrote:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div>Hi,</div><div><br></div><div>With my libnice maintainer hat on, it's definitely something I would accept.</div><div><br></div><div>The tricky part is the implementation. At first, I though we'd want to create a new object separate from the ICE agent to do the gathering, but it gets quite tricky quickly as the gathering and especially TURN code is quite tied to the ICE agent code.</div><div><br></div><div>And looking at the spec, I think the implementation is mostly a webrtc level issue. All that you need to do is to add a new API to GstWebRTCICE to create GstWebRTCICEStream objects ahead of time and "cache" them, then when gst_webrtc_ice_add_stream() is called, you can just return one of the pre-allocated streams. The only issue is that we need to add an API to libnice to mark a stream "unallocated" so that it gets ignored when doing the freezing/unfreezing dance, and the same thing needs to happen inside webrtcbin so they get ignored when trying to compute the overall agent state.</div><div><br></div><div>Olivier</div><div><br></div><div><br></div><div>On Mon, 2021-05-03 at 21:21 +0200, Mathieu Duponchelle via gstreamer-devel wrote:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div> Hey, this seems interesting, perhaps open an issue in libnice's gitlab to discuss this?<br> <br></div><div>On 5/2/21 5:29 AM, Sherrill Lam via gstreamer-devel wrote:<br></div><div> <br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div> </div><div dir="ltr">Hi there!<br> <br> My team is interested to implement a prefetch ice candidate pool and add an ice-candidate-pool-size property ( [rtc spec](<a href="https://www.w3.org/TR/webrtc/#dom-rtcconfiguration-icecandidatepoolsize" target="_blank">https://www.w3.org/TR/webrtc/#dom-rtcconfiguration-icecandidatepoolsize</a>) ) for webrtcbin element. We think it will help accelerate the SDP generation at startup process. We’d like to get more guidance on what would be the best way to do it.<br> <br> Although ice candidate pool is a webrtc concept, I think it might make more sense if the pool itself is implemented within NiceAgent in Libnice. We could add an API in Libnice to create such a pool with a specified pool size and start generating ice candidates. When nice_agent_gather_candidates() is called, it will first check if there are candidates in the pool before generating new ones.<br> <br> Any thoughts or suggestions?<br> <br> Thanks!<br><div>Sherrill</div></div><div> <br> <fieldset></fieldset></div><pre>_______________________________________________</pre><pre>gstreamer-devel mailing list</pre><pre><a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a></pre><pre><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a></pre></blockquote><div>_______________________________________________<br></div><div>gstreamer-devel mailing list<br></div><div><a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br></div><div><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br></div></blockquote><div><br></div><div><span><pre><div>_______________________________________________<br></div><div>gstreamer-devel mailing list<br></div><div><a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br></div><div><a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br></div></pre></span></div></blockquote><div><br></div><div><span><pre>-- <br></pre><div>Olivier Crête</div><div><a href="mailto:olivier.crete@collabora.com" target="_blank">olivier.crete@collabora.com</a></div><div><br></div></span></div></div>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div>
</blockquote></div>