On Thu, Dec 22, 2011 at 6:12 AM, Jeff Shanab <span dir="ltr"><<a href="mailto:jshanab@smartwire.com">jshanab@smartwire.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.  </span></p>
</div></div></blockquote><div><br>I do this as well--all of our media data is reference counted to prevent multiple copies of the same sample.  That said, my embedded processor is slow enough that even a final memcpy into Live555's buffers show up in profiling.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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!</span></p>
</div></div></blockquote><div><br>I had considered this.  For Live555's event-driven model, you'd need a function that gets called when Live555 is done with a sample so the calling application can appropriately free the memory.<br>
<br>In any event, this isn't sounding like it'd be a simple or straight-forward thing to add to Live555, so....not much to discuss. <br></div></div>