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.