Performance issues when trying to view an network stream

[Azsde]

Hello everyone,

I am trying to turn my raspberry pi 3 into a security camera, to do so I am simply using the following command on the raspberry pi:

Code: Select all

libcamera-vid --width 1920 --height 1080 -t 0 --inline -o - | cvlc stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/stream1}' :demux=h264

As you can see, it uses VLC to create the RTSP stream.

Then on my laptop, to view the stream, I use the following command:

Code: Select all

vlc rtsp://<ip of my raspberry pi>:8554/stream1

The stream is viewable BUT performances are terrible, there is a lot of delay (I don't mind the delay that much) and the image is sometimes "blocky":



When I use ffplay to play the same stream, it works great (ffplay can receive more arguments to reduce the delay):



This is the ffplay command:

Code: Select all

ffplay rtsp://<ip of my raspberry pi>:8554/stream1

Here is a video illustrating the difference between ffplay and VLC: https://i.imgur.com/EbYpfQg.mp4

As you can see, the difference is quite huge, since ffplay can play the video feed without any issues (besides the delay which can be improved by tweaking some parameters), I assume that everything on the raspberry side is ok, and that the issue comes from my VLC client.

I tried with an UDP stream as well:

• Raspberry "server" : libcamera-vid -t 0 --width 1920 --height 1080 --inline -o udp://CLIENT-IP-ADDRESS:1234

• VLC client: vlc udp://@:1234 :demux=h264

• fflplay client: ffplay udp://@:1234

The performances are the same.

This issue also happens on Windows but using the Android App, everything works fine.

Is there a log I can provide to help resolve this issue ?

I thank you in advance for your help.

Regards,

Azsde.

I thank you in advance.

Regards,

[rom1v]

A h.264 raw stream has no timing information, but VLC want to timestamp every frame, so it will give a frame-rate by default of 25 (can be configured by --h264-fps=…, but that won't perfectly match your stream anyway). In addition, it will add buffering and adjust it whenever a packet is lost. Hence the delay.

I worked on a "0latency" PoC which displays the frames as soon as possible, you can read about it here if you're interested: https://code.videolan.org/rom1v/vlc/-/merge_requests/20

[Azsde]

Interesting, but the main issue here is the ''blockiness'' of the video.

The delay is something I could live with, the ''corrupted'' video not so much.

It seems that this issue did not happen on earlier version of VLC, i will need to do some testing to figure out which version introduced the issue.