qyot27
25th April 2013, 06:53
Recently there have been reports that using a combination of:
A) AviSynth 2.5.8 (32-bit)
B) FFmpeg-git, post-March 21st (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b9ad009475f3afb76bd2fbd92936dc4d4cd441ec) (also 32-bit)
and sometimes
C) 64-bit Windows (I assume it applies equally to Vista, Win7, and Win8)
results in a crash whenever files attempt to be loaded through a source filter - AVISource, DirectShowSource, FFMS2, etc., but a simple Version() is not and displays correctly. AviSynth 2.6 (alpha4 or in my case, both alpha3 and SEt's MT build from 2012-05-15) does not exhibit this issue and using source filters works just fine. I was able to reproduce the crash on my 32-bit Windows XP install, so I'm not entirely sure whether the bittage is important.
I'm asking here rather than on FFmpeg's bug tracker because I'm not entirely convinced that the error is in FFmpeg*. This is because there was a similar issue reported a couple years ago with avs2avi (http://doom10.org/index.php?topic=1253.0). The thread there sort of devolved without any clear resolution or proper debugging done, though. x264 has no issue with the script, so I'm not sure what the actual issue is.
*although it certainly could be, but since FFmpeg development is majority-Linux I figured I'd probably get a better explanation of what the real issue is and possibilities of how to resolve it if I asked here.
I don't know how much it helps since it's gdb and not MSVC's debugger, but this is what happens with, e.g., an AVISource script:
(gdb) r -i test.avs
Starting program: C:\Program Files\megui\tools\ffmpeg\ffmpeg.exe -i test.avs
[New Thread 440.0x604]
ffmpeg version N-51733-g7514dcb Copyright (c) 2000-2013 the FFmpeg developers
built on Apr 10 2013 13:10:05 with gcc 4.7.2 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enab
le-gpl --enable-version3 --disable-w32threads --enable-libutvideo --enable-libxvid --enabl
e-libx264 --enable-libtwolame --enable-libmp3lame --enable-libvorbis --enable-libopus --en
able-libvo-aacenc --enable-libvpx --enable-libtheora --enable-libopenjpeg --enable-avisynt
h --cpu=pentium3 --extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW3
2_STATIC_LIB' --target-os=mingw32 --arch=x86
libavutil 52. 25.100 / 52. 25.100
libavcodec 55. 2.100 / 55. 2.100
libavformat 55. 2.100 / 55. 2.100
libavdevice 55. 0.100 / 55. 0.100
libavfilter 3. 50.103 / 3. 50.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
[New Thread 440.0x4e0]
warning: DllMain: hModule=0x10000000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
gdb: unknown target exception 0xe06d7363 at 0x7c812afb
Program received signal ?, Unknown signal.
0x7c812afb in RaiseException () from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0 0x7c812afb in RaiseException () from C:\WINDOWS\system32\kernel32.dll
#1 0x77c2272c in msvcrt!_CxxThrowException () from C:\WINDOWS\system32\msvcrt.dll
#2 0x1001269e in ?? () from C:\WINDOWS\system32\avisynth.dll
#3 0x021af9c8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
The same script plays without issue in Windows Media Player, and it also supposedly worked correctly in FFmpeg prior to the introduction of the new AviSynth demuxer. The old demuxer relied on VFW to load AviSynth, whereas the new one loads the AviSynth library directly (like x264 does, although as I noted above, x264 has no issue with it here).
A) AviSynth 2.5.8 (32-bit)
B) FFmpeg-git, post-March 21st (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b9ad009475f3afb76bd2fbd92936dc4d4cd441ec) (also 32-bit)
and sometimes
C) 64-bit Windows (I assume it applies equally to Vista, Win7, and Win8)
results in a crash whenever files attempt to be loaded through a source filter - AVISource, DirectShowSource, FFMS2, etc., but a simple Version() is not and displays correctly. AviSynth 2.6 (alpha4 or in my case, both alpha3 and SEt's MT build from 2012-05-15) does not exhibit this issue and using source filters works just fine. I was able to reproduce the crash on my 32-bit Windows XP install, so I'm not entirely sure whether the bittage is important.
I'm asking here rather than on FFmpeg's bug tracker because I'm not entirely convinced that the error is in FFmpeg*. This is because there was a similar issue reported a couple years ago with avs2avi (http://doom10.org/index.php?topic=1253.0). The thread there sort of devolved without any clear resolution or proper debugging done, though. x264 has no issue with the script, so I'm not sure what the actual issue is.
*although it certainly could be, but since FFmpeg development is majority-Linux I figured I'd probably get a better explanation of what the real issue is and possibilities of how to resolve it if I asked here.
I don't know how much it helps since it's gdb and not MSVC's debugger, but this is what happens with, e.g., an AVISource script:
(gdb) r -i test.avs
Starting program: C:\Program Files\megui\tools\ffmpeg\ffmpeg.exe -i test.avs
[New Thread 440.0x604]
ffmpeg version N-51733-g7514dcb Copyright (c) 2000-2013 the FFmpeg developers
built on Apr 10 2013 13:10:05 with gcc 4.7.2 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enab
le-gpl --enable-version3 --disable-w32threads --enable-libutvideo --enable-libxvid --enabl
e-libx264 --enable-libtwolame --enable-libmp3lame --enable-libvorbis --enable-libopus --en
able-libvo-aacenc --enable-libvpx --enable-libtheora --enable-libopenjpeg --enable-avisynt
h --cpu=pentium3 --extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW3
2_STATIC_LIB' --target-os=mingw32 --arch=x86
libavutil 52. 25.100 / 52. 25.100
libavcodec 55. 2.100 / 55. 2.100
libavformat 55. 2.100 / 55. 2.100
libavdevice 55. 0.100 / 55. 0.100
libavfilter 3. 50.103 / 3. 50.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
[New Thread 440.0x4e0]
warning: DllMain: hModule=0x10000000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
gdb: unknown target exception 0xe06d7363 at 0x7c812afb
Program received signal ?, Unknown signal.
0x7c812afb in RaiseException () from C:\WINDOWS\system32\kernel32.dll
(gdb) bt
#0 0x7c812afb in RaiseException () from C:\WINDOWS\system32\kernel32.dll
#1 0x77c2272c in msvcrt!_CxxThrowException () from C:\WINDOWS\system32\msvcrt.dll
#2 0x1001269e in ?? () from C:\WINDOWS\system32\avisynth.dll
#3 0x021af9c8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
The same script plays without issue in Windows Media Player, and it also supposedly worked correctly in FFmpeg prior to the introduction of the new AviSynth demuxer. The old demuxer relied on VFW to load AviSynth, whereas the new one loads the AviSynth library directly (like x264 does, although as I noted above, x264 has no issue with it here).