MVTools

[josey_wells]

OK here is fix for blocksize 16

http://rapidshare.com/files/13779570...9.6.7.rar.html

Hopefully last issue

[Fizick]

thanks for fast develpment!
some questions:

Originally Posted by josey_wells

1. A multitude of memory fragmentation and alignment problems have been fixed.

Magnitude was fixed? How it is important?

Originally Posted by josey_wells

2. A bug in YUY2 planes have been fixed.

Please be more specific, where was the bug. Your code has massive cosmetic changes (rewriting) and it is difficult to analyse and compare. Comments (marks) in changed code will be very useful. IMHO, it wold be better do not touch working code lines.

Originally Posted by josey_wells

6. I have fixed several other stability problems. The worst being where a destructor was called twice after the object was detroyed.

Same question, where?

Originally Posted by josey_wells

3. At more than one hundred of places delete was used where delete [] was needed.

Opps, will fix it. But they are probably all in filters (not frame) destructor, so not so important (do not use Animate with MTtools .

Originally Posted by josey_wells

4. All the filters are being updated to not ask for frames if not needed, i.e. already in cache. Filters will need testing after this because of the scope of changes. This will also prep them to become multithreaded as time permits.

dont quite understand it, but have a question. Your AnaliseMulti function calculate all "mult" stacked frames at once or needed (requsted) only?

Originally Posted by josey_wells

5. I want to redo the cache mechanism for idx since I believe it can be made clearner using the STL map class.

Some time ago I wrote, that it is better (IMO) to remove idx completely and replace it with MVPrepare, to use normal Avisynth cache (may be v.2.6)

Originally Posted by josey_wells

Although I doubt this will ever be officially adopted and always remain a branch.

really I am not official person.
However, due to combination of your new great lines of code with massive cosmetic changes (all those ++, etc) it is hardly to check (understand) and continue development (for me). For example, now I try implement Didee's request, based on v1.9.5.7 (and may be even older version).

But what is bad with "branch" if you and people will use it?
May be some day other developer will continue. Its open source world.

[IanB]

@Fizick,

Now you understand why a lot of open source projects only accept changes in the form of diff patches.

Diff patch submission encourages the submitter to express their idea in a tidy concise form. The more concise and tidy the quicker it gets reviewed, accepted and imported into the core source.

It stops senseless reformatting with just white space changes, that makes the job of the integrator that much harder, by playing on the pride of the submitter. Nobody wants to get a reputation for submitting patches that delete all the lines and insert all these new ones.


@josey_wells,

You have done much good work here. I would encourage you to take a few hours to review all your changes with a good source diff program (M$ windiff is reasonable) and remove all the white space and white code changes you have made so the real changes you have made can shine out.

[thetoof]

Woah, some awesome development was made here in a short while!
As for what happens with mvtools... imo it'd be a shame to have 2 branches, 1 "official" and 1 multi-threaded with a new concise syntax... but maybe no implementation of further development. What IanB suggested seems to be the best solution for everybody, even if it's more work for you, josey_wells, who already gave us a lot of your time. Thanks.

Anyways, on with my request: I have yet to read all the posts and understand fully the new syntax, so I was wondering if someone could post a modded version of MCBob, TempGaussMC_beta1 and TemporalDegrain since they are very ressource hungry and that the speed boost we can now have would be more than welcome.

[mikeytown2]

Here are the 2 MC scripts that I use, haven't used TemporalDegrain so maybe someone else can upload their mod's.
http://rapidshare.com/files/13791035...ussMC.zip.html

In my MCbob I call the dll version of Vinverse, it's also the nnedi version

[Leak]

Originally Posted by IanB

a good source diff program (M$ windiff is reasonable)

I'd suggest WinMerge if I may...

[josey_wells]

Originally Posted by Fizick

Magnitude was fixed? How it is important?

I fixed several places in the code and don't want to list this all. Here is a good example.

 blocks = new FakeBlockData*[nBlkCount];
for ( int j = 0, blkIdx = 0; j < nBlkY; j++ )
    for ( int i = 0; i < nBlkX; i++, blkIdx++ )
        blocks[blkIdx] = new FakeBlockData(i * (nBlkSizeX - nOverlapX), j * (nBlkSizeY - nOverlapY));

was replaced by

 blocks = new FakeBlockData[nBlkCount];
int blkYSpace=(nBlkSizeY - nOverlapY);
int blkXSpace=(nBlkSizeX - nOverlapX);
int blkIdx=0;
for ( int j = 0; j < nBlkY; ++j ) {
    int j1 = j * blkYSpace;
    for ( int i = 0; i < nBlkX; ++i)  
        blocks[blkIdx++].Init(i * blkXSpace, j1);
}

While the first one works and is functional code. It can do up to 20000 news on DVD video and closer to 140000 on HD video. I replaced with a single new and then inited each which allocates a single block of memory for the advantage of faster access and less fragmentation.

Originally Posted by Fizick

Please be more specific, where was the bug. Your code has massive cosmetic changes (rewriting) and it is difficult to analyse and compare. Comments (marks) in changed code will be very useful. IMHO, it wold be better do not touch working code lines.

 const int awidth = min(nSrcPitchYUY2>>1, (nWidth+7) & -8);

While I haven't worked it out to see whether the complement of -8 gives the correct bits the way it should be expressed is ~0x7 or ~7 depending on your preference.

Originally Posted by Fizick

Same question, where?

class MVClip : public GenericVideoFilter, public FakeGroupOfPlanes, public MVAnalysisData {
...
}

MVClip::~MVClip()
{
FakeGroupOfPlanes::~FakeGroupOfPlanes(); //v1.2.1
}

When the class derives from a base class, the destructor is called automatically. So the call in the destructor of MVClip results in a second call since the base class was destroyed first. I acutally changed fakegroupofplanes to be a pointer member which does require an explicit delete to invoke the destructor.

Originally Posted by Fizick

Opps, will fix it. But they are probably all in filters (not frame) destructor, so not so important (do not use Animate with MTtools .

Almost all of them were in the destuctors of the filters where in the constructor new x[y] was performed and delete y was done instead of delete [] y. In most cases would not cause a problem except when possibly exiting virtualdub or loading a new script etc.

Originally Posted by Fizick

dont quite understand it, but have a question. Your AnaliseMulti function calculate all "mult" stacked frames at once or needed (requsted) only?
Some time ago I wrote, that it is better (IMO) to remove idx completely and replace it with MVPrepare, to use normal Avisynth cache (may be v.2.6)

All multi stacked frames are calculated at once one in each thread. This was how a great performance improvment could be achieved.

I haven't done anything to the cache mechanism yet. I agree that it needs an overhaul or removal but I dont't want to take on that task now.

Originally Posted by Fizick

However, due to combination of your new great lines of code with massive cosmetic changes (all those ++, etc) it is hardly to check (understand) and continue development (for me). For example, now I try implement Didee's request, based on v1.9.5.7 (and may be even older version).

But what is bad with "branch" if you and people will use it?
May be some day other developer will continue. Its open source world.

I think the code is actually easier to understand now in a lot of cases since I took out code that was repeated in every filter and created some new class functions to perform the same purpose. This resulted in smaller code which is easier to see what is really happening.

Also I see nothing wrong with white space changes. www.perforce.com has a great diff program called p4diff which is free. It can be used to diff my files against originals to see only real code changes. May modern diff programs can be used to ignore line endings and white spaces.

Also there is a multitude of changes due to the addition of threading class, semaphore class, critical section class, thread files for MVDegrain, MVAnalyseMulti as well as factoring out common code for MVDegrain into a single base class moving out common code etc.

In the end all I did was just some code consilidation, bug fixes, performance improvements, and multithreading. While it took me a long time I do not take any credit for the algorithms as all I did was make them run better, faster, and more reliably.

I would be interested in performance results.

I could also look at mulithreading some of the other functions. The impact of the functions can be evaluated by doing the following:

c=last
MVMulti=c.MVAnalyseMulti(refframes=x, ...)
c.MVShow(MVMulti.MVMultiExtract(0))

This will force MVAnalyseMulti to run and when MVFLow, MVFps, etc. are added to the script the performance hit can be evaluated as to whether mulithreading will provde performance benifit.

[Fizick]

 const int awidth = min(nSrcPitchYUY2>>1, (nWidth+7) & -8);

IMO, this code is correct and not a bug. There was no any need to rewrite it.

Thanks, I will remove ~FakeGroupOfPlanes();
Why you did not simply remove it?

About stacked multi frames. So, even if some filter use MVExtract to extract one vector subframe, all rest unneeded multi stacked vectors will be calculated?

[josey_wells]

Originally Posted by Fizick

IMO, this code is correct and not a bug. There was no any need to rewrite it.

I looked up two's complement for -8 and it has the same reprensentation as ~0x7. So yes this line would actually work as originally written.

Originally Posted by Fizick

About stacked multi frames. So, even if some filter use MVExtract to extract one vector subframe, all rest unneeded multi stacked vectors will be calculated?

The first reference to MVMultiExtract will cause a full evaluation of all the requested frames in MVAnalyseMulti. Subsequent request to MVMultiExtracts will cause no extra computation since all frames have already been completed. The only way I could perform threading was to thread the computation of the frame calculations.

[Fizick]

Thanks for clarification!

[EuropeanMan]

Nerds all of you!

J/K -wonderful work done here! Can't wait to start testing! thanks to josie & fizick for sweet filters... Keep on rockin!

[egrimisu]

Where can i find the latest version of MVTools optimized for multithread?

[Ranguvar]

Err... download the latest package josey_wells has posted... top of this thread...

[Fizick]

1. I tried latest version on old Ahtlon 64, so I use classic MVAnalyse-MVDegrain2 script.
The speed is about 8 fps (blksize=16, overlap4).
But I have 10 fps with v1.9.5.7 for same script.
BTW, I recompile v1.9.6.7 with my development env (VCToolkit2003), but speed is still 8 fps.
Disabling mt=false do nothing.

2. I sent preliminary v1.10 with MVRecalculate to Didee for testing.

[mikeytown2]

Is there any way to improve MVAnalyse? This is moving 10 px per frame, no sub pixels yet it still is giving a fairly low PSNR of 45.96

Global b = ColorBars(320,240, "YUY2").Trim(0,64)

Function ttt(clip c, int x, int y)
{
	c.Overlay(b,x,y)
	#~ Subtitle(String(x), Align=2)
}
BlankClip(b,64, 640,480)
F30 = Animate(0,32, "ttt", 0,120, 320,120)
F60 = Animate(0,64, "ttt", 0,120, 320,120).Trim(0,62)


vectors=F30.mvtools_MVAnalyseMulti(blksize=16, overlap=8, divide=2, idx=1, dct=4, truemotion=true, pel=2, search=0, searchparam=0, lambda=2700, sadx264=7, pnew=9)
bw1_vec1=vectors.mvtools_MVMultiExtract(0)
fw1_vec1=vectors.mvtools_MVMultiExtract(1)
F60_2=F30.mvtools_MVFlowFps(bw1_vec1, fw1_vec1, num=60000,den=1001).Trim(0,62)

Compare(F60_2, F60)
StackHorizontal(last,StackComparer(F60_2,F60, ""))
SelectOdd()

Function StackComparer(clip x, clip y, string s)
{
	sb1=Subtract(x,y)
	sb1=Overlay(sb1.Levels(128,1,130,0,255), 
	\ sb1.Levels(126,1,128,0,255).PointResize(640*4,480*4).ConvertToYUY2().Invert("y").ConvertToRGB32().PointResize(640,480)
	\ ,mode="add").Levels(34,1,255,0,255).Subtitle("Black pixels means less/no change")
	sb1
}

Ideally this should be able to hit close to 100

[IanB]

...
F30 = F60.SelectEven() # Avoid Overlay chroma subsabsampling
...

[mikeytown2]

Still get the same PSNR of 45.96

Global b = ColorBars(320,240, "YUY2").Trim(0,64)

Function ttt(clip c, int x, int y)
{
	c.Overlay(b,x,y)
	#~ Subtitle(String(x), Align=2)
}
BlankClip(b,64, 640,480)
F60 = Animate(0,64, "ttt", 0,120, 320,120).Trim(0,62)
F30 = F60.SelectEven().AssumeFPS("ntsc_video")


vectors=F30.mvtools_MVAnalyseMulti(blksize=16, overlap=8, divide=2, idx=1, dct=4, truemotion=true, pel=2, search=0, searchparam=0, lambda=2700, sadx264=7, pnew=9)
bw1_vec1=vectors.mvtools_MVMultiExtract(0)
fw1_vec1=vectors.mvtools_MVMultiExtract(1)
F60_2=F30.mvtools_MVFlowFps(bw1_vec1, fw1_vec1, num=60000,den=1001).Trim(0,62)


Compare(F60_2, F60)
StackHorizontal(last,StackComparer(F60_2,F60, ""))
SelectOdd()

#~ F60

Function StackComparer(clip x, clip y, string s)
{
	sb1=Subtract(x,y)
	sb1=Overlay(sb1.Levels(128,1,130,0,255), 
	\ sb1.Levels(126,1,128,0,255).PointResize(640*4,480*4).ConvertToYUY2().Invert("y").ConvertToRGB32().PointResize(640,480)
	\ ,mode="add").Levels(34,1,255,0,255).Subtitle("Black pixels means less/no change")
	sb1
}

[morsa]

No matter what I do or what kind of script I use, when calling MVAnalyseMulti, the scripts just exit after ~800 frames.

Image size is 1920x1080 / 1088 .I tried using 1920x540 / 544 with same results

[jeffy]

@morsa:
Have you tried SetMemoryMax(512) or less at the beginning of your script? Does your source file use DirectShowSource for loading?

[Dark Shikari]

Bug report from Kokotier:

Hello I have found a bug.
Download this steam http://rapidshare.com/files/13884330...muxed.zip.html
Load it (MPEG2 file) in avisynth and add those lines to the avisynth script:
source=last
MVForBack = source.MVAnalyseMulti(refframes=1, pel = 2, overlap=2, overlapv=2, sharp=1, idx = 1,blksize=16,search=3,chroma=true,global=true)
source.mvshow(MVForBack)

Look at the frame just before the scenechange, motiondetection is totaly broken.