Avisynth 2.5.8 MT

[Zep]

SetMTMode(2)

MPEG2Source("E:\R_O_T_K\VIDEO_TS\VTS_03_1.d2v")


is bad. MPEG2Source can really screw up and hang and slow down with it. you should move it above SetMTMode(2)
also adding ChangeFPS(last,last,true) right after MPEG2Source can many times increase speed since it sorta forces
it to cache/read ahead.

anyway what happened when you tried my version?

[Zep]

MT("""LsfMod(defaults="slow", preblur="on", kernel=19)""",2)

16 fps. It seems that MT() call gives faster results. Could you help me enter command for MT() so I can use LSFMOD for resizing also so I can ditch Spline36Resize step. Thanks for your response!

Odds are you will need to call LSFMOD twice and do what you did for spline. Me i would leave it how it is and not try to resize in LSFmod. I never use MT() anyway cause it can screw things up unless you have a lot of over lap (depends on the filters) which then slows it down so....

[zambelli]

SetMTMode(2)

MPEG2Source("E:\R_O_T_K\VIDEO_TS\VTS_03_1.d2v")


is bad. MPEG2Source can really screw up and hang and slow down with it. you should move it above SetMTMode(2)

Have you been able to find any MT mode that works with DGMPGDec? I think I tried all of them in both your x86 and JoshD's x64 mod and it'd always either crash right away or hang after several hundred frames.

BTW, it's interesting that http://avisynth.org/mediawiki/MT_support_page lists MPEG2Source() as being compatible with mode 1. Should that be updated? Or did something change between MT 2.5.7 and MT 2.5.8 that's breaking MPEG2Source?

also adding ChangeFPS(last,last,true) right after MPEG2Source can many times increase speed since it sorta forces
it to cache/read ahead.
Wow, I'll have to try that. So, you're suggesting:

MPEG2Source("foo.d2v")
ChangeFPS(last,last, true)
SetMTMode(2)
#other functions and filters
Is that right?

[Didée]

Almost. Dont forget to put SetMTmode(5) before the mpeg2source() call. (The first MTmode call defines the number of threads, and must appear before any kind of video frames are created. In case of doubt, put SetMTmode(5,<threads>) as the very 1st line in the script.)

Linguistical correction: "adding ChangeFPS ... can many times increase speed" sounds like it would give an X-fold speed turbo. Better let's formulate it like so: "adding ChangeFPS(last,last,true) right after XYZ-source() can increase speed in some cases. (YMMV)."

[Zep]

Have you been able to find any MT mode that works with DGMPGDec? I think I tried all of them in both your x86 and JoshD's x64 mod and it'd always either crash right away or hang after several hundred frames.

BTW, it's interesting that http://avisynth.org/mediawiki/MT_support_page lists MPEG2Source() as being compatible with mode 1. Should that be updated? Or did something change between MT 2.5.7 and MT 2.5.8 that's breaking MPEG2Source?


Wow, I'll have to try that. So, you're suggesting:

MPEG2Source("foo.d2v")
ChangeFPS(last,last, true)
SetMTMode(2)
#other functions and filters
Is that right?

DGMPGDec. no idea have not used it in ages :)

AS for MPEG2Source mode 3 works ok 80% of the time but the slight speed up IMHO is not worth the risk. 4 is slower than no MT. Lets face it any decent pc should be able to read frames in at 100FPS+ with a single non MT MPEG2Source so I just do not see the need/risk. I have never been able to get mode 1 to run more than a few seconds before it crashes

yeah that code is what i am suggesting. note though that you should always test and experiment. So many times moving a filter around in the chain has either sped up (or slowed it down lol) so much I always try a few versions and never just go with the first one.

and like Didee said add a setMTmode(5,whatever) at the start

[Zep]

Almost. Dont forget to put SetMTmode(5) before the mpeg2source() call. (The first MTmode call defines the number of threads, and must appear before any kind of video frames are created. In case of doubt, put SetMTmode(5,<threads>) as the very 1st line in the script.)

Linguistical correction: "adding ChangeFPS ... can many times increase speed" sounds like it would give an X-fold speed turbo. Better let's formulate it like so: "adding ChangeFPS(last,last,true) right after XYZ-source() can increase speed in some cases. (YMMV)."

i get good speed up on simple scripts doing that but none on more complex ones. What speed up it does do helps mostly just on 50+ FPS when random reads and decoding partial GOPS is happening quickly. The more complex stuff is so slow mpeg2source() has no problem keeping up without ChangeFPS(last,last,true)

[zambelli]

DGMPGDec. no idea have not used it in ages :)

AS for MPEG2Source mode 3 works ok 80% of the time but the slight speed up IMHO is not worth the risk.
But wait... DGMPGDec is MPEG2Source. DGMPGDec is the plugin and MPEG2Source is one of its functions.

Are we talking about 2 different versions of MPEG2Source?

and like Didee said add a setMTmode(5,whatever) at the start
That's the problem - it doesn't work for me. It hangs my app several hundred frames into it.

The only way I could ever get MPEG2Source() to work in a multithreaded script was to move any calls to SetMTMode() down below MPEG2Source.

[Gavino]

The only way I could ever get MPEG2Source() to work in a multithreaded script was to move any calls to SetMTMode() down below MPEG2Source.
As I understand it (not entirely sure), unless a SetMTMode appears before the first video-processing function in the script, you will get no multithreading at all.

[Zep]

But wait... DGMPGDec is MPEG2Source. DGMPGDec is the plugin and MPEG2Source is one of its functions.

Are we talking about 2 different versions of MPEG2Source?


That's the problem - it doesn't work for me. It hangs my app several hundred frames into it.

The only way I could ever get MPEG2Source() to work in a multithreaded script was to move any calls to SetMTMode() down below MPEG2Source.

I use the MPEG2Source that is in the DGDecode.dll which is part of DGIndex/DGDecode. IIRC that one via DGMPGDec is old old stuff. Do a search and refresh my/our memory :D

[zambelli]

I use the MPEG2Source that is in the DGDecode.dll which is part of DGIndex/DGDecode. IIRC that one via DGMPGDec is old old stuff. Do a search and refresh my/our memory :D
Its author Donald Graft still refers to the whole package as DGMPGDec. See here: http://neuron2.net/dgmpgdec/dgmpgdec.html

[Zep]

Its author Donald Graft still refers to the whole package as DGMPGDec. See here: http://neuron2.net/dgmpgdec/dgmpgdec.html

interesting he removed the bins. bummer

so you are using 1.5.8? Doesn't change much since mode 1 and 2 fails with it. (for me anyway) Mode 3 is the only mode i found worth trying but not enough speed up to risk using it in the long run IMHO.

[zambelli]

interesting he removed the bins. bummer
I believe it was in order to avoid potential legal trouble with MPEG-LA.

so you are using 1.5.8? Doesn't change much since mode 1 and 2 fails with it. (for me anyway) Mode 3 is the only mode i found worth trying but not enough speed up to risk using it in the long run IMHO.
Yeah, I'm using 1.5.8. I can't get any mode of it to work without crashing the process. The only way I can get past the crashing is by not calling SetMTMode() at all before MPEG2Source(), though some have said that just disables multithreading entirely so it might be just a red herring.

[Didée]

@Zep - What is that with mode 1, 2, 3 for mpeg2source? Are you trying to multithread the source filter itself? Usually the source filter is fast enough to just not care about it - for Mpeg-2, anyway! So mode 5 for the source filter, the other modes for video filters that come later.
If you're really going to run so ultrafast that the source filters matters, then I'd rather use ffms2 with its internal multithreading.

@zambelli - something seems not right on your side. I've not noticed any problems related to mpeg2source (DGDecode 1.5.8) when using SetMTmode. The occasional problem with other (processing) filters, but not mpeg2source.

[IanB]

Mode 5 is always recommended for source filters for formats that contain intra (B) frame encodings like mpeg2. With intra frame encoding the frames need to be decoded out of order, e.g With an IBBPBBPBBPB... mpeg 2 stream the decoder may decode frame 0 directly, but needs to decode frames 0 and 3 before it can decode frames 1 and 2. Similarly it cannot decode frame 3 without frame 0 or frame 6 without frame 3. And needs frames 3 and 6 to decode frames 4 and 5.

WIth modes 1, 2 and 3 graph splitting occurs and multiple instances of each filter are created. Each instance only processes a portion of the frames. This is an effective way to process frames in parallel on multiple cores, provided the filter has no context from the calculation of adjacent frames.

Intra frame source filters have a pant load of context from adjacent frames, so much so that in mode 2 all the instance end up needing to do all the work anyway, so you get no speed improvement, just hotter CPU cores.

With formats that are all I frames like huffyuv and DV there is no context between frames and mode 2 with a source filter in that case may well be beneficial.

[Hagbard23]

Thanks a lot IANB for your clarification...its something i wanted to know for a while...good explanation...

[Nephilis]

Stick with MT(".........",threads=?). A lot better than SetMTMode, which is problematic and incompatible with many filters

[SilaSurfer]

~Zep~

LoadPlugin("C:\Program Files\GordianKnot\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\MT.dll")
LoadPlugin("E:\R_O_T_K\ColorMatrix\ColorMatrix.dll")
LoadPlugin("E:\R_O_T_K\Mask\mt_masktools-25.dll")
LoadPlugin("E:\R_O_T_K\Removegrain\RemoveGrainSSE2.dll")
LoadPlugin("E:\R_O_T_K\Removegrain\RepairSSE2.dll")
Import("E:\R_O_T_K\Lsfmod.avsi")

SetMTMode(5)
SetMemoryMax(512)

MPEG2Source("E:\R_O_T_K\VIDEO_TS\VTS_03_1.d2v")
ChangeFPS(last,last,true)

SetMTMode(2)

Colormatrix()
crop(2,80,712,416)
LsfMod(defaults="slow", preblur="on", kernel=19,dest_x=720, dest_y=288)

Well tried it but it seems I'm getting "Thread Deadlock" in VirtualDub, when encoding it just hangs no matter where I put SetMTMode(5,0), before Source call or as the first line in the script. Probably LSFMOD not fully compatible. Why is MT() mode bad, it works faster on my system and the above mentioned problems don't occur.

[Zep]

@Zep - What is that with mode 1, 2, 3 for mpeg2source? Are you trying to multithread the source filter itself? Usually the source filter is fast enough to just not care about it - for Mpeg-2, anyway! So mode 5 for the source filter, the other modes for video filters that come later.
If you're really going to run so ultrafast that the source filters matters, then I'd rather use ffms2 with its internal multithreading.
.

not me zambelli is or was. Me I NEVER use anything other than mode 5 on mpeg2source. If you read a few posts back i mentioned that IMHO MT on it is not needed since any decent PC can do 100+ FPS with Mpeg2source.

ffms2 does not keep sync so be careful. Many times frame count does not match that of DGIndex etc... (for me anyway)

[Zep]

~Zep~



Well tried it but it seems I'm getting "Thread Deadlock" in VirtualDub, when encoding it just hangs no matter where I put SetMTMode(5,0), before Source call or as the first line in the script. Probably LSFMOD not fully compatible. Why is MT() mode bad, it works faster on my system and the above mentioned problems don't occur.

===========================================
I have never ever had a problem with this

SetMTMode(5)
SetMemoryMax(512)

MPEG2Source("E:\R_O_T_K\VIDEO_TS\VTS_03_1.d2v")
ChangeFPS(last,last,true)
===========================================

so test the below filters in mode 5 to see which one is causing the problem. then mode 3 it or leave it in mode 5


SetMTMode(2)

Colormatrix()
crop(2,80,712,416)


SetMTMode(5)
LsfMod(defaults="slow", preblur="on", kernel=19,dest_x=720, dest_y=288)
SetMTMode(2)

yes end with mode 2 cause for some reason it speeds everything up. In fact sometimes I need to add something after it just to trigger the speed up like

fadeout0(10)

[Zach]

Ignorant question, but that's why we ask questions: to remove ignorance. :)

Is this build fully backwards compatible with the official 2.5.8 build, i.e., will all my old scripts (and plug-ins) work "as is?"

Note: I understand that not everything is multi-thread friendly or capable, or, at the very least, will need a custom build plug-in with MT() functionality in mind. I am just asking if all my old single thread based plug-in and scripts will work with this "2.5.8 MT" build.

[lych_necross]

Ignorant question, but that's why we ask questions: to remove ignorance. :)

Is this build fully backwards compatible with the official 2.5.8 build, i.e., will all my old scripts (and plug-ins) work "as is?"

Note: I understand that not everything is multi-thread friendly or capable, or, at the very least, will need a custom build plug-in with MT() functionality in mind. I am just asking if all my old single thread based plug-in and scripts will work with this "2.5.8 MT" build.
Yes this build is fully backwards compatible with the official 2.5.8. If you do come across any problems, please post them in this thread so we can help. :)

[Zach]

If you do come across any problems, please post them in this thread so we can help. :)
Will do!

:thanks:

[XhmikosR]

That patch has been already applied in ffdshow's svn for quite some time now (r3358). Just FYI, the patches apply to source files and not binaries.

[rodgar]

Recently I noticed a recurring VirtualDub crash in connection with MT. I use FastDegrain() wich in my case only uses MVTools.
The Input Video is a segmentedAVI Capture via VD - ffdshow dv.

Here are 2 ErrorLogs from VD (Seems to be always the same problem):
VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
04dfa2c0: 0401 add al, 01h
04dfa2c2: 0f6e1411 movd mm2, [ecx+edx]
04dfa2c6: 0f60c7 punpcklbw mm0, mm7
04dfa2c9: 0f60d7 punpcklbw mm2, mm7
04dfa2cc: 0ff5c1 pmaddwd mm0, mm1
04dfa2cf: 0ff5da pmaddwd mm3, mm2
04dfa2d2: 0ffeeb paddd mm5, mm3
04dfa2d5: 0ffee0 paddd mm4, mm0
04dfa2d8: 83c608 add esi, 08h
04dfa2db: 83c104 add ecx, 04h
04dfa2de: 3b4c240c cmp ecx, [esp+0ch]
04dfa2e2: 72d3 jc 04dfa2b7
04dfa2e4: 01fe add esi, edi
04dfa2e6: 0f6fc4 movq mm0, mm4
04dfa2e9: 0f62e5 punpckldq mm4, mm5
04dfa2ec: 0f6ac5 punpckhdq mm0, mm5
04dfa2ef: 0ffee0 paddd mm4, mm0
04dfa2f2: 0f72e407 psrad mm4, 07h
04dfa2f6: 0f6be4 packssdw mm4, mm4
04dfa2f9: 8b442420 mov eax, [esp+20h]
04dfa2fd: 0f7e2418 movd [eax+ebx], mm4
04dfa301: 83c304 add ebx, 04h
04dfa304: 739a jnc 04dfa2a0
04dfa306: 8b5c2410 mov ebx, [esp+10h]
04dfa30a: 8b742414 mov esi, [esp+14h]
04dfa30e: 8b7c2418 mov edi, [esp+18h]
04dfa312: 83c41c add esp, 1ch
04dfa315: c3 ret
04dfa316: f7db neg ebx
04dfa318: 8b542438 mov edx, [esp+38h]
04dfa31c: 89f1 mov ecx, esi
04dfa31e: 8d041b lea eax, [ebx+ebx]
04dfa321: 8b742428 mov esi, [esp+28h]
04dfa325: 89c7 mov edi, eax
04dfa327: f7df neg edi
04dfa329: c1e303 shl ebx, 03h
04dfa32c: 01fa add edx, edi
04dfa32e: 29d9 sub ecx, ebx
04dfa330: 037c2420 add edi, [esp+20h]
04dfa334: 0fefff pxor mm7, mm7
04dfa337: 55 push ebp
04dfa338: 89c5 mov ebp, eax
04dfa33a: 8db600000000 lea esi, [esi+00]
04dfa340: 0fb7042a movzx eax, word ptr [edx+ebp]
04dfa344: 0fb75c2a02 movzx ebx, word ptr [edx+ebp+02h]
04dfa349: 0f6f0ca9 movq mm1, [ecx+ebp*4]
04dfa34d: 0f6f5ca908 movq mm3, [ecx+ebp*4+08h]
04dfa352: 0f6e0406 movd mm0, [esi+eax] <-- FAULT
04dfa356: 0f6e141e movd mm2, [esi+ebx]
04dfa35a: 0f60c7 punpcklbw mm0, mm7
04dfa35d: 0f60d7 punpcklbw mm2, mm7
04dfa360: 0ff5c1 pmaddwd mm0, mm1
04dfa363: 0ff5da pmaddwd mm3, mm2
04dfa366: 0f6fe0 movq mm4, mm0
04dfa369: 0f62c3 punpckldq mm0, mm3
04dfa36c: 0f6ae3 punpckhdq mm4, mm3
04dfa36f: 0ffec4 paddd mm0, mm4
04dfa372: 0f72e007 psrad mm0, 07h
04dfa376: 0f6bc0 packssdw mm0, mm0
04dfa379: 0f7e042f movd [edi+ebp], mm0
04dfa37d: 83c504 add ebp, 04h
04dfa380: 73be jnc 04dfa340
04dfa382: 5d pop ebp
04dfa383: 8b5c2410 mov ebx, [esp+10h]
04dfa387: 8b742414 mov esi, [esp+14h]
04dfa38b: 8b7c2418 mov edi, [esp+18h]
04dfa38f: 83c41c add esp, 1ch
04dfa392: c3 ret
04dfa393: f7db neg ebx
04dfa395: 8b542438 mov edx, [esp+38h]
04dfa399: 89f1 mov ecx, esi
04dfa39b: 8d041b lea eax, [ebx+ebx]
04dfa39e: 8b742428 mov esi, [esp+28h]
04dfa3a2: 89c7 mov edi, eax
04dfa3a4: f7df neg edi
04dfa3a6: c1e304 shl ebx, 04h
04dfa3a9: 01fa add edx, edi
04dfa3ab: 29d9 sub ecx, ebx
04dfa3ad: 037c2420 add edi, [esp+20h]
04dfa3b1: 0fefff pxor mm7, mm7
04dfa3b4: 55 push ebp
04dfa3b5: 89c5 mov ebp, eax
04dfa3b7: 89f6 mov esi, esi
04dfa3b9: 8dbc2700000000 lea edi, [edi+00]

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7601) [Service Pack 1]

EAX = 00000000
EBX = 00000000
ECX = 001efa20
EDX = 0219e1d0
EBP = fffffd30
ESI = 021a0048
EDI = 021e04f0
ESP = 3825fd2c
EIP = 04dfa352
EFLAGS = 00010206
FPUCW = 027f
FPUTW = 96aa

Crash reason: Access Violation

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

...reading address 021A0048.

Pointer dumps:

ECX 001efa20: 00000000 40000000 00000000 00000000 33797430 00000000 331bf236 0c001658
EDX 0219e1d0: 001e00b0 00000000 00000000 00000000 af13f2a2 08041756 02252060 0219ed18
EDI 021e04f0: 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040
ESP 3825fd28: 00000000 0000023b 000005a0 021e01a0 021e04f0 021e0ae0 022116a0 0000023b
3825fd48: 00000001 04e03d7c 021e0220 00000168 021a0048 000000b4 00008000 001eeee0
3825fd68: 0219df00 00000004 00000000 000002d0 00000168 00000000 00000000 00000000
3825fd88: 00000000 00000000 02206f28 00000000 021ec2e8 021a0048 0217ffc4 021e0810

Thread call stack:
04dfa352: ffmpeg!yadif_filter [04bd0000+219c50+10702]
7771e003: ntdll!RtlFreeHeap [776f0000+2df85+7e]
04e047e4: ffmpeg!yadif_filter [04bd0000+219c50+1ab94]
76651148: kernel32!WaitForSingleObject [76640000+11136+12]
04e12037: ffmpeg!sws_getContext [04bd0000+23a1e0+7e57]
7525a53a: msvcrt!_lock [75250000+a449+f1]
75261287: msvcrt!_itow_s [75250000+1123b+4c]
75261328: msvcrt!_endthreadex [75250000+112bc+6c]
766533ca: kernel32!BaseThreadInitThunk [76640000+133b8+12]
77729ed2: ntdll!RtlInitializeExceptionChain [776f0000+39e6f+63]
77729ea5: ntdll!RtlInitializeExceptionChain [776f0000+39e6f+36]

-- End of report


Second one:
VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
6d22a2c0: 0401 add al, 01h
6d22a2c2: 0f6e1411 movd mm2, [ecx+edx]
6d22a2c6: 0f60c7 punpcklbw mm0, mm7
6d22a2c9: 0f60d7 punpcklbw mm2, mm7
6d22a2cc: 0ff5c1 pmaddwd mm0, mm1
6d22a2cf: 0ff5da pmaddwd mm3, mm2
6d22a2d2: 0ffeeb paddd mm5, mm3
6d22a2d5: 0ffee0 paddd mm4, mm0
6d22a2d8: 83c608 add esi, 08h
6d22a2db: 83c104 add ecx, 04h
6d22a2de: 3b4c240c cmp ecx, [esp+0ch]
6d22a2e2: 72d3 jc 6d22a2b7
6d22a2e4: 01fe add esi, edi
6d22a2e6: 0f6fc4 movq mm0, mm4
6d22a2e9: 0f62e5 punpckldq mm4, mm5
6d22a2ec: 0f6ac5 punpckhdq mm0, mm5
6d22a2ef: 0ffee0 paddd mm4, mm0
6d22a2f2: 0f72e407 psrad mm4, 07h
6d22a2f6: 0f6be4 packssdw mm4, mm4
6d22a2f9: 8b442420 mov eax, [esp+20h]
6d22a2fd: 0f7e2418 movd [eax+ebx], mm4
6d22a301: 83c304 add ebx, 04h
6d22a304: 739a jnc 6d22a2a0
6d22a306: 8b5c2410 mov ebx, [esp+10h]
6d22a30a: 8b742414 mov esi, [esp+14h]
6d22a30e: 8b7c2418 mov edi, [esp+18h]
6d22a312: 83c41c add esp, 1ch
6d22a315: c3 ret
6d22a316: f7db neg ebx
6d22a318: 8b542438 mov edx, [esp+38h]
6d22a31c: 89f1 mov ecx, esi
6d22a31e: 8d041b lea eax, [ebx+ebx]
6d22a321: 8b742428 mov esi, [esp+28h]
6d22a325: 89c7 mov edi, eax
6d22a327: f7df neg edi
6d22a329: c1e303 shl ebx, 03h
6d22a32c: 01fa add edx, edi
6d22a32e: 29d9 sub ecx, ebx
6d22a330: 037c2420 add edi, [esp+20h]
6d22a334: 0fefff pxor mm7, mm7
6d22a337: 55 push ebp
6d22a338: 89c5 mov ebp, eax
6d22a33a: 8db600000000 lea esi, [esi+00]
6d22a340: 0fb7042a movzx eax, word ptr [edx+ebp]
6d22a344: 0fb75c2a02 movzx ebx, word ptr [edx+ebp+02h]
6d22a349: 0f6f0ca9 movq mm1, [ecx+ebp*4]
6d22a34d: 0f6f5ca908 movq mm3, [ecx+ebp*4+08h]
6d22a352: 0f6e0406 movd mm0, [esi+eax] <-- FAULT
6d22a356: 0f6e141e movd mm2, [esi+ebx]
6d22a35a: 0f60c7 punpcklbw mm0, mm7
6d22a35d: 0f60d7 punpcklbw mm2, mm7
6d22a360: 0ff5c1 pmaddwd mm0, mm1
6d22a363: 0ff5da pmaddwd mm3, mm2
6d22a366: 0f6fe0 movq mm4, mm0
6d22a369: 0f62c3 punpckldq mm0, mm3
6d22a36c: 0f6ae3 punpckhdq mm4, mm3
6d22a36f: 0ffec4 paddd mm0, mm4
6d22a372: 0f72e007 psrad mm0, 07h
6d22a376: 0f6bc0 packssdw mm0, mm0
6d22a379: 0f7e042f movd [edi+ebp], mm0
6d22a37d: 83c504 add ebp, 04h
6d22a380: 73be jnc 6d22a340
6d22a382: 5d pop ebp
6d22a383: 8b5c2410 mov ebx, [esp+10h]
6d22a387: 8b742414 mov esi, [esp+14h]
6d22a38b: 8b7c2418 mov edi, [esp+18h]
6d22a38f: 83c41c add esp, 1ch
6d22a392: c3 ret
6d22a393: f7db neg ebx
6d22a395: 8b542438 mov edx, [esp+38h]
6d22a399: 89f1 mov ecx, esi
6d22a39b: 8d041b lea eax, [ebx+ebx]
6d22a39e: 8b742428 mov esi, [esp+28h]
6d22a3a2: 89c7 mov edi, eax
6d22a3a4: f7df neg edi
6d22a3a6: c1e304 shl ebx, 04h
6d22a3a9: 01fa add edx, edi
6d22a3ab: 29d9 sub ecx, ebx
6d22a3ad: 037c2420 add edi, [esp+20h]
6d22a3b1: 0fefff pxor mm7, mm7
6d22a3b4: 55 push ebp
6d22a3b5: 89c5 mov ebp, eax
6d22a3b7: 89f6 mov esi, esi
6d22a3b9: 8dbc2700000000 lea edi, [edi+00]

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7601) [Service Pack 1]

EAX = 00000000
EBX = 00000000
ECX = 05070440
EDX = 007e9170
EBP = fffffd30
ESI = 04fc9068
EDI = 033741b0
ESP = 3e8efd2c
EIP = 6d22a352
EFLAGS = 00010202
FPUCW = 027f
FPUTW = 96aa

Crash reason: Access Violation

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

...reading address 04FC9068.

Pointer dumps:

ECX 05070440: 00000000 40000000 80808080 80808080 80808080 80808080 029a216f 0c1d125c
EDX 007e9170: 7a7d00b0 4bd7b630 cc37ff95 c975a951 809a21ed 0a001353 04fc6f10 025eea48
EDI 033741b0: 40404040 40404040 40404040 40404040 40404040 40404040 40404040 40404040
ESP 3e8efd28: 00000000 0000023b 000005a0 03373e60 033741b0 033747a0 03369fa0 0000023b
3e8efd48: 00000001 6d233d7c 03373ee0 00000168 04fc9068 000000b4 00008000 0506f900
3e8efd68: 007e8ea0 00000004 00000000 000002d0 00000168 00000000 00000000 00000000
3e8efd88: 00000000 00000000 0506f868 00000000 05054c28 04fc9068 04fab0a4 033744d0

Thread call stack:
6d22a352: ffmpeg!yadif_filter [6d000000+219c50+10702]
7746e003: ntdll!RtlFreeHeap [77440000+2df85+7e]
6d2347e4: ffmpeg!yadif_filter [6d000000+219c50+1ab94]
74ee1148: kernel32!WaitForSingleObject [74ed0000+11136+12]
6d242037: ffmpeg!sws_getContext [6d000000+23a1e0+7e57]
74b9a53a: msvcrt!_lock [74b90000+a449+f1]
74ba1287: msvcrt!_itow_s [74b90000+1123b+4c]
74ba1328: msvcrt!_endthreadex [74b90000+112bc+6c]
74ee33ca: kernel32!BaseThreadInitThunk [74ed0000+133b8+12]
77479ed2: ntdll!RtlInitializeExceptionChain [77440000+39e6f+63]
77479ea5: ntdll!RtlInitializeExceptionChain [77440000+39e6f+36]

-- End of report


And that's my AVS-Script (If I only delete fastdegrain(), everything goes well)
Import(".\Scripte\LimitedSharpenFaster.avs")
Import(".\Scripte\FastDegrain-ripped.avs")
Import(".\Scripte\FixChromaBleeding.avs")
SetMtMode(2,4)
SegmentedAVISource("video.avi")

ConverttoRGB()
trim(329, 75241)
ReverseFieldDominance()
ConvertToYV12()
FastDegrain()
separateFields()
crop(24,6,-24,-12)
LanczosResize(720,288)
FixChromaBleeding()
LimitedSharpenFaster(strength=145)
weave()

To complete this, here's FastDegrain() (it's only cutted down to what I need)
function FastDegrain(clip src)
{

super = src.MSuper(pel=1)
bvec2 = super.MAnalyse(isb=true, delta=2, blksize=8, overlap=4)
bvec1 = super.MAnalyse(isb=true, delta=1, blksize=8, overlap=4)
fvec1 = super.MAnalyse(isb=false, delta=1, blksize=8, overlap=4)
fvec2 = super.MAnalyse(isb=false, delta=2, blksize=8, overlap=4)

src = src.MDegrain1(super, bvec1, fvec1, limit=255)
src = src.MDegrain2(super, bvec1, fvec1, bvec2, fvec2, limit=255)

return src
}

[Gavino]

SetMtMode(2,4)
SegmentedAVISource("video.avi")

ConverttoRGB()

It's more reliable to use mode 5 for source filters.
Also, if your source is interlaced you need to tell ConvertToRGB:
SetMtMode(5,4)
SegmentedAVISource("video.avi")
SetMtMode(2)
ConverttoRGB(interlaced=true)
...

[Didée]

Though not related to the crashes, that script is full of issues.

- If the source is interlaced, FastDegrain shouldn't be applied like that. (Mocomp denoising is a temporal-spatial filter, and you know spatial is no good idea on interlaced footage).

- Also, cropping+resizing the fields individually is likely to cause some spatial field misalignment.

- In the stripped fastdegrain function, it seems like an additional msuper() clip should be created after the 1st, and be used in the 2nd mdegrain call. (It can be used like it is now, but the resulting effect probably is not the intended effect.)

[rodgar]

Good to know. Thanks a lot for the advice, both of you. :)

If the source is interlaced, FastDegrain shouldn't be applied like that. (Mocomp denoising is a temporal-spatial filter, and you know spatial is no good idea on interlaced footage).

I don't know much about all that, but before I used it on the Separated fields like suggested but this way it looks way better. Maybe because of the double of height during processing.

- In the stripped fastdegrain function, it seems like an additional msuper() clip should be created after the 1st, and be used in the 2nd mdegrain call. (It can be used like it is now, but the resulting effect probably is not the intended effect.)

That's right. It's if you set Degrain=3. But I use it as if Degrain would be 2, so I don't need this additional lines.

[kenpachi]

Guys, I need to ask You something. Is it hard to understand and get on with MultiThreading in AviSynth? I find it very difficult see difference in speed while using unofficial MT285 and this is why I'm puzzled a bit. Even when trying a simple example from here (http://avisynth.org/mediawiki/MT) not mentioning more complex scripts.

Let's take a script as below and encode it with x264 CQ20 High@4.1
SetMTMode(2,x)
src=AviSource("MT_test.avi") # 640x368
SetMTMode(5)
src=src.converttoyuy2().fft3dgpu
SetMTMode(2)
src.LimitedSharpenFaster()
Subtitle("Number of threads used: " + string(GetMTMode(true)) + \
" Current MT Mode: " + string(GetMTMode()))
Trim(62038,65395) # 3357frame sample
ConvertToYV12()


Results:
MT_test_noMT (*) - 6.67fps
MT_test_SetMTMode(2,0) - 6.54fps // 0 - default. Creates 2 threads
MT_test_SetMTMode(2,1) - 6.76fps
MT_test_SetMTMode(2,4) - 6.52fps

* noMT means I used official avisynth 2.5.8.5 x86 and commented all MT-related syntax.


Hardware:
Intel Core 2 Duo CPU T7250 @ 2.00GHz (with Hyper-Threading)
Software:
meGUI with up to date x264

1 thread = 2 threads? Does it make sense? Task Manager would give 100% to all the above choices.

[Didée]

Rule of thumb: when system load is 100%, then it is 100%. :)

Multithreading makes sense only when the Avisynth script is so slow that it becomes the bottleneck (i.e. when it can't produce frames fast enough for x264, so x264 has to wait for the next frame, and the next, and the next...)

In your case, the script is fast enough even single-threaded. Therefore, nothing to gain from multithreading.

That's probably because of the stamp-sized video. (Joke.) Seriously, 640x368 is so small a resolution, that "even" LSF can run fast enough.

Anyway, you should use SetMTmode(5, [threads] ) in the 1st line. Mode 2 is not generally safe for source filters (sometimes works, most often works not). Mode 5 should always be safe for the source filter.

[kenpachi]

Argh, I haven't even previewed the script. I picked it from the mentioned link as an example. Didn't even think about how fast the script was. But I got problems achieving speed ups with more complex ones. An example below.

I encoded it gaining only 0.06fps using MT285 vs. 0.23fps using official 285. I can't explain this. I don't remember what Task Manager said, will check it later. I usually encode with let's say 1.4fps. Now it's even more like 1.1 average but I don't want to get too low with speed on long sources. Sure thing, when I have a 2 minute trailer I can let myself get to 0.4, 0.2, but when it's 2hrs it would be insane to accept it.


SetMTMode(5, 4) # Choosed 4 threads as for HyperThreading 2x2=4

LoadCplugin(...)

MPEG2Source(...)
a = NicAC3Source(...)
BlankClip(...).KillAudio() + Trim(...) + BlankClip(...).KillAudio()
AudioDub(last, a)
Trim(0,0)

SetMTMode(2)
last.QTGMC(Preset="slow", FPSDivisor=2, EdiThreads=2)

Deblock_QED(...)

Crop(4, 2, -8, -2)

vectors = last.MVAnalyseMulti(...)
last.MVDegrainMulti(...) # JoseyWells mvtools

GradFunkMirror(...)
Lanczos4Resize(672, 544)

LimitedSharpenFaster(...)

SetMTMode(5)
GrainFactory3(...)

Trim(100, 200) # 101-frame sample


What's more I have a funny feeling it might be faster if I did it doing 2 separated scripts: the first would contain everything to Crop and the second one would perform degraining etc. to GrainFactory3. I've noticed my script needs about 1.5s for a frame to load when QTGMC and mvtools aren't enabled at the same time and it takes about 8s when they are. Even 1.5+1.5 what'd be too high isn't 8.

[Didée]

Your 2nd example is simply too complex, aka "system overload".

If you give me a 100kg cement bag that I must carry 100 meters, I'll do it in one minute.

If you give me one 200kg cement bag that I must carry 100 meters, I'll NOT do it in 2 minutes. Because I will break down on the way.

[SEt]

Source filters should be put in mode 3, not 5. It has less overhead and effect is the same for source filters.

If you want to combine some single-threaded initial processing with the rest of the script multithreaded - try putting first part in separate non-MTMode script that second part opens as AviSource("first_part.avs"). Avoid using mode 5.

Always put even empty brackets after function calls with MTMode Avisynth.

And the most important: do not use this Avisynth version - it has many threading bugs. Use builds of Avisynth 2.6 instead.

[sutha25]

can some one please share the Avisynth.DLL MT 2.5.8 i searched Google and couldn't find 1....Mediafire Link file removed

[turbojet]

http://www.mediafire.com/download/5n1iujf48l8dotg/avisynth-2.58mt.dll

2.6 MT and avs+ is much more stable for me.

[sutha25]

http://www.mediafire.com/download/5n1iujf48l8dotg/avisynth-2.58mt.dll

2.6 MT and avs+ is much more stable for me.

i tired that bro but still same is not like it use to be i use to get 100-125FPS and now iam getting 9-15FPS i haven't changed anything then the DLL

[turbojet]

You formatted, that's about the largest change you could do. The installer and that dll is the official build, no need to ask in 2 other places. What's your script?

[sutha25]

You formatted, that's about the largest change you could do. The installer and that dll is the official build, no need to ask in 2 other places. What's your script?

HI thanks for the reply where can i get the MT dll then?

SetMTMode(2)
LoadPlugin("C:\Users\Administrator\Documents\megui\tools\ffms\ffms2.dll")
FFVideoSource("D:\Downloads\Playground.mp4")
Crop(2, 88, -2, -88)
Spline36Resize(720,304)
fft3dfilter(sigma=1.0, bt=5, bw=32, bh=32, ow=16, oh=16, sharpen=0.4)
LSFmod( strength=75, smode=3, soothe=true, keep=20, edgemode=0, edgemaskHQ=false)
Tweak(Sat=1.15,Bright=5,cont=1.15)

please let me know where i can get the DLL mt edition so i can gain my speed agian

[turbojet]

http://www.mediafire.com/download/97w3y45d7atp3af/MT.dll but your script doesn't use it.

Are you opening the script with something other than x264?
You might need to add distributor() at the end.

It should be a pretty fast script. What cpu are using?

[sutha25]

http://www.mediafire.com/download/97w3y45d7atp3af/MT.dll but your script doesn't use it.

Are you opening the script with something other than x264?
You might need to add distributor() at the end.

It should be a pretty fast script. What cpu are using?

i need the MT AVISYNTH.dll iam opening the script with AVSpmod and then using megui to encode to AVI format from .MP4