with fec,the max playload to 1452bytes

[chllcy]

Hi,I test with fec,but encounter problem with playload size。send with 1456 bytes。1500MTU。
the log below：
Due to filter-required extra 4 bytes, SRTO_PAYLOADSIZE fixed to 1452 bytes

is it need to change max payload size(m_iMaxSRTPayloadSize) to 1452 if with fec feature at handshake？

[ethouris]

Did you set the payload size using SRTO_PAYLOADSIZE?

Might matter the order in which you set options. When you set payloadsize first and packetfilter second, the packetfilter setting should cut the payloadsize. In the opposite order, it should disallow you to set payloadsize that big.

Note also that there's #1130 PR to remove this option completely. The actual maximum payload size is then managed internally and allowed as maximum in the beginning.

[chllcy]

with send 1456 bytes payload, fec rebuild will report error.
FEC: DECLIPPED length '1456' exceeds payload size. NOT REBUILDING.

[ethouris]

Yes, definitely this is an internal error that shouldn't happen.

How did you configure the socket then? For me it looks as if the payload size was somehow allowed to be set to 1456, which shouldn't be allowed when you also configured FEC. Some check looks like have been bypassed.

[ethouris]

@chllcy Could you please describe the exact way how you made the test? It looks for me as if you have forcefully set the payloadsize option to 1456 on the sender, and then you tried to send 1456 bytes of data per packet. This should be rejected as error, and looks like it somehow didn't. It would be nice if you could repeat this test with using the version from #1130 PR at least on the sender side and confirm or deny as to whether this fixes the problem.

[chllcy]

yes I hard code for 1456 on the sender and receiver。is it necessary to fix this problem？
I will try the version from #1130 PR。

[ethouris]

What should happen is that when you configure FEC on the connection and try to send 1456 bytes through that connection, your sending function should report error and reject sending. The version from that PR simply disables the SRTO_PAYLOADSIZE option (it's treated as deprecated and ignored), but still it allows you to send the maximum possible number of bytes through one sending call. Of course, the maximum is 1456 in a normal situation, but it's decreased by 4 when you configure FEC. Whether the control of the maximum single sending size is in force or not, it depends this time on SRTO_TRANSTYPE option.

[kgbook]

The same issue.

I set SRT_LIVE_MAX_PLSIZE to SRTO_PAYLOADSIZE options both on sender and receiver side, and enable FEC with SRTO_PACKETFILTER option.

The receiver receive no video frame, and complaint that "payload size: 1456 exceeds maximum allowed 1452".

log :

E  [SrtLogCallback:42]:[checkTransArgs#119]14:46:11.044730/VideoEncoder*E:SRT.cc: LiveCC: payload size: 1456 exceeds maximum allowed 1452
E  [input:89]:srt_sendmsg failed, reason: Operation not supported: Incorrect use of Message API (sendmsg/recvmsg)
E  [SrtLogCallback:42]:[checkTransArgs#119]14:46:11.045254/VideoEncoder*E:SRT.cc: LiveCC: payload size: 1456 exceeds maximum allowed 1452
E  [input:89]:srt_sendmsg failed, reason: Operation not supported: Incorrect use of Message API (sendmsg/recvmsg)

[ethouris]

Is the same thing happening if you don't change the SRTO_PAYLOADSIZE option?

[kgbook]

Is the same thing happening if you don't change the SRTO_PAYLOADSIZE option?

the issues fixed with no more than 1456-4 bytes payload. it works.

I will test tomorrow if not change SRTO_PAYLOADSIZE option.

[ethouris]

There's #2677 prepared to fix some of these problems. This constant - SRT_LIVE_MAX_PLSIZE will be deprecated (it's IPv4-specific, which isn't exactly clear).

The actual maximum payload size should be calculated this way:

• The maximum unit is the value of SRT_MSS option (default: 1500)
• Minus 20 bytes for IPv4 or 32 bytes for IPv6 header
• Minus 8 bytes for UDP header
• Minus 16 bytes for SRT header
• Optionally, minus 4 bytes for FEC packet filter
• Optionally, minus 16 bytes for auth tag (if you use cryptomode AES-GCM)

Without these optionals you have 1456 for IPv4 and 1444 for IPv6.