jernej

Yes, H616 Cedrus is capable of decoding VP9, but I'm not aware that anyone actually implemented support for it.

Even if this is now more than 10 years old, this is still mandatory read: https://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/ All of these players use Android API, so they don't need to care how HW video decoding is really done. Android is modified in a way to use Cedar core for that. libVA backend isn't maintained and LE doesn't use it. Latest kernel are not supported in that v4l2_request libVA port. For VLC and other players it would be easier to use it, but that's life... There is more than enough information to figure out how this works, but granted, there is also a lot of obsolete information, so you have to figure how things work. Hint, VLC currently won't work with Cedrus.

@Troy H If you want mediacenter distro, you can try LibreELEC with Kodi. It has proper OPi3 LTS support (except wifi), but it might not be to your liking because it's single minded distro - no package manager to install extra software. If you decide to try it, I suggest latest nightly image (mind the date!) until 12.0.2 is out, as it has one important video rendering fix.

LE doesn't use VAAPI as it would be just extra complication where something could go wrong. At the time LE started supporting v4l2_request based drivers, v4l2 wasn't flexible enough to support VAAPI way of memory management, at least not in all cases. Instead, LE uses modified ffmpeg with native v4l2_request support, among some other modifications. Patches are available here. In some cases Kodi also need patches (for example, for HW deinterlacing.) They are right, because Mali GPU has nothing to do with HW video decoding. It can be used for video rendering, but even that is done with DRM planes on LE, which is more performant in most (all?) cases. Allwinner SoCs use Cedrus core for video decoding. LE uses GPU only for GUI rendering.

It has, all H family has 2 mixers. Addresses are hidden in DE BSP source code, but not as absolute address, only as relative. In any case, you don't need second mixer if you won't use any other display output. Note that there is no documentation for DE3.3. There is documentation for DE3 on linux-sunxi.org, which is older, but nevertheless similar core. Still, BSP source code will give you best info, even if it's sometimes hard to understand. In any case, you seem to be on right track to get it working. I strongly suggest that you dump register values of all components involved in pipeline from working BSP solution (most likely Android image) and compare to them to register values dump from your mainline based system. This includes TVE, TCON top and also very importantly, clocks and resets. One extremely useful trick for diagnostics is to use TCON test patterns. Those patterns are directly generated in TCON and then piped to encoder, TVE in this case. It allows you to test TVE without worrying about mixer and if it's properly routed through TCON top. Those test patterns can be enabled by setting TCON register 0x40 to, for example, 1, which will get you well know color check pattern. Note that your solution with TV TOP included in same driver as TVE will work here, but it's not appropriate solution for upstream. TV TOP should be standalone driver like TCON TOP...

If you want Kodi and smooth video playback, you can always check LibreELEC. OPi3-LTS has some bugs, so best build is here, but you can wait for next point release which will be done in about a week. Video playback needs some work in progress software if you want smooth experience, which afaik is not present (yet) in Armbian.

I don't have neither of these boards, but I can help answering any question regarding state of the art drivers in mainline kernel.

Note that crust is very board specific. If it doesn't have IR by default, you have to enable it in config. Apart from that, you have also select correct IR protocol and key code. On some boards you also have to select proper clock for IR.

I don't know this board, but it seems button is directly wired to reset pin, so reset is expected response. This board isn't the best choice for testing this. Maybe you can try with RTC wakeup. Or maybe even HDMI-CEC wakeup, but you need to change config for this one.

Which board do you use for testing?

Crust is successfully integrated on A64, H3, H5 and H6 in LibreELEC. R40 and H616 don't have co-processor, so they can't have it. I don't know A83T state. H3 needs additional U-Boot patches which are in conflict with other SoCs (including R40), so it's best to have them separated. Easiest test is to use board with power button. Put board in sleep with "systemctl suspend" or power it down via command line (poweroff, shutdown now, etc.). Once it's in sleep or in stand by mode, press power button. If everything works as it should, board should come to life. Serial console is highly recommended during testing and a must for debugging any kind of issues.

No, that part is correct, but I must admit that since I have no system with patched ffmpeg at hand currently, I misremember how request api is expressed in ffmpeg decoders list. In any case, request api is covered by drm hwaccel and use drmprime pixel formats. Anyway, it seems you succeeded in reaching your goal.

Not sure what are current defaults, but that's generally on the low side. LE uses CMA size of 384 MiB, mainly due to 4k. They fix one buffer management issue which may cause incorrect decoding but most importantly, they massively lower amount of memory that's used during decoding. Those fixes are included in 6.2 and newer kernels. Use following command for testing: ffmpeg -loglevel debug -hwaccel drm -hwaccel_output_format drm_prime -i video.mkv -f null - It will be pretty obvious from debug log if request api is used or not. Not sure which version of mpv you're using, but very latest (not sure if it's in released version or in development branch) should allow using request api ffmpeg also when window manager is running. EDIT: make sure that this ffmpeg patch is included: https://github.com/jernejsk/FFmpeg/commit/5057eb96b2adbff022a1abd8d5b06f369f908d51

*_v4l2m2m codecs are for v4l2 stateful drivers, not request api. Actually, you have to grep for "request" word. Check that you have 6.1 kernel headers installed. IIRC last important kernel patches went into 6.2, so ideally you would run that. Last but not least, to know which codecs are supported, you have to use v4l2-ctl command. Easiest way is to use --all parameter and check for supported formats on cedrus device.

Encoding is not supported by mainline driver. There are some hacks posted on this forum how to make it work using vendor driver, but you need to patch kernel and ffmpeg and you can only have encoding or decoding working, not both.