#2526 closed defect (fixed)
ffmpeg on windows crashes when using Avisynth 2.5.8
| Reported by: | Zarxrax | Owned by: | |
|---|---|---|---|
| Priority: | important | Component: | undetermined |
| Version: | unspecified | Keywords: | regression |
| Cc: | qyot27, Michael Niedermayer | Blocked By: | |
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug: When loading a .avs file as the input into ffmpeg on a windows machine, ffmpeg will crash if the version of avisynth installed on the system is 2.5.8.
When using avisynth 2.6.0, everything works as expected.
The problem seems to have began to occur after this commit: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=b9ad009475f3afb76bd2fbd92936dc4d4cd441ec
More details about the issue can be found in this forum thread: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1084&start=20
Change History (21)
comment:1 by , 12 years ago
| Keywords: | regression added |
|---|---|
| Priority: | normal → important |
comment:2 by , 12 years ago
I've been trying to get to the bottom of this, but I'm not getting anywhere. The crash happens in DllMain whenever a source filter (AVISource, DirectShowSource, FFMS2, etc.) is used, but the reason why it only affects 2.5.8 is a mystery to me.
Based on the observation that x264 can handle 2.5.8 without issue, and that it's been using dynamic loading for AviSynth since November 2009, I tried to shuffle things around in libavformat/avisynth.c to more closely match how x264's input/avs.c is organized, but it just ends in segfaults (what I managed to do is in the 'avsfix' branch on Github: https://github.com/qyot27/FFmpeg/commits/avsfix).
comment:4 by , 12 years ago
AviSynth 2.5.8 - official build from http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/
Script:
AVISource("input.avi")
The actual video file and source filter used don't matter, it simply needs to be loading a video file into the script.
ffmpeg -i test.avs
Crashes without even showing file info.
Backtrace, disassembler, and register info:
C:\dap\vid\Incoming Files>gdb ffmpeg
GNU gdb (GDB) 7.5.50.20130204-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\dap\vid\Incoming Files\ffmpeg.exe...done.
(gdb) r -i test.avs
Starting program: C:\dap\vid\Incoming Files\ffmpeg.exe -i test.avs
[New Thread 348.0x194]
ffmpeg version N-53721-gf70d021 Copyright (c) 2000-2013 the FFmpeg developers
built on Jun 1 2013 17:15:00 with gcc 4.8.0 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enab
le-gpl --enable-version3 --disable-w32threads --enable-avisynth --extra-cflags=-DPTW32_STA
TIC_LIB --target-os=mingw32 --arch=x86 --enable-debug --disable-stripping
libavutil 52. 34.100 / 52. 34.100
libavcodec 55. 12.102 / 55. 12.102
libavformat 55. 8.102 / 55. 8.102
libavdevice 55. 2.100 / 55. 2.100
libavfilter 3. 73.100 / 3. 73.100
libswscale 2. 3.100 / 2. 3.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 3.100 / 52. 3.100
warning: DllMain: hModule=0x10000000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
[New Thread 348.0x578]
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 0x0509b698 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disass $pc-32,$pc+32
Dump of assembler code from 0x7c812adb to 0x7c812b1b:
0x7c812adb <RaiseException+50>: stc
0x7c812adc <RaiseException+51>: (bad)
0x7c812add <RaiseException+52>: ja 0x7c844950 <ValidateLocale+45352>
0x7c812ae3 <RaiseException+58>: test %ecx,%ecx
0x7c812ae5 <RaiseException+60>: mov %ecx,-0x40(%ebp)
0x7c812ae8 <RaiseException+63>: je 0x7c812af1 <RaiseException+72>
0x7c812aea <RaiseException+65>: push %edi
0x7c812aeb <RaiseException+66>: lea -0x3c(%ebp),%edi
0x7c812aee <RaiseException+69>: rep movsl %ds:(%esi),%es:(%edi)
0x7c812af0 <RaiseException+71>: pop %edi
0x7c812af1 <RaiseException+72>: lea -0x50(%ebp),%eax
0x7c812af4 <RaiseException+75>: push %eax
0x7c812af5 <RaiseException+76>: call *0x7c801510
=> 0x7c812afb <RaiseException+82>: pop %esi
0x7c812afc <RaiseException+83>: leave
0x7c812afd <RaiseException+84>: ret $0x10
0x7c812b00 <RaiseException+87>: test %edi,%edi
0x7c812b02 <RaiseException+89>: jle 0x7c80be3e <KERNEL32!IsBadCodePtr+207>
0x7c812b08 <RaiseException+95>: mov -0x4(%ebp),%edx
0x7c812b0b <RaiseException+98>: mov %edx,0xc(%ebp)
0x7c812b0e <RaiseException+101>: movzwl (%esi),%edx
0x7c812b11 <RaiseException+104>: mov -0x8(%ebp),%edi
0x7c812b14 <RaiseException+107>: mov (%edx,%edi,1),%dl
0x7c812b17 <RaiseException+110>: mov %dl,(%ecx)
0x7c812b19 <RaiseException+112>: mov 0xc(%eax),%edi
End of assembler dump.
(gdb) info all-registers
eax 0x22d4f0 2282736
ecx 0x0 0
edx 0x22d590 2282896
ebx 0x51968b0 85551280
esp 0x22d4ec 0x22d4ec
ebp 0x22d540 0x22d540
esi 0x22d580 2282880
edi 0x22d580 2282880
eip 0x7c812afb 0x7c812afb <RaiseException+82>
eflags 0x200206 [ PF IF ID ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0
st0 -nan(0xe1e2e2e2e1e3e2e2) (raw 0xffffe1e2e2e2e1e3e2e2)
st1 -nan(0xe0e1e0e0e2e1e2e1) (raw 0xffffe0e1e0e0e2e1e2e1)
st2 -nan(0xe2e0e3e2e0e1e1df) (raw 0xffffe2e0e3e2e0e1e1df)
st3 -nan(0xe2e1e1e2e1e0e2e1) (raw 0xffffe2e1e1e2e1e0e2e1)
st4 -nan(0xe1e2e1e1e2e3e1e2) (raw 0xffffe1e2e1e1e2e3e1e2)
st5 -nan(0xe2e1e4e2e4e3e2e2) (raw 0xffffe2e1e4e2e4e3e2e2)
st6 -nan(0xe1e1e3e2e3e0e2e2) (raw 0xffffe1e1e3e2e3e0e2e2)
st7 -nan(0xe2e1e1e2e2e1e3e2) (raw 0xffffe2e1e1e2e2e1e3e2)
fctrl 0xffff037f -64641
fstat 0xffff0420 -64480
ftag 0xffffffff -1
fiseg 0x1b 27
fioff 0x4a32ca 4862666
foseg 0xffff0023 -65501
fooff 0xbbd120 12308768
fop 0x5d8 1496
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x40, 0x92, 0xcc, 0x1, 0x28, 0x1, 0x0,
0x0}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x9240, 0x1cc, 0x128, 0x0}, v4_int32 = {0x0,
0x0, 0x1cc9240, 0x128}, v2_int64 = {0x0, 0x12801cc9240},
uint128 = 0x0000012801cc92400000000000000000}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x48, 0x92, 0xcc, 0x1, 0x62, 0x6f, 0x1, 0x1e, 0xa0, 0x2, 0x3a, 0x0, 0x20, 0x1, 0x0,
0x0}, v8_int16 = {0x9248, 0x1cc, 0x6f62, 0x1e01, 0x2a0, 0x3a, 0x120, 0x0},
v4_int32 = {0x1cc9248, 0x1e016f62, 0x3a02a0, 0x120}, v2_int64 = {0x1e016f6201cc9248,
0x120003a02a0}, uint128 = 0x00000120003a02a01e016f6201cc9248}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x3a, 0x0, 0xcc, 0xe0, 0x5f, 0x1, 0x3, 0x0, 0x0,
0x0}, v8_int16 = {0xffff, 0x0, 0x0, 0x3a, 0xe0cc, 0x15f, 0x3, 0x0}, v4_int32 = {
0xffff, 0x3a0000, 0x15fe0cc, 0x3}, v2_int64 = {0x3a00000000ffff, 0x3015fe0cc},
uint128 = 0x00000003015fe0cc003a00000000ffff}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x34, 0xe3, 0x5f, 0x1, 0xc5, 0x81, 0x0, 0x1e, 0x88, 0x0, 0x0, 0x0, 0x40, 0xf, 0xc9,
0x1}, v8_int16 = {0xe334, 0x15f, 0x81c5, 0x1e00, 0x88, 0x0, 0xf40, 0x1c9},
v4_int32 = {0x15fe334, 0x1e0081c5, 0x88, 0x1c90f40}, v2_int64 = {0x1e0081c5015fe334,
0x1c90f4000000088}, uint128 = 0x01c90f40000000881e0081c5015fe334}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x30, 0xf, 0xc9, 0x1, 0x34, 0xe3, 0x5f, 0x1, 0x18, 0xe3, 0x5f, 0x1, 0xb5, 0x5e,
0x0, 0x1e}, v8_int16 = {0xf30, 0x1c9, 0xe334, 0x15f, 0xe318, 0x15f, 0x5eb5,
0x1e00}, v4_int32 = {0x1c90f30, 0x15fe334, 0x15fe318, 0x1e005eb5}, v2_int64 = {
0x15fe33401c90f30, 0x1e005eb5015fe318},
uint128 = 0x1e005eb5015fe318015fe33401c90f30}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x34, 0xe3, 0x5f, 0x1, 0x38, 0xe3, 0x5f, 0x1, 0x1, 0x0, 0x0, 0x0, 0xa0, 0xc4, 0xc4,
0x1}, v8_int16 = {0xe334, 0x15f, 0xe338, 0x15f, 0x1, 0x0, 0xc4a0, 0x1c4},
v4_int32 = {0x15fe334, 0x15fe338, 0x1, 0x1c4c4a0}, v2_int64 = {0x15fe338015fe334,
0x1c4c4a000000001}, uint128 = 0x01c4c4a000000001015fe338015fe334}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x0, 0x0, 0x0, 0x0, 0x6c, 0xe4, 0x5f, 0x1, 0x0, 0x0, 0x0, 0x0, 0x3c, 0xe3, 0x5f,
0x1}, v8_int16 = {0x0, 0x0, 0xe46c, 0x15f, 0x0, 0x0, 0xe33c, 0x15f}, v4_int32 = {
0x0, 0x15fe46c, 0x0, 0x15fe33c}, v2_int64 = {0x15fe46c00000000, 0x15fe33c00000000},
uint128 = 0x015fe33c00000000015fe46c00000000}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {
0x41, 0x83, 0x0, 0x1e, 0x34, 0xe3, 0x5f, 0x1, 0x38, 0xe3, 0x5f, 0x1, 0x0, 0x0, 0x0,
0x0}, v8_int16 = {0x8341, 0x1e00, 0xe334, 0x15f, 0xe338, 0x15f, 0x0, 0x0},
v4_int32 = {0x1e008341, 0x15fe334, 0x15fe338, 0x0}, v2_int64 = {0x15fe3341e008341,
0x15fe338}, uint128 = 0x00000000015fe338015fe3341e008341}
mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
mm0 {uint64 = 0xe1e2e2e2e1e3e2e2, v2_int32 = {0xe1e3e2e2, 0xe1e2e2e2},
v4_int16 = {0xe2e2, 0xe1e3, 0xe2e2, 0xe1e2}, v8_int8 = {0xe2, 0xe2, 0xe3, 0xe1, 0xe2,
0xe2, 0xe2, 0xe1}}
mm1 {uint64 = 0xe0e1e0e0e2e1e2e1, v2_int32 = {0xe2e1e2e1, 0xe0e1e0e0},
v4_int16 = {0xe2e1, 0xe2e1, 0xe0e0, 0xe0e1}, v8_int8 = {0xe1, 0xe2, 0xe1, 0xe2, 0xe0,
0xe0, 0xe1, 0xe0}}
mm2 {uint64 = 0xe2e0e3e2e0e1e1df, v2_int32 = {0xe0e1e1df, 0xe2e0e3e2},
v4_int16 = {0xe1df, 0xe0e1, 0xe3e2, 0xe2e0}, v8_int8 = {0xdf, 0xe1, 0xe1, 0xe0, 0xe2,
0xe3, 0xe0, 0xe2}}
mm3 {uint64 = 0xe2e1e1e2e1e0e2e1, v2_int32 = {0xe1e0e2e1, 0xe2e1e1e2},
v4_int16 = {0xe2e1, 0xe1e0, 0xe1e2, 0xe2e1}, v8_int8 = {0xe1, 0xe2, 0xe0, 0xe1, 0xe2,
0xe1, 0xe1, 0xe2}}
mm4 {uint64 = 0xe1e2e1e1e2e3e1e2, v2_int32 = {0xe2e3e1e2, 0xe1e2e1e1},
v4_int16 = {0xe1e2, 0xe2e3, 0xe1e1, 0xe1e2}, v8_int8 = {0xe2, 0xe1, 0xe3, 0xe2, 0xe1,
0xe1, 0xe2, 0xe1}}
mm5 {uint64 = 0xe2e1e4e2e4e3e2e2, v2_int32 = {0xe4e3e2e2, 0xe2e1e4e2},
v4_int16 = {0xe2e2, 0xe4e3, 0xe4e2, 0xe2e1}, v8_int8 = {0xe2, 0xe2, 0xe3, 0xe4, 0xe2,
0xe4, 0xe1, 0xe2}}
mm6 {uint64 = 0xe1e1e3e2e3e0e2e2, v2_int32 = {0xe3e0e2e2, 0xe1e1e3e2},
v4_int16 = {0xe2e2, 0xe3e0, 0xe3e2, 0xe1e1}, v8_int8 = {0xe2, 0xe2, 0xe0, 0xe3, 0xe2,
0xe3, 0xe1, 0xe1}}
mm7 {uint64 = 0xe2e1e1e2e2e1e3e2, v2_int32 = {0xe2e1e3e2, 0xe2e1e1e2},
v4_int16 = {0xe3e2, 0xe2e1, 0xe1e2, 0xe2e1}, v8_int8 = {0xe2, 0xe3, 0xe1, 0xe2, 0xe2,
0xe1, 0xe1, 0xe2}}
(gdb)
comment:5 by , 12 years ago
Thank you for adding above information!
Since at least two Windows bugs were reported that were only reproducible with gcc 4.8.0, could you confirm that it also fails with gcc 4.7.3 ?
comment:6 by , 12 years ago
It does affect 4.7.x as well, as part of that discussion Zarxrax linked to originally dealt with builds that were compiled with 4.7.2. It was exactly the same sort of error in DllMain, and only affected AviSynth 2.5.8.
For that matter, I can also confirm that MSVC builds exhibit this problem with 2.5.8 (while 2.6 works fine) as well. I'd compiled an MSVC test build for that discussion, and can reproduce it with said same build (which, granted, is from April 21st, but the gdb output of that MSVC build is exactly the same as the backtrace from the current build I posted above).
Unless I'm way off (totally possible here), the crash seems to be occurring *within* avisynth.dll, due to how libavformat is trying to load it. The DllMain errors would seem to point to this. My best guess is that AviSynth 2.6 adds protection meant to avoid this problem, and it doesn't show up on Linux/OSX because dlopen doesn't have the same limitations as LoadLibrary, or because AvxSynth (which is based on AviSynth 2.5.8) backported any necessary changes concerning this issue from 2.6.
One distinct difference between libavformat/avisynth.c and x264's input/avs.c is that in x264's case the struct containing the AVSC_DECLARE_FUNC definitions (func) is nested inside the struct for the environment (avs_hnd_t), whereas in libavformat, AviSynthLibrary and AviSynthContext are separate from each other.
comment:7 by , 12 years ago
| Status: | new → open |
|---|
follow-up: 13 comment:8 by , 12 years ago
I found out something new during some testing just now. The issue with 2.5.8 is very specifically isolated to the loading of video streams. If the script is loading audio only, then it doesn't cause 2.5.8 to crash and FFmpeg can deal with it correctly.
As was noted in the thread Zarx linked to, but curiously never got brought up here (I'm partially to blame, I take responsibility for failing to mention it also), the Version() function works with 2.5.8 and FFmpeg doesn't have an issue with it. It's when external files - and due to the new information, it's actually external video - are loaded that problems start.
To illustrate, scripts like the following:
Version()
works with 2.5.8
AVISource("test.avi")
fails with 2.5.8
AVISource("test.avi",audio=false)
fails with 2.5.8
AVISource("test.avi").KillVideo()
works with 2.5.8
WAVSource("test.wav")
works with 2.5.8
FFAudioSource("test.mp4")
works with 2.5.8
and so on. With any of the arbitrary source filters, so long as the only thing that's received by FFmpeg is audio, there's no problem. But the instant that video is served through the script, there's the segfault that this ticket centers around. This applies to audio-only files opened with the script, or video+audio files, in which the latter case only works if the video stream is disabled (or just simply ignored) within the script, since if that happens it won't pass the video stream to FFmpeg and the segfault will then be averted.
comment:9 by , 12 years ago
In the forum post linked its said that "That's strange, because during the testing phase for the patch, I saw 2.5.8 working correctly" Is there some way to recover this working version, it likely would help debuging this
also the debug dump looks like its missing symbols
comment:10 by , 12 years ago
| Cc: | added |
|---|
Is there a way to detect 2.5.8 at runtime and print a sane error message instead of crashing ?
follow-up: 12 comment:11 by , 12 years ago
I now actually think it's pretty likely that I was remembering wrong when I said I thought one of them worked - I may have just been seeing the case above where Version() works. The missing debug symbols are because of the mismatch in compiler; it may be possible to figure it out with a debug version of FFmpeg built with MSVC, but I have no clue how to use MSVC's debugger (or if it even ships in the Express version), or it may not show anything deeper than what it already does, since avisynth.dll wouldn't be a debug build (much less the actual Windows system libraries).
x264 has a function (get_avs_version) in input/avs.c that can detect the version of AviSynth that it's using.
comment:12 by , 12 years ago
Replying to qyot27:
I now actually think it's pretty likely that I was remembering wrong when I said I thought one of them worked - I may have just been seeing the case above where Version() works. The missing debug symbols are because of the mismatch in compiler; it may be possible to figure it out with a debug version of FFmpeg built with MSVC, but I have no clue how to use MSVC's debugger (or if it even ships in the Express version), or it may not show anything deeper than what it already does, since avisynth.dll wouldn't be a debug build (much less the actual Windows system libraries).
It would probably be helpfull if a avsynth.dll would be build with debug symbols
x264 has a function (get_avs_version) in input/avs.c that can detect the version of AviSynth that it's using.
Can you submit a patch? (make sure its LGPL or ask the authors first)
thanks
comment:13 by , 11 years ago
Replying to qyot27:
I found out something new during some testing just now. The issue with 2.5.8 is very specifically isolated to the loading of video streams. If the script is loading audio only, then it doesn't cause 2.5.8 to crash and FFmpeg can deal with it correctly.
As was noted in the thread Zarx linked to, but curiously never got brought up here (I'm partially to blame, I take responsibility for failing to mention it also), the Version() function works with 2.5.8 and FFmpeg doesn't have an issue with it. It's when external files - and due to the new information, it's actually external video - are loaded that problems start.
To illustrate, scripts like the following:
Version()
works with 2.5.8
AVISource("test.avi")
fails with 2.5.8
AVISource("test.avi",audio=false)
fails with 2.5.8
AVISource("test.avi").KillVideo()
works with 2.5.8
WAVSource("test.wav")
works with 2.5.8
FFAudioSource("test.mp4")
works with 2.5.8
and so on. With any of the arbitrary source filters, so long as the only thing that's received by FFmpeg is audio, there's no problem. But the instant that video is served through the script, there's the segfault that this ticket centers around. This applies to audio-only files opened with the script, or video+audio files, in which the latter case only works if the video stream is disabled (or just simply ignored) within the script, since if that happens it won't pass the video stream to FFmpeg and the segfault will then be averted.
Wanted to mention that I have this issue as well on Win 7 x64.
Though, not specific to just FFMPEG, the freeze happens with MPC-HC[LAVFilters]/VirtualDub as well in combination with AVISynth (2.5.x, 2.6.x, 2.6.x MT) under the following conditions:
1) using AVISource (DirectshowSource seems to work fine)
2) loading a file with both video & audio streams.
The following will work however: AVISource("file.avi",audio=false)
comment:14 by , 11 years ago
After some more backtracing with a build of ffmpeg that had asm and compiler optimizations disabled, I was able to zero in on what I believe is the issue: accessing avs_bit_blt under AviSynth 2.5.8 is what causes the crash, possibly due to problems further up the chain, but I wasn't able to smoke out that part. Unfortunately, due to what that function does, I'm not sure it can be fixed without changing the method in which the data is copied to the output (x264 doesn't use avs_bit_blt, opting for some other method of doing this).
The version check ended up not being based on what x264 does, so the license issue isn't a problem with the patch I've submitted to the mailing list:
http://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/146922.html
The side effect of this is that one of the working cases, that of using Version(), will no longer work with 2.5.8. But since most (or all) other video inputs wouldn't work with 2.5.8 as it stands, and the check basically tells you that you're using a pre-2.6 version of AviSynth and that's the reason it won't work, I view that as sort of a necessary evil just to get it to stop crashing. It wouldn't be very useful for just Version() to work while virtually nothing else does.
@Trigunflame: I don't think that problem is related to this. For starters, I don't believe LAV Filters touches AviSynth at all (it's not one of the formats listed in LAV Splitter's selection dialog, at any rate), not to mention Video for Windows, so if it's the only thing you're relying on there I don't think it'd work (which would explain the problem with VirtualDub, but if the VfW dependency isn't resolved, then AVISource won't work anywhere). You'd need to use ffdshow's VFW interface and the right ACM codecs to resolve that...and keep it to all 32-bit versions so there isn't a bittage conflict.
follow-up: 17 comment:15 by , 11 years ago
After yet another round of fiddling with things yesterday (mostly a wild goose chase, but I did realize yesterday that it was in the parameters being passed to avs_bit_blt rather than avs_bit_blt itself) and again earlier this afternoon, I finally uncovered the real reason for the crash.
It was part of the API change that occurred between 2.5 and 2.6, specifically concerning the functions avs_get_row_size_p and avs_get_height_p. These are then called by avs_bit_blt and it's the API mismatch on those two functions that cause the crash, since the avisynth_c.h header included in compat/avisynth/ assumes 2.6's versions of those functions. AvxSynth uses 2.6's versions so that's why it wasn't affected by it.
A patch that properly fixes this and makes using 2.5.8 work again will be submitted shortly.
comment:16 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | open → closed |
Fixed in 2c25e83b1d022ab36842d77749024b3d720a4227 by Stephen Hutchinson
comment:17 by , 11 years ago
Replying to qyot27:
A patch that properly fixes this and makes using 2.5.8 work again will be submitted shortly.
Could you test if this patch can also be applied to origin/release/2.0 ?
comment:18 by , 11 years ago
Yes, it can be applied to release/2.0. Commit 3aa2257d240a5a0eb94014b9113dd91730786886 can also be safely reverted on master and release/2.0.
comment:19 by , 11 years ago
Please consider sending patches (made with git format-patch) or set up a public git clone that can be merged.
follow-up: 21 comment:20 by , 11 years ago
Wouldn't it be easier to use:
git cherry-pick 2c25e83b1d022ab36842d77749024b3d720a4227 (on release/2.0)
and
git revert 3aa2257d240a5a0eb94014b9113dd91730786886 (on release/2.0 and master)
But just in case:
2.5 patch: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/147345.html
or
https://github.com/qyot27/FFmpeg/commits/avsfix (for master)
https://github.com/qyot27/FFmpeg/commits/release/2.0
comment:21 by , 11 years ago
Replying to qyot27:
Wouldn't it be easier to use:
git cherry-pick 2c25e83b1d022ab36842d77749024b3d720a4227 (on release/2.0)
and
git revert 3aa2257d240a5a0eb94014b9113dd91730786886 (on release/2.0 and master)
yes but then the code isnt tested
no big difference in this case here, but for complex & big patchsets it can make a difference
But just in case:
2.5 patch: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-August/147345.html
or
https://github.com/qyot27/FFmpeg/commits/avsfix (for master)
https://github.com/qyot27/FFmpeg/commits/release/2.0
merged
thanks
Please provide all relevant information here in the ticket, do not use external resources.