cancel
Showing results for 
Search instead for 
Did you mean: 

RTSP Example on STM32N6570-DK: Video Appears in VLC but Is Very Blurry and Low FPS

qiqi
Associate II

Environment:

  • Board: STM32N6570-DK

  • Network: RJ-45 Ethernet cable connected to a router, IP obtained via DHCP: 192.168.10.41

  • Client: VLC 3.0.21 (64-bit) on Windows 10

  • Stream URL: rtsp://192.168.10.41:554/stream


Symptoms:

  • VLC can successfully open the RTSP stream and display video.

  • The video is very blurry, especially during motion, where details are hard to distinguish.

  • The frame rate is very low (VLC statistics show high frame loss and decoding frame rate below 10 fps).


Tried So Far:

  • Increased network caching in VLC to 1000 ms.


Questions:

  1. Why does VLC show blurry and low frame rate video when playing the same RTSP stream? Is it due to a low default bitrate or misconfigured encoding parameters?

  2. In the NetX Duo RTSP example, how can we correctly set H.264 bitrate, IDR (keyframe) interval, and RTCP minimum report interval to ensure clear image quality with minimal frame drops?

  3. What other common factors could cause blurry video and low frame rate (e.g., GOP length, network configuration, VLC settings), and what are the recommended ways to optimize them?Snipaste_2025-05-26_16-56-53.jpgSnipaste_2025-05-26_17-14-39.jpg

3 REPLIES 3
DanielS
ST Employee

Hello qiqi

These are macroblocks.
It looks like a network issue rather than an encoding issue: packets are lost, and the decoder cannot reconstruct the whole image.
The lower frame rate probably also results from a poor network connection.

 

Best Regards,

Daniel

exarian
Associate III

Hi there @qiqi ,

I have a few suggestions to assist with your debugging.

1. Try testing with a known test pattern versus the camera feed, e.g.

Color blocks in the corners with a frame counter in the center, or another known test pattern.

frame_0.bmp

frame_0001.bmp

2. Pipe the video stream over a UART port that you can pick up and have analysed with a tool like FFMpeg,

to verify its free of corruption. 

3. Alternatively just dump all the encoded H264 to RAM, and then after a few seconds extract it and try and play it with FFMpeg.

4. Try enable an internal test pattern on the Camera itself that you can test with.

frame_32.jpg

5. Hook up an ethernet analyser like Wireshark, and then dump the packets and also analyse to pick up where the faults are occuring.

 

I agree with @DanielS , in that you are most likely dropping packets.

 

Testing 1 you can check with a simple fixed pattern. If that doesn't work then there are fundamental problems.

If 1 does work, then perhaps it is a bandwidth problem.

Step 2 will allow you to compare the stream with another source, i.e. you can dump the serial/RAM and at the same time stream via RTSP and be able to compare.

 

Good luck on your debugging!

Thank you very much, I will have a try!