[SOLVED] Slackware ARM Raspberry Pi - armv6 and armv7 - optimized FFMPEG with HW Acceleration

stormtracknole · 02-05-2018, 04:38 PM

Quote:

Originally Posted by SCerovec

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.

abga · 02-06-2018, 01:32 AM

Dear fellow Slackers, can we move this discussion to the appropriate thread? Thank you

https://www.linuxquestions.org/quest...hf-4175613852/

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)

stormtracknole · 02-06-2018, 06:22 AM

Quote:

Originally Posted by abga

Dear fellow Slackers, can we move this discussion to the appropriate thread? Thank you

https://www.linuxquestions.org/quest...hf-4175613852/

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.

SCerovec · 02-09-2018, 03:19 PM

Are we missing an auto-login for Slackware thread now?

abga · 02-10-2018, 09:50 AM

Quote:

Originally Posted by stormtracknole

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.

stormtracknole · 02-12-2018, 07:27 PM

Quote:

Originally Posted by SCerovec

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.

stormtracknole · 02-12-2018, 07:28 PM

Quote:

Originally Posted by abga

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.

Thank you! I'll direct my questions there.

abga · 04-22-2018, 11:05 AM

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

Code:

framebuffer_depth=24

or, if you want to go 32 bit:

Code:

framebuffer_depth=32
framebuffer_ignore_alpha=1

abga · 07-29-2018, 09:48 PM

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/

ansic · 08-16-2018, 10:18 PM

Rpi3, slackwarearm-current hf.
Compiling ffmpeg fails due to OpenGL headers missing.

Here is the config.log: http://termbin.com/uw7k

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.

ansic · 08-16-2018, 11:19 PM

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.

abga · 08-18-2018, 11:51 AM

@ansic

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:

Code:

 --disable-gnutls
 --enable-openssl
 --disable-libass
 --disable-ffserver

and I don't believe any of these extra parameters could have caused your failure (not sure about what --enable-openssl requires).

I believe your issue is related to the environment, don't forget to set the LDFLAGS var pointing to /opt/vc/lib/:

Code:

LDFLAGS="-L /opt/vc/lib/"

And put:
/opt/vc/lib
in:
/etc/ld.so.conf
and issue:
ldconfig
before you start configuring/compiling ffmpeg.

If you only need the kernel+firmware+vc-libs get the smaller Raspbian Lite image:
https://downloads.raspberrypi.org/raspbian_lite/images/

ansic · 08-19-2018, 02:27 PM

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.

abga · 08-19-2018, 03:45 PM

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

abga · 01-12-2019, 04:24 PM

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:

Code:

-march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft

are for Pi1 / Pi0.

If you compile it for Pi2B, use:

Code:

-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard

And for Pi3B:

Code:

-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard

Don't add /opt/vc/bin in /etc/ld.so.conf - my mistake, sorry.