When transporting a video across two PCs with SRT and enabling FEC, image distortion occurs

[kobayashi750]

Describe the bug
When transporting a video across two PCs with SRT and enabling FEC, image distortion occurs.

To Reproduce
Steps to reproduce the behavior:

• PC1(192.168.0.50) is connected to PC2(192.168.0.60) with a LAN cable directly.

1. At PC1: ffmpeg -re -i big_buck_bunny_720p_stereo.avi -pix_fmt yuv420p -c:v libx264 -b:v 3000k -profile:v baseline -preset veryfast -f mpegts "udp://127.0.0.1:1234?pkt_size=1316"
2. At PC1: srt-live-transmit "udp://127.0.0.1:1234?rcvbuf=67108864" "srt://192.168.0.50:4201?mode=listener&packetfilter=fec,cols:4,rows:4,arq:never"
3. At PC2: srt-live-transmit "srt://192.168.0.50:4201?mode=caller&packetfilter=fec" "udp://127.0.0.1:1235"
4. At PC2: ffplay "udp://127.0.0.1:1235"

Expected behavior
No image distortion occurs.

Desktop (please provide the following information):

• PC1: Windows 8.1, Intel Core i5-5200U CPU, Fire wall is disabled
• PC2: Windows 10 Pro, Intel Core i7-9700 CPU, Fire wall is disabled
• SRT Version: v1.5.1
• srt-live-transmit's cmake: cmake -G"Visual Studio 17 2022" -A x64 -DENABLE_STDCXX_SYNC=ON
• ffmpeg/ffplay Version: version 6.0-essentials_build-www.gyan.dev

Additional context

• The video "big_buck_bunny_720p_stereo.avi" is from https://download.blender.org/peach/bigbuckbunny_movies/ .
• I tryed following but results don't change
  • change FEC dimension to 10 rows / 10 cols
  • increase the lantecy of srt-live-transmit to 300ms at PC2
  • decrease the video rate to 1000kbps at ffmpeg
  • try SRT version v1.4.4 and v1.5.2
• I tryed following then results changed (Image distortion decreased)
  • Use not two PCs but only one PC (Don't transport a video across two PCs. Complete within a single PC)
  • Switch PC1 and PC2 (Transport a video from PC2 to PC1)
• The output of srt-live-transmit at PC1 is
• The output of srt-live-transmit at PC2 is

[ethouris]

It's hard to speculate anything just for the fact that drops occur. Please add options to collect statistics at least on the receiver side so that it's possible to have idea about the level of losses (on the sender it's not necessary as you have turned off retransmission). If I can see 82 packets dropped in a row, I doubt FEC can do any significant recovery, no matter the configuration. Still, if you have statistics, we can at least have idea how many packets could be recovered by FEC and whether it is expected.

[kobayashi750]

Thank you for your comment. I will add the statistics collection option.
However, I think it is more important why the packet drop occurs, not whether it can be recovered by FEC. The two PCs are directly connected by a LAN cable, so the packet drop should not occur.

[kobayashi750]

Sorry for the wait. I added the statistics collection option as follows at step 3.
srt-live-transmit -s:100 -statsout:stats.txt -f -logfile:log.txt "srt://192.168.0.50:4201?mode=caller&packetfilter=fec" "udp://127.0.0.1:1235"

The obtained files are
stats.txt
log.txt

Please check it and give me advice.

[ethouris]

Ok, here is one example stats grab:

PACKETS     SENT:           0  RECEIVED:          2625
LOST PKT    SENT:           0  RECEIVED:            50
REXMIT      SENT:           0  RECEIVED:             0
DROP PKT    SENT:           0  RECEIVED:            21
FILTER EXTRA  TX:           0        RX:           873
FILTER RX  SUPPL:           2  RX  LOSS:             0
RATE     SENDING:           0  RECEIVING:      6.45087

We have 2625 packets received, 50 packets were detected as lost, and out of these only 2 were able to be rebuilt by FEC with 873 considered as FEC overhead. Not sure why all these numbers don't sum up - that something we need to take a closer look at - but definitely if you lose so many packets, especially in a row, full recovery with FEC is definitely not possible.

Just one question: what kind of network it is, through which you send the data? Is it programmed to have losses, or it's just the property of this link?

[ethouris]

So, I have also viewed logs and there's a reported of 150 packets dropped at once, which means that UDP dropped so many packets and they were - or at least a vast majority of them - were not recovered. There's no way FEC can recover this. For example, if you make a matrix 5x5, it's 25 packets + 10 overhead and 10 evenly distributed packets out of these might be recovered. So with 150 packets lost in a row, you have 6 full FEC matrices with neither one packet received - nothing can be recovered. OTOH if you set a crazy size 50x50 FEC matrix, you have 2500 packets in the matrix + 100 FEC overhead and so 100 packets potentially can be recovered, but with 150 packets lost in a row you have 3 consecutive lost rows or 4 consecutive rows with only edge packets received: no way that any of them are recovered, unless you have the staircase arrangement and are lucky enough to get this hit on the border between consecutive FEC groups. Maybe the probability of this may increase if you use very low number of rows (say, cols=50,rows=5), but still, we are talking about 150 consecutive loss, which means 3 consecutive rows. At best you might recover packets from the first row, or packets that happen to be on the border of FEC groups, but never all of them. Recovering from 3 consecutive lost rows is simply impossible. You might test the configuration with 50 columns and 5 rows (which makes 250 packets in the matrix with 55 packets of overhead (18%), there's a chance that losing 30 packets in a row can be recoverable, but 150 definitely not.

Note also that it makes sense to use FEC only in network links, which have a highly stable bandwidth cap (packet losses are rather evenly distributed) and high RTT (more than 1000ms). When your bandwidth cap fluctuates, but RTT is rather low (I've seen 5ms highest), using the default retransmission mechanism is a better choice.

[kobayashi750]

Thanks for advice. And I answer your question.

Just one question: what kind of network it is, through which you send the data? Is it programmed to have losses, or it's just the property of this link?

The two PCs used to send/receive data are directly connected by one LAN cable. No router or hub is connected. So the packet loss should not occur.

[ethouris]

Well, the packet loss simply does occur - on the UDP level. SRT doesn't do anything that would result in losing the packet, the packet scheduled first time for sending is always sent, so the only party responsible for dropping this first time sent UDP packet with SRT data is the operating system.

We have been observing such a thing on Windows during some of our tests (never seen on Linux or Mac). Windows may even sometimes cause packet loss on UDP when sending data between two applications running on the same system.

[maxsharabayko]

We have been observing such a thing on Windows during some of our tests (never seen on Linux or Mac). Windows may even sometimes cause packet loss on UDP when sending data between two applications running on the same system.

Should now be resolved with PR #2632 (SRT v1.5.3-rc.0).

[ethouris]

Ah, right, forgot about that fix with overlapped API. So, @kobayashi750 you may want to retest once version 1.5.3 is released.

[kobayashi750]

Thank you for comments! And I'll retest with version 1.5.3.

[kobayashi750]

I retested with version 1.5.3. And now packet loss doesn't occur anymore. Thank you very much !