ffmpeg 7.0.1 and Windows 7

[manolito]

Thanks autodidact,

yes, this explains everything...


Cheers
manolito

[pandy]

yes I was talking to you, after many more tests using your versions I think I know pretty well what's going on...

Even if the core parts of your offerings are working under Win7, some of the additional content does not, and libzimg is one of them. Each of the scripts I have to convert HDR sources to SDR using libzimg crashes right after starting the script. This was obviously not tested, the FFmpeg devs in their eternal visdom seem to have decided to change libzimg so it no longer works under Win7.

The most simple script I use for HDR to SDR is this one:

zscale=1280:-2,zscale=m=gbr:t=linear:dither=none:npl=225,format=gbrpf32le,tonemap=mobius:desat=3.0,zscale=m=709:t=709:p=709:r=limited:c=left:dither=error_diffusion,format=yuv420p,sidedata=delete

Works perfectly under the other FFmpeg versions I use, but crashes your offerings immediately.

This is no problem by itself, but if someone advertizes his offerings as Win7 compatible I would expect that this claim was tested. For the builds you offer this is obviously not the case, so I'm out...


Thanks anyways, and cheers
manolito

Hi manolito

I feel guilty a bit as i never faced problem you described - tested some of my scripts with zscale and work fine without warning with latest build i suggested - so if you feel misguided please accept my apologies - i suggested AnimMouse builds not aware of problems you describe.

Sorry and cheers.

[autodidact]

Here is a build of FFmpeg git master with the following change along the lines suggested by manolito:

Added libfdk_aac functionality via external DLL to comply with the GPL. Enabling code here.

The DLL only needs to be downloaded and placed with the FFmpeg binaries if the libfdk_aac encoder is going to be used.
The FFmpeg binaries will otherwise execute normally without the DLL.

This may not be an indication of the configuration of future builds, just a demonstration for now.

[manolito]

Hi autodidact,

thanks for this new version, tested it quite extensively, but sadly it does not work here...

The error is the same as with the versions provided by pandy. Right after starting the encode it crashes with a (German) error message, and aborting is the only option. According to my tests it has nothing to do with libfdk_aac, I get the same behavior with your older version which does not include libfdk_aac.


More details:

My source is a file from https://kodi.wiki/view/Samples , the name is "Camp by Sony". The chroma position is
ChromaSubsampling/String : 4:2:0 (Type 2)

transfer characteristics are
transfer_characteristics : PQ


This source gets converted perfectly with Reino's encoder (v. 7.1 , 32bit only) as well as with the reddit offering (64 bit only):
https://www.reddit.com/user/VeritablePornocopium/comments/okw130/ffmpeg_with_libfdk_aa...x64/?rdt=51481


But when trying the same command with your latest build as well as with the versions offered by pandy I get immediate crashes. The crash notification is in German, and it does not give any information about the cause of the crash.

In case it might help I provide the conversion log by dmMediaConverter. I do not understand it completely, maybe you can find something in it...
Please note that dmMediaConverter has no interaction with the encoder whatsoever, it just calls the specified encoder with the command line it has created.

ffmpeg.exe  -fflags +genpts -y -hwaccel auto -i "D:\Download\Camp by Sony.mp4" -map 0:0 -filter:v:0 "zscale=1280:-2,zscale=m=gbr:t=linear:dither=none:npl=225,format=gbrpf32le,tonemap=mobius:desat=3.0,zscale=m=709:t=709:p=709:r=limited:c=left:dither=error_diffusion,format=yuv420p,sidedata=delete" -c:v:0 libx264 -preset:v:0 medium -tune:v:0 film -profile:v:0 high -level:v:0 4.1 -crf:v:0 19 -metadata:s:v:0 "creation_time=2016-02-03T07\:59\:49.000000Z" -metadata:s:v:0 "language=und" -metadata:s:v:0 "handler_name=Video Media Handler" -metadata:s:v:0 "vendor_id=[0][0][0][0]" -metadata:s:v:0 "encoder=HEVC Coding" -disposition:0 "+default-forced" -map 0:1 -c:a:0 libfdk_aac -vbr:a:0 4 -cutoff 18000 -channel_layout:a:0 "stereo" -metadata:s:a:0 "creation_time=2016-02-03T07\:59\:49.000000Z" -metadata:s:a:0 "language=eng" -metadata:s:a:0 "handler_name=Sound Media Handler" -metadata:s:a:0 "vendor_id=[0][0][0][0]" -disposition:1 "+default-forced" -map_chapters 0 -pix_fmt yuv420p "D:\Camp by Sony.mkv"

Hope this might help...

Cheers
manolito

[autodidact]

Hi manolito,

The first thing I would do is remove -hwaccel auto from the command or set it to one you know works on your system instead of auto.
The hardware accelerators in each FFmpeg build can vary greatly and it may be auto selecting one that is not compatible with your system.

The XP build:

dxva2
d3d11va

The reddit build:

cuda
dxva2
qsv
d3d11va

The AnimMouse build:

cuda
dxva2
qsv
d3d11va
vulkan
amf

My build:

cuda
dxva2
qsv
d3d11va
opencl
vulkan
d3d12va
amf

Your command does work here on that video.

[manolito]

Thanks autodidact,

this sounds very plausible, I tried all afternoon to get it working somehow, but no luck...

In dmMediaConverter users can either specify to use all available hardware accelleration automatically, or they can specify the separate accelleration methods they want to use separately. My original setting was "Automatic", and this produced the crash on startup. Trying all kinds of different accelleration methods did not change the error. Even turning HW accelleration comptetely OFF still resulted in the same crash with the identical message.

This may well be a peculiarity of my old Thinkpad T530 with its two separate graphics adapters. I think it is not worth it wasting any more time trying to fix this. I have two relatively recent FFmpeg versions (32bit by Reino and the 64bit offering from Reddit, they both work just fine).


So thanks a lot for your help and your patience...

Cheers
manolito

[autodidact]

Hi manolito,

It might be instructive if you can try an AnimMouse build from late February of this year rather than the most recent.

No pressure though.

[manolito]

Hi autodidact,

thanks for your suggestion, this works. Since i hate automatic daily builds I downloaded the latest stable build of the AnimeMouse version before February 2025, and this was from December 2024. Success, this build works.

The next think I want to test is if my Computer Setup has anything to do with this failior to work with the latest FFmpeg versions. There are some settings in the BIOS setup which influence the way how the two different graphics adaptors are treated, the current setting prefers the NVIDIA card over the built-in INTEL adapter. No idea if this will make any difference, but it cannot hurt to test this.

I will keep you posted about my findings...


Cheers
manolito

[manolito]

Tested the BIOS settings for the two graphics adapters extensively, but it was unsuccessful...

Even when I specified to only use the built-in graphics adapter exclusively and completely turning off the NVIDIA adaptor I got the same crash with the identical error messige as I got before. For all the available different configurations for the two adaptors the result was always identical.

So it seems clear that my old Thinkpad T530 hates the current FFmpeg test versions (or vice versa).


Thanks for your help anyways...

Cheers
manolito

[pandy]

So it seems clear that my old Thinkpad T530 hates the current FFmpeg test versions (or vice versa).

Test version may have undiscovered/unfixed problems i if official release work for You then perhaps this is good opportunity to raise bug in ffmpeg bugzilla system?

[autodidact]

thanks for your suggestion, this works. Since i hate automatic daily builds I downloaded the latest stable build of the AnimeMouse version before February 2025, and this was from December 2024. Success, this build works.

It looks like vulkan may be a problem for your system. The reason I suggested late Februrary is because the only major change to that build in a while is the addition of vulkan in early March. And vulkan is common to the builds that don't work for you (like mine), and is excluded from the builds that do work.

That doesn't rule out a bug in FFmpeg though. The presence of vulkan even if it can't be used shouldn't be causing a crash.

[cholla]

@ autodidact,
I appreciate your work to provide Windows7 32-bit builds.
Currently using this one: ffmpeg-7.1-static

In the videohelp forum I saw posted this codec: aac_at
The ffmpeg-7.1-static build does not have this codec.
I understand that may be because of a licensing conflict.
If not it would be a good codec to add.

I have an old Reino build that has libfdk-aac when I need it.
ffmpeg version N-106824-gf3b7ba2-Reino Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 11.2.0 (GCC)

Using my laptop that has Windows 7 64-bit.
I tried to bulid a newer version for Windows 7 32-bit with libfdk-aac.
Using media-autobuild_suite-master.
It failed with this error:

[Attachment 86490 - Click to enlarge]

[manolito]

thanks for your suggestion, this works. Since i hate automatic daily builds I downloaded the latest stable build of the AnimeMouse version before February 2025, and this was from December 2024. Success, this build works.

It looks like vulkan may be a problem for your system. The reason I suggested late Februrary is because the only major change to that build in a while is the addition of vulkan in early March. And vulkan is common to the builds that don't work for you (like mine), and is excluded from the builds that do work.

That doesn't rule out a bug in FFmpeg though. The presence of vulkan even if it can't be used shouldn't be causing a crash.

Hi autodidact,

thanks for your reply. My Thinkpad has these properties:
Intel Core i5-3230M (2,60 GHz, 3 MB L3, 1600 MHz FSB)

I searched extensively a while ago (when I tried to use libplacebo), but it seems to be clear that there is no support for vulkan with this CPU. I can live with this...

The last AnimeMouse version which does work without vulkan is this one:
ffmpeg-5a72266-4c3fc4e-win64-nonfree.7z

It is from Sunday, ‎‎January 12th, ‎2025, ‏‎22:47:06, all later versions seem to require vulkan, at least if zscale is used.


Cheers
manolito

[Hemingway]

Gentlemen, I have Windows 7 x64 and CPU without AVX and SSE4.

FFMPEG 7.0.1 compiled in September 2024 by autodidact serves me well and I am grateful for it. But 7.1.1 compiled in March 2025 crashes with the error 0xc000001d. However, AnimMouse recent builds still work fine, but they are static, whereas I prefer shared builds to save some disk space.

[autodidact]

@cholla

I don't think current MSYS2 works on Windows 7 anymore so the m-ab-s build won't work.
That particular error is for a function in Windows 8+. Maybe an older MSYS2 would still be useable, I don't know.
If you want to build your own, the Reino script will definitely work on Windows 7 and you could remove the Windows XP compatibility patches.
Of course it will have to build the whole gcc toolchain in cygwin which takes some time.
I recently produced a build with up to date FFmpeg when testing that script. I linked it at the time in post #20 under "XP".
ffmpeg-7.2-1753-8b2372c-win32-static-xpmod-P4.7z
libfdk-aac-2.0.3-146-2ef9a14-win32-xpmod-P4.7z

The aac_at codec is from audiotoolbox and I think is meant for MACOS builds so it requires a bit more complicated implementation using a wrapper to interface with iTunes libraries on Windows. Licensing is an issue for the necessary DLLs so the user would be responsible for installing iTunes or supplying the libraries needed to function. I'll look into it.

@manolito

Thank you for doing all that testing.

@Hemingway

A cpu with AVX is definitely not required. I added vvenc in 7.1 and it does require SSE4.1 so if your cpu is from the CORE2DUO era it may
lack that instruction set. Other than that I don't know why it is not working for you. I may modify future builds to be more broadly compatible
which may mean removing some things.

[El Heggunte]

1)

Using my laptop that has Windows 7 64-bit.
I tried to bulid a newer version for Windows 7 32-bit with libfdk-aac.
Using media-autobuild_suite-master.
It failed with this error:

2)

@cholla

I don't think current MSYS2 works on Windows 7 anymore so the m-ab-s build won't work.
That particular error is for a function in Windows 8+. Maybe an older MSYS2 would still be useable, I don't know.
If you want to build your own, the Reino script will definitely work on Windows 7 and you could remove the Windows XP compatibility patches.

@autodidact: I may be wrong, but I think the problem is not in MSYS2 itself, I think the problem is in the GCC executables downloaded and used by MSYS2. I have never liked those executables, so I always downloaded and used the GCC files provided by nevcairiel, OR I myself compiled them by using his modified build scripts.
Besides, MABS really is not Windows-7 friendly or 100% compatible, I agree, but it's mainly because it depends on the "latest and greatest" PowerShell, which definitely was not designed/optimized for anything below Windows 10.

3)

Of course it will have to build the whole gcc toolchain in cygwin which takes some time.

Friends don't let friends use cygwin.

[cholla]

@ autodidact,
I tested the ffmpeg & libfdk you posted in #20 & #45.
It produced the same .aac file as the older version a already have.
MediaInfo read them as the same.
They sound the same to me.
Since the version you posted has some newer files in it I plan to use it.

I had read the error was for Windows 8 so IDK why it displays in Windows 7.
I tried a "Fix" I found involving Windows Updates.
I uninstalled the suggested KB & installed the other suggested KB & installed the older KB afterwards.
Per instructions of the "Fix".
This did not work.

To both autodidact & El Heggunte compiling my own ffmpeg is above my current knowledge level.
I am trying to learn but it will take me a while.

[autodidact]

1)]@autodidact: I may be wrong, but I think the problem is not in MSYS2 itself, I think the problem is in the GCC executables downloaded and used by MSYS2. I have never liked those executables, so I always downloaded and used the GCC files provided by nevcairiel, OR I myself compiled them by using his modified build scripts.
Besides, MABS really is not Windows-7 friendly or 100% compatible, I agree, but it's mainly because it depends on the "latest and greatest" PowerShell, which definitely was not designed/optimized for anything below Windows 10.

I have read that mintty is the source of the "entry point GetSystemTimePreciseAsFileTime not found" error and I'm sure you are right about the PowerShell and GCC issues with MABS/MSYS2. I have made use of the nevcairel scripts as well. I guess the options are few for the Windows 7 user without much compiling experience.

1)]Friends don't let friends use cygwin.

That does take another option off the table. What to suggest then?

[autodidact]

Updated build of ffmpeg git master in post #33 with the following changes:

• enable libfdk_aac (external DLL) - suggested by manolito
• enable audiotoolbox (aac_at) - suggested by cholla
• remove vulkan - to possibly improve compatibility
• remove vvenc - (64bit only library) to possibly improve compatibility

[El Heggunte]

@autodidact: thanks for the up-to-date info about mintty, so if your sources are right, then the MSYS2 project is getting much worse than I expected.

I guess the options are few for the Windows 7 user without much compiling experience.

1)]Friends don't let friends use cygwin.

That does take another option off the table. What to suggest then?

The OLD MSYS2 base-installation archives appear to be our only option available.

To whom this may interest: on the web, you have to look for archives named "msys2-base-*.tar.xz"
(* = wildcard character). They are not many, and the ones dated from 2016 thru 2020/2021 should be 100% compatible with Windows 7 SP1. With them I used to build x264, x265, xvid, LAME, twolame, ffdcaenc, L-Smash, GCC itself , and even ffmbc.

Hope this helps.

[Hemingway]

Updated build of ffmpeg git master in post #33

Thank you, it works fine on my end without AVX and SSE4.
But the static version takes 430 MB, so for now I reverted to the shared version, which takes 160 MB.

To whom this may interest: on the web, you have to look for archives named "msys2-base-*.tar.xz"… Hope this helps.

There is msys2-base-x86_64-20221216.sfx.exe.

[cholla]

@ autodidact,
Thanks for the try/
Using aac_at did not work in a test.
It seems there is a lot more to do to get Windows to use aac_at.
I do not need it that much.
This is what I read on the reddit forum:

I finally figured it out! Open ffmpeg config file in notepad++, control F:

"enabled audiotoolbox && check_apple_framework AudioToolbox"

change to:

enabled audiotoolbox && check_apple_framework

./configure --extra-libs="-lAudioToolboxWrapper" --enable-audiotoolbox --disable-outdev=audiotoolbox --enable-AlltheOtherCrapUwant

Also, make sure you are using the latest release from the correct fork:

https://github.com/maz-1/AudioToolboxWrapper/releases

I added this commit as well so my itunes would act as the source:

https://github.com/dantmnf/AudioToolboxWrapper/compare/master...cynagenautes:AudioTool...Wrapper:master

If you are using --arch=x86 with msys2, you must use ffmpeg 6.1 or later due to an issue with binutils 2.41.

If it will help these are the errors from ffmpeg:

[aac_at @ 09d4c080] AudioToolbox init error: 3587
[aost#0:0/aac_at @ 0a4c2040] [enc:aac_at @ 0a4c2840] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.
[af#0:0 @ 0a4c2980] Error sending frames to consumers: Unknown error occurred
[af#0:0 @ 0a4c2980] Task finished with error code: -1313558101 (Unknown error occurred)
[af#0:0 @ 0a4c2980] Terminating thread with return code -1313558101 (Unknown error occurred)
[aost#0:0/aac_at @ 0a4c2040] [enc:aac_at @ 0a4c2840] Could not open encoder before EOF
[aost#0:0/aac_at @ 0a4c2040] Task finished with error code: -22 (Invalid argument)
[aost#0:0/aac_at @ 0a4c2040] Terminating thread with return code -22 (Invalid argument)
[out#0/adts @ 0a428b00] Nothing was written into output file, because at least one of its streams received no packets.
size= 0KiB time=N/A bitrate=N/A speed=N/A
Conversion failed!

[El Heggunte]

Updated build of ffmpeg git master in post #33

Thank you, it works fine on my end without AVX and SSE4.
But the static version takes 430 MB, so for now I reverted to the shared version, which takes 160 MB.

To whom this may interest: on the web, you have to look for archives named "msys2-base-*.tar.xz"… Hope this helps.

There is msys2-base-x86_64-20221216.sfx.exe.

I would prefer http://mirrors.enigma-dev.org/distrib/i686/ and http://mirrors.enigma-dev.org/distrib/x86_64/

Also, I hope the guide that I wrote some years ago has not become (too) outdated.

https://forum.videohelp.com/threads/394148-How-to-setup-an-MSYS2-building-environment

[autodidact]

@Hemingway
Thank you for testing.
The next release version of FFmpeg I will post a full set of builds, 32/64bit, static and shared.

@cholla
Thank you for testing.
It does work. I tested it before I posted the build.
Those are compiling instructions. It is already compiled and included in the posted binaries.
What is needed is the 8 iTunes/Quicktime DLLs to be available.

ASL.dll, CoreAudioToolbox.dll, CoreFoundation.dll, icudt62.dll, libdispatch.dll, libicuin.dll, libicuuc.dll, objc.dll

Depending on how the wrapper is patched it will look in a local folder QTfiles or QTfiles64, Program Files\iTunes\ or Program Files\Common Files\Apple\Apple Application Support\, or directly next to the FFmpeg binary. Placing the libraries next to the binary should guarantee that it works as long as the bitness matches. The wrapper I compiled doesn't look in the "Common Files" location.

@El Heggunte

Thanks for the MSYS2 information.

[manolito]

Hi autodidact,

tested your latest build, but no luck. Crashed whenever I used zscale in my script.

Since it works fine when zscale is not used, it should be some peculiar issue with zscale. I tried to analyze some source code, but this is way over my head...

The latest build by AnimeMouse which works for me is this one:
ffmpeg-5a72266-4c3fc4e-win64-nonfree.7z
from Sunday, ‎‎January 12th, ‎2025, ‏‎22:47:06

All later versions crash with the same error message. It is way beyond my capacity to analyze which code changes are to blame for this. Has the zscale code changed completely, or is it only a different compiler switch? Whatever, currently even your latest build is not working for me...


Cheers
manolito

[cholla]

@ autodidact,
I figured you tested the ffmpeg that has aac_at.

I do not have ITunes
I will see if I can locate the needed files .
Thanks for the list of .dlls' & locations that folders should be in.

@cholla
Thank you for testing.
It does work. I tested it before I posted the build.
Those are compiling instructions. It is already compiled and included in the posted binaries.
What is needed is the 8 iTunes/Quicktime DLLs to be available.

ASL.dll, CoreAudioToolbox.dll, CoreFoundation.dll, icudt62.dll, libdispatch.dll, libicuin.dll, libicuuc.dll, objc.dll

Depending on how the wrapper is patched it will look in a local folder QTfiles or QTfiles64, Program Files\iTunes\ or Program Files\Common Files\Apple\Apple Application Support\, or directly next to the FFmpeg binary. Placing the libraries next to the binary should guarantee that it works as long as the bitness matches. The wrapper I compiled doesn't look in the "Common Files" location.

[autodidact]

Hi manolito,

Here is another test build if you are willing to try it.
ffmpeg-git-1e5c65f539-zimg-test-WIN7_64.7z

[manolito]

Hi autodidact,

YES, that's the ticket, this test version DOES WORK just fine with my hardware...
Thank you so much!

Would you care to explain what settings you had to change to make this work? Just curious...

Whatever, this is another proof of the old saying: Never let the Computer win...


Thanks again and Cheers
manolito

[autodidact]

Would you care to explain what settings you had to change to make this work? Just curious...

I compiled a slightly earlier revision of libzimg. So I guess the latest code is not compatible with your machine.
They have been removing/moving/merging intrinsics helper code so if it is a bug, it may be very specific to your cpu type.

[manolito]

Hi autodidact,

thanks for your reply. It sounds like FFmpeg support for my ThinkPad will disappear soon, so I better start collecting versions which still support it...

Whatever, right now I cannot complain. The selection of fairly recent FFmpeg versions for Win7 which still support my computer is still pretty solid, and since I also use AviSynth+ I can always fall back to DGHDRtoSDR which does a pretty good job for these conversions.


Thanks again,
Cheers
manolito