MVTools

[il9ad]

Originally Posted by il9ad

AVISource() doesn't seem to like (my) MPEG files.

I neglected to mention this earlier. To explore this "seek" problem, I set up a simplified test using a plain MPEG file. However, I first noticed it when reading a VideoTools (v.0.93) generated "sign-post" file, frame-served from Premiere (v.5.1c) into AviSynth. This .AVI file was read with AVISource().

There are too many variables involved in that whole process, but it brings AVISource() into suspect, too. Just FYI.

Originally Posted by foxyshadis

try adding trim(framecount-1,0)+last at some point. It'll start with the last frame and after that seek back to the beginning for the real start.

An excellent work-around idea! Wish I had thought of that. And even better ... it works! Both with the old MPEGSource() & MPEG2Source() in my test file and with AVISource() in the frame-served file! A fully denoised picture without any (additional) seeking. Thanks, foxyshadis!

Well, that would seem to verify my "seek problem" hypothesis. Now if someone else on a different machine could confirm the problem ...

... oh, it seems Didee just did.

[Boulder]

Is there some alignment problems in MVDegrain1() with Avisynth 2.5.7a3?

With this script I get a messed-up video:

MPEG2Source("E:\Temp\Captures\TS\Demux\hiidenvirta_1.d2v",cpu=4)
TDeint(mode=1)
cleaned=TemporalSoften(2,5,0,8,2)
vbw1=cleaned.MVAnalyse(isb=true,truemotion=true,delta=1,pel=2,chroma=false,blksize=16,idx=1,sharp=2)
vfw1=cleaned.MVAnalyse(isb=false,truemotion=true,delta=1,pel=2,chroma=false,blksize=16,idx=1,sharp=2)
MVDegrain1(last,vbw1,vfw1,thSAD=400,idx=2)
Limiter()
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

If I put SetPlanarLegacyAlignment(true) right after MVDegrain1(),the video is OK. MVDegrain2 works fine without that line. The source is a DVB capture, the resolution is 720x576.

[Fizick]

Thanks for report, Boulder.
this small bug with pitch for overlap=0, YV12 in MVDegrain1 fixed in next version (1.5.1 ?).

[Fizick]

Released final v1.4.11, one more final 1.4.x
Corrected vector predictors interpolation (from coarse to fine scale) for overlap>0.
Fixed bug with pitch for overlap=0, YV12 in MVDegrain1 (thanks to Boulder for report)

(also fixed v1.5.1 beta)

[Alain2]

Thank you for the new version
Small thing: in the documentation, the default settings of mvanalyse were not updated as per the changelog of 1.4.10

[Fizick]

Alain2,
thanks, fixed.

[Fizick]

As was noted by cwk,
I forgot to add the same comment to MVDeGrain1/2 doc as for MVCompensate.
Overlaped blocks processing is implemented as window block summation (like FFT3DFilter, overlap value up to blksize/2) for blocking artefactes decreasing.
MVAnalyse works well for almost any overlap size.
Larger overlap for compensation (and degrain) can be implemented too, but not in current versions.
It is more difficult to program, and slower (more numbers of overlapped blocks for every pixel - try draw it on paper).
I will add this comment to docs and the overlap size check to the code in next MVTools version.

[Fizick]

One more final 1.4.x version
1.4.12 (25.09.2006)
Fixed (?) bug with frames caching in MVDenoise (and possible in MVDegrain) (thanks to il9ad for report)
The cache problem http://forum.doom9.org/showthread.ph...614#post879614 is partially solved,
but please test and report.

[nibbles]

These are immensely significant tools to so many people around here.
From all of us lurkers, a huge thank you for working on them!
Could you tell me approximately how much time it would take an
experienced programmer like yourself of shodan for instance to
code a 64bit version of mvtools? I have no idea, but I would
to understand the challenge. Ok, thanks again. nib

[Fizick]

nibbles,
64bit is still not mainsteam.
And I am not an experinced programmer.

Released v1.4.13 (28.09.2006) - next final v1.4.x
Fixed bug with possible wrong frames pointers in core (MVClip.Update), hided by caching (thanks to IanB for advice)

I make this version on the base of v1.4.11 and disabled all v1.4.12 changes. it use more correct way to prevent the bug.
But I make correction to almost all functions,
so may be created some new copy-paste bugs.

[anton_foy]

@Fizick

Thats great!
But when I download the 1.4.13 the file is named 1.4.12.

[Fizick]

thanks, fixed.
try again.

[Fizick]

Released v1.5.8 beta (dll 14.10.2006)
Many functions: added clip2x parameter to use 2X upsampled clip instead of internal subpixel interpolation for pel=2
MVFlowFps, MVFlowFps2: added thSAD parameter; use local blending of neighbour frames pixels in regions with bad motion vectors
MVFlowFps, MVFlowFps2: may use motion vectors for any frames delta
MVFlowFps, MVFlowFps2: fixed a bug for video with big nominators and denominators (thanks to Trixter for report)
MVCompensate: added experimental fields parameter to compensate fields shift of fieldbased video for pel=2
MVAnalyse: changed pnew parameter to relative of SAD

[foxyshadis]

MVDegrain and MVDegrain2 crash whenever I try to use them with 2.5.7 RC1 (not with tritical's latest build though), causing an avistreamsynth exception, and when recompiling a debug version it seems something is missing: SADToMask is unresolved.

[Fizick]

Oops. I updated mvtools158.zip archive with correct maskfun.cpp and maskfun.h source files.
(binary MVtools.dll is the same, not updated)
Post your script, system and other detail.
What if you add isse=false ?

[Fizick]

Luma flicker and fades are plorblem for current MVTools.
Some time ago (in unpublished v1.5.2) I tryed use local luma difference compensation at motion estimation but without great success.

But DCT (discrete cosinus frequency transform) is more interesting for me
What if we make DCT of blocks and compare coefficients with DCT of block at other frame?
I try to use the same SAD (sum of absolute diferences) function for DCT coefs.

Released MVTools v1.6.2
MVAnalyse: added experimental DCT mode to improve motion estimation at luma flicker and fades (fast for blksize=8 only).

dct: using of block DCT (frequency spectrum) for blocks difference (SAD) calculation. In particular it can improve motion vector estimation at luma flicker and fades.
0 - usual spatial blocks, do not use DCT;
1 - use block DCT instead of spatial data (slow);
2 - mixed spatial and DCT data; weight is dependent on mean frame luma difference;
3 - adaptive per-block switching from spatial to equal-weighted mixed mode (experimental, a little faster).
4 - adaptive per-block switching from spatial to mixed mode with more weight of DCT (experimental, a little faster).
Default = 0.

Mode dct=2 works quite good at (global) fades in my test.
All new dct modes are experimental, probably more optimal combination of 'traditional' SAD with DCT SAD is possible.
The question is about weight of DC (null frequency = block mean luma) component. For example, in DCT coder it is usually decreased.

[netsnake]

thanks fizick for the new version updates~

[actionman133]

Fizick, I'm downloading your latest version, but WinRAR keeps telling me the archive is corrupted... 'Unexpected end of archive'.

Anyone else having this issue?

[Fizick]

actionman133,
try re-download (or continue stopped download).
I hope you do not use MS IE

[superuser]

Currently I am experimenting with MVDeGrain2, MVDegrain1, DeGrainMedian and RemoveGrain. For past couple of months was using RemoveGrain (mode 2 and 17)and sometimes in combination with RemoveDirt

Purpose is to filter out grain noise from source and avoid using heavy grain removers like RemoveDirt as removedirt with grain also seems to eat away color sharpness and details. Currently I am using with default values, tomorrow will start tweaking SADs. Comments and suggestions, which would be better choice for grain removal while preserving details.

original_source=last
denoised_source = DeGrainMedian()
SeeSaw(original_source, denoised_source,  NRlimit=a, NRlimit2=b, sootheT=xx, bias=yy)

MVDeGrain2

original_source=last

backward_vector_2=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = true, lambda = 1000, delta = 2, plevel=2)
backward_vector_1=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = true, lambda = 1000, delta = 1, plevel=2)

forward_vector_1=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = false, lambda = 1000, delta = 1, plevel=2)
forward_vector_2=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = false, lambda = 1000, delta = 2, plevel=2)

denoised_source=original_source.MVDegrain2(forward_vector_2, backward_vector_2, forward_vector_1, backward_vector_1)

SeeSaw(original_source, denoised_source,  NRlimit=a, NRlimit2=b, sootheT=xx, bias=yy)

Aah, one more thing when I try to load the script in VirtualDub (VD), which I do for preview and syntax checking of script, for MVDeGrain1 it is giving System Exception - Access violation, for MVDeGrain2 is working fine!!! Ny ideas why so?

MVDegrain1

original_source=last

backward_vector_1=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = true, lambda = 1000, delta = 1, plevel=2)
forward_vector_1=original_source.MVAnalyse(pel=2, search=3, chroma=true, isb = false, lambda = 1000, delta = 1, plevel=2)

denoised_source = MVDegrain1(backward_vector_1, forward_vector_1)

SeeSaw(original_source, denoised_source,  NRlimit=a, NRlimit2=b, sootheT=xx, bias=yy)

a, b, xx, yy are defined parameters.