"vector subscript out of range" occurs when FEC is enabled

[hayaTMC]

When connecting to a Linux server from a Windows client with FEC enabled, the error in the attached image occurs on the client side.
When FEC is disabled, files can be sent and received without any problems.
What do you think is the cause?

I have also attached the call history from Visual Studio.

The execution environment is as follows.
SRT: Ver.1.5.3
SERVER: Linux Ver.6.1.30
CLIENT: Windows10 Pro 22H2

[ethouris]

As I review the code there, such a thing should be impossible, unless the payload_size parameter (the real size of the payload in the data packet) is somehow greater than payloadSize(), which is deemed to be the maximum possible payload size. Could theoretically think of being payload_clip vector not resized to this maximum size, but this is done always and in the beginning of the configuration.

Could you show the exact configuration for SRT client, including IP version (IPv4/IPv6) in use?

[hayaTMC]

Thank you for your answer.

The SRT client configuration is as follows.
No SRT-API errors have occurred.

IP: IPv4
Network: Wired LAN, 1000Base-T
SRT client code:
srt_startup();
SRTSOCKET srtSock = srt_create_socket();
srt_setsockopt(srtSock, 0, SRTO_TRANSTYPE, SRTT_FILE, typeLen);
srt_setsockopt(srtSock, 0, SRTO_PACKETFILTER, "fec,cols:10,rows:1,arq:onreq,layout:staircase", filterLen);
srt_setsockopt(srtSock, 0, SRTO_LATENCY, latency, latencyLen);
srt_connect(srtSock, serverAddr, serverAddrLen);

[ethouris]

Well, that's weird. Why do you use the SRTT_FILE transtype? FEC is intended for use exclusively with LIVE mode.

Even weirder is that you have established the connection, which may only mean that the service side has also set this mode. Do you have also information about the server side configuration?

[hayaTMC]

Well, that's weird. Why do you use the SRTT_FILE transtype? FEC is intended for use exclusively with LIVE mode.

FEC is enabled because we expect the network to be unstable wireless in the future.
Perhaps it is necessary to optimize SRTO_PAYLOADSIZE according to the FEC setting?

Even weirder is that you have established the connection, which may only mean that the service side has also set this mode. Do you have also information about the server side configuration?

The server side configuration is as follows.
srt_startup();
SRTSOCKET srtSock = srt_create_socket();
srt_setsockopt(sai.srvSock, 0, SRTO_TRANSTYPE, SRTT_FILE, typeLen);
srt_setsockopt(sai.srvSock, 0, SRTO_PACKETFILTER, "fec", filterLen);
srt_bind();
srt_listen();
srt_accept();

[ethouris]

I understand that the network can be unstable and with varying parameters, but what's wrong with just using the default loss recovery mechanism through retransmissions?

FEC is a mechanism normally used in protocols that offer no feedback (like pure UDP); in SRT it is useful, but only if you have strict time requirements and RTT is so high that retransmission would require very high latency. In case of file-type transmission you usually don't care about the timely delivery, so retransmission should suffice, even if you use the satellite link.

[hayaTMC]

Thank you for your advice.
Testing was necessary to investigate the effectiveness of FEC.

There are two points to confirm:
Am I correct in assuming that ARQ functions by default for file types?
Am I correct in assuming that the built-in filter (fec) is not supported for file types?