<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 13px;">
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">I deal with security cameras and over time, the resolutions have been getting higher.<br>
They love to crank up the quality and resolution to give users that initial: "Wow this camera has a nice picture"<br>
<br>
But our customers are bandwidth sensitive and the first thing we have to do is change the settings on the camera.<br>
For us the number of network packets is not the issue, it is the key frames. This is each image in MJPEG.<br>
(MJPEG is never compressed as much as a key frame on H264 but they are close.)<br>
<br>
I see abut 29K for a 720 x 480 key frame<br>
I have seen 59K for the same on Samsung/GVI <br>
The few cameras giving 1280x1024 always go over.<br>
<br>
To my understanding Live 555 can handle Periodic Intra Refresh, we just need to get the camera manufactures to embrace it.
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF381567"><font color="#000000" face="Tahoma" size="2"><b>From:</b> live-devel-bounces@ns.live555.com [live-devel-bounces@ns.live555.com] on behalf of Roman Gaufman [hackeron@gmail.com]<br>
<b>Sent:</b> Wednesday, April 03, 2013 3:28 AM<br>
<b>To:</b> LIVE555 Streaming Media - development & use<br>
<b>Subject:</b> Re: [Live-devel] OutPacketBuffer::maxSize should be larger by default?<br>
</font><br>
</div>
<div></div>
<div>
<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>
<P> </P>
<P> </P>
<P>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.</P><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; 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" target="_blank">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>
</div>
</div>
</div>
</body>
</html>