webrtcbin doesn't retransmit because rtprtxsend has no payload type map

[Matthew Waters]

Hi,

On 16/3/22 23:19, Michiel Konstapel wrote:
>
> Thanks Matthew!
>
> On 16-03-2022 01:49, Matthew Waters via gstreamer-devel wrote:
>> Hi,
>>
>> 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 default policy?
>

You can if you like, however the default probably isn't going to change
at this point.

>>>> 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
> <https://github.com/GStreamer/gst-plugins-bad/blob/master/ext/webrtc/gstwebrtcbin.c#L6117>
> this code path is unchanged.
>

The github mirror is currently out of date.  The branch to look at is 'main'

The code has changed since:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-bad/ext/webrtc/gstwebrtcbin.c#L6676.

> 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?
>

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

> Cheers,
> Michiel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220317/0748a4c1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220317/0748a4c1/attachment.sig>