User report on x86 problem in to WinXP SP3 in v2.7.1 build 's after 30.12.2018

[VictorVG]

User's forum.ru-board.com bug-report

- Что то разработчики перед НГ в сборке avidemux_2.7.1 r181230_win32.exe Dec 30 2018, мягко говоря, не доглядели!
На моей ОС WinXP SP3 программа при запуске выдаёт следующее уведомление -

- Тогда, как предыдущая сборка avidemux_2.7.1 r181226_win32.exe Dec 26 2018 запускается штатно!

after:

опробовал крайнюю сборку от 01.01.19 - всё тот же трабл!
При запуске программы, тремя возможными командами (наименования exe-шников видны на тёмно-синей полосе), получаю следующие уведомления:

Sorry, I don't have Windows XP SP3 and can't check source whats this phenomena.

[eumagga0x2a]

В сборках от 30.12.2018 и 01.01.2019 изменений в исходниках нет!

Well, the git branch was switched from master to ffmpeg4x bringing FFmpeg 4.1 as well as fixes for indexers for H.264 and HEVC in MPEG-TS and for the Annex B to Annex B stream filter. Unsure about 30.12.2018, but the most recent builds have switched to Qt 5.12.0 thus fixing some sore issues like HiDPI scaling with OpenGL on win10.

WinXP is entirely untested and thus unsupported. I hope Mean might have an idea, I can't help here, unfortunately.

[eumagga0x2a]

Would you please swap libgcc***.dll and libstdc++-*.dll for testing purposes with versions taken from an older build which still runs?

[VictorVG]

Big thanks! I write Your answer than send unpacked DLL for testing and  wait user's test-report in to topic.

Happy New Year!

[eumagga0x2a]

Thank you, the suggestion came from Mean, I just relayed it. I've bookmarked the original topic so I'll know whether it helped or not on my own (I don't enable email notifications here).

Happy New Year to you too.

[eumagga0x2a]

Okay, it didn't work out.

[VictorVG]

Possible I found source for this phenomena - after 26.12.2018 for build used new version GCC and output sequestrable have differential's  ordinal in to KERNEL32.dll and msvcrt.dll. Please, see attachments in to imports_list.zip. List generated use PEView (part Process Hacker project) - menu Tools -> Inspect executable v3.0.6559.2032 Git-bde9755c .

P.S.

Me can revert XP support example then if use previsions version GCC, but needed or have another resolve?

[eumagga0x2a]

I am currently trying to build MXE at 54871cb14524e56a451996daf85432af5024abb3, the last commit before MinGW was updated on 2018-09-18 from 5.0.4 to 6.0.0. This may take a while. If I succeed, I'll cross-build win32 Avidemux using this MXE and upload it (I can generate only ZIP archives as described in cross-compiling.txt) somewhere for testing.

By the way, I forgot to delete the passage in the description which states that "x265 has not been packaged for MXE as
of this writing". Luckily enough, x265 is finally available as an MXE package.

[eumagga0x2a]

Please ask MOCKBAsity to try the win32 build uploaded to WeTransfer. File size of the ZIP archive: 37528059 bytes, checksums:

SHA256: 19ea63ee259aacbbf3a74e6748b12c382834d9e8e624dc490e7131297b462e03
SHA1: 45a932deb343c6a4ea27026113ee405fae094f92
MD5: f532c77f6d79bc42acd9a7af3d5c7343

The following not yet committed patch was applied:

Code Select Expand

git diff cmake/admCheckNvEnc.cmake
diff --git a/cmake/admCheckNvEnc.cmake b/cmake/admCheckNvEnc.cmake
index 33a602323..29e296bdd 100644
--- a/cmake/admCheckNvEnc.cmake
+++ b/cmake/admCheckNvEnc.cmake
@@ -8,16 +8,14 @@ MACRO(checkNvEnc)
                IF (NVENC)
             PKG_CHECK_MODULES(FFNVENC ffnvcodec)
                    IF (FFNVENC_FOUND)
-                        FIND_PATH(NVENC_INCLUDE_DIR nvEncodeAPI.h
-                        PATHS /usr/include /usr/include/nvenc /usr/include/x86_64-linux-gnu ${FFNVENC_CFLAGS}) # Needed for 64 bits linux
-                        IF(NVENC_INCLUDE_DIR)
-                                       MESSAGE(STATUS " nvenc header Found in ${NVENC_INCLUDE_DIR}")
-                                SET(USE_NVENC True)
-                                SET(NVENC_FOUND 1)
-                        ELSE(NVENC_INCLUDE_DIR)
-                                               MESSAGE(STATUS " nvenc header not Found ")
-                                SET(NVENC_FOUND 0)
-                        ENDIF(NVENC_INCLUDE_DIR)
+                        IF(FFNVENC_INCLUDE_DIRS)^M
+                            MESSAGE(STATUS " nvenc header Found in ${FFNVENC_INCLUDE_DIRS}")^M
+                            SET(USE_NVENC True)^M
+                            SET(NVENC_FOUND 1)^M
+                        ELSE(FFNVENC_INCLUDE_DIRS)^M
+                            MESSAGE(STATUS " nvenc header not Found ")^M
+                            SET(NVENC_FOUND 0)^M
+                        ENDIF(FFNVENC_INCLUDE_DIRS)^M
                        SET(NVENC_CHECKED 1)
                    ELSE (FFNVENC_FOUND)
                 MESSAGE(STATUS "FFNVENC not found, you can get it from here https://github.com/FFmpeg/nv-codec-headers")


to enable the build of NVENC-based video encoder plugins for H.264 and HEVC (I don't think it can be of any use on WinXP as it requires a pretty current NVIDIA graphics card as well as driver version to work, but whatever).

[VictorVG]

I looked on the NVIDIA website - for video cards newer than
GeForce GTX TITAN, GeForce GTX TITAN Black or GeForce GTX 960, GeForce GTX 950 there are no drivers for XP/Vista, and under XP there is hardly any new video card with hardware support for nvenc x.264/x.265, so I think in the case of this OS it would be more correct to use the CPU than the GPU - at least the problem of load balancing of the vector processor will disappear.

[eumagga0x2a]

Мы думаем должна заработать

No, it is just a wild guess that the loss of WinXP compatibility might be related to that mingw update – the famous trial and error method.

кодирование H.264/HEVC в этой сборке осуществляется средствами ЦП (программно) т.к. для ХР нет драйверов новее чем для GeForce GTX TITAN, GeForce GTX TITAN Black, GeForce GTX 960, GeForce GTX 950 (9-я серия) но возможности плат поддерживаются частично. Лично я этими платами не экспериментировал (у меня сейчас на стенде стоит  GTX 650, а рабочей машине GTX 1060)

A NVIDIA driver newer than 378.13 397.93 (with the current nv-codec-headers version) would be required while max. 368.81 is available, so yes, the build (generally, the ffmpeg4x branch) is likely unusable on WinXP for encoding on the GPU.

[eumagga0x2a]

Well, I see that the error on WinXP persists even with an MXE rolled back to 2018-09-17.

[VictorVG]

MOCKBAsity

Also have API error if try test build avidemux_r190103-013709_win32Qt5. It seems everything rests on ld which when linking links substitutes the entry points of which in XP has not yet been. In principle, you can use the old trick that was used on IBM OS/360 - an assembler-wrapper that reverses API calls in the case of XP and partially takes over exception handling.

Then I coordinated the code written in IBM PL/1 with the mathematical libraries of Fortran in this way, but this may require a fairly large assembly code, although it will ensure its maximum speed and controllability of the hook procedures.

[eumagga0x2a]

eumagga0x2a удалось воспроизвести ошибку. Ищем решение.

No, it meant simply that I had read MOCKBAsity's answer. I don't have any WinXP installation to test and also can't go further back in time with MXE. Mean might posess a backup of his old MXE, it is up to him whether to provide legacy builds from it (maybe from a special branch which will never be updated to ffmpeg 4.x) or not. I cannot offer any help here, sorry.

[VictorVG]

Understood, I will tell him. Thanks!