Very strange bug with Qt-MinGW32 using x264 and FFmpeg libraries
-
When attempting to build the 32-bit version of a GUI application that I have been developing and using in 64-bit systems for some years, which uses video encoding features with the FFmpeg and x264 libraries, I am experiencing crashes after encoding the first frames of the video.
Investigating further, I have discovered that this bug does not occur when the exact same video encoding subroutine is called in a Win32 console application built also with Qt. To prove this, I have done a console application and a GUI application executing the exact same pieces of code involving video encoding, succeeding in the first case and failing in the last one. Here is a link in which you can download these two projects along with the FFmpeg and x264 libraries that I am using and the instructions to build them, so that you can perform tests with them:
https://takeafile.com/?f=hisusinivi
It must be pointed out that I have been trying with many different versions of both FFmpeg and x264 libraries and the errors still occur. Also, to compile the projects I am using the 32-bit version of Qt Creator 4.1.0 based on Qt 5.6.2 in a MSYS2w32-MingGW32 environment.
Is there any solution to this? Or should it be reported as a bug? In any case, many thanks in advance.
-
I think I have found the reason behind this problem. This is because it looks like Qt allocates a certain amount of RAM for GUI applications which is much higher than the amount allocated in console applications. On the other hand, x264 also allocates a lot of RAM memory while encoding a video. When these two factors are combined, it leads to allocations of a large amount of RAM which may easily surpass the 2 GB limit that a 32-bit process is allowed to use. This is strongly supported by the fact that when I switched the resolution of the video from 1080p to 720p in the dummy GUI project that I shared in my above message, the program did not crash and encoded it successfully.
Even so, since I am not properly documented with respect to this topic, I would like to know why it is required such large amount of RAM, even on a very simple GUI application consisting in a main window and a button, with respect to the corresponding command line version executing the same code/action.
-
Hi and welcome to devnet,
Did you check the RAM consumption between the two versions so of your application ?
-
I think I have found the reason behind this problem. This is because it looks like Qt allocates a certain amount of RAM for GUI applications which is much higher than the amount allocated in console applications. On the other hand, x264 also allocates a lot of RAM memory while encoding a video. When these two factors are combined, it leads to allocations of a large amount of RAM which may easily surpass the 2 GB limit that a 32-bit process is allowed to use. This is strongly supported by the fact that when I switched the resolution of the video from 1080p to 720p in the dummy GUI project that I shared in my above message, the program did not crash and encoded it successfully.
Even so, since I am not properly documented with respect to this topic, I would like to know why it is required such large amount of RAM, even on a very simple GUI application consisting in a main window and a button, with respect to the corresponding command line version executing the same code/action.
@DSmith said in Very strange bug with Qt-MinGW32 using x264 and FFmpeg libraries:
I would like to know why it is required such large amount of RAM, even on a very simple GUI
How much RAM is your app consuming without doing encoding?
-
When the GUI app is not doing encoding, it consumes about 350 MB according to Windows Task Manager. I made some sort of "bisection" algorithm to find out the approximate resolution in which it crashes, and it is something located between 720p (where it does not crash) and 1080p (where it crashes). This is a bit strange because in the boundary separating the resolutions in which the app does not crash and the one in which crashes the app consumes about 1300 MB while it is encoding, far from the 2 GB limit for 32-bit apps. Could it be because Windows does not report how much RAM is being consumed when shared DLLs are being used?
Quoting an answer that I received in StackOverflow, it seems so:
"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."
-
What is the stack trace of the crash ?