Receiver Buffer Management with SRTO_TLPKTDROP=false

[MalikAhmed2]

Hi,

I have a question about SRT Live mode when SRTO_TLPKTDROP is set to false on both the sender and the receiver.

My understanding is that with Too-Late Packet Drop disabled, packets are not discarded simply because they have missed their scheduled playback time. In that case, does the receiver buffer ever drop packets whose play time has already passed? What mechanism removes old packets from the receive buffer so it doesn't keep growing forever?

[ethouris]

If SRTO_TLPKTDROP is off, then SRT never drops packets - it aims at 100% packet recovery, even at the expense of causing head-of-the-line blocking. In case of MPEG-TS this may lead to delivering packets to the decoder too late and cause distortion in the playout. In the extreme cases, it may also lead to the receiver buffer blowup, which quickly causes breaking of the connection.

If you consider this because it prevents also dropping on the sender side (as it prevents dropping completely), and you have observed many "unnecessary" drops at the sender side, you can disable sender-side drops by setting SRTO_SNDDROPDELAY to -1 on the sender side. This will prevent completely "premature" drops on the sender side - at the expense of sending anyway packets that would be still dropped by the receiver and possibly waste the link for useless sending.

[MalikAhmed2]

I decided to disable SRTO_TLPKTDROP because I am observing a significant number of packets being dropped at the sender, which causes severe visual artifacts in the video.

What happens if SRTO_TLPKTDROP is enabled only on the receiver while it remains disabled on the sender?

[ethouris]

The only site that SRTO_TLPKTDROP influences is the receiver, it changes nothing on the sender.

As I said, if you want to prevent sender from dropping packets that it "thinks" will be dropped by the receiver, set SRTO_SNDDROPDELAY to -1. This will prevent sender from dropping anything - at the expense of possibly sending retransmissions uselessly.

[MalikAhmed2]

Thanks for the clear explanation.