Dropping support of 32-bit build

[1480c1]

Алексей @Alexpux 06:28
I will not provide 32 bit MSYS2-packages anymore since today

from gitter

Starting today, it seems that 32-bit packages will no longer be updated, thus it would be good to be able to drop 32-bit support soon.

Any comments/concerns @wiiaboo and @LigH-de (since you are the only one that I know compiles 32-bit)

[LigH-de]

I read this like there won't be msys32 anymore, but cross-compilation under msys64 may still be possible. That's fine for me as a buffer. But I do see that with the discontinuation of Windows 7, the market for 32-bit code vanishes, and when even cross-compiling is not possible anymore, I shall not cry but let old limits go...

[1480c1]

I think it's more like the current mingw-w64-i686 packages will be frozen at their current state and none of those packages will receive any more updates, maybe not even bugfixes etc, so theoretically, cross-compilation will still be possible, just not supported

[Alexpux]

There are missundestanding. I will not update packages for 32-bit MSYS, not MINGW

[1480c1]

Ahh, I see, nevermind then

[1480c1]

I guess I still need to update to prevent using a msys32 host

[wiiaboo]

That's great news.

[1480c1]

I think it might be fine to reopen this since it might be a good time to revisit the question of dropping 32-bit compilation since currently both of the "official" builds listed on ffmpeg.org (gyan's, BtbN) does not distribute 32-bit builds, and also considering a lot of issues stem from 32-bit, and we have a lot of code specific to 32-bit, I think it might be better to drop it

[1480c1]

I do want to get some other people's opinion on this though, emote with +1 for drop or -1 for no drop I guess, with comments for specific concerns or questions or arguments

[1480c1]

pinging people who recently had issues with 32-bit builds (thus the only people I know who actually compile 32-bit, not for testing)

@Rollinnn
@pat357
@kenichi512
@jlw4049
@Barough

[LigH-de]

I do compile for both targets as long as it is supported, knowing that a few people enjoy me still providing 32-bit builds now and then, where available. But I won't be the "last hope" for those. Might abstain from voting... not sure yet.

[GyanD]

I've only had one request so far for 32-bit builds.

If someone is ready to build a redistributable 32-bit build once whenever a micro (or greater) release occurs, I would be willing to host it.

[dloneranger]

32bit dlls are still used for virtualdub's ffmpeg plugin - it's downloaded quite a lot

[jessielw]

I do not not require 32 bit

[dloneranger]

@GyanD if it's the compiling thats a problem I can do that , it doesn't take long - could even schedule the pc to do it daily while im at work
Not sure how you'd do an ffmpeg release version as mab just pulls the latest?
So far the only problem has been the compile errors with strncpy_s and rust that has meant more fails that sucesses ;-)

[moisespr123]

For me this is fine. Today's world is only 64bit. Don't need 32bit versions of the suite and the software it compiles.

[GyanD]

@dloneranger You would modify build/media-suite_compile.sh to pull from ffmpeg repo from a release branch. It's a small change on one line.

[dloneranger]

@GyanD well, if 32bit stays (hope so, most virtualdub plugins are 32bit) I can do that
Probably better to wait to see what happens here and then feel free to email me dloneranger67@gmail.com if you'd like me to do the building

[Barough]

I want 32bit to stay as long as it's possible. I know some that enjoy that im still compiling 32bit encoders.

[wiiaboo]

If everything rust is broken in 32-bit, then nothing rust is compiled for 32-bit, simple.
If any library is only broken in 32-bit, disable it indefinitely.

If people need that rust app/library in 32-bit, let them waste time making it work again.

[garoto]

Considering how this repo purpose is to build a variety of native Windows binaries for a bunch of programs, and knowing how the whole Windows legacy ecosystem is much more complex than people might want to admit it, I'd say keep the 32bit framework/toolchain for now, but only if it doesn't incur a costly maintainance burden.

[1480c1]

An alternative I was thinking about is essentially forking this repo, but making that fork 32-bit only and stripping out a lot of things so it only compiles ffmpeg and making that fork essentially maintenance mode only. That way this main mabs can be 64-bit only, and that fork will be 32-bit only, but I am not sure about how much effort that will be as well.

[wiiaboo]

Well, it'd be almost the same effort to keep 32-bit but strongly discourage it.

[1480c1]

I guess since it's been 1 week, I will start first making sure that 32-bit compilation for both clang and gcc at least works (probably not going to test if all of the resulting binaries do work though), then maybe tag the commit, and then work on removing 32-bit support from the main repo, I might consider making a separate fork or repo based on that tag and strip pretty much everything except 32-bit ffmpeg and libs and then put that on maintenance mode. But for the most part, those who still might want 32-bit compilation can pin their suite to that commit, I hope.

[Selur]

I often compile 32bit mencoder/mplayer/ffmpeg :)
Mainly to handle 32bit Avisynth scripts and DVDs
So it would be nice if 32bit would still be supported.

[1480c1]

Well, we still have a bit of time before anything major happens, right now I'm first trying to completely make 32-bit compilation work including vlc, currently waiting on msys2 to update their headers-git package to the latest for qtdeclarative building

[WereCatf]

Just a quick mention as it's quite pertinent to this topic: building only 64bit ffmpeg with OpenCL enabled currently fails. I do realize OpenCL-support isn't exactly high priority, but that's still one thing that could warrant looking into, once 32bit support is dropped.

[1480c1]

I guess while trying to fix 32-bit and 64-bit compilation with gcc and clang, I can try to test as many libraries for ffmpeg as well

[1480c1]

Just a quick mention as it's quite pertinent to this topic: building only 64bit ffmpeg with OpenCL enabled currently fails. I do realize OpenCL-support isn't exactly high priority, but that's still one thing that could warrant looking into, once 32bit support is dropped.

could you perhaps elaborate on your issue of ffmpeg and opencl 64-bit? I still haven't run into it

[WereCatf]

@1480c1 Nevermind, I'm a dumbass.

[WereCatf]

I think despite the excellent improvements in hardware world, Its still essential to keep supporting 32bit system because the number of users with 32 bit devices is not low. These difficulties seems come from one of the ffmpeg developers mistake that they tried to put anything together in one package

Uh, first you're talking about one thing, then about a completely different thing. How is difficulties with compiling ffmpeg related to people using or not using 32bit systems?

[viliml]

I guess Delphi-Coder's point is that making mabs 64-bit only would sadden people on 32-bit systems because they would lose the simple way to compile ffmpeg.

[ggarra13]

-1. Please keep 32bit support.

[softworkz]

About 10% of our users are still downloading the 32bit package of our Windows application.
If 32bit build support would be removed, we'd have to stop using m-ab-s altogether and cross-compile on Linux instead.

[GTANAdam]

32bit should be kept for some legacy purposes, removing it should cause lots of issues to lots of users

[ultrasound1372]

At least keep 32-bit build on 64-bit systems, the resulting FFmpeg is being brought into foobar2000 to support more codecs and foobar2000 is still 32-bit only.

[Rollinnn]

At least keep 32-bit build on 64-bit systems, the resulting FFmpeg is being brought into foobar2000 to support more codecs and foobar2000 is still 32-bit only.

If you are talking about foo_input_ffmpeg, it can use 64-bit ffmpeg. On 64-bit Windows only , of course.

[ultrasound1372]

That and foo_youtube, which uses the AV libraries directly.

[1480c1]

For the people who still use 32-bit libraries etc, can you list which libraries and executables you actually use/need?

[Selur]

Sure. :)
I frequently use use: mplayer,mencoder, ffmpeg.

[1480c1]

mplayer,mencoder, ffmpeg.

For those, do you know which external libraries you use for them? Or is it just "all"?

[Selur]

Personally I only need the 32bit versions for handling 32bit Avisynth and mencoder&mplayer for their 32bit vfw interface to handle some old usually propriatary legacy formats libav can't handle. (For anything else I use the 64bit versions.)

[softworkz]

Hi,

we are still doing 32bit builds with each release and each beta and there's still a significant share of users who are downloading the 32bit Windows packages (haven't drilled down on the reasons).

In our case it's all ffmpeg executables (with most of the libs) but none of any of the other executables.

BTW, thanks a lot for maintaining this project!

Best wishes,
softworkz

[ultrasound1372]

I use all FFmpeg shared libs and MPV integrated with a few components in foobar2000, requiring they all be 32-bit. I do not use the 32-bit version of any of the static command line executables. My build environment is option 3 with minor changes, can send you my options.txt if necessary. The foo_youtube component also has the ability to specify an external libcurl, which I assume also has to be 32-bit, but I don't personally use that option. Furthermore it supports integration of madVR, VSFilter, and LAV Filters libraries. Those, however, I get from other places since the suite doesn't build them, and I doubt it needs to.

[Maypeur]

Please no, keep alive this 32b version i link it in all my program !
Anyway, thanks for this usefull tool !

[ultrasound1372]

It turns out VGMStream includes configuration files for a custom FFmpeg build via this suite, and it is primarily compiled as 32-bit for all of its media player plug-ins.

[maxiuca]

I'm also still using 32bit builds for some specific tasks, and m-ab-s has been extremely useful for me for the last 2 years because I can get 32b versions of apps built that aren't available to download anywhere.

[suphamster]

Looks like support for 32bit already dropped this year coz it doesn't wants to compile throwing error similar like in ancient issue there https://trac.ffmpeg.org/ticket/3177

[LigH-de]

Which support of what module exactly, @suphamster ? This issue is about the general support of a separate MinGW32 cross-compilation stage in m-ab-s, not in the sources of ffmpeg or any linked codec.

[suphamster]

Which support of what module exactly, @suphamster ? This issue is about the general support of a separate MinGW32 cross-compilation stage in m-ab-s, not in the sources of ffmpeg or any linked codec.
Yeah, looks like I chose wrong topic and my error exactly same as described in my link.
┌ ffmpeg git ............................................ [Files missing] ├ Changing options to comply to nonfree... ├ Compiling static FFmpeg... ├ Running configure... ├ Running make... Likely error (tail of the failed operation logfile): inlined from 'get_cabac' at src/libavcodec/cabac_functions.h:145:12, inlined from 'decode_cabac_mb_intra4x4_pred_mode' at src/libavcodec/h264_cabac.c:1377:9, inlined from 'ff_h264_decode_mb_cabac' at src/libavcodec/h264_cabac.c:2081:32: src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints 199 | __asm__ volatile( | ^~~~~~~ src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints src/libavcodec/x86/cabac.h:199:5: error: 'asm' operand has impossible constraints make: *** [/build/ffmpeg-git/ffbuild/common.mak:81: libavcodec/h264_cabac.o] Error 1

[LigH-de]

That looks specific to the CABAC decoder in a libavcodec H.264 codec, in the ffmpeg sources.

[suphamster]

That looks specific to the CABAC decoder in a libavcodec H.264 codec, in the ffmpeg sources.

But 64bit version compiles fine with same settings so I thought that it concerns dropped support...

[LigH-de]

You are still in the wrong thread.

This thread is related to the development of the media-autobuild suite. We are not ffmpeg developers. Even if the ffmpeg team dropped support for 32-bit code (which I would doubt a lot), the suite can still compile many other codecs, also as separate executables, independent of ffmpeg.