jernej

NV15, although sounds standard, it's not. It's RK invention and used only (AFAIK) on their chips. So I would presume not many mesa developers are aware of it and even less care about it. Note, EGL has nothing to do with DRM planes. EGL lists format supported for GPU rendering and DRM planes lists formats supported by Direct to plane rendering. There is catch, though. ffmpeg must provide proper mapping to DRM descriptor. I have no idea if that's done for NV15 in ffmpeg rkmpp module. If that's not done, direct to plane method won't work. Note that I don't care about vendor solutions and I'm only indirectly involved with RK platforms, so I can't help you more.

Driver needs a bit of rework since Cedrus on H6 needs a bit different initialization. I guess you need this for video encoding?

Well, if freezes it's doubtful that it will work with newer image. Your box is different than OrangePi board, so most likely reason why it freezes is that electronics is not compatible and you would need device tree file (HW description) tailored to your box. This is not an easy task for a beginner. You can copy 1 MiB from that image, starting at 8 KiB offset. However, U-Boot has many board related configuration hardcoded, so I can't promise it will work.

Bootloader has to be written to SD card at offset of 8 KiB. dd command for this would be: sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1k seek=8 conv=fsync NOTE: Replace /dev/sdb with proper path to your SD card.

ZQ value should be in decimal, so 3750393. Other than that, it should be ok. Just be sure to write U-Boot to right location. How do you write U-Boot to SD card?

It's not supported on H6 yet.

Uh, your box uses RAM with extremely low frequency. All images you tested have about 2 times higher frequency set. This alone is very likely the reason for non working RAM. Additionally, ZQ value is different, but usually that's not a big problem. With these two changes, you can already customize U-Boot config, build it and replace it on one of the images.

Please write in english, I don't speak russian. Yes. Most of them contains partial DRAM configuration. Not enough to configure DRAM properly, but enough for quick check. Just copy first 1 MiB from eMMC, you can use dd command for that. There is plenty of guides on net. You still didn't tell which Armbian image you tried to boot.

This was maintained right - obsolete vendor kernel which hinders many modern functionality (wireguard, for example) was replaced with mainline kernel, which receives non-stop fixes and improvements for the cost of not supporting some HW features, which still can be eventually supported. DDR frequency scaling is mostly regarded as power saving feature, so most people don't care if board consumes few mA more or less. Only recently such driver was added for Allwinner A64 and H5, but these are pretty different from A20, so driver most probably can't be easily extended.

You should tell which image you tried to use and in order to be able to do anything, boot log of original FW (probably Android) and extracted sys_config.fex or first megabyte of bootloader, so it can be extracted from there.

It's ARM9 core, so it's very old architecture. Only BSP kernel exists, but who knows where source can be found. So, even if sources for kernel can be found, it would be a waste of time to support it in Armbian.

First of all, I assume you installed patched ffmpeg libraries system wide? I saw mpv complain if installed ffmpeg libraries are different version that the version that mpv was built with. In such case, you have to also rebuild mpv. Second, mpv will use v4l2 request acceleration only in gbm mode, e.g. when no desktop environment is running. I guess nobody wrote support for converting dma-bufs to gles buffers, even though mesa have function for exactly that. Simple, RPi foundation has enough power to convince various players to support their proprietary API. Others did not. Similarly, Android is popular enough that vendors hammer their own proprietary solution into their ports. Only now various HW decoders are being unified under v4l2, either with request api or stateful api. Currently only gstreamer has good native support for these apis out of the box (HEVC will be supported in next stable release).

That's not the case. Collabora was contracted to work on Hantro and RKVDEC driver, that's why there is a major push to improve these drivers and make API stable. While LE always had good enough patches for missing functionality, there was lack of time to actually push them in mainline. It's not, but @Kwiboofixed most issues for media playback long time ago, so his DRM/KMS patches are still maintained in LE.

Well, you can always wait until any issue is resolved by LE developers.

Deadline for media patches was extended for another week, due to additional RC version for 5.19. Let's see if RKVDEC HEVC manages to sneak in.

Not at the moment. Thing is that it's, as you said, proof of concept. RPi variant is probably the one that it will be sent upstream (asynchronous job submission, which is much more performant), but it needs to be tweaked to be more universal. Hopefully we'll start working on this soon, since HEVC request api is the only common interface between RPi4 driver and Cedrus, Hantro and RKVDEC. FYI, RKVDEC HEVC will most likely miss 5.20, since it was posted just yesterday and cut off date for new media features is end of this week.

Kernel 5.19 (rc1 will be released in about one week) will have all drivers, but no DT. So 5.20 will presumably have initial support, with DT included. Probably USB too. However, patches exists for most features.

For those who don't closely follow development, certainly. I don't work on RK drivers, so I'm not sure if this is some kernel/driver quirk or userspace issue, but I know that v4l2 supports max. 32 buffers. Since your number is on the upper limit, it's not clear where the issue lies. I heard that RPi4 devs have issue with HEVC support on VLC, because VLC wants to allocate more than 32 buffers.

When someone sends patches to ffmpeg ML and goes through all requests made by ffmpeg devs. Before that, patches need to be consolidated with RPI HEVC ones (also request api based). Another issue is that Kodi doesn't support ffmpeg 5.0, so patches will stay on 4.4 until that happens. Needless to say, upstream takes patches only on top of last version. Since nobody works on that, I would say not in near future.

VP9 is stable already and it's covered on more SoCes than RK3399. It works on Allwinner H6, for example. HEVC is not yet stable, you still need external patches. LE has already patches for 5.18: - kernel: https://github.com/LibreELEC/LibreELEC.tv/pull/6423 - ffmpeg: https://github.com/jernejsk/FFmpeg/commits/v4l2-request-hwaccel-4.4

Yes, there are several topics. Quick search found: Best to ask in one of existing topics. Oh, only H264 encoding is supported.

Encoding isn't supported by mainline kernel, unless you modify kernel like some people on this forum.

Find what?

Well, you have to be careful which address you use with which bus type. As long as bus and address pair match, there should be no observable difference in behaviour. I have no clue why it wouldn't work on another board. BTW, error -517 means that driver can't be loaded due to dependency issues. In this case, where axp address was wrong, this happened because many devices tried to enable or set up their regulator, but regulator couldn't be located on bus due to wrong address.

There is absolutely no difference, otherwise there is a bug somewhere. Reason why OrangePi image has I2C and Armbian RSB is that switch from I2C to RSB happened with kernel 5.13 and OrangePi uses kernel 5.10, which predates this. If OrangePi releases image with newer kernel, it will most likely use RSB too. The only important differences could be in regulator settings (subnodes to axp), those are important settings to copy.