[Live-devel] Live555 EventLoop crash

[Jeff Shanab]

Above the live 555 libs I have my own frame class. It is a simple RAII data class with payload, a bit of byte alignment, and some metadata like size and type. I use a reference counted pointer to this. This allows my multiple subscribers to keep lists of pointers to frames, they each have their own list and not worry about memory management and there is minimal memcopying around.  Another important detail is this makes sure he who created the memory deletes the memory. This is to keep windows happy, If memory is allocated in one heap and attempted to delete it from code running in a different heap, windows throws an access violation, especially in debug mode!

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Wednesday, December 21, 2011 10:54 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Live555 EventLoop crash

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/

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1890 / Virus Database: 2109/4695 - Release Date: 12/21/11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111222/82c89bc4/attachment-0001.html>