[derMart]

Hi,

i'm trying to use the VAAPI with kodi on weston/wayland. Running armbian 20.05.4 focal (Ubuntu bases distribution running mainline kernel 5.4.45) on the cubieboard2 (Allwinner A20 chip).
The official kodi ppa repo does not have armhf builds, so I checked out the 18.7-Leia tag and compiled from source:

Code:

cmake ../kodi -DCORE_PLATFORM_NAME=wayland -DWAYLAND_RENDER_SYSTEM=gles

cmake configuration shows that VAAPI is enabled.
After successful compilation, running kodi with:

Code:

LIBVA_DRIVER_NAME=v4l2_request ~/kodi-build/kodi-wayland]

seems to be able to open the VAAPI driver as the stderr shows:

libva info: VA-API version 1.7.0
libva info: User environment variable requested driver 'v4l2_request'
libva info: Trying to open /usr/lib/arm-linux-gnueabihf/dri/v4l2_request_drv_video.so
libva info: Found init function __vaDriverInit_1_7
libva info: va_openDriver() returns 0

The main Problem is that when I go to settings -> player under Videos -> Processing -> Render method Auto detect is shown, but greyed out:


From the documentation I would expect options to set VAAPI / VDPAU etc. under Linux (https://kodi.wiki/view/Settings/Player/Videos) but this is all missing.
This is the kodi log while just starting kodi, go to the player settings and exit: kodi.log
Any Idea what the problem is and how to enable the settings?

(The same Problem occurs if I use the kodi from the standard ubuntu/armbian apt repo, either under wayland as well as under X11)

thnx alot in advance
Martin

[asavah]

Render method Auto detect is shown, but greyed out:

AFAIK this is correct.
However if everything is ok VAAPI options should appear below "Render method".

I noticed

Code:

2020-06-19 19:52:53.872 T:2893443088 DEBUG: Vaapi2 EGL interop test results: general no, deepColor no
2020-06-19 19:52:53.956 T:2893443088 DEBUG: Vaapi1 EGL interop test results: general no, deepColor no

As both of these tests fail vaapi does not get registered as renderer.
https://github.com/xbmc/xbmc/blob/Leia/x...pp#L42-L56
Maybe it's lima driver limitation.
I'm not skilled enough to tell you what exactly is missing and why these tests fail.

Let's hope a developer skilled enough in this E/GL/ES madness see this and can provide a definitive answer.

Code:

GL_VERSION = OpenGL ES 2.0 Mesa 20.0.8

If this is possible on your distro I'd try newer mesa 20.1.x, AFAIK lima driver is pretty new and is under heavy development, it is possible that some missing features may (or may not) be already there.

[fritsch]

decoder is there, but renderer not. your vaapi does not implement the proper interop sharing method, e.g. egl interop, that's why it's not there.

See:

Code:

2020-06-19 19:52:53.872 T:2893443088   DEBUG: EGL Debugging:
                                            Error: EGL_BAD_PARAMETER
                                            Command: eglCreateImageKHR
                                            Type: EGL_DEBUG_MSG_ERROR_KHR

[derMart]

Hi all, thank you very much for the responses and pointing me to the right direction.

your vaapi does not implement the proper interop sharing method

Heh, well I have not implemented the VAAPI backend used here, though thank you for the credit. Just for completeness, I am using the v4l2_request VAAPI backend developed by bootlin.
On their blog they claimed compatibility with kodi in 2019.

I think I have tackled the probem a bit further. I am not an expert on the topic, but I am not sure if this is (solely) a problem of the VAAPI backend.

The problem occurs when calling eglCreateImageKHR with this setup:

Code:

EGLint attribs[] = {
EGL_LINUX_DRM_FOURCC_EXT, static_cast<EGLint>(drmPrimeSurface.layers[0].drm_format),
EGL_WIDTH, width,
EGL_HEIGHT, height,
EGL_DMA_BUF_PLANE0_FD_EXT, static_cast<EGLint>(object.fd),
EGL_DMA_BUF_PLANE0_OFFSET_EXT, static_cast<EGLint>(layer.offset[0]),
EGL_DMA_BUF_PLANE0_PITCH_EXT, static_cast<EGLint>(layer.pitch[0]),
EGL_NONE};

only the DMA_BUF attributes for PLANE0 are specified. However, the drm_format of the drmPrimeSurface coming back from vaExportSurfaceHandle is NV12, which has two planes.
So, correctly egl is complaining about that for the second plane fd, offset and pitch are not specified (plane attribute(s) missing).

So, in the first place, Kodi is making assumptions about the drmPrimeSurface which are not true (being a single plane format).

Is Kodi supposed to work with the NV12 format in this context?
If yes, I might file an issue in the github repo.
If not, apart that the code should check that before calling eglCreateImageKHR with bad attributes, is this maybe a regression or is it possible to add support for NV12 / multi plane formats?
This pull request came to my attention, but I haven't gone far enough into the topic to find these answers on my own.

best
Martin

[fritsch]

The plane consists of an Y plane and a UV plane, the interop for 8 bit only checks if it can map the Y plane with DRM's R8 format. Anything wrong with that?

[lrusak]

I would not use VAAPI with V4L2 request API.

Use GBM windowing which has native support for using DRM PRIME with v4l2 requests (using ffmpeg patches). Or use my PR here https://github.com/xbmc/xbmc/pull/17722 which implements DRM PRIME for wayland.

FFmpeg patches are here: https://github.com/Kwiboo/FFmpeg/commits...ccel-4.2.2

[fritsch]

I think your IMX (cubieboard) does not support the R8 import. You can try to hack the code and try with the entire NV12 plane. Though, kodi will have assumptions later on when it works on the two separate planes.

[jernej]

Just for completeness, I am using the v4l2_request VAAPI backend developed by bootlin.
On their blog they claimed compatibility with kodi in 2019.

While that's true, they achieved that by slightly modifying Kodi so VAAPI was used by DRMPRIME codec and renderer. They completely bypassed GPU. However, at this point, this doesn't make sense anymore:
1. VAAPI to request API translation layer does untiling using CPU (A20 VPU outputs tiled NV12 format) which is completely unnecessary because DRM knows to render tiled NV12 directly.
2. No Kodi modifications are needed if you're using master branch
3. Patched ffmpeg uses request API directly which is way more efficient

LibreELEC has experimental A20 support in nightlies with also improved HW decoding in comparison to Armbian and unmodified mainline kernel.

[derMart]

@all thank you so much for the suggestions! Great news about the patched ffmpeg. I will try to build and use this, as well as LibreELEC. It will take a while for me to try this out though. I will report as soon as there is more progress.

[derMart]

I've tried to compile Kwiboo patched ffmpeg, but it does not work with the current mainline kernel used by the 20.05 armbian distro (5.4.45), getting the same error as here
However, the current git master builds of LibreELEC works out of the box smoothly. It can encode h264 720p without problem. So thanks to all.