gstreamer: update to 1.28.1 (Kooha: update to 2.3.1)

[Rutpiv]

Testing the changes

• I tested the changes in this PR: briefly

Local build testing

• I built this PR locally for my native architecture (x86_64)
• I built this PR locally for these architectures using specific masterdirs:
  • x86_64-musl
  • i686
• I built this PR locally for these architectures (crossbuilds):
  • aarch64
  • aarch64-musl
  • armv7l
  • armv7l-musl
  • armv6l
  • armv6l-musl

[Rutpiv]

While looking into the CI failure, I noticed that xlint flags qmake_default_version as a custom variable, even though this variable is already part of the qmake build-helper workflow.

qmake_default_version is referenced in:

• the qmake5.sh and qmake6.sh build-helpers
• the sourcepkg.sh environment setup script

However, it does not seem to be recognized by xlint’s variable whitelist, which results in a warning when it is set in the template.

What would be the preferred way forward here?

• Add qmake_default_version to xlint’s recognized variables
• Keep the template as-is, since this variable has historically been used this way
• Or adopt another approach that maintainers consider more appropriate

I’m happy to adjust the template or make a follow-up modification based on the preferred approach.

[classabbyamp]

if it's used by a build style, it should be in xlint

[Rutpiv]

Thanks for confirming. I’ll follow up with a PR to update xlint to recognize qmake_default_version.

[Rutpiv]

Given that GStreamer 2.18.0 has been released upstream recently, I’d like to ask for guidance before proceeding further.

Would you prefer updating this PR to target the new 2.18.x major release, or keeping it on the current 1.26.x series and waiting for an initial stabilization/follow-up release before migrating?

I’m happy to adjust based on the preferred direction.

[Duncaen]

I would go for the latest release.

[Rutpiv]

Thanks!

While checking 2.18.x, I noticed gstreamer-vaapi doesn't have a matching release yet.

Would it make sense to keep everything on 1.26.11 for now and move to 2.18.x once all components are available?

[Duncaen]

No idea if if that matters, if I'm uncertain I would look at other distributions, alpine and arch seem to ship 2.18, so that would probably be fine.

[Rutpiv]

Updated to GStreamer 1.28.1 as suggested.

Rebuilt for all architectures from my first message (native x86_64, x86_64-musl, i686, crossbuilds for aarch64/armv7l/armv6l + musl variants). All builds passed.

Runtime testing on x86_64 confirmed:

• All plugins load without errors
• Audio/video pipelines work (audiotestsrc, FLAC, H.264, H.265)
• VA-API hardware decoding works via the va plugin (vah264dec/vah265dec)
• VA-API hardware encoding works on both Intel (vah264lpenc) and AMD (varenderD129h264enc/h265enc)
• gst-libav, gst1-python3, GES, and RTSP elements all functional

Dropped gstreamer-vaapi — per the 1.28 release notes (https://gstreamer.freedesktop.org/releases/1.28/), it has been removed upstream in favour of the va plugin in gst-plugins-bad, which is working correctly.

Refreshed the sndio.patch for gst-plugins-base1. The old patch broke with the upstream rename of meson_options.txt to meson.options. Pulled the updated patches from OpenBSD ports and verified the build on x86_64.

Added dejavu-fonts-ttf to checkdepends for gst-plugins-base1, as some tests expect a TTF font to be available in the test environment.

Also updated Kooha, which previously depended on gstreamer-vaapi and now pulls gst-plugins-bad1 instead.