[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-Ji...ases/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?

[Jamaika]

You use file avs:

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

ffplay_avx2.exe file.avs

[filler56789]

Originally Posted by Jamaika

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/1f5y...ew?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]

Originally Posted by DTL

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 to both of you for the tests and insights. 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 ,
and this will take some time :-|

[StvG]

Here 32-bit version (2.1.2).

[filler56789]

Originally Posted by StvG

Here 32-bit version (2.1.2).

1) 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-Ji...esize.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-Ji...esize.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-res...Resizer.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 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/...e5#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.