Add a functionality for best parameter tweak calculation

[ethouris]

Many options need to be changed in sync or a wrong value of one option may make others not working, as well as the transmission may not work at all at given combination of options.

Cases found so far:

1. With very high latency and high bitrate, a default setting for a sender and receiver buffer size need not suffice.
2. With packet filtering (pending feature) some delivery delay may be extra required, as results from the filter settings combined with predicted maximum bitrate. It is desired that basing on these two values there can be spelled up a minimum latency value that must be preserved.

[oviano]

I'm curious about point 1 as I'm testing high latencies with SRT - what sort of examples of high latency and high bitrate produce problems and which buffer size settings exactly would need increasing - would it be SRTO_RCVBUF and SRTO_SNDBUF?

For example, lets say maximum latency of 8000ms, and a bitrate of 20 Mbit/s. So that's total size of 20MB (assuming exactly constant encoder output) over 8 seconds vs the default buffer size of 8192 x (1500 - 28) = 11.5MB, so in that scenario the buffer is too small?

[ethouris]

I haven't made any research on that topic yet, but I think it can be calculated.

The receiver buffer has a default setting of 8192 packets and every packet is set to maximum determined from the SRTO_MSS option, which is 1500 default, so it takes the maximum size of 1456 bytes, and this is the base for the total buffer size managed by SRTO_RCVBUF option.

Important thing is to know how distant is one packet to another in time. This is determined by the stream bitrate and it decides for how much "playing time" in total is the total space in the receiver buffer predicted. A safe statement would be to give not more than 1/4 of the receiver buffer for "latency buffering".

[maxsharabayko]

#703 addresses this topic and references this issue. Therefore, Closing.