jock

@Werner mpv or ffmpeg may show some "failed" messages, but they appear when they probe v4l2 devices for features and codec support; in case the combo does not work, they report an error and pass to probe the next v4l2 device until they find something valid. You can see similar messages in the screenshots of my PR, but then if you get "Using hardware decoding (drm)" you should be ok. Does the video play with high cpu usage or it does not play at all?

@usual user I'm not quite sure I understand what you mean, because the only enforced flag is hwdec=drm in mpv.conf. There are other two flags to tell mpv which plane to use for drawing and which one for video when it is run in virtual terminal (drmprime-overlay interop). I'm not enforcing vo=gpu, mpv is selecting it by itself. I guess that is the only way to render frames without actively copying buffers around is to render to an EGLImage object and let the gpu do the presentation.

There is a suggestion on how to modify /etc/mpv/mpv.conf in a proper way to use autodetection features by mpv that does not require you to specify everything on the command line. In my experience, mpv 0.35.1 does a pretty good job in guessing what is the right combination if you don't force it. It always worked fine for me in X11, Wayland and virtual terminal

Perhaps you did not select led-conf7 again? rk322x-config is supposed to be run once when system is freshly installed and then it should not be anymore necessary.

Hello, first of all I would suggest you to avoid DietPI; there have been some circumstances were has been reported that credits were not due to the big work done here by armbian maintainers and taken without proper attribution. This is sad to say, but until I hear the opposite, I woudl stay away and don't endorse such "distribution". More about the hardware decoding and rk3318: legacy kernel is now completely deprecated and not suggested to be used at all. It is old and unmaintained code, plus standard linux tools won't work because it contains vendor-specific modules and paths. You would rather stay stick to a regular armbian image with recent mainline kernel. You could also advance to edge kernel (at the moment it is 6.6), but it is not necessary. For the hardware decoding capabilities, I recently made an apt repository for both debian bookworm and ubuntu jammy that may be helpful to you: That repository provides ffmpeg compiled with the right patches to work with hardware decoding, and the player of choice is mpv which is working pretty fine. Unfortunately there is a bug for Mali 400/450 in mpv (or mesa) that causes the video to be pink-colored when played in X11 or wayland, but when run from virtual terminal is works fine though. Also rockchip64 does not have yet the patch to enable hevc, something which I would like to fix soon

Nope

What do you mean, that HDMI does not work yet?

Post reserved

Hello, for those still interested in hardware video decoding, I made a new thread introducing an APT repository to make installation easier for Armbian Debian Bookworm and Ubuntu Jammy distros:

Hello, this quick tutorial is to introduce an experimental Debian and Ubuntu APT repository to install ffmpeg and mpv compiled with v4l2request and v4l2drmprime patches developed by Linux kernel, LIbreELEC and Kodi folks to allow hardware video decoding on stateless decoders like those implemented in Rockchip and Allwinner SoCs for h.264, h.265, vp8 and vp9 codecs. The repository introduces a new package ffmpeg-v4l2request that integrates and substitues the base ffmpeg package and its related packages. Also provides mpv 0.35.1 for Ubuntu Jammy, which has an overrall better support for hardware video decoders. Preconditions: Kernel should be 6.1 or more recent armhf or arm64 architecture Supported operating systems are Debian Bookworm and Ubuntu Jammy Rockchip and Allwinner have already been tested, but this should work on other platforms with stateless decoders supported in kernel APT REPOSITORY SETUP To install the repository, just copy and paste the lines for your operating system in a terminal For Debian Bookworm: $ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/debian bookworm main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list For Ubuntu Jammy: $ sudo wget http://apt.undo.it:7241/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc $ echo "deb http://apt.undo.it:7241/ubuntu jammy main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list INSTALL FFMPEG AND MPV PACKAGES $ sudo apt update $ sudo apt install ffmpeg-v4l2request mpv SETUP MPV CONFIG FILE $ sudo mkdir -p /etc/mpv $ echo -e "hwdec=drm\ndrm-drmprime-video-plane=primary\ndrm-draw-plane=overlay" | sudo tee /etc/mpv/mpv.conf You can now play your videos using mpv and they should run with hardware decoding if supported, either in virtual terminals or in X11/Wayland windows! Enjoy! Notes: your mileage may vary a lot: the more recent is the kernel version, the better is support (you may need edge kernel) bug: when rendered in X11/Wayland window, video may show scattered tiles during frames bug: Lima driver (Mali 400/450) shows a red/pink tint when video is played in X11/Wayland (see https://github.com/mpv-player/mpv/issues/12968) (workaround below: https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/?do=findComment&comment=177968) Panfrost driver should work flawlessy 10 bit HEVC are generally supported on all Rockchip devices (rk322x, rk3288, rk33x8, rk3399), but Allwinner H3 have no hardware support for that

@digicroxx @Carlos Ervedoso add line overlays=led-conf7 in /boot/armbianEnv.txt

Source code is open, I have no rk3128 board but support can easily added (not by me though!)

That is intended to work that way, for an important reason: the bootloader is not just a mere bootloader, but installs complex code in memory and you don't know what it does. More on that: that code runs in a secure context, which is not accessible by anything, so you really don't know what it does and what it can do. One clear example is the fact that the stock bootloader artificially blocks the rk3318 when it runs beyond 1.1ghz, while we have seen it is pretty capable of running at 1.3ghz perfectly fine like the rk3328. The idea is to remove as much as possible of the proprietary blobs (ie: the stock bootloader) and provide open alternatives; tinkering with the bootloader may work now but surely will cause troubles when there will be an updated bootloader. Your case with broken emmc is a different condition by the way, because you have limited alternatives. However there are no real secrets in the boot process, just some complexities and some of them are explained here

@aht2000 Perhaps this helps

Don't know, I never experienced such issue with either FAT or NTFS partitions, since the multitool uses the standard debian tools to do the resize and it works either in Linux and Windows.

@jins what board do you have? It should be sufficient to connect an USB male-to-male cable and flash a backup (or the mere bootloader, if you have it or are able to craft it) with rkdeveloptool or rkflashtool and then it should be able to boot again from sdcard. What board do you have?

A good thing would be the original android device tree, although looks strange to me because the board is a regular R29 and should not behave differently than others.

And it is my advice too. tv box are cheap shit, as @fabiobassa said it is a nice roulette and mostly they are made of scrap parts. If you're very lucky, you get something that works and has some kind of support, if you're unlucky you get crap that breaks after a bunch of weeks because soldering is weak and parts are refurbished scrap. The advice I always give is, if you need something that is required to be minimally reliable and much less painful to setup, go with an SBC supported by armbian; tvboxes are for toying around

@Bert Kortenbach paolo@predatorg:~$ sha1sum rk322x-led-conf7.dtbo f599404e8ccb9d9002da9864a1fe32424400be10 rk322x-led-conf7.dtbo seems like different; by the way I downloaded twice form the post and it worked for me.

Mmmh, apparently it is a forum issue. The same resource can be downloaded from the box in the footer of the post

@Bert Kortenbach Mmmh, looks strange to me it does not work with the updated led-conf7. This is a fresh copy of the overlay for kernel 6.1, in case the one you picked up was experimental or not really working: rk322x-led-conf7.dtbo This is the source reference, for instance. rk322x-led-conf7.dtbo

Then it would not be a maintenace tool anymore but something else; but feel free to take it as a base for anything else! Hint: speaking of Kodi, you are just heading on something like LibreElec Yes, and also because it is the only what to make it cross-OS down to Windows XP. Previously (four months ago) the partition was FAT32, but it would not support files larger than 4Gb

@Arthur Ferraz sorry but without dmesg logs it is impossible to suggest something. It may be that your emmc is broken or who knows?

@Bert Kortenbach Hello; indeed it fails. There's a reason the file is .dtbo and not .dtb: it is an overlay which applies on top of the base dtb. Restore the original rk322x-box.dtb file exactly where it was and restore also the entry in /etc/armbianEnv.txt. rk322x-led-conf7.dtbo has to be put into /boot/dtb/overlay directory, and then has to be activated by adding a line: overlays=led-conf7 in /boot/armbianEnv.txt. Note that rk322x-config script will overwrite the overlays= line in armbianEnv.txt, so you should manually add led-conf7 if you run it

hardware video decoding is still a complex beast, mostly because ffmpeg is still missing the necessary bits which are available as separate patches. v4l2m2m is not the right codec: those are suitable for stataful decoders (rpi and amlogic), but rockchip has a stateless decoder and you have to use v4l2_request decoders. I'm currently working on bringing a ubuntu and debian apt repository which should ease the pain with ffmpeg. It is in an early state and works better in debian bookworm rather than ubuntu jammy currently. I would not disclose the repository yet because it is very early and hosted in my personal lan, but if you're interested in give it a chance I may give you some instructions via private message.