thats weird, can you provide log output of:
ffplay4 -loglevel repeat+level+debug -i videofile
Archlinux on Rock5b
there is nothin suspicious in the log files, is the video file 8k? it seems like its decoding but may be its too slow, rga can not handle more than 4k size at current state. can you also provide the output of journalctl -f? Can you provide the file somewhere on the web? do you have issues with other formats as well?
Hi, this file is very huge (56 GB).
It is 4k file, it is logged in that attached log:
grep video_size ffplay-error-log
[ffplay_buffer @ 0x7f60003ed0] [debug] Setting âvideo_sizeâ to value â3840x2160â
I also downloaded an HEVC sample file from here: 2160p sample which plays, but it is very slow, probably ffplay4 doing software decoding.
Look below for the requested journalctl output while started to play this huge file.
febr 22 21:02:55 horvath-pc kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
febr 22 21:02:55 horvath-pc kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
febr 22 21:02:55 horvath-pc mpp[3348]: mpp_info: mpp version: 7b7bca62 author: Yandong Lin 2023-02-22 [av1d]: fix loss frame when eos packet has one more frame
febr 22 21:02:55 horvath-pc mpp[3348]: mpp_info: mpp version: 7b7bca62 author: Yandong Lin 2023-02-22 [av1d]: fix loss frame when eos packet has one more frame
febr 22 21:02:55 horvath-pc kmix[996]: org.kde.kmix: Channel Map contains a pa_channel_position we cannot handle 8
febr 22 21:02:55 horvath-pc kded5[782]: org.kde.kmix: Channel Map contains a pa_channel_position we cannot handle 8
febr 22 21:02:55 horvath-pc kded5[782]: org.kde.kmix: Channel Map contains a pa_channel_position we cannot handle 9
febr 22 21:02:55 horvath-pc kmix[996]: org.kde.kmix: Channel Map contains a pa_channel_position we cannot handle 9
febr 22 21:02:55 horvath-pc mpp[3348]: mpp_buf_slot: set frame info: w 3840 h 2160 hor 4864 ver 2160
febr 22 21:02:55 horvath-pc mpp[3348]: mpp_dec: setting default w 3840 h 2160 h_str 4864 v_str 2160
febr 22 21:02:55 horvath-pc rtkit-daemon[816]: Failed to make ourselves RT: Operation not permitted
file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/Footer.qml:155:5: QML LeaveButtons: Binding loop detected for property âshouldCollapseButtonsâ
febr 22 21:02:58 horvath-pc mpp[3348]: mpp_meta: ~MppMetaService cleaning leaked metadata
febr 22 21:02:58 horvath-pc mpp[3348]: mpp_buffer: ~MppBufferService cleaning leaked group
febr 22 21:02:58 horvath-pc mpp[3348]: mpp_buffer: ~MppBufferService cleaning leaked buffer
febr 22 21:02:58 horvath-pc ffplay4[3348]: mpp_mem_pool: put_pool found 1 used buffer size 304
febr 22 21:02:58 horvath-pc ffplay4[3348]: mpp_mem_pool: put_pool found 31 used buffer size 224
febr 22 21:02:58 horvath-pc ffplay4[3348]: mpp_mem_pool: put_pool found 1 used buffer size 13752
febr 22 21:02:59 horvath-pc kwin_x11[788]: OpenGL vendor string: Panfrost
febr 22 21:02:59 horvath-pc kwin_x11[788]: OpenGL renderer string: Mali-G610 (Panfrost)
febr 22 21:02:59 horvath-pc kwin_x11[788]: OpenGL version string: 3.0 Mesa 23.0.0-devel (git-120202c675)
febr 22 21:02:59 horvath-pc kwin_x11[788]: OpenGL shading language version string: 1.30
febr 22 21:02:59 horvath-pc kwin_x11[788]: Driver: Panfrost
febr 22 21:02:59 horvath-pc kwin_x11[788]: GPU class: Unknown
febr 22 21:02:59 horvath-pc kwin_x11[788]: OpenGL version: 3.0
febr 22 21:02:59 horvath-pc kwin_x11[788]: GLSL version: 1.30
febr 22 21:02:59 horvath-pc kwin_x11[788]: Mesa version: 23.0
febr 22 21:02:59 horvath-pc kwin_x11[788]: X server version: 1.21.1
febr 22 21:02:59 horvath-pc kwin_x11[788]: Linux kernel version: 5.10.110
febr 22 21:02:59 horvath-pc kwin_x11[788]: Requires strict binding: yes
febr 22 21:02:59 horvath-pc kwin_x11[788]: GLSL shaders: yes
febr 22 21:02:59 horvath-pc kwin_x11[788]: Texture NPOT support: yes
febr 22 21:02:59 horvath-pc kwin_x11[788]: Virtual Machine: no
febr 22 21:02:59 horvath-pc kwin_x11[788]: BlurConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: ZoomConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: WindowViewConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: SlidingPopupsConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: SlideConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: OverviewConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: KscreenConfig::instance called after the first use - ignoring
febr 22 21:02:59 horvath-pc kwin_x11[788]: DesktopGridConfig::instance called after the first use - ignoring
well, my board just got burned 1 minute ago, so i canât help anything anymore.
Was working fine until a âbzztâ sound came and board is dead as a potato now. I really regret the moment that i tocuhed this thing. what a waste
Damn, thatâs sad. I hope you can get a replacement.
1 Like
sad hope you get a new one fro radxa
1 Like
It seems like only the PD part is burned, the board works again with 12v dc now.
@armogur the sample hevc you attached works fine on my rock5. Could you also post the output of pacman -Q | grep mpp ?
what power supply were u using and how did that happened?
I donât know why Arch with your panfork seems not as smooth as the armbian image.
Is that because armbian used more hack which is hard to pack to other distributions?
@DarkevilPT i was using 45W Lenovo Laptop Charger. Without doing nothing special, device went off after a âbzztâ sound. So not anything special.
@sharelter, it is exactly the same sode as per panfork, and i dont think minor compilation flags would change a thing. Only thing i can say is wayland is more butter smooth than X, but wayland is amazing until there is something it does not work (especially with panfork and with libGLX issues) therefore i use X. I used armbian also but could not notice too much of a difference. I did not check throughly thoughâŚ
Thats fucked upâŚ
I can only speculate either CC line grounded inside the charger cable because of excessive bending, or shorted to 5V/12V or whatever it is negotiated to, because the board was still on the desk, nothing can short to anywhere because it was running for hours. In any case the board should have protection mechanism for such cases even if the case was like that, but yeah, it is what it isâŚ
Hi @boogiepop , Iâm doing some experiment with Linux on my Rock 5B, so in the meantime I flashed Debian/Bullseye to my eMMC card (I only have one storage device around here, so I cannot do multiple installation) that means I completely erased my Reborn os.
I thought this will solve this problem but having the same issue here, so Iâm kinda: 
Could you please share the source code (link, whatever) to ffplay and other necessary drivers, etc�
I will give it a try in Debian, and letâs see if it works here, thanks.
You can then try armbian, since @amazingfate also has the same ffmpeg+mpp and in his ppa for armbian
If you want to go to DIY route:
i merged every possible version of ffmpeg with mpp pacthes here they are originated froy JeffyCNâs repo. Please note that on Jeffyâs repo u need librga which is unmaintained, on my patched repo it is embedded in the ffmpeg source. Replacing system ffmpeg needs caution though, you need use a very similar version of ffmpeg with system otherwise the headers may differ from minor version to minor version, and you might get segfaults on applications which is linked against original ffmpeg with slightly different symbols.
mpp is here, definetely use the develop branch.
for the actual compilation you can check PKGBUILD scripts in those AUR packages.
I am quessing/speculating your problem with Reborn was that you might have installed the wrong package for mpp, in AUR there is an old rockchip-mpp package from 2017 which is totally obselete, and there is a new package mpp-git which is up to date.
2 Likes
@boogiepop Thank you, I followed the instructions, installed the mpp devel branch, then checked out your repo and compiled your version of FFmpeg, but not installed so it remained in my home dir.
Now when I run ffplay I get segmentation fault error, and the before this segfault error it writes to console this error message:
libGL error: failed to load driver: rockchip
Any hint? What can I still miss?
Make sure your user is a member of video group. This is in case your mpp driver is allowed to +rx to video group. Check PKGBUILD of mpp post install script where it confugures the driver access levels. For testing you can shortly try running as root
@boogiepop Great, one step closer.
Issue was: /dev/dma_heap/ permissions + groups ; fixed, with this modification ffplay now starts, but still slow (very slow, probably it still uses software decoding).
I also checked my groups, and my default rock user is in the video group.
Here are some lines from output:
libGL error: failed to create dri screen
libGL error: failed to load driver: rockchip
libGL error: failed to create dri screen
libGL error: failed to load driver: rockchip
[hevc_rkmpp @ 0x7f2c001830] Decoder noticed an info change (3840x2160), format=0
[hevc @ 0x7f2c000c10] Stream #0: not enough frames to estimate rate; consider increasing probesize
Input #0, hevc, from ââŚ/Downloads/sample_3840x2160.hevcâ:
Duration: N/A, bitrate: N/A
Stream #0:0: Video: hevc (Main), yuv420p, 3840x2160, 23.98 fps, 25 tbr, 1200k tbn
[hevc_rkmpp @ 0x7f2c0c1180] Decoder noticed an info change (3840x2160), format=0
[hevc_rkmpp @ 0x7f2c0c1180] Doing slow software conversionB f=0/0
[hevc_rkmpp @ 0x7f2c0c1180] Doing slow software conversionB f=0/0
Last message repeated 1 times
[hevc_rkmpp @ 0x7f2c0c1180] Doing slow software conversionB f=0/0
[hevc_rkmpp @ 0x7f2c0c1180] Doing slow software conversionB f=0/0
Not only dma heap but also rga and mpp_service as well
Logs state that rga can not be utilized, most likely permission issue
Here is the rules you can base.
https://aur.archlinux.org/cgit/aur.git/tree/mpp.rules?h=mpp-git
@boogiepop Those were correct permission + group, thatâs why I didnât mentioned it.
In the meantime I investigated further, not sure if this is the issue, but when I run the glxinfo -B command I got these:
name of display: :0
libGL error: failed to create dri screen
libGL error: failed to load driver: rockchip
libGL error: failed to create dri screen
libGL error: failed to load driver: rockchip
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
Device: llvmpipe (LLVM 11.0.1, 128 bits) (0xffffffff)
Version: 20.3.5
Accelerated: no
Video memory: 15721MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 11.0.1, 128 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
See the OpenGL vendor string and OpenGL renderer string? Maybe this is the reason? In this video: Install Panfrost I see Mali-G610 at OpenGL renderer string