0

I have been testing for years a software that I am developing, compiled only for 64-bit systems through Qt-MinGW64, without experiencing any kind of issue regarding video encoding (which is one of the features of such application). Recently, I have been attempting to build the corresponding x86 version of my software by compiling it with Qt-MingGW32.

However, after bulding the same ffmpeg and x264 library versions to create the 32-bit versions and successfully linking them to my project, the application keeps crashing after few frames are encoded, due to segmentation fault error. This is very strange because, as I indicated before, it works flawlessly when compiled for 64-bit systems.

I have also lost a considerable amount hours trying to combine a big amount of different versions of both ffmpeg and x264 libraries, but with no luck either. Neither it works when disabling threads both for x264 and ffmpeg libraries, hence it does not seem to be a win32 threading issue. Therefore, I have concluded that the error is most likely in my code, which by some chance beyond my comprehension tells ffmpeg to allocate the right amount of memory in the x64 version, but not in the x86 version.

It must be pointed out also that before the avcodec_encode_video2 call, I do the following calls, among others, in order to allocate the memory associated to the corresponding items (AVFrame, AVCodec, etc.), such as

avcodec_open2( my_codec_context, my_codec, &opt );
my_av_frame=av_frame_alloc();

More precisely, the details involving the code structure that I am using can be found here.

Therefore, the error appears to be more subtle than just issues regarding uninitialized memory.

Many thanks in advance.

UPDATE:

I have discovered the focus of the problem. For some reason, FFmpeg/x264 libraries behave abnormally in Win32 GUI applications compiled with Qt-MinGW32, while they run correctly in Win32 console applications, also compiled with Qt-WinGW32. I have proven this claim performing two dummy tests, in which the exact same piece of code is run through a console application and on a GUI application, succeeding in the first case and failing in the latter one. The code for such tests can be found below, along with the x264 and FFmpeg libraries used in my projects, together with instructions to build them in msys2 with MinGW32:

https://takeafile.com/?f=hisusinivi

I have no idea whether it can be solved by simply tweaking the code or it is a serious bug involving an incompatibility issue. If it is the latter, should it be reported to the Qt/FFmpeg/x264 staff as a major bug?

ksb496
  • 835
  • 1
  • 7
  • 12
  • It's not at all strange - I'd expect almost all software that compiled, linked and worked when compiled for 64-bit to fail when switched to 32-bit. –  Feb 23 '18 at 23:31
  • I've done a lot of 32-bit and 64-bit cross-compiling. (And 16-bit cross-compiling, way back when.) Assumptions about pointers or data type sizes can often lead to problems. Making highly portable code is hard -- as it requires a lot of diligence and discipline. If the code is on, say, GitHub or whatever, I can take a look at it. – Eljay Feb 23 '18 at 23:31
  • Also, a friend of mine ported AT&T Unix to the 64-bit Cray computers. He ran into all sorts of fun assumptions in the Unix code that he had to straighten out. Good times. – Eljay Feb 23 '18 at 23:33
  • Thanks for all your comments. As for the code, I only use local control version through SVN. The code of the entire application is too long, but if you want, and for the sake of readability, I can extract and upload the encoding routine in a separate project so that you can analyze the specific part in which the issues are produced, without having to deal unnecesarily with the rest of the code nor having to compile further third party library dependencies used in other parts of the code. – ksb496 Feb 23 '18 at 23:47
  • Well, it happened that after I separated for you the piece of code that failed, generating dummy frames and encoding them, it did not crash. Investigating further, I found out that the error was being produced because precisely the project whose video I was stubbornly trying to encode with the 32-bit version used an amount of RAM very close to 2 GB, which appears to be the limit that a program can use in 32-bit OS. Therefore, it seems that in the middle of the encoding process it somehow reached such 2 GB limit, causing that crash. Once more, many thanks for your inspiring suggestion. – ksb496 Feb 24 '18 at 00:40
  • After further experimentation, the behaviour is still abnormal with random crashes, even when almost no RAM should be consumed. However, I have discovered the focus of the problem: for some reason, FFmpeg/x264 libraries do not get along with Win32 GUI applications built with Qt-MinGW32. This is because, while the above dummy example, done in a console application, works, the exact same part of code being executed in a Qt GUI application fails. Here you have a link containing the Qt projects as well as the libraries and the instructions to build them: takeafile.com/?f=hisusinivi – ksb496 Feb 24 '18 at 05:29

1 Answers1

1

Looks like you are going out memory (virtual address space available to 32-bit app) at least that is what happens with your QT GUI-test app. Your settings for encoding YUV 4:4:4 FullHD video need around 1.3 GB of memory and this should be available for 32-bit app at 64-bit OS by default (and it is for your console test). But for some reason your QT GUI-test starts to fail after allocating only 1 GB of memory. I am dunno if this 1 GB limit is by QT or Windows for any GUI app. If you make you video resolution 960x540 instead of 1920x1080 than it should work (as it needs less than 1 GB of memory). Otherwise you should set LARGE_ADDRESS_ AWARE flag in PE header by specifying -Wl,--large-address-aware to linker and than 4 GB of memory should be available to 32-bit app on 64-bit OS.

UPDATE

Looks like QT GUI-test have less memory than console test because it links also to Qt5Guid.dll and Qt5Widgetsd.dll which takes additional 450 MB of address space in addition to other libraries which also links in console app and so only 1 GB of free address space from 2 GB available remains to memory heap.

nobody555
  • 2,239
  • 18
  • 18
  • Thanks for your reply. I was also suspecting it was of problem involving the 2 GB limitation for 32-bit apps , but you have specified exactly what is making the GUI version to take a much larger amount of RAM, so I have marked your answer as the accepted one. I guess I should invoke the encoder in a separate command-line process in the 32-bit version of my app. – ksb496 Mar 02 '18 at 08:25