@graysky - For the video renderer itself you can check the code - https://github.com/xbmc/xbmc/blob/f2376ff0a77c90651ec3203efab1533f1c3ca855/xbmc/cores/VideoPlayer/VideoRenderers/LinuxRendererGLES.cpp#L138. No check for HDR metadata is done in the GL renderer, so it's not going to work (also on an LG C2 with one the TV switches to HDR, the other not - note that HDR on X11 isn't going to work anyways, you need to use GBM, wayland maybe works but unclear). It's possible that the DRM prime renderer that I enabled like this https://dpaste.com/FM8PY52X9 would also work with normal GL but it seems not ready for use and just crashed.
Imho GLES is just the modern backend of kodi you can see it generally gets more development, GLES was meant for embedded but is these days used everywhere and is way closer to modern OpenGL than OpenGL2.0 as used by kodi. Librelec chooses GLES for non x11 builds (I guess as you found there may be some x11 issues) - see: https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/mediacenter/kodi/package.mk#L57. Where you using a hardware video decoder, it's possible VDPAU is not as well tested with gles... As for faster I have a J4005 and those things are far from fast, so you can just tell in the menu it's smoother & faster at 4k, but I have no benchmark data.
Pinned Comments
graysky commented on 2022-06-11 11:49 (UTC)
@laichiaheng - kodi is bound to a specific version of ffmpeg which is generally older than Arch's package. We avoid incompatibilities by using that specific version (ie internal ffmpeg). Recommend that you build kodi in clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot
I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.