[Live-devel] OutPacketBuffer::maxSize should be larger by default?

[Jeff Shanab]

I deal with security cameras and over time, the resolutions have been getting higher.
They love to crank up the quality and resolution to give users that initial: "Wow this camera has a nice picture"

But our customers are bandwidth sensitive and the first thing we have to do is change the settings on the camera.
For us the number of network packets is not the issue, it is the key frames. This is each image in MJPEG.
(MJPEG is never compressed as much as a key frame on H264 but they are close.)

I see abut 29K for a 720 x 480 key frame
I have seen 59K for the same on Samsung/GVI
The few cameras giving 1280x1024 always go over.

To my understanding Live 555 can handle Periodic Intra Refresh, we just need to get the camera manufactures to embrace it.
________________________________
From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Roman Gaufman [hackeron at gmail.com]
Sent: Wednesday, April 03, 2013 3:28 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] OutPacketBuffer::maxSize should be larger by default?

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?






This message and any attachments contain confidential and proprietary information, and may contain privileged information, belonging to one or more affiliates of Windy City Wire Cable & Technology Products, LLC. No privilege is waived by this transmission. Unauthorized use, copying or disclosure of such information is prohibited and may be unlawful. If you receive this message in error, please delete it from your system, destroy any printouts or copies of it, and notify the sender immediately by e-mail or phone.

On 3 April 2013 02:01, Ross Finlayson <finlayson at live555.com<mailto:finlayson at 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 at lists.live555.com<mailto:live-devel at lists.live555.com>
http://lists.live555.com/mailman/listinfo/live-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130403/cf527aeb/attachment-0001.html>