RTSP stream - smoothing video view.

[dcung]

Hi, I use cctv-viewer on Bookworm (Debian 12). The cameras are WiFi cameras, so a couple are located in not in good reception areas - weak signal. Those one are frequently showing black, "End-of-media", "loading" until the streams are available again. They were okay before I updated the firmware of the NVR/Camera.

The security camera vendor has this Android app that displays the same videos/streams. I think it 'suffers' from the same issue (?), but it 'looks smoother' since it doesn't display black screen and just shows last un-updated frame until the next frame is available. It just skips frames, ie you see timestamp jumped, skipping 1-2 seconds sometimes on the weakest WiFi camera. And I think it's actually better after the firmware update.

Is there a way to improve in cctv-viewer by using some more parameters to get similar effect? Sort of showing last frame (or other trick) instead of black, "End-of-media", "loading" looping.

At the moment, I use default ffmpeg options -analyzeduration 1 -probesize 500000 -rtsp_transport tcp

I tried this command on the weak signal - this intermittently does not start. On good signal ones, they are okay. ffplay -x 640 -y 480 -rtsp_transport tcp rtsp://ip:port/ch02/1

Thank you.

[iEvgeny]

Hi! This is good food for thought... Your camera probably has an MJPEG stream that is more resistant to a bad connection.

[dcung]

The camera only provide RTSP stream.

I have observed and tested a little longer. I now do not think it is weaker signal that is causing the issue. The camera locations do not change before and after the firmware update - and I think 2 bars of of 4 is still acceptable signal strength (?).

When the cameras switched from color to b/w (at late afternoon/night) the CCTV-VIEWER issue went away. This makes me think it is something else causing the issue. The firmware update did something I haven't figured out yet.

I am seeing this when I used VLC to test the stream prior to video stopped. MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (250000). 9474 bytes of trailing data will be dropped!

Found this - but I have no idea what it means. https://live-devel.live.narkive.com/rmKHoEfy/fixing-the-total-received-frame-size-exceeds-the-client-s-buffer-size

[iEvgeny]

I can assume that switching to b/w mode reduces the bitrate of the video stream and the connection becomes more stable. Try checking your camera settings and lowering the bitrate as an experiment.

[dcung]

I had to I drop it to 3 fps (default is 15 fps) for cctv-viewer to completely get rid of the "End-of-media", "loading" issue.

The trade off is that vendor supplied app suffers the consequence. Their app can tolerate default fps fluctuations. With the fps now set so low, video does not look good.

Well, at least now I have choices to make... :-) until I find another solution.

Edit: Is there parameters that I can use in the viewport to lower the bitrate while leaving camera fps a little higher?

[iEvgeny]

Also try the options -timeout or -stimeout. Value in microseconds. For example -timeout 30000000

[dcung]

I tried -timeout and then -stimeout. Restarted cctv-viewer each time. Doesn't seem to make any difference.

Thank you for suggestions.