[Live-devel] Frame loss using a slightly modified testRTSPClient‏‏

[Ross Finlayson]

> On Oct 4, 2021, at 1:20 AM, Kfir Shtober <shtober at tokagroup.com> wrote:
> 
> Hi,
> 
> I'm using the test program "testRTSPClient" to stream video from an IP camera's RTSP server (with a slight modification - replacing the dummy sink with the H264VideoFileSink instead).
> 
> With low resolutions, I face no problems streaming the video, however, when the camera is configured with a high resolution (2688x1520) and 20FPS, I noticed frame losses. It's important to mark that I didn't view any logs saying the buffers I use are not large enough.

For RTSP/RTP clients, there are two ‘buffers’ to concern yourself with.  One is the buffer - within ‘user space’ (i.e., your application) - that is used to receive and assemble complete frames (video frames, in this case).  The LIVE555 library reports (with an error message "The input frame data was too large for our buffer size”), if this buffer is too small.  For H.264 video, this can happen if the video ‘key frames’ are too large.  The other, more serious, problem with very large ‘key frames’ is that they become more vulnerable to network packet loss; the loss of just a single RTP packet makes the entire frame unusable.  Therefore you should, if possible, reconfigure your server(s) to break H.264 key frames into multiple ’slice’ NAL units.

The second buffer to concern yourself with is the buffer - within your OS - used for receiving incoming packets on network sockets.  Because this buffer is implemented inside the OS, any overflowing of this buffer is not detected in ‘user space’ (i.e., the LIVE555 library or its application).  Instead, any overflowing of this buffer appears just like network packet loss.

If you’re not seeing any messages on ’stderr’ saying "The input frame data was too large for our buffer size”, then you may be overflowing the second buffer - the internal OS socket buffer.  This is usually large enough to not be an issue, but - in some OSs (e.g. some versions of Linux) - it might be too small by default.  In this case, you can query/set this buffer size using the LIVE555 function calls “getReceiveBufferSize()”/“setReceiveBufferSize()”.  See below...


> The reason I modified the testRTSPClient is for saving the frames to a file and playing it.

You could also - at least initially, for testing - use our “openRTSP” application (see <http://live555.com/openRTSP/>).  “openRTSP”, by default, records incoming video (and audio, if present) data into files.  (For H.264 video, it uses the “H264VideoFileSink” class, as you did.)

In “openRTSP”, you can specify the size of the user-space buffer using the "-b <buffer-size>” option,  And you can specify the size of the OS-internal socket buffer using the "-B <buffer-size>” option.  You may wish to look at how “openRTSP” implements this, and do the same in your own application.



Ross Finlayson
Live Networks, Inc.
http://www.live555.com/