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