[FR] SRT_MSGCTRL::boundary return to user from srt_recvmsg2

[mGaosi]

We are building a new format of live stream over SRT. Members suggested that I add a data boundary field to the format. I found that there are boundary fields(FF in Data Packet) in SRT protocol and SRT_MSGCTRL 😄, But it's not return to user for now, Why?😣.

I think it's reasonable request with return by SRT_MSGCTRL::boundary of srt_recvmsg2.

Additional context

[maxsharabayko]

The reason is that srt_recvmsg(..) returns the whole message based on those boundary flags. Another API function srt_recv(..) just reads as many bytes as the submitted buffer can take, without any alignment on the message boundary.

[ethouris]

To be precise: both srt_recvmsg and srt_recv do exactly the same thing. That's even explicitly said in the srt.h file.

I'm not sure why exactly the boundary field is in this structure, I think it was necessary for some internal operations. In the API it doesn't make any sense. The FF flags are set for a packet, not a data portion that is being sent.

This is meaningful exclusively in the file/message mode - otherwise FF is always 11. Example:

You call srt_send with a block of 4096 bytes of data. This will be split into three packets:

[0] FF=10 size=1456 [1] FF=00 size=1456 [2] FF=01 size=1184

Only when all 3 packets are received will the srt_recvmsg2 return you the whole 4096 block of data. The only sensible value for boundary to return here would be still 11, same as in all other cases.

The live mode is much like the message mode, except that the message can't exceed the size of one packet's payload, so FF is always 11. In the file/stream mode the data are split into single packets, but each one is defined as individual message and FF is also always 11, just the received data are being glued together as long as available and fit in the user's buffer.

[maxsharabayko]

Probably makes sense to delete those FF fields from the SRT_MSGCTRL respecting ABI version increase.

[ethouris]

I'd rather rename it, while keeping the type. As this field isn't described as to be used for anything, we can first deprecate it, and then reuse for some other purpose. This will not break the ABI compatibility.

[mGaosi]

⚠️We need to keep it. I think users should be given more freedom to use protocol fields, when without affecting the protocol framework.

We are currently studying the integration of SRT into our low-latency applications, e.g. remote broadcasting and production. I think it is well designed at the protocol framework for real-time streams, especially tsbpd and the structure of data packets.

It is friendly to mpeg-ts in live mode(reflected at the libsrt interface), but we think that mpeg-ts has some problems in applications, such as PES reorganization cache delay and excessive header data (4/188) and PES header loss. At least in our applications, we think it needs to be improved.

We plan to use "FF" and "msgno" to make some attempts, so that SRT can achieve performance similar to RTP.(FF like RTP marker, msgno like RTP payload)

Please don’t remove or deprecate it and keep it for now. 🚧

Sorry about reply too late。

[ethouris]

Ok, let me point that out again: if even this field is set to anything that is read from the internal data, there's no way that, if this reflects the FF flags, this would have any other value than 11 in any possible case.

As per msgno, this carries ordinal numbers starting from 1 after connection and wrapping around at some point back to 1 (when reaching the maximum value for 26 bits, it's 0x0400'0000-1). And yes, this can be also used to detect a drop. Although sequence numbers can be as well, they roll over on 31 bits and 0 is allowed.

[maxsharabayko]

Potentially these flags can be repurposed. @mGaosi Looking for further insights once you have a PoC.