MVTools without idx

[Fizick]

MVTools without idx?

I consider how to remove idx from MTools to make it native avisynth plugin without internal buffers and hack,
in particular for multithread.

What is idx?
It is not my design (but Manao). Here is my analisys.
MVtools internally calculate frames hierarhy structure: original size, reduced by 2, by 4, etc, and upscaled to pel accuracy (3 additional planes for pel=2). Also different YUV planes are stored.
Structures with different idx calculated for different clips.
Various MVtools functions share same memory internally for this structure (to prevent duplicate calculations and memory usage).
first MVAnalyse reserve the memories, with some hack, store and give pointer of arrays of idx to other instances or functions (in number of audio channels).

Suggestion:
Introduce new function to remove internal hack with pointer:

MVPrepare (clip, int "pel", int "level", bool "chroma", int "sharp")

input is source clip.
output is clip of complex "superframes", i.e. hierarhical frame planes.

Usage:

source=avisource("progressive.avi")
prepared=MVPrepare(source,pel=2)
vb=MVAnalyse(prepared, isb=true)
vf=MVAnalyse(prepared, isb=false)
MVDegrain1(source,vf,vb,prepared)

Impementation problems:

How to store structures in clip.
What format of clip? Probably for YV12 we could store separately Y,U.V superframes in yuv planes, and original (or padded) width.
But for YUY2 we can't (we do not have YV16 now).
probably it is better to store in RGB format with height=1 (same as vector stream).
So, frames YUV may be mixed (interleaved).

So, it will be like (pel=2):

plane00Y (level 0, pel index 0, Y)
plane01Y
plane02Y
plane03Y

plane00U
plane01U
plane02U
plane03U

plane00V
plane01V
plane02V
plane03V

plane10Y (level 1)
plane10U
plane10V

plane20Y (level 2)
plane20U
plane20V
...


For every subplane we need to store several (class) parameters.
They are currently:
Uint8 **pPlane;
int nWidth;
int nHeight;
int nExtendedWidth;
int nExtendedHeight;
int nPitch;
int nHPadding;
int nVPadding;
int nOffsetPadding;
int nPel;
bool isse;
bool isPadded;
bool isRefined;
bool isFilled;

Seems, they should be stored in avisynth framebuffers too (before every plane data).
Probably offset of every plane from start of framebuffer must be stored in framebuffer.
Currently planes memory are allocared with "new", so they are in different places.
Probably in every planes parametes block we should also store offset to next plane parameters block.
Seems, redesign is large but may be done.

Next problem is properties transfer.
MVanalyse need in width, height, colorspace of original clip.
Wel, some of them may be transtered instead of clip "audio" properties (audio_samples_per_second, sample_type, num_audio_samples, nchannels)
audio_samples_per_second should be 0,
sample_type may be used as pixel_type
num_audio_samples may be used as width
ncannles as height

(may be i missed something)

Sorry my English and mess.
May somebody can do it (may be myself)

...to be continued... :)

[MfA]

If you are feeling up to it why not add a generic metadata interface to 2.6 instead of storing stuff in a separate clip?

IanB suggested frame->GetUserData(key) and frame->SetUserDate(key, value) as the methods.

You'd have to use a LUT which used the pointer of the VideoFrame object together with the key to find the relevant data (because you can't add actual data/pointers to the object itself without breaking binary compatibility).

[krieger2005]

I don't know if it is possible to use it in avisynth but is it not easier to replace the idx-functionality with some shared-memory-mechnism? The you should not create new Functions (for the avisynth-user), don't need to expand the avisynth-functionality and can create interfaces you like.

EDIT: I see. This discussion can be read at the MT-Thread

[AVIL]

Hi,

To maintaint YUY2 compatibility perhaps you could use YUY2 planar as in kassandro's filters. Then you need not reinvent the wheel.

See section "Color spaces":

http://home.pages.at/kassandro/RemoveGrain/

See also this thread :

http://forum.doom9.org/showthread.php?t=91598

Thanks for your works.

[IanB]

@Fizick,

First up another instance of a former problem I stumbled over. Manao's bad habit of using child->GetFrame(n, env)->GetReadPtr(), there is another instance in MVClip.cpp line 90.

For other readers, a quick summary. GetFrame returns a PClip which is a smart pointer. When the PClip goes out of scope the underlying frame data gets released. With the above construct the temporary intermediate PClip goes out of scope immediatly, rendering the returned pointer as a pointer to potentially free'd and/or reuseable memory. In the single threaded case, you probably get away with it as long as you do not do any GetFrames or NewVideoFrame calls before you are done using the data under the pointer. In the multithreaded case any random call to NewVideoFrame could well steal the frame buffer just returned.

Okay down to discussion.

MVAnalyze() currently returns a RGB32 Clip, height=1, Width=<big enough to hold the vectorFields data>, nchannels=&analysisData.

analysisData holds various state data about what is happening and what info is currently stored. This is a very bad thing! Even in the single thread case, doing disjoint frame access to a MV function spoils any stored state data making it only usefull when frame access order is exactly as expected.

A proper fix for the issue is to first simplify and normalize analysisData based on the state for frame "n". And then include it or references to it in the returned MVAnalyze()'s clip GetFrame data.

The idea is to make GetFrame the only method of passing data between a MV function and MVAnalyse(). And all the state data that MVAnalyse stores be packed into the frames returned by GetFrame. i.e. extend the current use in addition to just the vectorFields data include the state for it as well.

I do not think you will need to add an MVPrepare, however it may simply the design if after normalizing analysisData there is sufficient common state data that doing a GetFrame chain between MVAnalyse() and MVPrepare() could radically simply the GetFrame chain between MV{whatever}() and MVAnalyse().

A cunning way to manage any buffers needed, like plane00Y etc, in MVAnalyze() would be to build pseudo clips internally for each type and attach a normal avisynth Cache then use GetFrame() to retrieve the required one. It would be quite legal to return a set of PClip's and "N" values in the vectorFields data if needed.

So a MV{whatever} would do {MVAnalyse}->GetFrame(n, env) calls and retrieve the state and vectorFields for frame "n". Any MVCore interface routines needed would be called with the appropriate PClip and the value "N" from the returned data. The core routine then internally does a {PClip}->GetFrame(N, env) to retrieve whatever buffer it wants. If it is in the cache then it comes for free else it gets built as normal.

The thing to keep in mind when (ab)using the avisynth cache to stash data buffers is they may get reused, so you always need to be able to regenerate the original contents. And everytime you generate contents they must be bit identical.

:Edit: - Okay having read more I see mvCore is process global, so to replace the IDX concept you will need MVPrepare or similar. Above coloured grey I now see is partially wrong.

With MVPrepare you can make mvCore a member of the MVPrepare object and buffer all the MVGroupOfFrames objects thru GetFrame calls.

:Edit 2: For your MVPrepare output clip stick with RGB32, height=1, for the moment. This offers 32bit storage units and no restrictions. In 2.6 I have a "Raw Data" pixel type on my todo list, it will probably internally mirror RGB32 but externally it will be a distinct pixel type that most filters will refuse to process (stuff with).

For passing your metadata around just jam a pointer to it into the front of your GetFrame data, it will also have the benefit of being a signature to check in case users try to feed a wrong clip into your routines.

For holding the plane data you can continue to manage it internally and just pass pointers in your GetFrame data, this will require minimal changes, maybe do this first.

Or you can go the whole hog and build a PClip for each plane and do {PClip}->GetFrame(n, env) to recover each element. Or perhaps somewhere in the middle with grouping an entire level into a PClip. As I read more I may understand better the issues on how to decide.

[Fizick]

Mfa, metadata is not implemented in current 2.6 alpha.
(besides new pixel_type).


krieger2005,
I do not know about shared-memory-mechnism. How user can say to avisynth (without idx or MVprepare), what data could be shared and what not?

AVIL,
Yes, thanks, I remember about it, and similar approach may be used.

IanB,
1. Are you sure that you get latest version 1.8.4 of MVTools? :)
IMO, the "former problem" was solved (thank to your advice) in v.1.4.13 about one year ago.
There is no any GetFrame call in MVClip now.

2. IMO the new MVPrepare is the only way to remove idx effectively.
Without common MVPrepare (and without idx), every MVAnalyse(for different offsets or direction) will need in own (duplicate) calculation of same super frame interpolation. It will also result in huge memory eating (superframes are big) - without sharing.
It is equivalent to case of unique idx for every MV function now.

to be continued :)

[Fizick]

3. Other attempt to decribe how MVTools and idx works (it is not to IanB, but to somebody else and myself :).

For example consider MVDegrain1() is requested by frame n=10 (and it is start of processing).
MVDegfrain1 requests vector frame 11 from MVnalyse(backward). To produce it, MVnalyse(backward) is need in superframe 10 and 11.
It calculate them and put both them (10,11) to "idx internal clip".
MVDegrain1 also requests vector frame 9 from MVnalyse(forward). To produce it, MVnalyse(forward) is need in superframe 9 and 10.
It can get superframe 10 from "idx internal clip", calculate superframe 9 and put it to "idx internal clip".

Note: supperframes with same N are the SAME for any direction (backward,forward) and any frame estimation delta!
Of course, for same source clip. That is why we use idx.

Next step is n=11 (for usual sequencial access).
Two needed superfames (10, 11) are already calculated at previous step and may be taken from "idx internal clip", besides new superframe 12.

The cache buffer size is limited (MV_BUFFER_FRAMES=10),
when all spaces are filled, the oldest superframe is deleted and replaced by new.

If access is not sequencial, story is not so good.
For example if we use SelecEven after MVDegrain, the frame n=12 is requested instead.
We need in superframes 11, 12, 13.
Superframes 9, 10, 11 are in "idx internal clip" cache, so we have 11 and must calculate new superframes 12 and 13 now.


4. About IanB's suggestion to create set of (pseudo)clips internally in MVAnalyse.
As I wrote above, there are several MVanalyse command in script, so these clips will be duplicated again.
How to communicate and share calculated frames buffers? With some globals?
Do not forget, several source clips (now with different idx) may be in a script, for example with MVFlowfps2 or prefiltered clips.

Probably we could create these pseudoclips in MVPrepare.
But I do not quite understand about "quite legal return a set of PClip's and "N" values".
Can "prepared" clip (see example script above) be not single clip but (AVSValue) ARRAY of pseudoclips (with array size = number of hierarchy scale levels)?
Is it possible in Avisynth syntax? (I never saw any such filter. :))
If yes, this way may be considered.

I wrote above about some problem with YUY2 case (as AVIL mentioned, we could try use YUY2 planar as in kassandro's filters).
Storage of pel-interpolated data must be considered too: one big upscaled clip or 4 clips of subframes(as currently implemented).

Of course, it would be fine do not put any extra metadata to these videoframes,
but I am afraid "audio" properties number is not enough.

[tsp]

Of course, it would be fine do not put any extra metadata to these videoframes,
but I am afraid "audio" properties number is not enough.
What about saving it in the frame that MVPrepare returns with all the other stuff? If you are going to save the extra parameters for the subplane you could also save the original width,height, colorspace, etc for the original clip. It shouldn't take many cycles to copy that.

[IanB]

@AVIL, 2.6 Has planar YUY2, it is called YV16.

@Fizick, Yes I got confused with many archived sources. I have 1.8.4 but stupidly was reading an old 1.4.8 source :o sorry for causing any panic attack.

Yes I now agree, the MVPrepare type approach, is a very favourable approach. I changed my post above 2 times as I read more source, so some is not quite relevant anymore.

I do not think my internal pseudo clip idea is that good any more. For the future it may be desirable to use external filters (i.e NNEDI, etc) to generate/calculate the superframe clips, so I think it would be helpful make the superframe data regular clips where possible.

As tsp says for the metadata just put the data or a pointer to the data in the MVPrepare returned frame.

[Fizick]

I am still preparing for MVPrepare :)

more correct syntax should be with padding parameters:

MVPrepare (clip, int "pel", int "levels", bool "chroma", int "sharp", int "hpad", int "vpad", clip "pelcip")

currently in MVTools padding=blocksize.

IMO, to have superframe compatible with external resizing tools, it is better do not put any parameters to frame data,
and try transmit them in packed (hacked) audio properties.
Every parameter (pel, ... vpad) value is really small, so we can use BYTE.
Four parameters = one int, for example sample_type.

this way superframe is simply stacked multilevel image data.
Every color plane may be stored indpendently for YV12.
For YUY2 we all waiting for avisynth 2.6 (but packing-repacking way is also possible).

[Fizick]

question (to TSchneide?)
Why align planes in MVPlane ?
I see x256sad cache spilt code, and understand why ALIGN_SOURCEBLOCK in PlaneOfBlocks.
But anyway refence block may be in any place, so why to align it?

I want create planes data in normal Avisynth frames and do not want to add additional aligment.

[Fizick]

OK, here is preliminary alpha version 2.0.0.1
http://avisynth.org.ru/mvtools/mvtools20.dll

It contains only MVPrepare function.

Can anybody suggest better name for it and for clips its produced (for future MVAnalyse)?
:)

[mikeytown2]

Can anybody suggest better name for it and for clips its produced (for future MVAnalyse)?
:)

MV Prep
MV Pointer
MV Container
MV Root
MV Threads
MV Superframe
MV Wrapper

[Fizick]

I considered MVMulti , but it is a little confused :)

prep=MVPrepare(source)
vec=MVEstimate(source,prep)
MVDegrain(source,vec,prep)

source may be omitted, but it will mostly provide audio and some clip properties.

I like to have dozen Motion properties in avisinth.h v2.6

[Gavino]

prep=MVPrepare(source)
vec=MVEstimate(source,prep)
MVDegrain(source,vec,prep)

source may be omitted, but it will mostly provide audio and some clip properties.
Will this new scheme fix the problems with 'implicit last' that we discussed (http://forum.doom9.org/showthread.php?p=1183259#post1183259) recently?

[Fizick]

implicit last will be functional if I replace named clip parameters to unnamed. I am not sure that i will do it.

but anyway all existant script must be changed

avisource()
super=MVSuper()
vecb=MVAnalyse(super,isb=true)
vecv=MVAnalyse(super,isb=true)
MVDegrain1(last,super,vb,vf)

we need in users opinions.

[TSchniede]

question (to TSchneide?)
Why align planes in MVPlane ?
I see x256sad cache spilt code, and understand why ALIGN_SOURCEBLOCK in PlaneOfBlocks.
But anyway refence block may be in any place, so why to align it?

I want create planes data in normal Avisynth frames and do not want to add additional aligment.

It's simple... the functions we use from x256 are only faster because they can depend on aligned access. The best case would be to compare only two aligned blocks, but we must shift either the source or the destination block freely, so one of them should be unaligned in most cases. The trouble is, that only MMX tolerates unaligned access most SSE instructions don't. To make matters worse, any newer intel chip hat a noticeable penalty for a memory access across physical cache line borders and an even worse penalty if that also happens to coincide with a memory page border. So there are unfortunately only two possible options right now: use simple MMX and ignore the penalty (which is essentially using the old isse functions) or use a work around like in x256sad and align the memory blocks (this could be done once for each frame if all data is sized in accordingly (padding and the like)).
Compensating on both sides source and destination is only possible for MMX but the overhead should be far greater than the gain (ok it would be possible but it is certainly slower).

[Fizick]

I do not understand.

SAD(pSrc[0], nSrcPitch[0], pRef0, nRefPitch[0])

Src is artificantly aligned (ALIGN_SOURCE_BLOCK)

But Ref block is GetRefBlock(vx, vy). Why align Ref plane, if vector may be any, and Ref block will be unaligned (in most cases) anyway?

[TSchniede]

I do not understand.

SAD(pSrc[0], nSrcPitch[0], pRef0, nRefPitch[0])

Src is artificantly aligned (ALIGN_SOURCE_BLOCK)

But Ref block is GetRefBlock(vx, vy). Why align Ref plane, if vector may be any, and Ref block will be unaligned (in most cases) anyway?

I have to admit, this is somewhat excessive. It's mostly because I did that first, but it prevented overlapped blocks. There is still a small profit though, as the copy code doesn't compensate for cacheline splits. Ensuring that most the cacheline splits occur on the borders(16xY blocks without overlap) or at least exactly in the middle (16xY with 8 overlap or 8xY without overlap) reduces the penalty. It might be less than the alignment penalty though - I forgot to check :(

[Fizick]

TSchniede,
Please also look to new v2.0 code ( when it will be released :)) to check the issue.
I use usual avisynth framebuffer as a storage of all (super) planes.

Preliminary alpha v2.0.0.3 is probably almost ready (not tested) with functions MVSuper, MVAnalyse, MVDegrain1, MVShow only.
(other MVXXX code temporary removed from project).
I can upload MVTools.DLL and source

[Fizick]

here is v2.0.0.3 alpha
http://avisynth.org.ru/mvtools/mvtools-v2.0.0.3.zip

project file for codeblocks: mvtools-super.cbp
New documentaton is missing. Current using (may be changed without notification :) ):

avisource()
super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(super,isb=true) # any old MVAnalyse params besides above
vf=MVAnalyse(super,isb=false)
MVDegrain1(last,mvbw=vb,mvfw=vf,super=super)

I note some speed increasing and memory usage decreasing. Please test.

About syntax and implementation.
superframe contains all source video data. So, it is possible implement clients (like MVDegrain1) without usage of source (i.e. last clip):
MVDegrain1(super,mvbw=vb,mvfw=vf)

But super clip does not contain source audio (i killed it). Of course we can use audiodub.

[Gavino]

Sorry to bring up the 'implicit last' issue yet again, but it's such a fundamental part of Avisynth usage that I think it's important to get it as right as possible. Would this be a valid sequence:

avisource()
MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(isb=true)
vf=MVAnalyse(isb=false)
MVDegrain1(mvbw=vb,mvfw=vf)

with the last 3 implicitly using the result of MVSuper?

Why kill the audio? I don't understand that. Or does it hide extra data in what would otherwise be audio properties?

[Didée]

Looking at the proposal of superframe concept, it seems that some possible kind of processing "tricks" are lost.

One "trick" you could do with v1.x is this:

source = last
vb = source.MVAnalyse(isb=true, idx=1)
vf = source.MVAnalyse(isb=false,idx=1)

alt = source.blur(1) # example for an "alternate" spatial or spatio-temporal filter

result = alt.MVDegrain1(vb,vf,idx=1) # *same* idx !


This way you get "automatically" weighting-in of the alternate filter in places where compensated blocks get less weighting (due to thSAD). If all compensations "fail" completely, the result is 100% of the alternate filter.

Now with the new superframe concept, it seems no more possible to do this kind of "mixing". You get only vanilla "no processing" for failed compensation areas. To get that "functionality" (though it's a trick) back, it would require to additionally include the alternate filtered clip into the superframe?

Some more thoughts should be thrown about handling of "failed compensation" blocks in MVDegrain. (par ex., the mix achieved by the given code example is not optimal either - in areas where compensation is successful, it gives too much weight to "alternate".)
But for today, it's too late now. ;)

[IanB]

@Fizick,

I had a thought on a way, for a function like MVSuper, to return a set of clips.

Currently you pack all the levels into a monster single clip, "super". Strikes me that you would really like each level to be a single ordinary clip and be able pass all these level clips around as a single unit.

If you create all these PClips and then assign each to unique var name, you only need return all the var names, say as a string.

AVSValue __cdecl Create_MVSuper(AVSValue args, void* user_data, IScriptEnvironment* env)
{
...
//
AVSValue level0clip = AVSValue((PClip)(new LevelClip(child, 0, ... , env)));
level0clip = env->Invoke("Cache", level0clip); // Add a cache
AVSValue level1clip = AVSValue((PClip)(new LevelClip(level0clip.AsClip(), 0, ... , env)));
level1clip = env->Invoke("Cache", level0clip); // Add a cache
...

// Use hex of object pointer to make a unique name
char *level0name = env->Sprintf("MVInternal_%08x", (int)level0clip.AsClip());
char *level1name = env->Sprintf("MVInternal_%08x", (int)level1clip.AsClip());
...
//
env->SetGlobalVar(level0name, AVSValue(level0clip));
env->SetGlobalVar(level1name, AVSValue(level1clip));
...

// Pass back all the relevant info
char *ReturnString = env->Sprintf("hpad=%d, vpad=%d, pel=%d, levels=%d, level0=%s, level1=%s, ...",
hpad, vpad, pels, levels, level0name, level1name, ...);

return AVSValue(ReturnString);
}Thoughts?

[Fizick]

IanB,
If we would have so many multi-level clips (and GetFrames calls), will it pollute the avisynth cache?
Or it is dependent not on number of clips (frames), but on their sizes only?

BTW, i have got about 10% speed increasing with v.2.0, probably due to better caching

[Fizick]

Gavino,
I agree, that now it is a very good chance to change (improve or brake) the syntax. :)

Implicit last works with super in MVAnalyse v2.0.
Implicit last will work perectly with MVDegrain1 and other client fuctions if I make all clips parameters as annamed:

replace

c[super]c[mvbw]c[mvfw]c[thsad]i....

to:

cccc[thsad]i...


but in this case the syntax
MVDegrain1(super=super, mvbw=vb, mvfw=vf) will be not accepted (There are no named param super...)
so we must use :

MVDegrain1(super, vb, vf)

It is easy change of code :) , it may be done in any moment. I ask opinion from other users and script writers

[Fizick]

Didée,
yes this is a trick.
I do not see that it is used in any script probably beside your secret unpubliched :)
It is not documented way. If you need in such processing, it may be somehow implemented.

Well, here is suggested way to use different clips for motion estimation and compensation:

avisource()
super=MVSuper() # super original clip
f=blur(1.0) # filtered clip
fsuper=MVSuper(f) # super filtered clip
vb=MVAnalyse(fsuper,isb=true)
vf=MVAnalyse(fsuper,isb=false)
MVDegrain1(last,super=super,vb,vf)

So, for your trick the last line should be changed to :

MVDegrain1(f,super=super,vb,vf)

this should works in v2.0.0.3, please check.

BTW, I considered to remove source clip reading in next MVDegrain1 alpha (and get all info from super source clip), but after your request it will be preserved. :)

[IanB]

If we would have so many multi-level clips (and GetFrames calls), will it pollute the avisynth cache?
Or it is dependent not on number of clips (frames), but on their sizes only?Yes it is the total size as in SetMemoryMax(Megabytes).

As far as I understand your new code, (still reading it), all the clips and their GetFrame calls are already present in some abstracted form. My theory is to try and make them all separate regular Avisynth clips as much as possible. If a component contains image data then as a separate clip you should be able to process it with any normal Avisynth filter, e.g. once you have a level clip you may use any resizer available to make the next level if you want.

The example with Didée above with separate level clips would be a lot better. Only the levels actually used in a Super would be rendered and cached. As you currently have it you must build both complete Super clip at all levels, maybe this is still required and there is no gain to be found, I do not currently understand enough to predict.

Also for multithreading having components distinct means that maybe they can be processed in parallel.




Also for your implicit last problem you can overload the function definitions twice and use the user data value to know which one is current. env->AddFunction("MVDegrain1",
"ccc[thSAD]i[thSADC]i[plane]i[limit]i[super]c[idx]i[thSCD1]i[thSCD2]i[isse]b",
Create_MVDegrain1, (void*)0);
env->AddFunction("MVDegrain1",
"c[thSAD]i[thSADC]i[plane]i[limit]i[super]c[idx]i[thSCD1]i[thSCD2]i[isse]b[mvbw]c[mvfw]c",
Create_MVDegrain1, (void*)2);In the second pattern you must make the order different enough so that the parser cannot mismatch missing non-optional arguments. Unfortunately this changes the arg numbers but by clever use of the user data value the code can still be simple. e.g.AVSValue __cdecl Create_MVDegrain1(AVSValue args, void* user_data, IScriptEnvironment* env)
{
int A = (int)user_data;
int plane = args[5-A].AsInt(4);
...
int thSAD = args[3-A].AsInt(400);

return new MVDegrain1(
args[0].AsClip(),
args[A?12:1].AsClip(), // mvbw
args[A?13:2].AsClip(), // mvfw
thSAD, // thSAD
args[4-A].AsInt(thSAD), // thSADC
YUVplanes, // YUV planes
args[6-A].AsInt(255), // limit
args[7-A].AsClip(), // prep clip
args[8-A].AsInt(0),
args[9-A].AsInt(MV_DEFAULT_SCD1),
args[10-A].AsInt(MV_DEFAULT_SCD2),
args[11-A].AsBool(true),
env);
}

[AVIL]

My two pence:

It is easy change of code :) , it may be done in any moment. I ask opinion from other users and script writers

I usually don't use clip arguments as named. For me will be transparent if you declare it unnamed.

[Fizick]

Probably currently i will agree with Gavino and AVIL, and wait when IanB make some internal trick in Avisynth 2.6.X to have option to mark some named agruments mandatory (some modifier like "!")

c[super]c![mvbw]c![mvfw]c![thsad]i....

IanB,
probably trick wih strings is possible, but I am not very like globals and checking of non-coincided clip names (with multitreading).
But i like idea to have an option to produce super clip without MVTools. That is why I remove all non-pixel metadata from super frames.
It is possible to process super clip wit some user filter.
Generally say, my goals of MVTools v2.0 are more speed, clarity and stability. With using of normal avisynth cache and removing idx and other hacks.
IMO, these goals are achieved :)

Note. I assume that it is not very hard to add some MVTools parameters (mostly MVAnalysisData) to videoinfo structure in avisynth.h like:

int mvtools_version;
int mvtools_hpad; (or may be simply mvtools1)
...
etc, and some reserved space for future using:
mvtools_reserved1; (or may be simply reserved1)
mvtools_reserved2;
...

It is only several bytes fo my metadata parameters.
If we will add them to the end of vi structure, we can preserve compatibility with 2.5 plugins, right?
I do not see many other plugins what need in such parameters.

[IanB]

Probably currently i will agree with Gavino and AVIL, and wait when IanB make some internal trick in Avisynth 2.6.X to have option to mark some named agruments mandatory (some modifier like "!")

c[super]c![mvbw]c![mvfw]c![thsad]i....Be aware that it will be a very long wait. I have given you several workarounds in the past and have just given you another one.


probably trick with strings is possible, but I am not very like globals and checking of non-coincided clip names (with multitreading).You don't have to use a string, it was just an idea to pass information to allow you to find the needed clip objects without the problems we had using AVSValue arrays in scripts. There is no problem using globals here. By using the hex of the clips object address in memory for the name they will be unique even with multi threading. Two objects cannot occupy the same memory. By assigning the clip to a var it means you can use env->Invoke() or other functions to process it internally. The vars do not need to be global they just need to have just enough scope so you can latter get the PClip value and add it into the graph.

But I like idea to have an option to produce super clip without MVTools. That is why I remove all non-pixel metadata from super frames.
It is possible to process super clip with some user filter.But still the super clip is not a stardard clip, it is packed data from what should really be a matching set of clips. I would urge you most strongly to explore all means to stop packing what should really be individual but associated clips. You have a lot of complicated code to manage this packing and it will just go away with individual PClips.

Generally say, my goals of MVTools v2.0 are more speed, clarity and stability. With using of normal avisynth cache and removing idx and other hacks.
IMO, these goals are achieved :)And yes you are achieving that goal. I am just trying to provide extra ideas to do even better.

Note. I assume that it is not very hard to add some MVTools parameters (mostly MVAnalysisData) to videoinfo structure in avisynth.h like:

int mvtools_version;
int mvtools_hpad; (or may be simply mvtools1)
...
etc, and some reserved space for future using:
mvtools_reserved1; (or may be simply reserved1)
mvtools_reserved2;
...

It is only several bytes for my metadata parameters.
If we will add them to the end of vi structure, we can preserve compatibility with 2.5 plugins, right?
I do not see many other plugins what need in such parameters.Inside your plugin you can extend any structure in any way you want, but any extra data will not be preserved outside your plugin. VideoInfo is 48 bytes long so once outside your plugin only the first 48 bytes will ever be copied.

vi.num_audio_samples=nHeight+(nHPad<<16)+(nVPad<<24)+((_int64)(nPel)<<32)+((_int64)nModeYUV<<40)+((_int64)nLevels<<48);

If you continue with using a packed super clip then you might as well just pack this data into every super clip frame. If you use my string idea then it comes for free. If you use an AVSValue array as we had discussed a while ago then it is also for free.

[Fizick]

AVIL,
I switch to planar packed to interleaved YUY2 (same as kassandro) for super clip storage in next alpha. It is faster.

[Fizick]

IanB, can 48 bytes be extended in v2.6?

[IanB]

IanB, can 48 bytes be extended in v2.6?It would not help because baked in code in any 2.5 filters will still only copy 48 bytes.

[AVIL]

AVIL,
I switch to planar packed to interleaved YUY2 (same as kassandro) for super clip storage in next alpha. It is faster.

Due to mt-masktools usage, converting my yuy2 clips to planar form is a frequent task. Surerly i can profite previous conversions when use mvtools. No problem then.

An idea. ¿Could be make compatibility between kassandro's YUY2 planar form and YV16?

Anyway thanks for your efforts.

[Fizick]

IanB,
it is not a irresistible reason to stop progress. :)
Let's add first extra vi parameter as an some keymark (Is26ExtraParamsUsed), and check this key in new 2.6 filters and plugins with appropriate ThrowError message if it is not coincide.

AVIL,
are you use Avisynth v2.6 prealpha? What do you mean as "compatibility" ? Some format conversion function (plugin)?

[AVIL]

@Fizick:

Actually i use version 2.5.7.

For compatibility means that clips used by interleaved2planar()/planar2interleaved() follows the avisynth planar structure :

http://avisynth.org/mediawiki/Filter_SDK/Working_with_Planar_Images

so almost native (or external) plugin that accepts planar files (yv12, yv16,...) could accepts this clips too. Number of conversions in complexe scripts (see http://forum.doom9.org/showpost.php?p=1159284&postcount=150) could be dramatically reduced.

[Fizick]

AVIL,
I missed, that MaskTools recently (in February :) ) got support of yuy2 planar.
I will consider to add support of this to MVTools

[Fizick]

here is next 2.0.7.0 alpha.
http://avisynth.org.ru/mvtools/mvtools-v2.0.7.0.zip
Docs is absent.
Implemented functions:
MVSuper(source, hpad, vpad, pel, levels, chroma, sharp, rfilter, pelclip, isse, planar)
MVAnalyse(super,blksize,...)
MVFlowFps(source,super,mvbw,mvfw,...,planar=true)
MVFlow(source,super,vec,...,planar=true)
MVCompensate(source,super,vec,...,planar=true)
MVShow(source,vec,...,planar=true)
MVMask(source,vec,...,planar=true)
MVDegrain1(source,super,mvbw,mvfw,...,planar=true)
MVDegrain2(source,super,mvbw,mvfw,mvbw2,mvfw2,...,planar=true)

So, all functions (besides MVAnalyse) got planar parameter for YUY2 planar input and output. Default = false (i.e. normal interleaved YUY2), slower.
All (mandatory) clip parameters lost their names, and mvbw=vb is not correct syntax now.
Use unnamed syntax. I will consider IanB's suggestion later, afrer small "vacations" :)

[Fizick]

here is next 2.0.9.0 alpha.
http://avisynth.org.ru/mvtools/mvtools-v2.0.9.0.zip

Implemented more functions without idx: MVSCDetection, MVDepan, MVFlowInter, MVBlockFps, MVFlowBlur, MVDegrain3, MVRecalculate
Fixed crashes with MVSuper(chroma=false)
Some small changes and fixes for v2.0 of course :)
Documentation for v2.0, see here: http://avisynth.org.ru/mvtools/mvtools2.html

I also have an intention to remove some obsolete functions, in particular MVDenoise, MVFlowFPS2

[yup]

Fizick!
:thanks:
Great work and big step ahead. I only read doc not tested. Planar support it is very important for my scripts. MVSuper life without headache, especialy with MT.
One more :thanks:
yup.

[Delerue]

Fzick, I tried to use MVFlowFPS, but I got this error: invalid arguments to function 'MVSuper'. I tried with your three script examples here (http://avisynth.org.ru/mvtools/mvtools2.html).

[Fizick]

Delerue, what example?

Documentation is in progress ;)

[Delerue]

These:


AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
# assume progressive PAL 25 fps source
super = MVSuper(pel=2)
backward_vec = MVAnalyse(super, isb = true)
forward_vec = MVAnalyse(super, isb = false)
MVFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps



To double fps with MVFlowFps for fastest (almost) real-time playing:
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
# assume progressive PAL 25 fps or NTSC Film 23.976 source
super = MVSuper(pel=1,hpad=16,vpad=16)
backward_vec = MVAnalyse(super, blksize=16, isb = true, chroma=false, searchparam=1)
forward_vec = MVAnalyse(super, blksize=16, isb = false, chroma=false, searchparam=1)
MVFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last), mask=0)



To double fps with MVFlowFps for 'best' results (but slower processing):
AVISource("c:\test.avi") # or MPEG2Source, DirectShowSource, some previous filter, etc
# assume progressive PAL 25 fps or NTSC Film 23.976 source
super = MVSuper(pel=2)
backward_vec = MVAnalyse(super, overlap=4, isb = true, search=3)
# Use block overlap, halfpixel accuracy and Exhaustive search
forward_vec = MVAnalyse(super, overlap=4, isb = false, search=3)
MVFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(last), \
den=FramerateDenominator(last))

[Fizick]

At least first script works fine for me.
can anybody confirm?

May be I upload wrond mvtools.dll?

[Delerue]

To be more specific, I used the new MVTools alpha with FFDShow, changing only AVISource("c:\test.avi") to source=ffdshow_source(). Sorry if I didn't mentioned this before; that's because this change seems to be harmless and works with all official MVTools versions. But if you're confirming that these examples works for you, so maybe my change isn't that harmless, hehehe. Can you try using your examples inside FFDShow Avisynth tab?

Thanks!

[Fizick]

Delerue,
OK, i will try found my ffdshow :)
But can you also try script without ffdshow ;)


EDIT:
source= ?
For ffdshow you probably must use this:


ffdshow_source
super = MVSuper(pel=2)
backward_vec = MVAnalyse(super, isb = true)
forward_vec = MVAnalyse(super, isb = false)
MVFlowFps(super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps

[Delerue]

Fizick, ffdshow_source works only with your Yadif plugin port. MVTools doesn't work this way, even this alpha. If I try it, I get Evaluate: System exception - Acess Violation....

I'll try your alpha with VirtualDub later. ;)

[Fizick]

source=ffdshow_source()
super = MVSuper(source, pel=2)
backward_vec = MVAnalyse(super, isb = true)
forward_vec = MVAnalyse(super, isb = false)
MVFlowFps(source, super, backward_vec, forward_vec, num=50, den=1, ml=100) # get 50 fps

[Delerue]

I just get it (also with MT!):


SetMtmode(1,5)
source=ffdshow_source()
SetMTMode(2)
LoadPlugin("C:\Program Files (x86)\AviSynth\plugins\mvtools.dll")
super = source.MVSuper(pel=1)
backward_vec = MVAnalyse(super, blksize=8, overlap=2, isb = true, search=2)
forward_vec = MVAnalyse(super, blksize=8, overlap=2, isb = false, search=2)
source.MVFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
distributor()


I'm testing right now. I'll tell you my thoughts later.

[Delerue]

Fizick, I've been testing your alpha for 4 days, and until now no problems at all. About memory usage, take a look at this (all tests with MPC HC 1.1.839 + FFDShow 2228):

MVTools 1.11.4.3 -> MVFlowFPS:

backward_vec = source.MVAnalyse(blksize=8, overlap=2, isb = true, pel=1, search=2, idx=1)
forward_vec = source.MVAnalyse(blksize=8, overlap=2, isb = false, pel=1, search=2, idx=1)
source.MVFlowFps(backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source), mask=2, idx=1)
distributor()


Memory usage 211 MB.

MVTools 2.0.9.0 -> MVFlowFPS:

super = source.MVSuper(pel=1)
backward_vec = MVAnalyse(super, blksize=8, overlap=2, isb = true, search=2)
forward_vec = MVAnalyse(super, blksize=8, overlap=2, isb = false, search=2)
source.MVFlowFps(super, backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))
distributor()


Memory usage 428 MB.

I don't know if there's any memory leak, but there was a huge increase, don't you think?

About CPU optimization, I don't know if you tried something with MVAnalyse and/or MVFlowFPS, but as far as I tested, both versions look like the same.

[Fizick]

Delerue,
v2.X uses Avisynth cache for superframes, so more frames are contolled by avisynth (in addition to source). Memory size may be contolled by SetMemoryMax. Probably you have 2Gb memory, and memorymax is about 512 Mb.
i am not sure how exactly avisynth use cache memory if there is no many frames requests.
probably growing it is limited by max frame distance from current?

[Delerue]

I see. I indeed have 2 GB. There's no problem to me to have a video using almost 500 MB; I only told you about memory usage because you're in alpha stage and I thought that it would be useful somehow, hehehe. Keep going. ;)

[Fizick]

Delerue,
Of course, your report is useful!
Now I see, that you use pel=1, and i discovered, that I use non-optimal processing for pel=1 in v2.0.9 (non-needed finest clip).
It is removed in v2.0.9.1, please test it.

http://avisynth.org.ru/mvtools/mvtools-v2.0.9.1.zip

[Delerue]

Cool. I noticed a great performance improvement. Thanks. ;)

[Fizick]

and what about memory?

[Delerue]

and what about memory?

I didn't check it before you ask now. Take this: cut in half. :eek:

[Fizick]

so, this alpha 2.0.9.1 is rather mature alpha :)
Its a time to add link to it at my site :)

I consider vector format possible change.
for 2.1.X development it would be interesting (may be) to get vectors, make some manipulations with them an put to vector stream again, and recalulate.

now we have mask(kind=5) to have a vectors for processing. it is easy to implement complementary function. But these vectors are limited by value to signed char limit =127, i.e. 63 pixels max for pel=2. We need in two byte color format :)

[IanB]

A thought on improving memory usage in the Super clip.

The current implementation is to vertically pack all the various level combinations of samplings of the original image into 1 big frame.

Strike me that not all of these level sampling components are always used, so generating and storing them is a waste. So just store each sampling component in its own avs frame and multiplex the frames by frame number instead of stacking vertically.

i.e. A given super clip has say 9 level sampling components.

So you vi_of_super.num_frames *= 9; in the constructor.

In MVFrame or such instead of using PlaneSuperOffset(... Level ...) etc you resolve to pclip_of_super.GetFrame(n*9+Level, env);

In MVSuper::GetFrame you get Level=n%9; and Source_N=n/9;

A further refinement would be to also multiplex the luma and chroma planes individually as well, so 9 becomes 27. i.e. to get use (n*9+Level)*3+Plane and to resolve use Plane=n%3; Level=(n/3)%9; Source_N=n/(9*3); If you go this far just use RGB32 as you do for the vector clips.

[Fizick]

IanB,
Yes, memory usage is not perfect.

1. All levels are used in MVAnalyse (so, generation is not a waste), but in MVAnalyse only.
MVCompensate (et al) uses finest level only. It is biggest through, especially for widely used pel=2 (and pel=4 of course). We have 4*height. coarse levels use about 1*height max.

2. I certainly do not want to return to RGB32 and split a chroma! I like to have native color format for every level. It was one of my aims. I like to have possibility to see every level and its padding (i already fixed 2 bugs when i saw intermediate clip :) ). We may also apply some external filter to whole super frame (or to sublevel with a mask).

3. Anyway, I considered to split the super to finest level and coarse levels. Your suggestion is interesting. Thanks for this and others! I considered and considerer. But I am wonder, how we can multiplex frames with different width and height.

4. Where we really waste a memory, it is in MVFlowXXX, when I build full finest clip (instead separated by pel subplanes). I succesfully impemented (non-public) version without this finest clip, but modified MVFlowFps is slower by 15 percent. Reason - too many calls (for every pixel, not to every block!) to get address of specific pel plane. I may add it as an option for testing.

5. IanB, may CACHE_RANGE help? Can we get some memory improving if we explitily set cache range by MVSuper(..., cache_radius=1) if we know, that there are MVAnalyse(delta=1) only?

[mikeytown2]

An idea for #3

Throw good programing out the door and use some global variables. So instead of multiplexing we have completely separate streams. Sadly this might bring back some form of idx; but it would allow you a lot more storage space for passing info and such.

[superuser]

super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(super,isb=true) # any old MVAnalyse params besides above
vf=MVAnalyse(super,isb=false)
MVDegrain1(last,mvbw=vb,mvfw=vf,super=super)

I note some speed increasing and memory usage decreasing. Please test.

About syntax and implementation.
superframe contains all source video data. So, it is possible implement clients (like MVDegrain1) without usage of source (i.e. last clip):
MVDegrain1(super,mvbw=vb,mvfw=vf)




tested above and works fine.

though had couple of points - If I pass in the source clip to MVAnalyze, it gives be invalid argument error.

source = last
super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(source, super,isb=true)
vf=MVAnalyse(source, super,isb=false)


If I remove source from the MVAnalyze it works fine.

Also can clip especially vectors be passed in as mvbw=vb,mvfw=vf.

source = last
super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(source, super,isb=true)
vf=MVAnalyse(source, super,isb=false)
MVDegrain1(super,mvbw=vb,mvfw=vf)


If I try this it does not work and do not think it is expected to work. If I substitute above with following it works fine:


source = last
super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(super,isb=true)
vf=MVAnalyse(super,isb=false)
MVDegrain1(super, vb, vf)


....

Can MVDegrain and in general mvtools be used along with MT? Yesterday I was running MVDegrain2 on a source of about 3 hours of run length and had experienced system crash (Vista 64 bit). Not sure exactly how frames it was into it when system crashed as I was asleep than and in morning saw system crashed. I was doing 2 pass XVid encode and have xvid stats file produced during 1 pass of XVid, in which system had crashed, tell us about how many frames it had processed to know many frames the script choked on. Though I had other filters in the script, so later today will try out only with MVDegrain2 and see what happens. I have wrapped MVDegrain2 in a function and have this processed using MT. Hopefully this should not be a problem. This was a working script with new addition being MVDegrain2 using latest mvtools bundle to chain of filters. Following are filters/steps I am using in the script

- Tdeint and TDecimate
- crop
- upscale
- Masked HDRAGC
- MVDegrain2 with MT
- fft3dfilter
- LSF with MT
- SootheT and Dehalo with MT
- downsize to desired resolution
- Tweak

[MfA]

An idea for #3

Throw good programing out the door and use some global variables. So instead of multiplexing we have completely separate streams. Sadly this might bring back some form of idx; but it would allow you a lot more storage space for passing info and such.
You could just use the pointer for the videoframe together with a hash map to store arbitrary amounts of meta data for each frame.

[Fizick]

superuser,
MVAnalyse (clip super, int "blksize",....) does not use source clip.
Are you read docs about new syntax changes? :)

Can MVDegrain and in general mvtools be used along with MT?
Are you say about MT("....") ? Yes, it probably may be used. But you know about frame dividing with MT.

[superuser]

superuser,
MVAnalyse (clip super, int "blksize",....) does not use source clip.
Are you read docs about new syntax changes? :)

sorry, my bad ...

Can MVDegrain and in general mvtools be used along with MT?
Are you say about MT("....") ? Yes, it probably may be used.

Yes, this is what I am doing:



...
...
MT("mc_degrain(src)", threads=4)
...
...

function mc_degrain(clip src)
{
last = src
super=MVSuper(hpad=8, vpad=8, pel=2, sharp=2, rfilter=1)
vb=MVAnalyse(super,isb=true)
vf=MVAnalyse(super,isb=false)
return MVDegrain1(last,mvbw=vb,mvfw=vf,super=super)
}




But you know about frame dividing with MT.

no clue about it ... so can this mean using MT can result into different results? :confused:

[Fizick]

return MVDegrain1(last,mvbw=vb,mvfw=vf,super=super) ?
I am sure you use not latest 2.0.9.1 MVTools.

Yes, MT can result into different results (from single-treaded).
The search region is halved (i forget, vertically or horizontally).
But results may be quite good anyway.

[superuser]

I am sure you use not latest 2.0.9.1 MVTools.

sorry copy paste mistake :p. below r somewht the lines I used. Currently away from the system I have script on.

function mc_degrain()
{
...
...
return MVDegrain1(last,super, vb, vf)
}

I am using the latest bundle of mvtools.


Yes, MT can result into different results (from single-treaded).
The search region is halved (i forget, vertically or horizontally).
But results may be quite good anyway.

Oh ok, if frame search region is getting halved (either on vertically or horizontally), so overall is there much speed gain when using MT. At present say for search param I use exhaustive (search=3), I think. So would it be better to use in single threaded version (without MT) and may be use search as 1 or 2 (logarithmic I think would be better) - to get expeceted results of MVtools than instead of going for fraction of speed bump using MT? What I am thinking of: if MT halves the search region and MVTools based on search parameter passed would look for more data. Coz of MT data is reduced (either on vertically or horizontally), can there be chances of artifacts? I know it is a broad ranged question, and I am putting it here as it ran through my thoughts.

[Fizick]

superuser, please read MT docs at wiki.
halved is probably my wrong term.
With MT, the full frame is divided by 2 (or more) parts., and every thread has own MVTools(Analyse+Degrain) which works in single (one) part only.
So, if object is stay at same part in a time, it is OK. If object cross parts boundary, MVTools can not find it with any search param :)
Of cource, MVTools probably will find some most similar block, but it may be other object.

[superuser]

thnxs fizicks for pointing tht out, learned something new :) ... I was confusing between SetMTMode() and MT() .... may be will try out couple 1000 frames with and without MT() to check it out more.

[AVIL]

@Fizick

I have 2 clips a, b with same framesize, same framerate, same colorspace but non related contents. Both are YUY2 clips, translated in planar form with interleaved2planar.

I do motion compensation on clip a

s=a.MVSuper(planar=true)
vf1a=s.MVAnalyse(delta=1,isb=false,truemotion=true,overlap=4,search=3,searchparam=3)
ca=a.mvcompensate(s,vf1a,planar=true)


I use same vectors to mocomp clip b:

cb=b.mvcompensate(s,vf1a,planar=true,mode=1)


I expected that cb will be a (strange) mocomped version of b. Instead is an exact copy of ca (excepted first frame what is an exact copy of b).

¿Is it correct?

[Fizick]

AVIL, you should produce other supeclip from clip b, and use it in MVCompensate instead of s.

Currently in MVCompensate the source clip is used for audio only, and at bad places: blocks with bad SAD and at scenechenges (like start of clip).

It may be discussed and changed if we found a consensus (in particully with famous trick-lover Didee! :)

[AVIL]

@Fizick

Thanks. Everything is fine now. And gain in speed is noticeable too.

[IanB]

1. All levels are used in MVAnalyse (so, generation is not a waste), but in MVAnalyse only.
MVCompensate (et al) uses finest level only. It is biggest through, especially for widely used pel=2 (and pel=4 of course). We have 4*height. coarse levels use about 1*height max.Yes, I do not fully understand the code, so maybe all the components of all the levels are always needed, I must take your word on this. But they are not all needed at the same time, there is room here for sequencing, which would allow scope for some parallel processing. Also when tight for memory it is better to recalculate a frame again than to crash because a malloc fails. And it is better to recalculate just 1 components of 1 level than the entire set for all levels when available buffers are marginal. (1 humongous composite frame either fits or does not fit. With say 16 component elements any number between 0 and 15 could still fit where a single giant frame cannot.)

2. I certainly do not want to return to RGB32 and split a chroma! I like to have native color format for every level. It was one of my aims. I like to have possibility to see every level and its padding (i already fixed 2 bugs when i saw intermediate clip :) ). We may also apply some external filter to whole super frame (or to sublevel with a mask).It's only an obvious parallelisation, if they are separate they can be calculated in parallel. Far more likely is you want to apply a filter to a level or set thereof. Having the components distinct in Avisynth terms make this easy. My previous thoughts re strings and clips or even more so with the AVSValue arrays idea, offers even simpler access for this case.

3. Anyway, I considered to split the super to finest level and coarse levels. Your suggestion is interesting. Thanks for this and others! I considered and considerer. But I am wonder, how we can multiplex frames with different width and height.If a clip is private like your, you can do whatever you like. Conventional filters may choke if things are not as expected. But each PVideoFrame has it's own shape and size and these are only the same as the VideoInfo values by polite convention. Nothing says these must match always. Just thinking outside the box.

4. Where we really waste a memory, it is in MVFlowXXX, when I build full finest clip (instead separated by pel subplanes). I succesfully impemented (non-public) version without this finest clip, but modified MVFlowFps is slower by 15 percent. Reason - too many calls (for every pixel, not to every block!) to get address of specific pel plane. I may add it as an option for testing.Yes on any CPU architecture that uses cached memory you must arrange your data for good locality. Also you want addressing in inner loops to be simple, like p+=n where n={1,2,4,8,16, ...}.

5. IanB, may CACHE_RANGE help? Can we get some memory improving if we explicitly set cache range by MVSuper(..., cache_radius=1) if we know, that there are MVAnalyse(delta=1) only?No CACHE_RANGE never helps memory usage, it always uses equal or more. Sometime it helps speed by forcing cache buffers to be kept for when they are needed again, but all cache buffers must be expendable. Remember the cache only works when a given frame is requested a 2nd time! And it is only worthwhile when the set of frames that need to be kept between the 1st and 2nd access can fit in the available memory.

So I ask the question inside point 1 above again :- Are all the components, of all the levels, always needed all together every single time?

[Fizick]

So I ask the question inside point 1 above again :- Are all the components, of all the levels, always needed all together every single time?

Thanks for discussion.

In MVAnalyse we use them all in one frame processing to estimate and produce motion vectors.
MVAnalyse firstly uses coarsest level, produces coarsest vectors, then interpolates them to finer level and uses finer levels data to estimate correspondent finer vectors, and so on up to finest level.

So, the answer is: all levels, but not it single time together.

Note: Currently motion vectors of all levels is always present in output vector clip (it is used for storage).

It is other memory problem. I consider how to decrease memory usage for vector clip (not super clip only).
Usually we use top finest levels vectors only in all clients functions (besides special MVShow). Memory is 6 doubleword per block. For small block size it is rathe big value. I consider to convert vector components to short from int and remove not-used 3 components besides SAD (it was used in MVDenoise only). I already removed waste dummy motion compensation storage from vector clip, and it helps to decrese memory usage and improve performance by several procents.


Not (closely) memory related problem: I consider to add variable block sizes to MVTools like h.264 with macroblocks say 16x16 and subparts 8x8 or even 4x4 (and / or may be others 8x16 etc). All this info will be not so easy to code, store and decode :), and it is not very compatible with current MVTools design, in particular PlaneofBlocks concept, and block overlap. And it will be need in some additional parameters (type of macroblock) and storage. I will try to find the simplest solution if it exists. May be not optimal by speed but quality.

[Amefurashi]

Got a problem here: when I serve this rather simple script in VirtualDub

mpeg2source("C:\MINORITY\VIDEO_TS\MR.d2v")

super=MVSuper()
vb=MVAnalyse(super,isb=true)
vf=MVAnalyse(super,isb=false)
MVDegrain1(super, vb, vf)

I get this error message:


http://xs432.xs.to/xs432/08430/screencap1184.png


Any ideas? I'm using AviSynth 2.5.8 RC4a... :confused:

Thanks!

[Fizick]

And what is line 11 in your script with six lines? :)

[Amefurashi]

And what is line 11 in your script with six lines? :)

Sorry, I removed the "loadplugin" lines!
It's the last one ;)

[Fizick]

it is quite possible plugins conflct. so post your full script. If you say A, say B too. :)
What version MVTools do you use? may be some other older floating around.

Whats with some other video, for example ColorBars(pixel_type="YV12")

[Didée]

The script of Amerufashi does work for me, no exception.


in particully with famous trick-lover Didee! :)
Waitaminute! Generally, I'm not such a big fan of playing tricks. However: if there's a certain operation I'd like to do, which basically seems not available from the current set of tools, but a partly approximation can be achieved by using some "tricks", then ... well, so be it.

From the point of writing a script, I've no objections against the current concept of MVSuper. It reflects the old functionality completely (i.e. there's no loss of "features"), and it avoids idx collisions. Good deal so far.

But I got a small surprise when using MVTools2 in practice. Took the script "TemporalDegrain", and modified it for MVTools2 by removing all idx'es, and supplying according MVSuper frames instead.

Comparison of original TemporalDegrain (MVTools v1.10.2.1) vs. modded TemporalDegrain (MVTools v2.0.9.1)

|frames per fixed| phys. | virt.
| time interval | memory | memory
-----+----------------+--------+--------
MVT1 | 1166 (100%) | 392k | 459k (100%)
| | |
MVT2 | 947 (81%) | 378k | 397k (86%)

Memory usage decreased by 16%. Good. Speed reduced by 19%. Not so good.
Are there any optimizations in 1.10.2.1 that are not yet implemented in 2.0.9.1 ?


Note that TemporalDegrain is not an overly complex script, it's ~relatively~ easy. In essence, it boils down to

srch = source.FFT3DFilter()
vectors = srch.MVAnalyse()
source.MVDegrain(vectors).MVDegrain(vectors)

with a few more spatial operations inbetween that skeleton.

(The complete modified function can be DL'ed here (http://www.mediafire.com/file/uyiywe3fzm0/TemporalDegrain_MVT2.avs) (Mediafire). I'm rather confident that all changes related to MVTools2 are correct.)

[thetoof]

I noticed that you're still using the old hierarchical levels reduce method... I thought that since the new "smooth motion estimation" became the default, it was some important improvement that we should benefit from.

Does it mean that some scripts like TD and TGMC must be changed to use rfilter=1 or that a proper mod for MVT2 should use rfilter=0?

[Didée]

Oh. Nah, that was only an accident.

I did the initial test without specifying rfilter at all. Then, I put "rfilter=0" to see if it makes a noticeable differences in speed (it didn't). Then I uploaded the script, still having rfilter=0 in it. That's all.

[Delerue]

Fizick, is there any way to avoid mixed frames in MVFlowFPS? I mean, sometimes is very noticeable that the last frame from take A is mixed with the first frame of take B, like this:

http://img.photobucket.com/albums/v256/Delerue/Merge.jpg

In the case above, we can't see this mix with MVFlowFPS disabled.

Thanks

[Fizick]

thetoof,
rfilter=0 or =1 are simply a little different resizers like bilinearresize and reduceby2.

Delerue,
probably this mixed frame is at scenechange?

If YES: currently at scenechages (= poor estimation with big SAD) MVFlowFPS is downgraded to simple ConvertFPS function (with blending). Probably I can add some option like blend=false, with downgrading to ChangeFPS instead (you will have one or more repeated frames at scenechanges), if you prefere it.

If NOT: provide more info.

[Delerue]

Yes, the two mixed frames come from two different (and consecutive) takes/scenes. Well, I think that repeating the frame is a better idea, because blending doesn't improve the motion, instead it mix incompatible frames that sometimes can annoy people. What you think?

[Fizick]

Delerue,
I do not know what is better in general, but I will implement blend=false option to MVFlowFps (and probably to some other functions, if requested).
We (you) prefer to repeat the previous frame always or nearest to intermediate time value (i.e. next frame if time=70 percents inbetween?) Consider changing FPS from 25 to 100 Hz.

I do not remember changeFPS logic.

[Fizick]

Didée,
all optimizations of 1.10.2.1 are implemented in 2.0.9.1. Moreover, from 1.11.4 too, which use lesser memory for vector clips.

v.2.0 use avisynth cache for superframes, and it is probably the reason for some speed decreasing if memory is low. So, iMVTools2.0 speed is more dependent on memory size. Try set SetMomoryMax to bigger value if you can. I am interested in results.

Will look to script later.

[Delerue]

I don't know, but always repeat the previous frame seems to be a good idea, and the easiest to implement, no? :)

[Didée]

Hehe, I have a little story.

Adjusted SetMemoryMax up & down (my default: 216, it's a PC with 512MB RAM), even reduced frame size to half, but no major change: The MVTools2 version was constantly slower by ~16%, with only minimal changes.

Then I remembered something: boy, on this machine here, I'm still running Avisynth v2.5.6 ...

Went ahead, installed latest Avisynth v2.5.8-RC4 ...
Result: Under 2.5.8, the processing speed of the MVTools2 version was still the same. Almost no change.

But now the catastrophe: All of a sudden, the original MVTools 1.x version was ~30% slower than before!

Or, the other way round:
Compared to running under AS v2.5.8, TemporalDegrain runs 40~45% faster under Avisynth 2.5.6!

At least that's my result here ...


I'm close to losing faith, and will keep using 2.5.6 as long as possible. I'm still stuck with this poor old slow PC, but nonetheless do fiddle a lot with pretty complex scripting stuff. Such an TREMENDOUS speed loss is definetly not an option for me, no way, not at all.

@ IanB: if you're still in search for a showstopper for 2.5.8 final - here you have mine. :)

[thetoof]

Quick tests: memory usage decreased, minimum memory decreased, speed is unchanged.

Version | frames/2:30 | SetMemoryMax | Peak Mem Usage/ VM Size
---------+-------------------+--------------+--
1.11.4.3 | It just hangs | 50 | 145/162k Unsufficient
1.11.4.3 | 310 | 200 | 300/315k ( 65.08% / 63.38% )
1.11.4.3 | 311 | 1000 | 461/497k (100.00% / 103.33% )
1.11.4.3 | 310 | undefined | 461/481k (100.00% / 100.00%)

2.0.9.1 | 308 | 50 | 114/129k ( 24.73% / 26.82% )
2.0.9.1 | 310 | 200 | 267/283k ( 57.92% / 58.84% )
2.0.9.1 | 311 | 1000 | 318/333k ( 68.98% / 69.23% )
2.0.9.1 | 308 | undefined | 318/333k ( 68.98% / 69.23% )

Avisynth 2.5.8 RC4

Script v1:
setmemorymax(x)
srch=mpeg2source("Op.d2v")
ov=4
blksize=8
pel=2
b3vec = srch.MVAnalyse(isb=true, delta=3, overlap=ov, blksize=blksize, pel=pel,idx=1)
b2vec = srch.MVAnalyse(isb=true, delta=2, overlap=ov, blksize=blksize, pel=pel,idx=1)
b1vec = srch.MVAnalyse(isb=true, delta=1, overlap=ov, blksize=blksize, pel=pel,idx=1)
f1vec = srch.MVAnalyse(isb=false, delta=1, overlap=ov, blksize=blksize, pel=pel,idx=1)
f2vec = srch.MVAnalyse(isb=false, delta=2, overlap=ov, blksize=blksize, pel=pel,idx=1)
f3vec = srch.MVAnalyse(isb=false, delta=3, overlap=ov, blksize=blksize, pel=pel,idx=1)
srch.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=1).MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=1).MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=1).MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=1)

Script v2:
setmemorymax(x)
srch=mpeg2source("Op.d2v")
ov=4
blksize=8
pel=2
srch_super = srch.MVSuper(pel=pel)
b3vec = srch_super.MVAnalyse(isb=true, delta=3, overlap=ov, blksize=blksize)
b2vec = srch_super.MVAnalyse(isb=true, delta=2, overlap=ov, blksize=blksize)
b1vec = srch_super.MVAnalyse(isb=true, delta=1, overlap=ov, blksize=blksize)
f1vec = srch_super.MVAnalyse(isb=false, delta=1, overlap=ov, blksize=blksize)
f2vec = srch_super.MVAnalyse(isb=false, delta=2, overlap=ov, blksize=blksize)
f3vec = srch_super.MVAnalyse(isb=false, delta=3, overlap=ov, blksize=blksize)
srch.MVDegrain3(srch_super,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
MVDegrain3(srch_super,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
MVDegrain3(srch_super,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
MVDegrain3(srch_super,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)


The simplified syntax of the multi branch would be more than welcome... Instead of isb/delta, a simple refframes= or tradius= is much simpler.

edit: I installed 2.5.6 Oct 28 2005 and it had no influence on the results... Can someone else confirm?

[Didée]

I'll try to test my scenario on the more beefy office PC - dated too, but at least a dual core /w 1 GB RAM.

@ thetoof: your scripts do not fully reflect that scenario. Those scripts re-use the same old stuff over and over again, so they're not that demanding on the cache system like they look like at first glance...

Modified to be similar to my TemporalDegrain test:

script1:
setmemorymax(x)
source=mpeg2source("Op.d2v")
srch=source.temporalsoften(2,2,2,20,2) # just to do something temporal here
ov=4
blksize=8
b3vec = srch.MVAnalyse(isb=true, delta=3, overlap=ov, blksize=blksize,idx=1)
b2vec = srch.MVAnalyse(isb=true, delta=2, overlap=ov, blksize=blksize,idx=1)
b1vec = srch.MVAnalyse(isb=true, delta=1, overlap=ov, blksize=blksize,idx=1)
f1vec = srch.MVAnalyse(isb=false, delta=1, overlap=ov, blksize=blksize,idx=1)
f2vec = srch.MVAnalyse(isb=false, delta=2, overlap=ov, blksize=blksize,idx=1)
f3vec = srch.MVAnalyse(isb=false, delta=3, overlap=ov, blksize=blksize,idx=1)
source.MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=2)
MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=3)
MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=4)
MVDegrain3(b1vec,f1vec,b2vec,f2vec,b3vec,f3vec,idx=5)


script2:
setmemorymax(x)
source=mpeg2source("Op.d2v")
srch=source.temporalsoften(2,2,2,20,2) # just to do something temporal here
ov=4
blksize=8
srch_super = srch.MVSuper()
b3vec = srch_super.MVAnalyse(isb=true, delta=3, overlap=ov, blksize=blksize)
b2vec = srch_super.MVAnalyse(isb=true, delta=2, overlap=ov, blksize=blksize)
b1vec = srch_super.MVAnalyse(isb=true, delta=1, overlap=ov, blksize=blksize)
f1vec = srch_super.MVAnalyse(isb=false, delta=1, overlap=ov, blksize=blksize)
f2vec = srch_super.MVAnalyse(isb=false, delta=2, overlap=ov, blksize=blksize)
f3vec = srch_super.MVAnalyse(isb=false, delta=3, overlap=ov, blksize=blksize)

super1 = source.MVSuper()
source.MVDegrain3(super1,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
super2 = last.MVSuper()
last.MVDegrain3(super2,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
super3 = last.MVSuper()
last.MVDegrain3(super3,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)
super4 = last.MVSuper()
last.MVDegrain3(super4,b1vec,f1vec,b2vec,f2vec,b3vec,f3vec)

(Better don't try that with full-HD stuff...)

[thetoof]

Oh dang, you're right. I was just about to leave, so I'll run the tests when I come back to confirm your findings.

[Fizick]

Didee,
I can confirm that 2.0 is slower for this script (did not try 2.5.6).
Small more optimal setting.
Use MVSuper(...,levels=1) if you do not MVAnalyse it (second and third item in your script).

Will research.

[IanB]

Compared to running under AS v2.5.8, TemporalDegrain runs 40~45% faster under Avisynth 2.5.6!Are you comparing apples with apples here. I think you will find 2.5.6 almost totally ignores SetMemoryMax and you are running a defacto very large cache. If you set the cache to the same resultant size the speed should be the same with 2.5.8.

These are 4 items from the change list that are related. The 1st is probably what is happening here.* Fixed Cache memory oversubscription of SetMemoryMax() limit.
* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. As per 2.5.7.
* SetCacheHints(CACHE_RANGE, n) will now surrender frames to satisfy SetMemoryMax().

[Adub]

So, then by increasing SetMemoryMax() can we reach the "40-45%" speed increase on 2.5.8 that Didee had back with 2.5.6?

I myself am using 2.57, so I am curious if a specific setmemorymax call can increase my speed as easily.

[morsa]

That thing about the scene change blending is exactly the problem I suffer everytime I do framerate conversion.

I tried sometime ago to use the mvtools scenechange detection to generate a mak an replace the frames by the ones given by changeFPS, but it seems scene change detection wasn't working reliable.

So If I had this modification applied to MVtools it will make my life a lot easier.The situation right now is that after changing framerate, I need to manually check every cut and replace frames manually, because sometimes they are just blended and someothers they are really trashed.

[IanB]

@Merlin7777,

Assuming Didée's problem is actually that the cache size he is using is to small for the script he is running, then yes setting SetMemoryMax to the appropriate value for the script in question will help a lot.

The Avisynth cache is a simple LRU scheme. If the size is insufficient to hold all the buffers between the initial request for a given frame and the subsequent request for the same frame again then the cache will be absolutely useless.

[Adub]

Is there a quick and dirty way to calculate the appropriate value for a setmemorymax line? I have 4gb (well on a 32bit xp install) and if there is a way that I can use more effectively, I would like to know if there is a procedure, or a good rule of thumb that I should use when dealing with scripts like TemporalDegrain or MC_Spuds or MCTemporalDenoise.

I seem to recall an old test that someone ran ages ago using a function that Didee wrote called "Bob" or something, with took seconds per frame to render. It would generate several scripts, all with different SetMemoryMax lines. I remember that we came to specific conclusion, something along the lines of 50-75% of total ram was optimal. I just wish I could find that thread again.


Edit: AHA!!
http://forum.doom9.org/showthread.php?t=120371

It seems half of total ram is usually a good choice.

[IanB]

something along the lines of 50-75% of total ram was optimal.Hardly! Using a sledge hammer to crack wall nuts here. Any amount more than enough to satisfy a given script will work the same! Well except for the overhead involved in managing a larger amount of memory. And of course the risk of using up the entire 32bit address space, which is of course catastrophic.

[Fizick]

i can not confirm v2.5.6 speed increasing.

[IanB]

@Fizick, and you will have a devil of a time trying. The nearest you will get to seeing the issue reliably is to compare SetMemoryMax(1) and SetMemoryMax(SomethingBig) under 2.5.8, under 2.5.6 the cache does not obey SetMemoryMax correctly so you cannot force the issue without a debugger (and some hair loss ;) ).

[Fizick]

I found, that sadx264=-1 (i.e. old) in MVAnalyse is faster option than sadx264=0 (default, auto) in v2.0.9.1 (unlike v1.X)
So, some problem with alignment.
Please somebody with modern computer confirm it.

[Fizick]

Silence.
BTW, I take back my confirmation of a big slowdown of v2.0.9.1: I stupidly used wrong version of TemporalDegrain for comparison (and had slowdown even with disabled MVAnalyse-MVDegrain :) !
(too many is floating around, and all use wrong type of sigmas for some reason BTW...).
Where is its forum thread?
http://avisynth.org/mediawiki/Temporal_Degrain



But small (not very clear) slowdown (<5%) due to some introduced checking will be removed in next version.

[Fizick]

well, new version 2.0.9.2 without any external changes :cool:
But (i hope) it is faster a little. :devil:
please report.


Nearest plan: more accurate motion search. (No various block sizes yet). For bad SAD blocks (only!) we repeat a search at finest level with large radius, probably with UMH or even ESA.
:eek:
This way some small objects would not be skipped by hierarhy.
I already implemented it, but some tuning and merging is needed (I am switched to SVN), and I am not very excited with new parameters names badSAD, badradius :)

[mikeytown2]

Here's an idea for more accurate FPS conversions: Incorporate vcmohan's WaterShed. I don't even know where to begin but it segments the pic for coloring, maybe tracking of thoes segments will help FPS conversions. Just trying to give you more ideas; something different from the typical blocks that are used in image processing.
http://avisynth.org/vcmohan/WaterShed/Watershed.html

[Adub]

Hmm... would it be possible to transplant x264's motion search code into MVtools? The reason I ask is it is already available, well tested, and probably pretty damn optimized as well. Since you mention UMH and ESA, of which x264 has had for a long time.

[Fizick]

Merlin7777,
i take them from x264 :) (with some modification). But they are not so good for true motion and big vectors.

[Fizick]

about speed, I wonder why rearranging pSrc[3] with other declarations in PlaneOfBlocks.h give 4% slowdown....

[thetoof]

(Better don't try that with full-HD stuff...)I can see no difference in speed between the two scripts.

Use MVSuper(...,levels=1) if you do not MVAnalyse it (second and third item in your script).
Is the correct usage of levels=1 like this?
pref = source.denoiser
prefsuper = pref.MVSuper(settings)
sourcesuper = source.MVSuper(levels=1,settings)
vecs = mvanalyse(prefsuper,settings)
source.mvdegrainx(sourcesuper, vecs)
I found, that sadx264=-1 (i.e. old) in MVAnalyse is faster option than sadx264=0 (default, auto) in v2.0.9.1 (unlike v1.X)
So, some problem with alignment.
Please somebody with modern computer confirm it.
About 5% speed increase here. Q6600 2.4 Ghz (no setmtmode or mt) 4GB RAM

Where is its forum thread?
It was developed in the very grainy (http://forum.doom9.org/showthread.php?t=132310) thread, though it's not its "official" thread...

But (i hope) it is faster a little. :devil:
please report.Didn't do exhaustive testing, but I noticed a 4-8% speed increase.Nearest plan: more accurate motion search. (No various block sizes yet). For bad SAD blocks (only!) we repeat a search at finest level with large radius, probably with UMH or even ESA.
:eek:
This way some small objects would not be skipped by hierarhy.
I already implemented it, but some tuning and merging is needed (I am switched to SVN), and I am not very excited with new parameters names badSAD, badradius :)
Looking forward to it! :cool:

[Fizick]

About 5% speed increase here. Q6600 2.4 Ghz (no setmtmode or mt) 4GB RAM


What sadx264 option is faster?


Well , v2.0.11.1 is released. I am not sure about status, probably alpha.

I tested wide search with badSAD=1000 for the clip with a ball (some user sent it to me): http://rapidshare.com/files/154452839/video.avi.html

seems, ball is better now.

[thetoof]

sadx264=0

edit: I'll run more tests for the sadx264
Also, you didn't answer my question about the usage of levels=x to speed up super clips that won't be mvanalysed.

[Fizick]

Your usage levels=1 is correct. (you do not MVAnalyse this super clip).

[Naito]

Well , v2.0.11.1 is released.

http://avisynth.org.ru/mvtools/mvtools-v2.0.11.2.zip -> "404 Not Found: The requested URL /mvtools/mvtools-v2.0.11.2.zip was not found on this server."

Can this someone confirm?

EDIT: Confirmed within the MVTools v1 Thread (http://forum.doom9.org/showthread.php?p=1210771#post1210771).

EDIT2: Thanks Fizick :)

[Fizick]

Yes, i can :(
Fixed :)

[Delerue]

Fizick, last night I tried to watch a 2 hours movie with MVFlowFPS using pel=2 and it crashed in a random moment (can't reproduce it when I want...). I changed to pel=1 and it didn't crash once. I don't know if it has anything to do, but until this new version (2.x.x.x) MVTools never crashed like this. The problem is that until now I never tried pel=2, hehehe. Is there any way to debug this kind of crash?

Also, any idea when blend=false will be released? :)

Thanks

[Fizick]

Delerue, it is not informative without at least version information. try various 2.0.x, and additionally control memory usage.

blend=false version will be soon :).

[Fizick]

Released v2.1.0 (build 140)
MVFlowFps, MVBlockFps, MVFlowInter: added blend parameter for ChangeFps-like mode at scene changes
MVFlowFps, MVBlockFps: more safe for big nominator and denominator.

[Mug Funky]

[edit] nm, i'm with stupid - forgot all about mvsuper

i'm getting errors :(

"MVAnalyse: wrong super clip (pseudoaudio) parameters"
script:

qtinput("blackmagic 10-bit.mov",mode=1,raw="v210")

converttoyv12()

vf=last.mvanalyse()
last

[Delerue]

Delerue, it is not informative without at least version information.

Always the last, always. :D

try various 2.0.x, and additionally control memory usage.

Ok.

blend=false version will be soon :).

Well, already released, ahn? Perfect! Thank you very much. ;)

[Fizick]

Delerue, what was "the last" exactly (to produce crash)?

[Delerue]

Delerue, what was "the last" exactly (to produce crash)?

Well, when I told you that the last version was 2.0.11.2.

[Fizick]

it is bad news if will be confirmed. :(

[superuser]

For MVtools 2 version: How do we use outfile param for MVAnalyze. These were the thoughts that had came to mind when had seen that param in documentation: More of was thinking if running two or more pass encode, in past pass can we have MVAnalyze write vectors to a output file and in second pass the output file to which vector information were written. This can help speed up MVDegrain'x' and others utility functions which uses MVAnalyse

Did search on MVTools 1 thread and found this post: http://forum.doom9.org/showpost.php?p=1075333&postcount=560 for which Fizicks already had answered. Thought will bring this up as if this functionality if not implemented can be incorporated (MVRead)

Also tried 2.1.0 MVDegrain'x' speed wise better thn 2.0.9.1 and have not seen system crash till yet which had twice when using 2.0.9.1

[Fizick]

fixed MVBlockFps (left border) in v2.1.1 and v1.11.4.5

[Shon]

mvtools it is a revolutionary thing, I do not understand many people which consider that it only a usual plug-in and in it there is nothing especial. That it it has made MANY THANKS to the Fizick that!

[AVIL]

@Shon

The art of understand the point of view of the others is a skill difficult to obtain. Despite or this I also greatly appreciate mvtools plugin and Fizick efforts.

[Fizick]

Revolutionary? But it has long history of evolution! :)

BTW, I (not intentionally! :) ) changed default search method to Hex in v2.1.1.
Now I consider to return default to Diamond in v2.1.2. But not sure. Any opinions about v2.1.1 results of motion search?

[Shon]

Mvtools2 Does movements much more smoothly, but artefacts became more,
and in mvtools1 them it is visible in one places, and in the second version they appear in other scenes.
Strangely enough but trimension DNM (windvd) in such difficult scenes cannot make interpolation.http://i423.photobucket.com/albums/pp313/Shon198/mvtools1.jpghttp://i423.photobucket.com/albums/pp313/Shon198/mvtools2.jpg

[Fizick]

I try figure the difference of vectors v2.x from v1.x :

v2.0.9.2 and above always check (calculate SAD) the hierarhycal predictor,
but v1.x does not test it, if the predictor vector is same as already checked zero vector or global motion vector.
(these special vectors have some penalty pzero if pzero>0, but hierarhycal predictor has not any penalty).
So, zero predictor is more stable in v2 (other vectors have pnew penalty and lambda penalty).
Comment: It is not the "the only possible way", and I almost forgot about this change :), but it is implemented so.

v2.0.11 and above have new hexagon search method (=4) as default insted of Logariphmic (=2) due to some mess.
Comment: same as above.

Anyway, these difference are not very big, and I am wonde so big changes at your pictures.
what versions and script do you use? (short clip?)

[Delerue]

Shon, you're using MVFlowFPS, right? Try to use this two parameters (with version 2.x):

ThSCD1=350, blend=false

Put this inside the call of MVFlowFPS function. Example:

super = source.MVSuper(pel=2)
backward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = true, search=3)
forward_vec = MVAnalyse(super, blksize=8, overlap=0, isb = false, search=3)
source.MVFlowFps(super, ThSCD1=350, blend=false, backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source))

blend=false -> doesn't blend (mix) at scene changes, but...
ThSCD1=350 -> when ThSCD1 isn't changed, the default value is '400', and with some similar consecutive scenes (as yours), MVFlowFPS 'thinks' that's the same scene, so it mess everything. You can try other values besides '350'. I'm still testing it, and '350' seems to be better than '400'. The problem is that it's almost impossible to find a perfect value, because lowering 'ThSCD1' value mess with fast scene, and higher values mess with similar consecutive scenes. I can't remember what TrimensionDNM does in these situations (although I remember TrimensionDNM as a very good motion estimation algorithm), but maybe Fizick can think in a better solution to this problem.

[morsa]

Just to let you know that the new 2.x branch is really a big step forward in stability.
I can't say much about image quality (yet) but I hope to find out in coming days.

Amazing work.Congrats!! :D

[Fizick]

Delerue,
yes this dumb threshold ThSCD1 is not very clever. May be some adaptive or relative (to several previous frames) wolid be better. Who knows.
Suggestions?

[Terranigma]

Any chance we can see an 8x2 blocksize ?

[Fizick]

Terranigma, I have no it in my "to do" list.

EDIT: "no" is not "now" but "not" . sorry.

[Terranigma]

Terranigma, I have no it in my "to do" list.

OK Cool. Thanks! :D

[Delerue]

Delerue,
yes this dumb threshold ThSCD1 is not very clever. May be some adaptive or relative (to several previous frames) wolid be better. Who knows.
Suggestions?

It's hard to think in a solution that doesn't kill the CPU, hehehe. Serious, to me the real problem is performance. Otherwise, you could try to search a group of pixels in X frames behind and forward, and search it in the whole frame, and if this search returns something, than we're probably in the same scene. Well, but that's what you said with 'relative (to several previous frames)', right? :)

[Fizick]

no, i say about comparing SAD not to constant, but some floating value, dependent on history.

[AVIL]

@Fizick

a) A question about the values of mvmask(kind=3 or 4). When pel>1, the vector components are fractionary and will be rounded or the value are multiplied by pel or what?

b) About ThSCD1.

Perhaps using relative differences instead absolute differences could make predictions more robust against noise.

Another idea is to use difference of SAD's.

If a scene is stationary then succesive block sads are near to zero. Difference is (almost) constant between a frame and the next.

If the scene is panning blocks sad are higher but probabily constants in value across frames. Differece is again constant between a frame and the next.

In a scene change, block sad will be simillar to the previous frame one and very different than the next.

[Fizick]

a) from the doc: "...in pel units". So, in halfpel units for pel=2. for example, 25 halfpels, exactly as founded by search. Not rounded.

[AVIL]

I'll see now. Thanks and sorry.

[Fizick]

Shon,
After more deep digging, I found that v2.0.11 and above use wrong scaling of LSAD (and BadSAD) for non 8x8 blocks.
It is fixed in released v2.2.1

[Naito]

Suggestion: Offical renaming to "mvtools2.dll" to avoid confusion with the v1-Branch.

[Shon]

Fizick
Thanks, became now much better!:thanks:
blksize=32x16 well works, if still that I will notice I will necessarily inform!:)

[Fizick]

Naito,
it is worth to consider.

[AVIL]

Version 2.2.1 crashes with yuy2 clips, even with simple scripts:

setmemorymax(256)

Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\ssetools.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\mvtools2.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\nnedi.dll")
Loadplugin("D:\Mis documentos\MiSoft\MULTIMEDIA\Video\Proceso_edicion\Avisynth\plugins2\yadifmod.dll")


x0=avisource("Bautizo veronica.avi").assumetff()
y=x0.nnedi(field=3)
x=x0.Yadifmod(mode=1,edeint=y)

s=x.MVSuper()

vf1y=s.MVAnalyse(delta=1,isb=false,truemotion=true)

x.mvcompensate(s,vf1y,thSAD=350)


In planar form don't crashes but image is distorted
Converting clip to YV12 make dissapear le problem.

[Fizick]

AVIL,
what older version (if any) worked fine?

[AVIL]

2.1.1 works fine

[Fizick]

confirmed the bug at scanechanges

[LaTo]

Bug report:
chroma=false in MVSuper produces black output in MVDegrain (with plane=0)...

MVSchroma= #true or false

mvs=MVsuper(last, chroma=MVSchroma)

v1b=MVanalyse(mvs, isb=true, delta=1, chroma=false)
v1f=MVanalyse(mvs, isb=false, delta=1, chroma=false)

MVdegrain1(last, mvs, v1b, v1f, plane=0)
With MVSchroma=true it's okay, but MVSchroma=false it's bugged

[Fizick]

LaTo,
fixed in v2.2.2

Naito,
I am not sure about renaming to MVTools2.dll and coexisting with v1.x mvtools.dll (in plugin folder)
please discuss.

[LaTo]

LaTo,
fixed in v2.2.2
Thanks!

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

[Jawed]

For a bit of extra performance/reduction in memory usage when doing pre-filtering on a calm_super clip, specifying levels=1 works for the source_super clip:

source_super = source.MSuper(pel=2, hpad=16, vpad=16, levels=1) # create the source superclip
Jawed

[yup]

Hi folks!
I use simple script from doc
LoadPlugin("MT.dll")
SetMemoryMax(1024)
SetMTMode(5)
AVISource("sel.avi") # или MPEG2Source, DirectShowSource, некоторый предыдущий фильтр

SetMTMode(2)
super = MSuper(pel=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

[img=http://img301.imageshack.us/img301/2894/mtmvtoolserrorkd9.th.png] (http://img301.imageshack.us/my.php?image=mtmvtoolserrorkd9.png)
MT 0.7 (I replace avisynth.dll at windows\system32 directory)
MVTools 2.31
Avisynth 2.58
Windows XP SP3
Core 2 Duo 3.16
Source huffyuf encoded.

Please advice.
yup.

[yup]

Hi!
Folowing script:
LoadPlugin("MT.dll")
avisource("sel.avi")
MT("""
super=MSuper(pel=2,sharp=1)
backward_vec2=MAnalyse(super,isb=true,delta=2,overlap=4)
backward_vec1=MAnalyse(super,isb=true, delta=1,overlap=4)
forward_vec1=MAnalyse(super,isb=false,delta = 1,overlap=4)
forward_vec2=MAnalyse(super,isb=false,delta=2,overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
""",2)
work without problem.
yup.

[Fizick]

yup,
To be precise, it is NOT exact script from the doc.

[yup]

Fizick!
From doc
SetMTMode(5)
FFmpegSource("some.avi") # avisource не работает с SetMTMode на моих машинах - TSchniede

SetMTMode(2)
super = MSuper(pel=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)

my script
LoadPlugin("MT.dll")
SetMemoryMax(1024)
SetMTMode(5)
AVISource("sel.avi") # или MPEG2Source, DirectShowSource, некоторый предыдущий фильтр

SetMTMode(2)
super = MSuper(pel=2)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
I use AVISource instead of FFMpegSource or I could not use LoadPlugin("MT.dll")?
This different thing modified avisynth.dll and plugin mt.dll?
But why second scrip work?
Where trick?
yup.

[thetoof]

Have you tried with ffmpegsource?
TSchniede clearly says that "avisource doesn't work with SetMTMode on [his] machines"

[Fizick]

Yup,
i know why MT(""" script work. It must work :)
But I do no know exactly, why the first your script (SetMTMode) does not work. Try to use FFPEGSource, or other codecs. And also try various sadx264 modes. I am not sure.
Please report your results here.

[halsboss]

had trouble with ffmpegsource, see other thread. see how your own luck holds. avisource seems to work for me don't know why.

[cwk]

I cannot access Fizick's website: http://avisynth.org.ru/

I get the following error:
The browser could not find the host server for the provided address.

Is anyone else having the same problem?

[jeffy]

@cwk:
http://forum.doom9.org/showthread.php?p=1246713#post1246713
http://forum.doom9.org/showthread.php?t=144849

[cwk]

Thanks Jeffy.

ck

[yup]

Hi Fizick & thetoof!
Thanks to advice.
I downloaded FFMpegsource2
http://ivtc.org/new/beta/FFmpegSource-2.00b4.rar
change AVISource to FFVideoSource in my script and now all work fine.
yup.

[Blue_MiSfit]

@cwk:

Yes, I also can't get on avisynth.org.ru... :(

~MiSfit

[Terranigma]

It's working now. :)

[McCauley]

Hi,

is there a way this script could be converted to MVTools2?
##############################################################################
#Original script by g-force converted into a stand alone script by McCauley #
#latest version from December 10, 2008 #
##############################################################################

function Stab (clip clp, int "range", int "dxmax", int "dymax") {

range = default(range, 1)
dxmax = default(dxmax, 4)
dymax = default(dymax, 4)

temp = clp.TemporalSoften(7,255,255,25,2)
inter = Interleave(temp.Repair(clp.TemporalSoften(1,255,255,25,2)),clp)
mdata = DePanEstimate(inter,range=range,trust=0,dxmax=dxmax,dymax=dymax)

DePan(inter,data=mdata,offset=-1)
SelectEvery(2,0) }
As far as i understand the documentation it is not possible, because of the Lack of certain parameters.
Is there a speed gain to be expected with MVTools2?

Regards and thanks in advance
McCauley

[Sagekilla]

That script doesn't use MVtools. There's no need to "convert" it to MVTools 2.

[McCauley]

That script doesn't use MVtools. I am aware of that. But i want to know if there's a speed gain to be expected if it does. Hint: MDepan

There's no need to "convert" it to MVTools 2.That is what i'm asking.

Regards
McCauley

[pbristow]

Not a question, but a compliment:

I've been working with AVISynth for about 2 years; I've been learning and using MVTools2 for just a few weeks now, reading about and trying out a new filter every few days, and I have to say it is the most thorough, well designed and professional piece of work I've seen in a long time! It's a real joy to study and play with. Congratulations to Fizick and everyone else who helped.

The documentation is excellent too, despite occasional (small) English language errors! =:o} It's brought back my joy in studying complex technical stuff.

[Fizick]

pbristow,
thanks.
can you can correct (small) English language errors produced by developers from France, Russia, Denmark and Germany ?
;)

[SEt]

After playing with my aWarpSharp i went to optimize something more useful. Here is modified version of MVTools 2.4.2: http://pavelsx.googlepages.com/mvtools-v2.4.2_mod.rar
I did some source/project settings cleanup and optimized primary for MDegrain1/2/3 - depending on your settings you'll probably see 2-15% speedup, results are bit-identical to original 2.4.2.

[tedkunich]

After playing with my aWarpSharp i went to optimize something more useful. Here is modified version of MVTools 2.4.2: http://pavelsx.googlepages.com/mvtools-v2.4.2_mod.rar
I did some source/project settings cleanup and optimized primary for MDegrain1/2/3 - depending on your settings you'll probably see 2-15% speedup, results are bit-identical to original 2.4.2.

SEt,

Thanks for the update! I try to get some test results this evening - the only script that I tried so far saw about a 0.5% speed increase with the new filter. (results are not realistic as MDegrain2 was never really the bottleneck)

T

[SEt]

Corrected threading problems, minor optimizations: http://pavelsx.googlepages.com/mvtools-v2.4.2_mod2.rar

[tedkunich]

Corrected threading problems, minor optimizations: http://pavelsx.googlepages.com/mvtools-v2.4.2_mod2.rar

SEt,

Sorry, forgot to post some numbers last week....

Using Mdegrain2, I saw about a 5% speed increase on my quad core AMD, processing SD material. I'll try out your threadding patches in the next few days, as I still get some locked threads (even after quitting Vdub, I see a Vdub procees still running a 25% CPU).

Thanks,

T

[Fizick]

SEt, thanks for your efforts :)
I have some to start revise your mod.
Can I ask, why did you change :

SECTION .rodata data align=16

to

SECTION .rodata align=16

in NASM code?

[SEt]

Because it caused section to be read-write instead of read-only, so the resulting dll had 2 .rodata sections: one read-only and one read-write.

[Fizick]

I merged all SEt mods in new released v2.4.4, besides avisynth.h (replaced by official v2.5.8) and VC2005 project files (anyway I use Codeblocks with VC Toolkit 2003 :) )

threading problems?

[SEt]

Well, i changed avisynth.h not out of nowhere:

0xffffffff80000000 as i remember C/C++ standard is actually 0x80000000 (unsigned int constant) and promoting it uint64_t leads to 0x0000000080000000 what is incorrect. VS as usual compiles it its own way, but GCC warns about constant truncation.
void Release() { if (refcount==1) InterlockedDecrement(&vfb->refcount); InterlockedDecrement((long *)&refcount); }is definitely not thread safe and
~VideoFrame() { InterlockedDecrement(&vfb->refcount); }is also suspicious (but never actually called).
virtual __stdcall ~IClip() {}
VS silently ignores it and compiles some kind of __thiscall here. Intel warns that __stdcall is ignored and GCC floods you with errors if you don't redefine destructors in all derived classes as __stdcall (seems like calling convention isn't inherited for default destructors).

[niiyan]

@Fizick
I can't download MVTools v2.4.5.

[Fizick]

I temporary removed it. I was not sure is any bug in avisynth.h from 2.5.8MT or not.

[niiyan]

I see. I'll wait until v2.4.5 is back. Thanks.

[tormento]

Why this project has frozen?

[Emulgator]

While trying MVTools 2.5.10.1 to interpolate frames (MFlowInter)
it seems to me that changes to thSCD1, thSCD2 and blend are not respected.
Can anybody repeat this ?
Source is a 24p clip where 2 frames had been burnt and cut off.
These were to be interpolated.
blksize=8 gave too many artifacts, so I choose blksize=16
which had helped in the past to have more coherent vectors.

But blksize=16 led to interpretation as a scenechange and in consequence to 2 blended frames.

OK, so I would raise thSCD1 and SCD2, but no change in response.
While setting blend to false, no changes. The 2 inserted frames still stayed blended.

MShow shows vectors before and after, but not for the two frames that mark the gap,
so i guess that MAnalyse throws a scene change here.

#..............................Part of a frame interpolation script based on MVTools 2
blksz=8 # Blocksize for Motion search. Default = 8. 4: many artefacts with poor sources, 16 being smoother.
searchp=32 # Radius for Motion search. Default = 2. KungFu: For Blocksize=16 searchp up to 32 helped.
bld=true # Decides what to do if a Scenechange is detected by the following parameters: true will blend, false will repeat previous frame.
SCDpb=400 # Default = 400. SAD (pixels*luma values) Threshold per Block. A Block exceeding this SAD is considered changed.
## SAD = Sum of Absolute Differences = Number of pixels per 8x8 block (=64) multiplied with their luma difference.
## SCDpb is always given related to 8x8 blocks and scaled internally to match other block sizes. SCDbp is thSCD1 and is evaluated before SCDpf=thSCD2
SCDpf=130 # 0-255, Default=130. Changed Blocks threshold per frame.
## This Threshold sets which minimal percentage of changed blocks a frame has to contain to be considered as a scene change.
#..............................................................................................................End of Input Parameters.................................................................................................................................................................
IsYUY2 ? NOP : IsYV12 ? NOP : ConvertToYV12(IsFieldBased) # MVTools need YUY2 or YV12 !
pixtyp=IsYV12 ? "YV12" : IsYUY2 ? "YUY2" : "Unspported"
source=last
super=MSuper(source, pel=4, rfilter=3)
backward_vectors=MAnalyse(super, blksize=blksz, search=5, searchparam=searchp, isb=true, delta=1, temporal=false, dct=0, divide=0, trymany=false)#delta=framedistance;isb=IS Backward
forward_vectors=MAnalyse(super, blksize=blksz, search=5, searchparam=searchp, isb=false, delta=1, temporal=false, dct=0, divide=0, trymany=false)#search 3:=Exhaustive; 4:=Hex(default); 5:=UMH
#....other inter clips
interthirtythree=MFlowInter(super, backward_vectors, forward_vectors, time=33, ml=70, blend=bld, thSCD1=SCDpb, thSCD2=SCDpf)
#....other inter clips
intersixtyseven=MFlowInter(super, backward_vectors, forward_vectors, time=67, ml=70, blend=bld, thSCD1=SCDpb, thSCD2=SCDpf)
#...other interclips
function framerest(int insertbefore, int insertlength, clip src,[*...other clips...,*] clip thirtythree,[*...other clips...,*] \
clip sixtyseven,[*...other clips...,*] int wide, int high, float framespersec, string pixtyp, int audch, int audbit, int audsamp)
{
insertlength==-1 ? blankclip(length=0, width=wide, height=high, pixel_type=pixtyp, fps=framespersec, stereo=true, sixteen_bit=true, audio_rate=audsamp) : \
#.....other insertlengths....
insertlength==2 ? thirtythree.trim(insertbefore-1,-1) ++ sixtyseven.trim(insertbefore-1,-1) ++ src.trim(insertbefore,-1) : \
#...other insertlengths....
: blankclip(length=0, width=wide, height=high, pixel_type=pixtyp, fps=framespersec, stereo=true, sixteen_bit=true, audio_rate=audsamp)
return(last)
}
interA=framerest(insertbeforeA, insertlengthA, source,[*...other clips..., *] interthirtythree,[*...other clips...,*] intersixtyseven,[*...other clips...,*] width, height, framerate, pixtyp, audch, audbit, audsamp)
insertlengthA!=-1 ? source.trim(0, insertbeforeA-0==1 ? -1 : insertbeforeA-1)++interA++\
#....lots of other interclips here...
: source.trim(insertbeforeA+1, 0)) : source
#MShow(super, forward_vectors)
MShow(super, backward_vectors)

[Emulgator]

Solution found:

The version 2.5.10.1 mod16a version contained in dither1.3 by Firesledge
has this fixed and respects thSCD changes.

http://ldesoras.free.fr/

[Fizick]

Emulgator,
I can not confirm your bug report.
This bug was in older version 2.5.10.
Are you sure, that you load latest version 2.5.10.1 from my site?
May be some older version is floated around at your system? How do you load mvtools2.dll?

[Emulgator]

I loaded mvtools2.dll not by extra call from extra directory, only by autoload from normal plugins directory.
mvtools 1.11.4.5 resides in the same directory.
It may well be that something 2.5.10 was floating around before,
I think I updated to 2.5.10.1 from avisynth.ru and erased the 2.5.10.dll.
As the fault happened I was confirming by "Properties"
and I think I remembered seeing version 2.5.10.1.

(Late Edit: No, I was remembering wrong:
I actually saw 2.5.10 and thought: Maybe the name edit had been forgotten)

But many thanks anyway, Fizick, all is fixed and running now.

[Emulgator]

Late Edit: It looks like driver error on my side.
I guess the previously downloaded mvtools2.zip containing 2.5.10 had been cached
and coughed up a second time by my browser when I meant to download 2.5.10.1.
I just had the same scenario with DGAVCIndexDI not bringing the just introduced Manual update.
Erasing my Browser cache helped !
I should empty my browser cache more often.
Please accept my apologies.