SRT payload other than 188-byte TS packets?

[lelegard]

Hello,

In the context of the TSDuck project, I had to extend some input/output plugins to 204-byte TS packets (files, pipes, UDP/IP, pcap captures, etc.) This is request from ISDB-T and ISDB-Tb users. This standard stores modulation information in the 16-byte trailer, not only RS FEC as with DVB modulations. There is a request to propagate this information (and therefore 204-byte packets) in UDP transmission, probably for remodulation later. I don't find that using the 16-byte trailer for meaningful information is a brilliant idea, but many things are not brilliant in ISDB.

As a simple experiment, I tried to convert the SRT input and output plugin to support 204-byte packets, in addition to standard 188-byte packets. I got a few errors and I would like your opinion.

Disclaimer: this is just a question, I don't complain about this behaviour 😉

• Using the message API and SRTT_LIVE.
• Sending 7 packets at a time does not work. I get an error message saying that the max payload is 1316 bytes (exactly 7x188). With 204-packets, the message is 1428 bytes long. If fits in a UDP datagram with some space for headers, remaining below the Ethernet MTU.
• If the SRT payload is limited to exactly 7x188, this is the symptom of some affinity with TS packets.
• Then, I send 6 x 204-byte packets. The send operations complete without errors. However, on the receiver side, srt_recvmsg2() receives nothing. As soon as I transmit 188-byte packets, everything works well again.

I did not spent much time trying to characterise the problem because it was just a test, an experiment, not a required feature.

However, I am curious on the capabilities of SRT to transport something else that 188-byte TS packets.

Maybe, some time in the future, ISDB guys will want to transport their 204-byte packets over SRT, who knows...

[ethouris]

1316 is only the default payloadsize, but you can extend it. Just note that a single packet is limited in size to 1456 (IPv4) or 1444 (IPv6). You need to set this value through the SRTO_PAYLOADSIZE prior to connecting on both sides.

There is a PR prepared that fixes the limit for IPv6, but not yet merged. This isn't an internal problem, just UDP packets will be split and joined by the system, so it would disturb in SRT's statistics and traffic control.

[lelegard]

Thanks @ethouris

You need to set this value through the SRTO_PAYLOADSIZE prior to connecting on both sides.

On both sides? Including the receiver side? The doc for SRTO_PAYLOADSIZE mentions the sender side only.

[lelegard]

OK, thank you @ethouris, it works with SRTO_PAYLOADSIZE set on sender size only.

And since it works, I added 204-byte support to TSDuck plugin srt. I don't know if it will be useful some day, maybe in Japan or Brazil, who knows?