Stuttering PAL source (previously: Quick MVbob problem)

[Maldark]

My inital problem has been solved but it still didn't fix what I was hoping it would.

My source is stuttering, it's extremely annoying and I believe results from a poor NTSC -> PAL conversion on the part of the dvd company.

So I'm looking for a solution any help will be greatly appreciated.

Samples
RAW: http://www.fileupyours.com/files/48567/RAW%20Sample.vob
Encoded sample: http://www.fileupyours.com/files/48567/Encode%20Sample.mkv

I have been using the following script
# PLUGINS
LoadPlugin("D:\!!RIPP~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\UnDot.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\awarpsharp.dll")
Import("D:\!!Ripping\GordianKnot\AviSynthPlugins\mvbob\mvbob.avs")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\MVTools.dll")

# SOURCE
mpeg2source("D:\!RAWS!\GSC\Testor.d2v")

# DEINTERLACE
AssumeTFF()
MVbob()

# DENOISING
Undot()
awarpsharp(depth=4, blurlevel=2)

# FPS CORRECTION
backward_vec = last.MVAnalyse(isb = true, truemotion=true, pel=2, idx=8)
forward_vec = last.MVAnalyse(isb = false, truemotion=true, pel=2, idx=8)
last.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=8)

# CROPPING
crop(14,6,694,566)

# RESIZING
lanczos4Resize(704,528)

[scharfis_brain]

# SOURCE
source = mpeg2source("D:\!RAWS!\GSC\Testor.d2v")

# DEINTERLACE
MVbob()

which video should mvbob() ever process?
without any parameters it tries the variable 'last'. But 'last' is empty. the only variable that exsits is 'source'.

[Maldark]

Sorry to be more of a pain, but is there any chance you could give me an example of what this script should look like to function correctly.

I'm still having a little trouble with some of the scripts involved in AVIsynth.

And i've been having a hard time tring to get mvbob and mvflowfps to cooperate.

Is it actually possible to do this in one encode or do I have to do mvbob first and then re-encode the new file to get back to the original fps?

[scharfis_brain]

either:

mpeg2source("D:\!RAWS!\GSC\Testor.d2v")
MVbob()

OR

source = mpeg2source("D:\!RAWS!\GSC\Testor.d2v")
MVbob(source)

[Didée]

And i've been having a hard time tring to get mvbob and mvflowfps to cooperate.

Is it actually possible to do this in one encode or do I have to do mvbob first and then re-encode the new file to get back to the original fps?
You can do it in one script, but the script will need great amount of RAM. You'll probably need a PC equipped with at least 1GB, perhaps 1.5 GB of RAM to do both operations in one script. (Can't say for sure, since my machines have only 512MB...)

Anyway, for MVBbob and MVFps to cooperate, you need to heal the "idx disease" wich your script is suffering from ...

In the "FPS correction" part of your above script, change those "idx=1" to e.g. "idx=8", and those "idx=2" to e.g. "idx=9". (Because the lower idx values are already occupied by the formerly called MVBob.)
Alternatively, you could completely delete those "idx=?" assignments.

This is a common problem, and not a seldom one. Using discrete values for "idx" deals pretty good for cutting down the needed system ressources, especially in complex appliances of MVTools. But it becomes a big problem when different functions are combined, which use the same values for "idx", because the functions don't know of each other ...

For those MVTools-based functions I have built / am building, I tried to escape the problem by using global variables for the idx values, that get count-up during the function call. But this, too, can only work out as long as all involved functions follow the same path.

[Boulder]

either:

mpeg2source("D:\!RAWS!\GSC\Testor.d2v")
MVbob()

OR

source = mpeg2source("D:\!RAWS!\GSC\Testor.d2v")
MVbob(source)
And with AssumeTFF() before MVBob if the source is top field first (which it very likely is).

He should also either use blocksize 8 in MVAnalyse or crop the second clip by 8 pixels.

[Maldark]

I fixed my inital problem now and the current compination is really slow will changing the idx values increase performance?

Resources really arn't a problem I've got 1gb of ram and it's an Opteron 175 (2.2GHz Dual core).

I ran it as this
# PLUGINS
LoadPlugin("D:\!!RIPP~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\UnDot.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\awarpsharp.dll")
Import("D:\!!Ripping\GordianKnot\AviSynthPlugins\mvbob\mvbob.avs")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\MVTools.dll")

# SOURCE
mpeg2source("D:\!RAWS!\GSC\Testor.d2v")

# DEINTERLACE
MVbob()

# DENOISING
Undot()
awarpsharp(depth=4, blurlevel=2)

# FPS CORRECTION
backward_vec = last.MVAnalyse(isb = true, truemotion=true, pel=1, idx=1)
forward_vec = last.MVAnalyse(isb = false, truemotion=true, pel=1, idx=1)
return last.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=1)

# CROPPING
crop(14,6,694,566)

# RESIZING
lanczos4Resize(704,528)
for some reason the output file isn't cropped filtered or resized :/
And it took forever.

Little more information on the peice, it's anime, pal source interlaced 25fps

The problem I was hoping mvbob would eliminate is a stutter in the source, I've noticed it with nearly all my anime I believe it's from a poor conversion from NTSC -> PAL from the DVD creators.

EDIT: yes it is top field first.

[Boulder]

It's because of this:
return last.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=1)
Remove the return statement and it'll work.

EDIT: and as Didée already said, fix the idx numbering.

[Maldark]

It's because of this:
return last.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=1)
Remove the return statement and it'll work.

EDIT: and as Didée already said, fix the idx numbering.


OK now it looks like this, it's still taking its sweet time.
# PLUGINS
LoadPlugin("D:\!!RIPP~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\UnDot.dll")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\awarpsharp.dll")
Import("D:\!!Ripping\GordianKnot\AviSynthPlugins\mvbob\mvbob.avs")
LoadPlugin("D:\!!RIPP~1\GORDIA~1\AviSynthPlugins\MVTools.dll")

# SOURCE
mpeg2source("D:\!RAWS!\GSC\Testor.d2v")

# DEINTERLACE
MVbob()

# DENOISING
Undot()
awarpsharp(depth=4, blurlevel=2)

# FPS CORRECTION
backward_vec = last.MVAnalyse(isb = true, truemotion=true, pel=2, idx=8)
forward_vec = last.MVAnalyse(isb = false, truemotion=true, pel=2, idx=8)
last.MVFlowFps(backward_vec, forward_vec, num=25, den=1, ml=100, idx=8)

# CROPPING
crop(14,6,694,566)

# RESIZING
lanczos4Resize(704,528)

[Boulder]

You still need the AssumeTFF() statement. Anyway, it won't be lightning fast in any case, MVBob is very slow and the fps correction will take its time. Besides, 1GB of RAM isn't really much with complex Avisynth processing.

[Didée]

The problem I was hoping mvbob would eliminate is a stutter in the source, I've noticed it with nearly all my anime I believe it's from a poor conversion from NTSC -> PAL from the DVD creators.
It would be better to identify the real problem and tackle it, instead of just pulling the biggest weapon out of the board and hoping it will magically bulldoze everything.

Chances are "good" that your source has fieldblending. And IF this is the case, then MVBob or MV'ed framerate conversion not only will not help, but make everything even worse instead.
In particular, the results of motion vector search are comparatively poor when a search is done between clean and blended fields ... (spells "unusable").

[Maldark]

I was just about to move onto that problem, I'm going to upload a sample and i'll see if you or anyone else who feels like helping can find me a way to solve my problem, it's been plaguing me for some time now.

[scharfis_brain]

Boulder: with MPEG2Source there is NO need for the assume?ff() command, cause MPEG2Source itsfelf takes care for the correct fieldorder.

Assume?ff() is only needed with Avisource and directshowsource.

[Boulder]

Hmm, when did this happen? I must have missed some changelog (or has it always been that way?)

[scharfis_brain]

or has it always been that way?
According to my experience: yes!