<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi,<br>
    <br>
    <div class="moz-cite-prefix">On 16/3/22 23:19, Michiel Konstapel
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Thanks Matthew!<br>
      </p>
      On 16-03-2022 01:49, Matthew Waters via gstreamer-devel wrote:<br>
      <blockquote type="cite"
        cite="mid:dae6883c-6f87-03d2-acf6-695a105bd8f5@gmail.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        Hi,<br>
        <br>
        <div class="moz-cite-prefix">On 16/3/22 03:09, Michiel Konstapel
          via gstreamer-devel wrote:<br>
        </div>
        <blockquote type="cite"
          cite="mid:20084d2d-d0c9-e413-6aec-d536dd3e0cfb@aanmelder.nl">
          <meta http-equiv="Content-Type" content="text/html;
            charset=UTF-8">
          <p>Aha - it does appear to work if I set "bundle-policy" to
            "max-bundle". At least, then I see it setting up the pt map,
            and I see it creating/pushing rtx buffers. It doesn't seem
            to immediately work wonders for combating packet loss,
            though, but I do think it runs a little smoother.</p>
          <p>So RTX doesn't work with the default bundle-policy, is that
            correct?<br>
          </p>
        </blockquote>
        <br>
        Unknown.  If you're talking with a browser, then you can pretty
        much always use max-bundle so the other modes don't get too much
        testing.  The whole bundle-policy thing is also up for potential
        removal at some point in the WebRTC specification.<br>
      </blockquote>
      <p>I figured I'd stick with default values (like bundle-policy) if
        I don't understand the impact. This is purely streaming to
        browsers, so I'll use max-bundle then. Should I create a ticket
        for the bug impacting the default policy?<br>
      </p>
    </blockquote>
    <br>
    You can if you like, however the default probably isn't going to
    change at this point.<br>
    <br>
    <blockquote type="cite"
      cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl">
      <p> </p>
      <blockquote type="cite"
        cite="mid:dae6883c-6f87-03d2-acf6-695a105bd8f5@gmail.com">
        <blockquote type="cite"
          cite="mid:20084d2d-d0c9-e413-6aec-d536dd3e0cfb@aanmelder.nl">
          <blockquote type="cite"
            cite="mid:1e742b3c-c7f2-6a1e-23c7-7c3be196b271@aanmelder.nl">Looks
            like this is the call from
            gstwebrtcbin.c:on_rtpbin_request_aux_sender, but that only
            assigns stream->rtxsend AFTER the call to
            _set_rtx_ptmap_from_stream. </blockquote>
        </blockquote>
        <br>
        This was an issue that may have only been fixed in latest git.</blockquote>
      <p>I'm looking at master now, but it <a
href="https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c#L6117"
          moz-do-not-send="true">looks like</a> this code path is
        unchanged.</p>
    </blockquote>
    <br>
    The github mirror is currently out of date.  The branch to look at
    is 'main'<br>
    <br>
    The code has changed since: <a moz-do-not-send="true"
href="https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6676"
      class="moz-txt-link-freetext">https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6676</a>.<br>
    <br>
    <blockquote type="cite"
      cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl">
      <p>By the way - do you happen to know if nack/rtx actually works
        when streaming to a browser? I figured retransmits would easily
        hide 1% packet loss. I see the browser sending nacks, and I see
        rtprtxsend pushing out buffers, but I see no visual improvement.
        Is there any statistic I can get from the browser that shows
        whether the retransmits are arriving (at all, and on time?)
        Would VP8 or VP9 cope with packet loss better than H.264?<br>
      </p>
    </blockquote>
    <br>
    I have had experience with NACK's working when talking to a browser,
    yes.  Depends on your browser as to what exact stats are available. 
    e.g. in Chromium-based browsers, 'chrome://webrtc-internals/'.<br>
    <br>
    Cheers<br>
    -Matt<br>
    <br>
    <blockquote type="cite"
      cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl">
      <p> </p>
      <p>Cheers,<br>
        Michiel<br>
      </p>
    </blockquote>
    <br>
  </body>
</html>