On Wed, Dec 14, 2011 at 1:27 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.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 style="word-wrap:break-word">No, you must send only one frame at a time, because downstream objects expect 'frames', not 'portions of frames'.  "fMaxSize" is the size of the buffer that the downstream object specified when it called "getNextFrame()" on your input source object.  If your frames are larger than "fMaxSize" (which is what you are seeing), then that simply means that your downstream object's buffer is too small.  You need to increase it.<div>
<br></div><div>(Unfortunately, you didn't say what your downstream object is, so until you do, I can't really tell you how to increase the buffer size.)</div></div></blockquote><div><br>Two quick questions:<br><br>
1. One thing another open source project I maintain does is automatically adjust buffer size when a frame too large comes along using realloc. Seems like you field this question often enough that it might be worth consideration to do something similar?<br>
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? (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)<br>
<br>Thanks!.<br></div></div>