<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> 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 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">looks like</a> this code path is unchanged. 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? Cheers, Michiel </body> </html>