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
