MVTools

[Fizick]

mroz,
probably it may be done, but i do not know how and it is not in my "to do" list.

Th most intrigue for me is returning array

mv=MVAnalayse(source)
array=MVGlobal(mv) # like MVDepan
dx=array[0] # in conditional env

[mroz]

Ok, fair enough. I don't think there's anything special about runtime functions - I tried calling one outside of a conditional environment & as long as you manually define current_frame to some value it will work.

So it should be 'just' a matter of defining the function as you would normally do, but return an integer or array, as you prefer, instead of a clip.

Of course as I've never written a plugin & have only dipped a toe into poking around in MEncoder's handling of AVISynth script input, the 'just' is not so small for me

Ah well, never mind.

Oh, I did notice in the MVTools MVDepan source there's some logging code. Any idea how I turn that on? Is it a compile time option?

[Fizick]

MVTools 1.8.5 (05.11.2007 by Fizick)
Added pelsearch parameter as search parameter (radius) at finest level (request by Terranigma). Default=pel
Decreased internal buffer to decrease memory usage, with some changes in critical sections.
Added block size 16x2 (requested by ab_99).

I do not merge latest 1.8.4.3 code by TSP.
I independenly developed similar solution (probably worse, but I must firstly read and undestand TSP circular buffer concept).


mroz, MVDepan is very old code.
My codes are ugly, but my English is even more, so please read a code.
Brobably the simplest solution is to add some func to MVDepan code to output array

[superuser]

Originally Posted by Fizick

superuser, it is delayed.
Now I consider Terranigma's request.

sure, thanks for the update. I was going through that another where you had posted about MVDegrain3 and was excited about it. But I agree the point raised by Taerranigma's is higher priority. I will wait no probs .

[Terranigma]

Originally Posted by Fizick

MVTools 1.8.5 (05.11.2007 by Fizick)
Added pelsearch parameter as search parameter (radius) at finest level (request by Terranigma). Default=pel

Thanks so much for this. I'm now getting the speed I was once accustomed to with 1.7.0.

[mroz]

Originally Posted by Fizick

mroz, MVDepan is very old code.
My codes are ugly, but my English is even more, so please read a code.
Brobably the simplest solution is to add some func to MVDepan code to output array

No worries

If I pluck up the courage I'll have a play with the code. Can you recommend build tools? What do you use to compile MVTools?

[Fizick]

mroz,
Any Microsoft compler since VCToolkit 2003, plus Platorm SDK.

Probably my MVGlobal suggestion instead of MVDepan is bad.
It is not possible to return array.
And every MVGlobalDx, MVGlobalDy... will ineffective recalculate global motion.
So, your suggestion of separate function (plugin) MVPepanDx(MVDepan()) is better.

But it also may be implemented as (global) variables (MVDepanDx, ... ) in MVDepan like "current_frame".
I can implement it. But should its names to be fixed or user defined (for every MVDepan instance) ?

[Terka]

how to mask (by black) areas which move
1. less then treshold in both directions (sqr(x^2+y^2));
2. in vertical direction only?

[mroz]

Originally Posted by Fizick

mroz,
Any Microsoft compler since VCToolkit 2003, plus Platorm SDK.

Probably my MVGlobal suggestion instead of MVDepan is bad.
It is not possible to return array.
And every MVGlobalDx, MVGlobalDy... will ineffective recalculate global motion.
So, your suggestion of separate function (plugin) MVPepanDx(MVDepan()) is better.

If it is, then only by chance. I thought your idea to return an array was better, so I must have very little idea of what's going on - which doesn't surprise me ;(

But it also may be implemented as (global) variables (MVDepanDx, ... ) in MVDepan like "current_frame".
I can implement it. But should its names to be fixed or user defined (for every MVDepan instance) ?

Eek, not sure. Anyone else?

Would appending string(idx) to Dx etc be enough? Though I suspect I've again revealed how little I understand.

Edit: no sorry, that's obviously not helpful. I guess the names would need to be user defined. Sorry, had a few drinks.

BTW Thanks for considering this

[superuser]

If MVFlowFPS/MVFlowFPS2 is used to bring down the framerate to half, in this case does MVFlowFPS/MVFlowFPS2 will select the same frames as SelectEven or SelectOdd would had? If not who different will it behave be. I tried differentiating between both of the approaches, but it was not clear to me, so posted this question here.

When using MVFlowFPS2 on would following be a good approach to follow:

numerator = dcSrcFramerateNumerator()/2
denominator = dcSrc.FramerateDenominator()/2
#
backward_vec = dcSrc.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1, delta=1, search=3)
forward_vec = dcSrc.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1, delta=1, search=3)
backward_vec2 = dcSrc.MVAnalyse(isb = true, truemotion=true, pel=2, idx=2, delta=2, search=3)
forward_vec2 = dcSrc.MVAnalyse(isb = false, truemotion=true, pel=2, idx=2, delta=2, search=3)
dcSrc = dcSrc.MVFlowFps2(backward_vec,forward_vec,backward_vec2,forward_vec2,num=numerator, den=denominator, idx=1, idx2=2)

or MVFlowFPS2 has been crafted to take vectors on cropped frames which depends on the block size used in MVAnalyze?

[talen9]

I *think* that, using that script, you're not changing FPS at all

The FPS value is given by (numerator)/(denominator), right? So, dividing both of them by 2, the resulting "new" FPS will be ... the same as the original one

I think that you'll need to change it a bit ... like, you'll have to divide by 2 the numerator and keep unchanged the denominator:

numerator = dcSrcFramerateNumerator()/2
denominator = dcSrc.FramerateDenominator()
...

[mroz]

Double the denominator rather than halve the numerator, else you'll have a problem when the numerator is odd.

[foxyshadis]

The way you use it is just an extremely slow no-op. Flow will use the input frame if it matches up perfectly with the output. What you probably want is to use mvflowblur(...).selecteven() instead, so that you lengthen the shutter to compensate for lowering the framerate. (Films generally have longer shutters than DV, it's an important part of the 'film look' everyone treasures.)

If not, you're going to have to explain what you're looking for.

[superuser]

Originally Posted by talen9

I *think* that, using that script, you're not changing FPS at all

The FPS value is given by (numerator)/(denominator), right? So, dividing both of them by 2, the resulting "new" FPS will be ... the same as the original one

I think that you'll need to change it a bit ... like, you'll have to divide by 2 the numerator and keep unchanged the denominator:

numerator = dcSrcFramerateNumerator()/2
denominator = dcSrc.FramerateDenominator()
...

Originally Posted by mroz

Double the denominator rather than halve the numerator, else you'll have a problem when the numerator is odd.

thnxs for pointing that out. In my scripts I m using it first doubling the framerate (using Bobber), and than bring it back to the original framerate. I have detailed why below why I am doing so. Though again this methodology may not be the appropriate way to do it

Originally Posted by foxyshadis

The way you use it is just an extremely slow no-op. Flow will use the input frame if it matches up perfectly with the output. What you probably want is to use mvflowblur(...).selecteven() instead, so that you lengthen the shutter to compensate for lowering the framerate. (Films generally have longer shutters than DV, it's an important part of the 'film look' everyone treasures.)

If not, you're going to have to explain what you're looking for.

Thnxs, I will try this out.

Details of what I trying to do: Currently I am processing a movie about 3 hours run time. The problem with these movies are released as NTSC, but they were converted from PAL. So as to over-come poorly interlaced frames effects, what I had in mind is first double the framerate, in my case was using yadiff for the same (2*29.97), than bring the framerate to original using mvflowfps (29.97). With this frames looked much better and smoother than before. I am using DVD-RB and CCE as the encoder. Had tried for manual encoding CCE so as to encode as Film, but I did not get it right so reverted back to DVD-RB. The idea of playing with framerate being is do not disturb the output framerate, keep it same as the input one and deinterlace them, if the above is the appropriate one to follow. I had used DVD-RB's features for deinterlacer, but the results were not that soothing, so am exploring other options which can work with DVD-RB.

Again I am in learning process so feel free to slam the ideas or approach which does not seem appropriate.

thxs once again for ur input and I will try out what Foxyshadis suggested.

[Didée]

Originally Posted by superuser

The problem with these movies are released as NTSC, but they were converted from PAL.

Usually such conversions are done either by normal pulldown, or by a converter box that produces field-blending.
For the former you should use IVTC, for the latter you should use MRestore (or Restore24, or RePal).
Motion compensated Yabba-dabba-doo most times is of zero use in this context.

[superuser]

Thnxs Didee for the input.

Originally Posted by Didée

Usually such conversions are done either by normal pulldown, or by a converter box that produces field-blending.

Would normal Pull-down work with DVD-RB? Also if possible can you please where can I find information

Originally Posted by Didée

For the former you should use IVTC, for the latter you should use MRestore (or Restore24, or RePal).
Motion compensated Yabba-dabba-doo most times is of zero use in this context.

Above is what I had started with and I was getting shaky or not much clear frames, so I switched to above approach. But I was bringing the framerate back to the original which of the limitation of the process I am following . When I get back to my place, I will post the what calls I was using (I was making calls to tritical's TDient plugins for the same).

[IanB]

You first need to identify your input.

xxxSource("file")
Assume?ff() # choose TTF or BFF
Bob()

Step thru the Bobbed fields looking for the pattern of how moving parts are rendered. If the original was 24 fps film then you should be able to decern how it has become intertwined with video field structure. If the motion steps 2 forwards then 1 backward then use the other TFF/BFF.

E.g. If it is simple 3-2 pulldown from the dumb bob you will see Frame1, dup1, dup1, Frame2, dup2, Frame3, dup3, dup3, Frame4, Dup4, Frame5, ...

Or if field blending has occured Frame1, dup1, blend12, Frame2, Frame3, blend34, Frame4, ....

Once you have your pattern then you can start reseaching how to recover the original frames. Didée has offered 2 prime candidates.

[Terranigma]

Fizick, is there any way to use dct=1 on all frames except those at scene changes? That's only where oscillation occurs.

---
OK, I noticed that there's only errors when using dct 1, 2, & 4 during backward searches; I wonder why that is

[Fizick]

Terranigma,
Please provide (much) more info.

[Fizick]

mroz, Ii can implement motion info as AviSynth global variables (via SetGlobalVar in internal code):

...
MVDePan(..,vdx="dx")
ScriptClip(last,"Subtitle(String(dx))",after_frame=true)

or as local variables:

...
dx=0.0 # must be initialized in this case
MVDePan(..,vdx="dx")
ScriptClip(last,"Subtitle(String(dx))",after_frame=true)

What is better for MT environment?
probably first, but some trick may be needed anyway if you want different names for difrerent threads.