Upgrade ubuntu image to 24.04 (LTS) and ffmpeg to 7.1

[jsheffie]

resolves: #407 , #406

• add in support for ubuntu 2404 TLS
• if using ffmpeg 7.1 or greater build with 2404.
• added logic in update.py to build ffmpeg 7.1 and greater with new lib dependancies
• added templates for Dockerfile-env-ffmpeg-7.1-plus and Dockerfile-run-ffmpeg-7.1-plus
• these new templates updated these libs ( to make build work )
  • OPENCOREAMR_VERSION 0.1.5 -> 0.1.6
  • OPENJPEG_VERSION 2.1.2 -> 2.5.2
  • X264_VERSION 20170226-2245-stable -> 20191217-2245-stable
  • X265_VERSION 3.4 -> 4.0
  • XVID_VERSION 1.3.4 -> 1.3.7
  • LIBZMQ_VERSION 4.3.2 -> 4.3.5
  • LIBSRT_VERSION 1.4.1 -> `1.5.31
  • LIBVMAF_VERSION 2.1.1 -> 2.3.1
• added template Dockerfile-template.ubuntu2404 ( updated buildDeps to use python3 )
• ~~removed template Dockerfile-template.ubuntu2204 ( which was really pointed to 20.04 )~~ Decided not to remove 2204 at this time, so that this PR does not get too large.

Developer notes I was building this on my desktop w/ ( because I have apple silicon I needed the --platform argument )

./update.py; docker build --no-cache --platform linux/amd64 -t ffmpeg-7.1-ubuntu2404-desktop-build docker-images/7.1/ubuntu2404

Initial Description: was point Dockerfile-template.ubuntu2204 at correct version number

Docker template Dockerfile-template.ubuntu2204 is pointed at

FROM ubuntu:20.04 AS base

Which is old (March 2023), and misleading, since the template name specifies 2204.

should be FROM ubuntu:22.04 AS base

[jsheffie]

For reference I found/realized because of a SOC2 Vulnerabilities Scan on the docker image.

[jsheffie]

converted to draft as I think this is going to require a X265_VERSION update to 4.0

Working through that now.

[jsheffie]

alright I got 7.1-ubuntu docker-images/7.1/ubuntu2404 to build with no vulnerabilities. I need to split it out into its own Pull-Request ( probably ) and circle back to making 2204 work. Note: I did not check in anything into the docker-images directory at the moment. As it just makes the PR large. Is there a reason that we don't have a .gitignore configured to ignore the docker-images directory?

./update.py; docker build --no-cache -t 7.1-ubuntu docker-images/7.1/ubuntu2404

[jrottenberg]

2404 is the current LTS, https://endoflife.date/ubuntu at this point if it's simpler to upgrade to Noble Numbat, I'd say let's drop 2204.

Thank you very much for the contribution !

[jsheffie]

2404 is the current LTS, https://endoflife.date/ubuntu at this point if it's simpler to upgrade to Noble Numbat, I'd say let's drop 2204.

@jrottenberg concur, I will get this issue and pull-request cleaned up today to reflect the decision to add support for Ubuntu 2404 Noble Numbat, and I will leave all of the 20.04 and 22.04 stuff alone in this pull-request.

[jsheffie]

2404 is the current LTS, https://endoflife.date/ubuntu at this point if it's simpler to upgrade to Noble Numbat, I'd say let's drop 2204.

Thank you very much for the contribution !

@jrottenberg you are welcome. Alright I cleaned up the PR and I think this is ready to go. I considered removing 2204 altogether, but I decided that should be done in a different PR probably. Note: I did run update.py before checking in. update.py now has a bit more control over building newer versions of ffmpeg. Let me know your thoughts on this.

[jrottenberg]

Very nice, running it on https://dev.azure.com/video-tools/ffmpeg/_build/results?buildId=690&view=results

[jrottenberg]

Why 7.1 has its own env and run files ? I needed to change the download mirror for xvid, but that should be the main change required, rest should work for every version of ffmpeg, ideally.

Trying to not have to do too much per version.

[jsheffie]

Very nice, running it on https://dev.azure.com/video-tools/ffmpeg/_build/results?buildId=690&view=results

• Looks like Build_Docker_Images ubuntu2404_7.1 succeeded.
• there were 32 errors, 16 of which were 2204. Maybe it is worth pulling out the 2204 build now. ( I figured we would do it after this, but after seeing the build results maybe it makes since to do it now )
  Let me know if you want me to pull 2204 out and I will do it.

[jsheffie]

Why 7.1 has its own env and run files ? I needed to change the download mirror for xvid, but that should be the main change required, rest should work for every version of ffmpeg, ideally.

Trying to not have to do too much per version.

I just chose the newest thing. ( just trying to make one thing work, for starters ) We can probably pull this back to a couple of revisions ( ffmpeg 5.1 ) and it will probably work.

so: Build_Docker_Images ubuntu2404_7.1 now works.

We can turn the knobs in update.py - VARIANTS - SKIP_VARIANTS - and the new logic ffmpeg > 7.1 lib deps. Dockerfile-{env_or_run}-ffmpeg-7.1-plus

To dial this back to get everything building.

Looking Again

Very nice, running it on https://dev.azure.com/video-tools/ffmpeg/_build/results?buildId=690&view=results

• Looks like Build_Docker_Images ubuntu2404_7.1 succeeded.
• there were 32 errors, 16 of which were 2204. Maybe it is worth pulling out the 2204 build now. ( I figured we would do it after this, but after seeing the build results maybe it makes since to do it now ) Let me know if you want me to pull 2204 out and I will do it.

🤔 actually: this build (of the same branch): https://dev.azure.com/video-tools/ffmpeg/_build/results?buildId=691&view=results Did much better, it had the following problems:

• Build_Docker_Images alpine313_5.1.6 == error: ran longer than the maximum time of 60 minutes
• Build_Docker_Images vaapi2204_5.1.6 == Push docker image, failed with received unexpected HTTP status: 500 Internal Server Error
• Build_Docker_Images alpine313_4.4.5 == error: ran longer than the maximum time of 60 minutes
• Build_Docker_Images alpine313_3.4.13 == error: ran longer than the maximum time of 60 minutes
• Build_Docker_Images scratch313_3.4.13 == error: ran longer than the maximum time of 60 minutes
• Build_Docker_Images ubuntu2204_2.8.22 == error: ran longer than the maximum time of 60 minutes ( also a: gent Hosted Agent did not respond to a cancelation request )
• Build_Docker_Images ubuntu2204_2.8.22 == error: here I am seeing the ffmpeg dep libs build errors.
• Build_Docker_Images vaapi2204_2.8.22 == error: here I am seeing the ffmpeg dep libs build
• `Build_Docker_Images nvidia2204_2.8.22`` == error: here I am seeing the ffmpeg dep libs build

based on this information: I am going to tweek the update.py to try and get us better results.

[jsheffie]

Doing some local builds to see if this works:

for debuging the deps
$ docker run -it --rm alpine:3.20 sh

$ ./update.py; docker build --no-cache --platform linux/amd64 -t ffmpeg-5.1-alpine320-desktop-build docker-images/5.1/alpine320

[jrottenberg]

Thank you so much for all the pushes and effort on it, I'll catch up and rebase on the weekend, but one thing I've noticed, the build doesn't pass pre-commit, can you run the step locally (pre-commit install ; pre-commit run -a) to fix the minor lint issues ?

[Gwemox]

Hello, thanks for your work on this!

I’ve implemented a fix for the issue https://github.com/jrottenberg/ffmpeg/issues/403, but I’m wondering if I should wait for this PR to be merged before submitting my fix? What do you think?

[jsheffie]

Hello, thanks for your work on this!

I’ve implemented a fix for the issue #403, but I’m wondering if I should wait for this PR to be merged before submitting my fix? What do you think?

@Gwemox I currently have the following working for ffmpeg 7.1, 7.0.2, 6.1.2, 5.1.6

• [x] <ffmpeg ver>-ubuntu2404 ( supporting libs are from debian packages, should be easier to maintain )
• [x] <ffmpeg ver>-ubuntu2404-edge ( all libs source build, the original approach, and more bleeding edge )
• [x] <ffmpeg ver>-alpine320
• [x] <ffmpeg ver>-scratch320 need to stitch in the ubuntu2404-edge changes here.
• [x] <ffmpeg ver>-vaapi2404
• [x] <ffmpeg ver>-nvidia2204 need to move to ubuntu2404 style and

Thoughts:

• I finally got the (more robust, and easier to debug ) download_tarballs.sh and build_source.sh going. I will update this PR description to reflect my thought process on this, and why I eventually went that direction as soon as I get everything working again. The remaining tasks should be pretty cookie cutter. ( so they should go much quicker )

https://github.com/jrottenberg/ffmpeg/issues/403 👓 I will keep an eye out for the drawtext error when I make the <ffmpeg ver>-nvidia2204 -> build <ffmpeg ver>-nvidia2404. My guess is it will just work.

[jsheffie]

Thank you so much for all the pushes and effort on it, I'll catch up and rebase on the weekend, but one thing I've noticed, the build doesn't pass pre-commit, can you run the step locally (pre-commit install ; pre-commit run -a) to fix the minor lint issues ?

yes, I will do that. I did see that precommit was failing. ( I have been heads-down on making the builds work ) I think I have that almost ironed all out. I will circle back and fix the precommit stuff.. ( Note: I through I had pre-commit all set up... but clearly I don't quite have it set up correctly in this branch )

[jsheffie]

@jrottenberg I got a little bit of cleanup to do, based on my self review. But these all build now. 🎉 ( see updated pr description ) This is ready for an initial review ( I am going to be gone for most of the day ) but I am going to try to finish this out later today. Sorry the change-set is so significant. Once I realized the stupid download failures were biting me, I started looking for a solution to the problem and the changes got much more significant.

[jsheffie]

Converted back to draft, as the versions 7.02, 6.1.2, and 5.1.6 are all actually building the latest 7.1 version of the ffmpeg lib ( need to handle this in the builder to properly build the version of ffmpeg correctly )

[jrottenberg]

lot of work, really appreciate it, let me run the ci.

[jsheffie]

lot of work, really appreciate it, let me run the ci.

cool, I actually have a fix the the build version issue Note both alpine320 and ubuntu24.04 failed on building ffmpeg 5.1 with a math error. Error

./libavcodec/x86/mathops.h: Assembler messages:
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
make: *** [ffbuild/common.mak:81: libavformat/shortendec.o] Error 1

So taking that ffmpeg-5.1 version out of the buildable versions ( i.e. adding it to SKIP_VARIANTS )

@jrottenberg putting this back to ready-for-review Updating the description now, these are what I will expect to build correctly ( with the correct versions of ffmpeg in each container )

Preparing Dockerfile for ffmpeg-7.1
                         7.1-ubuntu2404
                         7.1-ubuntu2404-edge
                         7.1-alpine320
                         7.1-scratch320
                         7.1-vaapi2404
                         7.1-nvidia2404
Preparing Dockerfile for ffmpeg-7.0.2
                         7.0.2-ubuntu2404
                         7.0.2-ubuntu2404-edge
                         7.0.2-alpine320
                         7.0.2-scratch320
                         7.0.2-vaapi2404
                         7.0.2-nvidia2404
Preparing Dockerfile for ffmpeg-6.1.2
                         6.1.2-ubuntu2404
                         6.1.2-ubuntu2404-edge
                         6.1.2-alpine320
                         6.1.2-scratch320
                         6.1.2-vaapi2404
                         6.1.2-nvidia2404

[jsheffie]

alright, after looking at the runs here

Looks like everything built 🎉 except for the one alpine320 image's.

Images that built

7.1-vaapi2404       81mb      2024-10-28
7.1-vaapi           81mb      2024-10-28
7.1-ubuntu2404-edge 101mb     2024-10-28
7.1-ubuntu2404      81mb      2024-10-28
7.1-ubuntu-edge     101mb     2024-10-28
7.1-ubuntu          81mb      2024-10-28
7.1-scratch320      40mb      2024-10-28
7.1-scratch         40mb      2024-10-28
7.1-nvidia2404      630mb     2024-10-28
7.1-nvidia          630mb     2024-10-28
7.0.2-vaapi2404     81mb      2024-10-28
7.0.2-ubuntu2404-edge101mb     2024-10-28
7.0.2-ubuntu2404    81mb      2024-10-28
7.0.2-scratch320    40mb      2024-10-28
7.0.2-nvidia2404    630mb     2024-10-28
7.0-vaapi2404       81mb      2024-10-28
7.0-vaapi           81mb      2024-10-28
7.0-ubuntu2404-edge 101mb     2024-10-28
7.0-ubuntu2404      81mb      2024-10-28
7.0-ubuntu-edge     101mb     2024-10-28
7.0-ubuntu          81mb      2024-10-28
7.0-scratch320      40mb      2024-10-28
7.0-scratch         40mb      2024-10-28
7.0-nvidia2404      630mb     2024-10-28
7.0-nvidia          630mb     2024-10-28
7-vaapi             81mb      2024-10-28
7-ubuntu-edge       101mb     2024-10-28
7-ubuntu            81mb      2024-10-28
7-scratch           40mb      2024-10-28
7-nvidia            630mb     2024-10-28
6.1.2-vaapi2404     81mb      2024-10-28
6.1.2-ubuntu2404-edge101mb     2024-10-28
6.1.2-ubuntu2404    81mb      2024-10-28
6.1.2-scratch320    40mb      2024-10-28
6.1-vaapi2404       81mb      2024-10-28
6.1-vaapi           81mb      2024-10-28
6.1-ubuntu2404-edge 101mb     2024-10-28
6.1-ubuntu2404      81mb      2024-10-28
6.1-ubuntu-edge     101mb     2024-10-28
6.1-ubuntu          81mb      2024-10-28
6.1-scratch320      40mb      2024-10-28
6.1-scratch         40mb      2024-10-28
6-vaapi             81mb      2024-10-28
6-ubuntu-edge       101mb     2024-10-28
6-ubuntu            81mb      2024-10-28
6-scratch           40mb      2024-10-28

the alpine320 image builds fine locally for me. ( not sure what to make of it not building on the server just yet )

Also: I went ahead and checked in 2 files in docker-images ( azure-jobs.yml gitlab-ci.yml ) to fix the pre-commit errors.

[jsheffie]

@jrottenberg If you re-kick the build, (picking up my latest 2 changes) it should build the alpine320 images now as well. Which means everything should build. ( note I pulled and tested several of the images and they are working properly. )

Also pre commit on docker-images confusion

• I was avoiding checking in all of my changes on the generated docker-images as now that generates 167 files, which makes code reviewing a bit of a pain.
• I did re-checkin the two yml files for azure and github builders. ( as one of them got a pre-commit error on the builder ... I think its missing the trailing /n which maybe we should just add to the update.py script. )
• I saw that you ran pre commit on the directory docker-images
• I am now confused because it seems like I can't fetch down my latest changes

I cant do a fresh pull of my lates changes? ( that's weird)

$ mkdir tmp; cd tmp
$ gh repo clone jrottenberg/ffmpeg
$ cd ffmpeg
$ git status
$ git branch -a |grep jds
$ git checkout jds-Ubuntu-template-22.04-Jammy-Jellyfish
$ git log

This shows your latest commit, not the following 2 commits I made. ( I don't understand this ) Note: this PR shows they made it to github... so 🤷‍♂️ ( I have no idea what happened there )

In any case, maybe I should just check in the 167 docker-images files. We can decide if its worth striping the checkins on docker-images in a separate PR.

Let me know what you think. If you want me to check in all of the docker-images files like normal I will do that. ( it is alot of files ) Because now every build is getting 7 files. Dockerfile, Dockerfile-env-variant, Dockerfile-run-variant, generate-source-of-truth-ffmpeg-versions.py, download_tarballs.sh, build_source.sh, install_ffmpeg.sh

Note: I made a PR review comment on .gitignore, it is currently set to ignore docker-images dir. ( So that should be consistent with whatever decision we make )

[jrottenberg]

Ah yeah, pre-commit is the first step of the pipeline so will fail and stop it if it hasn't run.

Since I don't use docker for the builds, but azure pipeline, I wanted to make it very clear for users to lookup a given image and find the full Dockerfile that was used to generate it

[jsheffie]

Ah yeah, pre-commit is the first step of the pipeline so will fail and stop it if it hasn't run.

Since I don't use docker for the builds, but azure pipeline, I wanted to make it very clear for users to lookup a given image and find the full Dockerfile that was used to generate it

@jrottenberg I understand, this makes since. kk, I re-added the 'docker-images' generated directories. this is ready-for-review ( I expect all of the builds will go smoothly now )

[Gwemox]

@Gwemox there are 7.1 builds on hub.docker now. Specifically docker pull jrottenberg/ffmpeg:7.1-nvidia

@jsheffie this PR does not yet resolve #403. The harfbuzz library and the --enable-libharfbuzz argument are still missing during the FFMPEG compilation.

I had planned a fix using the old method, but I’m waiting for this PR to be merged to use the new build system.

You can test it with the command : docker run -it --rm jrottenberg/ffmpeg:7.1-nvidia -filters | grep drawtext

[FreezyLemon]

Note both alpine320 and ubuntu24.04 failed on building ffmpeg 5.1 with a math error. Error

./libavcodec/x86/mathops.h: Assembler messages: ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for shr' ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for shr' ./libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr' make: *** [ffbuild/common.mak:81: libavformat/shortendec.o] Error 1

So taking that ffmpeg-5.1 version out of the buildable versions ( i.e. adding it to SKIP_VARIANTS )

FYI: This is because of an update to binutils. It's easy to fix via including this patch, I ran into this same problem before.

[FreezyLemon]

This update breaks our CI workflow. I'm not 100% sure what the problem is, but it seems like copying /usr/local/lib and settings the LD_LIBRARY_PATH have something to do with it.

Running the same workflow with a clean ubuntu 24.04 image and the repository FFmpeg version works fine.

[jsheffie]

@Gwemox I added --enable-libharfbuzz ( not checked in yet ) but still does not show the filter as added. 🤔

• compiled w/ flag --enable-libharfbuzz
• verified that ffmpeg is linked against the lib

ldd `which ffmpeg` |grep harf
        libharfbuzz.so.0 => /usr/local/lib/libharfbuzz.so.0 (0x00007ffffc6fa000)

• but still does not show the filter enabled.

docker run -it --rm --platform="linux/amd64" ffmpeg-7.1-nvidia2404-desktop-build:latest -filters |grep draw 
 T.C drawbox           V->V       (null)
 ... drawgraph         V->V       (null)
 T.C drawgrid          V->V       (null)
 T.C drawtext          V->V       (null)
 ... drawbox_vaapi     V->V       (null)
 ... adrawgraph        A->V       (null)

Edited:

Filters:
  T.. = Timeline support
  .S. = Slice threading
  ..C = Command support
  A = Audio input/output
  V = Video input/output
  N = Dynamic number and/or type of input/output
  | = Source or sink filter

actually I think its has Timeline Support and Command Support for video in and out

[Gwemox]

@jsheffie Is libfreetype also enabled?

[jsheffie]

@jsheffie Is libfreetype also enabled?

@Gwemox yep, enabled --enable-libfreetype --enable-libharfbuzz and linked

ldd `which ffmpeg` |grep freetype
        libfreetype.so.6 => /usr/local/lib/libfreetype.so.6 (0x00007ffff8334000)

here is what my local desktop build made. I think it should work. https://hub.docker.com/repository/docker/jsheffie/ffmpeg-7.1-nvidea2404-testimg/general

[Gwemox]

Hello @jsheffie,

Indeed, drawtext seems to be active; however, there is an issue with the fonts. The error now appears on all versions:

docker run -it --rm -v ./:/videos jsheffie/ffmpeg-7.1-nvidea2404-testimg:1.0 -i /videos/320_OUTRO.mp4 -vf "drawtext=text='Stack Overflow':fontcolor=white:fontsize=24:box=1:[email protected]:boxborderw=5:x=(w-text_w)/2:y=(h-text_h)/2" -codec:a copy /videos/output.mp4
...
Fontconfig error: Cannot load default config file: No such file: (null)
[Parsed_drawtext_0 @ 0x5ad7b68a52c0] Cannot find a valid font for the family Sans