rtpst2022-1-fecenc/rtpst2022-1-fecdec: Performance Issues (i.e. Packet recovery) with Increased 2D grid size
Hi Integrated rtpst2022-1-fecenc (i.e. sender side)and rtpst2022-1-fecdec (receiver) in our streaming application. For the same drop probability, packet recovery decreases with 2D grid sizes. In my experiment, measured the no of lost frames before decoding
No of lost frames For Drop probability of 1% 5x5: 1, 6x6: 1, 8x8: 8, 10x10: 12,
For Drop probability of 2% 5x5: 1, 6x6: 9, 8x8: 27, 10x10: 56,
For Drop probability of 3% 5x5: 4, 6x6: 12, 8x8: 45, 10x10: 213,
For Drop probability of 4% 5x5: 0, 6x6: 19, 8x8: 109, 10x10: 277,
For Drop probability of 5% 5x5: 0, 6x6: 27, 8x8: 131, 10x10: 310
Total no of frames tested 2700
clearly packet recovery decreases with 2d grid size.
Observed the logs in rtpst2022-1-fecdec element, pasted few logs
rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:549:check_fec:<rtpst_2022_1_fecdec0>[00m Too many media packets missing, storing FEC packet rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:549:check_fec:<rtpst_2022_1_fecdec0>[00m Too many media packets missing, storing FEC packet rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:456:xor_items:<rtpst_2022_1_fecdec0>[00m Recovered buffer through row FEC with seqnum 1455, payload len 910 and timestamp 784757681 rtpst2022-1-fecdec gstrtpst2022-1-fecdec.c:541:check_fec:<rtpst_2022_1_fecdec0>[00m All media packets present, we can discard that FEC packet
Based on the logs, and experimental data, assuming it is recovering the packets using row FEC, i haven't observed any message related to column (i.e. just like Recovered buffer through column FEC).
Theoretically, if more than one packet loss (i.e. assume two packets)in a row, then both column and row fec needed to recover
those packets (i.e. first column fec and then row fec).
with increased 2d grid size, probability for losing multiple packets in a row increases, if we use row fec only, then the recovery ratio decreses.
So my experimental data is supporting my assumption (i.e. using only row FEC to recover).
Please check.
Tested in our application and also using gst-launch.
gst-launch-1.0 rtpbin name=rtp fec-encoders='fec,0="rtpst2022-1-fecenc\ rows=5\ columns=5";' filesrc location="filename.yuv" ! videoparse width=640 height=360 format=2 framerate=25 ! x265enc tune=zerolatency ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! rtph265pay ssrc=0 ! rtp.send_rtp_sink_0 rtp.send_rtp_src_0 ! udpsink host=xxx.xx.xxx.xxx port=5000 rtp.send_fec_src_0_0 ! udpsink host=xxx.xx.xxx.xxx port=5002 async=false rtp.send_fec_src_0_1 ! udpsink host=xxx.xx.xxx.xxx port=5004 async=false
gst-launch-1.0 rtpbin latency=500 fec-decoders='fec,0="rtpst2022-1-fecdec\ size-time=1000000000";' name=rtp udpsrc port=5002 caps="application/x-rtp, payload=96" ! queue ! rtp.recv_fec_sink_0_0 udpsrc port=5004 caps="application/x-rtp, payload=96" ! queue ! rtp.recv_fec_sink_0_1 udpsrc port=5000 caps="application/x-rtp, media=video, clock-rate=90000, encoding-name=H265" ! queue ! netsim drop-probability=0.05 ! rtp.recv_rtp_sink_0 rtp. ! rtph265depay ! queue ! h265parse ! avdec_h265 ! videoconvert ! videoscale ! ximagesink