[Live-devel] Randomly I Frame missed for high bitrate cameras

[Alex Agranovsky]

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 <finlayson at 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 at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20231230/d3e9c784/attachment.htm>