[SOLVED] Looking for an updated 32-bit JincResize DLL

[filler56789]

Sadly the developer released only the 64-bit binary there on GitHub.

https://github.com/Asd-g/AviSynth-JincResize/releases/tag/2.1.2

IF anybody has already compiled the 32-bit DLL of JincResize, please share it :)

[DTL]

If it uses non-compatible with 32bit asm/intrinsics it is not very easy. Also Asd-g drop support for 32bit binaries some time ago as I understand for all projects.

[Jamaika]

https://www.sendspace.com/file/b48gkg

Only JincResize works.
AviSource("input_yuv420p.avi", audio=false)
JincResize(1920, 1080)

Avisynth function: Jinc36Resize [1920, 1080]
Assertion failed: IsArray() && index>=0 && index<array_size, file interface.cpp, line 871

[filler56789]

ffmpeg_avx2.zip

File Size: 146.56MB

Are you sure you uploaded the right file? :D

[Jamaika]

You use file avs:

AviSource("input_yuv420p.avi", audio=false)
JincResize(1920, 1080)
ffplay_avx2.exe file.avs

[filler56789]

You use file avs:

AviSource("input_yuv420p.avi", audio=false)
JincResize(1920, 1080)
ffplay_avx2.exe file.avs

Well, ffmpeg /ffplay /ffprobe .EXE is not the same as JincResize.DLL.

[Jamaika]

That's true. I already have it in ffplay. You don't need to add JincResize.DLL. I did it as test.

[DTL]

You can try this build (with VS2019) - https://drive.google.com/file/d/1f5yOWuiGlGb2NHNsIWaZy4QTWh22wvh9/view?usp=sharing .

Looks like something not very nice :


LoadPlugin("JincResize.dll")

ColorBarsHD()
JincResize(200,200)


Is working. But some larger size like 2000,2000 throws error "Evaluate: Unhandled C++ Exception (line 4)". May be something is not very good with build environment settings or C++ settings. Do not have many experience where to look at.

Also may depend on AVS version and MSVC redistributable installed and so on ?

Debug buid do not break in VS2019 debugger and only shows same error messagebox. The output log is

Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0019E788.
Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.
Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: AvisynthError at memory location 0x0019DE98.
Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: AvisynthError at memory location 0x0019D59C.
The thread 0x1978 has exited with code 0 (0x0).
The thread 0x20a4 has exited with code 0 (0x0).
The thread 0x20bc has exited with code 0 (0x0).
The thread 0x1c4 has exited with code 0 (0x0).
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\msvcp140_2d.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\msvcp140d.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\msvcp140d_atomic_wait.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\vcruntime140d.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\ucrtbased.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\CPP\AviSynth-JincResize-2.1.2\AviSynth-JincResize-2.1.2\msvc\Debug\JincResize.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\quartz.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9672_none_d08f9da24428a513\msvcp80.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9672_none_d08f9da24428a513\msvcr80.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Windows\SysWOW64\DevIL.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll'
'VirtualDub.exe' (Win32): Unloaded 'C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll'
Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: MyError at memory location 0x0019F6A8.
Exception thrown at 0x77480B82 in VirtualDub.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.


Do not have more ideas what to do more. May be sources uses some not very friendly memory allocations in 32bit mode and it causes some memory corruption and complex errors.

Stackoverflow version: std::bad_alloc is commonly thrown when the program doesn't have enough memory to complete the requested action. May be in 32bit mode simply frame size of 2000,2000 already requies too large internal LUT for the used 2D resampling algorithm so this frame size already too large for 32bit memory mode. As I remember that 2D resampling algoriphm used creates very large LUT in RAM. And it may greatly depends on frame size and resample ratio.

[Jamaika]

But some larger size like 2000,2000 throws error "Evaluate: Unhandled C++ Exception (line 4)". May be something is not very good with build environment settings or C++ settings. Do not have many experience where to look at.
I don't have problem with 4K or 2000x2000 in win64.

[DTL]

As was expected if 32bit by Asd-g build is not provided - some issues may happen with MSVC or other compilers builds and too few experienced developers left to try to debug and this (if possible). As I understand, Asd-g does not like to support old 32bit systems in 2025 and later. Maybe ask pinterf to make a fork and provide 32bit proper builds ?

Can you try to build plugin .dll file with your build tools ?

[filler56789]

Many :thanks: to both of you for the tests and insights. :goodpost:s

I myself will try to build a 32-bit DLL with MSYS2

— but only after (re-)"installing" my previous Core2-Quad build environment on my Skylake :o ,
and this will take some time :-|

[StvG]

Here (https://filebin.net/bf15r98bq61x8oa8) 32-bit version (2.1.2).

[filler56789]

Here (https://filebin.net/bf15r98bq61x8oa8) 32-bit version (2.1.2).

1) Thanks! :thanks:

2) Just confirming what DTL and Jamaika had already said,
this 32-bit DLL really does not work as it should :-/

For both upscaling and downscaling,
Jinc144 and Jinc256 always return:
Avisynth open failure:
Evaluate: Unhandled C++ exception!

As for Jinc, Jinc36 and Jinc64, they work only if the new resolution is equal-to or less-than 2048x1152,
otherwise, they also return the error message mentioned above.
🤔

[DTL]

Possible solution - cut frame to tiles and use resize of each tile in a separate filter call and StackHorizontal/StackVertical to get full size output. If resizer make a good job at the processing of edges - the combined result expected to look same as full size processing at a single call.

If processing of edges is not perfect - next solution is to process some padded size of input frames to resizer and cut (scaled) padding before stacking output.

[DTL]

As expected the C++ runtime at 32bit mode crashes at time of generating full-frame coefs table at function
generate_coeff_table_c() https://github.com/Asd-g/AviSynth-JincResize/blob/82a3f5ee050cf377e73e364021c8a18ccec84254/src/JincResize.cpp#L319

For 2000x2000 output frame size: const int coeff_per_pixel = 112 (bytes)
and std::bad_alloc crash at
tmp_array.reserve(static_cast<int64_t>(dst_width) * dst_height * coeff_per_pixel);
https://github.com/Asd-g/AviSynth-JincResize/blob/82a3f5ee050cf377e73e364021c8a18ccec84254/src/JincResize.cpp#L349
where 2000*2000*112 = about 448 MB attempt to allocate+reserve at 32bit process and its fail. Looks like not enough contigous virtual address space left in that 32bit process total address space (and Windows memory manager too lazy to make defragmentation if it even possible).

In 64bit virtual memory address mode there are much larger areas of contigous virtual address space blocks available and this issue sort of never happen (while also possible).

[filler56789]

@DTL:

Thanks (again) for the (possible) workarounds.
Today I also tested version 2.1.0 and it has the same problems as version 2.1.2. Now I understand, it's really no surprise that Asd-g stopped releasing 32-bit builds of the DLL :-/
Some minutes ago, I tested the ancient version r44, and noticed that it too has issues: for example, Jinc256 crashes at attempting to downsize to 1280x720, whereas Jinc144 works normally 0_o

Anyway: all these limitations should have been very-well DOCUMENTED.
But they remain undocumented, and this actually suxxx :-/
Not a word about them neither in the wikis, nor in the ReadMes. *THUMBS DOWN*

[DTL]

There are also some more old versions for AVS - https://github.com/AviSynth/jinc-resize/tree/master . As I see they are constantly growing in size of the std::vector object instead of attempting to reserve all memory at a single call before filling this structure. Though at the end of function the tmp_array is copied to a simple memory block to use in resamplers without that std:vector C++ object. Though the requested memory pointer by aligned _malloc
https://github.com/AviSynth/jinc-resize/blob/0cd502acb17f0e1cc410d2448b8f54d628f7050e/JincResize/EWAResizer.h#L236
also not checked for validity (may also crash if OS can not allocate same sized buffer one more time).

If tmp_array exists only as a local object to function - the function anyway needs 2 same sized contiguous memory allocations at the end. While tmp_array is destroyed at the function exit (?). It may be even less probable at the tight 32bit process.

Sad for the plugin is timing of load process - the first are created AVS environment and calling application and plugin init performed at the later time when virtual memory of the process may be already significantly fragmented. So typically available only about 1/10 of possible for 32bit process 2 or 3 GB of RAM for single block allocation.

If coefficients are stored for single output sample calculation and for SIMD it is enough to load several coefficients for output line computing - maybe possible to split one full-frame coefficients buffer to array of buffers for each output line and it will relax memory addressing requirement at least up to several times for 32bit builds. But this also requires redesign of both coefs generation function and all resamplers (C and SIMD).

If we have not (very quickly) dying white civilization it is nice to have as a progress to build-in 2D resample engine to AVS core (or at least to all other resize plugins like fmtc and z_convertformat) with same family of 2D resize kernels (EWA-jinc as jinc weighted by jinc, and all classic other kernels turned in 2D - like Gauss/Bilinear/Bicubic and more complex like SinPow and UserDefined2). Because JincResize is not any unique engine but only 2D resampler engine with 1 of many possible kernels used. About all other AVS resamples use dual-pass H+V 1D resample engines and that make some different output (depending on kernel and source and scale ratio).

As I found some time ago - the Airy disc of diffraction-limited optics also is shaped as jinc function (bessel_j1(arg)/arg) https://en.wikipedia.org/wiki/Airy_disk so usage of this kernel (and also 2D resampler) may produce more natural results to real physical optics 'downscaling' in physical optical camera lens.

[filler56789]

Today I gave 2 cents to Asd-g. :)

https://github.com/Asd-g/AviSynth-JincResize/issues/10

[filler56789]

UPDATE

Asd-g released a fixed :cool: 32-bit DLL.
According to DTL, it doesn't work under Windows 7,
it requires Windows 8.1 or higher.
Now all that we need is to compile it as a C plugin.

Download from:

https://forum.videohelp.com/threads/237819-Test-for-you/page5#post2764461

[DTL]

At first that build requires some C++ redistributable .dlls for Win7. And with very small test it end with a crash at attempt to JincResize(2000,2000) of the ColorBarsHD() source. The crash is simple memory access violation exception at SIMD processing. Directly after (latest ?) C++ redistributables from Microfost site install (without reboot). May be reboot can help - I do not have a time for long tests.

As I see from the uploaded sources to github - main changes are
1. Attempt of memory pre-allocation with tmp_array.reserve is removed. Version 2.1.2 cause C++ exception here is there were not enough RAM in OS + C++ library. But old versions of JincResize also do not use this pre-allocation and use constantly growing vector class as in the latest build.

2. The catch of C++ exception in the generate_coefs() function added with throwing error about not enough memory (but may be other error reasons in theory).

1 and 2 do not add any visible optimizations or direct reasons of access viloation crash.

I think in the temporal build for testing may be other optimizations for low-RAM use cases.

[filler56789]

At first that build requires some C++ redistributable .dlls for Win7. And with very small test it end with a crash at attempt to JincResize(2000,2000) of the ColorBarsHD() source.

It seems Asd-g's JincResize has a problem with ColorBarsHD().
Next time please run your tests with a simple BlankClip(), or even better, with a "REAL-WORLD" video file.

UPDATE: The problem is not in ColorBarsHD() itself or its default colorspace YV24, it's the "preferred resizing dimensions" chosen by DTL (2000x2000)
— for some obscure reason, JincResize does not like them sometimes. :confused:

[DTL]

Random crashes with memory access violation are strange and harder to debug (longer time to reproduce at least to see what happen with addresses and attempt to understand where is it come from). If it somehow around internal multithreading - try to set threads=1 to disable internal multithreading and look if the crash still happen (at some runs).

Addition: Testbuild of x86 version with about 3x lower RAM usage for 4:4:4 and RGB formats added https://github.com/Asd-g/AviSynth-JincResize/issues/10#issuecomment-2603071285 . Though it runs with Jinc256Resize(3200,2000) from AVSmeter with only about 600 MiB RAM usage - attempt to open same script in VirtualDub still fail with memory allocation (formatted) error.

[filler56789]

Addition: Testbuild of x86 version with about 3x lower RAM usage for 4:4:4 and RGB formats added https://github.com/Asd-g/AviSynth-JincResize/issues/10#issuecomment-2603071285 . Though it runs with Jinc256Resize(3200,2000) from AVSmeter with only about 600 MiB RAM usage - attempt to open same script in VirtualDub still fail with memory allocation (formatted) error.

:thanks:

Okay, here we go again.

1) SCRIPT

LoadPlugin("C:\AVSplugins32\JincResize-LAST02.dll")
ColorBarsHD()
KillAudio()

2) TESTS AND RESULTS

Jinc256Resize(3840,2160) ##### OK

Jinc256Resize(640,360) #### OK

Jinc256Resize(2000,2000) #JincResize: failed to allocate memory for coefficient buffer.

Jinc144Resize(1000,1000) # OK

Jinc256Resize(1000,1000) # OK

Jinc256Resize(3000,3000) #VirtualDub crashes

Jinc256Resize(4000,2250) #OK

Jinc256Resize(1600,1600) #OK

Jinc256Resize(2400,2400) #OK

Jinc256Resize(8000,4500) #JincResize: failed to allocate memory for coefficient buffer.

JincResize(8000,4500) #Opens OK, but VirtualDub crashes during playback.

Jinc36Resize(8000,4500) #Opens OK, but VirtualDub crashes during playback.

Jinc64Resize(8000,4500) #VirtualDub crashed

Jinc144Resize(8000,4500) #JincResize: failed to allocate memory for coefficient buffer.

Now please tell us,
¿what is so special in the video resolution 2000x2000?
¿Does Asd-g's JincResize dislike it by design? :confused:

[DTL]

"JincResize(8000,4500) #Opens OK, but VirtualDub crashes during playback.
Jinc36Resize(8000,4500) #Opens OK, but VirtualDub crashes during playback."

Thank you. This is more easy way to finally catch the crash in the debugger and start looking what is wrong. Crash after OK loading (processing) of some frames is more strange because addresses/memory allocations are not changes at GetFrame() and sort of nothing changes. Only random come from threads switching (multithreading and normal threads switch).

When you got crash at playback - at the first frames or after some 100..1000+ ? The 8000x4500 runs very slow at my old CPU but still can not got crash at playback (about 20 frames tested).

[filler56789]

When you got crash at playback - at the first frames or after some 100..1000+ ? The 8000x4500 runs very slow at my old CPU but still can not got crash at playback (about 20 frames tested).

After just 2, 3, 4 OR 5 frames.

Still, you haven't answered my last question.
¿WHY Jinc256Resize happily accepts 4000x2250 OR 3840x2160 BUT "fails to allocate memory" for 2000x2000? :confused:

4000x2250 > 2000x2000;
3840x2160 > 2000x2000;

[DTL]

"WHY Jinc256Resize happily accepts 4000x2250 OR 3840x2160 BUT "fails to allocate memory" for 2000x2000? "

Do not have ideas now. My latest tests is that Jinc144Resize(3000,3000) about stable crash in release build at opening in VirtualDub and no one time crash in debug build and with some frames resize in 'playback' in VirtualDub when running from VS debugger. Sad - can not easy catch the crash in the debugger. The release build even with debug info with optimizations enabled not very good match the source. So the debug of some annoying crashes may take many time.

[filler56789]

JincResize v2.1.3 has been released!

The problem, of course, is Asd-g still is too lazy to build a 32-bit DLL :mad: :p

https://github.com/Asd-g/AviSynth-JincResize/releases/tag/2.1.3

[Xuqiwu]

You can find 32-bit build here: https://github.com/Asd-g/AviSynth-JincResize/issues/16#issuecomment-2608657460

If you not have found it yet.

[filler56789]

You can find 32-bit build here: https://github.com/Asd-g/AviSynth-JincResize/issues/16#issuecomment-2608657460

If you not have found it yet.

1) Thanks for the URL.

2) Still, that is no excuse for a) not including the DLL in the "official" archive and b) keep saying the 32-bit edition is "unsupported" :rolleyes:
*Not recommended*, OK, I agree with this.
But "unsupported", this makes no sense.
Because after all, it was because the 32-bit DLL was compiled and tested that both DTL and Asd-g could make the source-code less-inefficient ;)

[DTL]

32bit version still very frequently crashes at attempt to run simple script

LoadPlugin("JincResize.dll")
ColorBarsHD()
Jinc256Resize(3000,3000)

And I think 'unsupported' means Asd-g does not like to search why these (non-repeatable in a sequence) crashes happen in release 32bit build. So it may left as 'hanging issue' for unknown time (or simply ignored after 32bit machines will die in the past completely).

[DTL]

One more test version with attempt to fix crashes - https://github.com/Asd-g/AviSynth-JincResize/issues/16#issuecomment-2612169256

[filler56789]

One more test version with attempt to fix crashes - https://github.com/Asd-g/AviSynth-JincResize/issues/16#issuecomment-2612169256

:thanks: again.

Well, it SEEMS the problem with 2000x2000 is gone. :)
BUT :rolleyes: the trouble with 3000x3000 remains. :D
And it remains as "illogical" as before.
I mean, Jinc256Resize(4096,2304) opens fine and plays fine,
whereas Jinc256Resize(3000,3000) still makes VirtualDub crash,
—even though 3000x3000 < 4096x2304. 🤔

[DTL]

Can you save and post VirtualDub crashinfo.txt file ?

[filler56789]

Can you save and post VirtualDub crashinfo.txt file ?

Good idea.
Below is the content of crashinfo.txt.
The problem was, the "modern" :rolleyes: versions of Windows are exceedingly meddlesome and love to get in the way
(I mean, I had to find a way to fool the annoying "VirtualDub has stopped working" pop-up generated by the operating system itself).

VirtualDub crash report -- build 35491 (release)
--------------------------------------

Disassembly:
733f6e40: 0f8e0e010000 jle 733f6f54
733f6e46: 8b4610 mov eax, [esi+10h]
733f6e49: c5d0 lds edx, eax
733f6e4b: 57 push edi
733f6e4c: ed in eax, dx
733f6e4d: c5d9 lds ebx, ecx
733f6e4f: ef out dx, eax
733f6e50: e48b in al, 8bh
733f6e52: 088b4618894c or [ebx+4c891846], cl
733f6e58: 240c and al, 0ch
733f6e5a: 8b38 mov edi, [eax]
733f6e5c: 8b4614 mov eax, [esi+14h]
733f6e5f: 897c2420 mov [esp+20h], edi
733f6e63: 8b30 mov esi, [eax]
733f6e65: 8b44241c mov eax, [esp+1ch]
733f6e69: 0fafc2 imul eax, edx
733f6e6c: 8974242c mov [esp+2ch], esi
733f6e70: 8d0440 lea eax, [eax+eax*2]
733f6e73: c1e002 shl eax, 02h
733f6e76: 89442418 mov [esp+18h], eax
733f6e7a: 660f db 0fh
733f6e7c: 1f pop ds
733f6e7d: 44 inc esp
733f6e7e: 0000 add [eax], al
733f6e80: 8b4904 mov ecx, [ecx+04h]
733f6e83: c5fc lds edi, esp
733f6e85: 10dd adc ch, bl
733f6e87: 8b540104 mov edx, [ecx+eax+04h]
733f6e8b: 0fafd7 imul edx, edi
733f6e8e: 031401 add edx, [ecx+eax]
733f6e91: 8b4c0108 mov ecx, [ecx+eax+08h]
733f6e95: 03d6 add edx, esi
733f6e97: 8b44240c mov eax, [esp+0ch]
733f6e9b: 8b00 mov eax, [eax]
733f6e9d: 8d3488 lea esi, [eax+ecx*4]
733f6ea0: 8b4c240c mov ecx, [esp+0ch]
733f6ea4: 8b790c mov edi, [ecx+0ch]
733f6ea7: 85ff test edi, edi
733f6ea9: 7e59 jle 733f6f04
733f6eab: 8b4110 mov eax, [ecx+10h]
733f6eae: c1e002 shl eax, 02h
733f6eb1: 89442424 mov [esp+24h], eax
733f6eb5: 897c2410 mov [esp+10h], edi
733f6eb9: 0f db 0fh
733f6eba: 1f pop ds
733f6ebb: 800000 add byte ptr [eax], 00h
733f6ebe: 0000 add [eax], al
733f6ec0: 33c0 xor eax, eax
733f6ec2: 8bce mov ecx, esi
733f6ec4: 0f db 0fh
733f6ec5: 1f pop ds
733f6ec6: 40 inc eax
733f6ec7: 000f add [edi], cl
733f6ec9: 1f pop ds
733f6eca: 8400 test [eax], al
733f6ecc: 0000 add [eax], al
733f6ece: 0000 add [eax], al
733f6ed0: c4e2 les esp, edx
733f6ed2: 7d31 jge 733f6f05
733f6ed4: 0410 add al, 10h
733f6ed6: c5fc lds edi, esp
733f6ed8: 10d3 adc bl, dl
733f6eda: c5fc lds edi, esp
733f6edc: 5b pop ebx
733f6edd: d8c4 fadd st, st(4)
733f6edf: e26d loop 733f6f4e
733f6ee1: 98 cwde
733f6ee2: 1983c0088d49 sbb [ebx+498d08c0], eax
733f6ee8: 20c5 and ch, al
733f6eea: fc cld
733f6eeb: 10c3 adc bl, al
733f6eed: 3bc7 cmp eax, edi
733f6eef: 7cdf jl 733f6ed0
733f6ef1: 03742424 add esi, [esp+24h]
733f6ef5: 03542420 add edx, [esp+20h]
733f6ef9: 836c241001 sub dword ptr [esp+10h], 01h
733f6efe: 75c0 jnz 733f6ec0
733f6f00: 8b4c240c mov ecx, [esp+0ch]
733f6f04: 8b542414 mov edx, [esp+14h]
733f6f08: 8b742428 mov esi, [esp+28h]
733f6f0c: 8b7c2420 mov edi, [esp+20h]
733f6f10: c4e3 les esp, ebx
733f6f12: 7d19 jge 733f6f2d
733f6f14: d801 fadd dword ptr [ecx]
733f6f16: c5f8 lds edi, eax
733f6f18: 58 pop eax
733f6f19: c3 ret
733f6f1a: c5fb lds edi, ebx
733f6f1c: 7cc0 jl 733f6ede
733f6f1e: c5fb lds edi, ebx
733f6f20: 7cc0 jl 733f6ee2
733f6f22: c5f9 lds edi, ecx
733f6f24: 5b pop ebx
733f6f25: c0c4e2 rol ah, 0e2h
733f6f28: 792b jns 733f6f55
733f6f2a: c4c5 les eax, ebp
733f6f2c: f9 stc
733f6f2d: 67c4c5 les eax, ebp
733f6f30: f9 stc
733f6f31: 7ec0 jle 733f6ef3
733f6f33: 880432 mov [edx+esi], al
733f6f36: 42 inc edx
733f6f37: 8b442418 mov eax, [esp+18h]
733f6f3b: 8b74242c mov esi, [esp+2ch]
733f6f3f: 83 db 83h

Built on Althena on Sun Oct 27 15:59:07 2013 using compiler version 1400

Windows 6.3 (Windows 7 x64 build 9600) []
Memory status: virtual free 1667M/2048M, commit limit 10125M, physical total 8077M

EAX = 00000000
EBX = 008dce00
ECX = 0d46c000
EDX = 04735ed5
EBP = 0f18fd8c
ESI = 0d46c000
EDI = 00000011
ESP = 0f18fd58
EIP = 733f6ede
EFLAGS = 00010246
FPUCW = 027f
FPUTW = ffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'JincResize'...

...reading address 0D46C000.

Pointer dumps:

EBX 008dce00: 00000060 00000061 00000062 00000063 00000064 00000065 00000066 00000067
EDX 04735ed1: 68686868 68686868 68686868 68686868 68686868 68686868 68686868 68686868
ESP 0f18fd58: 008dcdd4 0018f4c0 0f18fe2c 00888cb8 0000000b 00000045 002eb45c 00000bb8
0f18fd78: 00000540 00000080 11ccf700 04730040 00000001 0f18fda8 733f92e9 00000055
0f18fd98: 0086faf0 733f9420 0b110f58 0018f468 0f18fde8 733f9429 77253677 0f18fe2c
0f18fdb8: 0018f468 0086faf0 0080b830 0086fb50 77253540 00000000 0b110f58 00000000
EBP 0f18fd88: 00000001 0f18fda8 733f92e9 00000055 0086faf0 733f9420 0b110f58 0018f468
0f18fda8: 0f18fde8 733f9429 77253677 0f18fe2c 0018f468 0086faf0 0080b830 0086fb50
0f18fdc8: 77253540 00000000 0b110f58 00000000 0086faf0 0b110f28 00000018 26b7ab76
0f18fde8: 0f18ff80 77250e61 0f18fe2c 0086fb50 26b7a93a 77244870 77244870 0080b830

Thread call stack:
733f6ede: JincResize!_avisynth_c_plugin_init@4 [733f0000+3860+367e]
733f92e9: JincResize!_avisynth_c_plugin_init@4 [733f0000+3860+5a89]
733f9429: JincResize!_avi

[DTL]

Try new build - https://github.com/Asd-g/AviSynth-JincResize/issues/16#issuecomment-2624888094 it expect to handle second way to crash as AVS error message if OS can not allocate enough RAM for coefs buf too.

[DTL]

Test also x86 build with FP16 mode of resampling program storage - it uses 2 times less RAM. Also for equal sized planes formats (RGB(A), YUV444(4)) only 1 piece of resampling program used and it is lowest RAM requirements mode.

https://github.com/DTL2020/JincResizeMT/releases/tag/post1.1.0_t02