Voidbert

Greetings!
 
I have been trying out hardware video decoding recently, running Debian bullseye, kernel 5.15.53-rk322x and the lima open-source drivers on my RK3229. Here are my conclusions (working only on a virtual terminal):
Using Debian's default ffmpeg and mpv installation, I am only able to get up to 720p with few frame skips. That is using software decoding (--hwdec=no) and SDL for rendering (--vo=sdl). Trying to use DRM (for either software decoding and / or rendering) will result in worse performance. Atomic modesetting needs to be turned off (--drm-atomic=no) in order for anything to appear on my screen (or else, I just get a gray screen). I found this issue of yours (https://github.com/mpv-player/mpv/issues/8522) but it applies to the LibreELEC build. In my case (repo build), --drm-atomic=no needs to be turned on in order for the video playback to work, but it is of no use, since you get better performance out of SDL. --hwdec=rkmpp was also tried but performance differences weren't observed. When you say you built ffmpeg using LibreELEC's patches, are you referring to this? https://github.com/LibreELEC/LibreELEC.tv/tree/0e57a30916a3a88e0d4c595a5525d3c03156fcc6/packages/multimedia/ffmpeg/patches Using your version of mpv, everything works as supposed! Some notes: YUV420 video works very well but RGB video doesn't (both hardware and software decoding). I know it isn't common, I tried it because it could possibly be faster if the CPU didn't have to convert colors between formats, but it ended up being slower. I have tried to provide my help to the Armbian project previously, but what is needed isn't what I know how to provide. Though, I have an idea to help this community: maintaining ffmpeg packages that can take advantage of this hardware acceleration on these chips. This can be done externally of the Armbian project. What do you think of this idea?

Greetings!
 
I have been trying out hardware video decoding recently, running Debian bullseye, kernel 5.15.53-rk322x and the lima open-source drivers on my RK3229. Here are my conclusions (working only on a virtual terminal):
Using Debian's default ffmpeg and mpv installation, I am only able to get up to 720p with few frame skips. That is using software decoding (--hwdec=no) and SDL for rendering (--vo=sdl). Trying to use DRM (for either software decoding and / or rendering) will result in worse performance. Atomic modesetting needs to be turned off (--drm-atomic=no) in order for anything to appear on my screen (or else, I just get a gray screen). I found this issue of yours (https://github.com/mpv-player/mpv/issues/8522) but it applies to the LibreELEC build. In my case (repo build), --drm-atomic=no needs to be turned on in order for the video playback to work, but it is of no use, since you get better performance out of SDL. --hwdec=rkmpp was also tried but performance differences weren't observed. When you say you built ffmpeg using LibreELEC's patches, are you referring to this? https://github.com/LibreELEC/LibreELEC.tv/tree/0e57a30916a3a88e0d4c595a5525d3c03156fcc6/packages/multimedia/ffmpeg/patches Using your version of mpv, everything works as supposed! Some notes: YUV420 video works very well but RGB video doesn't (both hardware and software decoding). I know it isn't common, I tried it because it could possibly be faster if the CPU didn't have to convert colors between formats, but it ended up being slower. I have tried to provide my help to the Armbian project previously, but what is needed isn't what I know how to provide. Though, I have an idea to help this community: maintaining ffmpeg packages that can take advantage of this hardware acceleration on these chips. This can be done externally of the Armbian project. What do you think of this idea?

Human resources primarily for project management, business development and similar non technical tasks which would improve conditions for development ... 
 

We have several hundred dedicated CPU cores and around 1 TB memory for CI. We also have several dedicated storage machines / mirrors. If if double all numbers, I could say we are good, otherwise its survivable not even critical. If we keep project support expansion under control, images count low. 
 
 
This is some general list of roles that are needed:
https://forum.armbian.com/staffapplications/
 
I assume you are familiar with this FAQ? For expanding  / changing TV boxes section we currently only have means / task for small forum rearrangements. Planning and leading changes is time consuming ... If you got an idea, join here https://docs.armbian.com/Community_IRC/ 

I spent this morning trying out things in my Dolamee D5 and these are my conclusions:
HDMI audio and AV audio are working! This box also supports SP/DIF audio (which is detected and appears as an output device in ALSA) but I have no devices to test that on. On the note of audio, you can't control the volume of any of the internal devices (HDMI, spdif and analog) using alsamixer. Because this is a TV box, could it have been designed so that the volume is changed on the TV? On the other hand, the included remote has volume buttons (that worked under Android). The remote is working with ir-keytable (no changes needed)! I mentioned that it wasn't working on a previous post because my first attempt was unsuccessful (a few months ago) when I installed an older image (legacy kernel) and limited myself to running the auto configuration tool (didn't run ir-keytable manually). I couldn't open the TV box up (this box uses plastic tabs that I couldn't remove). I didn't want to drill through some (maybe safe?) places (likely plastic holders for the board) fearing damaging the board. Though, it is likely an eMMC system, as it boots flawlessly on the newer kernels. @fabiobassa said and I don't know if this matters, but this box is from 2016 (at least the 1GB RAM model; mine is a 2GB model and was bought 2017, though I don't know when it was released). Is there the possibility of it being an eMCP model, when the product listing (https://web.archive.org/web/20160924063015/http://www.dolamee.com/dolamee-d5-comes-with-rockchip-rk3229-cpu-and-android-5-1-os/) lists eMMC?
 
Also, @Igor, what do you mean by "the resources we have" in this sentence?
Are you talking about human resources for testing and development or actual hardware for building all the images? I can help with either.

Greetings, @jock! It's the guy that would like to help out with these community maintained TV boxes. Sorry for the delay, but I'm only allowed 1 post and 0 messages a day on this forum. Is there any other way to reach you (I was told you don't use IRC frequently) or to increase my limit?
 
In terms of suggestions, I have some to present. I could even help out in the process:
Getting the broken multitool link working again (https://users.armbian.com/jock/rk322x/multitool.img.xz -> https://users.armbian.com/jock/rk322x/multitool/multitool.img.xz) on the information page (https://www.armbian.com/rk322x-tv-box/). I know the file is in the post that started this forum thread, but that might be best for new users. Debian bullseye builds. Debian is great for mini servers, and if someone is installing it now, they'd probably like to get the newest version for longer support (LTS support for older versions ends sooner, requiring moving to a new one if you want to secure your system). Also, some prefer the Debian package release cycle to the Ubuntu one. I can help out the builds (my CPU for sure won't be happy, but I'd be pleased to help out)! Considering wayland as a suggestion for those who wish for graphical acceleration. It is still slow, but I have experienced better performance with the lima driver on the 5.15 kernel than on X11. Also, congratulations on the project! Things like wifi work flawlessly out of the box, something I can't say for all laptops when I install Linux.