<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> Hi, <div class="moz-cite-prefix">On 16/3/22 23:19, Michiel Konstapel wrote: </div> <blockquote type="cite" cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Thanks Matthew! On 16-03-2022 01:49, Matthew Waters via gstreamer-devel wrote: <blockquote type="cite" cite="mid:dae6883c-6f87-03d2-acf6-695a105bd8f5@gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi, <div class="moz-cite-prefix">On 16/3/22 03:09, Michiel Konstapel via gstreamer-devel wrote: </div> <blockquote type="cite" cite="mid:20084d2d-d0c9-e413-6aec-d536dd3e0cfb@aanmelder.nl"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 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. So RTX doesn't work with the default bundle-policy, is that correct? </blockquote> 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. </blockquote> 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? </blockquote> You can if you like, however the default probably isn't going to change at this point. <blockquote type="cite" cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl"> <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> This was an issue that may have only been fixed in latest git.</blockquote> 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. </blockquote> The github mirror is currently out of date. The branch to look at is 'main' 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>. <blockquote type="cite" cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl"> 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? </blockquote> 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/'. Cheers -Matt <blockquote type="cite" cite="mid:0fe40b6d-5f44-5cb8-f5c6-577a0983b34b@aanmelder.nl"> Cheers, Michiel </blockquote> </body> </html>