<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=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1502162766;
mso-list-type:hybrid;
mso-list-template-ids:978118278 1019904868 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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>This is kind of a shot in the dark, but I have been puzzling over a problem for several days and I am hoping someone here can either rule out Live555 or confirm that it could be contributing.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I am running an RTSP server application based on Live555 that receives live H.264 encoded video from a hardware encoder (which gets its data from a camera), muxes it into an MPEG2-TS and then sends it out as multicast raw UDP data (our customer’s requirements do not allow us to use RTP/RTCP). My setup is as follows. I get a signal from a camera that a new frame is available, which triggers the encoder to encode the frame and then pass it off to my server. After my server muxes the data it writes it to a Linux pipe that is used as the input to a ByteStreamFileSource. The ByteStreamFileSource is used as the input to an MPEG2TransportStreamFramer. The MPEG2TransportStreamFramer is returned by an OnDemandServerMediaSubsession subclass’s createNewStreamSource function.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This has been working very well for us, though we have noticed what we have assumed were decoder buffering problems when viewing the live video. Recently, however, I was analyzing a Wireshark capture and noticed a very strange traffic pattern (see attached image) that I am now convinced has caused most if not all of what we were considering decoder buffering problems.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The graph plots the number of packets received per millisecond. The blue bars indicate the receipt of the signal that a new frame is available from the camera. The red bars indicate the receipt of the resulting multicast stream packets. For about the first quarter of the graph you will see the expected pattern of frame available signal followed by a burst of multicast traffic followed by nothing until the next frame available signal (our camera frame rate is about 7Hz). The remaining three quarters of the graph, however, show the pattern that we get most of the time. After a signal we will occasionally get a burst of multicast traffic, but most often we seem to be limited to one multicast packet every 10 milliseconds or so. Occasionally it will clear up and go back to the expected pattern for a brief time period but then it will return to the bad pattern. It is definitely not a firewall, bandwidth, or networking equipment issue.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Is there anything in BasicUDPSink (which is created by OnDemandServerMediaSubsession for raw UDP transfer), MPEG2TransportStreamFramer, or ByteStreamFileSource that could somehow be limiting the rate at which the UDP packets are sent under any circumstances?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks in advance for your attention and response.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Tyson Wiser<o:p></o:p></p></div></body></html>