rpidistro-vlc: Upgrade to latest, 3.0.22, upstream

[gizahNL]

Recipe has been changed to better reflect OE VLC recipe

The biggest feature is full HW acceleration when using v3d driver, with zero copy video output via vout_drm

Compilation has been tested both with and without v3d driver setting.

[EasyIP2023]

@gizahNL Thank you so much for picking up the mantel of responsibility! :)

Haven't had the motivation since I've mostly been working with x64 cpu's for the past 3 years.

[agherzan]

Huge work. Thanks for taking this.

[gizahNL]

Huge work. Thanks for taking this.

My pleasure ;) Necessity motivates! :)

I'm not sure the failing tests are related to my MR, the pi0-wifi systemd tests fails on psplash, the DCO test with an unknown error (it's not displayed)

[gizahNL]

Could someone take a look at this? Would be nice if it got merged ;)

(yes I understand the patchset is huuuuge, perhaps comparing with the "official" vlc patchset from RPI would be good?)

[OldManYellsAtCloud]

One more comment, with 2 thoughts:

1. After fixing the do_configure, compilation failed with the following error:

codec/avcodec/audio.c: In function 'InitAudioDec':
codec/avcodec/audio.c:274:27: error: 'FF_PROFILE_UNKNOWN' undeclared (first use in this function); did you mean 'AV_PROFILE_UNKNOWN'?
  274 |     if( avctx->profile != FF_PROFILE_UNKNOWN )
      |                           ^~~~~~~~~~~~~~~~~~
      |                           AV_PROFILE_UNKNOWN
codec/avcodec/audio.c:274:27: note: each undeclared identifier is reported only once for each function it appears in

I'm using the following packageconfig (which is the default from the recipe): live555 dv1394 fontconfig fluidsynth freetype png x11 x264 gles2 notify udev alsa harfbuzz jack neon v4l2 drm
The only thing I changed was adding gtk3 to the dependencies of the notify pkgconfig.

2. These is just some semi-loud musing: I'm not sure if it is better to vendor 40+ patches in the layer instead of creating a small extra task in the recipe before do_config that loops through all these patches in from the debian folder, and applies them. I understand that the vendored versions are verbatim copies, but some of them are quite irrelevant - like the first one, fixing risc-v linking, in an rpi-focused layer :)
   I don't consider this a blocker for this, but would be curious what you and others think.

[gizahNL]

One more comment, with 2 thoughts:

1. After fixing the do_configure, compilation failed with the following error:

codec/avcodec/audio.c: In function 'InitAudioDec':
codec/avcodec/audio.c:274:27: error: 'FF_PROFILE_UNKNOWN' undeclared (first use in this function); did you mean 'AV_PROFILE_UNKNOWN'?
  274 |     if( avctx->profile != FF_PROFILE_UNKNOWN )
      |                           ^~~~~~~~~~~~~~~~~~
      |                           AV_PROFILE_UNKNOWN
codec/avcodec/audio.c:274:27: note: each undeclared identifier is reported only once for each function it appears in

I'm using the following packageconfig (which is the default from the recipe): live555 dv1394 fontconfig fluidsynth freetype png x11 x264 gles2 notify udev alsa harfbuzz jack neon v4l2 drm The only thing I changed was adding gtk3 to the dependencies of the notify pkgconfig.

2. These is just some semi-loud musing: I'm not sure if it is better to vendor 40+ patches in the layer instead of creating a small extra task in the recipe before do_config that loops through all these patches in from the debian folder, and applies them. I understand that the vendored versions are verbatim copies, but some of them are quite irrelevant - like the first one, fixing risc-v linking, in an rpi-focused layer :)
   I don't consider this a blocker for this, but would be curious what you and others think.

Yeah I agree, it should either automatically apply the patches from the debian folder. Or some tooling should be added to meta-raspberrypi that automates the pulling of patches, vendoring & testing them. Either way works.
Right now I just updated as-is, and added meta-oe patches & followed that recipe as much as possible, such that the divergence becomes less.

I think the "best" solution would be to update VLC in meta-oe and rebase patches here onto that, it's a lot of work though (and I'm not sure I can convince my employer of that ;) )

Ideally I'd really like to see this get merged though ;) It saves me from having to maintain a local fork as well :P

[OldManYellsAtCloud]

Thanks for the fixes - it seems that my previous compilation error disappeared (thinking back, probably that was a user error on my end, by not setting all required PREFERRED_PROVIDERs) - but now I have a new error during do_compile, it seems that it tries to use libdrm from the build machine:

../doltlibtool  --tag=CC   --mode=compile aarch64-oe-linux-gcc  -mcpu=cortex-a72+crc+nocrypto -mbranch-protection=standard -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security --sysroot=/yocto/vlctest/build/tmp/work/cortexa72-oe-linux/rpidistro-vlc/3.0.22/recipe-sysroot -DHAVE_CONFIG_H -I. -I..  -DMODULE_STRING=\"$
(p="video_output/drmu/libdrm_vout_plugin_la-drmu_fmts.lo"; p="${p##*/}"; p="${p#lib}"; p="${p%_plugin*}"; p=$(echo "$p"|sed 's/-/_/g'); p="${p%.lo}"; echo "$p")\" -D__PLUGIN__  -I./a
ccess -I./codec -I../include -I../include   -pthread -I/usr/include/libdrm  -O2 -g -fcanon-prefix-map  -ffile-prefix-map=/yocto/vlctest/build/tmp/work/cortexa72-oe-linux/rpidistro-vl
c/3.0.22/sources/rpidistro-vlc-3.0.22=/usr/src/debug/rpidistro-vlc/3.0.22  -ffile-prefix-map=/yocto/vlctest/build/tmp/work/cortexa72-oe-linux/rpidistro-vlc/3.0.22/sources/rpidistro-v
lc-3.0.22=/usr/src/debug/rpidistro-vlc/3.0.22  -ffile-prefix-map=/yocto/vlctest/build/tmp/work/cortexa72-oe-linux/rpidistro-vlc/3.0.22/recipe-sysroot=  -ffile-prefix-map=/yocto/vlcte
st/build/tmp/work/cortexa72-oe-linux/rpidistro-vlc/3.0.22/recipe-sysroot-native=  -pipe -I/yocto/vlctest/build/tmp/work/cortexa72-oe-linux/rpidistro-vlc/3.0.22/recipe-sysroot/usr/inc
lude/drm  -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wvolatile-register-var -Wformat -Wformat-security -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes -Werror-imp
licit-function-declaration -Winit-self -Wlogical-op -Wshadow=local -fvisibility=hidden -O3 -fno-math-errno -funsafe-math-optimizations -fno-rounding-math -fno-signaling-nans -fcx-lim
ited-range -funroll-loops -fomit-frame-pointer -fstack-protector-strong -c -o video_output/drmu/libdrm_vout_plugin_la-drmu_fmts.lo `test -f 'video_output/drmu/drmu_fmts.c' || echo '.
/'`video_output/drmu/drmu_fmts.c
cc1: error: include location "/usr/include/libdrm" is unsafe for cross-compilation [-Werror=poison-system-directories]

[OldManYellsAtCloud]

I think this is the culprit for the libdrm problem during do_compile. Should this rather use the cflags from pkg-config, $(DRM_CFLAGS) or similar?