Arch Linux User Repository

@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.

don't they need to use ffmpeg 5 for DV/HDR, sad that it didnt make to Kodi 20

Kodi 20.0 rc1 is out. Anyone wants to host a binary pkg repository again to support a broader testing audience? The Kodi 20.0 release is targetted for January.

@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.

@arfoll - Glad you like ccm. I built a local copy with gles rather than gl and found that on x11, kodi could not playback HEVC content. Just got a black screen. From what I read, gles is for embedded systems (ES) whereas gl is for desktops. I don't think selecting gles is the right option for x86_64. What evidence do you have that gles is required for HDR? What evidence do you have that the performance is generally way better?

Is there a good reason not to switch to the gles render backend? Note that this enables HDR support now (at least on Intel platforms if using GBM and maybe wayland?), and the performance is also generally way better. I can't imagine there's many platforms that don't have gles2 support...

I just added: -DAPP_RENDER_SYSTEM=gles

Also your clean-chroot-manager script is really cool - I had a bunch of crappy bash scripts doing similar things but this is way nicer. Thanks!

@graysky Should I create the buildroot with distcc(What is this)?

Should I Nuke the buildroot and external repo (if defined)<---What is this?

@graysky It also fails when I use the internal FFmpeg.

https://forum.kodi.tv/showthread.php?tid=368574&pid=3101040#pid3101040

@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.

[ 19%] Built target windowing_X11 make: *** [Makefile:146：all] 錯誤 2 ==> 錯誤： build() 遭遇失敗。 正在中止... -> error making: kodi-git