Repository navigation
Continued NACK Improvements #9
Description
- Currently nack is sent in a fixed intervals.
- There is no limit for how many times a nack will be sent for a single packet (current implementation sends nacks as long as either the packet arrives, or the packet is older than
max sequence number - buffer size) - Nacked packets/nack requests are sent using the same PayloadType as normal rtp packets. It is possbile to send them in a dedicated feedback stream. This is much more complicated, and current implementation works, so it should definietly be an improvement in a separate issue.
Activity
aler9 commentedon Dec 26, 2020
Is it normal that the NACK SSRC is random?
interceptor/pkg/nack/generator_interceptor.go
Line 116 in 0ee4264
I didn't saw the specification, but the receiver SSRC should be shared between reports and nacks, therefore it is random but at a higher level.
Edit: i realized that interceptors work with a variable number of streams, therefore they must be able to generate SSRCs - but they must be shared between NACKs and receiver reports. We have to find a way to make it so.
Sean-Der commentedon Dec 28, 2020
@aler9 I think the best way to do this is the Option pattern we use in Pion.
You can see it in GeneratorOption there is also a ResponderOption in the same directory. Instead of doing a 'Configuration Struct' or a bunch of function arguments we do this.
We should add one to set the SSRC. If one isn't set then we can do random!
oto313 commentedon Nov 19, 2024
Hi, I think that the NACK behavior is invalid, at least with pion version 4.0.1. If packet is lost once it indefinitely NACKing the packet.
The result of ReadRTX method https://github.com/pion/webrtc/blob/master/track_remote.go#L131 does not pass the RTX packets back to interceptors so the NackInterceptor thinks the rtx packets did not arrived and request retransmission again in a loop.
As you can see on the main stream the pion transmitted 1475 packets and 184 lost, but on the retransmission stream it requested absurd amount of retransmissions
Note: RTPType-102 is main stream
RTPType-103 is RTX stream
Am I not seeing something? some configuration or anything else? If I change GeneratorMaxNacksPerPacket to 1. It works as expected but if the retransmission packet is lost then there is no way to recover that packet data.
3DRX commentedon Apr 7, 2025
@Sean-Der I think we need an update in this thread, now sending NACK packets with distinct ssrc and payload type is working. (This thread caused me some confusion when I first came across it.)
So if someone is just using pion as a sender, the NACK responder interceptor should almost work perfectly (maybe in the future we can use attributes to make rtx packets have higher priority in pacer).