MT 0.7(+custom avisynth)a filter to run filters multithreaded. Usefull for SMP or HT

[Adub]

Okay, well a short little preliminary test of the blank clip script on the single core led to nothing. I aborted it after 12.1%. Mostly because it crashed @ 12% on my dual core.

I will complete a full test on the single core, it will just take a long time. I have access to another dual core that I will test eventually, and see if I can isolate it further.

@TSP
Is there anything I can do to help you diagnose this better? Like send you the error report created by windows when it crashes?

I don't know if I mentioned this or not, but it crashes on Xvid as well. The weired thing about it is that the blank clip script doesn't crash (atleast, not that I remember), but it does crash on the Step Up script, so I am sure that it is not just x264's problem.

[squid_80]

Don't you have an E6600 overclocked to 3ghz? Maybe it's not as stable as you think it is.

[Adub]

Nope, its not the overclock for two reasons.

1) I just updated by bios and my clocks are now back to normal, so I tested to be sure, and it still crashed.

2) I just tested on a new core 2 duo build of mine, actually I built it for my mom, but it also crashes using the same exact filters/MeGUI setup/Avisynth setup.

Edit: I think that I found the problem!!!!!!!!

TSP, try running the blankclip encode using the new colormatrix 2.1. If I removed Colormatrix() from the script, it worked! So, I think that the new multithreaded version of Colormatrix is having issues with you multithreaded Avisynth.

[tsp]

merlin7777: Yes colormatrix 2.1 does crash very fast on my machine. setting threads to 1 in colormatrix seems to be more stable

[Adub]

So is this an official bug? Should I report it to tritical in the Colormatrix 2.1 thread? or should I just go along using "1" threads, even though according to the manual, that should be the default.

[webzeb]

Originally Posted by webzeb

Hello,

Is there any solution to use MT/SetMT for resizing (Spline36Resize) under FFDShow ?

SetMTMode seems not working (GetMTMode return '0')...

Thank you,

Fred

[Adub]

What kind of processor are you using?
Besides MT doesn't like resizing, and that is the one that you will want for realtime watching.
SetMTmode is better for encoding, unfortunately for you, it supports resizing but it wont usually speed up realtime watching significantly, at least it doesn't for me. That is why I use MT for realtime viewing.

[tsp]

webzeb: The problem is that ffdshow insert a source filter before the avisynth script so SetMtmode is never the first filter in the script. You can see it by removing the selection in "add ffdshow video source" checkbox in the avisynth option in ffdshow.

Merlin7777: Yes the bug is official. I don't know if it is triticals code or mine that are wrong (probably mine ). Also if threads is not specified the default value is the number of cores available according to the manual.

[webzeb]

Originally Posted by Merlin7777

What kind of processor are you using?
Besides MT doesn't like resizing, and that is the one that you will want for realtime watching.
SetMTmode is better for encoding, unfortunately for you, it supports resizing but it wont usually speed up realtime watching significantly, at least it doesn't for me. That is why I use MT for realtime viewing.

I use a Core 2 Duo E6300, overclocked @3.326Mhz.

I play HD (720p/1080p) stuff, resized to 1024*768px.
(I watch it on a 1024*768px plasma TV. )

Thank you for your answer,

Fred

[tsp]

It is possible to use a resizer with mt() (at least after I fixed a bug in mt.dll see first post) by first doing the vertical resize and afterwards the horizontal resize. Something like this:

src=avisource("c:\test.avi")
s.mt("spline36resize(1280,last.height())",splitvertical=false)
mt("spline36resize(last.width(),704)",splitvertical=true)

It produces the exact same result as spline36resize(1280,704) because avisynth internally split the resizer up into a seperate horizontal and vertical resize

[Terranigma]

Thanks for the new version tsp (0.6)

[BigDid]

Hi,

@TSP, many thanks from a young dualcore owner (still in test). Continue the good work.

Regarding speed some test results here http://forum.doom9.org/showthread.ph...439#post948439
or here http://forum.doom9.org/showthread.ph...322#post949322

Did

[webzeb]

Originally Posted by tsp

It is possible to use a resizer with mt() (at least after I fixed a bug in mt.dll see first post) by first doing the vertical resize and afterwards the horizontal resize. Something like this:

src=avisource("c:\test.avi")
s.mt("spline36resize(1280,last.height())",splitvertical=false)
mt("spline36resize(last.width(),704)",splitvertical=true)

It produces the exact same result as spline36resize(1280,704) because avisynth internally split the resizer up into a seperate horizontal and vertical resize

Many thanks !

[Adub]

Actually TSP you are wrong, the default is one thread at least it is supposed to be:

threads:

Sets the number of threads Colormatrix will use for processing. Can be any value greater than 0 and, for YUY2, less than the frame height, for YV12, less than the frame height divided by 2. If set to 0, ColorMatrix will automatically detect the number of available processors and set threads equal to that value.

default - 1 (int)

Yeah, and you are right about setting the threads to 1, is last just a little bit longer, but still crashes.

[tsp]

Merlin7777: yes threads=1 are the default must have seen the default value for thrdmthd. Can you reproduce the crash with version 2.0?

[Adub]

if you mean colormatrix 2.0, then no. On my preliminary tests with colormatrix 2.0 and the blankclip script, I couldn't get it to crash. It appears that the new multithreading in colormatrix is very skittish when pared with MT Avisynth.

[Jeremy Duncan]

tsp,

Is mt.dll version 0.5 different from mt.dll 0.6 ? Or is only the avisynth.dll different ?

[tsp]

Jeremy Duncan: MT 0.6 contains a new mt.dll (that fixes the bug with vertical resizing) and avisynth.dll(same the one from post #407)

[Jeremy Duncan]

Thank you.

[BlueCup]

Just throwing this out there, but is it possible this filter can put too much constant strain on the CPU/mobo and burn something out or cause damage somewhere? Let's say with a 12hr+ encode.