srt: [BUG] [ffmpeg] Data packets dropped when ffmpeg is used as a sender

Describe the bug When using ffmpeg directly to send an SRT stream with a bad connection (I’m simulating with clumsy, adding only outbound packet loss), packets doesn’t get resend/rereceived or I don’t know what. But I get these kind of errors on the receiving end:

[mpegts @ 0x55ded175c740] Continuity check failed for pid 256 expected 4 got 10
[mpegts @ 0x55ded175c740] Continuity check failed for pid 0 expected 15 got 0
[mpegts @ 0x55ded175c740] Continuity check failed for pid 4096 expected 15 got 0
[mpegts @ 0x55ded175c740] Packet corrupt (stream = 0, dts = 3315590).
[mpegts @ 0x55ded175c740] Continuity check failed for pid 257 expected 5 got 10
[mpegts @ 0x55ded175c740] Continuity check failed for pid 256 expected 14 got 5
[mpegts @ 0x55ded175c740] Packet corrupt (stream = 0, dts = 3323090).
[mpegts @ 0x55ded175c740] Continuity check failed for pid 256 expected 7 got 8
[mpegts @ 0x55ded175c740] Continuity check failed for pid 257 expected 8 got 13
[mpegts @ 0x55ded175c740] Packet corrupt (stream = 0, dts = 3324590).
[mpegts @ 0x55ded175c740] Continuity check failed for pid 17 expected 0 got 1

And the H264 stream is completly garbled, at only 1% packet loss. Here is my flow: ffmpeg ----------SRT with latency set to 3000----------> ffmpeg server

When using the srt-live-transmit app as a proxy (ie: ffmpeg ----SRT----> srt-live-transmit ----SRT with latency set to 3000----> ffmpeg server) I can go up to 90% packet lost without ANY problem (with a high bandwidth of course, but it does recover the lost data).

To Reproduce the problem Steps to reproduce the behavior:

1. Run ffmpeg and output to an SRT listener server, specifying a high latency to allow for better packet recovery
2. With some network simulator (I’m on Windows so I use clumsy) try to drop packets and increase the rate.
3. Check the resulting stream and server console for dropped packets. My server is ffmpeg so I get the kind of error you can see above.

Expected behavior Packets should recover themselves with the SRT protocol (provided you have enough bandwidth, I’m on FTTH and my server have an unlimited 300mbps fiber connection with low latency). They do with srt-live-transmit and ffmpeg as a server, but not with ffmpeg as a sender. Either the latency setting is being ignored with FFMPEG (I get similar result when not specifying latency in srt-live-transmit, it defaults to something like 120ms (I though it should take server’s one)), or something else I’m not aware of.

Desktop (please provide the following information):

• OS: Windows 10
• SRT Version / commit ID: 1.4.1

Additional context

• The problem does not appear with either latest srt-live-transmit master, or 1.4.1.
• The ffmpeg build I use (zeranoe) has 1.4.1 included in it.
• I can also provide a server that does proxy SRT input (as “listener”) to my throwaway Twitch channel, so I can provide you the link if you want to test (and with the output you see easily if packets are dropping).