<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I wasn't planning on contributing to this thread anymore (because I thought that I'd already said everything that I could), but you did bring up one worthwhile point:</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>That would seem to suggest that as soon as frame loss occurs, LIVE555 incurs additional processing</div></div></div></div></div></div></div></blockquote><div><br></div>That is actually correct, because - when the LIVE555 receiving code sees a gap in the RTP sequence numbers - it doesn't know initially whether the 'missing' packet has actually been lost, or whether it has merely been reordered in the network (in which case it will arrive shortly). Allowing for possible packet reordering does, indeed increase overhead (once packet loss is seen).</div><div><br></div><div>You *could* reduce this by not having the code allow for reordered packets at all. To do this, you could call</div><div><span class="Apple-tab-span" style="white-space:pre"> setPacketReorderingThresholdTime(</span>0);</div><div>on your "RTPSource" object(s).</div><div><br></div><div>This *might* improve the performance of your system once it starts seeing packet loss (and thereby reducing the amount of packet loss), but it's not going to eliminate your basic problem: The reason why you're seeing systemic packet loss - despite having large OS socket buffers - is because your CPU is underpowered. You just need to accept the reality that you need a faster CPU, a slower (i.e., lower-bandwidth) incoming packet stream, or both.<br><br></div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></div></div><div>- Bottom line, all I'm doing is inquiring as to whether there might be possibilities to optimize things further upstream. I think that question is especially justified given that VLC, whom I looked at in lieu of not having any other example of a known working model, doesn't follow the testRTSPClient example approach. </div></div></div></div></div></div></blockquote><div><br></div>You keep saying this, but it's either irrelevant, or wrong, depending on what you mean by "the testRTSPClient example approach". As I explained last time, VLC - like other applications that receive a RTP stream - *does* follow the</div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>while (1) {</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Step A: Get a frame of data from a socket;</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Step B: Do something with this frame of data;</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>}</div><div>model. It's true that the person who wrote VLC's LIVE555 interface code chose not to use "RTPSink" subclasses when they wrote their "Step B", but that's irrelevant; it has no effect on performance.</div><div><br></div><div>Several people have written LIVE555-based RTP receiving applications, using "RTPSink"s, that receive a large number of high-bandwith streams concurrently. (If they haven't made their application code public, it's because they're not required to under the LGPL.) But they have sufficiently powerful CPUs. You apparently don't.</div></div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>