<div dir="ltr">I'm seeing the same problem -- and struggling to find an explanation. My set up is:<br><br>1. live555MediaServer serving an mkv file in Docker container<br>2. live555-based RTSP client reading the stream in another Docker container on the same device<div>3. TCP is being used for RTP transport. Because of this, setPacketReorderingThresholdTime is set to 0 (not expecting out of order packets on a TCP connection). </div><div>4. increaseReceiveBufferTo is called with 4MB on the client side.</div><div><br></div><div>I would not expect any packet/frame loss under this scenario, and yet, some is seen, albeit rarely, usually around I-frames (which are around 300kb in size). Usually it'd manifest in a gap between fNextExpectedSeqNo and rtpSeqNo in ReorderingPacketBuffer::storePacket,</div><div><br></div><div>The problem is reproducible within 5-10 minutes, so if you can suggest additional points to add trace statements (haven't taken it deeper than ReorderingPacketBuffer yet), I can generate some additional data.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 21, 2023 at 5:49 PM Ross Finlayson <<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I suspect that - despite the fact that you see no packet loss in the traffic ‘over the wire’ - you are experiencing packet loss inside your (i.e., the receiver’s) OS.  I.e., the receiver’s OS is dropping incoming packets before delivering them to the receiving application (your RTSP client, or “openRTSP”).  You can check this by testing whether you ever get to line 616 in “MultiFramedRTPSource.cpp”.  If you do, then you are seeing a lost packet.<br>
<br>
The problem is likely due to the OS not having enough internal buffering for delivering incoming packets.  “openRTSP” is set up to automatically tell the OS to buffer at least as much as the output file buffer size (your “-b” option); see lines 770-780 in “testProgs/playCommon.cpp”.  You can, if you wish, specify an even larger OS buffer size using the “-B” (i.e., capital-B) option - e.g., "-B 1000000”.<br>
<br>
HOWEVER, your real problem is your IP camera: It is sending key frames as single H.264/H.265 NAL units that are much, much too large for video streaming.  I have explained this several times on this mailing list; most recently here:<br>
        <a href="http://lists.live555.com/pipermail/live-devel/2023-June/022334.html" rel="noreferrer" target="_blank">http://lists.live555.com/pipermail/live-devel/2023-June/022334.html</a><br>
<br>
You should reconfigure your IP cameras to not send each key frame as a single NAL unit, but instead as multiple ’slice’ NAL units.  Then, your video won’t be as sensitive to packet loss.  (Please don’t claim that you can’t reconfigure/fix your IP cameras; you can.  They (unlike the LIVE555 software) are things that you have paid for.  If your IP cameras aren’t doing what you want, you need to tell the manufacturer to fix them.)<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>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
</blockquote></div>