<div dir="ltr"><div><div><div><div><div><div><div><div>I concour.<br><br></div>Here are some data points. <br></div> I have been streaming 4K cameras recently one of them is actually 4000x3000 resolution.<br></div> A Sony is the normal 3840 x 2150 streaming at 30 fps, It puts out 5 slices for each frame type. I,P,B Slices also enable us to parallelize the decoding so it can be reasonably decoded. The keyframes are indeed 250K+ <br></div> A 12MB (4000x3000) Samsung also streams at 30 fps but no slices. keyframes are large, I am not near my measurements so I cannot say but I would not be surprised if they hit 160K.<br></div><div> A Panasonic does not have slices either but it has a powerful processor on board.<br></div><div><br></div> The Sony has larger frames than the Samsung but is by far smoother and easier to stream, less resources and better at maintaining the framerate. Rock solid timestamps not varying more than a ms, not dropping either. <br><br></div> All 3 of these as well as some panoramic cameras that use slices and stitch the images into a ridiculously wide view, have been successfully streamed at full framerate on a single thread in debug mode or on low end dedicated PC.s<br><br></div>TCP has overhead and if combined with any network latency, I think it taxes the camera's internal buffer and it will drop framerate. I was surprised by this, really sensitive to latency. I am guessing that it must hold onto packets until they are acked and if there is delay the queue is forced to hold more.<br><br></div>Measure your network latency and try UDP transport if you think you are hitting a wall. <br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 30, 2015 at 7:06 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> I have a 40 Mb/s 1920x1080 H264 source video file running at 30 frames per second. So each frame is roughly 160 kB being bursted out every 33ms.<br>
<br>
I doubt that *each* frame is 160 kBytes - presumably only the ‘key frames’. But in any case, with key frames this large, I recommend that you reconfigure your encoder so that each key frame is encoded as a sequence of ’slice’ NAL units, rather than as a single NAL unit.<br>
<br>
People often have trouble streaming H.264 video with extremely large I-frames, if each I-frame gets encoded as a single NAL-unit. The problem with this is that these NAL units get sent as a (very long) sequence of RTP packets - and if even one of these RTP packets gets lost, then the whole NAL (I-frame in this case) will get discarded by the receiver; see<br>
<a href="http://lists.live555.com/pipermail/live-devel/2011-December/014190.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2011-December/014190.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2012-August/015615.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2012-August/015615.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2013-May/016994.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2013-May/016994.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2014-June/018426.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2014-June/018426.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2014-June/018432.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2014-June/018432.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2014-June/018433.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2014-June/018433.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2014-June/018434.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2014-June/018434.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2015-March/019135.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2015-March/019135.html</a><br>
<a href="http://lists.live555.com/pipermail/live-devel/2015-April/019228.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2015-April/019228.html</a><br>
For streaming, it’s better to encode large I-frames as a sequence of ‘slice’ NAL units.<br>
<br>
Ross Finlayson<br>
Live Networks, Inc.<br>
<a href="http://www.live555.com/" rel="noreferrer" target="_blank">http://www.live555.com/</a><br>
<br>
<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" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div><br></div>