Upgrade ubuntu image to 24.04 (LTS), alpine to 320 and ffmpeg to 7.1 #408

jsheffie · 2024-10-03T15:20:21Z

BLUF ( Bottom Line Up Front)

The following are ready to be built.

ffmpeg versions: 7.1, 7.02, 6.1.2, ~~and 5.1.6~~
Os flavors:
- <ffmpeg-ver>-ubuntu24.04
- <ffmpeg-ver>-ubuntu24.04-edge
- <ffmpeg-ver>-vaapi24.04
- <ffmpeg-ver>-nvidia24.04
- <ffmpeg-ver>-alpine320
- <ffmpeg-ver>-scratch320

Overview

I did not mean to have such a large commit. I did not. I actually originally had a one line fix... but turns out it was not that simple.

So here is how I got to where I am now. ( with such a large commit )

The libs needed to be updated to work with the new OS's

Simple enough, I started working through building the OS's with the lates libs. At some point along the way while working through the build / dependance issues, I realized ( after chasing my tail for awhile ) that I was getting intermittent download failures for some of the tarballs.

OMG it failed because the download got stuck? 🤯

What was worse is that with the Docker RUN DIR=/tmp/foo && \ mkdir ... && \ cd ... && \ curl ... && \ tar ... && \ configure && ... construct it is very difficult to tell where the failure is. I do understand that we don't want the image to build in production if something fails. ( Note: it is sometimes useful to have the image finish building when in development if something fails so you can "peek under the hood" to figure out what went wrong. ( more on this later ) I decided there were several problem areas that needed to be addressed to keep this all easily maintainable. Another thought:

are we building too much source?

Its a trade off, while building large portions form source allows us to run to the bleeding edge with the latest versions of all the libs, it comes at a difficult to maintain drawback. Most of these projects are being managed and regularly updated by debian and alpine. ( I do realize that this repo used to support other flavors of linux in the past )

Here is a screenshot from the README.md update that explains the image names. ffmpeg-7.1-ubuntu2404, ffmpeg-7.1-vaapi2404, ffmpeg-7.1-alpine320 all use os vender libs for the ffmepg support libs. The advantage of this is that upgrading OS's should be a breeze in the future, as we call for generic vender lib install names. Examples are: libtheora-dev, libtheora0, libzmq3-dev, libzmq5... etc.

Is endoflife.date/ffmpeg too much to support? ( the end of life on ffmpeg is a long time )

We use the endoflife.date API to find the most recent ffmpeg versions. (which I thought was brilliant, by the way) However, to simplify image maintenance, we only consider versions released within the last YEARS years (currently set to 3). Including very old versions compatibility
issues with different libraries and operating system versions. By focusing on recent versions, we keep things manageable.
Note: the older builds will be preserved in the the docker hub registry.To keep this from getting even larger and more confusing I decided to support

There should be one place for info related to the source we are building. This includes: where/how to download the source, the version of the source/library etc.

The Docerfile-env-<variant> was a great abstraction, we need more of that. I realized when I got to the bottom of the README.md with the package table to keep up to date, that we needed one place to maintain this.

Summary of changes:

have re-tryable downloads This conversation inspired the change to a re-trying download_tarballs.sh script. Which will loop through the list and re-try things a configurable amount of times ( currently set to 6 ) If you feed the command several libs to download it will cycle through them before coming back and re-trying the one it failed on.
Have clear loggable failures where the failure hapend. This is achieved with the build_sources.sh bash script. Which adds a set -e # Stop execution on any error at the top of the bash script. Now when calling the build_sources.sh from a RUN line the build will fail ( the same as before )
one source of truth. Before we had the Docker-env-<variant>. There were a few problems with this as well as a few details missing. It was repeated in the builds and the readme, and if we could store additional information about the packages we could use that information as well to, download, extract, checksum, and generate the table for the README.md

With those ideas in mind here is what a, Update the version of libvmaf tasking would look like.

open ./generate-source-of-truth-ffmpeg-versions.py and modify

LIBVMAF = {"version": "3.0.0", "release_date": "2023-12-07"}

to the correct version and release date.

run ./generate-source-of-truth-ffmpeg-versions.py

./generate-source-of-truth-ffmpeg-versions.py
Library table generated: generated_versions_table.md
Build manifest generated: generated_build_manifest.json
Versions manifest generated: generated_build_versions_manifest.json

shove the contents of generated_versions_table.md into the bottom of the README.md
That should be enough to rebuild all of the images with the new flavor. 🚀 ( your done )

You probably should kick the tires on the image ( I updated the CONTRIBUTING.md with additional details on this )
But here is a short walkthrough. I am currently developing on a Mac so the --platform= line is necessary,
you might not need to do that.

$ ./update.py; time docker build --platform linux/amd64 -t ffmpeg-7.1-ubuntu2404-edge-desktop-build docker-images/7.1/ubuntu2404-edge
( grab some coffee ) 

$ docker run -it --rm --entrypoint='bash' --platform="linux/amd64" ffmpeg-7.1-ubuntu2404-edge-desktop-build:latest

Under the covers: We still have the
Docker-run-varient In our example here you are looking for Docker-run-ubuntu-edge

You will notice the construct

# First batch of libraries ( split into docker layers, to allow for caching )
RUN /tmp/workdir/generate-source-of-truth-ffmpeg-versions.py --library-list \
libopencore-amr,\
libx264,\
libx265,\
libogg,\
libopus
RUN /tmp/workdir/download_tarballs.sh
RUN /tmp/workdir/build_source.sh

What this does is the first run line runs a python script inside of th development image which spits out
two manifests based on the lib arguments you give it

Build manifest generated: generated_build_manifest.json
Versions manifest generated: generated_build_versions_manifest.json

The next two RUN lines read in this information and do there operations.

download_tarballs.sh will download ( w/ retries on failures ) the downloads.
build_source.sh has the source building callbacks, and will build ( in order ) the things you pass in.
If any failures happen you the Docker image build will exit and the RUN line will fail straight away.

You can now string together these 3 RUN lines to process batches of libs to build in order. This will allow docker build to cache the layers of successful build items. ( this is pretty powerful when ironing out new any building / dependancies problems )

Screenshot of Docker Caching build layers ( on re-builds ) 📸

Finally you can pass in || true to any line to have it fail but keep going you can use this trick to let the build finish so you can inspect the image.

Rough Layout

update.py; docker build
                  -> Dockerfile-template.ubuntu2404-edge
                         -> Dockerfile-env-ubuntu-edge
                         -> Dockerfile-run-ubuntu-edge
                              -> (batch) generate-source-of-truth-ffmpeg-versions.py ... download_tarballs.sh ... build_source.sh
                              -> (batch) generate-source-of-truth-ffmpeg-versions.py ... download_tarballs.sh ... build_source.sh
                              -> (batch) generate-source-of-truth-ffmpeg-versions.py ... download_tarballs.sh ... build_source.sh
                              -> install_ffmpeg.sh

Follow ups

I think we have outgrown checking in the docker-images directory.
I vote for putting docker-images in the gitignore file. ( ~~but I did not do it in this commit~~ The files changed had ballooned to 167 files changed, so I went ahead and made this change. )
I am assuming that the azure build process runs ./update.py

Notes about initial changes

- 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 · 2024-10-03T15:36:34Z

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

jsheffie · 2024-10-03T16:06:09Z

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

Working through that now.

…nerabilities'

jsheffie · 2024-10-04T14:15:55Z

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 · 2024-10-05T03:38:01Z

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 · 2024-10-07T14:05:48Z

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 · 2024-10-08T19:44:12Z

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 · 2024-10-10T04:28:12Z

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

jrottenberg · 2024-10-10T05:43:56Z

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 · 2024-10-10T13:29:43Z

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 · 2024-10-10T13:57:27Z

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 · 2024-10-10T15:16:32Z

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

jsheffie · 2024-10-28T05:32:27Z

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 · 2024-10-28T16:46:31Z

@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 · 2024-10-28T18:27:10Z

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 · 2024-10-28T22:09:19Z

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 · 2024-10-30T15:54:55Z

@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 · 2024-10-31T10:14:27Z

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 · 2024-10-31T17:35:13Z

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 · 2024-11-04T15:24:59Z

@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 · 2024-11-04T17:27:31Z

@jsheffie Is libfreetype also enabled?

jsheffie · 2024-11-04T17:43:11Z

@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

…to build)

Gwemox · 2024-11-05T08:02:59Z

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:boxcolor=black@0.5: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

jrottenberg · 2024-11-06T03:43:00Z

Score !
https://dev.azure.com/video-tools/ffmpeg/_build/results?buildId=699&view=results

jrottenberg · 2024-11-09T02:02:46Z

Thank you very much @jsheffie ! Awesome work !

fix dockerfile template for ubuntu point at correct base 'ubuntu:22.04'

af98e79

jsheffie marked this pull request as draft October 3, 2024 16:05

got '7.1-ubuntu' 'docker-images/7.1/ubuntu2404' to build with no 'vul…

4265cdc

…nerabilities'

notes:

077ae5f

jsheffie mentioned this pull request Oct 8, 2024

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

Closed

jsheffie added 5 commits October 8, 2024 12:31

updates

c620353

update build to support ffmpeg libs for newer versions

6acdaa0

updates

3a03055

read_ffmpeg_template_content_based_on_version

dea29c8

code cleanup

3072aa1

jsheffie marked this pull request as ready for review October 8, 2024 19:35

renaming function for readibility

d0b4454

jsheffie changed the title ~~fix dockerfile template for ubuntu point at correct base 'ubuntu:22.04'~~ Upgrade ubuntu images to 24.04 (LTS) and ffmpeg to 7.1 Oct 8, 2024

jsheffie changed the title ~~Upgrade ubuntu images to 24.04 (LTS) and ffmpeg to 7.1~~ Upgrade ubuntu image to 24.04 (LTS) and ffmpeg to 7.1 Oct 8, 2024

clean up to build the latest OS's

25f0f59

jsheffie marked this pull request as draft October 10, 2024 20:23

jsheffie added 3 commits October 11, 2024 14:22

builder updates: ubuntu2404 and alpine320 are working

e15e9e9

incremental checkin got 'ubuntu2404' working again

7bcd805

updates

8041199

fixing pre-commit error

171e94e

jsheffie added 2 commits October 28, 2024 09:05

fixing 'alpine320' build

7c27d2a

fixing 'alpine320' 'install_ffmpeg.sh' for the build

021e38f

re-add the 'docker-images' files (pre code review feedback)

4bc420a

re-sync w/ upstream

b84de55

Gwemox mentioned this pull request Oct 30, 2024

7.0.1-nvidia2204 No such filter: 'drawtext' #403

Closed

jsheffie mentioned this pull request Oct 30, 2024

-ubuntu images use different versions of Ubuntu #410

Open

FreezyLemon mentioned this pull request Oct 31, 2024

Remove avresample shssoichiro/ffmpeg-the-third#81

Merged

jsheffie mentioned this pull request Nov 4, 2024

No such filter: 'drawtext' #412

Closed

added --enable-libharfbuzz

92b7cec

take nvidia and scratch builds out for ffmpeg 6.1 (took over an hour …

53228e8

…to build)

jrottenberg self-assigned this Nov 8, 2024

jrottenberg approved these changes Nov 9, 2024

View reviewed changes

jrottenberg merged commit 1e5a763 into jrottenberg:main Nov 9, 2024
18 checks passed

jsheffie deleted the jds-Ubuntu-template-22.04-Jammy-Jellyfish branch November 9, 2024 22:09

jsheffie mentioned this pull request Nov 13, 2024

FFmpeg 7.1 "Péter" Support #406

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade ubuntu image to 24.04 (LTS), alpine to 320 and ffmpeg to 7.1 #408

Upgrade ubuntu image to 24.04 (LTS), alpine to 320 and ffmpeg to 7.1 #408

jsheffie commented Oct 3, 2024 •

edited

Loading

jsheffie commented Oct 3, 2024

jsheffie commented Oct 3, 2024

jsheffie commented Oct 4, 2024

jrottenberg commented Oct 5, 2024

jsheffie commented Oct 7, 2024

jsheffie commented Oct 8, 2024 •

edited

Loading

jrottenberg commented Oct 10, 2024

jrottenberg commented Oct 10, 2024

jsheffie commented Oct 10, 2024

jsheffie commented Oct 10, 2024 •

edited

Loading

jsheffie commented Oct 10, 2024 •

edited

Loading

jsheffie commented Oct 28, 2024

jsheffie commented Oct 28, 2024

jrottenberg commented Oct 28, 2024

jsheffie commented Oct 28, 2024

Gwemox commented Oct 30, 2024 •

edited

Loading

FreezyLemon commented Oct 31, 2024

FreezyLemon commented Oct 31, 2024 •

edited

Loading

jsheffie commented Nov 4, 2024 •

edited

Loading

Gwemox commented Nov 4, 2024

jsheffie commented Nov 4, 2024

Gwemox commented Nov 5, 2024 •

edited

Loading

jrottenberg commented Nov 6, 2024

jrottenberg commented Nov 9, 2024

Upgrade ubuntu image to 24.04 (LTS), alpine to 320 and ffmpeg to 7.1 #408

Upgrade ubuntu image to 24.04 (LTS), alpine to 320 and ffmpeg to 7.1 #408

Conversation

jsheffie commented Oct 3, 2024 • edited Loading

BLUF ( Bottom Line Up Front)

Overview

Summary of changes:

jsheffie commented Oct 3, 2024

jsheffie commented Oct 3, 2024

jsheffie commented Oct 4, 2024

jrottenberg commented Oct 5, 2024

jsheffie commented Oct 7, 2024

jsheffie commented Oct 8, 2024 • edited Loading

jrottenberg commented Oct 10, 2024

jrottenberg commented Oct 10, 2024

jsheffie commented Oct 10, 2024

jsheffie commented Oct 10, 2024 • edited Loading

jsheffie commented Oct 10, 2024 • edited Loading

jsheffie commented Oct 28, 2024

jsheffie commented Oct 28, 2024

jrottenberg commented Oct 28, 2024

jsheffie commented Oct 28, 2024

Gwemox commented Oct 30, 2024 • edited Loading

FreezyLemon commented Oct 31, 2024

FreezyLemon commented Oct 31, 2024 • edited Loading

jsheffie commented Nov 4, 2024 • edited Loading

Gwemox commented Nov 4, 2024

jsheffie commented Nov 4, 2024

Gwemox commented Nov 5, 2024 • edited Loading

jrottenberg commented Nov 6, 2024

jrottenberg commented Nov 9, 2024

jsheffie commented Oct 3, 2024 •

edited

Loading

jsheffie commented Oct 8, 2024 •

edited

Loading

jsheffie commented Oct 10, 2024 •

edited

Loading

jsheffie commented Oct 10, 2024 •

edited

Loading

Gwemox commented Oct 30, 2024 •

edited

Loading

FreezyLemon commented Oct 31, 2024 •

edited

Loading

jsheffie commented Nov 4, 2024 •

edited

Loading

Gwemox commented Nov 5, 2024 •

edited

Loading