[Tracker] ffmpeg 7 transition

[Biswa96]

I would like to initiate the ffmpeg 7 update. Here is my plan.

1. update libx265 and reverse dependencies except handbrake. bump(main/libx265): 4.0 #22492
2. update ffmpeg and non-gui reverse dependencies. bump(main/ffmpeg): 7.1 #22518
3. update gui reverse dependencies of ffmpeg except handbrake. FFmpeg 7.1 transition part 2 #22551
4. update handbrake. FFmpeg 7.1 transition part 2 #22551
5. update big packages - pytorch, kdenlive, shotcut, firefox. FFmpeg 7.1 transition part 3 #22595
6. update audacity ffmpeg. bump(x11/audacity-ffmpeg): 7.1, revbump audacity for ffmpeg-audacity 7.1 #22614

But I can not test the bigger packages like firefox, python torch and need some help with those. Please let me know if there is any simpler and non-destructive of way to update those.

[robertkirkman]

That order looks to me like it would work and is similar to the order I used to test building all the packages locally.
I have a small question which is, do you mean that there is a way in which python-torch depends on ffmpeg, or is that just a general example? I did not notice that depending on ffmpeg at all.

[Biswa96]

There is a FIXME in build scripts of python-torchvision and python-torchaudio.

[robertkirkman]

Thank you for pointing that out, that did not show up in the way I detected reverse dependencies.

When I try to enable FFmpeg in the package python-torchaudio and recompile it, I see this error

/home/builder/.termux-build/python-torchaudio/src/src/libtorio/ffmpeg/stream_reader/conversion.cpp:39:57: error: no member named 'channels' in 'AVFrame'
     39 |   TORCH_INTERNAL_ASSERT_DEBUG_ONLY(num_channels == src->channels);
        |                                                    ~~~  ^

It would appear that python-torchaudio does not yet have any implementation of support for FFmpeg 7

pytorch/audio#3857

Hypothetically, I might be able to write my own solution to that error because, I saw a very similar error in the package oshu, which is also a reverse dependency, with a slow upstream that was written only for FFmpeg 5/6, and I was able to fix that error in a way that seemed to preserve audio support in the app on my device, by rewriting a small portion of its code to be compatible with FFmpeg 7.

On the other hand, that might be very difficult for python-torchaudio because this project's code is much, much larger than oshu, and more complicated, and I do not know if I have the ability to do it for such a large project, but I can try if another solution cannot be found.

• Arch Linux's AUR's python-torchaudio package does not support FFmpeg (similar to current termux package)
• Debian Sid has a python3-torchaudio package that was compiled against FFmpeg, but as far as I can tell, the last time it was built was against FFmpeg 6, and Debian Sid is a work in progress so that package does not install or build successfully on my Debian Sid device right now.

If we can find a distro or location where development of an FFmpeg 7 backend for python3-torchaudio is happening, then that could open a pathway towards enabling FFmpeg support in Termux's python-torchaudio package as well.

[robertkirkman]

Now I am currently writing another PR that will try to make what seem like the best choices for remaining lower-priority packages that for various reasons, needed a separate PR and/or don't seem to easily get errors after ffmpeg and libx265 were bumped (firefox,python-torchvision, etc)

[robertkirkman]

Now, all packages that depend on FFmpeg are using FFmpeg 7 except for these two:

• python-torchaudio: using FFmpeg 6.1.2, because it cannot yet be built using FFmpeg 7, tracked by the issue linked above
• audacity: using FFmpeg 6.1.1, reason unknown

I am not sure if this should stay open to keep track of those, or if this tracker would be considered complete.

[twaik]

So now audacity and pytorch do not work because of updated ffmpeg? Or they have ffmpeg 6 subpackage/static dependency?

[robertkirkman]

They both have an ffmpeg 6 subpackage and work, but audacity appears to work when recompiled and tested without the subpackage present, but you said to not worry about that and just leave it

[twaik]

I said to not worry about having subpackage. But probably in the case if audacity works with ffmpeg7 if recompiled we should recompile it. And probably we should upgrade ffmpeg subpackage too.

[robertkirkman]

oh, you had said that you do not think I should touch the subpackage, and I interpreted that to mean do not touch it including do not bump it to newer ffmpeg. If you mean that really the subpackage should be kept, but just bumped to use the same version of ffmpeg as the main ffmpeg package, I will do that now.