FEC with less than 2% loss?

[TheSashmo]

I’ve been playing with Ultragrid for a while now, and have had some great success using my with home brew RTP based error correction. I’m trying to get even lower latency I.e would like to get into using FEC only. I should be able to get around the standard arq style of transmission and as long as I have bandwidth, be able to crank up the FEC to compensate for losses and get down to 50% RTT time, at least in theory this makes sense.

My issue is no matter what RS combination I use, I can’t even survive .5 to 1 % losses which I measured with iperf. From what I was reading I should be able to handle 5% or more just with FEC.

My video is not more than 10mbps.

Any suggestions? My RTT time is 100ms so I’d like to be in 100ms or less with FEC. Is that even possible considering network jitter? Or should I just change my protocol to attempt a different method other than RTP/UDP

[alatteri]

What codec? I've had very solid results using FEC with H.264, but terrible results with H.265 to the point of near uselessness. I switched to SRT encapsulation, but it does incur a latency penalty.

[TheSashmo]

I’m using H264.

I have never seen SRT working with any advantage below 100ms and is still ARQ based. Which means it needs the full RTT time x2, that means 200ms to at least error correct once properly.

I’m trying to cut the RTT by half switching to FEC only.

[alatteri]

I run with an SRT latency of 60ms without issue. Receiver have a physical latency of around 18ms.

[MartinPulec]

Are you using default configuration for Reed-Solomon (I believe it is 200:240)? This should be very sufficient for your loss rate. But the important point is the loss distribution. For your example, supposing 30 FPS and 1500 B packet yields some 28 packets per video frame. If the network loss is not uniform, 5 lost packets per frame are critical. Could you check the value of max loss from output? It gives maximal consecutive packet loss. To sum up - the FECs in UltraGrid work well if the packet loss is equally distributed, if clustered, it cannot cope with it.

[TheSashmo]

Here is what iperf shows in my last test. It’s about 1% losses.

Yes I was testing with the default rs option.

#  iperf -s -u -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 172.16.21.140 port 5001 connected with 10.140.46.29 port 49197
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0- 1.0 sec  1.20 MBytes  10.0 Mbits/sec   0.856 ms    0/  854 (0%)
[  3]  1.0- 2.0 sec  1.18 MBytes  9.93 Mbits/sec   0.878 ms    6/  850 (0.71%)
[  3]  2.0- 3.0 sec  1.19 MBytes  10.0 Mbits/sec   0.829 ms    2/  852 (0.23%)
[  3]  3.0- 4.0 sec  1.19 MBytes  9.98 Mbits/sec   0.797 ms    1/  850 (0.12%)
[  3]  4.0- 5.0 sec  1.19 MBytes  9.98 Mbits/sec   0.861 ms    1/  850 (0.12%)
[  3]  5.0- 6.0 sec  1.18 MBytes  9.88 Mbits/sec   0.905 ms    9/  849 (1.1%)
[  3]  6.0- 7.0 sec  1.19 MBytes  9.95 Mbits/sec   0.857 ms    5/  851 (0.59%)
[  3]  7.0- 8.0 sec  1.19 MBytes  9.97 Mbits/sec   0.885 ms    3/  851 (0.35%)
[  3]  8.0- 9.0 sec  1.19 MBytes  9.98 Mbits/sec   0.887 ms    0/  849 (0%)
[  3]  0.0-10.0 sec  11.9 MBytes  9.97 Mbits/sec   0.926 ms   30/ 8504 (0.35%)
[  4] local 172.16.21.140 port 5001 connected with 10.140.46.29 port 45599
[  4]  0.0- 1.0 sec  2.39 MBytes  20.0 Mbits/sec   0.479 ms    6/ 1709 (0.35%)
[  4]  1.0- 2.0 sec  2.38 MBytes  20.0 Mbits/sec   0.459 ms    1/ 1702 (0.059%)
[  4]  2.0- 3.0 sec  2.38 MBytes  20.0 Mbits/sec   0.324 ms    2/ 1700 (0.12%)
[  4]  3.0- 4.0 sec  2.38 MBytes  20.0 Mbits/sec   0.502 ms    2/ 1699 (0.12%)
[  4]  4.0- 5.0 sec  2.39 MBytes  20.0 Mbits/sec   0.469 ms    0/ 1702 (0%)
[  4]  5.0- 6.0 sec  2.37 MBytes  19.9 Mbits/sec   0.563 ms    7/ 1700 (0.41%)
[  4]  6.0- 7.0 sec  2.38 MBytes  19.9 Mbits/sec   0.535 ms    2/ 1698 (0.12%)
[  4]  7.0- 8.0 sec  2.35 MBytes  19.7 Mbits/sec   0.466 ms   29/ 1702 (1.7%)
[  4]  8.0- 9.0 sec  2.38 MBytes  20.0 Mbits/sec   0.439 ms    6/ 1703 (0.35%)
[  4]  0.0-10.0 sec  23.8 MBytes  19.9 Mbits/sec   0.444 ms   55/17007 (0.32%)

[TheSashmo]

Sorry guys that was paste from iPhone.

[MartinPulec]

And what does UltraGrid receiver say about maximal loss? The number seem to be good but the loss pattern is very important here.

[TheSashmo]

I don't have the output logs anymore the device is offline, but the receiver was showing losses on either audio or video off an on, meaning either video had losses and audio didnt, or vice versa. I will be testing again on Friday with this exact setup. I just find it very weird that the FEC couldn't handle such basic losses. The moment I added my tool or srt, it cleaned it up, but both tools add latency.

[MartinPulec]

Ok, perfect if you could test. It really depends - if there is a block loss of let say >5 packets (for 10 Mbps) or so, it may cause problems. Otherwise, Reed-Solomon should handle that - unless the loss rate is higher in UG than in iperf. If so, it may be possible to look at it but hard to tell without more info.