Fade-Out lines with mvbob

[magic144]

hi

just wondering if anybody has seen this

I've been trying without great success to resize a non-anamorphic interlaced DVD source to try and make it anamorphic :-)

the best success I've had is with mvbob() from scharfis_brain - of course it takes an age to run, so I've only tried it on a 2-minute clip so far
I've basically just been using out as a bobber in a simple script with no parameters

e.g.
crop
bob
resize
separate.selectevery.weave...

one issue I do see on the output is during the opening credits, a large solid-white block fades in and out on a black background - during the "fade-out", some horizontal lines or banding can be seen which aren't present on the original source

btw I'm also using cce as the encoder

is this a known issue - is there a parameter I can use in mvbob to try and minimize this effect

cheers in advance,

m

EDIT:
btw, I have been using converttoyuy2() at the END of this script (NOT before the reinterlace) - and I have NOT used the interlaced=true param - could this have been causing this 'line' effect?

[magic144]

can I also get some confirmation on the following assumptions

1: mvbob() works equally well with YV12 or YUY2 colorspace input
2: the colorspace output of mvbob() is the same as its input
3: I should employ converttoyuy2(interlaced=true) BEFORE the re-interlacing
4: the interlaced=true option here is also important in this case

[foxyshadis]

interlaced=true is for interlaced input; between bobbing and reinterlacing, the video is progressive, so you would not use it. Only converting after reinterlacing would it be necessary.

The other two, basically yeah, although some of the intermediate processing will be done in yv12 and converted back to yuy2 at the end.

[magic144]

ok - thanks foxyshadis

I saw a post where Scharfis had recommended doing the convertoyuy2() BEFORE the re-interlacing - not sure why, but I think it had to do with chroma errors...??? - could that have been causing a banding effect? or could it have been that I was calling convertoyuy2() at the END of my script (after re-interlacing) WITHOUT the interlace=true flag...

my input is from an interlaced NTSC DVD (via a d2v file created from DGIndex) which I believe is YV12 - so I assume that mvbob() will operate with YV12 as its input - are you saying that YV12 will also be its output (but that perhaps some internal back-and-forth may occur as necessary for whatever reason - i.e. YV12-YUY2)?

thanks again,

m

ps - I don't really understand why a DVD movie would have been released in non-anamorphic widescreen interlaced??? this is just krap!
the thing is, it's a British film, so it must have originated in PAL, so the production company's already taken the trouble to convert it to this version/format... I believe the PAL disc is available in widescreen anamorphic! (which I will definitely look to get hold of)

[magic144]

well, they say a picture is worth a thousand words

here's the fade-out banding effect I am describing (fading out from solid white through grey to black...)

http://www.voguehost.com/ims/u/magic144/pics/lines.JPG

it doesn't seem to make a difference on my positioning of the converttoyuy2 line... :-(

any ideas foxy or scharfis ?! or is this phenomenon unavoidable

thanks so much for your help

m

ps - here's my current script:-

----

LoadPlugin("DGDecode.dll")
import("mvbob.avs")

MPEG2Source("G:\1\VideoFile.d2v")
Crop(0,60,720,360)

mvbob()

Lanczos4Resize(720,480)

SeparateFields() # We will be throwing out 1 of each pair
SelectEvery(4,0,3) # 4,1,2 for BFF, 4,0,3 for TFF
Weave() # Combine fields for encoder

[magic144]

I notice that if I use mvbob(th=5) instead of the default value (8), it mostly takes care of this issue

@scharfis (or other knowledgeable gurus...) - can you describe exactly what this parameter is responsible for (in layman's terms, so a child can understand - I need that!) - and what adverse affects changing it from 8 to 5 might otherwise have on the video?

thanks in advance!

[magic144]

anybody know what the significance of this 'th' param is????

btw, it seems a reencode of this 1h40m movie will take a walloping 110 hours using 2-pass VBR encoding (+1 for vaf file)

this is with an older P4 2Ghz CPU - what sort of time ratios are other people getting with more modern CPUs using the mvbob() filter and something like CCE...????

[foxyshadis]

When using something like mvbob, always store to a lossless file first, even if it's hugenormous for HD video. If huffyuv is too large, you can try ffdshow's ffv1, for a 20-30% size reduction (but much slower decoding), or xvid with Sharktooth's EHR (http://www.webalice.it/f.corriga/CQMs/eqm_v3ehr.xcm) matrix, quant 2, 1 or 0 b-frames, and otherwise default settings. The size of that will be about half of ffv1, but not quite 100% lossless.

This way, at least it'll only take a little over half the time to do your 2-pass, since you only need to mvbob once. You can also try using securedeint (part of mvbob), which skips some steps, but that might not be enough.

[magic144]

thanks foxyshadis

err, I'm still rather new to all this
is this Huffyuv what is described here:-
http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html

if so, I am guessing I have to install it, then run the mvbob script through VirtualDub, choosing a Compression scheme of Huffyuv? Is that right???

Will Huffyuv show up in VirtualDub's list of Compression choices?? FYI, I have ffdshow installed, but do not see anything about ffdshow in the compression choices in VirtualDub (it seems it might support Huffyuv AND FFV1!) - do I have to configure ffdshow somehow to make it show up - is it something to do with the VFW Configuration??

I will then end up with the mvbob() processed version of the original, stored in a lossless format, which I can then feed into CCE for 2-pass processing???

Let me know if I'm on the right path...
Also, I presume from reading the Huffyuv page, that I still want to feed YUY2 into Huffyuv?
And I also presume this intermediate Huffyuv file is an AVI container which I can feed directly into CCE for the multi-pass compression stages???

Finally, you suggest securedeint - is that INSTEAD/IN-PLACE of mvbob (I mean I think you're saying securedeint is used as one part of the processing mvbob does, but are you suggesting that it might be the only part of the mvbob processing I need - and hence if used in isolation would be faster??)

cheers once again - thanks for the insights,

m

[foxyshadis]

That's correct concerning huffyuv, it's yuy2 only (unless using ffdshow's huffyuv). You probably have an old version of ffdshow, without the vfw codec; try for instance installing this new one (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow_rev164_20060911_clsid.exe?download). If you use an ffdshow codec, you'll then have to wrap the output in another script to first convert it back to yuy2.

The best part is that even if you screw up in cce and realize you ned to completely re-encode, it doesn't mean rerendering the entire file yet again.

And yeah, suggesting securedeint as an alternative just to see test whether it performs well enough for you. There are times when the difference is huge and times when it's small, but processing time is halved.

[magic144]

THANKS foxy

just to pursue the ffdshow inquiry a little, since I have it installed and I've used that a little before (as a decoder)

fyi, I'm using the 20041012 ffdshow-alpha... It has installed a menu item/prog called VFW Configuration - it there something in there I have to set to enable VFW? or has it not installed the VFW interface correctly/at-all in the OS?

if I have to try the new build you suggest, do I have to uninstall the previous ffdshow - would that be a clean procedure?! what is the pedigree of these *new* builds and where do you get them?
I notice on this page
http://sourceforge.net/project/showfiles.php?group_id=173941
there are a number of branches of builds - what is the main difference between them?

There seem to be a lot of settings in the VFW Encoder properties sheet - I assume I have to set Encoder to
either Huffyuv or FFV1 as desired - what about FOURCC and then any other setting of note?

Finally (this should be an easy one!) - just for a ballpark figure, how much disk space would Huffyuv/FFV1 output files occupy? (as in a figure of MB or GB per minute of source video) - just so I know how big of a RAID array I need to set up here!!!

thanks again so much for your help

m

[scharfis_brain]

you may try this newer version of mvbob:
http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar

please read the included .txt files.
I changed the names of some parameters.

maybe this version is a little bit faster than the previous one.

on an 640x480@29.97fps interlaced YUY2 clip it needs
10 minutes for 10 seconds of video
with YV12 it needs
8 minutes for 10 seconds of video

my machine is an Athlon XP 1600+ (768MB DDR 266 RAM)

[magic144]

great Scharfis - so many new things to try!

can you tell me what false compensation is? what is it that the CorrectTh param is trying to correct? - what would be the effect of setting this to 0 for instance

I believe this is what I had to tweak as the "th" param on the previous version, but I'm not sure what its significance is

thanks!

m

[scharfis_brain]

CorrectTh (former th) sets the variance/threshold in amount of luma or chroma abbreviation that is allowed for the motion compensation to be passed through.

motion compensation always produces mismatches.
these mismatches needs to be taken care of.
Setting CorrectTh to zero means completely throwing away the benefit of mocomp.
the higher the value of CorrectTh the more mocomped video gets weaved into the output, at the risk of producing residual combing. But also you'll get a more detailled and stable image with a higher CorrectTh.

CorrectTh ranges from 0...255

if you want to deinterlace handycam footage
set the predeinterlacing Threshold to -1 (it disables motion adaption), cause handycam footage rarely contains static footage.

for all other types set Threshold as low as possible so static areas still aprear static.

Setting BLksize to 16 will help speed and image stability, but won't be able to track small objects anymore.

[foxyshadis]

THANKS foxy

just to pursue the ffdshow inquiry a little, since I have it installed and I've used that a little before (as a decoder)

fyi, I'm using the 20041012 ffdshow-alpha... It has installed a menu item/prog called VFW Configuration - it there something in there I have to set to enable VFW? or has it not installed the VFW interface correctly/at-all in the OS?

if I have to try the new build you suggest, do I have to uninstall the previous ffdshow - would that be a clean procedure?! what is the pedigree of these *new* builds and where do you get them?
I notice on this page
http://sourceforge.net/project/showfiles.php?group_id=173941
there are a number of branches of builds - what is the main difference between them?

There seem to be a lot of settings in the VFW Encoder properties sheet - I assume I have to set Encoder to
either Huffyuv or FFV1 as desired - what about FOURCC and then any other setting of note?

Finally (this should be an easy one!) - just for a ballpark figure, how much disk space would Huffyuv/FFV1 output files occupy? (as in a figure of MB or GB per minute of source video) - just so I know how big of a RAID array I need to set up here!!!

thanks again so much for your help

m

I have a complex huffyuv 1920x1080 file, it's 31MB/s. The same file in FFV1 is 27MB/s. The same file with the xvid settings I gave you is 19MB/s. (Xvid refused to use b-frames on this.) Usually it's less than that for 1080p, this is a killer file, but not a whole lot less.

Definitely go for a newer ffdshow; older ones are much slower, buggier, and less featureful. I've used the one I linked you since it came out and aside from the known bugs, it's been good to me. There are quite a bit less bugs (mostly with the new formats supported, like VC-1 and SVQ3) now than then. You're correct about using it btw, although it should be showing up in vdub's list.

[magic144]

thanks to both of you guys - I shall be trying this all out over the coming week - will let you know how I get on

cheers!

[magic144]

well to be honest, the newer mvbob wasn't faster than the original, and it seemed to produce more artifacts than before with what I assumed were comparable parameters - I am getting the impression that these non-anamorphic widescreen interlaced discs are useless entities!

I have a general question - I have a Sony standalone upconverting DVD player with HDMI output

I'm watching a DVD on it which I know has been hard-pulldown encoded (i.e. the video is NTSC 29.97fps - if you Single-Step it frame-by-frame in DGIndex, you can see the 3:2 pattern and the frame-type is listed as Interlaced)

How come I don't see any artifacting on the TV? Doesn't the DVD player have to solve exactly the same problem in resizing this interlaced source for HD output? Same question surely applies to pure interlaced (TV) discs too... Does hardware resizing do THAT MUCH better a job than any software techniques? If so - how, and why can't this quality be reproduced in software?

[foxyshadis]

Sony probably does something like a DEFT conversion: Look for pulldown cycles and remove them if found, otherwise deinterlace or just blend the artifacts away. That's assuming they don't just deinterlace everything regardless of pattern. TDeint/TFM/TDecimate can give you either easily, and it'll probably look fine if you're watching it full speed on a TV, you probably won't notice any of the artifacts that you'd see stepping through on a PC, especially if they blend or denoise away anything that looks like an artifact.

[magic144]

thanks foxy
yeah, I noticed when playing around with DG's Decomb IVTC Telecide/Decimate functions that there were still occasional combed areas so lord knows just how such a DVD was produced (badly and quickly I guess) - is TFM supposed to be better at the IVTC than Telecide?

I don't know whether it's better to try and restore the progressive source in such cases or just leave it as is - I leant towards leaving it as is, simply because I can always post-process in the future, but I can never "un-post-process" :-) I think the only drawback of leaving something interlaced when it is clearly from a progressive source, is that more space is wasted in an encode for interlaced source data.

well thanks for all the help - I guess there is no magic bullet for any of this stuff - the only thing to do is to make sure bought films are anamorphic, widescreen and progressive - sadly, the DVD case doesn't always tell you this (which I think is bit crappy on the part of the manufacturers) - and there's no excuse for selling anything less to the public these days when they're so concerned about piracy and everything else!!

maybe the advent of HD discs (HD or blu-ray) will improve the situation - though from some of the things I've read so far, the initial discs are quite variable in nature already (d'oh)

[zambelli]

you may try this newer version of mvbob:
http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar
Was there an announcement? I must've missed it.
How do the new params relate to the old ones? What's the proper way to "convert" an old script to one using the new MVbob?