Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#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 Carl Eugen Hoyos, 11 years ago

Keywords: regression added
Priority: normalimportant

Please provide all relevant information here in the ticket, do not use external resources.

comment:2 by qyot27, 11 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:3 by Carl Eugen Hoyos, 11 years ago

Could you add a backtrace etc. and information on how to reproduce?

comment:4 by qyot27, 11 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 Carl Eugen Hoyos, 11 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 qyot27, 11 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 Carl Eugen Hoyos, 11 years ago

Status: newopen

comment:8 by qyot27, 11 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 Michael Niedermayer, 11 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 Michael Niedermayer, 11 years ago

Cc: qyot27 Michael Niedermayer added

Is there a way to detect 2.5.8 at runtime and print a sane error message instead of crashing ?

comment:11 by qyot27, 11 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.

in reply to:  11 comment:12 by Michael Niedermayer, 11 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

in reply to:  8 comment:13 by Trigunflame, 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)

Last edited 11 years ago by Trigunflame (previous) (diff)

comment:14 by qyot27, 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.

comment:15 by qyot27, 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 Michael Niedermayer, 11 years ago

Resolution: fixed
Status: openclosed

Fixed in 2c25e83b1d022ab36842d77749024b3d720a4227 by Stephen Hutchinson

in reply to:  15 comment:17 by Carl Eugen Hoyos, 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 qyot27, 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 Carl Eugen Hoyos, 11 years ago

Please consider sending patches (made with git format-patch) or set up a public git clone that can be merged.

in reply to:  20 comment:21 by Michael Niedermayer, 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

Note: See TracTickets for help on using tickets.