MoComped deinterlace... don't know why i didn't think of this approach before.

[opoman]

I'm sorry, Scharfis_brain, my incorrect reference to 'dvdhelp' was a slip of the brain - I should have referred to the link I gave at the top of my piece - there you will find a little more detail than Richard Berg has given.

The latter was surprised that the faster script worked 'well.' That may be a quote from some other assessment but my own finding is that only with specific regard to the sports (rugby)clip's 'watchability', or what you might call motion-fidelity, the faster script does well. Others may want more perfect images.

[scharfis_brain]

better replace
bob() by leakkernelbob(...)

this will reduce flicker and increases detail!

plus, if you are worried about scene changes, take a look at this: http://forum.doom9.org/showthread.php?s=&threadid=90271

though its scene change detection is NOT optimal, it may cause some weird effects. so please test it before using it widely.

the script you are using is halving the resolution and creating a weird bobbing-effect on TV, because the fields become misaligned:
both of your fields share the same vertical position
but the one field needs to be shifted by exactly 1/2 pixel in relation to the other one.

so try this script:

crop(12,6,696,568)
i=leakkernelbob(order=?,threshold=7)

#either
i.mvfpsscd(59.94)
#or uncomment if you dislike mvfpsscd:
#fwd=mvtools0962_mvanalyse(i,isb=false,lambda=400)
#bwd=mvtools0962_mvanalyse(i,isb=true, lambda=400)
#i.mvtools0962_mvconvertfps(bwd,fwd,fps=59.94)

bicubicresize(width,472).AddBorders(4,4,4,4) #only this returns a proper Aspect Ratio -> encode at 704x480
Assumetff().Separatefields().selectevery(4,0,3).weave() #reinterlace



But *MAYBE* you want to go for another approach, that gives semi-smooth motion at much higher processing speed.
but it will only work with slow-speed-shutter (1/50 sec)video.
(motion is blurry)



crop(12,6,696,568)
leakkernelbob(order=?,threshold=7)
last.trim(1,0).mergeluma(last,0.5).mergechroma(last,0.5)
converttoyuy2()
convertfps(59.94)
bicubicresize(width,472).AddBorders(4,4,4,4)
Assumetff().Separatefields().selectevery(4,0,3).weave()

[opoman]

Thankyou for the suggested variations, Scharfis_brain.

I'll try options 2 and 3 when I can discover why leakkernelbob(order=1,threshold=7) is inducing a vertical green stripe at the RHS of my picture. Option 3, as judged in vitualdubmod, looks fast and promising (green stripe apart).

I'm unable to try option 1 as I can't track down a plugin which will induce avisynth to allow mvfpsscd()

[Leak]

Originally posted by opoman
I'll try options 2 and 3 when I can discover why leakkernelbob(order=1,threshold=7) is inducing a vertical green stripe at the RHS of my picture. Option 3, as judged in vitualdubmod, looks fast and promising (green stripe apart).

Try adding "align=true" to the parameters for the Crop above it, that should fix it. Yes, it's a bug, but adding "align=true" should fix it, and might probably even speed things up a little bit.

[opoman]

crop(12,6,696,568,align=true)

unfortunately, doesn't remove the green stripe.

However, crop(8,6,704,568)

is OK.

Trouble is, I haven't yet figured out exactly what is going on so I don't immediately know if Scharfis_brain's crop setting is crucial. Seems, from a quick encode in CCE, and assessment in virtualdubmod, that the script is both phenomenally fast and, maybe, acceptable to watch. I'll know when I put a bunch of these new tests through the player/TV.

[Leak]

Originally posted by opoman
crop(12,6,696,568,align=true)

unfortunately, doesn't remove the green stripe.

Hmmm... I could've sworn that copies the video data so it's aligned again - I guess I'll have to have a look at my code sometime soon...

Anyway, you can also just do the cropping after LeakKernelDeint - since you're only cropping a bit of the edges, deinterlacing a few pixels more is hardly going to hurt.

np: Gold Chains - Citizens Nowhere (Young Miss America)

[psme]

I use the all-in-one rar package and did a test on a short 4mins clip using DVD-Rebuilder. It took around 30 hours on my P4 3G (Northwood) 512M DDR333.

The clip is from the first 2 chapters of a DVD which is in pure 480i NTSC format of real video content. For some reason the encoded clip becomes in 25fps format and everything is in slowwwwww motion!

Do I need to use mvfps to convert it back to normal NTSC rate? I thought the default mvbob() will keep the format as is, or not?

Thanks in advance.

regards,

Li On

[scharfis_brain]

30hrs. is definately far too much.

on the page befor, 2bdecided experienced a similar problem!

on my athlonXP 1600+ it run at about 1 to 2 fps

also mvbobs output is always doublerate.

please post your script!
(and maybe a source sample - an unprocessed one!)

[opoman]

Odd result for the speed. My standard 3min 25sec PAL rugby clip took 6 hours for CCEbasic to convert to NTSC, using a 1Gig PIII and now, I've just tested it with a brand new 3Gig P4 and it went four times faster - maybe the difference is in the encoder settings and the known fact that CCE is faster than some others.

Maybe you meant 3 hours rather than 30.

[scharfis_brain]

@opoman: your times are realistc.
you can achieve a speedup, if you do

mvbob()
resize()
mvfps()

(this is, because the image is smaller for NTSC)

btw. last week, I finished a whole 2hrs video standards conversion from NTSC to PAL.
all together it needed about 4days of continous processing

but its results are astonishing.
you won't even notice, that the source was NTSC!

btw.: it was an adult movie, cause I did not have any other long contnuous NTSC video.
also this kind of video has
*ermmm* lots of overlapping, covering and periodic/rapid moving objects :p :p :p
so its easy to search for the artifacts, if you know, what I mean.
(finally, I can watch it on my TV set, which is unable to display 60 Hz! :D )

[psme]

Avisynth script reported by RB-Opt:

1 - #------------------
2 - # AVS File Created by DVD Rebuilder
3 - # VOBID:01, CELLID:01
4 - #------------------
5 - LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
6 - mpeg2source("E:\dvd-rb-in\D2VAVS\V01.D2V")
7 - trim(0,5862)
8 - setmemorymax(384)
9 - import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")
10 - assumetff()
11 - mvbob()
12 - ConvertToYV12()

I use the default QuEnc 2 pass encoding. I think during the first chapter encoding QuEnc reported framerate is around 1.3fps then the second chapter encoding speed drop to around 0.2fps.

The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

There is nothing special about my test clip. It is just a ramdom selection of a normal NTSC VIDEO content DVD. I can provide the VOB if needed but I really don't think the source is the problem. Maybe it's the DVD-Rebuilder? Though I just use their latest Installer release with almost all the default config, except the use of Avisynth process of course.

regards,

Li On

[scharfis_brain]

try this script


import("C:\Program Files\AviSynth 2.5\plugins\mvbob.avs")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
mpeg2source("E:\dvd-rb-in\D2VAVS\V01.D2V")
trim(0,5862)
assumetff()
mvbob()


also never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!

The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

are you sure, that your encoder is able to understand 59.94 fps progressive?
do you own devices being able to play back 480p59.94 ?!?

[Xesdeeni]

Originally posted by scharfis_brain
also never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!Given that AVI files are limited to 4 GB (2 GB by some programs). I'd guess that's 8-12 minutes a file, so it will require multiple files.

Xesdeeni

[scharfis_brain]

@Xesdeeni:
that's wrong!
AVI files can be easily made much larger than 4 GB.
The only thing required is a File System different than FAT(12/16/32).

so use win2k or xp and you won't get into file size trouble!

[psme]

Originally posted by scharfis_brain
The super long processing is not the issue. My problem is why the source 29.97 480i NTSC became in 25fps PAL format!

are you sure, that your encoder is able to understand 59.94 fps progressive?
do you own devices being able to play back 480p59.94 ?!?

Sorry, I'm new to encoding so I don't really understand your question. I use the DVD-Rebuilder bundled QuEnc encoder (version 0.59 I think). The source VOB is of course in 29.97p/59.94i normal NTSC video content. My playback is via DScaler 5 decoder (forced Weave deinterlace) with FFDShow processing. FFDShow Info read the correct 29.97fps on the original VOB. The mvbob() re-encoded VOB read 25fps in FFDShow and everything is in slowwww motion!

regards,

Li On

[scharfis_brain]

a SDTV MPEG2 encoder does not accept 59.94PPPPPPPPPP!!!
so it may have gotten confused with it and falled back to (wrong) 25p.

mvbob always does 59.94i -> 59.94p for NTSC
and 50i -> 50p for PAL.

so it effectively doubles the framerate!

what is your final intention by the use of mvbob?

[psme]

I see! Thanks for the explanation!

My intention is to see the effect (and power!) of your mvbob VIDEO deinterlace quality, for normal DVD playback on a HTPC to a projector on a big screen!

On standalone hardware processing, so far the best quality on pure video source deinterlace is the Faroudja DCDi processing IMO.

On a PC, IMO, the DScaler's MoComp2 video deinterlace gives the best image quality, followed by TomsMoComp.

And I always want to see a motion compensation video deinterlace processing. I thought the mvbob claim something like that so I want to see it's quality.

The perfect way should be just apply mvbob in Avisynth inside FFDShow during real time DVD playback. But on my p4 3G the framerate is less than 2fps I think! The image itself seems correct but with a <2fps I can't really judge the picture quality!

So my only choice is to do a re-encoding with the best encoding quality possible together with the mvbob processing.

I guess my question will be, which (cheap) MPEG2 encoder does 59.94p processing to be used with mvbob processing?

Thanks in advance.

regards,

Li On

[scharfis_brain]

why mpeg2?
just use xvid with fixed quant of 2 or 3 for testing purposes!

[psme]

Indeed, why MPEG2? Stupid me! I bet at the same bitrate Xvid can't look worse than any MPEG!

Though I need to do some research on Xvid encoding though...

regards,

Li On

[Xesdeeni]

Originally posted by scharfis_brain
that's wrong!
AVI files can be easily made much larger than 4 GB.
The only thing required is a File System different than FAT(12/16/32).

so use win2k or xp and you won't get into file size trouble! Well, in the case of the above process, it looks like you are right, there isn't a 4 GB limit. Sorry.

But, in order for an AVI file to be compatible with all applications, it must be less than 2GB, regardless of the file system. Many applications can handle 4GB, so that is often safe as well.

In order to support larger than 4GB, the application must support the OpenDML extension. Several of the applications I use regularly don't, so I stuck that 4 GB limitation in my head as a general rule. But, it looks like both VirtualDub and AVISynth support this extension, so for the above process, it should work.

Does anyone know if the specific codec can interefere with this?

Xesdeeni

[scharfis_brain]

I NEVER cared about AVI file sizes, cause I ALWAYS process to segmented AVI, to be able to resume crashed processings more easy (in common, only the last segment is defective, after a crash).
This is also important, because I cannot run my PC over night. The HDDs are far too loud (sounds like a circular saw).

also, I never feed my applications directly with avi.
everything passes AVS.

[Xesdeeni]

Well, that's confusing. How can you not feed directly, but not use AVI's either!?

Xesdeeni

[scharfis_brain]

1) source preparation
DVD or DV sources -> some painfully slow and instable AVS processing -> segmented AVIs (Huffy)

2) encoding or cutting
segmented AVIs -> AVS (trim all attempts to one complete vidoe)-> encoder or editing program

is this THAT complicated???

[Xesdeeni]

Originally posted by scharfis_brain
is this THAT complicated??? Hey, you're the one that saidalso never encode directly, because a second automated pass will cause weird thigs!
process to an intermediate file (HuffYUV!) before encoding!and thenalso, I never feed my applications directly with avi.
everything passes AVS.Wait! Now I get it. You use an intermediate AVI, but you don't let the application load the AVI directly, you use AVISynth...sometimes the thickness of my skull surprises even me.

Xesdeeni

[kle500]

Originally posted by scharfis_brain
last week, I finished a whole 2hrs video standards conversion from NTSC to PAL.
all together it needed about 4days of continous processing

but its results are astonishing.
you won't even notice, that the source was NTSC!

btw.: it was an adult movie, cause I did not have any other long contnuous NTSC video.
I was looking to do the same for the same type of video (adult NTSC interlaced).
with the mvbob.rar package, there are heavy artifacts (paterns) during scene change.

Can you please tell me what exact script you used, to achieve these results?
Cause i am quite sure that you noticed many patern artifacts to your convertion too.

Right now i am trying this script, with different deinterlacer. (smoothdeinterlacer).
I am stuck with smoothedeinterlacer, cause it doesn't produce the artifacts that i see with, either kernelbob, or Leakkernelbob.
But i use a modified script of smoothdeinterlacer, that get rid of black horizontal lines during movemet.
Below is the script i am testing right now:
Import ("C:\Program Files\AviSynth 2.5\plugins\mvfpsscd.avs")

Mpeg2Source("xxx.d2v")

ConvertToYUY2(interlaced=true)
i=SmoothDeinterlace(doublerate=true,tff=true,lacethresh=1,staticthresh=10,showlace=false).converttoYV12()

i.mvfpsscd(50)
Lanczos4Resize(width,576)
Assumetff().Separatefields().selectevery(4,0,3).weave() #reinterlace
Allthough, there are still some artifacts (paterns) during fades, using the mvbob script, is worst, and a lot slower.
So can you tell us what script you used please? :) :)

[scharfis_brain]

please post a picture of those artifacts.

yes. mvbob() creates some weak artifacts on scene changes.
(they didn't bother me, because: hey its just a scene change :) )
they can be lowered by playing with th

and please: drop smoothdeinterlacer!
use TDeint(mode=1) instead!

[kle500]

@scharfis_brain

...hmmm. you know i can't post a picture here...
it's realy hard for me to find a nice frame to post.

I will try the Tdeint, thank's

if you want, i can send you some samples...

[kle500]

@scharfis_brain

With smoothdeinterlace, i have 2x the speed i have with Tdeint,
using a simple script NTSCi -> PALi
Why is that?
Is it correct?

[Tommy P]

Hi everybody!

First of all, thank you, scharfis_brain, for a great toolbox! And thanks to everybody who participated in this thread; for me the educational value I found here was unmeasurable.

I have a couple of questions though.

I shot some wedding video on a regular NTSC miniDV camera, then captured it using Premiere Pro 1.5. So it should be YUV 4:1:1, right? Well, when I use DirectShowSource("Clip.avi") to open the file in VDubMod, and then go to File -> Info, it shows as YUY2 4:2:2. Why? (When I use AVISource("Clip.avi"), the Panasonic DV codec installed on my computer spits out RGB, so it doesn't tell me anything about the original format.)

Next, I put together a video in Premiere Pro, add titles, transitions, etc. Then I export the finished video to uncompressed (well, to Huffyuv actually), and the output turns out to be RGB32. Why is that? I expected the output to be YUV, as I thought Premiere Pro could handle YUV internally?

OK, so far so good. Now I'm trying to do NTSC --> PAL conversion. Say, the exported clip is called Finished.avi (remember, it's RGB32)

Is there anything obviously wrong with this script, considering that I'm going to import the converted video into Premiere Pro again (but this time into a PAL project), and then use built-in MediaConcept encoder. My final destination is a PAL DVD.

########################################################
avisource("Finished.avi")
converttoyv12(interlaced=true)
mvbob()
lanczos4resize(width,576)
mvfps(50)
converttoRGB(interlaced=false)
assumebff().separatefields().selectevery(4,0,3).weave()
########################################################

Also, I'm a bit unclear about all this color conversion stuff, in particular, RGB32 vs RGB24. Does Premiere Pro really use the alpha channel? If not, can I force the output to be RGB24 to save space?

Thanks a lot!
Tommy

[vinetu]

Originally posted by Tommy P
Well, when I use DirectShowSource("Clip.avi") to open the file in VDubMod, and then go to File -> Info, it shows as YUY2 4:2:2. Why?
The DirectShow DV decoder filter installed on your computer spits out YUY2.
Originally posted by Tommy P
Next, I put together a video in Premiere Pro, add titles, transitions, etc. Then I export the finished video to uncompressed (well, to Huffyuv actually), and the output turns out to be RGB32. Why is that?

Output in Premiere Pro should be YUV only if you export to DV and the timeline contain only DV - All other cases output is RGB32.
Originally posted by Tommy P
Is there anything obviously wrong with this script...
Yes. Don't use "mvps(50)" and "assumebff().separatefields().selectevery(4,0,3)" in the same time.
Originally posted by Tommy P
Does Premiere Pro really use the alpha channel? If not, can I force the output to be RGB24 to save space?
Ha! This sound like "Does the autos realy use 4 wheels -I see only 3..." :)
In older versions it was possible to choose 24 or 32 bit - I doubt it's possible in PPro

[Tommy P]

Thank you, vinetu, for your quick response.

You wrote:
Don't use "mvfps(50)" and "assumebff().separatefields().selectevery(4,0,3)" in the same time

Do you mind explaining why? How would you correct this part of the script?

With respect to my other question ("Does Premiere Pro really use the alpha channel?"), perhaps I didn't make myself clear enough. What I was trying to ask was this:

How do I find out whether the Premiere uses the alpha channel in my particular project? Because if it doesn't, I'd like to strip it off when saving.

Thanks a lot!
Tommy

[morsa]

I started using MVBob today (I downloaded the mvbob.rar package).
I have an NTSC clip of a bridge passing through the screen which is giving me lots and lots of artifacts that make it unusable.
I'm using plain mvbob() function.May be I'm some way a little bit stupid and I need to tweak things a lot, but problem is after reading the whole thread I don't know where to start or what to change :( .
I also PM Scharfis offering the clip to use it as a torture one.

PS: BTW everytime I try to load mv60ito24 or mvfps any version of Vdub and/or VdubMod exit unexpectedly.I suspect It should be something related to Mvtools, but I don't really know.
I have P4 Prescott Hyperthreading 3.4 GHZ.

[scharfis_brain]

all other deinterlacers do fail on these clips, too!

so mvbob() must fail, because its mv-artifact-prevention relies on the standard-deinterlacers.

only the newest version of Tdeint introduces the ap-parameter, that is intended to deal with these artifacts.

[morsa]

yes, I know.It is just that MVbob, specially on the bridge clips, gives so many misaligned blocks that the clip gets really a mess.
I will see what happens if I use despot after it, may be I can treat those blocks as if they were "spots" :)

[Xesdeeni]

Can you post a couple of fields/frames just for reference?

Xesdeeni

[Krizzz989]

Originally posted by scharfis_brain
if your mvbob() is painfully slow, just comment out the extended motion search parameters:

mvf=bobd.mvanalyse(blksize=blksize,pel=pel,isb=false,chroma=true)#,search=3,searchparam=10)
mvb=bobd.mvanalyse(blksize=blksize,pel=pel,isb=true, chroma=true)#,search=3,searchparam=10)
I'm new to avs script editing, how do I comment out these two lines? Thanks in advance for any help.

[scharfis_brain]

the item I mentioned is already excluded from execution.
it is the code after the # - chars

[dragonfly]

What am I doing wrong?
I tested mvbob and the output was very good. But it wasn't playing smooth. Very very jerky output. I tried the following.
I used the zipped file from scharfis_brain. Thanks by the way for making life a bit easier :)

The source video was a vacation in Barcelona. It is a Pal - 25 fps - interlaced DV-movie. The colorspace is on my computer is YUY2.
The test material was 4 seconds in a shopping mall. The cars that drove through the shot were giving some artifacts on the video because they were driving fast.

I used this avs for the video.

LoadPlugin("\convolution3d.dll")
LoadPlugin("\UnDot.dll")
LoadPlugin("\MaskTools-v1.5.6\MaskTools.dll")
LoadPlugin("\warpsharp.dll")
LoadPlugin("\LoadPluginEx.dll")
LoadPlugin("\DustV5.dll")
LoadPlugin("\aWarpSharp.dll")
LoadPlugin("\DGDecode.dll")
LoadPlugin("\asharp.dll")

SetMemoryMax(256)

Import("D:\Captures\Avisynth Scripts\iip v0.5a.avs")
Import("D:\Captures\Avisynth Scripts\LimitedSharpen1.avs")
Import("D:\Captures\Avisynth Scripts\mvbob testing\mvbob.avs")

AviSource("\Testmaterial DV.avi")

Converttoyv12(interlaced=true)
assumebff()

mvbob(blksize= 8,
\ pel= 2 ,
\ lambda= 1000,
\ th= 8,
\ ths= 4,
\ bobth= 8,
\ predenoise= false
\ )


I loaded this avs-file in virtualdubmod and choose full processing mode without compression (virtualdubmod says "no compresion rgb", however my file is yuy2. Does this mean virtualdub converts the colorspace again?)
The encoding of this was very slow. 1 frame per second. And my harddisk was going insane through the whole encoding process. The source video is 13.7MB and the output video was 237MB!! How can this be?

I checked the logfile of virtualdubmod 1.5.10.1 and it was giving me this error al lot of times:

[i] Starting up: VirtualDubMod build 2439/release

[!] Dub: I/O thread has not cycled for ten seconds -- possible livelock.
(Thread location: 7C90EB94)


To come back where I began...What am I doing wrong? And what would you advise me?

[dragonfly]

Why can't CCE read this script?
Everytime I try to use mvbob in CCE it gives me an error. (http://img205.echo.cx/my.php?image=error8xa.jpg)

I eventually want to encode my file (look at the post above) with cce and burn it to dvd later.
[list=1]
Use script from my previous post to deinterlace the raw avi with mvbob in virtualdub.
Load the deinterlaced file from step 1 into another avs-script and use the filters iip and limtitedsharpen.
Load the script from step 2 into CCE and encode it.
Author the resulting file and burn it to dvd.
[/list=1]
Is this an efficient way of working?

[Mug Funky]

200/4 = 50. maybe HDTV can do this, but not CCE.

use "selectodd" after mvbob.

[dragonfly]

Thanks Mug Funky, it worked. But I want to know why I must put this in avisynth. I read that Selectodd() selects the even frames, but what has this to do with CCE? Does CCE always divide by 4? Because then I understand --> The clip is 100 frames, if I put SelectOdd() in the script then CCE selects 100 frames and divides it by four. If not it doubles the frames.

Sorry to go offtopic, but I want to understand this.

[scharfis_brain]

CCE only supports SDTV-framerates!

meaning:
23.976 fps NTSC Film (propressive)
25.0 fps PAL (progr. and interl.)
29.97 fps NTSC video (progr. and interl.)


50 or 59.94 fps, which are produced by bobbing in general and by MVbob also aren't supported by CCE, because those framerates are not SDTV!

[2Bdecided]

This post is about the motion compensated framerate change, rather than the motion compensated deinterlace, but since both are used in the PAL>NTSC conversion that we're discussing, I'll post here...

I've just used this package to convert a PAL video of a school play to NTSC. I used LeakKernelDeint(order=1) instead of mvbob because it increased the conversion speed significantly.

Overall the converted output was of excellent quality - better than you usually see on, say, BBC America.

However, there's a persistent problem which may be worth looking at - it happens in the test clips I used before, and happened a lot in this school video: Where you have a border between two very different colours (e.g. golden angel's wings and black background, or white paper and brown wall, or whatever), then (even when the scene is relatively, but not completely static) small slithers of one colour will briefly break out into the other colour. It seems to happen around vertical transitions, rather than horizontal (as far as I've noticed). I assume it's an issue with the motion vectors, but haven't checked. It's still there with mvbob - in fact it has nothing to do with the choice of deinterlacer.

It's a pity, because otherwise the conversion quality would be excellent. Though one other thing I noticed: when the teacher wagged her finger quickly, her finger disappeared!

I'm not posting to criticise or complain, just to point out areas for improvement, if the developers are interested.

Cheers,
David.

[Xesdeeni]

Did you notice whether this effect was in the original? DV recordings (at least NTSC ones) use 4:1:1. This means a single color is shared by four pixels. Most of the time, the colors are similar, so no harm. But if the difference between them is sufficient, there are very visible color errors.

I'm not sure about PAL DV. I've read that it can actually use either 4:1:1 or 4:2:0. But I think the choice is up to the camera.

A while back I tried to create a VirtualDub filter that helped with this. My idea was to use the luma (the 4) information to guess what the chroma (the two 1's) should be. I called it "Luma Follow." I also put in basic linear interpolation. Luma Follow didn't work as well as I expected, and I had to do some clamping that I didn't expect. The interpolation looked better. But either looked better than the DV codec output I use (MainConcept). You can find the filter and some samples at http://www.geocities.com/xesdeeni2001/.

For details, see this thread (http://forum.doom9.org/showthread.php?s=&threadid=58294), specificially this post (http://forum.doom9.org/showthread.php?s=&threadid=57013&perpage=20&pagenumber=2). For updates, see this thread (http://forum.doom9.org/showthread.php?s=&threadid=57013).

Xesdeeni

[Wilbert]

I'm not sure about PAL DV. I've read that it can actually use either 4:1:1 or 4:2:0.
I don't think you have read that somewhere :) It's 4:2:0 (with different sampling as MPEG-1/MPEG-2).

[2Bdecided]

Thanks for the reply Xesdeeni, that looks very useful - but it's not what I'm seeing here! What's happening is nowhere near as subtle, and is certainly not on the source - though it could easily be due to the motion compensation getting confused by slight colour bleed or noise in the source.

Imagine a big block of black next to a big block of white, like this...

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
this part is black this part is white

When there's some slight movement (e.g. a very slow camera pan), very occasionally the black part breaks out into the white, like this...

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX /
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX|
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

or something like that! I'll have to play with some parameters, because that might tame it, but I'm not going to redo the whole video because it took 8 hours and it's done and sent now!

Cheers,
David.

[Xesdeeni]

Originally posted by Wilbert
I don't think you have read that somewhere :) It's 4:2:0 (with different sampling as MPEG-1/MPEG-2).My bad. PAL DVCPRO 25 is apparently 4:1:1.

Xesdeeni

[vcmohan]

2Bdecided
It is not clear to me whats happening. Can you put different symbols for black and white pixels?

[2Bdecided]

Here's an actual example...

http://www.david.robinson.org/pics/mvfps_issue.jpg

PAL on the left, converted to NTSC on the right - just a small section, with the PAL original resized to make the comparison easy. The original was deinterlaced using mvbob, the conversion shot was grabbed before being re-interlaced.

The camera is tracking a character walking off to the right, so the stationary golden pillar is moving to the left of the shot. As you can see, the gold breaks out into the black during the conversion.

I wonder if it's noise or colour bleed on the original confusing mvfps, because the transition from gold to black looks very obvious to the human eye - so when it goes wrong, it's very obvious. It only happens for one field, so it draws your attention as a "flash" on the screen - and it happens reasonably often - you'll see something like this maybe 5-15 times in ten seconds of video if there's any panning.

I can't release the clip because it's not mine, but I see a similar thing with mvfps PAL>NTSC conversion on the SVT new mobile and calendar shot that's here:

http://www.ldv.ei.tum.de/liquid.php?page=70

A similar thing happens - the white of the calendar breaks out into the brown of the wallpaper.

It's only a little thing, but I thought it might help to know about it. If not - ignore it!

Btw, if there is a setting I should change to reduce this particular type of artefact, please let me know.

Cheers,
David.

[WorBry]

Mug Funky or Scharfis_Brain,

Until recently I've been using TDeint for deinterlacing my Pal DV Type II home movies prior to conversion to DivX at 50fps, as follows:

AVS Script:
avisource("Clip.avi")
ConvertToYUY2(interlaced=true)
ColorYUV(off_y=-16,gain_y=16) # to correct luma shift with Sony DV codec
TDeint(mode=1,order=0)
LanczosResize(720,544)
Convolution3D(1,4,5,3,4,2.8,0)
RemoveGrain(mode=2)
#
DivX 6 settings:
4000 kbps
2-pass
Unconstrained
EXtreme
key frame 250
B Frame single
no PV or GMC

The results have been very good, but having now tried MVBob in place of TDeint, I can only say WOW - slow, thats for sure, but well worth the wait. However, having looked at the MVBob script, which I cant pretend to fully understand, I see that it incorporates pre-denoise filters - Undot and Temporal Smooth. I know that image quality is somewhat subjective, but from a theoretical viewpoint, do you think that l should drop RemoveGrain from the script, and possibly also Conv3D? Alternatively, would it do any harm to replace Undot with RemoveGrain in the MVBob script. My only reasoning is that I found RemoveGrain to marginally improve the compressability of my DV clips compared to Undot, as also did Conv3D.

Although not specifically related to AVISynth, would you also recommend switching on "Global Motion Compensation" in the DivX settings, or is that dealt with by MVBob?

Any other pointers you could suggest for optimizing the results with Pal DV sources would be really appreciated, as after all of this experimentation, I'm keen to settle on a standard format.

Great work you guys. Frankly the results I've been getting with MVBob have quelled any notion I was having about changing to a progressive scan camcorder, much to my wife's relief....well, at least until they become more financially accessible (the camcorders that is) :)