<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 28/8/20 6:54 am, Trey Hutcheson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAd3e3MAh0UO6ZPcBb+9nC-Yo-D32TUNNPZ0CCWuDXCDVSXZ=w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I'm sorry, but what do you mean that I have to wait
for the sources to have received data before proceeding with the
offer or answer?
<div><br>
</div>
<div>Here's the workflow:</div>
<div>1) Pipeline is created. Initially it contains a bin that
has a videotestsrc that tee's to a fakesink. </div>
<div>2) A new bin is created that contains a webrtcbin element.
The videotestsrc is linked to this bin, and encoded into vp8
along the way. </div>
<div>3) remote peer (chrome) creates and submits an sdp offer,
including ice candidates (non-trickle workflow)<br>
</div>
<div>4) I set the remote description of type offer, then
manually extract ice candidates from the sdp add them</div>
<div>5) i then create an sdp answer, while also listening for
locally gathered candidates. <br>
</div>
<div>6) I return the sdp and ice candidates via the signalling
channel and the remote peer uses it as the remote description</div>
<div>7) Media flows. Video is rendered. Etc etc etc.</div>
</div>
</blockquote>
<br>
Depending on your code, there may be a race between 2 and 5 of the
caps reaching a webrtcbin sink pad. You can workaround by waiting
for the later of notify::caps being emitted on the webrtcbin sink
pad and the successful setting of the offer before you ask to create
the answer.<br>
<br>
<blockquote type="cite"
cite="mid:CAAd3e3MAh0UO6ZPcBb+9nC-Yo-D32TUNNPZ0CCWuDXCDVSXZ=w@mail.gmail.com">
<div dir="ltr">
<div>This workflow worked 100% of the time, over hundreds and
hundreds of iterations, for the past several months on 1.16. </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Aug 27, 2020 at 3:16
PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca"
moz-do-not-send="true">nicolas@ndufresne.ca</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">Le
jeudi 27 août 2020 à 11:50 -0500, Trey Hutcheson a écrit :<br>
> I have a media server that currently runs against
gstreamer 1.16.2.<br>
> When I run that same code on top of the current 1.17.9
master, I<br>
> sometimes get no media to my remote peers. <br>
> <br>
> The workflow is simple. The browser provides the offer,
and webrtcbin<br>
> provides the answer (signaling is our own custom app).
Looking at the<br>
> sdp, I see that in the cases where media never starts
flowing that<br>
> the sdp answer does not include ssrc's. <br>
> <br>
> Example fragment from good sdp answer:<br>
> m=video 9 UDP/TLS/RTP/SAVPF 96<br>
> c=IN IP4 0.0.0.0<br>
> a=ice-ufrag:fENRu4J+ohkX+c21z/3vzhvQ0a7LMqrX<br>
> a=ice-pwd:64ese6hPqiLwjB8QytOBokIXJGqf37Az<br>
> a=mid:0<br>
> a=rtcp-mux<br>
> a=setup:active<br>
> a=rtpmap:96 VP8/90000<br>
> a=rtcp-fb:96 nack pli<br>
> a=rtcp-fb:96 ccm fir<br>
> a=framerate:30<br>
> a=ssrc:1009469877 msid:user286747991@host-a7789f8b
webrtctransceiver5<br>
> a=ssrc:1009469877 cname:user286747991@host-a7789f8b<br>
> <br>
> Example fragment from bad sdp answer:<br>
> m=video 9 UDP/TLS/RTP/SAVPF 96<br>
> c=IN IP4 0.0.0.0<br>
> a=ice-ufrag:2t2Wy+2pPcDPVPmVyixyMH2O/s63DFiX<br>
> a=ice-pwd:gPMprJzvik/ulzX3S92hcsGsdBMcYfgd<br>
> a=mid:0<br>
> a=rtcp-mux<br>
> a=setup:active<br>
> a=rtpmap:96 VP8/90000<br>
> a=rtcp-fb:96 nack pli<br>
> a=rtcp-fb:96 ccm fir<br>
> a=sendonly<br>
> <br>
> Notice that the second fragment does not include a=ssrc
lines (nor<br>
> does it include the framerate attribute). <br>
> <br>
> This is troubling because the issue is intermittent. It
happens with<br>
> great frequency. If, however, I set GST_DEBUG to 4, then
it happens<br>
> far less often, though still occasionally. That would
indicate to me<br>
> it is some internal race condition?<br>
<br>
Consider using GST_DEBUG="webrtcbin:7,3" or similar log level.
Be aware<br>
that you need to wait for the sources to have received data
before<br>
proceeding with an offer or answer. This corner case has
multiple FIXME<br>
in the webrtcbin. That is worked reliable without special care
in 1.16<br>
was likely just luck.<br>
<br>
Nicolas<br>
<br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org"
target="_blank" moz-do-not-send="true">gstreamer-devel@lists.freedesktop.org</a><br>
> <a
href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org"
target="_blank" moz-do-not-send="true">gstreamer-devel@lists.freedesktop.org</a><br>
<a
href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>