MVTools without idx

[AVIL]

Problem of yuy2 fixed in 2.2.2. Planar form distorted images was my faulty.

About the name of the dll, I actually rename the dll of version 2 to mvtools2. I retain the dll of mvtools version 1 with original name. So i can use old scripts without changes. New scripts don't merge both version of mvtools.

[Fizick]

Well, may be next (or even this!) version will be mvtool2.dll.
But I wonder how do you use old scripts "without changes", probably you use explicit loadPlugin command.

About scene changes. It is not trivial.
For example, most difficult is not true scene changes, but some flashes and fading.
So, we have at least two frames with big SADs.

[thetoof]

Maybe it's silly, but for the flashing/fading scenes... could the scene change threshold rely more on chroma, since it is a lot more stable than luma for those sections?

[Fizick]

thetoof,
it is interesting note. But how to use this fact?
As I wrote above, we do not need in perfect (true) scene detection.
We need in scene detection with minimal artefactes. So, flashes must be detected as scenechange (especially for MVFlowFps).



EDIT: I re-uploaded version v2.2.2 with mvtools2.dll inside.

[Delerue]

I discovered a weird bug with MVTools + Avisynth MT + FFDShow + MPC-HC. With my dual-core CPU using more than 3 threads in the script below cause some stutter.


setMTMode(2,3)
source=ffdshow_source()
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll")
super = source.MVSuper(pel=1)
backward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = true, search=3, searchparam=5)
forward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = false, search=3, searchparam=5)
source.MVFlowFps(super, backward_vec, ThSCD1=350, blend=false, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
distributor()


You can try this sample (http://www.zshare.net/video/52136102c2e1c667/) to see. Set, for example, 5 threads ('setMTMode(2,5)'), use MPC and hit the RIGHT_ARROW (to advance frame by frame) until you reach a scene change. You'll notice that in the new scene the car moves some frames, then it 'stops' for a while, and then it continues to move again (in fact what happens is a wrong frame repetition). With 3 threads this bug doesn't occour. Also, this bug disappear if you do any seek in the video. Note that with 'blend=false' parameter it's normal that the last frame of a scene repeats; there's no way to avoid this. The problem I'm talking about is the frame repetition in the beginning of a scene.

Can anyone confirm?

[LaTo]

Search=2 (diamond) is slower than search=4 (hexagon) in my test... but I thought that hexagon is better than diamond.

2 possibilities:
- I was wrong (diamond is better than hexagon)
- Hexagon is very optimized

Which one? :D

Thanks!

[Sagekilla]

More likely case 2. If the searches are anything like the --me dia or --me hex in x264, hex should be better than diamond.

[Fizick]

it was discussed
http://forum.doom9.org/showthread.php?p=1152489#post1152489

but there is no simple answer.
implementations are differ, especially for diamond.

[Shon]

http://rapidshare.com/files/169736254/Matrix2.avi.html
This heartrending experience for mvtools2 to what can write a script for this segment?

[Adub]

...
What?

[Shon]

In it video many the difficult moments, are a lot of movement.
To what needs to write a script that became less artefacts?
http://rapidshare.com/files/169736254/Matrix2.avi.html

[Naito]

About the name of the dll, I actually rename the dll of version 2 to mvtools2. I retain the dll of mvtools version 1 with original name. So i can use old scripts without changes. New scripts don't merge both version of mvtools.
I do the same. That's why I suggested the new naming. ;)
And I use explicit "LoadPlugin()" for the Plugins from a separate Plugin-Folder. (Had bad experience with autoloading.)

[Adub]

In it video many the difficult moments, are a lot of movement.
To what needs to write a script that became less artefacts?
http://rapidshare.com/files/169736254/Matrix2.avi.html

Translation: This video has a lot of artifacts, as there is a lot of motion. What script should I be using to clean up this video?

Answer: Take a look at some scripts like MC_Spuds or MCTemporalDenoise. They have custom built presets which make it easy for a lot of beginners to enjoy the wonders of Motion Compensated Denoising.

[Fizick]

no, Shon do not want to clean this video. He likes to convert video to double framerate with MVFlowFps , and preferable in real-time :)

[tedkunich]

no, Shon do not want to clean this video. He likes to convert video to double framerate with MVFlowFps , and preferable in real-time :)

Oh no... another Jerremy Duncan in the making.... :eek:

[Adub]

no, Shon do not want to clean this video. He likes to convert video to double framerate with MVFlowFps , and preferable in real-time :)
Wait, really? After all that talk about artifacts? Okay, then you pretty much answered his question.

[Shon]

Not necessarily that played in real-time :)It is possible also heavy in three floors:)
super = MVSuper(pel=2)
backward_vec = MVAnalyse(super, overlap=4, isb = true, search=3)
forward_vec = MVAnalyse(super, overlap=4, isb = false, search=3)
MVFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
http://i423.photobucket.com/albums/pp313/Shon198/img1-2.jpg

And here a script written Delerue
super = source.MVSuper(pel=1)
backward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = true, search=3, searchparam=5)
forward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = false, search=3, searchparam=5)
source.MVFlowFps(super, backward_vec, ThSCD1=350, blend=false, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
distributor()
http://i423.photobucket.com/albums/pp313/Shon198/img2.jpg

[LaTo]

@Fizick: I have a simple feature request but indispensable...

Why not rename all the MvTools2.x functions???

In this case, we can continue to use old MvTools1.x with our old scripts... and we are able to use / make new scripts with MvTools2.x without changing the autoload dll!

I think it's really a good idea, like Masktools v1 / v2... (with the "mt_" prefix)

For example:

old MvTools 1.x
MVanalyse
MVcompensate
MVmask

new MvTools 2.x
MV_analyse
MV_compensate
MV_mask

or something else...

Otherwise, great thanks for this new version... but as I said, it's mandatory to make this change :thanks:

[Mystery Keeper]

I agree with LaTo. Would be much more convenient.

[Fizick]

No, it is not mandatory.

[Terranigma]

Hey, I wanted to mention that I had to rename mvtools2.dll back to mvtools.dll because certain functions became b0rken such as the parity functions assumetff/bff and doubleweave. They will only work for me if mvtools is in the plugin directory as mvtools.dll.

[LaTo]

No, it is not mandatory.

It was a joke :rolleyes:

[Fizick]

Terranigma,
is it joke too? :)

Anyway, I ask(ed) for discussion about renaming, so please anybody contrubute.
Even function renaming may be discussed (a little) ;)

[Terranigma]

Terranigma,
is it joke too? :)


Actually it wasn't a joke, but thanks to the renaming, I stumbled across a problem on my side I never knew existed that I sorted, so all is good now. :)

[Sagekilla]

I would like to see function renaming too: Even if it was something like:

MVTools 1.x
MVAnalyse()
MVDegrain1()

MVTools 2.x
MV2Analyse()
MV2Degrain1() (Might be a bit confusing there though)


Regardless of how you'd rename it, it'd be -really- helpful.

[Delerue]

Shon, up to now it's impossible to avoid all the artifacts in fast scenes (although I bet Fizick is working on it). But you can set your script to a better quality if speed isn't your problem. So try this:


setMTMode(2,3)
source=ffdshow_source()
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\mvtools2.dll")
super = source.MVSuper(pel=2)
backward_vec = MVAnalyse(super, blksize=8, overlap=4, isb = true, search=3, searchparam=15)
forward_vec = MVAnalyse(super, blksize=8, overlap=4, isb = false, search=3, searchparam=15)
source.MVFlowFps(super, backward_vec, ThSCD1=350, blend=false, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
distributor()


If you want you can increase 'searchparam' value even more, but the CPU demand will be insane.

By the way, try to be more clear when you're writing. Sometimes is very hard to understand you. ;)

[Fizick]

Shon,
to imporovee motion interpolation, try set some overlap, eg. overlap=2. Block size should be small (=8) for image with small details and compex motion.
There is no need to use search=3, and NEVER use big searchparam :).
Try decrease motion search range with level=2.

[Fizick]

I do not see any -real- nead to rename MVTools2 functions.
It will relult in delaying of people to use new version (and forget previous) :).

[Sagekilla]

Oh well, minor inconvenience. I'm just glad you're still working on improving MVTools :)

On a side note, I noticed there was a script using SetMTMode(). Does this mean MVTools 2.0 is finally ... multithreading friendly, or at least more than MVTools 1.0?

[scharfis_brain]

it is always possible with avisynth to use different version of the same plugin:

example:

loadplugin("mpeg2dec3.dll")
loadplugin("dgdecode.dll")

a=mpeg2source(...) # you don't know which version is called!
b=mpeg2dec3_mpeg2source(...) #using the old version
c=dgdecode_mpeg2source(...) #using the new version

this is a naming convention that was introduced into avisynth some time ago: filename_functionname()

[Gavino]

loadplugin("mpeg2dec3.dll")
loadplugin("dgdecode.dll")

a=mpeg2source(...) # you don't know which version is called!
According to the relevant wiki page (http://avisynth.org/mediawiki/Plugins)
the function loaded at last takes precedence

[Delerue]

There is no need to use search=3, and NEVER use big searchparam :).

Yeah, I tried to encode the classic 20ª Century Fox Intro with 'searchparam' 5 and 50. The result is that 5 looks better. Why? Bigger values uses more CPU. There's a specific correct value?

Try decrease motion search range with level=2.

In your help page you say that '3' is the best value in terms of quality.

[Fizick]

In your help page you say that '3' is the best value in terms of quality.

Where? :confused:

[Fizick]

About renaming: i see some voting for renaming, but i do not see any argumentation (besides words -really useful-, etc) :)

[Delerue]

Where? :confused:

Maybe we're talking about different things, hehehe.

search = 3 : Exhaustive search, searchparam is the radius (square side is 2*radius+1). It is slow, but it gives the best results, SAD-wise.

And what about 'searchparam' question?

[wyti]

go beyond searchParam=3 is insane and don't provide much benefits (even none at all) if you want more precise motion search, you can try to use Satd (add dct=5) or dct itself (really slow !) with dct=1

[LaTo]

About renaming: i see some voting for renaming, but i do not see any argumentation (besides words -really useful-, etc) :)

In this case, we can continue to use old MvTools1.x with our old scripts... and we are able to use / make new scripts with MvTools2.x without changing the autoload dll!

I think it's really a good idea, like Masktools v1 / v2... (with the "mt_" prefix)

new MvTools 2.x
MV_analyse
MV_compensate
MV_mask

At least one, and a good one :D

Question: What are the advantages to keep old names ? :)

[Fizick]

the advantages to keep old names is to force users to switch to v2.0 :)


...
MAnalyse MCompensate MMask ...?

[LaTo]

the advantages to keep old names is to force users to switch to v2.0 :)
I think that the transition will be gradual, the time to adapt the old scripts...

MAnalyse MCompensate MMask ...?
Why not, if you like this one... I prefer MV_Analyse MV_Compensate MV_Mask version but it's not problem for me :)

[Fizick]

I do not like MXXX, but I do not like underscore more: it is messed with syntax feature noted by scharfis_brain (some plugin MV.DLL may exist).

[Gavino]

I do not like MXXX, but I do not like underscore more: it is missed with syntax feature noted by scharfis_brain (some plugin MV.DLL may exist).
Very good point.
In fact, we already have a similar situation. Plugin MT.dll does exist, and manages to coexist with Masktools functions mt_xxx (because there are no function name clashes), but there is potential for confusion.

[Fizick]

MVTools v2.3.0 with all functions renamed from MVxxx to Mxxx is released.

[Shon]

WOW! The piece Matrix2 plays much better, became less artefacts!
Fizick,what have you made? Can because of "pglobal"? Or you still have added something?

[LaTo]

MVTools v2.3.0 with all functions renamed from MVxxx to Mxxx is released.
Great update! :thanks:

[LegendSeeker]

Great script, great update.

[Morte66]

[Posted for Jawed who has forgotten his password and can't get it back right now.]

I'm trying to use a calm clip to perform pre-filtering, and then use this as the basis for analysis and then performing MDegrainX, using MVTools2 v2.3.1.

Here's a test script that shows the problem:

source=blankclip(9,640,480,"YV12",color=$808080).subtitle("test")#something to see

calm = blankclip(9, 640,480,"yv12") # dummy clip with nothing happening (pretend we blurred)

# MVTools 2
super = calm.MSuper(pel=2, hpad=16, vpad=16) # create the calm superclip
backward_vec1 = MAnalyse(super, blksize=16, isb = true, delta = 1,overlap=8)
forward_vec1 = MAnalyse(super, blksize=16, isb = false, delta = 1,overlap=8)
a=MDegrain1(source, super, backward_vec1,forward_vec1).subtitle("MVTools2",x=64,y=64)

# MVTools 1
backward_vec1 = calm.MVAnalyse(blksize=16, isb = true, delta = 1, overlap=8)
forward_vec1 = calm.MVAnalyse(blksize=16, isb = false, delta = 1,overlap=8)
b=source.MVDegrain1(backward_vec1,forward_vec1).subtitle("MVTools1",x=64,y=64)

interleave(a,b)

MDegrain1 appears to be blending the superclip into the degraining operation on the source clip. This generates the darkening of the frame (since it's blending "black"), which is of course not what I want.

Is this a bug or am I misunderstanding the way Super is used?

[Didée]

Not a bug at all. That's exactly the expected behaviour. In the MVDegrain call, motion compensation is done from the "super" clip, which is filtered (here: black frame). To let MVDegrain work from the not-filtered original source, it is needed to create a "super" clip from that one, too.

Expanded the script to do the intended operation, and pointing out the relation between MVTools v1 and v2:

source=blankclip(9,640,480,"YV12",color=$808080).subtitle("test")#something to see

calm = blankclip(9, 640,480,"yv12") # dummy clip with nothing happening (pretend we blurred)

# MVTools 2
calm_super = calm.MSuper(pel=2, hpad=16, vpad=16) # create the calm superclip
source_super = source.MSuper(pel=2, hpad=16, vpad=16) # create the source superclip
backward_vec1 = MAnalyse(calm_super, blksize=16, isb = true, delta = 1,overlap=8)
forward_vec1 = MAnalyse(calm_super, blksize=16, isb = false, delta = 1,overlap=8)
a=source.MDegrain1(source_super, backward_vec1,forward_vec1).subtitle("MVTools2",x=64,y=64)

# MVTools 1
backward_vec1 = calm.MVAnalyse(blksize=16, isb = true, delta = 1, overlap=8, idx=1)
forward_vec1 = calm.MVAnalyse(blksize=16, isb = false, delta = 1,overlap=8, idx=1)
b=source.MVDegrain1(backward_vec1,forward_vec1, idx=2).subtitle("MVTools1",x=64,y=64)

interleave(a,b)

In v1, you needed to care/remember to which clip a given idx value was tied.
In v2, you need to care/remember to which clip a given "super" clip is tied.

The principle behind is still the very same. See?

[Jawed]

Awesome Didée, thanks for your succinct explanation.

And may I follow-up by saying, I like MRecalculate :cool:

Jawed

[Fizick]

source_super = super.MSuper ?

Probably you mean:
source_super = source.MSuper

[Didée]

AYYY ... yes, of course. Fixed. Thanks for pointing out.