MVTools

[Boulder]

I wouldn't say that it's one or the other as the docs say that "Interpolated vectors of old blocks are used as predictors for new vectors".

Fizick definitely isn't a writer of clear documentation as he has many times said himself

[Dogway]

Then it would be good someone to confirm it, because I have never seen that approach. QTGMC, interframe, Killer, FizzKiller, etc all use the same processed super for manalyse and mrecalculate.

[-Vit-]

Documentation states that SAD is recalculated, so you should be able to change both super and settings if you have reason.

MRecalculate is not only useful for bad sources, it can help generally. Large block sizes are good for large areas moving fairly simply, they are not confused by complex / repeated patterns within the image and tend to be more stable even on fairly low contrast areas. However, they will not capture edges or small objects well, and are confused by more complex motion when large blocks change too much. Smaller blocks will capture fine motion detail, edges and more complex motion, but they more easily make mistakes. Consequently a large->small block recalculate can capture the best of both. Start with the large block attempt, then refine where the smaller blocks feel it is necessary. Smaller block recalculation uses settings that avoid changing the original vectors too much without compelling reason (balance the improvement in SAD against reduction in coherence, lambda & pnew). In such a context, and especially with a good source, I see reason to filter less (or differently) on the super for the MRecalculate - initial large block pass aims for stability, smaller block pass for detail. But as ever with MVTools, the theory sounds cleaner than the practice...

The mythical next version of QTGMC already supports multiple levels of MRecalculate as an option, I have been intending to experiment with different pre-filters for the reasons above (and also try the interesting concept that I *think* Boulder was referring to earlier: MRecalculating after scaling the vectors). I don't think there's a plugin reason not to try, whether there's any value...

[Boulder]

Yes, that approach is what I was experimenting with. At least by looking at MShow's output, it seems that doing the initial MAnalyse on the full-size frame and downscaling the vectors and doing MRecalculate on the downsized clip and vectors will stabilize the analysis. Of course, this is just an MVTools newbie talking. It is possible that the same would be achieved by recalculating also on a full-size frame but on HD sources (and x264 encoding), you take whatever speedup you can have.

I have built a hack-of-a-function to play around with things MVTools, and I think the next phase will be to add the possibility to preclean the full-sized frame and disable precleaning for the downscaled clip, or allow setting a different precleaning method

[SSH4]

hmm, don't find in documentation, but why i can't set blocksize 16 and overlap 12 for example, like i can made this in dfttest?

[Dogway]

I found something very strange. Either it is a bug or I didn't understand the behaviour.
When I process chroma with the motion vectors I got from the luma plane, sometimes chroma just smears a lot in an even conservative environment as thSAD=200 and tr=2 is. Shifting to tr=1 doesn't show this issue but I don't know, I thought luma plane was more reliable for motion vectors than the chroma planes.

chroma=false
plane=4

super_search=MSuper(chroma=chroma?true:(plane==0?false:true))
bv2=super_search.MAnalyse(isb = true, delta = 2,chroma=chroma)
bv1=super_search.MAnalyse(isb = true, delta = 1,chroma=chroma)
fv1=super_search.MAnalyse(isb = false, delta = 1,chroma=chroma)
fv2=super_search.MAnalyse(isb = false, delta = 2,chroma=chroma)
MDegrain2(super_search, bv1, fv1, bv2, fv2, thSAD=200,plane=plane)

[Didée]

Not sure if it's related to the problem, but you have "chroma=chroma ? ... : ..." in the MSuper() line. That should be "chroma==chroma ? ... : ...".

[Gavino]

Originally Posted by Didée

Not sure if it's related to the problem, but you have "chroma=chroma ? ... : ..." in the MSuper() line. That should be "chroma==chroma ? ... : ...".

Not at all.
The first 'chroma' is the argument name in the call, the second is the variable previously defined in the script.
'chroma==chroma' is obviously always true, so makes no sense here.

Incidentally, instead of
chroma=chroma? true : (plane==0?false:true)
you could write
chroma=(chroma || plane!=0)

[Didée]

Aiii, yes, you're right. I got confused. Script syntax is correct.

However, if msuper is called with chroma=false, then the super clip does not contain valid chroma data. And if the super clip does not contain valid chroma data, then the subsequent MDegrain (with plane=4, i.e. with chroma processing) might become problematic, obviously.

If you want to avoid the risk that source-damaged chroma influences the motionsearch, set chroma=false in the manalyse() call. But you need to keep chroma in the super-clip.

[Gavino]

Originally Posted by Didée

However, if msuper is called with chroma=false, then the super clip does not contain valid chroma data. And if the super clip does not contain valid chroma data, then the subsequent MDegrain (with plane=4, i.e. with chroma processing) might become problematic, obviously.

But if plane=4 (or any non-zero value), MSuper() is called with chroma=true.

If you want to avoid the risk that source-damaged chroma influences the motionsearch, set chroma=false in the manalyse() call. But you need to keep chroma in the super-clip.

Dogway's script does exactly that.

[Didée]

Hmmh. That's true, again.

Today is not my day, it seems. ^^

[manolito]

Originally Posted by Didée

Hmmh. That's true, again.

Today is not my day, it seems. ^^

Friday 13th

Cheers
manolito

[Overdrive80]

Hi, somebody could say me if i apply mmask properly???

a=last

######SPATIAL DENOISE####
b=dfttest(tbsize=1,sigma=14,lsb=true)

#####MASK####
vectors = MSuper().MAnalyse(isb = false)
msk=MMask(vectors).dfttest(tbsize=1,sigma=12)
      
#####BACK MERGING WITH DFTTEST####       
dither_merge16_8(b,a.Dither_convert_8_to_16(),msk,luma=true).ditherpost(mode=6)

#####CONTRASHARPEN#### 
contrasharpening(last, a)

#####TEMPORAL DENOISE####
super=Msuper(last)

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=320,lsb=true)

#####DEBANDING####
gradfun3(smode=1,lsb_in=true,mode=0,ampo=1.2)

#####ANTIALIASING####
LSharpAAF(StrDrk=10,aatype="supaa")

Thanks in advance

[cretindesalpes]

Sorry no I don't think it's a proper use. I don't know exactly what you want to achieve, but I guess you want to spatially filter only areas on which the motion estimation failed. Default kind parameter value for MMask is 0, meaning that it will output grey shades based on the vector length, even if the vector is completely wrong. You should set kind=1 to use the SAD value: smallest value = good match. I recommend to set Ysc=255 (scene change = bad match), and to play with the ml and gamma parameters. Display the msk clip to finetune the values. Then, the two first Dither_merge16 arguments should be swapped: 0 = use original clip, 255 = use spatially filtered clip.

[Overdrive80]

Originally Posted by cretindesalpes

Sorry no I don't think it's a proper use. I don't know exactly what you want to achieve, but I guess you want to spatially filter only areas on which the motion estimation failed. Default kind parameter value for MMask is 0, meaning that it will output grey shades based on the vector length, even if the vector is completely wrong. You should set kind=1 to use the SAD value: smallest value = good match. I recommend to set Ysc=255 (scene change = bad match), and to play with the ml and gamma parameters. Display the msk clip to finetune the values. Then, the two first Dither_merge16 arguments should be swapped: 0 = use original clip, 255 = use spatially filtered clip.

With the code I wanted to avoid that areas not affected by the mask, had a more smooth movement. Follow your recommendations although the masks that I'm a newbie. Thanks

[Boulder]

Some more dumb questions:

Is it generally wise to use a very high searchparam, such as 6-8 for SD sources with pel=2 and search=5? Or with any source, I'd expect that higher resolution actually needs a higher search range.

Is it useful to use MRecalculate and search=3 with a high (once again 6-8) searchparam value?

Let's say that the slowdown does not need to be considered, this is only some throwing of ideas off the top of my head. I've been trying to check the MShow output but I cannot determine which one produces better output, that's why I'd like to have some second opinions.

[alexx7777]

Please tell me how to be a script for doubling the frame rate (25> 50) interlaced video (TFF) using MVFlowFps2?

[StainlessS]

MVFlowFps2 seems to have been removed from v2 mvtools (there was a request
for comment (in v1) as to whether or not the filter was needed, but seems to have
just disappeared without further note).

The only example in v1 is for progressive however, here is the v1 example for progressive:

To change fps with MVFlowFps2:

# Assume progressive PAL 25 fps source. Lets try convert it to 50.
backward_vec = source.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1, search=3)
# we use explicit idx for more fast processing and use full search
forward_vec = source.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1, search=3)
cropped = source.crop(4,4,-4,-4) # by half of block size 8
backward_vec2 = cropped.MVAnalyse(isb = true, truemotion=true, pel=2, idx=2, search=3)
forward_vec2 = cropped.MVAnalyse(isb = false, truemotion=true, pel=2, idx=2, search=3)
source.MVFlowFps2(backward_vec,forward_vec,backward_vec2,forward_vec2,num=50,idx=1,idx2=2)

Doubt this helps but ...

[SubJunk]

The best way to make interlaced video double framerate is to use a deinterlacing script like QTGMC. It is an automatic function of that script (just don't use SelectEven() or SelectOdd() afterwards).
MVTools2 is a great way to double the framerate of progressive video, but not interlaced.

[fvisagie]

In the following scenario the YV12 U & V planes get swapped from FFVideoSource()'s CS_I420 to ConvertToYV12()'s CS_YV12, causing MRecalculate() to fail with "wrong pixel type":

source  = "input.avi"
FFIndex(source=source, cachefile=source+".ffindex", indexmask=-1, dumpmask=0, errorhandling=3, overwrite=false)
FFVideoSource(source=source, track=-1, cache=true, cachefile=source+".ffindex", seekmode=1, rffmode=0, width=-1, height=-1, colorspace="YV12")
a       = last
Assert(IsYV12(a), "Source is not YV12")
MSuper(hpad=16, vpad=16, pel=2, rfilter=4)
bvec1   = MAnalyse(isb=true, delta=1, blksize=16, overlap=8)
fvec1   = MAnalyse(isb=false, delta=1, blksize=16, overlap=8)
a.ConvertToRGB32()
# ... some filter/s requiring RGB32
ConvertToYV12()
MSuper(hpad=16, vpad=16, pel=2, rfilter=4, levels=1)
bvec1   = MRecalculate(bvec1, thSAD=400, blksize=8, overlap=4)
fvec1   = MRecalculate(fvec1, thSAD=400, blksize=8, overlap=4)
MDegrain1(a, last, bvec1, fvec1)

Discussion at http://forum.doom9.org/showthread.php?t=166603.

I raised the issue with the FFmpegSource2 developers, but their respone contained impolite language and indicated that they won't address this.

I realise that various work-arounds are possible, but as a convenience - and to prevent unexpected gotchas like the one above - please consider automatically handling swapped U-V planes? Perhaps existing behaviour could be extended with a bool "pixfmtstrict" parameter.