I'm seeing the same problem -- and struggling to find an explanation. My set up is:
1. live555MediaServer serving an mkv file in Docker container 2. live555-based RTSP client reading the stream in another Docker container on the same device 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). 4. increaseReceiveBufferTo is called with 4MB on the client side. 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, 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. On Thu, Dec 21, 2023 at 5:49 PM Ross Finlayson <finlay...@live555.com> wrote: > 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. > > 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”. > > 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: > > http://lists.live555.com/pipermail/live-devel/2023-June/022334.html > > 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.) > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel@lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel >
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
