The output UDP will become unstable in about three days by using srt-live-transmit.exe to transmit it.

[Ping-Chih]

The SRT caster side:
srt-live-transmit.exe udp://228.0.1.4:8004?adapter=10.10.10.11 srt://220.130.142.139:5204?adapter=192.168.1.5

The SRT receiver side:
srt-live-transmit.exe srt://:5204?adapter=192.168.0.162 udp://192.168.0.162:9998?adapter=192.168.0.162

There is a problem with SRT_1.4.1 using srt-live-transmit.exe to transmit UDP.

The output UDP on the receiver side will become discontinuous in about three days, and its waveform will look like a row of isolated pulses if we use StreamXpert to see the UDP signal.

We tried restarting the srt-live-transmit.exe on the caster side and the srt-live-transmit.exe on receiver side individually to see if the output UDP signal would get back to continuity, and we found that only restarting the receiver will work, again making the UDP signal continuous and a linear waveform with small oscillations amplitudes on StreamXpert.

How to make the output UDP stable for a long time?

The stable status of the output UDP in the beginning of connection (the video is normal on VLC):

The output UDP starting to be unstable in about 3 days (the video is abnormal on VLC):

[ethouris]

First of all: did you measure the UDP signal on both sides - the source device and destination device? This is in order to rule out any reasons for this to happen at any place BEFORE srt-live-transmit.

Second - srt-live-transmit has a known problem of not reading fast enough in case of high bitrates; not sure if this is the case here, but I think it might help to use a workaround intended for that case: enlarge the received buffer by adding appropriate rcvbuf attribute for UDP URI. You can find more info here.

[Ping-Chih]

The SRT caster side:
srt-live-transmit.exe udp://228.0.1.4:8004?rcvbuf=67108864?adapter=10.10.10.11 srt://220.130.142.139:5204?adapter=192.168.1.5

The SRT receiver side:
srt-live-transmit.exe srt://:5204?adapter=192.168.0.162 udp://192.168.0.162:9998?rcvbuf=67108864?adapter=192.168.0.162

The source UDP has been confirmed on the source device. There is no problem with the caster source. The bitrate of the transmitted UDP is 10 Mbps.

The stability of the output UDP won't last for one day once rcvbuf=67108864 is added, and there will be nothing seen on VLC, but it is still normal on the caster's VLC.

The SRT caster: (stable)

The SRT receiver: (It was as stable as the caster UDP source in the beginning, but became unstable in one day after adding rcvbuf to it. On the other hand, without rcvbuf added the stability can last three days, but still not long enough. )

[Ping-Chih]

The video quality drops along with the unstable stream. Is this an instinctive issue to be solved? There is not any lost or dropped packets reported.

[ethouris]

If there are no lost or dropped packets reported (you might also take a look at possible error logs appearing on standard error output), then please first make sure that your stream isn't damaged BEFORE entering the SRT link.

If the UDP link is to be utilized at the exact same machine where the stream is generated, I'd advice you sending the stream to srt-live-transmit through the pipe (using file://con as source), and similarly output the stream on the receiver side. The Windows platform is also known of being able to lose UDP packets even within the frames of a single machine.

[J-Rogmann]

Hello @Ping-Chih

I had a srt-live-transmit running on windows for more than 7 days and did not see any dropped packets on the SRT path. Also the UDP output was looking good to me, but I didn't had detailed statistics on the output.

I just re-started the test and added ?rcvbuf=67108864 to the URI like you did and will have a closer look at the UDP output this time. I'll let you know, as soon as I find something.

[maxsharabayko]

See also #1566

[J-Rogmann]

Hello @Ping-Chih

It's now running again for almost 4 days and still both outputs are okay and without any glitches or lost packets. I run 2 times srt-live-transmit in parallel, 1.4.1 and 1.4.2 version.

Command line sender:

.\srt-live-transmit.exe -s 5000 -statsout stats-142-udp2srt.log -pf csv -f udp://:8000?rcvbuf=67108864 srt://:8001

Command line receiver:

.\srt-live-transmit.exe -s 5000 -statsout stats-142-srt2udp.log -pf csv -f srt://192.168.2.49:8001?rcvbuf=67108864 udp://192.168.2.49:8002

I also attached a screenshot, where you can see, that the used network bandwidth is straight as line. I don't see anything going up and down. Looks really stable to me.

Are you trying this on a local machine, or between two computers? Can you try to use unicast instead of multicast, just to isolate a possible error.

[J-Rogmann]

Hello @Ping-Chih

do you have any updates on this ticket is it solved and can be closed.
Please let us know, if you still need help or how you solved it, in case you found an issue.

best regards,
Justus

[mbakholdina]

The issue isn't reproducible on our side. Closing the ticket. Feel free to reopen it in case of further questions.