Improve description of latency related options (e.g. SRTO_RCVLATENCY)

[mbakholdina]

Note: The description was changed.

Since the introduction of a bidirectional transmission, there are two latency settings, one per direction. The SRTO_TSBPDDELAY name comes from the times before it. The negotiated (effective) latency in a particular direction is available through SRTO_PEERLATENCY on the sender side and SRTO_RCVLATENCY on the receiver side. The existing SRTO_LATENCY option just sets both options to the same value to simplify configuration for a general user.

Latency related option names are a bit confusing. For example, a better name for SRTO_PEERLATENCY might be SRTO_PEERRCVLATENCY.

Likely the best and easiest way to reduce the confusion and unclearness would be to improve the description of socket options:

• SRTO_PEERLATENCY
• SRTO_RCVLATENCY
• SRTO_LATENCY

[dvzrv]

Hi!

It seems that https://github.com/Haivision/srt/pull/1364/files removed SRTO_TSBPDDELAY and replaced it with SRTO_LATENCY (IIUC).
However, this change was not communicated in the release notes.
If per this ticket SRTO_LATENCY is also deprecated, what will it be replaced with?

I'm asking, because the upgrade from 1.4.1 to 1.4.2 broke building VLC (on Arch Linux), which relied upon SRTO_TSBPDDELAY.
Before offering upstream with a patch it would be great to know what the way forward is.

[maxsharabayko]

Hi @dvzrv
Sorry for the delay in reply.

There are several topics touched in your question. I will split my answer accordingly.

1. Deprecating SRTO_LATENCY

SRTO_LATENCY is not deprecated as of v1.4.2. You can use it instead of SRTO_TSBPDDELAY.

2. Deprecation procedure.

To remove a socket option or an API function we have to follow a deprecation procedure (to be described in the Developer's Guide). This option/function is marked with a deprecation attribute and kept so fo several SRT releases. The deprecation attribute produces a build warning. thus letting a user know about this deprecation and that some steps have to be applied to use a new function or name.

3. Removed SRTO_TSBPDDELAY

SRTO_TSBPDDELAY was an alias of the SRTO_LATENCY, and it was (thought to be) marked deprecated since v1.4.0.
Although now I see it was only marked deprecated in the comments and did not produce any warnings when used, like with other deprecated socket options. It was our flow that we missed that.

4. Recommendations on SRTO_LATENCY

There are effectively two latency options: SRTO_RCVLATENCY and SRTO_PEERLATENCY. The first one sets the minimum receiving latency of the SRT side being configured, and the second one specifies the minimum receiving latency for the peer. The actual latencies are negotiated during the handshake.

The SRTO_LATENCY option sets both SRTO_RCVLATENCY and SRT_PEERLATENCY to the same value provided via the option for convenience.

It is recommended to use SRTO_RCVLATENCY and SRT_PEERLATENCY directly, rather than SRTO_LATENCY.