Difference in performances srt-test-live vs srt-live-transmit with high bitrate video

[abbetch]

Hello.
I've been doing some tests this past few days, looking mainly at the bonding feature.
I've noticed a video degradation with using the socket group option. So I've decided to use srt-test-live without using any grouping, and noticed the degradation too.

So, my question is : is it expected and I should try to play more with the parameters ? or there is actually an issue ?
(using the current code on master, compiled with ./configure --enable-testing --enable-experimental-bonding

Here are more informations if needed:

Here is my setup: (Both are linux machine, server is a physic one, client is a VM)
ffmpeg read -(udp)-> srt (listener) -> srt (caller) -(udp)-> ffplay

My source video is indicated by ffmpeg to be ~ 45000kbits/s

Here is the line used the 'client' (note that there is no difference if I use srt-live-transmit or srt-test-live)
./srt-live-transmit "srt://10.0.1.221:10999?type=caller" "udp://10.0.1.236:6000?rcvbuf=67108864"

On the server I'm using:
./srt-live-transmit udp://:5000?rcvbuf=67108864 "srt://:10999?type=listener"
or
./srt-test-live udp://:5000?rcvbuf=67108864 "srt://:10999?type=listener"

I've reduced the video bitrate to 15mb/s and I still have a lot compaints from ffplay about corrupted datas when using srt-test-live, but everything is perfect when I use srt-live-transmit.

The logs in both cases display no packed drop. here is two logs files from the server. (log1 with the srt-test-live, log2 with srt-live-transmit)

log2.csv

log1.csv

[maxsharabayko]

Hi @abbetch

The logs in both cases display no packed drop. here is two logs files from the server.

The SRT sender does not provide the number of drops of the receiver. It only reports its own drops. Receiver dropping a packet just acknowledges it as if it was received.
So the actual drop value can only be taken from the receiver at the moment. Related FR #1889.
Or from a network (Wireshark) capture on the receiver side.

However, the quality degradation you see is quite interesting. I would recommend checking srt-xtransmit.

Your commands would look the following way:

(client)
./srt-xtransmit route -i "srt://10.0.1.221:10999" -o udp://10.0.1.236:6000

(server)
./srt-xtransmit route -i udp://:5000 -o srt://:10999

[abbetch]

Hello,
I just tested the 'srt-xtransmit' and I have the same behavior.
This time I have a linux as server and a mac as client.

The transmission is fine up to until 15 -20 Mb/s but if I go up I obtain à lot of:

12:44:55.660649/T0x70000ceaf000!W:SRT.br: @288185374:RCV-DROPPED 16 packet(s), packet seqno %811940997 delayed for 2.116 ms
12:45:14.224753/T0x70000ceaf000!W:SRT.br: @288185374:RCV-DROPPED 10 packet(s), packet seqno %812015136 delayed for 0.094 ms
12:45:38.758009/T0x70000ceaf000!W:SRT.br: @288185374:RCV-DROPPED 3 packet(s), packet seqno %812110590 delayed for 0.923 ms
12:45:42.515697/T0x70000ceaf000!W:SRT.br: @288185374:RCV-DROPPED 7 packet(s), packet seqno %812128581 delayed for 5.199 ms

Just to be sure I checked the connection between the two. Using SCP to download a file, It's up to 40 MB.

I will eventually try to checkout the version before the d71aaef - Support SRT experimental bonding commit to see if I have the same results

[maxsharabayko]

Interesting. 🤔
Could you please check srt-live-transmit again, but this time with -buffering 1 command-line option?

(server)
./srt-live-transmit srt://10.0.1.221:10999 udp://10.0.1.236:6000 -buffering 1

(client)
./srt-live-transmit udp://:5000 srt://:10999 -buffering 1

[gangbanlau]

45Mbps was good in my evaluation.
the live source was from FFmpeg and srt-live-transmit(1.4.3 release) act sender and receiver.
ffmpeg.v4.2.3 -stream_loop -1 -re -i ~/1080p120fps.mp4 -c:v libx264 -preset ultrafast -pix_fmt yuv420p -x264opts keyint=50:min-keyint=50:scenecut=-1 -b:v 45M -maxrate 45M -bufsize 45M -c:a aac -ar 48000 -ac 2 -b:a 386k -f mpegts "udp://127.0.0.1:7800?pkt_size=1316&buffer_size=10000000"
srt-live-transmit "udp://127.0.0.1:7800?adapter=127.0.0.1&rcvbuf=67108864" "srt://:56820?mode=listener&latency=120"
the "net.core.rmem_max" was set to 26214400 and SRT latency set to 120ms.
connection was LAN 1Gbps.

I will have a trial srt-test-live later

[mbakholdina]

Hi @gangbanlau,

Do you have any updates regarding testing srt-live-transmit with -buffering 1 applied as @maxsharabayko suggested earlier?