[Sis-mia] RTP Over Space Links - Questions and Next Steps

[Jeremy.Mayer at dlr.de]

Hello Everyone,
Based upon the telecon from a few weeks back, I have some first results of a DTN/RTP-centric video transmission system. I would like to state in advance that this email will be very light on graphs, as I haven't made them yet. However, I figure that this may make your Monday morning slightly lighter.
In short, we built a en/decapsulation system for RTP over the Bundle Protocol, and it looks promising, as you can see from the screenshot below (which was encoded in H.264 at 2mbps, as I don't have H.265 encoding running properly, due to operation system problems).

[cid:image001.png at 01D33627.282A94A0]

In order to make this work, there are several different gears/protocols which all must run together, but that is common to many RTP-based systems. The figure below provides a brief overview of the various components which must work together:
[cid:image002.png at 01D33627.282A94A0]
The RTPSend application listens for multicasted SAP announcement messages, as described in IETF RFC 2974 (https://tools.ietf.org/html/rfc2974 ). These messages contain Session Description Protocol (SDP) data (https://tools.ietf.org/html/rfc4566) which describe the components of a single stream such as the multicast addresses, as well as any SPS/PPS data which H.264/265 requires. The RTPSend application subscribes to the multicast addresses specified by the SDP data and starts to listen for RTP data. Once RTP data has been received, the RTPSend application does some processing in order to allow the concatenation of RTP data into larger bundles (this will be described in detail in coming drafts and the Fall meetings), and sends the bundles, where one destination EID represents a single stream. Therefore, for a RTP program with two separate components, such as audio and video, two EID's are used. Equally importantly, the RTPSend application permutates the SDP data, replacing the IP4 connection parameter with a new one, BP. The address parameter of a BP connection item specifies the EID, which should help for multicast BP transmission. This SDP data is sent every X number of seconds on a third EID. On the receiving side, the RTPRecv application performs the inverse of RTPSend, listening for the SDP messages. Once received, RTPRecv permutates the SDP with "normal" multicast IP addresses and subscribes to all relevant DTN endpoint ID's. The new SDP data (with the normal IP addresses) is sent via SAP, while any RTP bundles are cut into smaller pieces and sent via multicast.

The nice thing about RTP is that, as long as you follow some certain rules (with regards to presentation times, source identifiers, and other stuff which you can get from the RTP header), RTP packets can be an arbitrary size. Most importantly, RTP packets for a single source should be stamped with the same timestamp if (and only if) they must be decoded at the same time. As a result, you can infer that all RTP packets (using H.264 as an example) with the same timestamp belongs to the same frame, and can be dumped out of the receiving application without any internal buffering applied. Also, RTP has the "marker" flag, which specifies that the packet is important for some reason, such as an I-frame. Therefore, you can also end the concatenation, if this bit is set from one packet to the next, even if the timestamp is the same. In my informal testing, I saw bundle sizes from 433 bytes to 30,000. Really tiny RTP packets can be padded, a change which is flagged in the RTP header. Therefore, for things like voice, we can get to the minimum payload size of whichever link we are using.

As can be expected, packet or bundle loss causes various visual impacts, some of which look like modern art (see below). However, some of this loss was due to my testing methodology, and could be removed if you used a more robust network than what I was using.
[cid:image003.png at 01D3362A.2CB45B20]

The encoding and decoding are nothing special, and could be replaced with a hardware solution. Similarly, the usage of SAP provides some simplification, as any new video channels are automatically subscribed to. If SAP is omitted, than SDP files can be written into a directory. For some types of data, such as voice via SIP, SAP is not used but SDP is. The software does not support SIP, but SDP data could be passed from a soft-PBX into the application.

Now, do any members of SIS-MIA have encoders/decoders which support SAP/RTP-using-the-Audio-Video-Profile? I believe that Wowza does, but I am not sure if anyone in MIA is using that operationally. Otherwise, please let me know what encoders/decoders/other constraints people have, so that I can prepare for the meetings. Separately, this is the kind of thing which should probably be written down. Therefore, I will try to start writing a summary for the meetings, but if anybody has specifics which I must dive deeper into, please let me know.

Thanks, and sorry for the huge email,
Jeremy
Jeremy Pierce Mayer
Systems Engineer
GMV INSYEN
Münchener Straße 20 - 82234 Weßling
Ph.: +49 (0) 8153 28 2774
Fax: +49 (0) 8153 28 1885
www.gmv-insyen.com
Visit GMV global
www.gmv.com
GMV Insyen AG, Amtsgericht München, HRB 174844, USt-Id.Nr.: DE261465579
Vorstand: Dave McMahon (Vorsitzender), Austin Gosling, Mattia Moscardino, Miguel Ángel Molina Cobos
Aufsichtsrat: Carmen Mónica Martínez Walter (Vorsitzende)
Registered in Munich, Germany HRB 174844 - VAT No.: DE261465579
Board of Directors: Dave McMahon (Chairman), Austin Gosling, Mattia Moscardino, Miguel Ángel Molina Cobos
Supervisory Board: Carmen Mónica Martínez Walter (Chairman)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-mia/attachments/20170925/1be66332/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 797578 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sis-mia/attachments/20170925/1be66332/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 15541 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sis-mia/attachments/20170925/1be66332/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 598805 bytes
Desc: image003.png
URL: <http://mailman.ccsds.org/pipermail/sis-mia/attachments/20170925/1be66332/attachment-0002.png>