[Live-devel] RTSPClient w/significant frame loss

[Brad O'Hearne]

Just in case anyone else was actually following this thread, I thought I'd make my final post in this thread the conclusion of the matter: 

- Setting the packet reordering threshold time very low had a noticeable impact. I originally tried setting it to zero, but oddly my benchmarks  were slightly slower when setting this threshold to 0.0 than they were when it was set to 0.001 -- so I settled on the latter. My frame rate noticeably increased (by 25-30+%) when this change was made, so I suppose the moral of the story is that the further this reordering threshold gets from zero, packet loss begets more packet loss. 

- CPU power also made a significant difference. I shifted from testing on iPad 1 to the new iPad (3rd generation), and that bumped my frame rate 30-40% too. 

Both together were significant. After adding back in the rest of my decoding process, with some additional optimizations (which weren't part of this thread discussion), I'm now getting 27-30fps on an iPad 3rd generation, full rtsp -> LIVE555 -> ffmpeg -> iPad screen. So for anyone following along at home, it can be done. 

Cheers, 

Brad

Brad O'Hearne
Founder / Lead Developer
Big Hill Software LLC
http://www.bighillsoftware.com

On Mar 23, 2012, at 2:01 PM, Ross Finlayson wrote:

> 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/
> 
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120324/faf09b6d/attachment-0001.html>