Package Details: kodi-git r67025.2e06c189dd88-1

Git Clone URL: https://aur.archlinux.org/kodi-git.git (read-only, click to copy)
Package Base: kodi-git
Description: A software media player and entertainment hub for digital media (master branch, gles renderer)
Upstream URL: https://kodi.tv
Licenses: GPL2
Conflicts: kodi, kodi-gbm, kodi-gles, kodi-wayland, kodi-x11
Provides: kodi-common, kodi-gbm, kodi-wayland, kodi-x11
Submitter: BlackIkeEagle
Maintainer: graysky
Last Packager: graysky
Votes: 85
Popularity: 0.001142
First Submitted: 2014-10-23 06:38 (UTC)
Last Updated: 2024-11-13 19:34 (UTC)

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 54 Next › Last »

csts commented on 2022-12-15 23:38 (UTC)

@graysky thank you.
I'll let the chaotic-aur guys know, and if they can they'll put up a binary.

graysky commented on 2022-12-15 23:12 (UTC)

@csts - Yes, master is master. I created a new PKGBUILD for nexus just now: https://aur.archlinux.org/packages/kodi-nexus-git

csts commented on 2022-12-15 22:32 (UTC)

@ghen I have been using chaotic-aur to get Nexus binary updates (kodi-git) until yesterday.
It's odd that kodi-git started giving me Kodi 21 alpha since yesterday.
After some checking there is no way to install Kodi 20 now.

graysky commented on 2022-12-11 15:32 (UTC)

https://github.com/xbmc/xbmc/issues/22238

kevku commented on 2022-12-11 13:33 (UTC)

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

ghen commented on 2022-12-10 14:16 (UTC)

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.

arfoll commented on 2022-11-30 06:33 (UTC)

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

graysky commented on 2022-11-12 23:31 (UTC) (edited on 2022-11-16 11:37 (UTC) by graysky)

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

arfoll commented on 2022-11-12 22:00 (UTC) (edited on 2022-11-12 22:01 (UTC) by arfoll)

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!

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 54 Next › Last »