[SOLVED] Slackware ARM Raspberry Pi - armv6 and armv7 - optimized FFMPEG with HW Acceleration
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.
FWIW,
On a Pi, I once wanted "autologin", in terminal only (run level 3).
I ended up putting an
Code:
/bin/login -f <username> &
to the end of /etc/rc.d/rc.local
It helped me get an tty login so I could have conky run, since once the user is "logged in" each and every startup procedure is invoked as well.
I used .bashrc
my2c
I have a script where it will automatically log in the user after boot from runlevel 3 by adding an entry on my /etc/inittab. I remember years ago setting up an application (not a desktop or window manager) when running startx. I'm drawing a blank now. Need to do some more digging.
I'm not starting kodi automatically at system boot but using lirc (irexec) to start it with the remote control. You can always use rc.local to start kodi ( create a kodi start script in your /home/kodi first):
Code:
su kodi -c /home/kodi/kodi-start
- more hints / script details on the Kodi thread (if asked first)
I'm not starting kodi automatically at system boot but using lirc (irexec) to start it with the remote control. You can always use rc.local to start kodi ( create a kodi start script in your /home/kodi first):
Code:
su kodi -c /home/kodi/kodi-start
- more hints / script details on the Kodi thread (if asked first)
Blah! I shouldn't be asking question so early in the morning before having coffee.
Blah! I shouldn't be asking question so early in the morning before having coffee.
Don't worry, the ffmepg&Kodi building and using on ARM is a little complex/confusing
Kodi doesn't need X to be launched and running, and on these little/performance-weak ARM boards, due to the overhead that X is creating, it's not even recommended to have it running while using Kodi. Additionally, you need the Raspberry Pi modified and adapted mesa libs (the ones that are also needed for this FFmpeg build). Slackware ARM provides you with the generic mesa libs in /usr/lib and X is using those, Kodi needs the special ones provided by Raspberry Pi in /opt/vc, again the very ones that are also used for this FFmpeg build: https://github.com/raspberrypi/userland
Basically you'll end up with two mesa libs versions and you also need to switch between them for using either X or Kodi. I remember trying to substitute the Slackware ARM stock mesa libs with the ones provided by Raspberry Pi and failed, then dumped the whole idea because it didn't make sense.
You'll get these details in the Kodi thread I created and referred to in my previous post. That's why I invited you to post on that thread and I'll be happy to reply/help on topic.
Are we missing an auto-login for Slackware thread now?
I phrased my question wrong. I have been doing auto-login for years. I should have asked how to automatically start kodi when executing startx. I know I've done it before.
Don't worry, the ffmepg&Kodi building and using on ARM is a little complex/confusing
Kodi doesn't need X to be launched and running, and on these little/performance-weak ARM boards, due to the overhead that X is creating, it's not even recommended to have it running while using Kodi. Additionally, you need the Raspberry Pi modified and adapted mesa libs (the ones that are also needed for this FFmpeg build). Slackware ARM provides you with the generic mesa libs in /usr/lib and X is using those, Kodi needs the special ones provided by Raspberry Pi in /opt/vc, again the very ones that are also used for this FFmpeg build: https://github.com/raspberrypi/userland
Basically you'll end up with two mesa libs versions and you also need to switch between them for using either X or Kodi. I remember trying to substitute the Slackware ARM stock mesa libs with the ones provided by Raspberry Pi and failed, then dumped the whole idea because it didn't make sense.
You'll get these details in the Kodi thread I created and referred to in my previous post. That's why I invited you to post on that thread and I'll be happy to reply/help on topic.
In my first post, the one I cannot edit anymore now, I suggested to use 16bit color depth for best performance. I did it because at the time I wrote the guide the support for 24 bit color in the firmware for the Raspberry Pi platform was broken.
It works now and I'd advise you to put the following color depth settings in your /boot/config.txt
In the original HowTo I focused on the encoding HW acceleration for libx264 by using the CPU (SIMD) NEON capabilities (only applicable to Raspberry Pi 2B/3B/3B+ - ARMv7/ARMv8).
However, there is another, apparently faster alternative by using the OpenMAX libraries to control the HW H264 encoding core of the VideoCore GPU (applicable to all Raspberry Pi boards). https://raw.githubusercontent.com/FF...ster/Changelog
Quote:
- Generic OpenMAX IL encoder with support for Raspberry Pi
This ffmpeg h264_omx encoder engine is already available starting with ffmpeg 3.1.X and you can enable it by adding the following parameters to the existing long string for ./configure in post #1:
Code:
--enable-omx --enable-omx-rpi
After the ffmpeg compilation and installation you can check the results with:
Code:
ffmpeg -encoders | grep h264_omx
This h264_omx looks limited in accepting any quality related parameters:
Code:
ffmpeg -h encoder=h264_omx
#result:
.....
Encoder h264_omx [OpenMAX IL H.264 video encoder]:
General capabilities: delay
Threading capabilities: none
Supported pixel formats: yuv420p
h264_omx AVOptions:
-omx_libname <string> ED.V.... OpenMAX library name
-omx_libprefix <string> ED.V.... OpenMAX library prefix
-zerocopy <int> E..V.... Try to avoid copying input frames if possible (from 0 to 1) (default 0)
I was actually looking after a real-time HW accelerated transcoding option while recording transponder streams with tvheadend and learned that it's not really possible. Then tried to use ffmpeg to postprocess (transcode/scale from 1080p to 720p) the recorded streams and found out that h264_omx is helpful, more efficient, but the output quality is really poor.
Nevertheless, there are reports that this h264_omx is really useful for encoding raw video inputs, that's transcoding and streaming a tvheadend stream (gstreamer), a webcam input, etc. https://tvheadend.org/boards/5/topics/13892?page=6 https://www.raspberrypi.org/forums/v...c.php?t=152499
+ google after h264_omx for more info/examples
This discussion is also interesting: https://www.reddit.com/r/raspberry_p...g_with_ffmpeg/
The same error with OpenMax, headers are missing. The shared objects & headers (/opt/vc/) were copied over from a Raspbian install, perhaps you could fill me in how these were supposed to come to Slackware? I never saw any mention of these GLES libs in the SARPI readme.
The condition that fails is 'check_lib'. It fails with 'no opengl found' if none of the four header options are located.
The first thing it looks for is glx.h. /usr/lib/GL/glx.h exists but it includes X11 headers which my bare minimum xorg-free Slackware does not have.
windows.h looks to be Windows specific.
The two last options in check_lib headers both have a the linker option: "-framework OpenGL" which the linker does not have. Someone mentioned on IRC that it's for OSX.
Everything compiles fine here on a Pi2B (same as Pi3, just the compiler flags differ) on Slackware ARM -current updated on Aug 17 2018.
Code:
wget http://director.downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2018-06-29/2018-06-27-raspbian-stretch-lite.zip
unzip 2018-06-27-raspbian-stretch-lite.zip
# get /opt/vc from the image and put it in /opt/vc, run ldconfig
wget https://github.com/xbmc/FFmpeg/archive/3.1.9-Krypton-17.4.tar.gz
tar -xzpf 3.1.9-Krypton-17.4.tar.gz
cd FFmpeg-3.1.9-Krypton-17.4/
export LDFLAGS="-L /opt/vc/lib/"
./configure --extra-cflags='-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' --extra-cxxflags='-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard' --disable-devices --disable-sdl --disable-ffprobe --disable-ffserver --disable-doc --disable-w32threads --enable-ffplay --extra-libs=-ldl --enable-shared --enable-libass --disable-devices --enable-mmal --enable-hwaccel=h264_mmal --enable-opengl --enable-neon --enable-gnutls --enable-libvorbis --enable-muxer=ogg --enable-encoder=libvorbis --enable-nonfree --enable-libx264 --enable-gpl --enable-runtime-cpudetect --enable-postproc --enable-bzlib --enable-gnutls --enable-muxer=spdif --enable-muxer=adts --enable-muxer=asf --enable-encoder=ac3 --enable-encoder=aac --enable-encoder=wmav2 --enable-protocol=http --enable-encoder=png --enable-encoder=mjpeg --enable-nonfree --enable-pthreads --enable-pic --enable-zlib --disable-mipsdsp --disable-mipsdspr2
Inspecting your log at http://termbin.com/uw7k I found a redundancy in my long ./configure line (doesn't do any harm - cannot edit my original post anymore), I used twice: --enable-gnutls
What you added in your configuration was:
Success, ffmpeg with openmax seems to function. There was a worrying warning that --enable-hwaccel=h264_mmal did not match anything but mpv-player says ffmpeg uses hardware acceleration and CPU/memory in htop stays at 0% while playing a h264 video. -- When mpv-player was compiled/configured, for the '--enable-rpi' configuration option to pass, the library libX11 *had* to be installed. Conclusion: libX11, libxshmfence, libXdmcp, libXau & libxcb is required by OpenGL even though it might not be used. -- PS. mpv-player did not play video without the --rpi-osd=no argument.
Glad you made it. As officially recommended, you should install the whole Slackware ARM distribution to make sure you have all required libs. On the Raspberry boards, when installing Slackware ARM, I only opt out KDE, KDEI and the K (kernel).
On your mpv compilation, I do remember having issues with the latest mpv git release and followed this tutorial (cut the Debian dependencies sections at the beginning): https://nwgat.ninja/compiling-mpv-wi...-1-2-3-zero-2/
Went for mpv v0.20.0:
Code:
wget https://github.com/mpv-player/mpv/archive/v0.20.0.tar.gz
tar -xvzpf v0.20.0.tar.gz
cd mpv-0.20.0
./bootstrap.py
./waf configure
./waf build -j4
#create a package or just install it
./waf install
I'd like to add that you should update the Raspberry provided userland, either by extracting it from a Raspbian image (if using Pi2B or Pi3B(+)) or by downloading the sources and compiling it, the build takes 15 minutes on a Pi2B.
It's constantly improved & patched.
See post #1 ,section:
___VC-USERLAND___
The compiler flags described in that procedure to be added in CMakeLists.txt, respectively:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.