draft: ffmpeg5 split

[zlice]

[ci skip]

Testing the changes

• I tested the changes in this PR: YES

I have conflicting changes from intel packages and don't want to mess with my system. If it makes sense I'll move these changes here like I originally intended. ffmpeg5 makes Intel vaapi easier and only rely on oneVPL iirc.

I do not use 80%+ of these packages. I may be able to run Blender, and I use shotcut.

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, x86_64

Discussion

Continuation of #36315 - thx tibequadorian :)

It was suggested to make ffmpeg version 5 and 'copy' (create a new?) ffmpeg4 package, and that seems to work well.

As stated, I haven't and probably won't test most of these packages, hoping for others to voice in on what's working.

A few months back (and now) afaict everything has been compiling with ffmpeg5 except for the few problem packages still using ffmpeg4 (below). Can add to the ffmpeg4 list as a incompatible package is found.

libavresample is deprecated, but marked as a dependency when trying to build other packages and install ffmpeg(5). I think the right way to handle this is make a meta package and the add to removals?

gstreamer 1.22.1 updates could go before this

Commit naming / misc

ffpmeg4 isn't "new", not sure what the commit messages should be really for the 4 and 5 split. Additionally xlint complains about ffmpeg4 revision being 3 and not 1 because it's a "new" package, I assume that's right but not sure.

Not sure how commits should be separated. ffmpeg4/5 could be split and all the rev bumps included (otherwise it's over 100 commits). opencv was updated to 4.7.0 for ffmpeg5 so I figured that should be a separate commit?

I wouldn't mind moving the intel packages into here under another commit. That just got a potential fix that may allow merging but I imagine moving to ffmpeg5 will change and even remove some of those packages. (I won't really test these changes without Intel vaapi either way.)

Maintainer for previous ffmpeg(4) was orphaned, I can put my name in there if that matters, though I don't exactly see myself keeping up on ffmpeg.

STILL FFMPEG4

These are a mix of emulators, games and/or older packages.

• attract (multiple patches in master)
• audacity (3.2.x should work but void is missing some libs? vst3sdk?)
• ccextractor (master patches? no release)
• vice
• mlt
• synfig (mlt)
• tvheadend
• ssr
• spek-alternative
• ppsspp
• olive
• moc
• mediastreamer
• libextractor
• idjc
• hedgewars
• handbrake
• ffmpegthumbnailer
• ffmpegthumbs
• deadbeef
• omxplayer
• qtav (fork has ffmpeg 5 patch - https://github.com/cmguo/QtAV)
• qt5-webengine (need patch and version bump. may work? if not gentoo has a patch? https://bugs.gentoo.org/831487)
• vlc (vlc4 will support ffmpeg5, there's a patch to build 3.x with ffmpeg5 but it will lack vaapi)
• osg (OpenSceneGraph plus xine-lib)
• ytmdl ? not sure but it uses python3-ffmpeg-python which being 6-8yr old I imagine is ffmpeg4

HAVE NOT BUILT YET (big-uns)

• omxplayer (rpi only?)
• kodi
• electron19
• qt5-webengine - some patches and version update
• digikam (qt5-webengine)
• chromium - some patches but vaapi doesnt seem to be working (use special flags)

UPDATED (for ffmpeg5)

• unpaper: update to 7.0.0.

• guvcview: update to 2.0.8.

• qt5: update to 5.15.8

• qt5-webengine: update to 5.18.13

• shiboken2: revbump for qt5.15.8 (patch)

• python3-pyside2: update to 5.15.8 (patch)

[paper42]

fpmeg4 isn't "new", not sure what the commit messages should be really for the 4 and 5 split

It is a new package

Not sure how commits should be separated. ffmpeg4/5 could be split and all the rev bumps included (otherwise it's over 100 commits). opencv was updated to 4.7.0 for ffmpeg5 so I figured that should be a separate commit?

as mentioned in CONTRIBUTING.md, use one commit per package

Testing the changes

I tested the changes in this PR: NO

I have conflicting changes from #41132 and don't want to mess with my system.

I don't think it's a good idea to blindly do a complex update like this and not even test it.

[paper42]

due to the large amount of random issues I found, I am not confident that the parts of this PR that I didn't check (like the huge lists of dependencies) don't contain similar random mistakes. Even if everything gets fixed, I don't think we should merge this without carefully checking every single line which is probably way harder than just doing the update again.

[sgn]

I'm advocate for not using major version of package as suffix for libraries' package name, instead, I think those libaries should use its SOVERSION for pkgname, like Debian.
For example, the new libswscale4 should be named libswscale5, the one splited from ffmpeg5 will be named libswscale6.

[zlice]

have a list of some packages that didn't build last night, i'll look at them today(?)

For example, the new libswscale4 should be named libswscale5, the one splited from ffmpeg5 will be named libswscale6.

not sure what you mean, rename libxxx's to lib*5 and have lib*5 and lib*4?

[zlice]

K everything should be building except the few outliers I added to OP.

Also, should we change this message? # audacity also needs to be bumped when a new ffmpeg version bumps libavformat's soname! seems like anything with ffmpeg-devel and I'm not 100% convinced that covers it (ytmdl doesn't have 'devel' but ffmpeg in 'depends')

[zlice]

fwiw, all ffmpeg5 packages seem to compile with a few extra patches for ffmpeg6

not sure if skipping 5 to 6 is fine (6 has all the av1 codec stuff i personally want)

note: still haven't gotten around to testing

[zlice]

installed ffmpeg6 last night https://github.com/zlice/void-packages/tree/ffmpeg6-split

chromium is the only exception so far i think

chrome just needs flags i guess? chromium --use-vulkan --enable-features=VaapiVideoEncoder,VaapiVideoDecoder,CanvasOopRasterization --disable-features=UseChromeOSDirectVideoDecoder,UseSkiaRenderer --disable-reading-from-canvas --webgpu --ignore-gpu-blocklist --enable-raw-draw --disable-gpu-driver-workarounds --use-gl=egl works for me

[zlice]

Have been running ffmpeg6 fine for a bit now, though on top of my gstreamer and intel packages PRs mentioned (switched intel stuff to oneVPL). Want to double check commits on the 6 branch even without gstreamer/intel changes.

This does touch a lot and is relying on other big changes. What should next steps be? (will probably make another PR with the 6 branch at some point)

[zlice]

Closing this in favor of #43761 since I have been running ffmpeg6 for a month now.