Windows XP compatible non-SSE2 FFmpeg binaries

[Reino]

On Zeranoe (https://forum.doom9.org/member.php?u=200225)'s forum I had a topic where once every 4 months I would post new FFmpeg binaries that are Windows XP compatible and will work on old CPUs without SSE2 instruction sets (like my own AMD Athlon XP 3200+).
Because Zeranoe took down his forum not so long ago I thought I'd create a topic here on Doom9 in the hope some of you might still find these binaries useful.

This all began end 2016 when (as far as I could tell) no one was willing to create WinXP- and old-CPU compatible FFmpeg binaries anymore.
Windows XP doesn't support TLS 1.2 and the latest compatible FFmpeg binary back then couldn't open TLS 1.2 encrypted https-urls either, which a lot of websites started using. This was the main reason I wanted to see if I could compile my own FFmpeg binaries. With the help of a third-party cryptography-library (OpenSSL, GnuTLS, or MbedTLS) I could solve that issue.
I had never compiled software before. In fact, it was literally my first encounter with Linux (Cygwin) Bash! But after my first attempts (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/219) I forked Roger Pack's cross-compilation-script (https://github.com/rdp/ffmpeg-windows-build-helpers) and the rest is history.

Binaries: https://reino.synology.me/ (https://reino.synology.me/)
Github: https://github.com/Reino17/ffmpeg-windows-build-helpers (https://github.com/Reino17/ffmpeg-windows-build-helpers)

My FFmpeg binaries are compiled with --enable-libfdk-aac, but they don't contain the actual code because of an incompatible license. You can download libfdk-aac separately from my fileserver and put the dll-file in the same folder as 'ffmpeg.exe', or in any folder listed in the %PATH%-variable.
This was made possible with the help of a patch created by Gianluigi (https://oss.netfarm.it/mplayer/) Tiesi (https://github.com/sherpya/mplayer-be).

My FFmpeg binaries are also compiled with --enable-frei0r. You can download frei0r video filtering plugins separately from my fileserver and put the 'frei0r-1' folder in the same folder as 'ffmpeg.exe'.
This was also made possible with the help of a patch created by Gianluigi Tiesi.

Build-configuration:

--arch=x86
--target-os=mingw32
--prefix=/cygdrive/[...]/cross_compilers/mingw-w64-i686/i686-w64-mingw32
--cross-prefix=/cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-
--extra-cflags='-O2 -march=pentium3 -mtune=athlon-xp -mfpmath=sse -msse'
--pkg-config=pkg-config --pkg-config-flags=--static
--extra-version=Reino
--enable-gpl
--enable-gray
--enable-version3
--disable-bcrypt
--disable-debug
--disable-doc
--disable-htmlpages
--disable-manpages
--disable-mediafoundation
--disable-podpages
--disable-txtpages
--disable-w32threads
--enable-avisynth
--enable-frei0r
--enable-filter=frei0r
--enable-gmp
--enable-libaom
--enable-libass
--enable-libfdk-aac
--enable-libflite
--enable-libfontconfig
--enable-libfreetype
--enable-libfribidi
--enable-libgme
--enable-libjxl
--enable-libmp3lame
--enable-libopenmpt
--enable-libopus
--enable-librubberband
--enable-libsoxr
--enable-libtwolame
--enable-libvidstab
--enable-libvorbis
--enable-libvpx
--enable-libwebp
--enable-libx264
--enable-libx265
--enable-libxml2
--enable-libxvid
--enable-libzimg
--enable-mbedtls

Changelog 01-09-2024:
FFmpeg buildscript:
xz 5.4.6 --> 5.6.2
SDL2 2.30.3 --> 2.30.6
freetype 2.13.2 --> 2.13.3
mbedtls 2.28.8 --> 2.28.9
mpg123 1.32.6 --> 1.32.7
libopenmpt 0.7.6 --> 0.7.9
harfbuzz 8.4.0 --> 9.0.0
*git --> latest commit

ffmpeg 7.1-596-5bc3b7f (N-115062) --> 7.1-2362-6aafe61 (N-116828)

Optional external libraries for use with FFmpeg:
frei0r-plugins 2.3.2-16-fdc9f32 --> 2.3.3-3-cbb507d

[manolito]

Many thanks... :D

I already downloaded the new builds, also the new ffms2 C-plugin. Will start testing right away. And it is good to see you supporting your builds here at Doom9, should give you more visibility compared to the deceased Zeranoe forum.

Cheers
manolito

[manolito]

Sorry, no joy this time with both ffmpeg builds (static and shared)... :confused:

The new ffms2 build seems to work fine so far (only made two test encodes). But both ffmpeg builds crash immediately after calling them. I get the old error popup which is very familiar. No idea if it is WinXP, or if the missing SSE2 capability causes it.

https://i.postimg.cc/pLPyRFnp/ffmpeg-error.png (https://postimages.org/)

Cheers
manolito

[FranceBB]

Sweet. I still gotta test the new builds, but just like I said on MSFN last year: Doom9 is the international encoding forum and pretty much everyone is here, so you're definitely gonna have more visibility than on the zeranoe's forum.
Anyway, thank you for the builds, I'll try them as soon as I get back home! :)

[lvqcl]

The error text in english is probably this:
"The NtCreateFile API failed. This error should never be returned to an application, it is a place holder for the Windows Lan Manager Redirector to use in its internal error mapping routines"

Also, found this: https://github.com/msys2/MINGW-packages/issues/5139#issuecomment-479645419

[Reino]

I get the old error popup which is very familiar.Hmm, this is very strange, because here on WinXP Pro SP3 my binaries run just fine.
Doing a search for "NtCreateFile" returns:
[...]\i686-w64-mingw32\include\ddk\ntifs.h
[...]\i686-w64-mingw32\include\winternl.h
[...]\i686-w64-mingw32\lib\libntdll.a
[...]\i686-w64-mingw32\lib\libntoskrnl.a
These are all MinGW-w64 7.0.0 files. My binaries from 4 months ago were also already compiled with MinGW-w64 7.0.0 and if I remember correctly you didn't have any problems with these binaries. At the moment I don't know what to make of this.

Also, found this: https://github.com/msys2/MINGW-packages/issues/5139#issuecomment-479645419I'm using Cygwin 2.874, the latest WinXP compatible version. And I'm not using winpthreads, but pthreads-w32.
It could be that something else in the MinGW-w64 buildscript is causing this though.

[manolito]

My binaries from 4 months ago were also already compiled with MinGW-w64 7.0.0 and if I remember correctly you didn't have any problems with these binaries.

Correct, your binaries from 4 months ago do run just fine on my old computer... :confused:

My system is absolutely standard, the CPU is an Intel Celeron Coppermine 1.1 GHz.

https://i.postimg.cc/Kz69tjcX/system.png (https://postimages.org/)

If you need any more information, just let me know. For now I am back to the older version...
BTW the new libfdk DLL works just fine with the older ffmpeg binary. Is it safe to use it, or are there any catches?

[Reino]

Maybe you could run the binary through Dependency Walker (https://www.dependencywalker.com/) and see what it has to say.

I also came across "Bugs in NTDLL.dll of non-english editions of Windows® XP" (https://skanthak.homepage.t-online.de/fubar.html). This website claims - if I understand correctly - the issue you're experiencing could be a bug in 'NTDLL.dll' of your German Windows XP because of a specific security update.

[manolito]

Did some more troubleshooting, this is what I found:

First of all FFMpeg, FFPlay and FFProbe all behave identical, they all display the same error message.

My ancient desktop machine has been updated with the PosReady updates as long as they worked, no other software has problems with it. I have two other XP laptops which were not updated with the PosReady updates, and I tried to replace NTDLL.dll on my desktop with older versions of this file from the laptops. No luck, these older versions prevented the desktop computer from booting altogether with a WinLogon error.

Then I used DependencyWalker on the desktop testing both the 4 months old build plus the new build. The results are here:
https://www.sendspace.com/file/6cnfxq

The old build also shows a couple of missing dependencies, but it does work.


I then retrieved the other two XP laptops from the vault and tested the new FFmpeg build there. Both laptops were updated up to the last official XP updates, but no PosReady updates.

The first laptop was an old Medion Netbook Akoya E1210 (made by MSI) with an Intel Atom CPU. SSE2 capable. This time FFmpeg also crashed, but the error message was different. This time it said that the application could not start because of a missing MFPlat.dll file.

The other XP laptop was a Medion Akoya 96360 with an AMD Turion64 X2 CPU, also SSE2 capable. Same error as above.


So these crashes have nothing to do with the SSE2 capability of the CPU, it is solely WinXP related. And I really wonder why these new binaries work on your AMD Athlon CPU...


//EDIT//
Could it be that your latest builds rely on some Windows Media Foundation functions which are not available under WinXP? Is it possible to remove the Media Foundation requirements from the build script?

[StainlessS]

No idea if anybody can make any sense out of below,
is KDiff of both results from dependency walker posted by Mani,
Left is from older one "ffmpeg-4.3-3133-1128aa8-win32-static-xpmod-sse.dwi", right from newer "ffmpeg-4.4-853-276d86a-win32-static-xpmod-sse.dwi".
At the end, older working one is cut off after new one exits with error.

As Png files [for those that dont have kdiff or other installed]

1) https://i.postimg.cc/F1vRdG4d/1.png (https://postimg.cc/F1vRdG4d)

2) https://i.postimg.cc/YjxS1grX/2.png (https://postimg.cc/YjxS1grX)

3) https://i.postimg.cc/HVsk3xjT/3.png (https://postimg.cc/HVsk3xjT)

4) https://i.postimg.cc/nCRcWJQB/4.png (https://postimg.cc/nCRcWJQB)

5) https://i.postimg.cc/3kkJ5cg6/5.png (https://postimg.cc/3kkJ5cg6)

EDIT: I missed out less interesting/matching sections.
EDIT: Old one fails to find module QUSEREX.dll, new fails to find MFPLAT.dll.

Could it be that your latest builds rely on some Windows Media Foundation functions which are not available under WinXP? Is it possible to remove the Media Foundation requirements from the build script?
MFPLAT.dll. might be media foundation.
uses these from MFPLAT.dll

MFCreateAlignedMemoryBuffer
MFCreateMediaType
MFCreateSample
MFShutdown
MFStartup

[lvqcl]

From ffmpeg Changelog:
version 4.3:
...
- MediaFoundation encoder wrapper

from configure:
--enable-mediafoundation enable encoding via MediaFoundation [auto]

I suppose that the latest binaries were built on a modern computer and MediaFoundation encoder was auto-enabled.
Then the obvious solution is to recompile it with --disable-mediafoundation option.

[FranceBB]

Actually, I haven't experienced the same problems you guys are facing.
It might be because of several reasons, but on my computer it works like a charm: Screenshot (https://i.imgur.com/cZW6agd.png)
https://i.imgur.com/RfiVE24.png
Windows XP x86 all updates + POSReady Updates 'till June 2019 + custom kernel with PAE Enabled.
My Intel Xeon CPU supports SSE, SSE2, SSSE3, SSE4.1, SSE4.2, though.
I'm not sure whether the issues you guys are facing are related to your CPU instructions set or if it's due to the fact that I'm using One Core API (custom kernel with backported functions).
Anyway, it works over here. Same goes for ffms2 C plugin which works like a charm.

[Reino]

Hmm, this is getting weirder and weirder.
And I really wonder why these new binaries work on your AMD Athlon CPU...Maybe the fact that I'm using a highly optimized WinXP iso has something to do with it. I don't know.
https://thumbs2.imgbox.com/4c/bf/krLMx7lP_t.png (https://images2.imgbox.com/4c/bf/krLMx7lP_o.png)

As far as the "The NtCreateFile API failed"-error is concerned, it's really strange that only your German localized WinXP suffers from this. FranceBB, your WinXP is English (International)?
I can't imagine any of the changes in 'cross_compile_ffmpeg.sh' are the cause of this, so this night I'll put my pc to work and revert gcc to 9.3.0 and maybe revert binutils and the others too.


Old one fails to find module QUSEREX.dllHere too:
LoadLibraryA("C:\WINDOWS\system32\QUSEREX.DLL") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x01AEBA86.
LoadLibraryA("C:\WINDOWS\system32\QUSEREX.DLL") returned NULL. Error: The specified module could not be found (126).
GetProcAddress(0x00000000, "QueueUserAPCEx_Init") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x01AEB915 and returned NULL. Error: The specified procedure could not be found (127).
GetProcAddress(0x77C10000 [MSVCRT.DLL], "___lc_codepage_func") called from "FFMPEG-4.4-853-276D86A-WIN32-STATIC-XPMOD-SSE.EXE" at address 0x0270D40E and returned 0x77C330F4.
I have no idea what it is, but at least it doesn't crash the binary. Loading Gianluigi (Sherpya) his binary in Dependency Walker I don't get this log message.

I suppose that the latest binaries were built on a modern computer and MediaFoundation encoder was auto-enabled.
Then the obvious solution is to recompile it with --disable-mediafoundation option.No, I also compile on my AMD Athlon XP pc.
In 'ffbuild/config.log' I can indeed see mediafoundation=yes. Even though there's no reason not to autodetect MediaFoundation, because FFmpeg doesn't support WinXP anymore after all, it's really strange it is detected in my case. I guess I'll have to add --disable-mediafoundation.

[manolito]

Problem solved...

Reino just sent me a test build compiled with "--disable-mediafoundation", and this build works without any problems. :D

Thanks so much to Reino,

Cheers
manolito

[FranceBB]

FranceBB, your WinXP is English (International)?

Yep. EN US (International).
I changed it in 2013 as I didn't like the localized one I had from 2001 to 2013 anymore and I wanted everything to be in English. (There's probably a post on MSFN buried somewhere in the XP section)

Problem solved...

Reino just sent me a test build compiled with "--disable-mediafoundation", and this build works without any problems. :D

I'm glad that it's working fine on your end as well now. :)
Anyway, thank you Reino and long live to XP.

[Reino]

I guess it was --disable-mediafoundation after all. So no need to revert anything in the MinGW-w64 buildscript.
I've recompiled and replaced all 3 FFmpeg archives, as well as FFMS2, just to be sure.

[manolito]

Beautiful, your new builds work nicely...

FWIW you mentioned that you use a patch by Sherpya for your builds. Sherpya's FFmpeg builds used to be XP compatible on my ancient XP machine, but not any more. His latest build from June 2020 crashes right on startup with the same error popup as your build before the fix.

Looks like for XP users your builds are now the only game in town...

[StainlessS]

Big up to Reino, thanks very much https://www.cosgan.de/images/smilie/froehlich/k020.gif

[real.finder]

your build remind me of this (https://oss.netfarm.it/mplayer/)

btw, is build for xp mean remove some of the features from ffms2 and ffmpeg? or they the same as non-xp one?

[Reino]

[Sherpya's] latest build from June 2020 crashes right on startup with the same error popup as your build before the fix.The "avcodec: Add MediaFoundation encoder wrapper (https://github.com/FFmpeg/FFmpeg/commit/050b72ab5ef318605b305aa6cb920e8b52f1002e)"-commit is from 19 May 2020 and his -buildconf doesn't contain --disable-mediafoundation, so that's probably why.
Just like my own binaries before the fix, for me Sherpya's 'ffmpeg.exe' doesn't crash upon simply invoking ffmpeg.exe, BUT does crash the moment I use -c:v libx264.
According to his source (https://github.com/sherpya/mplayer-be/blob/master/config.sh) (see "GLOBAL_CFLAGS") he does compile FFmpeg for non-SSE2 cpus, so I don't know what causes this crash.

A bit off-topic, but what puzzles me is how relatively small his binaries are. His 'ffmpeg.exe' has more components/libraries on board and is even compiled with --enable-hardcoded-tables (which if I'm correct increases filesize), but is still ~18MB smaller than mine. :confused:
is build for xp mean remove some of the features from ffms2 and ffmpeg? or they the same as non-xp one?From the top of my head... libx265 doesn't support high bit-depth, but apart from that everything is the same. Only made compatible for WinXP and non-SSE2 cpus.

[qyot27]

From the top of my head... libx265 doesn't support high bit-depth, but apart from that everything is the same.
It's not that it can't, it's that you have to use -DENABLE_ASSEMBLY:bool=off to enable 10 and 12 bit on i686 (which also means encoding to those bit depths will be slow as molasses, but it can be done). Nothing to do with XP.

[Reino]

I know that libx265 supports high-bit-depth. I should've chosen my words more carefully. What I meant was: the libx265 that's part of my FFmpeg binary doesn't support high-bit-depth, because...

http://hg.videolan.org/x265/file/tip/source/CMakeLists.txt (http://hg.videolan.org/x265/file/tip/source/CMakeLists.txt):
if(X64)
# NOTE: We only officially support high-bit-depth compiles of x265
# on 64bit architectures. [...]
[...]
endif(X64)

[Reino]

I've just uploaded new binaries. That is, only a static build for FFmpeg so far.

Running configure (while trying to compile a shared build) went just fine, but not with make. This is the short log:
GEN libavutil/libavutil.version
GEN libswscale/libswscale.version
GEN libswresample/libswresample.version
GEN libpostproc/libpostproc.version
GEN libavcodec/libavcodec.version
GEN libavformat/libavformat.version
GEN libavfilter/libavfilter.version
GEN libavdevice/libavdevice.version
CC libavdevice/alldevices.o
CC libavdevice/avdevice.o
CC libavdevice/dshow.o
CC libavdevice/dshow_common.o
CC libavdevice/dshow_crossbar.o
CC libavdevice/dshow_enummediatypes.o
CC libavdevice/dshow_enumpins.o
CC libavdevice/dshow_filter.o
CC libavdevice/dshow_pin.o
CC libavdevice/gdigrab.o
CC libavdevice/lavfi.o
CC libavdevice/reverse.o
CC libavdevice/sdl2.o
CC libavdevice/utils.o
CC libavdevice/vfwcap.o
WINDRES libavdevice/avdeviceres.o
/bin/sh: /cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -E -xc-header
-DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or directory
/cygdrive/m/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-windres: preprocessing failed.
make: *** [ffbuild/common.mak:93: libavdevice/avdeviceres.o] Error 1
If anyone knows what's going on and knows how to fix it, I'd really appreciate it.

About the static FFmpeg build; thanks to Stephen Douglas the x265 library is now multi-bit-depth:
ffmpeg.exe -hide_banner -h encoder=libx265
Encoder libx265 [libx265 H.265 / HEVC]:
General capabilities: delay threads
Threading capabilities: other
Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p gbrp
yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le
yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
[...]

[patul]

WINDRES libavdevice/avdeviceres.o
/bin/sh: /cygdrive/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -E -xc-header
-DRC_INVOKED -MMD -MF libavdevice/avdeviceres.d -MT libavdevice/avdeviceres.o: No such file or directory
/cygdrive/m/[...]/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-windres: preprocessing failed.
make: *** [ffbuild/common.mak:93: libavdevice/avdeviceres.o] Error 1

Perhaps windres.exe (part of binutils) was the problem, maybe you can try to use previous working version?

[manolito]

I've just uploaded new binaries. That is, only a static build for FFmpeg so far.

Thanks... :D:D:D
Works here without any issues.

[FranceBB]

Thanks for the new build, hugely appreciated! ;)

[Reino]

Perhaps windres.exe (part of binutils) was the problem, maybe you can try to use previous working version?
Too late I noticed "windres error with binutils 2.36.1 (https://github.com/rdp/ffmpeg-windows-build-helpers/issues/554)" and the suggested fix (https://github.com/rdp/ffmpeg-windows-build-helpers/pull/558/files), because I had already started a complete re-run with binutils 2.35.2.
Anyway, going back to 2.35.x proved successful. Thanks.

I've just uploaded new ffmpeg binaries and removed the "old" static one.

[FranceBB]

Thanks! :D
Any plan for a new build of ffms2 as well?
(I'm not in a hurry, just saying. And by the way, thank you so much for keeping the project updated and XP compatible).

[Reino]

Seeing there are no new commits (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin) since my last build, I wasn't about to.

[FranceBB]

Ah, right, so nothing changed, I see...
Well, that's fine then. :)

[manolito]

@Reino

could you have a look at this post:
https://forum.doom9.org/showthread.php?p=1943204#post1943204

[GMJCZP]

I'm testing version 4.5 static and it doesn't have the -preme argument (Estimation of previous movement) than if you have another videohelp build, the 4.2 static. Did they remove -preme?

[Reino]

I have no idea what you're talking about. Are you sure you posted in the right topic?

[GMJCZP]

In my signature I have a script based on FFMpeg to encode files to DVD. I downloaded the latest version and noticed that the -preme argument does not recognize it, my doubt is that the folks at FFMpeg removed -preme from their compilations.

Reino, or could it be that when compiling you skipped -preme?

[lvqcl]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/d85c41b5723a4acf9400043cb533682d2e2c4287#patch3

avcodec: Remove private options from AVCodecContext


-#if FF_API_PRIVATE_OPT
- /** @deprecated use encoder private options instead */
- attribute_deprecated
- int pre_me;
-#endif

[GMJCZP]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/d85c41b5723a4acf9400043cb533682d2e2c4287#patch3

avcodec: Remove private options from AVCodecContext


-#if FF_API_PRIVATE_OPT
- /** @deprecated use encoder private options instead */
- attribute_deprecated
- int pre_me;
-#endif

Thanks, but I downloaded a version shared from Here (https://github.com/sudo-nautilus/FFmpeg-Builds-Win32/releases/tag/autobuild-2021-06-27-12-28) and is present -preme.

[Reino]

Apart from a couple of patches to make ffmpeg WinXP compatible again, I haven't removed functionality. At least, not that I know of.

[GMJCZP]

Don't worry Reino, I suspect that preme was removed due to optimizations in the same encoding. I did a quick test and did not notice practically any major difference, so an increase in speed has apparently been gained, I say apparently because this increase may also be due to general optimizations.

[nevcairiel]

The option is still available in newer FFmpeg, it just changed its name - the global option was removed, and the codec-specific one for mpeg remains. So for this particular option, try "-mepre" instead

[GMJCZP]

The option is still available in newer FFmpeg, it just changed its name - the global option was removed, and the codec-specific one for mpeg remains. So for this particular option, try "-mepre" instead

Thanks for the clarification, I have confirmed the information.

[Reino]

I wanted to release new FFmpeg binaries, but I'm having difficulty creating error-free binaries. I need some more time, if I can fix it at all. "When it's done", I guess. :(

[FranceBB]

No worries, there's no rush. :)

[Reino]

A couple of headaches later...
Earlier this evening I've uploaded new binaries. Changelog in post #1 as usual. And my Github repo is already up-to-date as well.

At first libass its DirectWrite implementation caused a compilation-error (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/bedd85a5647def711207d02a0eebbc00e0e6a3a5).
Next a successfully compiled FFmpeg binary crashed immediately with the Windows error-message "The procedure entry point InitializeConditionVariable could not be located in the dynamic link library KERNEL32.dll".
Doing a search for "InitializeConditionVariable" among the compiled and installed libraries returned:
[...]/i686-w64-mingw32/lib/libwebp.a
[...]/i686-w64-mingw32/lib/libx265.a
For further testing I've compiled FFmpeg without --enable-libwebp and --enable-libx265, but it now crashed with the Windows error-message "The procedure entry point K32GetProcessMemoryInfo could not be located in the dynamic link library KERNEL32.dll".
Lots of searching and reading and through https://www.mingw-w64.org/changelog (https://www.mingw-w64.org/changelog) I landed at...

https://sourceforge.net/p/mingw-w64/mailman/message/37287751 (https://sourceforge.net/p/mingw-w64/mailman/message/37287751):
_WIN32_WINNT is now set to Windows 10 as default.

I had updated Zeranoe's "MingGW-w64 Build Script" (https://files.1f0.de/mingw/scripts) to r32, which uses MingGW-w64 9.0.0. Reverting MingGW-w64 to 8.0.2 (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/b1d4257c11a61df7876e58990b0952f380406a29) resolved all errors.

The strange thing is that, unlike 'libwebp.a', 'libx265.a' still contains "InitializeConditionVariable" (a function not available on WinXP), but using -c:v libx265 seems to work just fine (so far).

I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?

[LoRd_MuldeR]

I'm not a coder by profession, so I was wondering if anyone knows if MingGW-w64 9.0.0 contains some sort of WinXP compatible configuration option to correctly set "_WIN32_WINNT". Or would patching be required?
You #define _WIN32_WINNT (or set it via -D_WIN32_WINNT command-line option) to specify the version of Windows NT that you are targeting.

And you have to do this before #include'ing the <Windows.h> header file, or before #include'ing anything that implicitly #include's the <Windows.h> header file – otherwise it will have no effect at all!

Anyways, all that _WIN32_WINNT really does is to enable/disable the declaration of certain Win32 API functions (in the header file, and only there), depending on whether they were available in the target Windows version.

It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail :rolleyes:


Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!

If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.

For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.


Last but not least, latest MinGW-w64 still can (https://sourceforge.net/projects/muldersoft/files/cURL/curl-windows-x86.2021-06-20.zip/download) produce binaries that run on Windows XP, i.e. MinGW-w64's own runtime apparently doesn't use any Win32 API functions that weren't available in Windows XP.

But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64. Obviously, libwinpthread uses Win32 API functions only available on Vista and higher – and there's not much you can do about that. Consequently, as soon as the application code (or any of the dependencies that you are linking in) uses multi-threading via the pthread-API, then the resulting binary won't run on Windows XP. At least when using libwinpthread.


As an aside: Dependency Walker (https://www.dependencywalker.com/) (or, on modern Windows versions: Dependencies (https://github.com/lucasg/Dependencies) by lucasg) is your friend! ;)

[Reino]

(or set it via -D_WIN32_WINNT command-line option)Which I assume is a cmake option?

It does not "magically" change the application code! So, if the code that your are compiling depends on a certain Win32 API function, but that function is disabled via _WIN32_WINNT, then the compilation is going to fail :rolleyes:Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.

Also note that _WIN32_WINNT does not effect the pre-compiled libraries (.a files), which you are linking, in at all! That's because _WIN32_WINNT has to be used at compile-time, not at link time!I don't use pre-compiled libraries. I compile everything myself, because not only do the binaries that I compile need to be WinXP compatible, they need to work on old non-SSE2 cpus as well.

If you want to change the target Windows version of a library (.a file), then you have to re-compile that library from the sources and correctly set _WIN32_WINNT while doing so.Yes, I understand I have to re-compile all dependency libraries in that case.

For the same reason, setting _WIN32_WINNT has no effect on MinGW-w64 itself or any of the pre-compiled libraries that ship with MinGW-w64. It may have an impact, if you build MinGW-w64 yourself, from the sources.Which I do, as I'm using Zeranoe's "MingGW-w64 Build Script" after all.

But: That does not apply to libwinpthread, i.e. the implementation of the pthread-API that comes with MinGW-w64.The reason why I'm compiling MinGW-w64 with pthreads-w32 (which is the default thread library in Zeranoe's "MingGW-w64 Build Script" anyway).

Thanks for your elaborate post, LoRd_MuldeR.

[LoRd_MuldeR]

Which I assume is a cmake option?

It's an option for GCC. Or any compiler with GCC-compatible command-line syntax, such as Clang. You generally add this to the CFLAGS (https://en.wikipedia.org/wiki/CFLAGS), or whatever is the equivalent in cmake.

Then I might as well stick to MingGW-w64 8.0.2 from now on to save myself lots of trouble.

Don't know how this would save you from trouble.

If the code of the application (or its dependencies) that you are compiling uses some function from the Win32 API that was not yet available in Windows XP, then it won't be able to run on Windows XP – regardless of which version of MingGW-w64 you are using to build. Even setting _WIN32_WINNT to 0x0501 won't "magically" make the code run on Windows XP; this only causes the compilation to fail, if the code attempts to call a function that was unavailable in Windows XP.

Only way to get the application (or library) work on Windows XP will be to "patch" the actual program code in order to remove/replace any invocation of the "problematic" Win32 API functions...

[manolito]

Hi Reino,

long time no see, and you are no longer too active in the forum. I have been away for more than a year now due to a stroke. I try to relearn a few of my computer skills, but it is tough...

Back to your FFMpeg builds:
The version I have installed is still v. 4.5 from May 2021, and it works nicely. Now I noticed that you published new versions, the current one is v. 5.2. So I wonder if I should update. I do not think that I really need any new FFMpeg features, I am more interested in bug fixes and other improvements.

I made a short conversion using the current version 5.2, and everything seemed to work well, but I am a little reluctant to jump on the latest and greatest without asking for possible catches. As I already said, I am not looking for new FFmpeg features, I just like to take advantage of possible improvements and fixes of existing features.

I also have to say that in the past I did have some bad experiences with using new major FFMpeg versions too soon before they had time to mature. Maybe it would be safer to continue using the final 4.5 version for now?

Cheers
manolito

[Reino]

you are no longer too active in the forum.Yes. Too little time and other interests, I guess. From time to time I do still read threads of interest though.
I have been away for more than a year now due to a stroke.I'm sorry to hear that.
So I wonder if I should update. I do not think that I really need any new FFMpeg features, I am more interested in bug fixes and other improvements.In that case I think you should. I haven't enabled any extra external libraries in my FFmpeg binaries, so I think bug fixes and other improvements (upstream) is exactly what you can expect.

[manolito]

Thanks for your advice, much appreciated...

I made a couple of more tests under Win7 using your latest version 5.2 together with libfdk, no problems whatsoever. Still need to test if my ancient WinXP machine also likes version 5.2.

Thanks again
manolito

[metis]

@LoRd_MuldeR
Only way to get the application (or library) work on Windows XP will be to "patch" the actual program code in order to remove/replace any invocation of the "problematic" Win32 API functions...
This means Revising - and, if necessary, Modifying :scared: - the entire FFmpeg-SourceCode and the Sources of all Dependencies, that
link to the actual FFmpeg-Build - Phew, that's really a lot of Work !


@manolito
Still need to test if my ancient WinXP machine also likes version 5.2.
I just tried it on my WinXP 32-bit SP3...

I use the FFmpeg-DLLs in my FFPlay4Laz-Project, which is an ultrafast FFmpeg-based MediaPlayer/-PlayerEngine with
outstanding AudioQuality via PortAudio (www.portaudio.com) and ASIO (and some other "unusual" Features):
https://forum.lazarus.freepascal.org/index.php/topic,26666.msg428667.html#msg428667
This is the latest Release - The next Release will use Reino's WinXP-compatible Build for FFmpeg v5.2 to keep that Player
Running from WinXP to Win10 w/o any Modifications. :)

The FFmpeg-CLIs are required by 'RunFFmpeg', which is Part of my FFGrab4Laz-Project:
https://forum.lazarus.freepascal.org/index.php/topic,43411.0.html
-> GoTo "RunFFmpeg".
This is the OpenSource-BasicStructure for an ALL-In-One-GUI for any FFmpeg-Task, like
ScreenRecording, Converting, Playback/Streaming, Ripping/Recording, ... endless.
Everyone may extend and modify it to his personal Needs.

I tried both with Reino's shared Builds for FFmpeg v4.2 + v5.1 + v5.2, and they work all perfectly.
The DEVs I tried with Code:Blocks v17.12/gcc v5.1.0 (32-bit) - They work fine, as well.


@Reino
Which OS do You use for Your WinXP-compatible FFmpeg-Builds ?

Formerly, I used the FFmpeg-Builds from FFVCL (http://www.delphiffmpeg.com/downloads/) or I've built them myself.
But, this no longer works on my WinXP with newer FFmpeg-Versions (:(). So I am very glad, that I found your WinXP-Builds.
Many Thanks for your Work from all, who cannot be w/o their beloved WinXP-Machines (like me :) ).

[metis]

The next Release will use Reino's WinXP-compatible Build for FFmpeg v5.2
@Reino
Here it the first Release of FFPlay4Laz, that uses Your WinXP-compatible FFmpeg-Build:
https://forum.lazarus.freepascal.org/index.php/topic,26666.msg464784.html#msg464784 :)

[StainlessS]

For Reino and others interested in maintaining XP compatability:

It might seem obvious, but, even if using some later compiler, you should install XP compatible help/docs for XP and pretty much ignore your compiler docs [except on the subject of compiler OR XP compatability],
compiler docs will only doc for latest compiler/OS which of course may not work at all on XP+.

EDIT: Many thanx to Reino and Metis and all other contributers, I no longer have XP machine but like to maintain XP compatability just the same.

[FranceBB]

For Reino and others interested in maintaining XP compatability:

It might seem obvious, but, even if using some later compiler, you should install XP compatible help/docs for XP and pretty much ignore your compiler docs [except on the subject of compiler OR XP compatability],
compiler docs will only doc for latest compiler/OS which of course may not work at all on XP+.

If you're using MSVC through visual studio etc it's just a matter of including v141_xp during the installation (you have to specifically select it in the c++ tools) and targeting it while building and also include /Zc:threadSafeInit as compiling option. Once you've done that, it's highly likely that the build will effectively run on XP. ;)

[Reino]

Strange. Obviously I'm subscribed to my own thread, but I haven't received any notification e-mails.

@metis, glad to be of help. I'm using (a highly tweaked and slimmed down (https://www.nliteos.com/nlite.html)) WinXP Pro SP3.

I wanted to release another batch of FFmpeg binaries, but I actually came here today to tell that I'm a little stuck (https://msfn.org/board/topic/184276-error-while-compiling-python-3410-with-latest-winxp-compatible-cygwin). :(

[metis]

@Reino

I'm using...WinXP Pro SP3.
I also use a nLited WinXP Pro SP3, but only as long as I'am not on the Internet. For the Internet I use Linux Mint.
AFAIK, You can't build FFmpeg w/o InternetConnection, respectively w/o Internet it's quite nerve-wracking
to get all the Files and LIBs which are required during the Build-Process.
So, how do You do Your Builds on WinXP ?
Download all Dependencies before Building, and Compile them all "XP-friendly" ?

I wanted to release another batch of FFmpeg binaries...
Don't worry. I've just finished Updating the FFPlay4Laz-Code to Your latest FFmpeg-Build (= v5.2).
So, there's no hurry - at least not for me.

What would be missing in FFmpeg if You simply omit Python in the Build ?

[Reino]

This is still my every-day-computer, so I'm connected obviously. I don't see a reason why I shouldn't.

What would be missing in FFmpeg if You simply omit Python in the Build ?At the moment the latest Mbed TLS 3.3.0 (https://github.com/Mbed-TLS/mbedtls/releases) release. I've switched to the Mbed TLS 2.28.2 branch, which, despite some Python 3 warning messages, did compile without errors.
Next weekend I'll have some time to look at this again

[StainlessS]

it's just a matter of including v141_xp
...
Once you've done that, it's highly likely that the build will effectively run on XP. ;)

Nah, many of the system API calls doc'ed in more current compilers dont exist on XP [I know you use a 'frigged' up XP with VISTA/W7
API extension but not everybody does, and some calls may require W10 API].

Another problem is, if you only use current compiler docs, they may only present info for current systems, and may even say things like
supported from W10+ when in actual fact the call may have been supported since Windows 3.1, so is also misleading.

Above is probably a big part of why support for older systems is dropped, its just tiresome to have to look up multiple sets of docs.
You wanna support XP, then good idea to only [or mostly] use XP docs for API and system calls.

However, for just re-compiling code that was written with XP support in mind, then your reply should be good.

[FranceBB]

[I know you use a 'frigged' up XP with VISTA/W7
API extension but not everybody does, and some calls may require W10 API].


Speaking of which, I invite everyone to try One Core API on Windows XP, which is essentially the XP version of KernelX for Windows98SE. Thanks to the custom kernel with functions backported from newer version of Windows (currently Vista and 7) it allows programs compiled for newer version of Windows to run on XP natively. Since we leverage a lot on the Wine project (a big fat thank you to the Linux guys working on Wine and ReactOS), if a program runs through Wine on Linux it will almost definitely run on Windows XP with One Core API.

Builds: https://github.com/Skulltrail192/One-Core-API-Binaries/releases

Source Code: https://github.com/Skulltrail192/One-Core-Api

The code is open source and we're looking for people to help 'cause we're a tiny community of XP enthusiast and Samuel (who is driving the development) can't do everything on his own, so if any of you is willing to help, feel free to reach out. :)


Oh and as always, long live to Windows XP.

https://i.imgur.com/kWGsepg.png

[Emulgator]

Many thanks for bringing OneCoreAPI to my attention, again.
Software restrictions and requirements have me keeping at least 3 different Win systems running: WinXP32SP3, Win7U64, Win10Pro64.
and I maybe even have to go back to Win98 sooner or later for measurement software.
Very valuable, lets make ends meet.

[j7n]

Unless something has changed recently, One-Core-Api is different from KernelEx. It is a collection of many files from Windows NT6, and for this reason was banned by the copyright police on the other forum. After installation you would no longer have "XP", but a hybrid. KernelEx was very small with only some critical functions implemented.

[FranceBB]

Unless something has changed recently, One-Core-Api is different from KernelEx. It is a collection of many files from Windows NT6

Meh, it's just that the MSFN guys are just overly concerned with not redistributing any Windows dll at all ever, so they didn't want that. Not that there's anything wrong with it, in fact the RyanVM guys were more than willing to link those things. Besides, the backported APIs are open source and publicly available on GitHub (which is owned by Microsoft by the way), while the redistributed dll are just Microsoft dll that one can find in any version of Windows, so it's not like we're doing something bad.

[Reino]

Next weekend I'll have some time to look at this again
...and another batch is uploaded. See post #1 for details.

To circumvent the Python 3 issue (for now) I've switched to the Mbed TLS 2.28.2 branch, as mentioned earlier.
And I've re-added the time-stretching and pitch-shifting rubberband audio-filter, as per special request.

[FranceBB]

Outstanding news, Reino, thanks! :D
Speaking of which, are we gonna get a new build of ffms2 as well? :)
The last one was based on ffmpeg 4.5 while we're at 5.2

[Reino]

But latest commit (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin) is from 20-05-2021. Or would a release based on a newer FFmpeg make a difference?

[FranceBB]

would a release based on a newer FFmpeg make a difference?

Same ffms2, just based on a newer FFMpeg version so that decoders are new.
It would make a difference, namely it would:

1) Be able to decode Sony's IPCM (https://forum.doom9.org/showthread.php?p=1942427)
2) Be able to properly decode DNX120 interlaced (https://forum.doom9.org/showthread.php?p=1943529)

[Reino]

See https://rwijnsma.home.xs4all.nl/files/ffms2 (https://rwijnsma.home.xs4all.nl/files/ffms2). Untested.

[FranceBB]

Doesn't work... :(

https://i.imgur.com/Bh9rEz7.png

It's missing the Bcrypt stuff

BCryptCloseAlgorithmProvider
BCryptGenRandom
BCryptOpenAlgorithmProvider

https://i.imgur.com/Bh49A82.png

[Reino]

Sorry, my mistake (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/ed1ea1b378af732ffb2e79105bdc95c6903b0aed). Please re-download.

[FranceBB]

Works like a charm. ;)

https://i.imgur.com/O75rVix.png

[Reino]

Four months have gone by, so it's time for another round of binaries. As usual, see post #1 for details.

This time there's one little difference though. I had to compile FFmpeg without libfdk-aac this time. It appears the FFmpeg developers have pushed quite some libfdk-aac related code the last couple of months, but Gianluigi hasn't updated his code (https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0004-dynamic-loading-of-shared-fdk-aac-library.patch) yet (on which I depend). And I'm getting "undefined reference to"-errors with the patch in its current state. I wish I could code in C/C++, but alas.
This actually makes me wonder; do we really still need libfdk-aac? I haven't really been keeping up with FFmpeg's development progress lately, and its internal AAC encoder in particular, so does anyone know how this encoder performs quality-wise compared to libfdk-aac at the moment? I know at least that a couple of years ago it did pretty good already, though not yet as good as libfdk-aac.

Besides FFmpeg, one can also find new binaries/libraries of frei0r, openssl, curl and xidel on my host. And especially for FranceBB ;), I've compiled ffms2 (again, no new updates) against my latest shared FFmpeg release. This means that 'ffms2.dll' is really small now, but relies on 'avformat-60.dll', 'avcodec-60.dll', etc. somewhere in %PATH%.

[manolito]

I had to compile FFmpeg without libfdk-aac this time

Thanks for the new version, but this effectively makes this new build unusable for me. My Xtreamer external player does not get along with FFmpeg´s internal aac encoder, most audio which was encoded with the native FFmpeg encoder comes out totally distorted. There have not been software updates for my Xtreamer for many years now, and I will not discard it just for this reason.

Which means that I need to downgrade FFmpeg to the previous version again, I think that I will not be missing too many things.


Cheers
manolito

[Reino]

You won't be missing anything at all, because libfdk-aac (https://github.com/mstorsjo/fdk-aac) hasn't seen any updates since 31-05-2022.
For the next release I assume Gianluigi has updated his code.

[Jamaika]

You won't be missing anything at all, because libfdk-aac (https://github.com/mstorsjo/fdk-aac) hasn't seen any updates since 31-05-2022.
For the next release I assume Gianluigi has updated his code.
Or maybe it's because fdk-aac is added for other systems like GCC that don't work with aac float ffmpeg.

[Jamaika]

Maybe use this
https://github.com/schreibfaul1/FDK-AAC-DECODER-in-C

[FranceBB]

especially for FranceBB ;), I've compiled ffms2 (again, no new updates) against my latest shared FFmpeg release. This means that 'ffms2.dll' is really small now, but relies on 'avformat-60.dll', 'avcodec-60.dll', etc. somewhere in %PATH%.

No problem, I've put avcodec-60.dll and avformat-60.dll in C:\Program Files\Avisynth\Plugins along ffms2.dll, ffindex.exe and ffms2.avsi and it worked like a charm. :)

https://i.imgur.com/OwRDVPl.png

[metis]

@Reino
I've tried Your latest Build for FFmpeg v6.1:
Works perfectly for me on WinXP-Win10 + Linux with Wine (Win11 and macOS not tested yet).
Tnx, again for Your Work.

@manolito
This Player (https://forum.lazarus.freepascal.org/index.php/topic,63404.0.html) works with Reino's latest Build and AAC.

[Reino]

I've just updated post #1 for another round of binaries.

I had to compile FFmpeg without libfdk-aac this time. It appears the FFmpeg developers have pushed quite some libfdk-aac related code the last couple of months, but Gianluigi hasn't updated his code (https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0004-dynamic-loading-of-shared-fdk-aac-library.patch) yet (on which I depend). [...] I wish I could code in C/C++, but alas.This is sadly still the case. No updates on Gianluigi's repo either. And this also caused a problem for one of THE 2 "make-ffmpeg-winxp-compatible-again"-patches, '0001-make-bcrypt-optional.patch' (https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/patches/0001-make-bcrypt-optional.patch). The source-file involved here, 'libavutil/random_seed.c', received a number of updates in july from the FFmpeg developers, so I had to update the patch. Even though I can't code in C, after some trial and error I think(!) I got it right. I haven't tested stuff extensively, but at least I can open (hls-)video-urls without issue.
If you're reading this and you're a developer who can code in C, maybe you can tell me if I've correctly updated the 0001 patch, especially with regards to this FFmpeg commit (https://github.com/FFmpeg/FFmpeg/commit/d694c25b44c319eadfb8039fc917639314cadb08).

To circumvent the Python 3 issue (for now) I've switched to the Mbed TLS 2.28.2 branchThis has been solved (https://msfn.org/board/topic/184276-error-while-compiling-python-3410-with-latest-winxp-compatible-cygwin) and the FFmpeg binary is now using the latest Mbed TLS 3.4.1.

No problem, I've put avcodec-60.dll and avformat-60.dll in C:\Program Files\Avisynth\Plugins along ffms2.dll, ffindex.exe and ffms2.avsi and it worked like a charm. :)Could you please test the latest 'ffms2-2.18-841-d42a696-avs-vsp-win32-shared-xpmod-sse.7z'? The last couple of days it got a lot of updates (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin). I haven't had the time to test it myself, but by the looks of it the functions FFVideoSource(), FFAudioSource(), etc. are now hardcoded in 'ffms3.dll'.

[FranceBB]

Oooops, I totally forgot to reply!

FFVideoSource() as well as FFMpegSource2() from the package ffms2-2.18-841-d42a696-avs-vsp-win32-shared-xpmod-sse from 2023-09-04 throw an ACCESS VIOLATION when I try to use them. :(
Version ffms2-2.18-756-4d45afc-avs-vsp-win32-shared-xpmod-sse from 2023-05-04 throws a "platform returned code 126: the specified module could not be found" error as if it couldn't really load ffms2.dll.

The last safe version is the one from January of this year, namely 2023-01-08 ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse
To be absolutely safe, could you build the other two (or perhaps just the latest one) as static rather than shared to see if maybe that's the issue?



One more note: about version ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse from 2023-01-08, it looks like it doesn't fully support UTF-8 characters.

Something like this:

FFMpegSource2("abc.mkv", atrack=-1)

works, however something like:


FFMpegSource2("àèéìòù.mkv", atrack=-1)


doesn't.
Recently there's been a lot of discussion about UTF-8 support here (https://forum.doom9.org/showthread.php?p=1993989) and here (https://forum.doom9.org/showthread.php?t=127037&page=139), but essentially the very latest version of ffms2 by StvG introduces UTF-8 support, so perhaps you can take a look at his source code and use that one as a base instead. :)

[Liisachan]

it looks like it doesn't fully support UTF-8 characters.

Something like this:

FFMpegSource2("abc.mkv", atrack=-1)

works, however something like:


FFMpegSource2("àèéìòù.mkv", atrack=-1)


doesn't.

I know this can be a very rude question, but are you talking about (so-called) Unicode characters, or UTF-8 encoding?

(A file containing the string "àèéìòù.mkv" can be saved as UTF-8, but it can be also saved as so-called ANSI WinLatin, which is not UTF-8. Really confusing and inconvenient anyway…)

When encoding is indeed UTF-8, I believe one can tell the encoding explicitly, at least to some functions:
utf8=true

Sorry for saying something obvious…

[j7n]

You could increase the sevenzip dictionary size to 96 MB to create a significantly smaller package of around 30 MB for the static build. It keeps expanding like the ideal gas. Do you perhaps have a rough estimate which new codecs take up the majority of the huge code size? I remember back in in ffdshow they had one video codec framework with a lot of things shared efficiently. Happy to report this program runs under Win 2008 R2.

[FranceBB]

@Liisachan... After a few tests and wrapping my head around this, it looks like I got it wrong.
Basically you're absolutely right and it's effectively the other way round, namely that the ffms2 C plugin here only supports UTF-8 Script + UTF-8 Avisynth, but it doesn't support ANSI WinLatin.

As per the finding of the post in the AVSPmod mod topic (https://forum.doom9.org/showthread.php?t=175823&page=78), I updated the list with the new proper tests and it's actually more interesting than I initially thought:



Version: AvsPmod 2.7.6.0 x64
OS: Windows 10 Enterprise x64
Avisynth: 3.7.3 r4013 x64

Test file: àèéìòù.mkv

Script Encoding: ANSI
Script Avisynth encoding: System locale mbcs

FFVideoSource() r1387 ok
LWLibavVideoSource() v1156 ok
DirectShowSource() ok

Script Encoding: UTF-8
Script Avisynth encoding: System locale mbcs

FFVideoSource() r1387 ok
LWLibavVideoSource() v1156 ok
DirectShowSource() ok


Script Encoding: UTF-8
Script Avisynth encoding: UTF-8

FFVideoSource() r1387 ok
LWLibavVideoSource() v1156 ok
DirectShowSource() fail




Version: AvsPmod 2.7.6.0 x86
OS: Windows XP Professional x86
Avisynth: 3.7.3 r4013 x86

Test file: àèéìòù.mkv

Script Encoding: ANSI
Script Avisynth encoding: System locale mbcs

FFVideoSource() 2.40 (C Plugin) 2023-09-04 fail
LWLibavVideoSource() 2015-03-16 ok
DirectShowSource() ok


Script Encoding: UTF-8
Script Avisynth encoding: System locale mbcs

FFVideoSource() 2.40 (C Plugin) 2023-09-04 fail
LWLibavVideoSource() 2015-03-16 ok
DirectShowSource() ok


Script Encoding: UTF-8
Script Avisynth encoding: UTF-8


FFVideoSource() 2.40 (C Plugin) 2023-09-04 ok
LWLibavVideoSource() 2015-03-16 ok
DirectShowSource() fail



So, to recap:


ffms2 r1387
- Supports ANSI Script + mbcs Avisynth
- Supports UTF-8 Script + mbcs Avisynth
- Supports UTF-8 Script + UTF-8 Avisynth

ffms2 c plugin 2023-09-04 (the one from this topic)
- Supports UTF-8 Script + UTF-8 Avisynth
(anything else will only work if the file doesn't have accents)

libav v1156
- Supports ANSI Script + mbcs Avisynth
- Supports UTF-8 Script + mbcs Avisynth
- Supports UTF-8 Script + UTF-8 Avisynth

libav 2015-03-16
- Supports ANSI Script + mbcs Avisynth
- Supports UTF-8 Script + mbcs Avisynth
- Supports UTF-8 Script + UTF-8 Avisynth


DirectShowSource
- Supports ANSI Script + mbcs Avisynth
- Supports UTF-8 Script + mbcs Avisynth



So the question for Reino now actually shifted to whether he's willing to support Enhanced ANSI like WinLatin ANSI via system locale (mbcs) for the ffms2 C plugin by doing what StvG is doing in the normal ffms2 r1387 plugin (https://codeberg.org/StvG/ffms2/releases/tag/r1387) or not.


Apologies for the whole mess, but it was actually far more complicated than I originally anticipated.

[Liisachan]

Apologies for the whole mess, but it was actually far more complicated than I originally anticipated. Thanks for a lot of testing! Maybe UTF-8 is the way to go because some file names can’t be encoded in legacy ANSI. For example, if the file name is “Suzumiya Haruhi no Yūutsu.mkv", the letter ū is not supported by ANSI no matter whether your locale is ja-JP or WinLatin.

Another subtlety: e.g. WinLatin has the letter œ as 0x9C while this character is not U+009C but U+0153 in Unicode (incl. UTF-8 encoding). So, to support various encodings, the program basically needs to have a lot of big conversion tables.

Although there are things like `MultiByteToWideChar` & `WideCharToMultiByte` which do conversations for you, they too have a lot of pitfalls: e.g. é can be written as two characters:
U+0065 [ e ] LATIN SMALL LETTER E: U+0301 [ ́ ] COMBINING ACUTE ACCENT
instead of just U+00E9 [ é ] LATIN SMALL LETTER E WITH ACUTE, meaning the conversation is not one-to-one.

On the other hand, even using UTF-8, older versions of Windows may be bad at handling non-BMP code points (U+10000 and above). One way to test this would be including an emoji (a familiar example of non-BMP) in your file name such as: “I LOVE �� French fries.mkv” Though maybe no one would ever use such a weird file name, Unicode can be a huge headache if not fully supported on the OS level… Practically, just supporting UTF-8 (esp. BMP, below U+FFFF) is simple and sufficient?

Happy holidays!

PS: This forum itself doesn’ṭ support non-BMP ^^; The character between “I LOVE” and “French fries” is a single code point U+1F35F, but it seems that they are treated here as 2 “letters” (a surrogate pair).

[Reino]

Another round of binaries. Yes, I've still managed to compile some! :devil:

I'm afraid Gianluigi won't be updating his repo anymore, seeing his latest commit is from a year ago. So unless there's someone who can help me with '0003-load-shared-libfdk-aac-library-dynamically.patch', my builds will be without libfdk-aac, because sadly I still can't code in C/C++.

I've managed to add support for JPEG XL (libjxl). It took me quite some time and a lot of trial and error, but it works.

The cryptography-library MbedTLS can't be updated anymore. I found out the hard way that v3.5.0 (and v2.28.5) now requires Python 3.8 (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.0). Next time I'll have a look at whether LibTLS (part of LibreSSL) might be substitute.

Version ffms2-2.18-756-4d45afc-avs-vsp-win32-shared-xpmod-sse from 2023-05-04 throws a "platform returned code 126: the specified module could not be found" error as if it couldn't really load ffms2.dll.That's because, as I said, 'ffms3.dll' now relies on 'avcodec-60.dll', 'avformat-60.dll', 'avutil-58.dll', 'swresample-4.dll' and 'swscale-7.dll' from the shared build.
about version ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse from 2023-01-08, it looks like it doesn't fully support UTF-8 characters.I've seen the discussion in the other threads, but I just compile the source is all I can say. I really don't an answer to this other than that the source would probably be to blame.
So the question for Reino now actually shifted to whether he's willing to support Enhanced ANSI like WinLatin ANSI via system locale (mbcs) for the ffms2 C plugin by doing what StvG is doing in the normal ffms2 r1387 plugin (https://codeberg.org/StvG/ffms2/releases/tag/r1387) or not.Which is? Correct me if I'm wrong, but shouldn't qyot27 be looking is this then? It's his repo.
You could increase the sevenzip dictionary size to 96 MB to create a significantly smaller package of around 30 MB for the static build.I wasn't aware. It took me quite some time to figure out the correct commandline. First of all the (old) 7zip binary from the Cygwin install doesn't work in this case. I'm getting: ERROR: Can't allocate required memory!. So I had to do this manually with the local 7-Zip 23.01 install (outside of the Cygwin environment). Somehow its GUI won't allow me to select a higher dictionary size than 64MB (for LZMA2). After some reading and searching I came up with a working commandline that works. Thank god my 2GB RAM was enough.
Do you perhaps have a rough estimate which new codecs take up the majority of the huge code size?I haven't added support for any new codec for a long time, so I'd say it's the source (the FFmpeg repo) that's slowly getting larger and larger.

[FranceBB]

my builds will be without libfdk-aac

Well, the only "positive" thing is that FFMpeg's internal AAC encoder got better in the meantime as it went from "it totally sucks" to "somewhat usable" in 6.2. That, together with the restricting licensing conditions of FDK_AAC means that FDK_AAC won't be missed anyway. :)


I've managed to add support for JPEG XL (libjxl).


Amazing. :D



'ffms3.dll' now relies on 'avcodec-60.dll', 'avformat-60.dll', 'avutil-58.dll', 'swresample-4.dll' and 'swscale-7.dll' from the shared build.


Right, right, yeah, I did move them all to plugins+ but I was surprised that it didn't work.
Turns out it was something stupid I did: although I moved FFMS2.avsi to plugins+ along with ffms3.dll, ffmsindex.exe, avcodec-60.dll, avdevice-60.dll, avfilter-9.dll, avformat-60.dll, avutil-58.dll, postproc-57.dll, swresample-4.dll and swscale-7.dll and I did remove ffms2.dll, I forgot to remove FFFMS2Cplugin.avsi xD

Once I got rid of that, it worked like a charm. :)
Version 6.2 is working like a charm too.


I've seen the discussion in the other threads, but I just compile the source is all I can say.
Shouldn't qyot27 be looking is this then? It's his repo.


Yep yep, Stephen (i.e qyot) should be looking at this on his repo, sorry about the mixup, sometimes I forget about this:


sadly I still can't code in C/C++


I'll ask him and perhaps we'll get support in the C plugin too.
For reference, ffms2 C++ version was maintained by Myrsloyk who then left it hanging in 2021, SvtG picked it up and he's the current maintainer of ffms2 C++ version while qyot is the maintainer of ffms2 C version, so yeah, if qyot ports the ANSI WinLatin support from the SvtG C++ version to his C version then we'll also have it in your XP builds. :D


Anyway, thank you for another round of builds to start off this 2024!
Windows XP Forever! :D

[FranceBB]

Actually, although using FFVideoSource() works, whenever I load it in Avisynth an error is thrown.

Import("ffms2.avsi")
LoadCPlugin("ffms3.dll")

throws the following error as a separate window in AVSPmod mod:

Exception WindowsError: 'exception: access violation reading 0x00000020' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x038376D0>> ignored

While AVSMeter returns:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Cannot determine module
Address: 0x00161DCD

however everything seems to be working and the file is indexed nonetheless and I can seek through it etc.
Weird. Pretty weird.

Out of curiosity, would you also be able to provide a static build for ffms2?
I just wanna rule any issue out.

[Reino]

Out of curiosity, would you also be able to provide a static build for ffms2?Well, especially for you then. ;) It's up.

About the error; Same here with both the shared as well as the static build. In AVSMeter 3.0.9.0 I'm getting the same error. In AvsPmod 2.5.1 I'm getting a slightly different message though:Exception WindowsError: 'exception: access violation reading 0xD0029BD8' in <bound method
PIScriptEnvironment.__del__ of <avisynth.PIScriptEnvironment instance at 0x01F65198>> ignoredI'm clueless as to what could be the cause. If there's one person who could possibly answer this, I think it's, again, qyot27.

[FranceBB]

Well, especially for you then. ;) It's up.


Awww. :)



About the error; Same here with both the shared as well as the static build.


Yes I can reproduce.



I'm clueless as to what could be the cause. If there's one person who could possibly answer this, I think it's, again, qyot27.

Perhaps.
What I can add to this, though, is that I made the following tests:

2020-05-03 Ok
ffms2-2.18-736-43dc804-avs-vsp_ffmpeg-4.3-3133-1128aa8-win32-xpmod-sse

2020-09-05 Ok
ffms2-2.18-744-7e1e75d-avs-vsp_ffmpeg-4.4-853-276d86a-win32-xpmod-sse

2021-01-02 Ok
ffms2-2.18-748-c48a6db-avs-vsp_ffmpeg-4.4-2460-2c6f532-win32-xpmod-sse

2021-05-21 Ok
ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-4.5-697-5541cff-win32-xpmod-sse

2023-01-08 Ok
ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse

2023-05-04 Error
ffms2-2.18-756-4d45afc-avs-vsp-win32-shared-xpmod-sse + ffmpeg-6.1-588-4006c71-win32-shared-xpmod-sse

Exception WindowsError: 'exception: access violation reading 0x00000020' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x0381BB50>> ignored

2023-09-04 Error
ffms2-2.18-841-d42a696-avs-vsp-win32-shared-xpmod-sse + ffmpeg-6.2-609-238f9de-win32-shared-xpmod-sse

Exception WindowsError: 'exception: access violation reading 0x00000010' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x0381BAF0>> ignored


2024-01-01 Error
ffms2-2.18-842-f6098b6-avs-vsp-win32-shared-xpmod-sse + ffmpeg-6.2-609-238f9de-win32-shared-xpmod-sse

Exception WindowsError: 'exception: access violation reading 0x00000020' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x038376D0>> ignored


2024-01-02 Error
ffms2-2.18-842-f6098b6-avs-vsp_ffmpeg-6.2-609-238f9de-win32-xpmod-sse

Exception WindowsError: 'exception: access violation reading 0x00000030' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x0381BAF0>> ignored


All these tests were made using AviSynth+ 3.7.3 (r4013, master, i386) on Windows XP Professional x86, however I also tried 2024-01-02 static on Windows 10 Enterprise x86 too and it errored in the exact same way:

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Users\bucciantinif\Desktop\Utility\AVSMeter\AVSMeter.exe
Address: 0x00821F80

Exception WindowsError: 'exception: access violation reading 0xC0DDAFD1' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x04C18CF0>> ignored


I don't know whether Stephen (qyot) has some insights / can shed some light on this...
Right now, however, I'll revert to the last working one, namely the 2023-01-08 build ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse.

[Reino]

2023-01-08 Ok
ffms2-2.18-756-4d45afc-avs-vsp_ffmpeg-5.2-2131-fcd557a-win32-xpmod-sse

2023-05-04 Error
ffms2-2.18-756-4d45afc-avs-vsp-win32-shared-xpmod-sse + ffmpeg-6.1-588-4006c71-win32-shared-xpmod-sse

Exception WindowsError: 'exception: access violation reading 0x00000020' in <bound method AVS_ScriptEnvironment.__del__ of <avisynth.AVS_ScriptEnvironment object at 0x0381BB50>> ignoredAt first I thought some FFmpeg commit would probably be the cause, but after having test-compiled different versions of both FFmpeg and FFMS2, it turns out the culprit really is FFMS2 afterall. To be specific; "Fix memory leak" (https://github.com/qyot27/ffms2_cplugin/commit/34a4379c211b166da50bf3a6bfb249166634547d) is the latest still working revision. I can't say which of the commits (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin/) after that is the real culprit, because 16 of them are all part of a pull-request (https://github.com/qyot27/ffms2_cplugin/pull/5). So yes, Stephen and/or this "Asd-g" person should be able to shed some light on this issue, if you ask me.
About this pull-request; I hardly use AviSynth anymore, so I'm not up to speed with FFMS2 development, but I don't understand why they're removing 'FFMS2-cplugin.avsi'. I remember using the convenient function FFmpegSource2() a lot back then.

Anyway,... new builds uploaded soon.

[qyot27]

At first I thought some FFmpeg commit would probably be the cause, but after having test-compiled different versions of both FFmpeg and FFMS2, it turns out the culprit really is FFMS2 afterall. To be specific; "Fix memory leak" (https://github.com/qyot27/ffms2_cplugin/commit/34a4379c211b166da50bf3a6bfb249166634547d) is the latest still working revision. I can't say which of the commits (https://github.com/qyot27/ffms2_cplugin/commits/c_plugin/) after that is the real culprit, because 16 of them are all part of a pull-request (https://github.com/qyot27/ffms2_cplugin/pull/5).
I can't reproduce it on Win 10, no matter whether I'm using my own build of the C plugin, one of your builds, avsmeter 3.0.0.3 or 3.0.9.0, Avspmod, or AviSynth+ 3.7.3 or the build of r4040 I ran off a couple weeks ago for the static/HEAD versions of ImageSeq and TimeStretch.

It's completely possible to zero in on which commit might have been responsible, I don't do merges unless there's not really any other option (read: the integration commits that occur when pulling in changes from the master branch). Virtually every other time I merge a pull request (on ffms2_cplugin, AviSynth+, etc.) it's as a rebase, so there is no merge commit and the history is still traversible.

About this pull-request; I hardly use AviSynth anymore, so I'm not up to speed with FFMS2 development, but I don't understand why they're removing 'FFMS2-cplugin.avsi'. I remember using the convenient function FFmpegSource2() a lot back then.
Because it was rendered redundant by https://github.com/qyot27/ffms2_cplugin/commit/c391125378cdae04db8bb21432fdc5115eeddab9

Seriously, remove the FFMS2*.avsi file from the autoload folder or the Import line from the script and try to use FFmpegSource2 anyway - it'll still work if you're using the dll with those updates.

The C++ plugin got some refactoring years ago, and one of the things that happened was all those functions were added directly into the plugin, so they were removed from FFMS2.avsi. Since I'd not gotten around to doing the equivalent things in the C plugin, FFMS2-cplugin.avsi was created to preserve those functions specifically so the C plugin could still use them. With the update of the C plugin, that was no longer necessary, so the content of FFMS2.avsi and FFMS2-cplugin.avsi would be exactly the same, making the latter completely unnecessary (and really, if the only thing you ever used the .avsi for was to use the *Source wrapping functions and not any of the other ones¹, you don't even need to keep FFMS2.avsi around, either).

¹ FFFormatTime, FFColorSpace, FFColorRange, FFCropping, FFSampAR, FFPictType, and FFInfo

[Reino]

Stephen, for what it's worth:

b3a4a0d33849df3d6e864c79aa8fb600dd41f99b (https://github.com/qyot27/ffms2_cplugin/commit/b3a4a0d33849df3d6e864c79aa8fb600dd41f99b) No compilation errors, works correctly
8bc3bb3955f8c27c344ccbc29602680f59925128 (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128) Compilation error: "undefined reference to `muldivRational'"
b593c8e65df63917c7b3e0464fc382d52d40359d (https://github.com/qyot27/ffms2_cplugin/commit/b593c8e65df63917c7b3e0464fc382d52d40359d) No compilation errors, but AVSMeter reports: "Script error: there is no function named "FFVideoSource""
[...]
d4680ec8f72cabd9248d179a9a30aa5fd5badc00 (https://github.com/qyot27/ffms2_cplugin/commit/d4680ec8f72cabd9248d179a9a30aa5fd5badc00) No compilation errors, but AVSMeter reports: "Script error: there is no function named "FFVideoSource""
d42a696e24a079cc9eba9bdf084669bb30db4828 (https://github.com/qyot27/ffms2_cplugin/commit/d42a696e24a079cc9eba9bdf084669bb30db4828) No compilation errors, but AVSMeter reports: "Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Cannot determine module
Address: 0x00332758"
So strictly speaking, it all starts with "Port frame properties" (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128).

I can't reproduce it on Win 10You don't have WinXP still laying around? It could very well be an issue that only occurs on WinXP.

[qyot27]

With a couple of the frame properties, it mirrors essentially what the C++ plugin does, which includes a usage of muldivRational in order to reduce the result of the DurNum and DurDen pointers used to calculate the _DurationNum/Den properties.

muldivRational is getting re-used from the VapourSynth headers (VSHelper4.h, specifically). So even if the function itself is self-contained (which it appears to be), the headers being there are making it try to look for an install of VapourSynth. My guess is that - because VS dropped XP support long ago - it isn't installed, or if it is, it may even be checking for an API4 version, which is way too recent for XP and wouldn't be installed for that reason.

Try with the patch I just pushed up to the 'cplugin_muldivtest' branch:
https://github.com/qyot27/ffms2_cplugin/commits/cplugin_muldivtest/

You don't have WinXP still laying around? It could very well be an issue that only occurs on WinXP.
The only two machines that still have XP on them are effectively in storage. The closest I could come to it would be spinning up a ReactOS VM, but that's a completely different set of issues to navigate.

[Reino]

Thank you. Though it didn't help, because I'm still getting the same "Cannot determine module" error.

[qyot27]

Okay, so it moves from a straightforward failure to load the plugin (and hence the functions provided by it), to the access violation issue when the Plus-specific API calls are made optional at load.

Does it happen with a debug build of FFMS2?

[Reino]

If you mean compiling with ./configure --enable-debug, then yes, same "Cannot determine module" error at load.
Because it's a debug-build I was expecting a more verbose message.

As a side note, which FranceBB also already mentioned; This is what AVSMeter is spitting out. With AvsPmod, despite the "Exception WindowsError" error message in a separate window, 'ffms3.dll' appears to work just fine. Which is... weird.

[manolito]

Hi Reino,

Just discovered the latest update, tested it, and it really does work again together with lidfdk-aas. What a welcome surprise... :D

I noticed that there is also a newer version of the libfdk-aac plugin available, but it is not required to use it for the new version. So all the changes to make the current ffmpeg version compatible with libfdk-aac must be inside the ffmpeg code. Very impressed... :cool:

Would you mind to chare a few details how you achieved this? I am not aware of any updates by Sherpya, so you must have done everything by yourself...


Thanks very much,

cheers
manolito

[Reino]

Another 4 months have gone by, so it's time for another round of binaries.
I'm afraid Gianluigi won't be updating his repo anymoreIt appears Gianluigi hasn't quit yet, because 5 weeks ago his repo suddenly showed some activity (https://github.com/sherpya/mplayer-be/commits/master/) again. So, good news. Thanks to his patches I've successfully added support for libfdk-aac again.
The cryptography-library MbedTLS can't be updated anymore. I found out the hard way that v3.5.0 (and v2.28.5) now requires Python 3.8 (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.0).I guess I was wrong. I don't know why and how, but Mbed-TLS 2.28.8 - which I now compiled FFmpeg with - compiled without issues without the need for Python 3.8.

As usual, see post #1 for details.

@FranceBB and @qyot27, I've also had a look at ffms2, but I'm getting the following error with make:
CXX src/core/audiosource.o
In file included from src/core/audiosource.h:24,
from src/core/audiosource.cpp:21:
src/core/utils.h:102:10: warning: unnecessary parentheses in declaration of 'ptr' [-Wparentheses]
102 | T(FFMS_Struct::*ptr);
| ^
In file included from src/core/audiosource.cpp:21:
src/core/audiosource.h: In constructor 'FFMS_AudioSource::FFMS_AudioSource(const char*, FFMS_Index&, int, int, int, double)':
src/core/audiosource.h:119:9: warning: 'FFMS_AudioSource::TrackNumber' will be initialized after [-Wreorder]
119 | int TrackNumber;
| ^~~~~~~~~~~
src/core/audiosource.h:66:12: warning: 'double FFMS_AudioSource::DrcScale' [-Wreorder]
66 | double DrcScale;
| ^~~~~~~~
src/core/audiosource.cpp:56:1: warning: when initialized here [-Wreorder]
56 | FFMS_AudioSource::FFMS_AudioSource(const char *SourceFile, FFMS_Index &Index, int Track, int DelayMode, int FillGaps, double DrcScale)
| ^~~~~~~~~~~~~~~~
src/core/audiosource.cpp: In member function 'void FFMS_AudioSource::SetOutputFormat(const FFMS_ResampleOptions&)':
src/core/audiosource.cpp:217:95: error: 'av_get_channel_layout_nb_channels' was not declared in this scope
217 | BytesPerSample = av_get_bytes_per_sample(static_cast<AVSampleFormat>(opt.SampleFormat))
* av_get_channel_layout_nb_channels(opt.ChannelLayout);
|
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/core/audiosource.cpp:233:5: error: 'av_opt_set_channel_layout' was not declared in this scope; did you mean 'av_opt_set_chlayout'?
233 | av_opt_set_channel_layout(newContext.get(), "out_channel_layout", opt.ChannelLayout, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| av_opt_set_chlayout
make: *** [<builtin>: src/core/audiosource.o] Error 1
I'm afraid this is due to changes upstream (the FFmpeg repo). At least, I think that's highly likely the case here. So ffms2 needs an update. However, with the issue (starting with "Port frame properties" (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128) and discussed above) still unresolved, it doesn't look too good.

[Reino]

You're welcome, Manolito. I've uploaded all the stuff earlier today, but only now I had the time to add another post. So, you were too fast! ;)
Though libfdk-aac is all thanks to Gianluigi again, there were plenty other headaches I've managed to solve on my own to make it all compatible again.
I'll try to update my repo (https://github.com/Reino17/ffmpeg-windows-build-helpers) again soon, when I have the time. Hopefully a lot sooner than last time! :o Then you can see all the details.

[FranceBB]

Thank you Reino, as always. The static build works like a charm.
About ffms2 and the changes in FFMpeg, I can see that Myrsloyk updated the API for 5.1 first and 6.1.1 then.
I know that you're trying to link against FFMpeg 7.x so I don't think it's gonna work anyway but it might be worth trying pulling the changes. (https://github.com/qyot27/ffms2_cplugin/compare/c_plugin...FFMS%3Affms2%3Amaster)
I'll ask Myrsloyk anyway. (https://forum.doom9.org/showthread.php?p=2001715#post2001715)

[GMJCZP]

Thank you Reino for your contributions. Excuse my ignorance but how, with an example, can I use Ffmpeg with libfdkaac to convert an audio file? Since both are separated.

[StvG]

Stephen, for what it's worth:

b3a4a0d33849df3d6e864c79aa8fb600dd41f99b (https://github.com/qyot27/ffms2_cplugin/commit/b3a4a0d33849df3d6e864c79aa8fb600dd41f99b) No compilation errors, works correctly
8bc3bb3955f8c27c344ccbc29602680f59925128 (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128) Compilation error: "undefined reference to `muldivRational'"
b593c8e65df63917c7b3e0464fc382d52d40359d (https://github.com/qyot27/ffms2_cplugin/commit/b593c8e65df63917c7b3e0464fc382d52d40359d) No compilation errors, but AVSMeter reports: "Script error: there is no function named "FFVideoSource""
[...]
d4680ec8f72cabd9248d179a9a30aa5fd5badc00 (https://github.com/qyot27/ffms2_cplugin/commit/d4680ec8f72cabd9248d179a9a30aa5fd5badc00) No compilation errors, but AVSMeter reports: "Script error: there is no function named "FFVideoSource""
d42a696e24a079cc9eba9bdf084669bb30db4828 (https://github.com/qyot27/ffms2_cplugin/commit/d42a696e24a079cc9eba9bdf084669bb30db4828) No compilation errors, but AVSMeter reports: "Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Cannot determine module
Address: 0x00332758"
So strictly speaking, it all starts with "Port frame properties" (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128).

You don't have WinXP still laying around? It could very well be an issue that only occurs on WinXP.

... However, with the issue (starting with "Port frame properties" (https://github.com/qyot27/ffms2_cplugin/commit/8bc3bb3955f8c27c344ccbc29602680f59925128) and discussed above) still unresolved, it doesn't look too good.

1. Against what AviSynth+ version you build ffms2?
2. What's the used AviSynth+ version when you try to run the script?

[manolito]

Thank you Reino for your contributions. Excuse my ignorance but how, with an example, can I use Ffmpeg with libfdkaac to convert an audio file? Since both are separated.

Hi GMJCZP,

there are several ways to use libfdk_aac. First of all I suggest to have a look at the documentation here:
https://trac.ffmpeg.org/wiki/Encode/AAC

The commandline parameters are a little different than for the built-in AAC encoder, so you might want to have a look.


Your next decision will be if you want to use the software using the command line interface, or if you prefer a GUI.

For a CLI I made a simple template you can alter depending on your needs:

"Full Path\ffmpeg.exe" -y -i "Source file name with full path" -crf 19.0 -preset medium -tune film -vcodec libx264 -acodec libfdk_aac -ac 2 -ar 48000 -b:a 160k "Output file name with full path"

Just edit the script according to your needs and run it.


As an alternative you can use an ffmpeg GUI which may be easier and also more powerful. My favorite is dmMediaConverter by Marius Dalacu. Marius was nice enough to integrate libfdk seamlessly into his software, so it is easy to use and still very powerful.

You can find all the necessary info and download links here:
https://forum.doom9.org/showthread.php?p=1979037#post1979037

You should also read the following posts for some additional info and recommendations...

If you got questions, please don't hesitate to ask.


Cheers
manolito

[GMJCZP]

Thank you Manolito for your response. I have used libfdkaac but I have never used it with ffmpeg outside of their compilation. In the first post Reino explains how to do it (map?) but I would like an example to understand what it is like to use both separately. Anyway, I'll check your information.

[manolito]

Looks like I do not really understand what you mean... :(
I have used libfdkaac but I have never used it with ffmpeg outside of their compilation

The libfdk file which can be downloaded from Reino's link does not do anything by itself, it depends on a compatible FFmpeg version which can use it just like it was incorporated in the FFmpeg binary itself. So it makes no sense to me when you say that you have used libfdk-aac-2.dll before, but never used it with FFmpeg.


Are you talking about some very different libfdkaac file? Please clarify...


Cheers
manolito

[Reino]

Excuse my ignorance but how, with an example, can I use Ffmpeg with libfdkaac to convert an audio file? Since both are separated.As I explained in post #1, put the dll-file in the same map as 'ffmpeg.exe', or in any map listed in the %PATH%-variable. Next, please consult https://trac.ffmpeg.org/wiki/Encode/AAC (https://trac.ffmpeg.org/wiki/Encode/AAC).

1. Against what AviSynth+ version you build ffms2?The latest (headers only (https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L792-L799)).
2. What's the used AviSynth+ version when you try to run the script?Uh... v2.6.0. :o
While reading your question, immediately my gut feeling was, this could be the root cause. Somehow it never crossed my mind to try to use a more up-to-date Avisynth install. I feel so dumb! :rolleyes:
I've uploaded a new ffms2_cplugin build, which uses the latest revision (from https://github.com/qyot27/ffms2_cplugin.git (https://github.com/qyot27/ffms2_cplugin.git)) and is linked against ffmpeg-6.2-609-238f9de (my previous FFmpeg build from begin this year).
I've installed AviSynthPlus_3.7.3_20230715_xp.exe (https://github.com/AviSynth/AviSynthPlus/releases/download/v3.7.3/AviSynthPlus_3.7.3_20230715_xp.exe) and did some tests. This new ffms2_cplugin build works perfectly now. No more errors. So it was my mistake afterall, not using an up-to-date Avisynth install.

[FranceBB]

Oh, that's very good to know!
But... to avoid having a blob in the plugins+ folder, would you mind uploading ffms2 as static rather than shared? Pretty pretty please?

[Reino]

I think you misunderstand. You always have to compile ffms2 with --enable-shared (https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L1120), in order to get 'ffms3.dll'. Hence "shared" in the archive name.
But I can see where the confusion is coming from. Especially because I don't put "shared" in the archive name of libfdk-aac, frei0r, or openssl either. So I've renamed the content or the entire ffms2 dir (https://rwijnsma.home.xs4all.nl/files/ffms2/). I think it's more clear now. Also the filesize would be an indication whether FFmpeg was linked statically, or not.

[FranceBB]

Ahhhhh it was just the name hahahahahahaha gotcha.
Yep, it's indeed static and it works like a charm, I've just put it in my plugins+ folder and I used FFMpegSource2("test.mp4", atrack=-1). Nice! :D

[manolito]

After reading some FFmpeg docs I am a bit scared about version 7.1 backward compatibility. Here is the important part from the 7.0 documentation:

This release is not backwards compatible, removing APIs deprecated before 6.0. The biggest change for most
library callers will be the removal of the old bitmask-based channel layout API, replaced by the AVChannelLayout API
allowing such features as custom channel ordering, or Ambisonics. Certain deprecated ffmpeg CLI options were also
removed, and a C11-compliant compiler is now required to build the code.

I wonder if this is relevant for me, since I do use some fairly old software under FFmpeg. So far I did not encounter any crashes or even warnings, so Reino may well have taken care of possible incompatibilities. Can I lean back, or would it be safer to revert back to the older version 5.2 ?


Cheers
manolito

[FranceBB]

Good point, manolito.
For me the big blow was around -map_channels.
I use it all the time and it no longer works now.
In FFMpeg 7.x this code fails:


#Extract DolbyE track 1
ffmpeg -i "DolbyE.mov" -map 0:1 -acodec copy -f u8 -y "stream1.u8"
#Extract each channel of DolbyE 5.1
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.0:0.0.0 -y "FL.wav"
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.1:0.0.0 -y "FR.wav"
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.2:0.0.0 -y "CC.wav"
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.3:0.0.0 -y "LFE.wav"
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.4:0.0.0 -y "SL.wav"
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.5:0.0.0 -y "SR.wav"
#Extract each channel of DolbyE 2.0
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.6:0.0.0 -y $jobOutputFolder:Left.wav
ffmpeg -i "stream1.u8" -acodec pcm_s24le -ar 48000 -ac 1 -map_channel 0.0.7:0.0.0 -y $jobOutputFolder:Right.wav
#Audio 5.1
ffmpeg -i "FL.wav" -i "FR.wav" -i "CC.wav" -i "LFE.wav" -i "SL.wav" -i "SR.wav" -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a]join=inputs=6:channel_layout=5.1:map=0.0-FL|1.0-FR|2.0-FC|3.0-LFE|4.0-BL|5.0-BR[a]" -map "[a]" -c:a pcm_s24le -ar 48000 -f wav -y "Track1_51.wav"
#Audio 2.0
ffmpeg -i "Left.wav" -i "Right.wav" -filter_complex "[0:a][1:a]join=inputs=2:channel_layout=stereo[a]" -map "[a]" -c:a pcm_s24le -ar 48000 -f wav -y "Track2_20.wav"



I still have to see how to change it...
I guess I'm gonna stick to 6.1.1 for a little bit longer...

[GMJCZP]

Sorry for the delay in the response.

Are you talking about some very different libfdkaac file? Please clarify...
Manolito: Reino in post #104 has explained it for me. The idea of using both files as Reino suggests

As I explained in post #1, put the dll-file in the same map as 'ffmpeg.exe', or in any map listed in the %PATH%-variable. Next, please consult https://trac.ffmpeg.org/wiki/Encode/AAC.
Reino: I don't know how to place libfdkaac in the same ffmpeg map, if someone can explain it to me with an example I would greatly appreciate it, like in the link above.

Edit: Manolito, with dmMediaconverter you can use libfdkaac with ffmpeg but I don't know how to integrate them...

[Reino]

Have you actually downloaded the latest archive, 'libfdk-aac-2.0.3-win32-xpmod-sse.7z' (https://rwijnsma.home.xs4all.nl/files/ffmpeg/libfdk-aac/libfdk-aac-2.0.3-win32-xpmod-sse.7z)? That's where you'll find 'libfdk-aac-2.dll'.

[manolito]

Looks like GMJCZP is mixing up fdkaac.exe which is a standalone audio encoder with lidfdk-aac-xxx.dll which is an FFmpeg plugin. Those two programs serve a completely different purpose and must not be mixed up.


Cheers
manolito

[GMJCZP]

I explain: I have the two files that Reino has uploaded, but I don't know how to use them as he says in his first post. I use fdkaac.exe in BeHappy but I want to learn how to use libfdkaac with ffmpeg like Reino says but I don't know about mapping

[lvqcl]

but I want to learn how to use libfdkaac with ffmpeg like Reino says but I don't know about mapping

As I explained in post #1, put the dll-file in the same map as 'ffmpeg.exe', or in any map listed in the %PATH%-variable.

I suppose that in this quote the word 'map' means folder (directory):

put the dll-file in the same folder as 'ffmpeg.exe', or in any folder listed in the %PATH%-variable

[manolito]

Yes, that's exactly it. In this context the word "Folder" should be used. Nothing gets "mapped" in this context.

[manolito]

@ GMJCZP

Edit: Manolito, with dmMediaconverter you can use libfdkaac with ffmpeg but I don't know how to integrate them...


You can find all the relevant information starting at this post. Make sure to also read the following couple of posts up to #195 :

https://forum.doom9.org/showthread.php?p=1979037#post1979037


Good luck...
manolito

[GMJCZP]

Thank you all, I will read all the information. So if I put libfdkaac in the same folder as ffmpeg it would be the same as if the library had been compiled inside ffmpeg, right?

Edit: About dmMediaConverter here (https://forum.doom9.org/showthread.php?p=1979042#post1979042) Can I with that activate libfdkaac?

[manolito]

Thank you all, I will read all the information. So if I put libfdkaac in the same folder as ffmpeg it would be the same as if the library had been compiled inside ffmpeg, right?

Yes, but only if your FFmpeg version supports it. At the moment there are only the versions by Reino and by Sherpya which can do that. Sherpya's version can be found here:
https://oss.netfarm.it/mplayer/

Edit: About dmMediaConverter here (https://forum.doom9.org/showthread.php?p=1979042#post1979042) Can I with that activate libfdkaac?

Yes, if you follow the procedure outlined in this post then libfdkaac will appear in the audio configuration tab and can be configured from there.


Cheers
manolito

[richardpl]

This thread is for research for museums.

[manolito]

We love museums... :p

[GMJCZP]

Thank you Manolito! I'll try all the information that you has written.

[Reino]

A user of my FFmpeg binaries (but not a Doom9 member, I think) notified me of a small regression; the absence of the drawtext filter, where ffmpeg-6.1-588-4006c71 (12 months ago) was the latest still working release.
I've done some searching and found that it all comes down to "avfilter/vf_drawtext: improve glyph shaping and positioning" (https://github.com/FFmpeg/FFmpeg/commit/1eeb59a2099479eeead8cdc0d4586443fb301a8a). Starting with this commit libharfbuzz is added as a dependency for the drawtext filter, which means that to enable the drawtext filter you have to configure and compile FFmpeg with --enable-libharfbuzz. I've done just that a moment ago. I've uploaded and replaced the latest release with it! So, same filename.

[FranceBB]

Thanks for that, Reino.
I don't generally use drawtext, but a friend of mine does to display the timecode. Hopefully it will make him happy. :)

[danbow]

Reino Hi. Can You help me. In latest versions ffmpeg-7.1 (2024-05-05), (2024-05-26), i use this:
ffmpeg -ss 5:33.667 -to 7:49.219 -i "360p.mp4" -cpucount 1 -f avi -c:v huffyuv -vf "mpdecimate,setpts=N/FRAME_RATE/TB" -an -sn "360p.avi"
and video output with 600 fps. In previous ffmpeg-6.2-609-238f9de-win32 (2024-01-01) same command out 23.976.
This video Initially 23.976fps, but with duplicate frames. Sorry. Thank You! Very much. :)

[Emulgator]

ffmpeg 7.0 (and 7.1) has removed some in 6.x depreciated, nonetheless there still valid and used command syntax.
Their logic seems to be : What we consider depreciated from one big version step (+1) on, may still be used within this new version (+1),
but will be removed in the following version (+2).
You may want to read that up in ffmpeg docs:
This release is not backwards compatible, removing APIs deprecated before 6.0. The biggest change for most library callers will be the removal of the old bitmask-based channel layout API, replaced by the AVChannelLayout API allowing such features as custom channel ordering, or Ambisonics. Certain deprecated ffmpeg CLI options were also removed...

[Reino]

Hello danbow.
I don't see a question in your post. But anyway, as I'm not an FFmpeg expert, I can't help you with usage questions like these. Though I can say that -to should always come after -i. See https://trac.ffmpeg.org/wiki/Seeking (https://trac.ffmpeg.org/wiki/Seeking).
You're better off asking on the FFmpeg user mailinglist, or on StackOverflow.

[danbow]

My question: it not mistake ffmpeg? so and it is necessary in new version?

[GMJCZP]

I did all the tests and everything turned out perfect, both with libfdk-aac-2 and dmMediaConverter, many thanks to Reino and manolito!

[danbow]

And, i try run official ffmpeg-7.0.1-full_build 2024-05-26 on Windows 7 x64 - not starting. Stop supported?

[FranceBB]

And, i try run official ffmpeg-7.0.1-full_build 2024-05-26 on Windows 7 x64 - not starting. Stop supported?

Welcome to the club, Win7 buddy.
The Windows Vista folks were waiting for you along with us, XP users. ;)

[lvqcl]

And, i try run official ffmpeg-7.0.1-full_build 2024-05-26 on Windows 7 x64 - not starting. Stop supported?

Probably https://github.com/GyanD/codexffmpeg/issues/136#issuecomment-2147215357

[Emulgator]

Respect for finding those needles in the haystack.

[manolito]

Please, respect the topic for this thread:
Windows XP compatible non-SSE2 FFmpeg binaries

Questions like there:
i try run official ffmpeg-7.0.1-full_build 2024-05-26 on Windows 7 x64

should be posted in a separate new thread... :(


Such a new thread would also be the place where I'd like to discuss other non-official FFmpeg versions like this one:
https://www.reddit.com/user/VeritablePornocopium/comments/okw130/ffmpeg_with_libfdk_aac_for_windows_x64/

Post was deleted
Also it could be a good place to discuss more generic tools to make "modern" applications compatible with Win7. Like this one:
https://github.com/vxiiduu/VxKex


Cheers
manolito

[danbow]

manolito forgive me please. Reino, manolito thank You very very much for this tool for xp users :)

[manolito]

Not sure if this is the appropriate thread, but since there is no separate FFmpeg forum in Doom9 I figured that I might just as well post it here... :D

It is about HDR to SDR conversions which uses the z.lib library. Up to version 6.xx this library had a bug which made sources with these properties fail:
If MediaInfo reports that the chroma subsampling of the source is 4:2:0 (Type2) then this FFmpeg command line will fail

This has been fixed by the z.lib devs for the current FFmpeg versions 7.xx. Here is my Readme for dmMediaConcerter (of cource also applies if FFmpeg is used via command line)


Using FFmpeg to convert HDR sources to SDR:
======================================================================

This video filter call will do it (thanks to GeoffreyA for his contribution):


SD target (704x516) or (720x528):
---------------------------------
PQ:
===
zscale=704:-2,zscale=m=gbr:t=linear:dither=none:npl=225,format=gbrpf32le,tonemap=mobius:desat=3.0,zscale=m=bt470bg:t=bt470bg:p=bt470bg:r=limited:c=left:dither=error_diffusion,format=yuv420p,sidedata=delete

HLG:
====
zscale=704:-2,zscale=m=gbr:t=linear:dither=none:npl=203,format=gbrpf32le,tonemap=mobius:desat=0,zscale=m=bt470bg:t=bt470bg:p=bt470bg:r=limited:c=left:dither=error_diffusion,format=yuv420p,sidedata=delete



Half HD target (1280x720):
--------------------------
PQ:
===
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

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



Full HD target (1920x1080):
---------------------------
PQ:
===
zscale=1920:-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

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



________________________________________________________________________________


These FFmpeg parameter lines are meant to be inserted in the "Picture
Settings -> More" field of dmMediaConverter. If you want to use them
in an existing FFmpeg commandline you need to add them as a video
filter and enclose the parameters in double quotes.
Like:
-vf "parameter list"

________________________________________________________________________________



For considerably higher quality conversions (which are also much more tweakable
and also much slower) there is another script by Gyan I found at the Reddit
website. I had to tweak some parameters to get the results I wanted, but it
was worth the effort...

----------------------------------------------------------------------------------

Half HD target (1280x720):
--------------------------
zscale=1280:-2,zscale=t=linear:npl=100,format=gbrpf32le,tonemap=tonemap=gamma:param=1.2:desat=0:peak=15,zscale=p=709:t=709:m=709:r=full:d=error_diffusion,noise=alls=3:allf=t+u,eq=saturation=1.2:brightness=0.155:contrast=1.15:gamma=0.85,huesaturation=colors=y:saturation=-0.5:intensity=0.40,curves=all=0.05/0 0.35/0.5 1/1,curves=all=0/0 0.75/0.76 0.9/0.94 1/1,deband=1thr=0.015:2thr=0.015:3thr=0.015:4thr=0.015:range=16:blur=true:coupling=true,noise=alls=2:allf=p+t,colorspace=iall=bt709:all=bt709:range=tv:format=yuv420p:dither=fsb


Full HD target (1920x1080):
---------------------------
zscale=1920:-2,zscale=t=linear:npl=100,format=gbrpf32le,tonemap=tonemap=gamma:param=1.2:desat=0:peak=15,zscale=p=709:t=709:m=709:r=full:d=error_diffusion,noise=alls=3:allf=t+u,eq=saturation=1.2:brightness=0.155:contrast=1.15:gamma=0.85,huesaturation=colors=y:saturation=-0.5:intensity=0.40,curves=all=0.05/0 0.35/0.5 1/1,curves=all=0/0 0.75/0.76 0.9/0.94 1/1,deband=1thr=0.015:2thr=0.015:3thr=0.015:4thr=0.015:range=16:blur=true:coupling=true,noise=alls=2:allf=p+t,colorspace=iall=bt709:all=bt709:range=tv:format=yuv420p:dither=fsb




Cheers
manolito

[Reino]

Another round of FFmpeg binaries. See post #1 for details.

[FranceBB]

Thank you for keeping XP alive! :D

[Scruff]

A user of my FFmpeg binaries (but not a Doom9 member, I think) notified me of a small regression; the absence of the drawtext filter, where ffmpeg-6.1-588-4006c71 (12 months ago) was the latest still working release.
I've done some searching and found that it all comes down to "avfilter/vf_drawtext: improve glyph shaping and positioning" (https://github.com/FFmpeg/FFmpeg/commit/1eeb59a2099479eeead8cdc0d4586443fb301a8a). Starting with this commit libharfbuzz is added as a dependency for the drawtext filter, which means that to enable the drawtext filter you have to configure and compile FFmpeg with --enable-libharfbuzz. I've done just that a moment ago. I've uploaded and replaced the latest release with it! So, same filename.

Hi all. @Reino, would you be able to rebuild 6.1.2009 please? It also has DrawText disabled but is the last build with XFade working properly. The v7 builds use double the memory and fail with "cannot allocate memory" errors if you have a long filter chain. Build 6.1.2009 seems to work properly but DrawText is missing.

Also, is there an updated helper script? The one at github is not working because some of the dependencies are no longer available. I managed to fix the first two errors I came across, but I am now stuck with "rubberband" failing with error "sndfile not found" - I can't seem to find the right package to fix the problem.

These are the fixes I've found so far for cross_compile_ffmpeg.sh:

426 -download_and_unpack_file http://zlib.net/zlib-1.3.tar.xz
+download_and_unpack_file http://zlib.net/zlib-1.3.1.tar.gz

427 -cd zlib-1.3
+cd zlib-1.3.1

552 -do_git_checkout https://github.com/xiph/opus.git
+download_and_unpack_file http://ftp.osuosl.org/pub/xiph/releases/opus/opus-1.2.1.tar.gz

553 -cd opus_git
+cd opus-1.2.1

686 -do_git_checkout https://github.com/breakfastquay/rubberband.git "" "" 18c06ab8c431854056407c467f4755f761e36a8e
+download_and_unpack_file http://breakfastquay.com/files/releases/rubberband-3.3.0.tar.bz2

687 -cd rubberband_git
+cd rubberband-3.3.0

[Reino]

would you be able to rebuild 6.1.2009 please? It also has DrawText disabled but is the last build with XFade working properly.I can try.

Also, is there an updated helper script? The one at github is not working because [...]Which one at Github? That doesn't look like mine, or at least not the latest one.

[Scruff]

Thanks mate.

The script I'm using is the one linked in Post#1 (https://github.com/Reino17/ffmpeg-windows-build-helpers). The changes I posted are changes I had to make myself. The first 2 (zlib-1.3.1 and opus-1.2.1) seem to have worked but I'm stuck at rubberband - that one requires sndfile and I don't know how to add that to the script properly.

[Reino]

The script I'm using is the one linked in Post#1I understand, but I think you're using an old revision of 'cross_compile_ffmpeg.sh', because all the things you say don't work I have fixed long ago. Two days ago I've pushed a couple of changes for the latest round of binaries.

[Scruff]

You wouldn't read about it - I just downloaded the master.zip again and the last modified date for cross_compile_ffmpeg.sh is 7 Sep 2024.

The master I've been using I downloaded 5 days earlier on 2 Sep and the last modified date on cross_compile_ffmpeg.sh is 5 Sep 2023.

So you are right - the script I've been using is almost a year out of date! What a difference 5 days makes!

I'll have to start from scratch again. :(

Do you still have the master scripts for older versions? I assume all the dependencies and patches are specific to each version. Is that correct?

I'd like to be able to go back as far as 5.2 to experiment with some mods. Getting the source for old ffmpeg versions is easy, but not so much for all the correct dependencies.

[Reino]

The master I've been using I downloaded 5 days earlier on 2 Sep and the last modified date on cross_compile_ffmpeg.sh is 5 Sep 2023.That's weird. That should've been 8 Jun 2024, my previous last commit (https://github.com/Reino17/ffmpeg-windows-build-helpers/commits/master). On the other hand, I use Git, so I don't know if such a tarball is updated after each and every commit I push.
Do you still have the master scripts for older versions?This (https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/master/ffmpeg_local_builds/cross_compile_ffmpeg.sh) is the "master script".
I assume all the dependencies and patches are specific to each version. Is that correct?No. With each new round (every 4 months) I do update my local FFmpeg repo to a specific commit (the latest at that moment though), and its patches are tailored to that revision, but all the dependencies (the git-repos at least) are always the latest revision at that moment. Unless specified (https://github.com/Reino17/ffmpeg-windows-build-helpers/blob/64051110d569c179cbde793d7a211d9bf81c7f4d/ffmpeg_local_builds/cross_compile_ffmpeg.sh#L690) otherwise (https://github.com/Reino17/ffmpeg-windows-build-helpers/commit/3e489fd2bf32bb3b721f4493f61171dd2e7e3cb3).

In fact, I've used the same revisions of all the dependencies for the binaries I've uploaded for you ('ffmpeg-6.2-609-238f9de-[...]_Scruff.7z' (https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D)) as I did for ffmpeg-7.1-2362-6aafe61. I haven't encountered any problems.
The other differences between the ffmpeg-6.2-609-238f9de binaries begin this year and this one are that this one has the drawtext filter (obviously) and libfdk-aac enabled.
I'd like to be able to go back as far as 5.2 to experiment with some mods. Getting the source for old ffmpeg versions is easy, but not so much for all the correct dependencies.Good luck with that! :rolleyes:
What are you trying to achieve?

[Scruff]

Now that I know how long it takes to make one of these builds, I'm really sorry to tell you that 6.2 is the wrong build. But never mind - it might be perfectly suitable for someone else.

I downloaded the latest script and after a couple of days of tweaking and testing, I've successfully made a build from the 6.1.2 source code (https://github.com/FFmpeg/FFmpeg/tree/release/6.1). As far as I can tell so far, this seems to be the last branch that doesn't have memory issues.

If anyone wants to see what I mean by "memory issues", I've generated some batch files to test all the builds that Reino is currently hosting. All you need to do is set the FFMPEG variable in each file to point to the correct ffmpeg.exe version (the batch files check the version string from ffmpeg and will only run with the correct build).

Each test alternates between two PNG images (1280x720px = 720p) as input to produce an MP4 video that shows all the XFade transitions for that build. For builds with DrawText enabled, the video shows the name of each transition as well.

The results I get are as follows:
All static builds (I haven't tested the shared builds because I don't use them).
System: XP Pro Corporate SP3; Intel E6600; 4GB RAM (3.5GB Available); NO OneCoreAPI

5.2-2131 success peak memory used 697 MB
6.1-588 success peak memory used 698 MB
6.1-2009 success peak memory used 697 MB
6.2-609 fail peak memory used 676 MB but hardly ever gets past the first transition - doesn't show any errors or set error code
6.2-609-Scruff fail (same as above)
7.1-596 fail peak memory used 1431 MB - sometimes fails on first error, sometimes shows heaps of errors and continues
7.1-2362 fail peak memory used 1415 MB - sometimes fails on first error, sometimes shows heaps of errors and continues

I've run all the tests without using DrawText and the results are the same.

I couldn't include the two images in the zip because of the file size restriction, so grab them from the following URL's and save them to the "XFade Tests/720p" folder:
https://bdth.org/01.png
https://bdth.org/02.png

I'm interested to know if the results are the same with the OneCoreAPI installed and on XP x64 which can access more memory natively.

I recommend that you reboot after any test that fails. I have a game that I wrote years ago in VB6 where some of the levels are pretty memory intensive. After running these tests, the game fails to create the memory DC's for those larger levels until I reboot. I don't know for sure, but it's possible that the later builds of ffmpeg are corrupting the RAM, so reboot to be safe.

[Scruff]

Anyone know how to include fdk-aac in the ffmpeg build instead of having an external dll?

Apparently it can be done (as long as you don't redistibute the exe), but I can't figure out how.

[manolito]

Use this one:

https://www.reddit.com/user/VeritablePornocopium/comments/okw130/ffmpeg_with_libfdk_aac_for_windows_x64/

It is 64bit only, but it does also work when called from a 32bit host software.


Cheers
manolito

[Scruff]

That requires linux with docker installed to build. I'm looking for a way to do it with cygwin on XP using Reino's script.

[manolito]

that requires linux with docker installed to build. I'm looking for a way to do it with cygwin on xp using reino's script.


what???

ffmpeg with libfdk_aac for windows x64
ffmpeg 7.0 "dijkstra" (master-a7e506fcd8 [2024-05-19])

official ffmpeg build download link

this version does not have any of the experimental h.266 codecs. Download ffmpeg 6.0 for those.

Custom builds with libfdk_aac and other "non-free" encoders:

Static builds:

Ffmpeg.exe github

ffplay.exe github

ffprobe.exe github

shared build:

Ffmpeg.exe, ffplay.exe, ffprobe.exe, avcodec-61.dll, avformat-61.dll, etc. Github


This is the standard Win64 build, no Linux or Docker whatsoever. :confused:
I suggest you get your act together before posting such nonsense.


Cheers
manolito

[Scruff]

what???
This is the standard Win64 build, no Linux or Docker whatsoever. :confused:
I suggest you get your act together before posting such nonsense.


1. The compiled binary on that page does NOT run on XP 32 bit.
2. If you bother to follow the links to find the build instructions at https://github.com/BtbN/FFmpeg-Builds, you will see the following:
How to make a build

Prerequisites

bash
docker

I suggest you take you're own advice.

[Reino]

If anyone wants to see what I mean by "memory issues", I've generated some batch files to test all the builds that Reino is currently hosting.If you really want me and others to have a look, I suggest you upload the batch-file somewhere else too, because it can take forever before your attachment gets approved.
On the other hand, if you're confident this is a regression in FFmpeg, then I suggest you create a ticket (https://trac.ffmpeg.org/).
Anyone know how to include fdk-aac in the ffmpeg build instead of having an external dll?I think the following should be enough. Not tested though.
diff --git a/ffmpeg_local_builds/cross_compile_ffmpeg.sh b/ffmpeg_local_builds/cross_compile_ffmpeg.sh
index bcf87c7..4dbe83a 100755
--- a/ffmpeg_local_builds/cross_compile_ffmpeg.sh
+++ b/ffmpeg_local_builds/cross_compile_ffmpeg.sh
@@ -592,18 +592,8 @@ build_twolame() {
build_fdk-aac() {
do_git_checkout https://github.com/mstorsjo/fdk-aac.git
cd fdk-aac_git
- do_configure --host=$host_target --prefix=$mingw_w64_x86_64_prefix --disable-static # Build shared library ('libfdk-aac-2.dll').
- do_make install-strip
-
- mkdir -p $redist_dir
- archive="$redist_dir/libfdk-aac-$(git describe | tail -c +2 | sed 's/g//')-win32-xpmod-sse"
- if [[ ! -f $archive.7z ]]; then # Pack shared library.
- sed "s/$/\r/" NOTICE > NOTICE.txt
- 7z a -mx=9 -bb3 $archive.7z $mingw_w64_x86_64_prefix/bin/libfdk-aac-2.dll NOTICE.txt
- rm -v NOTICE.txt
- else
- echo -e "\e[1;33mAlready made '${archive##*/}.7z'.\e[0m"
- fi
+ do_configure --host=$host_target --prefix=$mingw_w64_x86_64_prefix
+ do_make install
cd ..
} # [dlfcn]

@@ -880,7 +870,6 @@ build_ffmpeg() {
apply_patch $patch_dir/0001-make-bcrypt-optional.patch -p1 # WinXP doesn't have 'bcrypt'. See https://github.com/FFmpeg/FFmpeg/commit/aedbf1640ced8fc09dc980ead2a387a59d8f7f68 and https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0001-make-bcrypt-optional-on-win32.patch.
apply_patch $patch_dir/0002-windows-xp-compatible-CancelIoEx.patch -p1 # Otherwise you'd get "The procedure entry point CancelIoEx could not be located in the dynamic link library KERNEL32.dll" while running ffmpeg.exe, ffplay.exe, or ffprobe.exe, because 'CancelIoEx()' is only available on Windows Vista and later. See https://github.com/FFmpeg/FFmpeg/commit/53aa76686e7ff4f1f6625502503d7923cec8c10e, https://trac.ffmpeg.org/ticket/5717 and https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0002-windows-xp-compatible-CancelIoEx.patch.
apply_patch $patch_dir/0003-windows-xp-compatible-wcscp.patch -p1 # Otherwise you'd get "The procedure entry point wcscpy_s could not be located in the dynamic link library msvcrt.dll" while running ffmpeg.exe, ffplay.exe, or ffprobe.exe, because 'wcscpy()' is only available on Windows Vista and later. See https://github.com/FFmpeg/FFmpeg/commit/daf61dddc8e27424c320d5c3abe3e0c5182cd5c0.
- apply_patch $patch_dir/0004-load-shared-libfdk-aac-library-dynamically.patch -p1 # See https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0004-dynamic-loading-of-shared-fdk-aac-library.patch.
apply_patch $patch_dir/0005-load-shared-frei0r-libraries-dynamically.patch -p1 # See https://github.com/sherpya/mplayer-be/blob/master/patches/ff/0005-avfilters-better-behavior-of-frei0r-on-win32.patch.
init_options=(--arch=x86 --target-os=mingw32 --prefix=$mingw_w64_x86_64_prefix --cross-prefix=$cross_prefix --extra-cflags="$CFLAGS")
if [[ $1 == "shared" ]]; then

[Reino]

Last week, after more than 20 years of service, my old pc has died. :( After some troubleshooting it's most likely one or more capacitors on the ASUS A7N8X-E Deluxe motherboard that cause all this. I don't think there's anything wrong with the AMD Athlon XP 3200+ cpu or the ATI Radeon HD 3850 AGP gpu.
Every sane person would immediately take the entire system to the scrap heap, but as I'm still quite fond of the thing and because the WinXP compatible non-SSE2 FFmpeg binaries would otherwise stop, I'm contemplating whether or not I should bring it to a repair-shop (I'm not an expert with a soldering bolt).

For the moment I've bought a simple and cheap laptop (AMD Ryzen 3 3200u on Win11), which will have to do until Minisforum, Beelink or Geekom releases a minipc with the soon to be released monster AMD Ryzen AI Max 300 "Strix Halo" APUs (https://wccftech.com/amd-ryzen-ai-max-300-strix-halo-apus-confirmed/).

[FranceBB]

I'm so sorry to hear that, Reino! :(
In theory replacing a capacitor should be possible and I've seen the folks at "The Serial Port" (enthusiasts about very old hardware from the 80s and 90s) do it several times to bring back to life very old hardware, much older than yours.
Unfortunately, I've never done it myself, but I guess it's doable, you just have to find someone who's able and willing to do that.
Well, either that, or finding a replacement motherboard.

[Brazil2]

Last week, after more than 20 years of service, my old pc has died. :(

If you still can access your HDD then you could make a VHD image of it and then use it in a virtual machine.
Check this utility: https://learn.microsoft.com/en-us/sysinternals/downloads/disk2vhd

[Emulgator]

For some of the motherboards are quite good repair recommendations around.
Thanks to a thorough man who compared motherboard versions, found silent upgrades, and published his findings
I was able to get my first Laptop, a 2001 Gericom (1,2GHz Pentium III) back to life
It was the C466 problem, a 330µF/6,3V Tantalum cap, a bit undersized for its task, and giving in after 7 years of service.
Solder pads and some free mm² allowed me to tile 470µF||470µF/6,3V, back in 2015.
Last week it still started up and worked happily for a backup safety test PCMCIA -> 4xUSB2.0 -> 5x2TB RAID6 +...+...+...

[GMJCZP]

Hi Reino, I was testing my DVD encoding script with your latest version and noticed with GSpot that some metadata is not being included in the videos:

https://i.postimg.cc/xdtMSWM7/Muestra-FFMpeg26052024.jpg
Version 26052024

https://i.postimg.cc/nLHBgHjB/Muestra-FFMpeg01092024.jpg
Version 01092024

I already tried with the latest version from another recent build of 32 bits and everything is fine there. (https://github.com/yt-dlp/FFmpeg-Builds/releases)

PD: I'm sad for your PC :(

[Reino]

Hi Reino, I was testing my DVD encoding script with your latest version and noticed with GSpot ...
Please enlighten me, what does that have to do with my FFmpeg binaries? I don't use GSpot.
Btw, it doesn't look like you're on WinXP, so why are you using my FFmpeg binaries?
PD: I'm sad for your PC :(
At the moment the motherboard is being repaired. I've found someone willing to replace around 10 bad capacitors. With a bit of luck I'll have my old pc back in 2 weeks or so.

[FranceBB]

On the "not being on XP" part, by looking at the UI he's probably running Windows 7. I wouldn't be surprised if normal FFMpeg builds didn't run on Win7 either. A bit like Supermium being a Windows XP fork of Chromium which is used by other people running Windows Vista, Windows 7, Windows 8 and Windows 8.1 as the official builds wouldn't run on those OS either.

[Emulgator]

At the moment the motherboard is being repaired. I've found someone willing to replace around 10 bad capacitors. With a bit of luck I'll have my old pc back in 2 weeks or so.
Nice board ! The caps are indeed mentioned, and these are easy-to-replace Elkos.
https://theretroweb.com/motherboards/s/asus-a7n8x-e

[Reino]

I was hoping replacing 10 bad capacitors would bring the motherboard, the pc, back to life, but alas. We've tried another cpu, another gpu, even another BIOS chip, but no video output. Not even the keyboard would work, so probably another essential part (maybe even the chipset itself) is broken. End of the line.
I've learned a lot about Bash and compiling software in the process, but sadly this is where it stops. No more WinXP compatible non-SSE2 FFmpeg binaries from me. Thank you all! :thanks:

[LoRd_MuldeR]

I was hoping replacing 10 bad capacitors would bring the motherboard, the pc, back to life, but alas. We've tried another cpu, another gpu, even another BIOS chip, but no video output. Not even the keyboard would work, so probably another essential part (maybe even the chipset itself) is broken. End of the line.
I've learned a lot about Bash and compiling software in the process, but sadly this is where it stops. No more WinXP compatible non-SSE2 FFmpeg binaries from me. Thank you all! :thanks:

Just as an aside: You don't need a retro PC to create binaries that run on such PC. And you can use, e.g., QEmu for testing ;)

https://i.imgur.com/AdOW1u3.png

[j7n]

You could probably get a used PC that nobody wants for less than it takes to buy 10 capacitors at a radio parts store. The actaal compilation must take a computer from NASA I imagine, not a retro PC.

[danbow]

Never surrender! :)

[Lirk]

I found a problem with using yadif/bwdif filter in builds versions 6x/7x. When encoding with using of those filters, after ending of encoding FFmpeg gives an error and if the file extension is .mp4, then file will be broken, but if .mkv, then file will be working. It can be a workaround by using pipe: " -vf yadif -f nut -c:v rawvideo -c:a pcm_s16le -|ffmpeg -i - out.mp4", but would be better to fix it.

[manolito]

but would be better to fix it.

Slim chance, Reino seems to have lost interest in this thread... :rolleyes:

Don't know if my comments can be useful, I completely abandoned WinXP and moved to Win7 a few years ago. But I still use Reino´s plugin, and I could reproduce your findings.

Under Win7 I use several alternatives (AnimeMouse, autodidact, VeritablePornocopium at reddit), all 64 bit, and none of them has this problem. Reino's 32 bit software shows the problem you have, but only with full HD output resolution, half HD works fine.

My main workaround for this issue is to avoid the MP4 format under 32 bit FFmpeg. I usually transcode my MP4 sources to MKV before loading them into FFmpeg, if I really need MP4 files as the target format, I can easily transcode them back.


Cheers
manolito

[Reino]

Though that's kind of true, I'm still subscribed to this thread, so I do still read everything.
But even if my old pc would still work, I wouldn't be able to help users like Lirk, because the issue he describes of something the FFmpeg devs would have to look into. I (still) can't code in C/C++ after all.
There are some users that sent me a message telling me I should use a virtualdisk to continue this hobby in emulation, but for the moment I don't have the interest. Sorry.

[manolito]

Hey Reino,

good to hear from you after more than half a your, and I am glad that you sound like you´re doing fine... ;)

After my stroke more than 4 years ago my old WinXP PC overheated and crashed, I might have been able to fix this, but I took it as a sign that it was time for me to move on. Since then my computer is an older ThinkPad T530 with a CORE i5 CPU running under Win 7. Ancient by current standards, but I like it...

For Lirk's problem I cannot really say too much because I do not have a WinXP computer to test this. With my Win 7 computer I do not have these issues even under the 32bit versions of FFmpeg. The problems which Lirk has disappear when using an older version of your software like version 5.2. Unfortunately this also means that you will get a buggy version of the Z-Lib library which does not support sources with unusual chroma placement. This problem was fixed for the current FFmpeg versions 7.1, but then you will have the problem with mp4 sources which Lirk outlined. Chosing between a rock and a hard place...

My idea would be to remove the old Z-Lib version from FFmpeg 5.2 and replace it with the Z-Lib version from FFmpeg 7.1, but I would not know how to do this.


Alright, good talking to you after quite some time. Good luck and all the best...


Cheers
manolito

[Lirk]

Though that's kind of true, I'm still subscribed to this thread, so I do still read everything.
But even if my old pc would still work, I wouldn't be able to help users like Lirk, because the issue he describes of something the FFmpeg devs would have to look into. I (still) can't code in C/C++ after all.
There are some users that sent me a message telling me I should use a virtualdisk to continue this hobby in emulation, but for the moment I don't have the interest. Sorry.
Can you reupload an older versions? Because after year 2019/2020 even in official builds was dropped or broken some filters, such as: mcdeint, uspp, vidstabdetect. Maybe would be better to upload it to archive.org or another storage.

[Reino]

Done (https://rwijnsma.home.xs4all.nl/files/ffmpeg/?C=M;O=D).