Thanks ilmich .
After a long and deep research, I've noticed that everything is way too .. "fluid" at the moment for mpv w/hwdec to work reliably with rockchip cpus.
There was a step in the right direction here:
It was a wrapper lib that allowed to use the v4l2-request with more or less standard VAAPI infrastructure, but it's in abandoned state, and a lot of changes/patches are still ongoing in the mainline kernel. It's the Linux standard way to use video hardware decoders since Sandy Bridge (2011, more than ten years ago), but for some reason all the SoC stuff has to be hardcoded/specially built.
The only solution "simple enough" I can think of is using your LibreELEC (kernel 5.10 based) as a framework, and modify it to compile an mpv binary, and avoid launching kodi at startup. It should be simple enough for my purposes: what I need is kernel with wireguard support (that libreelec already has) and a video player that launches automatically a video in fullscreen mode.
It seems rather difficult, because of the way LibreELEC is built.
Way too many moving parts: I'll use .py scripts with your LibreELEC build.
Maybe OT, but still:
I have a question for ilmich : I have ported the latest Alpine Linux (3.16) on this device, kernel modules & firmware from Armbian (kernel 5.16.11), using the "overclock" DTB you kindly provided for this LibreELEC.
It works pretty well for everything , but I have troubles with video drivers/mesa anything video related.
I'd like to get some info about how to get "skeletal" video hardware acceleration with a player i.e. mpv , from the terminal.
All the bits&pieces from hantro/rvdec seem to be there i.e. v4l2, and the "lima" driver too. But using them on this platform is still sort of a "black art", afaik I need patches from various sources to ffmeg/mpv/ something else ?
Can you point me somewhere, give me some hints, if you can ?
As usual, thanks 100000
ilmich : your latest build works fine and I can select 480p (720x480) hd (1280x720) and fullhd (1920x1080) resolutions on my monitor, sound working correctly.
The problem shows up with some monitors: for example, my Samsung 32" TVs is correctly identified, my Samsung 27" PC monitor is not. Both on the HDMI port, of course.
You latest patch corrects the problem.
But what resolutions does your monitor support!?!?
I agree, it's a stupid idea
ilmich : tried the new build and it works, my monitor is limited to 1280x720 and 720x480, but that's EXACTLY the right resolution to work with the box.
HDMI audio works, too.
Thanks a million.
Maybe there's a "one-size-fits-all" EDID somewhere to inject in the kernel line as I did, to get some "forced" resolutions ?
I kinda "solved" it by getting the EDID with an el-cheapo HDMI->VGA adapter that sends the EDID in a format the box understands. I extracted it, put it into the LibreELEC overlay, modified kernel line parameters accordingly and finally works. See my previous post.
Finally nailed it.
- Connect the box with the VGA->HDMI adapter to the monitor (to the VGA port) and turn on the little sh*t
- login with SSH to the box and run the following commands:
mkdir -p /storage/.config/firmware/edid
cat /sys/class/drm/card1-HDMI-A-1/edid > /storage/.config/firmware/edid/edid.bin
mount -o rw,remount /dev/mmcblk2p1 /flash
- edit the linux kernel line:
- add this parameter to the kernel line:
reboot & connect the HDMI cable: resolutions are OK & audio works.
For some reason the hdmi driver can't get the correct EDID from hdmi directly. Tried with lots of monitors, but no banana.
Since I'm fortunate enough to have a cheap-ass HDMI->VGA adapter, I've noticed that it passes the correct EDID to the box.
So I'm extracting the EDID and putting it into the LibreELEC config/overlay, and finally tell the kernel to load/force this EDID to the HDMI port it at boot.
It's a sub-optimal/shitty fix but at least points to the problem, maybe the low-level rockchip/hdmi drivers have a bug or GOD KNOWS.
Further investigation proved that modules are not the problem, initialization of the HDMI port is.
If I connect the box with an adapter HDMI -> VGA, resolutions are correct (taken from the monitor EDID ?) : At this point, if I detach the VGA cable and connect another HDMI monitor, leaving the box on, I have sound.
I guess the vga/hdmi dongle sends some signals that initialize the hdmi interface of the box correctly.
If I boot with a normal HDMI cable I get wrong resolutions and no sound.
Quirks - they're coming outta the goddamn walls.
Investigating further into the HDMI no-sound issued I've found that in an Armbian with 5.15.25-rk322x kernel from Jammy-current the following modules are loaded:
And ALSA is handled by snd_soc_simple_card:
!!Soundcards recognised by ALSA
0 [analog ]: simple-card - analog
1 [SPDIF ]: simple-card - SPDIF
2 [hdmisound ]: simple-card - hdmi-sound
HDMI and Analog audio both work in this Armbian.
On this LibreELEC (kernel 5.10.115) the loaded modules (for sound) are:
I don't know if it makes any difference, at first glance it seems there are some parts completely missing, but I have no experience in building LibreELEC.
Thanks to ilmich for his hard work.
This build of LibreElec 10.0 works amazingly well, but I have some issues:
- HDMI resolutions are incorrect
- No audio from HDMI
I put two pics of the boxes: AFAIK they have eMMC (Samsung part, 8Gb), rk3228a & 533Mhz DDR3. On the board is written V3.1.
They have South valley SSV6051 wifi (not really important).
Actually, your build is the ONLY one that does not crash after one/two hours of video, too bad I do not have any audio, and I don't know where to look for a fix. HDMI driver loads fine, but it seems ALSA device is not detected. Here's what I read in dmesg:
[ 2.108808] ALSA device list:
[ 2.108828] No soundcards found.
I suspect that the previous RockChip 4.4 "legacy" Kernel was really buggy in the video hw accelerator part (rkmpp was hanging/spewing errors all the time) or maybe somethng else was wrong. Hard to say with these parts.
Even the Armbian build was giving the same errors with rkmpp video hw stack, and kept switching to software decoding after 5/6 minutes of video play.
This build works really well with an hardware SO low-spec. The original android 7.1 NEVER worked, hanged after half an hour. I bought 10 of those for €9, since they were marked "defective" (and for good reasons).
The "overclock" m4kpro dtb file works pretty well, even after two/three hours of video play (lan/udp streaming of a full HD webcam via ffmpeg).
Thanks again for giving some use to an hardware so limited.