MVTools without idx

[yup]

Fizick!

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

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

Originally Posted by Fizick

and what about memory?

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

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