[FR] SRT responsiveness under 20 ms of latency

[maxsharabayko]

SRT does not respond to events on time scales shorter than 20 ms.
The receiver buffer will not let the upstream application read a packet until ACK is sent. ACK is sent every 10 ms (LiteACK can be sent in between at higher data rates), and all packets are stuck in the receiver buffer until they are acknowledged by the receiver.
It limits the minimum end-to-end latency of SRT to ~20 ms.

Also the minimum interval of Periodic NAKs is 20 ms.

See also: How to Configure SRT Settings.

[ethouris]

There's a feature I've tried to implement during the works on socket groups: "immediate ACK". Step-based ACK makes indeed sense only in file transmission because it allows to sign off a series of packets that comprise a larger portion of the stream that a user can place in a larger buffer, or use directly to write to the output file without causing lots of fine-grained writing operations. In live mode it doesn't make any sense at all because every individual packet here is given up to the application when its play time comes and the situation of reporting a long series of packets is never a case.

The exact idea for "immediate ACK" was that simply the ACK-ed region was always extended with every contiguous packet coming in. If the next-to-last-acked was a loss hole, then reception of this one was connected with searching on for the next hole or end-of-buffer. In case when play time has come for the packet not in ACK-ed region (and with TLPKTDROP on), the ACK region was extended up to this packet and further like above. In this case also the ACK action didn't involve packet signoff at all, it was simply reporting the ACK value from the position of the current end of ACK region.

[maxsharabayko]

Resolved in #1674