> 2. One of the biggest performance hits in my profiling is memcpy (I use an > embedded platform, so memcpy gets pricy fast), much of it due to copying > media buffers. Would you ever consider adding (or consider accepting ;) code > that allows live555 to work in the calling library's buffers instead of its > own?
If I were to go back in time and design the LIVE555 code all over again, then this is something that I might well have done differently. In any case, sometime in the future, when I replace/reimplement the crusty old "groupsock" library (so that network interfaces become proper "FramedSource" and "MediaSink" objects, and we can also support IPv6), I will likely need to rethink the buffering mechanism, otherwise we'll be introducing an extra memcpy when transmitting data over a network socket. But that's for sometime in the future (because any buffering changes will be a *major* change to the code, involving a *lot* more than a simple patch). > (in other words, I give Live555 a pointer to a buffer to send and the size, > rather than memcpy'ing the buffer into live555's space) Unfortunately it wouldn't be quite that simple. Suppose, for example, we're outputting data into a "RTPSink". If the upstream object is providing it a buffer, it would also need to know that it needs to leave sufficient space at the front of the buffer, so that the "RTPSink" can add the 12-byte RTP header (plus any required RTP header extension bytes). (This wouldn't be necessary if the network interface supports 'scatter gather I/O', but we can't assume this in general.) Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
