Skip to content

rpidistro-vlc: Upgrade to latest, 3.0.22, upstream#1576

Open
gizahNL wants to merge 1 commit into
agherzan:masterfrom
gizahNL:upgrade_vlc
Open

rpidistro-vlc: Upgrade to latest, 3.0.22, upstream#1576
gizahNL wants to merge 1 commit into
agherzan:masterfrom
gizahNL:upgrade_vlc

Conversation

@gizahNL
Copy link
Copy Markdown

@gizahNL gizahNL commented Feb 4, 2026

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
Copy link
Copy Markdown
Contributor

@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.

@gizahNL gizahNL changed the title RFC: rpidistro-vlc: Upgrade to latest, 3.22.0, upstream RFC: rpidistro-vlc: Upgrade to latest, 3.0.22, upstream Feb 12, 2026
Copy link
Copy Markdown
Owner

@agherzan agherzan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huge work. Thanks for taking this.

@gizahNL
Copy link
Copy Markdown
Author

gizahNL commented Feb 19, 2026

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 gizahNL changed the title RFC: rpidistro-vlc: Upgrade to latest, 3.0.22, upstream rpidistro-vlc: Upgrade to latest, 3.0.22, upstream Feb 23, 2026
Recipe has been changed to better reflect OE VLC recipe

Signed-off-by: Gijs Peskens <gijs.peskens@munisense.com>
@gizahNL
Copy link
Copy Markdown
Author

gizahNL commented May 6, 2026

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

This comment was marked as outdated.

stream_t *s = (stream_t *)vlclua_get_this(L);
- int n = luaL_checkint( L, 1 );
+ int n = luaL_checkinteger( L, 1 );
+ int n = luaL_checkintegereger( L, 1 );
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

luaL_checkintegereger ? Is this correct (and not a copy-paste error)? Same question for all other occurrences

ac_cv_path_MOC=${STAGING_BINDIR_NATIVE}${QT_DIR_NAME}/moc \
ac_cv_path_RCC=${STAGING_BINDIR_NATIVE}${QT_DIR_NAME}/rcc \
ac_cv_path_UIC=${STAGING_BINDIR_NATIVE}${QT_DIR_NAME}/uic \
"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nitpick: these variables usually go to CACHED_CONFIGUREVARS (though now I see that the vlc recipe in meta-oe uses the same... oh well)

udev \
alsa harfbuzz jack neon v4l2 drm \
"
inherit ${@bb.utils.contains('PACKAGECONFIG', 'qt5', 'qmake5_paths', '', d)}
Copy link
Copy Markdown
Contributor

@OldManYellsAtCloud OldManYellsAtCloud May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this and the other inherit directive be moved closer to each other?

libmtp libopus orc libsamplerate0 libusb1 schroedinger taglib \
tiff"

inherit autotools-brokensep features_check gettext pkgconfig mime-xdg
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bitbake grumbles a bit: WARNING: Recipe inherits features_check but doesn't use it

}

# This recipe packages vlc as a library as well, so qt4 dependencies
# can be avoided when only the library is installed.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that qt4 in the comment should be just qt, so it gets obsolete less frequently.

PACKAGECONFIG[dv1394] = "--enable-dv1394,--disable-dv1394,libraw1394 libavc1394"
PACKAGECONFIG[svg] = "--enable-svg,--disable-svg,librsvg"
PACKAGECONFIG[svgdec] = "--enable-svgdec,--disable-svgdec,librsvg cairo"
PACKAGECONFIG[notify] = "--enable-notify,--disable-notify, libnotify"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found this after my configure failure comment: the previous version also added gtk+3 as a dependency for notify, which is missing from this version. Adding it fixes do_configure on my machine (TM)

@OldManYellsAtCloud
Copy link
Copy Markdown
Contributor

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.

  1. 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.

char *buf = malloc(n);

if (buf != NULL)
--- a/modules/lua/libs/net.c
Copy link
Copy Markdown
Contributor

@OldManYellsAtCloud OldManYellsAtCloud May 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Apologies for the spam...)
Should this whole portion (for modules/lua/libs/net.c & co) of the patch be removed also? Looking at the source, I would assume that the changes are still required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants