Windows XP compatible non-SSE2 FFmpeg binaries

[FranceBB]

Originally Posted by j7n

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]

Originally Posted by 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!
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 is from 20-05-2021. Or would a release based on a newer FFmpeg make a difference?

[FranceBB]

Originally Posted by Reino

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
2) Be able to properly decode DNX120 interlaced

[Reino]

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

[FranceBB]

Doesn't work...



It's missing the Bcrypt stuff

BCryptCloseAlgorithmProvider
BCryptGenRandom
BCryptOpenAlgorithmProvider

[Reino]

Sorry, my mistake. Please re-download.

[FranceBB]

Works like a charm.

[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 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 hasn't seen any updates since 31-05-2022.
For the next release I assume Gianluigi has updated his code.

[Jamaika]

Originally Posted by Reino

You won't be missing anything at all, because libfdk-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]

Originally Posted by Reino

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.

[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 works with Reino's latest Build and AAC.

[Reino]

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

Originally Posted by Reino

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 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'. 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.

Originally Posted by Reino

To circumvent the Python 3 issue (for now) I've switched to the Mbed TLS 2.28.2 branch

This has been solved and the FFmpeg binary is now using the latest Mbed TLS 3.4.1.

Originally Posted by FranceBB

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. 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 and here, 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]

Originally Posted by FranceBB

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.