<div dir="ltr">

<span style="font-size:12.8px;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">> The best way to handle data loss is to stream over UDP, but also configure your encoder so that ‘key frames’ are sent as a series of ‘slices’, rather than as a single ‘frame’ (or NAL unit, in H.264 terminology).  That way, the loss of a packet will cause only a single ‘slice’ to be lost; the rest of the frame will be received and render OK.  And you’ll avoid the large latency of streaming over TCP.</span>

<br><div><br></div><div>Thanks for the explanation. I have been using UDP without issue for a while now on lower definition cameras. Now that I've started using HD an UHD cameras I'm finding that TCP is the only thing that seems to make it work correctly (or at all).  I've noticed that a number of the largest consumer video manufacturers (Flir, Digital Watchdog, Hikvision, etc.) all seem to use RTSP over TCP by default. Is that more or less designed to combat unknown network circumstances of varying consumers networks, or would there be another reason? </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 12, 2018 at 9:08 AM, 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"><span class="">> I'm now assuming that the mere fact that TCP is a reliable transport protocol is what's ensuring that I get all of the necessary packets to reassemble the image frame.<br>
<br>
</span>This is a common (though understandable) misconception.  TCP is not some ‘magic fairy dust’ that will always prevent data loss.  If your transmitter’s (i.e., server’s) data rate exceeds the capacity of your network, then you *will* get data loss, *even if* you are streaming over TCP.  If you are streaming over TCP (and your transmitter’s data rate exceeds the capacity of your network) then the data loss will happen when the transmitter’s TCP buffer (in its OS) eventually fills up; the server’s TCP ‘send()’ operation will then fail.<br>
<br>
As I have explained numerous times (but which people like to ignore, because the truth is inconvenient to them), streaming over TCP is less data efficient than streaming over UDP, and should really be used only if you are streaming over a network that has a firewall (somewhere between the server and client) that blocks UDP packets.<br>
<br>
The best way to handle data loss is to stream over UDP, but also configure your encoder so that ‘key frames’ are sent as a series of ‘slices’, rather than as a single ‘frame’ (or NAL unit, in H.264 terminology).  That way, the loss of a packet will cause only a single ‘slice’ to be lost; the rest of the frame will be received and render OK.  And you’ll avoid the large latency of streaming over TCP.<br>
<span class=""><br>
<br>
> Lastly, I'm trying to understand how the OutPacketBuffer::maxSize value affects things specifically?  I noticed there was a comment that there was no point in going larger than 65536 bytes, but I've seen a number of posts referencing that for giant 4K frames that you should set that value much higher. If my MTU is 1500 how does changing that to be higher affect transport of my frames? <br>
<br>
</span>First, a UDP packet cannot be larger than 65536 bytes (16 bits in length).  That is the absolute maximum packet size for a UDP (including RTP) packet.<br>
<br>
Second, if your network’s MTU is 1500 bytes, then although you *can* send UDP (including RTP) packets larger than this (up to the maximum of 65536), you *shouldn’t* - because if you do, fragmentation/reassembly will take place at the IP level (inside the sender and receiver’s OS), and you won’t have any control over it.  The loss of a single IP fragment will cause the loss of the entire UDP packet.<br>
<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>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/live-devel</a><br>
</blockquote></div><br></div>