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 :(
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? Also, not sure if you saw my other thread about ProxyServer causing an RTSP client to freeze? On 3 April 2013 02:01, Ross Finlayson <finlay...@live555.com> wrote: > Is there any reason this buffer is so small by default? > > > This value is not 'small'. On the contrary - it's your cameras that are > generating ridiculously 'large' frames :-) > > "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. > > 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".) > > 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. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
