datarhei
Write Buffer Not Always a Multiple of 188 with SRT Version 4
When using the gosrt library with SRT version 4, I encountered an issue where the Write buffer does not always maintain a length that is a multiple of 188, even though the writeBuffer size is set to 1316. This issue occurs when writing to the buffer, leading to problems with some server implementations.
My server (using SRS) reports the following error when this happens:
[2025-03-20 14:52:07.901][ERROR][76115][996376t3][4] srt serve error code=6006(SrtConnection)(SRT connection level error) : srt: process packet : invalid ts packet len=148
It seems that the buffer occasionally produces packets with a length that is not a multiple of 188, which violates the TS (Transport Stream) packet size requirements.
Steps to Reproduce Set up a server using SRS (Simple Realtime Server). Use gosrt to send data with writeBuffer set to 1316 and SRT version 4. Observe the server logs. Occasionally, errors like the one above will appear. Expected Behavior The Write buffer should always maintain a length that is a multiple of 188, as this is required for TS packet compliance.
Actual Behavior The Write buffer intermittently produces packets that are not multiples of 188 in length, causing compatibility issues with servers like SRS.
Environment gosrt version: Latest at the time of writing Go version: 1.20+ Server: SRS (Simple Realtime Server) OS: [Your OS details, e.g., Ubuntu 20.04] Additional Context This issue could potentially lead to interoperability problems with other SRT servers that expect TS packets conforming to the 188-byte packet size standard.
Please let me know if you need further details or if I can assist in reproducing the issue.
Hello, SRT is meant to be completely independent from MPEG-TS, therefore, the 188-byte grouping should not be placed in this library, but in downstream apps / libraries.
Therefore, this is not a bug and should be closed.
My previous comment was inaccurate. The question is that SRS is based on the SRT reference implementation, therefore there's some kind of difference between this library and the reference one, with respect to packet splitting, that should be investigated.
I still believe that splitting packets in 188 packet-long units should not be performed unless mentioned in the specification or in the reference implementation though.
I couldn't find anything in the specification that requires the data length to be a multiple of 188 bytes. But as SRT is very mpegts oriented (but not limited to) it might make sense to enforce the data length to be a multiple of 188 bytes to improve compatibility with a configuration option.
