ffmpeg 7.0.1 and Windows 7

[pandy]

but the size of the build could be reduced
if there is a consensus on what is not needed.

Oh no, please, don't even suggest something like this... it may trig endless discussion without consensus in the final - ffmpeg is small when compared to other software size, even some ffmpeg GUI's are bigger than ffmpeg itself and it is hard to decide what is important or not - ffmpeg advantage is that you can use it in future for even most unique job hard to be predicted today...

And as always thank you very much for your hard work, i appreciate it very much.

[kgLum]

the size of the build could be reduced if there is a consensus on what is not needed.

Oh, thanks! No, I was just curious. Wasn't suggesting to change anything.

Well, unless there's a simple way that doesn't affect functionality, and it's not much bother. :)
Like if it's a random compiler setting or linker flag, or maybe a needless external lib that gets linked in for one or two trivial functions, and drags along with it an endless chain of dependencies.

But I know most people don't share my size-optimization affinities.

As examples, here are the largest static libraries used in the Windows 7 builds:

47MB librav1e.a
29MB libx265.a
23MB libSvtAv1Enc.a - not included in 32-bit
23MB libshaderc_combined.a
15MB libSDL2.a
12MB libaom.a

Intriguing. Any idea what contributes to each of these?
And in case these static libs include external libs, and if there's shared code, does it get merged in the final linkage?

FWIW, some observations in related software below. I've no idea if mingw changes the picture.

https://github.com/Multicorewareinc/x265/releases
x265 "static" x86_64 v4.3
As far as I can tell, the only non-OS external dependencies are VC 14 runtimes, though it does crash when I try it on Win <10.

5 MB - x265.exe

https://github.com/clsid2/mpc-hc/releases
LAVFilters is decode-only, which would explain some size difference, but I don't know if it's enough to explain it all.
In MPC-HC (clsid2) v2.8.3.12:

16 MB (vs 98) - avcodec-lav-63.dll
 6 MB (vs 23) - avformat-lav-63.dll
 1 MB (vs  3) - avutil-lav-61.dll
 1 MB (vs  2) - swscale-lav-10.dll

https://libsdl.org/release/?C=M;O=D
SDL (do people use ffplay?), I don't know if comparable exactly, but some sizes:

  5 MB - SDL3.dll - (SDL3-devel-3.4.18-mingw.zip)
  3 MB - SDL3.dll - (sdl12-compat-1.2.78-win32-x64.zip)
0.8 MB - libSDL3.dll.a - (SDL3-devel-3.4.18-mingw.zip)
0.3 MB - SDL2.dll

[autodidact]

@pandy,
I understand your point and I am content to have things remain as they are.


@kgLum,
It looks like the optimizations you seek would probably require major changes to the build configuration. Also, you may be
drawing some wrong conclusions from the size comparisons you are making.

Using one of your examples, a mingw build of x265 will have some overhead compared to a msvc build but the one you observed
supports 8bit encoding only compared to the one included here which supports 8bit+10bit+12bit.

[geextah_2]

Hi, would it be possible to make ffmpeg usable with FhG AAC? So kinda porting fhgaacenc into ffmpeg and use enc_fhgaac.dll

[nicolaasjan]

Hi, would it be possible to make ffmpeg usable with FhG AAC? So kinda porting fhgaacenc into ffmpeg and use enc_fhgaac.dll

Could try this: libfdk-aac_dlls.7z

[pandy]

Hi, would it be possible to make ffmpeg usable with FhG AAC? So kinda porting fhgaacenc into ffmpeg and use enc_fhgaac.dll

Could try this:
[Attachment 94217 - Click to enlarge]

There are two different AAC encoders from Fraunhofer FhG and FDK, FhG is higher quality encoder and it is not open sourced - it was available as a part of Winamp suite.

@OP - you can use ffmpeg and pipe to https://wiki.hydrogenaudio.org/index.php?title=Fhgaacenc however Apple AAC encoder offer higher quality and is supported by ffmpeg https://trac.ffmpeg.org/wiki/Encode/AAC#aac_at - ffmpeg builds from this thread offer 'aac_at' - Apple AAC codec.

[cholla]

I gave it a try but the suggestions I found did not work
They involved piping the ffmpeg converted file to fhgaacenc.
Also a path to these files is required:
enc_fhgaac.dll, libmp4v2.dll, nsutil.dll

This is the suggested ffmpeg code but it does not work for me. It always has an error.
If anyone can figure out how to do the pipe it may work.

ffmpeg -i input.mp4 -vn -f s16le -ac 2 -ar 44100 - | fhgaacenc --cbr 192 --profile auto -o output.m4a -

[autodidact]

Updated FFmpeg and libfdk_aac in post #33.

[cholla]

@ autodidact,
All the ffmpeg versions i have from you have --enable-libfdk-aac
& show this in the codec list:
L. aac AAC (Advanced Audio Coding) (decoders: aac aac_fixed aac_at libfdk_aac) (encoders: aac aac_at libfdk_aac aac_mf)
All have the capability to do libfdk_aac conversions.

Is there an improvement in the libfdk_aac conversion in the newest ffmpeg in post 33 ?

[autodidact]

Is there an improvement in the libfdk_aac conversion in the newest ffmpeg in post 33 ?

I don't think so. Most of the recent development and library version increase is related to the new
fdk-xhe-aac library which can now be produced when compiling fdk-aac. FFmpeg has also added support
for that new non-free library.