<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

<meta name="Generator" content="Microsoft Word 14 (filtered medium)">

<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}

o\:* {behavior:url(#default#VML);}

w\:* {behavior:url(#default#VML);}

.shape {behavior:url(#default#VML);}

</style><![endif]--><style><!--

/* Font Definitions */

@font-face

        {font-family:Calibri;

        panose-1:2 15 5 2 2 2 4 3 2 4;}

@font-face

        {font-family:Tahoma;

        panose-1:2 11 6 4 3 5 4 4 2 4;}

/* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

        {margin:0cm;

        margin-bottom:.0001pt;

        font-size:11.0pt;

        font-family:"Calibri","sans-serif";}

a:link, span.MsoHyperlink

        {mso-style-priority:99;

        color:blue;

        text-decoration:underline;}

a:visited, span.MsoHyperlinkFollowed

        {mso-style-priority:99;

        color:purple;

        text-decoration:underline;}

p.MsoAcetate, li.MsoAcetate, div.MsoAcetate

        {mso-style-priority:99;

        mso-style-link:"Balloon Text Char";

        margin:0cm;

        margin-bottom:.0001pt;

        font-size:8.0pt;

        font-family:"Tahoma","sans-serif";}

span.EmailStyle17

        {mso-style-type:personal-compose;

        font-family:"Calibri","sans-serif";

        color:windowtext;}

span.BalloonTextChar

        {mso-style-name:"Balloon Text Char";

        mso-style-priority:99;

        mso-style-link:"Balloon Text";

        font-family:"Tahoma","sans-serif";}

.MsoChpDefault

        {mso-style-type:export-only;

        font-family:"Calibri","sans-serif";}

@page WordSection1

        {size:612.0pt 792.0pt;

        margin:72.0pt 72.0pt 72.0pt 72.0pt;}

div.WordSection1

        {page:WordSection1;}

--></style><!--[if gte mso 9]><xml>

<o:shapedefaults v:ext="edit" spidmax="1026" />

</xml><![endif]--><!--[if gte mso 9]><xml>

<o:shapelayout v:ext="edit">

<o:idmap v:ext="edit" data="1" />

</o:shapelayout></xml><![endif]-->

</head>

<body lang="EN-US" link="blue" vlink="purple">

<div class="WordSection1">

<p class="MsoNormal">Hello Everyone,<o:p></o:p></p>

<p class="MsoNormal">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. <o:p></o:p></p>

<p class="MsoNormal">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).<o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal"><img width="1280" height="720" id="Picture_x0020_1" src="cid:image001.png@01D33627.282A94A0"><o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">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:<o:p></o:p></p>

<p class="MsoNormal"><img width="543" height="220" id="Picture_x0020_2" src="cid:image002.png@01D33627.282A94A0"><o:p></o:p></p>

<p class="MsoNormal">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 (<a href="https://tools.ietf.org/html/rfc4566">https://tools.ietf.org/html/rfc4566</a>)

 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. <o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">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.<o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">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.<o:p></o:p></p>

<p class="MsoNormal"><img border="0" width="1280" height="720" id="Picture_x0020_3" src="cid:image003.png@01D3362A.2CB45B20"><o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">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.<o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">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.<o:p></o:p></p>

<p class="MsoNormal"><o:p> </o:p></p>

<p class="MsoNormal">Thanks, and sorry for the huge email,<o:p></o:p></p>

<p class="MsoNormal">Jeremy<o:p></o:p></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Jeremy Pierce Mayer<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Systems Engineer<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">GMV INSYEN<br>

M�nchener Stra�e 20 - 82234 We�ling<br>

Ph.: +49 (0) 8153 28 2774 <br>

Fax: +49 (0) 8153 28 1885<br>

www.gmv-insyen.com <o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Visit GMV global

<br>

www.gmv.com<o:p></o:p></span></p>

<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">GMV Insyen AG, Amtsgericht M�nchen, HRB 174844, USt-Id.Nr.: DE261465579

<br>

Vorstand: Dave McMahon (Vorsitzender), Austin Gosling, Mattia Moscardino, Miguel �ngel Molina Cobos<br>

Aufsichtsrat: Carmen M�nica Mart�nez Walter (Vorsitzende)<br>

Registered in Munich, Germany HRB 174844 - VAT No.: DE261465579<br>

Board of Directors: Dave McMahon (Chairman), Austin Gosling, Mattia Moscardino, Miguel �ngel Molina Cobos<br>

Supervisory Board: Carmen M�nica Mart�nez Walter (Chairman)<o:p></o:p></span></p>

<p class="MsoNormal"><o:p> </o:p></p>

</div>

</body>

</html>