TL Packet drop does not work properly with TSBPD disabled

[maxsharabayko]

Problem statement

SRTO_TLPKTDROP=ON and SRTO_TSBPDMODE=OFF does not work as it may be expected to work.

Given it was not originally designed to work this way, this is either a bug or a feature request.

Timestamp based packet delivery (TSBPD)

Socket option: SRTO_TSBPDMODE and SRTO_LATENCY
When enabled, a packet will be delivered from a receiving SRT socket to an application with a certain latency.
When disabled, a packet is delivered to an application as soon as it is received and it has no preceding missing packets to wait to be received.

Implementation on receiver

If TSBPD is enabled, the receiver starts an additional TSBPD thread to track the time a packet should be delivered. In case of TL packet drop is enabled, this thread also decides when to drop missing packets as it is too late for them to be delivered to the app.
If TSBPD is disabled, the related thread that decides when to drop packets on the receiving side is not launched.

Implementation on sender

TSBPD makes the sender set the origin timestamp to each packet being sent. The origin timestamp is the time when the payload was written to SRT socket.
If TSBPD is disabled, the sender will set the timestamp related to the time the packet is being sent over UDP socket.

Too late packet drop (TL PktDrop)

Socket options: SRTO_TLPKTDROP and SRTO_SNDDROPDELAY

On the sending side, TLPKTDROP discards packets reported as lost if it is already too late to send them.

From the code, it looks like the sender will drop packets based on the timeout. No drop request is sent to the receiver to tell the receiver the packet is dropped. Probably it assumes the receiver will drop it itself, but with TSBPD disabled the receiver does not start the TSBPD thread to do it.

Furthermore, with TSBPD disabled, the receiver will keep getting packet with the timestamp of sending instead of the original timestamp.

Note. If support for this combination is added, consider:

• checking SRT version of the peer, and maybe write a warning that the peer will likely not operate properly with the current configuration.
• adding a note to the docs, that SRTO_MINVERSION might worth t be used for such a configuration.