Recompiling ffmpeg best practices?

Byron · 04-01-2024, 11:37 AM

I've been trying to run AlienBOB's ffmpeg6 script on Slackware 15 Stable, and I've been running into some problems. The code below is the STDERR output of the script, with it running well until it tries to apply the Vulkan diff. A user informed me that Slackware 15, if up-to-date, should include Vulkan, but it didn't show up when I ran slackpkg update and install-new, so I'm not sure if I'm missing something. Searching Slackbuilds.org returned nothing for Vulkan on Slackware 15, which implies it's included in 15...

Code:

Hunk #1 succeeded at 179 (offset 49 lines).
Hmm...  Ignoring the trailing garbage.
done
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- ./configure.orig   2023-03-26 09:21:00.000000000 -0500
|+++ ./configure        2023-08-29 13:13:08.176019532 -0500
--------------------------
patching file configure
Using Plan A...
Hunk #1 succeeded at 6705 with fuzz 2 (offset 154 lines).
done
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff '--color=auto' -rupN ffmpeg.orig/libavformat/avformat.h ffmpeg/libavformat/avformat.h
|--- ffmpeg.orig/libavformat/avformat.h 2022-08-19 17:42:47.323422603 +0200
|+++ ffmpeg/libavformat/avformat.h      2022-08-19 17:42:51.347130436 +0200
--------------------------
patching file libavformat/avformat.h
Using Plan A...
Hunk #1 succeeded at 1030 with fuzz 2 (offset -98 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff '--color=auto' -rupN ffmpeg.orig/libavformat/mux_utils.c ffmpeg/libavformat/mux_utils.c
|--- ffmpeg.orig/libavformat/mux_utils.c        2022-08-19 17:42:47.346758108 +0200
|+++ ffmpeg/libavformat/mux_utils.c     2022-08-19 17:47:28.549589002 +0200
--------------------------
patching file libavformat/mux_utils.c
Using Plan A...
Hunk #1 succeeded at 40 with fuzz 2 (offset 3 lines).
done
ERROR: vulkan requested but not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
Makefile:186: /tests/Makefile: No such file or directory
make: *** No rule to make target '/tests/Makefile'.  Stop.
Makefile:186: /tests/Makefile: No such file or directory
make: *** No rule to make target '/tests/Makefile'.  Stop.
** Adding ffmpeg presets:
** Fixing up pkgconfig files:
ls: cannot access '/tmp/build/package-ffmpeg/usr/lib/pkgconfig/*.pc': No such file or directory
cp: cannot stat 'doc/*.html': No such file or directory
./ffmpeg.SlackBuild FAILED at line 2029!

The main thesis of what I want to ask is; with regards to recompiling large programs like ffmpeg, which place their fingers in many pies - depending upon myriad dynamic libraries, of whose versions change according to whether you're using ffmpeg4.x, ffmpeg5.x or ffmpeg6.x - I'm wondering what is the general best practice for recompiling such programs on Slackware?

Has anyone successfully got AlienBob's ffmpeg6.x SlackBuild working on 15 Stable? If this is infeasible and would simply introduce too many breakages, I'm wondering if it would be better to extend his ffmpeg4.x script to include the likes of updated libdav1d and AV1 encoder libraries? Or might it be better to edit his ffmpeg5.x or ffmpeg6.x scripts to work with already-installed library versions on 15 Stable?

smallpond · 04-01-2024, 12:38 PM

Code:

(offset 154 lines)

oof. Not a clean patch. ffmpeg is hard enough to compile even when you're not trying to install patches intended for a different version.

Byron · 04-01-2024, 04:14 PM

aaw, biscuits! I suppose those patches were for library versions included in [Current] and not 15 Stable users like myself then? Any comment on how to best approach compiling an ffmpeg that works for me? I just want a good AV1 encoder. Any idea if some of the code minus the patches in BOB's script for ffmpeg6.x could work for ffmpeg4.x? It's difficult to tell what some of the patches specifically address. I just assumed they would be best to have for the long-term.

zeebra · 04-02-2024, 08:51 AM

Use Pats ffmpeg build script included in Slackware 15, change the parts you need to change and recompile the same version of ffmpeg and build a custom slackware package with it.

chemfire · 04-02-2024, 09:22 AM

One strategy depending on what your objectives are might be to build the version Alien is on but set the prefrix to /opt/ffmpeg or /usr/local/. This has the advantage of not breaking anything but might not meet your requirements depending on what you want to do.

It won't get you added codec/container support in software that is linking the libraries in the standard slackware package, but will get the binaries like ffmpeg, ffplay, ffprobe, etc that you can use for viewing and transcoding content.

You *might* be able to use LD_PRELOAD to start some other application that uses libavcodec with your custom build at runtime.

Byron · 04-03-2024, 09:05 AM

I was wondering is it possible to package ffmpeg5.x for Slackware 15 stable? Or would this definitely introduce too many breakages? And if so, how could I go about finding which version of libaom and SVT-AV1 is the latest and still-compatible with ffmpeg4.4?

kgha · 04-04-2024, 02:39 AM

If AV1 capabilities is what you're after, maybe the following can do the trick (haven't tried myself):
(1) build and install aom and dav1d using the buildscripts from slackbuilds.org
(2) build ffmpeg-4.4.1 using Pat's buildscript from https://slackware.uk/slackware/slack...urce/l/ffmpeg/ and editing lines 115 and 117:

libaom="" ; [ "${AOM:-yes}" != "no" ] && libaom="--enable-libaom"

libdav1d="" ; [ "${DAV1D:-yes}" != "no" ] && libdav1d="--enable-libdav1d"

No guarantees, but it might give you what you want.

chemfire · 04-04-2024, 07:28 AM

I suspect kgha's solution is the most likely to work and the least invasive. Worst case with that you can always re-install the stock package if anything does break. It should not break anything.

It may be the current libaom and libav1d are to new, and ffmpeg 4.4.1 might not build. Unfortunately I am not sure you will know unless you either 1) just try it or 2) go slogging though the automake files to see what version checks might exist in them. I took a quick look and the highlevel documentation does not seem to help in this area much: https://ffmpeg.org//general.html#All...-_0028AOM_0029

I used to build ffmpeg before it was included in Slackware and it was also a bit of trial and error when it came to the external libraries. The strategy I used was basically. Grab the latest ffmpeg release, look at the date, grab a last release of the externals libraries before the ffmpeg release date; unless there were serious bugs reported and in that instance try a more recent release. Usually that worked. However my primary interest in it at the time was 'archiving stuff to DVD format' getting good transfers of home VHS recordings, and moving commercial stuff we owned over in a way that looked good (for being sourced from S-VHS)and fit nicely on single DVD5 and play on most devices. So its been a while. Since then I have re-ripped most of it and shoved it into matroska container files without re-econding just simple mpeg2ps -> copy codecs -> matroska; because storage is cheap now and there is no reason to take more loss.

kgha · 04-04-2024, 07:43 AM

Quote:

Originally Posted by chemfire

It may be the current libaom and libav1d are to new, and ffmpeg 4.4.1 might not build.

There's a risk, for sure. Slackbuild's dav1d script builds version 1.4.0. Latest is 1.4.1. AlienBob's ffmpeg-4.4.2 uses version 1.3.0. Slackbuild's aom script builds the latest version (3.8.2). Should the latest versions create havoc, try again with a slightly older version.

Byron · 04-04-2024, 02:21 PM

Thanks. I ended up editing Alien's slackbuild script for 4.4.2, and it seemed to be going well until it reached libGME. I don't understand why it supposedly can't find the gme library, considering its source is in the sources directory, where it's able to find and build everything else...

Specifically, it builds gme, but then it just claims to not be able to find where it built it in the build process for ffmpeg itself, after building zbvi:

Code:

make[1]: Leaving directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35/po'
Making install in doc
make[1]: Entering directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35/doc'
make[2]: Entering directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35/doc'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35/doc'
make[1]: Leaving directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35/doc'
make[1]: Entering directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35'
make[2]: Entering directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35'
make[2]: Nothing to be done for 'install-exec-am'.
test -z "/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/lib/pkgconfig" || mkdir -p -- "/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/lib/pkgconfig"
 /usr/bin/ginstall -c -m 644 'zvbi-0.2.pc' '/tmp/build/tmp-ffmpeg/ffmpegdeps/usr/lib/pkgconfig/zvbi-0.2.pc'
make[2]: Leaving directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35'
make[1]: Leaving directory '/tmp/build/tmp-ffmpeg/zvbi-0.2.35'
/tmp/build/tmp-ffmpeg/dav1d-1.3.0/build
**
**  ffmpeg ...
**
ERROR: libgme not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.

Not sure what went wrong. Could it be that it's put it with the rest of the built libraries as "game-music-emu-0.6.3" instead of "gme-0.6.3" or "libgme-0.6.3"?

gildbg · 04-04-2024, 03:45 PM

Use its precompiled binary and save yourself some beer time with friends, it's the same binary, trust me.

Byron · 04-04-2024, 06:05 PM

Quote:

Originally Posted by chemfire

I suspect kgha's solution is the most likely to work and the least invasive. Worst case with that you can always re-install the stock package if anything does break. It should not break anything.

It may be the current libaom and libav1d are to new, and ffmpeg 4.4.1 might not build. Unfortunately I am not sure you will know unless you either 1) just try it or 2) go slogging though the automake files to see what version checks might exist in them. I took a quick look and the highlevel documentation does not seem to help in this area much: https://ffmpeg.org//general.html#All...-_0028AOM_0029

I used to build ffmpeg before it was included in Slackware and it was also a bit of trial and error when it came to the external libraries. The strategy I used was basically. Grab the latest ffmpeg release, look at the date, grab a last release of the externals libraries before the ffmpeg release date; unless there were serious bugs reported and in that instance try a more recent release. Usually that worked. However my primary interest in it at the time was 'archiving stuff to DVD format' getting good transfers of home VHS recordings, and moving commercial stuff we owned over in a way that looked good (for being sourced from S-VHS)and fit nicely on single DVD5 and play on most devices. So its been a while. Since then I have re-ripped most of it and shoved it into matroska container files without re-econding just simple mpeg2ps -> copy codecs -> matroska; because storage is cheap now and there is no reason to take more loss.

Thanks, that seems like a good way to go. In the meantime, I've retrofitted Alien's slackbuild to include libaom and SVT-AV1 okay, but for some reason, an untouched part of the script to do with libgme (game music emulator) isn't working, specifically the part where everything except for ffmpeg has already compiled and ffmpeg is looking for the libraries. It seems ffmpeg can't find libgme for...some reason. Even weirder is that the code running before it clearly says it was just building zvbi, but then it tries to enter the tmp-ffmpeg/dav1d-1.3.0/build directory before beginning the compilation process for ffmpeg itself, which doesn't make sense, because libdav1d isn't ran after, it's ran before the zvbi function.

Am I reading this bash script right?

chemfire · 04-05-2024, 07:59 AM

I would try to isolate the problem. If you disable libgme does it build?

I am sure the errors are useful if you are familiar with the code and build process but I am certainly not. Its hard to know what is really going on. It also could be that some of build is happening in parallel which might cause you to see messages 'out of order'

you might try setting NUMJOBS=1 to make understanding the output easier.

The other thing is GME=0.6.3 is defined in that script; is that consist with the version of library present?

Byron · 04-08-2024, 02:08 PM

It builds if I disable gme. And it's weird. Checking the build directory of gme shows that it supposedly matched exactly with what version it's looking for.

Even installing the same version of libgme from slackbuilds.org prior to building doesn't make it work. For some reason, ffmpeg is looking at the directory where libgme is built in, and it just isn't good enough for some reason.