2025-05-26 2:21 AM - last edited on 2025-05-28 3:34 AM by Andrew Neil
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:
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?
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?
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?
2025-05-28 3:24 AM
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
2025-05-30 12:50 AM
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.
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.
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!
2025-06-02 6:35 AM
Thank you very much, I will have a try!