You are not logged in.
Hi everyone!
Does anybody know if VLC supports HVEC/x265 hardware acceleration on the rpi4 with arm64? (not armhf)
I've tried installing Devuan and then using the vlc packages for arm64 from http://archive.raspberrypi.org/debian/ but I'm not getting hardware acceleration... Is this supposed to work? Maybe I should replace some Devuan-provided libraries with raspbian-provided ones?
Thanks for your assistance!
(With the 32-bit Raspbian VLC works perfectly)
Offline
hello joril,
I don't own a rpi4, but the generic build of VLC for arm64 will not bring hardware acceleration with it for rpi, or any other board, it depends always in libraries that are related with that board/SoC.. in the arm world each vendor implements things in a different way, so they are not compatible
Kodi, and Raspbian( and maybe others), offers prebuild libraries and also hardware acceleration( but because they had built it specifically for that hardware.. ).
I don't know the level of acceleration support that we can get with VLC, or others, but I believe at least x264 is possible to some extent, maybe some stuff is yet done in the CPU, but it should play reasonably well..
I believe the solution could be to build VLC yourself, with raspberrypi userland libraries..
1) Start by building the userland libraries for RPI:
git clone https://github.com/raspberrypi/userland.git
cd userland
/buildme --native
The libraries/headers should land in: '/opt/vc'
2) Update the dynamic linker..
echo "/opt/vc/lib" >> /etc/ld.so.conf
ldconfig -vv
3) Then build VLC or FFmpeg with support for RPi( will take advantage of the RaspberryPi userspace Libraries built above.. ):
a) Build VLC..
VLC has lots of dependencies,
So I just searched for RPI Build, and this tutorial is from 2017, its better to get the last VLC source code, to build..
On those cflags/cxxflags , you can compile for '-mcpu=cortex-a72'( rpi4 ), or if compiling for a generic arm64 '-mcpu=cortex-a53', the binary will work on rpi3 and rpi4 in this last case..
b) You can also build ffmpeg, for players that use it..
I found this tutorial .
One possible improvement would be to package it and put it in the repos, the userspace libraries for RPi, and the VLC package..
hope it helps
tux
Last edited by tuxd3v (2021-01-04 10:06:37)
Best Regards,
tux
Offline
Great, I'll try that, many thanks for your time!
Offline
For the record, to compile userland I had to follow this guide:
sed -i 's/__bitwise/FDT_BITWISE/' userland/opensrc/helpers/libfdt/libfdt_env.h
sed -i 's/__force/FDT_FORCE/' userland/opensrc/helpers/libfdt/libfdt_env.h
cd userland
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release -DARM64=ON ../
make -j4 && make install
Offline
3) Then build VLC or FFmpeg with support for RPi( will take advantage of the RaspberryPi userspace Libraries built above.. ):
a) Build VLC..
VLC has lots of dependencies,
So I just searched for RPI Build, and this tutorial is from 2017, its better to get the last VLC source code, to build..On those cflags/cxxflags , you can compile for '-mcpu=cortex-a72'( rpi4 ), or if compiling for a generic arm64 '-mcpu=cortex-a53', the binary will work on rpi3 and rpi4 in this last case..
I had to fiddle a bit with the "configure" invocation (remove -mfpu=neon-vfpv4 and -mfloat-abi=hard, add --disable-libva) to get it to compile... Sadly, still no HVEC acceleration
Offline
I had to fiddle a bit with the "configure" invocation (remove -mfpu=neon-vfpv4 and -mfloat-abi=hard, add --disable-libva) to get it to compile... Sadly, still no HVEC acceleration
That could be a problem, because VA API is the one responsible to get acceleration in VLC
I don't know what extensions has the rpi4:
cat you check the cpuinfo
grep Features /proc/cpuinfo
maybe the compiler doesn't like this combination for arm64..
-mfpu=neon-vfpv4 - is armv7 related
-mfloat-abi=hard - this one I think its arch agnostic, i don't get why it gives error, maybe compiling for armv8, already implies hard-float.. but even so..
This options are very standard for armv8..
-march=armv8-a+simd+crc
-mtune=cortex-a53
One thing that maybe can create problems..
The compiled VLC, should use the same specs as the the libraries compiled in rpi userland..
or maybe the VLC code you downloaded require latest versions of some library that are not present in beowulf yet.. try getting a less recent version and see if it compiles without errors with va-api
Last edited by tuxd3v (2020-12-29 17:51:07)
Best Regards,
tux
Offline
That could be a problem, because VA API is the one responsible to get acceleration in VLC
Ouch X-) I disabled it because compilation was complaining about missing "EGL_LINUX_DRM_FOURCC_EXT" and other constants, and here https://www.raspberrypi.org/forums/view … 5#p1396812 someone said "You shouldn't need vaapi - that's an Intel API."
--disable-wayland didn't solve the issue
Offline
cat you check the cpuinfo
grep Features /proc/cpuinfo
Features : fp asimd evtstrm crc32 cpuid
try getting a less recent version and see if it compiles without errors with va-api
Ok I'll try right away, many thanks again
Offline
I'm trying compiling VLC 3.0.10 instead of 3.0.11, here's how I'm calling "configure":
CFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/mmal -I/opt/vc/include/interface/vchiq_arm -I/opt/vc/include/IL -I/opt/vc/include/GLES2 -mcpu=cortex-a72"
CXXFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/mmal -I/opt/vc/include/interface/vchiq_arm -I/opt/vc/include/IL -I/opt/vc/include/GLES2 -mcpu=cortex-a72"
LDFLAGS="-L/opt/vc/lib" ./configure --enable-omxil --enable-omxil-vout --enable-rpi-omxil --enable-gles2
and the result is:
libvlc configuration
--------------------
version : 3.0.10
system : linux
architecture : aarch64
optimizations : yes
vlc aliases : cvlc rvlc nvlc
No need for --disable-libva this time On to compilation...
Offline
Spoke too soon...
video_output/opengl/converter_vaapi.c: In function ‘vaegl_image_create’:
video_output/opengl/converter_vaapi.c:75:9: error: ‘EGL_LINUX_DRM_FOURCC_EXT’ undeclared
Offline
Tried every version up to 3.0.6 (released in jan 2019) but still no luck, same error
Last edited by joril (2020-12-30 09:50:22)
Offline
tuxd3v wrote:That could be a problem, because VA API is the one responsible to get acceleration in VLC
Ouch X-) I disabled it because compilation was complaining about missing "EGL_LINUX_DRM_FOURCC_EXT" and other constants, and here https://www.raspberrypi.org/forums/view … 5#p1396812 someone said "You shouldn't need vaapi - that's an Intel API."
--disable-wayland didn't solve the issue
You seem to be right, vaapi maybe its not used for raspberrypi.
They refer instead mmal
I also found a thread in videolan forums that say that rpi doesn't use vaapi..
For what I saw v3.0.3 was the version they were speaking of in the forum.. and complaining because debian updated to v3.0.6
Last edited by tuxd3v (2020-12-30 22:50:28)
Best Regards,
tux
Offline
For what I saw v3.0.3 was the version they were speaking of in the forum.. and complaining because debian updated to v3.0.6
I've tried compiling 3.0.3 too (had to add --disable-wayland and patch a line inside the x264 codec) but still no h265 acceleration
Maybe I could try building a 32bit image of Beowulf and use the vlc debs from Raspbian...?
Offline
tuxd3v wrote:For what I saw v3.0.3 was the version they were speaking of in the forum.. and complaining because debian updated to v3.0.6
I've tried compiling 3.0.3 too (had to add --disable-wayland and patch a line inside the x264 codec) but still no h265 acceleration
Maybe I could try building a 32bit image of Beowulf and use the vlc debs from Raspbian...?
You can build the binaries for 32 bits( like the instructions say ), if it fails,
C0rnelious has images for 64 bits
Devuan image builder - https://github.com/pyavitz/rpi-img-builder/tree/devuan
You can find sample images under release - https://github.com/pyavitz/rpi-img-builder/releasesAs far as I know all the usual suspects work. HDMI, Audio, Bluetooth, Wifi, Eth... etc.
If you find any bugs or have a request than open an issue at the hub.
Now supports - BCM2711, 2710, 2708.
You can give them a try..
if its not possible, then see all dependencies that raspbian has for vlc, and get those files from there
Best Regards,
tux
Offline
I don't think you are going to get "HVEC/x265 on the Raspberry Pi 4 with arm64" as the best I've been able to do is 1080p/x264 using MPV and MESA 20.3 and that's a frankenbuild of sorts. x265 always tends to stumble over its self, but I haven't tested MESA 21.0 as of yet, so maybe there is hope?
Offline
I've tried following the path "32-bit Devuan + vlc from Raspbian", but still no luck h264 works but only in full screen, h265 doesn't work at all... It throws errors about "CMA buf pool alloc buf failed" so I've tried fidgeting with the "cma=" parameter on cmdline.txt, but to no avail.
Offline
This 64-bit gentoo-on-rpi-64bit project may help ...
(unfortunately looking for a new maintainer now)
Offline
I've tried following the path "32-bit Devuan + vlc from Raspbian", but still no luck h264 works but only in full screen, h265 doesn't work at all... It throws errors about "CMA buf pool alloc buf failed" so I've tried fidgeting with the "cma=" parameter on cmdline.txt, but to no avail.
hello joril,
yeah it shouldn't be easy indeed..
While the kernel space indeed as seen tremendous advances,
The userspace is still lacking and it still depends on manual builds/hacks and such..
What are the mount of MB you added to the Contiguous Memory Allocator( cma )?
it should need at least 256MB,
I would, as a precaution, add 'cma=384M', its a kernel parameter usually set in the bootargs..
At least some people around ARM is using 384MB( but I believe its for different userpace tools..by other words different hardware, but its a nice consensus value for any device.. ), anyway it deserves a shot..
I don't hold my breath on it, because probably it won't work, but one needs at least to try..
Last edited by tuxd3v (2021-01-21 21:15:52)
Best Regards,
tux
Offline
Personally I think this approach is just silliness and what I mean by this is, that these boards "no matter what the manufacture may suggest" are a niche device. If you are interested in proper video playback, I would go with an OS that is specializing in this approach.
I wouldn't buy a toaster to cook a turkey and then act surprised when it didn't work.
I tend to lean towards Amlogic SoC's for video play back and use CoreELEC and just throw things at it like you would any commercial device: Chromecast, Firestick and Roku. This could also be done using the Pi4 and LibreELEC, but generally not as cost effective.
Offline