2025-04-23 11:52 AM
Hi STM Team,
We are working with a custom board based on the STM32MP157DAC.We are facing a video lag issue when trying to play a video file from Qt application 6.5.3 using media player.
Even reducing the frame rate had no effect.
But if we use gst-play we are able to play the video without any lag or delay.
Do we need to enable any HW accelerator to play the video over GPU from Qt application? how we achive the same video output without lag when played using gst-play from Qt application.
Thanks.
2025-06-27 3:05 AM
Hello @adnan_pasha ,
thank you very much for your example. It has also worked on my side on STM32MP257.
I will investigate why gstreamer reference example does not work as it is.
And I will also use a gstreamer command compatible with MP25 video hardware accelerator and check the CPU load in that configuration. We will see if we can get some clue for your initial question on MP157.
BR,
Philippe.
2025-06-27 3:14 AM
Hi @PPAGE.13
Good to hear it’s working for you.
I tried setting the EGLFS environment variables as you suggested, but I still observe high CPU usage when playing a video file.
Also, I noticed that there’s no framebuffer device present on my system. We're using the MIPI-DSI subsystem for display, which relies on DRM drivers. Could the absence of a framebuffer be contributing to the issue?
root@stm32mp15-disco:~# ls -l /dev/fb*
ls: cannot access '/dev/fb*': No such file or directory
Thanks.
2025-06-27 3:50 AM
Hi @PPAGE.13
export QT_QPA_PLATFORM=eglfs
ediaplayroot@stm32mp15-disco:~# ./mediaplayer
Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, but has failed to switch to one.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
Failed to move cursor on screen DSI1: -13
Failed to move cursor on screen DSI1: -13
SerialWorker created in thread: QThread(0x667ff8)
ScriptExecuter created, worker thread started.
Serial port opened successfully in thread: QThread(0xbedc1aa0)
Could not set DRM mode for screen DSI1 (Permission denied)
Could not queue DRM page flip on screen DSI1 (Permission denied)
[Warning] Serial port warning state: false
Object created for URL: QUrl("qrc:/FirstPage.qml")
Successfully found videoItem
GStreamer Error: Required property 'widget' not set
Could not queue DRM page flip on screen DSI1 (Permission denied)
I get permission denied if i set QT_QPA_PLATFORM=eglfs and run my application but if i set it to wayland it works
do you have any idea why this might be happening ?
2025-06-27 6:06 AM
Hi @adnan_pasha,
I made a few measurements.
- on STM32MP157F.
With your gstreamer example, I confirm the 140% CPU load in Wayland configuration. I have tried EGLFS conf, but I get the same number.
I also tried a standard MediaPlayer with FFMPEG, I got a worst result with a 160% CPU load.
- on STM32MP257F:
If I use your standard gstreamer parameters ("qtdemux ! decodebin ! videoconvert ! video/x-raw,format=RGBA ! glupload ! qml6glsink name=sink"), the CPU load is 70%.
If I change the gstreamer command to get HW acceleration ("QString pipeline_str = "filesrc location=" + file + " ! qtdemux ! h264parse ! queue ! v4l2slh264dec ! glupload ! qml6glsink name=sink"), the CPU load is 20% in Wayland, and 15% in EGLFS.
I would say your configuration and code are correct, but I don't see possible optimization on STM32MP157.
Philippe.
2025-06-27 6:11 AM
Hi @PPAGE.13
Thank you for running those tests and sharing your results.
However, when I try to run the application using EGLFS, I encounter a "permission denied" error as shown in the logs above. Could you please let me know if there are any additional configurations or permissions I need to set to get EGLFS working properly?
Thanks in advance.
2025-06-27 6:16 AM
Hi,
I realize this isn’t related to video playback, but I’ve also been working on optimizing boot time. Currently, it takes around 40 to 42 seconds for my application to start automatically via a systemd service.
I’ve gone through ST’s documentation on boot time optimization, but haven’t seen any significant improvements. I also tried skipping U-Boot and booting directly into the kernel, but haven’t had success with that yet.
If you have any advice or suggestions to help reduce the boot time further, I’d really appreciate it.
Thanks!