<div dir="ltr"><div class="gmail_extra" style>This unfortunately seems more common than not. I have several Axis, Vivotek, Sony, ACTi, D-Link, Lilin and Chinese no brand cameras and they are all generating ridiculously large frames :(</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">Maybe the value can be an argument option without having to recompile? - Or maybe it can be larger but still print warnings unless silenced with --quiet?</div>

</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Also, not sure if you saw my other thread about ProxyServer causing an RTSP client to freeze?</div><div class="gmail_extra"><br><div class="gmail_quote">

On 3 April 2013 02:01, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div dir="ltr"><div>Is there any reason this buffer is so small by default?</div></div></blockquote><div><br></div></div>This value is not 'small'.  On the contrary - it's your cameras that are generating ridiculously 'large' frames :-)</div>

<div><br></div><div>"OutPacketBuffer::maxSize" defines the largest possible 'frame' that a server (or a proxy server) can send.  It's important to understand that each outgoing frame - if it is larger than the RTP/UDP packet size (about 1500 bytes on most networks) - will be broken up into multiple outgoing RTP packets, and the receiver must receive *all* of these packets in order to be able to reconstruct the frame.  In other words, if even one of these packets is lost, then the receiver will lose the *entire* frame.</div>

<div><br></div><div>The default 60000 byte size corresponds to a sequence of about *20* RTP/UDP packets (assuming a standard ~1500 byte MTU).  Internet streaming servers should not be generating frames that are this large.  But if they do, it's useful to have our code print out an error message, telling them that they're doing something that they shouldn't.  (Ditto if you're trying to proxy frames this large; this will not work if the network in front of the proxy server has any significant packet loss.  But if these networks happen to have no packet loss, then you can easily update your code to increase "OutPacketBuffer::maxSize".)</div>

<div><br></div><div>I might end up increasing the default "OutPacketBuffer::maxSize" to 65000 kBytes (because such a frame would be large enough to fit inside a single 65536-byte UDP packet - the largest possible).  But I'm not going to make the default size larger than this, because developers need to be aware of the consequences of having their servers (try to) transmit ridiculously large frames.</div>

<span class=""><font color="#888888"><br><br><div>
<span style="border-collapse:separate;border-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">Ross Finlayson<br>

Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span>
</div>
<br></font></span></div><br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br></div></div>