User's forum.ru-board.com
bug-report (http://forum.ru-board.com/topic.cgi?forum=5&topic=26189&start=1240#4)
Quote- Что то разработчики перед НГ в сборке avidemux_2.7.1 r181230_win32.exe Dec 30 2018, мягко говоря, не доглядели!
На моей ОС WinXP SP3 программа при запуске выдаёт следующее уведомление -
(https://i1.imageban.ru/out/2019/01/01/7a99d6c3daa6b774fc3bfc1f05c6927c.png)
- Тогда, как предыдущая сборка avidemux_2.7.1 r181226_win32.exe Dec 26 2018 запускается штатно!
after:
Quoteопробовал крайнюю сборку от 01.01.19 - всё тот же трабл!
При запуске программы, тремя возможными командами (наименования exe-шников видны на тёмно-синей полосе), получаю следующие уведомления:
(https://i5.imageban.ru/out/2019/01/02/4308a1e9ea3e9cccb92625eef872ec41.png)
(https://i1.imageban.ru/out/2019/01/02/b6f2cbce1bff6887535eb2484e19b2c4.png)
(https://i2.imageban.ru/out/2019/01/02/9518f9df7162e257cb704df4b2aa02e7.png)
Sorry, I don't have Windows XP SP3 and can't check source whats this phenomena.
QuoteВ сборках от 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.
Would you please swap libgcc***.dll and libstdc++-*.dll for testing purposes with versions taken from an older build which still runs?
Big thanks! I write Your answer than send unpacked DLL for testing and wait user's test-report in to topic.
Happy New Year!
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.
Okay, it didn't work out.
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?
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 (https://github.com/mean00/avidemux2/blob/ffmpeg4x/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.
Please ask MOCKBAsity to try the win32 build uploaded to WeTransfer (https://we.tl/t-zJntuxr8jB). File size of the ZIP archive: 37528059 bytes, checksums:
SHA256: 19ea63ee259aacbbf3a74e6748b12c382834d9e8e624dc490e7131297b462e03
SHA1: 45a932deb343c6a4ea27026113ee405fae094f92
MD5: f532c77f6d79bc42acd9a7af3d5c7343
The following not yet committed patch was applied:
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).
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.
QuoteМы думаем должна заработать
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.
Quoteкодирование 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.
Well, I see that the error on WinXP persists even with an MXE rolled back to 2018-09-17.
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.
Quoteeumagga0x2a удалось воспроизвести ошибку. Ищем решение.
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.
Understood, I will tell him. Thanks!
Would you please ask MOCKBAsity to try r190103 from https://avidemux.org/nightly/win32/ (https://avidemux.org/nightly/win32/)? The question is only whether it runs. It doesn't include NVENC video encoder plugins just for now, please don't focus on that.
The next build (r190104) has sorted out the problem of NVENC missing. It has been built using the old MXE off a new "legacy-compat" branch which was branched from the master (so FFmpeg stays at 3.3.x, which might allow NVENC to work with older NVIDIA drivers) with selected patches cherry-picked from ffmpeg4x.
Thanks! I say MOCKBAsity try test build 2.7.1 r190104 win32 and wait hi answer.
MOCKBAsity wrote the test results:
Quoteavidemux_2.7.1 r190104_win32.exe has been installed and works perfectly in WinXP OS! Many thanks to the developers!
FIXED
Very good :-)
With regard to
Quote from: MOCKBAsityА этому видеоролику исходником послужил формат 4K UHD и Avidemux с ним справился отлично!
I can't agree as the first 3 frames are gray in the second video too. The first guess would be that we assume a fixed, low number of reference frames somewhere, which doesn't work nicely when setting ref frames in the encoder to high values.
I can reproduce the issue which looks for me like a bug in libx264. The relevant MediaInfo output for the encoded video which exhibits the problem:
Complete name : x264-reenc-first-frames-gray.mkv
Format : Matroska
Format version : Version 4
File size : 21.9 MiB
Duration : 45 s 775 ms
Overall bit rate : 4 009 kb/s
Writing application : Lavf58.20.100
Writing library : Lavf58.20.100
ErrorDetectionType : Per level 1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 13 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 13 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 45 s 779 ms
Bit rate : 3 738 kb/s
Nominal bit rate : 4 000 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.135
Stream size : 20.4 MiB (93%)
Writing library : x264 core 152 r2854 e9a5903
Encoding settings : cabac=1 / ref=13 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=11 / psy=1 / psy_rd=1,00:0,00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=0 / bitrate=4000 / ratetol=1,0 / qcomp=0,60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20,0 / qblur=0,5 / vbv_maxrate=50000 / vbv_bufsize=62500 / nal_hrd=none / filler=0 / ip_ratio=1,40 / pb_ratio=1,30 / aq=2:1,00
Default : Yes
Forced : No
DURATION : 00:00:45,011000000
The same source, different x264 settings, the output is fine:
Complete name : x264-reenc-ok.mkv
Format : Matroska
Format version : Version 4
File size : 23.7 MiB
Duration : 45 s 775 ms
Overall bit rate : 4 341 kb/s
Writing application : Lavf58.20.100
Writing library : Lavf58.20.100
ErrorDetectionType : Per level 1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 12 Ref Frames
Format settings, CABAC : Yes
Format settings, ReFrames : 12 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 45 s 779 ms
Bit rate : 4 063 kb/s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.147
Stream size : 22.2 MiB (94%)
Writing library : x264 core 152 r2854 e9a5903
Encoding settings : cabac=1 / ref=13 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1,00:0,00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=16 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=100 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20,0 / qcomp=0,60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1,40 / aq=1:1,00
Default : Yes
Forced : No
DURATION : 00:00:45,011000000
It is not directly linked to the number of ref frames.
If you have time for that, it would be nice if you identify the exact setting which triggers this bug and report it where it belongs --> https://mailman.videolan.org/listinfo/x264-devel