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

[filler56789]

Originally Posted by 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.

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.

[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-Ji...ent-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]

Originally Posted by DTL

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-Ji...ent-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.

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?

[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]

Originally Posted by DTL

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?

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

https://github.com/Asd-g/AviSynth-Ji...ases/tag/2.1.3

[Xuqiwu]

You can find 32-bit build here: https://github.com/Asd-g/AviSynth-Ji...ent-2608657460

If you not have found it yet.

[filler56789]

Originally Posted by Xuqiwu

You can find 32-bit build here: https://github.com/Asd-g/AviSynth-Ji...ent-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"
*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-Ji...ent-2612169256

[filler56789]

Originally Posted by DTL

One more test version with attempt to fix crashes - https://github.com/Asd-g/AviSynth-Ji...ent-2612169256

again.

Well, it SEEMS the problem with 2000x2000 is gone.
BUT the trouble with 3000x3000 remains.
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]

Originally Posted by DTL

Can you save and post VirtualDub crashinfo.txt file ?

Good idea.
Below is the content of crashinfo.txt.
The problem was, the "modern" 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