[SOLVED] KODI Leia - 18.x MediaPlayer - Optimized for Raspberry Pi1/Zero/Pi2B/Pi3B(+) on Slackware ARM 14.2 SF & Slackware ARM - current HF
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Note that I'm also building a separate FFMPEG, properly optimized for the vc4 GPU and I'm subtituting and blacklisting (from updates) the one that comes with Slackware ARM. FFMPEG is the workhorse for the Kodi "overlay".
I'm also using this optimized FFMPEG for other players and if you follow my instructions for building it please note that I made a mistake related to a ./configure switch, actually disabling ffplay, corrected by @lazardo here: https://www.linuxquestions.org/quest...ml#post6058232
- use the --enable-sdl switch
@tarnow presented another way of building Kodi, optimized for the Pi4. He found a way to link the Kodi build with the mesa libs in /opt/vc and is patching and building FFMPEG statically inside the Kodi build (as designed). I haven't tried his instructions, but only commented/corrected some steps: https://www.linuxquestions.org/quest...65-4175662156/
Slackware ARM is not focusing on Raspberry optimizations, but built to run on many ARM boards and for the Raspberry you need specially optimized mesa libs (/opt/vc) and FFMPEG.
I didn't follow your instructions, so I did have Mesa installed when I built.
What's the point of removing it? The configuration step still says "-- Platform: X11". There doesn't seem to be a way to disable X11.
-DENABLE_X11 was removed in the latest Kodi's CMakeLists.txt.
Didn't know about the removal of -DENABLE_X11, at least Kodi 18.1 was OK (the last one I built & played with) and didn't require X, maybe use that version instead.
Now, I don't want to push you away from using Slackware, quite the contrary, I'm happy to keep you a happy Slacker, but if you feel that building and using Kodi on Slackware ARM is too complicated & time consuming. And, if you plan to dedicate your Raspberry board just for Kodi, then LibreELEC could be a good alternative. I've also used it and the latest versions provide all the goodies and customizations one would require (it wasn't the case with older versions), including firewall, openvpn, etc: https://libreelec.tv/
As for me, I'm still using Kodi 17.4 on Pi Zero boards, running Slackware ARM 14.2, and I'm really happy with it, no need for Netflix & other crap, but only playing DVB streams (another Pi Zero runs tvheadend and streams DVB-S2 & DVB-C), add-on streams, IP-TV streams, online radio, local media, you name it ...
Last edited by abga; 04-23-2020 at 07:55 PM.
Reason: typo
My issue is entirely with X, though; xorgsetup doesn't produce an xorg.conf.
Kodi runs just fine when I start it from within an xterm in Fluxbox. I tried this with TigerVNC, but Kodi doesn't start when I want it to go through the HDMI to the TV.
My issue is entirely with X, though; xorgsetup doesn't produce an xorg.conf.
Kodi runs just fine when I start it from within an xterm in Fluxbox. I tried this with TigerVNC, but Kodi doesn't start when I want it to go through the HDMI to the TV.
Try to rebuild it by following my instructions to "hide" the mesa libs that are officially provided by Slackware ARM - uninstall and reinstall them (the package) back after you got the Kodi built - and point the Kodi build scripts to use the ones in /opt/vc/
Then, use the glx & glkodi scripts I mentioned to switch the symlinks in /usr/lib, for the case when you use X and then for when you use Kodi.
When using the Slackware provided mesa libs and not switching the libs I get an "ERROR: Unable to create GUI. Exiting" error and not a "X11 Error: No Display found"
Make sure sure you have proper settings in your /boot/config.txt (reboot is needed after any modifications):
Code:
#comment out:
#dtoverlay=vc4-fkms-v3d
# set the minimum amount of GPU RAM (at least 128 MB)
gpu_mem=128
framebuffer_depth=24
#or if you have eagle eyes and not limited like all other humans to 24 bit color depth (useless)
#framebuffer_depth=32
#framebuffer_ignore_alpha=1
Or, raise the issue with the Kodi devs in the Kodi Forum. Although I couldn't find a record with the removal of -DENABLE_X11 in the commits history (might have missed it): https://github.com/xbmc/xbmc/commits/Leia
I'm sorry, I don't have the time & space to start building Kodi 18 again. Other than helping you, I also have no interest in using it, since the OMX engine is broken and it's useless on my Raspberry Pi Zero boards. I'm keeping Kodi 17.4 running until Slackware ARM 14.2 is still maintained, after which I might move to a stripped down version of Gentoo ARM (already prepared). I can't use LibreELEC, because they use the broken Raspberry firmware (analogue audio) and the Kodi 17.x releases that have the OMX engine working are unmaintained.
Last edited by abga; 04-24-2020 at 11:00 PM.
Reason: typo
didn't help with video choppiness in Kodi or Mplayer.
Also, I don't have a /boot/config.txt file to put gpu_mem=252 or 512, but there is a /boot/config-armv7-5.4.31 file. Is there a new way to set GPU memory?
didn't help with video choppiness in Kodi or Mplayer.
Also, I don't have a /boot/config.txt file to put gpu_mem=252 or 512, but there is a /boot/config-armv7-5.4.31 file. Is there a new way to set GPU memory?
The video choppiness could be caused by FFMPEG, if that wasn't properly optimized and directed to use the mesa libs in /opt/vc.
It could be also caused by the broken OMX, disable OMX acceleration and enable only MMAL in Kodi's settings (GUI Menu > Settings > Video Player)
Or, it could be because of the default Advanced Deinterlacing Method, switch it to MMAL Bob as instructed in the end of this older post: https://www.linuxquestions.org/quest...2/#post5759079
You should have a /boot/config.txt, that's the firmware (BIOS) conf file, create it if it's not there and /boot/config-armv7-5.4.31 should be the kernel config file. Don't know how you installed Slackware ARM, I'm only able to help you if you followed the standard manual setup as I don't have experience with any other method: https://docs.slackware.com/howtos:ha...rm:raspberrypi
As the mesa build script for ARM includes a larger set of drivers than the x86 build, it may be feasible to update the ffmpeg build script (which is equivalent to the x86 build) to use them.
If that's the case, let me know!
Any additional drivers need to have an appropriate licence permitting distribution though.
Just trying (again) to explain the whole picture with the specific mesa libs and FFMpeg that you need for Kodi.
You have the generic mesa libs provided by Slackware ARM, that nowadays do support the Broadcom vc4 GPU acceleration (wasn't the case some 1-2 years ago and I'm still not sure to what extent the video HW decoding is), and that are the generic mainstream version. This mesa package is the one Slackware ARM provides for all supported devices and is not specifically designed, optimized and containing all the extra implementations for the Raspberry boards.
These mesa libs are the ones that the whole Slackware ARM is linked against (the programs that depend on mesa), including X and the provided FFMpeg.
Then you have the specific mesa libs, optimized by the Raspberry team, that are part of the "greater" userland package, found in /opt/vc and used as the main mesa libs in the Raspberry specific Raspbian distro.
These are also constantly fine tuned by the Raspberry Team according to the changes they perform to their firmware and maybe vc driver and I'm not sure how much of these changes are then upstreamed in the generic mesa libs, thus, I've always used these and didn't care about the generic mesa from Slackware ARM for my multimedia needs on Raspberry boards.
Overview:
https://elinux.org/Raspberry_Pi_VideoCore_APIs
For instance, these are the only ones containing the kronos OpenMAX libs -> on an up to date Slackware ARM -current system:
These are the two mesa libs that you'll need to have and make use of on your Slackware ARM system running on Raspberry, and that you need to switch between, according to your needs (running X or using Kodi&FFMpeg). It sucks, but it works. "Hiding" (uninstalling/reinstalling) the generic mesa libs was the only way I was able to build and use Kodi 18.x, because its build scripts automatically links it to the generic Slackware mesa libs if they are available. This sucks too, but it also works.
Now, as already mentioned, FFMpeg is the workhorse behind the Kodi Mediaplayer and it's the FFMpeg that needs to make use of all the Raspberry specific optimizations in order to provide good results. In your case, you got video choppiness presumably because the generic FFMpeg you're using, the one provided by Slackware ARM, doesn't use these Raspberry specific optimizations , in other words, it was built against the generic mesa libs. Which is normal.
For building a Raspberry optimized FFMpeg, you'll need to link it to the userland libs in /opt/vc for proper HW video playback acceleration, enable these Raspberry accelerations during the FFMpeg build with specific ./configure options and also make use of platform specific (SoC) optimizations - using the NEON SIMD (single instruction multiple data) architecture extension - FFMpeg contains assembler code for NEON
First, you'll need the userland in /opt/vc, then uninstall the Slackware ARM official FFMpeg, then grab the FFMpeg source code that was choose by the Kodi team for the Kodi 18.6 release - here you have a short HowTo https://www.linuxquestions.org/quest...7/#post5781476
It looks to be 4.0.4-Leia-18.4 - but better check in the source code of your Kodi 18.6 tree: https://github.com/xbmc/xbmc/blob/Le...FFMPEG-VERSION
and finally build and install it according to either:
1. the way I did it on my own (might be obsolete): https://www.linuxquestions.org/quest...ml#post5956641
- don't forget: https://www.linuxquestions.org/quest...ml#post6058232
2. the way the Kodi devs are doing it (might be also obsolete): https://www.linuxquestions.org/quest...5/#post5958276
- don't forget: https://www.linuxquestions.org/quest...ml#post6058232
3. check the Kodi 18.6 build scripts and learn/adapt if there are any changes in the way the Kodi team is building FFMpeg.
Then perform a "ldconfig", try to launch Kodi and check if it works with the new FFMpeg (it should, it's the 4.x version that is also provided by Slackware). If not, start to build Kodi again, it'll link automatically against this optimized FFmpeg.
Maybe Mplayer (and other apps that require FFMpeg) will also work with this FFMpeg version, if not, well, recompile them too.
Note that this is the "improper" way I managed to get FFMpeg build for Kodi, as shared and not built in inside Kodi, more background here: https://www.linuxquestions.org/quest...7/#post5781540
I've already mentioned in post #16 that @tarnow found a way to build FFMpeg inside Kodi (statically) and link the whole compilation against /opt/vc. That's an elegant solution, also the "designed" way, and you can still keep the Slackware ARM provided FFMpeg and won't need to switch between the mesa libs. Try to follow his process.
I'm fine with my way, I'm using these Raspberries headless (no X) and the ones for multimedia only running Kodi.
The FFMpeg package I built specific for Kodi 18.1 RC1, back in Feb 2019, and was mentioned (documented) in this thread looks linked to the following /opt/vc libs:
Then I moved to the ffmpeg-4.2.2.tar.xz, currently provided by Slackware ARM -current, checking if it contains some MMAL acceleration for the Broadcom vc4 by itself and learned the following:
- NEON SIMD acceleration should be enabled by default, because there is only a ./configure parameter to disable it: --disable-neon (disable NEON optimizations)
- there is a --enable-mmal (enable Broadcom Multi-Media Abstraction Layer (Raspberry Pi) via MMAL [no]) parameter that makes ffmpeg to link automatically (finally! don't need to specify this with LDFLAGS anymore) to the MMAL libs in /opt/vc, and when these are not available, the FFMpeg compilation bails out with: ERROR: mmal not found
If /opt/vc is available, the compilation will link to it automatically -> I could observe these in the compilation output:
- but then I discovered that you can enable MMAL with --enable-decoder=h264_mmal and --enable-decoder=mpeg2_mmal (MPEG2 HW acceleration is only enabled if you buy a license from Raspberry). These two parameters don't require the MMAL libs in /opt/vc, apparently, and the FFMpeg doc doesn't describe them - is it actually HW acceleration? Who knows...
I moved on, used the FFMpeg build script from the Slackware ARM - current repo, modified it to add the following MMAL & Kodi related ./configure parameters and built FFMpeg:
- MMAL related acceleration
Got the special FFMpeg package built and installed only to find out that my Kodi 18.1 - RC1 compilation form Feb 2019 isn't working anymore due to the Slack ARM -current changes. (Happy that I'm using the stable Slackware 14.2 for Kodi, -current would be a PITA, recompiling Kodi due to the frequent updates.)
Code:
# ldd /usr/local/lib/kodi/kodi-rbpi | grep found
libidn2.so.4 => not found
libhogweed.so.4 => not found
libnettle.so.6 => not found
libcdio.so.18 => not found
While still having my Kodi compilation installed, I was curious to see what it uses from the /opt/vc and got the following ldd output:
Removed Kodi 18.1 RC1 (no way I recompile that huge pile of **** again) and tried to use the freshly built FFMpeg for Mplayer under X, testing if the --enable-decoder=h264_mmal helps.
Started Mplayer, went into settings and chose to use FFMpeg as decoder, restarted Mplayer and played a movie 1080p-h264, only to find out that all 4 CPU cores were maxed out and the playback was kind of a slide show - unwatchable.
Conclusion, so far, both FFMpeg & Kodi need the MMAL libs in /opt/vc for proper MMAL HW acceleration. I don't know if there is any other (free/non specific) MMAL lib available that could be integrated by default in Slackware ARM -current and provide HW accelerated playback for the vc4 core.
Last edited by abga; 04-29-2020 at 10:03 PM.
Reason: Slackbuild = build script
While we're at it (Kodi 18.x), I learned that the latest pvr.hts add-on (useful for watching tvheadend content(DVB streams))doesn't build anymore and found out that the last version that does is 4.4.21, use the following code to build it:
Code:
cd /kit/kodi-slack-build/addons-18/
wget https://github.com/kodi-pvr/pvr.hts/archive/4.4.21-Leia.tar.gz
tar -xzpf 4.4.21-Leia.tar.gz
cd /kit/kodi-slack-build/addons-18/pvr.hts-4.4.21-Leia/
cmake -DCMAKE_INSTALL_PREFIX=/usr/local
make && make install
ldconfig
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
