[Live-devel] RTSPClient w/significant frame loss

[Ross Finlayson]

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:

> That would seem to suggest that as soon as frame loss occurs, LIVE555 incurs additional processing

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).

You *could* reduce this by not having the code allow for reordered packets at all.  To do this, you could call
	setPacketReorderingThresholdTime(0);
on your "RTPSource" object(s).

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.


> - 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. 

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
	while (1) {
		Step A: Get a frame of data from a socket;
		Step B: Do something with this frame of data;
	}
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.

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.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120323/0f3bf7b2/attachment.html>