Srt: SRT not recovering from corrupted/lost packets

[aamirrad]

I am not sure if this is an issue, not supported feature, or something I am doing wrong.
Here is my setup.
UDP->SRT->UDP it works fine and I see the transmission between client and server.

But when I corrupt or drop an input UDP packet, I expect the SRT protocol to recover and not see those issues on the output. But I see those issues and SRT is not recovering.

I am under impression that this should be handled by the SRT, but I can't have it to work. Any help would be appreciated.

[ethouris]

If I understand correctly, if you have not exactly clean input on UDP as a source in stransmit call, then the SRT library has no clue about it. SRT states that whatever goes to the input is simply a stream of data to send and correct at that point.

What is exactly the source from which you have the UDP transmission that you feed into stransmit as input?

[aamirrad]

What I am trying to do is that I have a clean UDP source that I first send it to a small application that I wrote to drop some of the packets or even corrupt some other packets and then send those into stransmit (Shown below).

Clean UDP -> app to corrupt or drop some packets -> stransmit -> Output

I expected the output to be clean, but from what I understood from your comment is that, input needs to be clean. However, for any reason, if a packet gets lost or corrupted between the client and server where the SRT transmission is happening, your protocol should recover? Is that right?

[ethouris]

SRT transmits simply whatever you stream to the input. Whatever happens before feeding to SRT is out of SRT's interests.

[aamirrad]

Ok I modified my stransmit (server) so that it drops 1 packet before sending the packets to client. Shouldn't the output of the client (UDP) be clear with no hit?

I see the output gets hit and has issues.

I am just trying to see how and what SRT recovers in the case of packet loss and jitter.

[ethouris]

If you are trying to see how SRT recovers from lost packets, you have to enforce packet drop on the way between two SRT endpoints. To ensure a clean transfer, it's best to not use UDP in this test at all.

The only way to achieve it that I'm aware of is to shape the traffic using some system tools. You can't influence the fate of a UDP packet that a user code has sent using sendmsg (which happens in SRT), this must be somehow done by the system. On Linux, for example, you can use the tc tool with netem program. Then you can send given stream first through UDP and see how it gets corrupted, and then using the same network path send the stream using SRT.