Windows XP compatible non-SSE2 FFmpeg binaries

[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?