FFmpeg 7.1 transition part 2

[robertkirkman]

Progress on #22502

Bumped packages

Packages that require bumping to be compatible with FFmpeg 7.

• handbrake: 1.9.0
  • patches copied from Debian Testing
  • reverted the "Dolby Vision RPU" feature because it depends on a custom build of FFmpeg with an API modified specifically for handbrake.
• ffplay: 7.1 to match ffmpeg

Patched packages

Packages that require patching to successfully build against FFmpeg 7.

• vlc + vlc-qt: patches copied from Debian Testing
• deadbeef: patch cherry-picked
• oshu: I wrote and tested the patch for this package by myself. It works for me, but hopefully it is good enough to work for everyone.

Recompiled packages

Packages that are revision-bumped to recompile against FFmpeg 7 with no other changes.

• audacious-plugins
• kf6-kfilemetadata
• kid3
• mgba
• mlt
• spek

Skipped packages

Packages that I suspect do not technically need to be revision-bumped (recompiled), because I suspect that they continue to fully work after updating the ffmpeg package to FFmpeg 7, without being recompiled.
A primary reason for me to suspect that is that the command pkg install -y $pkgname && for f in $(dpkg -L $pkgname); do ldd $f 2>/dev/null | grep libav; done prints nothing, for all of them. This strongly suggests, but does not absolutely guarantee, that they all use some methods of connecting to FFmpeg that do not require recompilation after major FFmpeg version updates.
If extra caution is wanted to make sure no revision bumps are missed and there is no possibility of a mistake, then maybe these should all be marked with revision bumps as well, just to be on the safe side.

• firefox
• thunderbird
• kdenlive
• shotcut

Difficult packages

These packages are supposed to be compiled against FFmpeg, but currently are not because it is very difficult for me to compile them against FFmpeg 7.
I have not yet found any existing operating system that shows an example of compiling python-torchaudio against FFmpeg 7,
but maybe there will be one soon, or if that doesn't happen then I could attempt to make patches for them by myself but it might take a long time.

• python-torchaudio
• python-torchvision

Confusing package

• waypipe

When I check, it appears that waypipe is not currently capable of calling FFmpeg API on Termux (regardless of whether the FFmpeg version is 6 or 7). This suggests that FFmpeg is not a true build or runtime dependency of waypipe on Termux yet. More details are explained in a comment in build.sh.

I am not great at Wayland or very experienced with it, I hope that someone who is familiar with Wayland or a contributor to Waypipe upstream could explain what is going on and if there is any workaround.

[twaik]

About python-torchaudio and python-torchvision. We always can package separate (frozen?) version only for these packages and make it available in $PREFIX/lib/$TERMUX_PKG_NAME and add -Wl,-rpath to LDFLAGS like we did for audacity.

[robertkirkman]

About python-torchaudio and python-torchvision. We always can package separate (frozen?) version only for these packages and make it available in $PREFIX/lib/$TERMUX_PKG_NAME and add -Wl,-rpath to LDFLAGS like we did for audacity.

Thank you for pointing that out, after you said that I noticed that Audacity has already been supporting FFmpeg 7 since Audacity version 3.6. In order to test that I reverted most of 04dd0b7 locally and inserted ffmpeg 7.1 into TERMUX_PKG_DEPENDS (i tested replacing the audacity-ffmpeg package with the normal ffmpeg package), then tested the resulting package by downloading a .webm file using yt-dlp, then opening it in Audacity which is a test of FFmpeg-based importing in Audacity, then I clicked File->Export, then I clicked "FFmpeg export options" and selected .mp4 container with aac codec, which is a format I believe Audacity cannot export without calling FFmpeg, so that is a test of FFmpeg-based exporting in Audacity, then I used mpv to play the resulting .mp4 file and it sounds normal, so at least for this test, FFmpeg 7 is working on my device with Audacity in Termux:X11.

Should I remove audacity-ffmpeg and replace it with ffmpeg, then create a torch-ffmpeg package that moves the same workaround to the python-torchaudio and python-torchvision packages where it is needed instead?

That seems like possibly a good thing to wait a little while and put in a "part 3" PR, since this PR is already pretty large, and the changes to python-torchaudio, audacity and python-torchvision would be a slightly different category from most of the changes in this PR.

[twaik]

I do not think you should touch audacity-ffmpeg. It exists for some reason.

[robertkirkman]

The issue linked to by the comment has been closed for a long time,
audacity/audacity#2445
however I understand, it is difficult to identify exactly why it is there so it should be left to be on the safe side.

[TomJo2000]

Are we ready to merge this batch in the meantime?

[twaik]

Probably it will be better to replace vlc-qt's patch symlink with the following code in build.sh

termux_step_patch_package() {
	cd "$TERMUX_PKG_SRCDIR"
	for patch in $(find "$TERMUX_SCRIPTDIR/packages/vlc" -mindepth 1 -maxdepth 1 -name \*.patch | sort); do
		echo "Applying patch: $(basename $patch)"
		test -f "$patch" && sed -e "s%\@TERMUX_PREFIX\@%${TERMUX_PREFIX}%g" "$patch" | patch --silent -p1
	done
}

[TomJo2000]

Probably it will be better to replace vlc-qt's patch symlink with the following code in build.sh

termux_step_patch_package() {
	cd "$TERMUX_PKG_SRCDIR"
	for patch in $(find "$TERMUX_SCRIPTDIR/packages/vlc" -mindepth 1 -maxdepth 1 -name \*.patch | sort); do
		echo "Applying patch: $(basename $patch)"
		test -f "$patch" && sed -e "s%\@TERMUX_PREFIX\@%${TERMUX_PREFIX}%g" "$patch" | patch --silent -p1
	done
}

The symlinks work fine, why would a termux_step_patch_package() override be preferable?

[twaik]

To avoid messing with patches after each VLC update.

[TomJo2000]

To avoid messing with patches after each VLC update.

I'm not sure I follow.
The status quo is to make duplicate patches for vlc and vlc-qt.

I personally think the explicitness of the symlinks outweighs the benefit of automatically pulling in new patches.

[TomJo2000]

• mpv-x already bumped in 7133a43
• scrcpy already bumped in 68f384a
• opencv already bumped in 6ced900

[TomJo2000]

We should get this merged before even more of them get yoinked for acute issues.

[robertkirkman]

Are we ready to merge this batch in the meantime?

yes sorry i didn't know whether it needs my approval or not, if it looks ready to you then it's ready, and afterward I will make another PR with the revision bumps for firefox, thunderbird, kdenlive, shotcut, python-torchaudio and python-torchvision

[TomJo2000]

yes sorry i didn't know whether it needs my approval or not,

Well it's your PR, so I didn't wanna go over your head on this, but since sylirre and Grimler had started bumping some of the packages in this PR I felt it was best to get it merged now so we can have the related issues closed.

I will make another PR with the revision bumps for firefox, thunderbird, kdenlive, shotcut, python-torchaudio and python-torchvision

Thank you.