webrtcbin doesn't retransmit because rtprtxsend has no payload type map
michiel at aanmelder.nl
Wed Mar 16 12:19:26 UTC 2022
On 16-03-2022 01:49, Matthew Waters via gstreamer-devel wrote:
> On 16/3/22 03:09, Michiel Konstapel via gstreamer-devel wrote:
>> 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?
> 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.
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
>>> 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.
> This was an issue that may have only been fixed in latest git.
I'm looking at master now, but it looks like
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel