[Live-devel] Live555 EventLoop crash

Ross Finlayson finlayson at live555.com
Wed Dec 21 20:53:31 PST 2011


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

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


More information about the live-devel mailing list