Add RTP Input support in srt-live-transmit

[premultiply]

For TS transmission it is common practise to add RTP headers (12 bytes) in front of the TS payload of the UDP traffic. So it may be a good idea to add handling for it to SRT apart of manually increasing the SRT chunk size to 1328 bytes.

There may be an autodetection (packet payload size 1316 or 1328 bytes) or manual declaration (udp:// or rtp://) of what is fed to SRT.

This could by used to simply strip the RTP header bytes from the payload before sending it to the receiver through SRT or adjust the default chunk size to 1328 or 1316 bytes.

[ethouris]

Well, that's not exactly a "common practice for TS transmission", it's simply a different protocol. This 12-byte header is not just "to be stripped" - the data contained there should be interpreted and accordingly handled, and it might even be necessary to read some information from the RTCP protocol.

If so, then the best approach would be to create another set of media in stransmit that would handle the RTP protocol, possibly based on the existing UdpSource and UdpTarget classes, but with additional facilities and its own parameter table.

[premultiply]

No, there is no RTCP etc. It is just as I wrote. There are just those additional 12 Bytes which can be simply stripped if not needed or supported. The RTP headers use is just to allow additional measurements and error recovery like detection of packet reordering, packet jitter measurement and detection of packet loss on network layer. Further it provides support for multipath transmission. If the receiver does not support or need those feature it can just strip those bytes.

This has nothing to do with raw transmission with RTSP/RTP and RTCP.

[ethouris]

You really sound like highly underestimating the information that RTP protocol provides. Timely delivery, error detection and reordering detection in particular is what makes it preferred to a dumb UDP. At least the timestamp in the packet is important for synchronization. This should be either turned into the application-supplied timestamp (although this feature needs further development, it doesn't work correctly yet), or the input medium should use some controlled delay so that the times when passing the payload from the RTP input to the SRT output medium is in sync with the timestamps in the RTP header.

Also sequence numbers should be interpreted. Even tho' not much can be done, as packets can't be recovered, unidirectional live streaming protocols usually do FEC for that purpose. If so, the application should be also prepared to do FEC recovery. This requires also extra delay with packet delivery and temporary packet buffering, and while having this, the packets can be explicitly ordered by sequence in this buffer, which will additionally take care of the UDP reordering and phantom packets.

Maybe this isn't the first need feature for that, but at least the infra should be prepared to be able to handle that in future. At least for that reason this rather shouldn't be done by just adding extra functionality to the UDP medium, but a set of two classes should be prepared for that. This what you described deserves only RtpSource class, but I saw already a proposal to have an RTP output in another ticket :)

You can simply copy the UdpSource class to a new RtpSource class, if no common RTP things are needed then just keep it derived from UdpCommon. Then in its Read method simply skip these 12 bytes, just for the beginning. Then follow the way how this UdpSource class is ultimately bound to udp scheme name in the URI handler and just repeat this for rtp. Probably you'd have to update also the UriParser::Type enum and add the initialization item in UriParserInit.

[premultiply]

No I know very well which features RTP provides if devices or applications support it properly. But as first step to ingest such streams to stransmit you could start with detecting and stripping the 12 Byte header...

[ethouris]

That's still very good. And that would be the purpose of the RtpSource class. The first version would do exactly this, and beside that it would be an exact copy of UdpSource class. Just the code would be better prepared for any future enhancements in RTP handling.

Just at the end of the Read method instead of return data, you'd do return bytevector(data.begin()+12, data.end());.