NACK optimize

[notedit]

Hi murillo,

I read your nack part code, i think the nack can be optimized. here is some stats from webrtc.
I test this in local network.

this is retransmit bitrate

this is video bitrate

this is nack received

[murillo128]

How do you think it can be optimized? i am against early-optimizations without clear metrics from real live scenarios.

[murillo128]

Also, what do you see wrong in your graphics?

[notedit]

I compare medooze and agora's service on my mac, agora's has very little nacks and retransmit bitrate is almost is zero.

[notedit]

Also, what do you see wrong in your graphics?

the nacks is too much and the retransmit bitrate is a bit of high.

[murillo128]

do you have a sendonly stream? in this case I use rtx/nacks to get the rtt periodically. If not, there should be nacks according to the packet losses.

[notedit]

yes, this is a sendonly stream. I know you send rtx to get rtt periodically, but there is only one rtx in one second.

[murillo128]

nack policy is a bit aggressive, I send one nack packet each time a packet is lost and on subsequent packets until rtx is received or timeout happens.

This nacks redundant packets will be filtered by libwebrtc and only send rtx first time the nack packet is receveid and retransmisión based on rtt. So this causes no extra rtx from client->server.

The only effect are minor spikes of rtcp traffics depending on the rtt which should not have much side issues.

[notedit]

Just go through webrtc's nack_module https://github.com/notedit/webrtc-clone/blob/5a29d526be7589f5ba7fb824a749f9088b305070/modules/video_coding/nack_module.cc#L36

they add a default 10ms delay filter. that may help.

[notedit]

I have a simple test in my local, add 20ms delay can reduce half of retransmit bitrate in 500kbps.

[murillo128]

that's expected as bbr is a delay based algorithm so an increase means congestion and bwe is reduced. post a screenshot of the bwe stats viewer to set the behavior of the algorithm better El sáb., 12 oct. 2019 20:44, leeoxiang <notifications@github.com> escribió:

…

I have a simple test for in my local, add 20ms delay can reduce half of retransmit bitrate in 500kbps. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#80?email_source=notifications&email_token=AAIFN45DG5WLYLFSJPHKFSDQOILKNA5CNFSM4I3WXTRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCF4OQ#issuecomment-541351482>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIFN43XW5CVQ63KENOI7ITQOILKNANCNFSM4I3WXTRA> .

[notedit]

We may not say the same thing, I mean the incoming source's RTPLostPackets,

I add a 20ms filter when generate nacks, filter the pakcets's time is less than (now - 20ms).

[murillo128]

not sure if i follow you, could you share pr and test case? also that 20ms should be dependent of the rtt, not a fixed value El dom., 13 oct. 2019 7:31, leeoxiang <notifications@github.com> escribió:

…

We may not say the same thing, I mean the incoming source's RTPLostPackets, I add a 20ms filter when generate nacks, filter the pakcets's time is less than (now - 20ms). — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#80?email_source=notifications&email_token=AAIFN43SV3E5F5EWHOB2CHDQOKXBPA5CNFSM4I3WXTRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBCOZVQ#issuecomment-541387990>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIFN43HFJGW4GZAQX3WV3TQOKXBPANCNFSM4I3WXTRA> .

[notedit]

Ok, Will give a pr when i have more free time.