I concur; IP cameras are supporting higher and higher resolutions, and their maximum encoded frame size (particularly for I-frames) naturally increases in proportion. This can be mitigated by using H.264 slices but not many of them seem to do so.
That’s not necessarily a reason to increase the default though (as long as it can be increased by individual applications); IP security cameras are only one of many applications of this code and presumably most of them involve streams that have been encoded to suit the needs of the average internet user, as opposed to the high-res, high-quality streams typically found in a surveillance scenario. From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Roman Gaufman Sent: Wednesday, April 03, 2013 1:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] OutPacketBuffer::maxSize should be larger bydefault? 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
