Can anyone deinterlace this PAL DVD clip?

[mantis2k]

I'm in desperate need for an AVS script to de-interlace this film!!!

Thanks to previous help from generous people on this forum I've learnt how to deinterlace 3 types of video in the past, but this 4th type is proving a real challenge: it's basically an NTSC tape put through an old fashioned NTSC-to-PAL hardware conversion, recorded onto PAL tape (downgraded by a generation), before being captured to PAL DVD using a DVD Recorder (usually comes out Phase-Shifted Progressive on proper PAL VHS sources).

Using the Phase Shifted method, it comes out combed.
Using the Interlaced method, it comes out jerky.
A conversion with Canopus Procoder results in Ghosting.

Can anyone please help come up with a good script to make this progressive? I know the source is very poor quality, but I no longer have access to the original NTSC tape, so if anyone can help get this video deinterlaced and playing back atleast as smoothly as my software players are able to do so on-the-fly then I would be extremely grateful! I'm not looking for a perfect solution, as I realise there's no such thing with this horrid source--just something that works.

Download clip... (http://www.rarekungfumovies.com/clip.mpg)

If I can find out how to correctly deal with this 4th type of video then all my problems will be solved! Any help would be much appreciated.

[scharfis_brain]

mpeg2source("C:\forum\mantis2k\clip.d2v") #,cpu=6)
yadif(mode=1)
changefps(23.976*10)
selectevery(10,?)

replace ? by a number within 0...9

fir the sample clip ?=0 works quite well in restoring the video to its original 23.976fps.

but you may experience further stutter during the whole movie.
if this occurs you need to trim the movie in several parts an process them with their own ?-number.

[mantis2k]

OK Thanks! I'm about to try it now... Part of that code looks familiar... Is my clip Field Blended? Can you explain why my DVD recorder, which usually encodes in Phase-shifted, decides to come out Field Blended instead on certain PAL analogue sources that have had NTSC-to-PAL analogue treatment in the past...if that makes?

[scharfis_brain]

I don't looked for a phase shift. at least on cannot notice one since that video is standards converted.

you got teared fields instead of blended fields in you video.

remove everything besides mpeg2source().bob() and you'll see.
this must have been a REALLY cheapo standards conversion box.

the script basically BLINDLY selects all good fields by guessing a pattern.

but if that guess misses you'll end up with terrible sutter as well as teared frames

(teared = looks a lot like disabled VSync in PC-games)

[mantis2k]

I've just tested the script in VirtualDub and it appears to work very well during the 2nd half of the movie where the clip was taken from, but the 1st half appears to look better with ?=7 or something. In order to increase my arsenal of techniques for the future, can you please suggest any alternative scripts that do not require manual intervention? Anyway, I'm impressed you got it to come out smoother than WinDVD, so cheers for that method atleast.

[scharfis_brain]

no automatic approach is possible here!

[MOmonster]

I have only virtualdub-mpeg2 here and no avisynth, but I can´t see any blends:confused: .
My first try would be something like tdeint(mode=1,tryweave=true) with tdecimate (mode 2 with rate23,976 or something similar).
But I will have a closer look on the source next week.

Edit: Ok, I see. The teared fields are maybe no result of the virtualdub decoder, but in the source. This strong changes should be detectable with a small function. I´ll see next week.

[scharfis_brain]

@momonster: you're right. the could be a solution:
check each field, if it is built from its neighboring fields. if so then replace it by one of them.

but this may be difficult to do, cause you have a lot of orphaned field in this stream.

[MOmonster]

@scharfis_brain
If I looked right, this teared fields (they are only singles, surrounded by good ones, else your manual function also won´t work), don´t have any necessary informations to restore the original frames for good motion. Just replacing with the single neighbor and than decimating.
Maybe I think too easy this time.:rolleyes:

[scharfis_brain]

that was what I wanted to express.

but you first need a godd routine that can jugde a field for tearing

[MOmonster]

the detection of the tearing is no problem. The unofficial Mrestore1.9 build, Cdeblend v1.0 (not the last 1.1) and for example this small modification can do this:
function Cdeblend_mod3(clip clp, float "mlimit", float "xr", float "yr",clip "dclip")
{
###### parameters ######
global mlim = abs(default(mlimit, 0.5)) #motion limit
global irate = framerate(clp) #input framerate

xr = 0.125 / default(xr, 1.5) #x detection reduction
yr = 0.125 / default(yr, 2.0) #y detection reduction


###### source preparation ######
global det = default(dclip,clp).bilinearresize(int(width(clp)*xr)*8,int(height(clp)*yr)*8).KillAudio().ConvertToYV12()
global det3 = blankclip(det,pixel_type="YV12",length=3)+det
global out = clp.duplicateframe(0)


###### initialise variables ######
global cfo = 0
global cut = 1
global lifr = 44


###### final evaluation ######
ScriptClip(clp, " out.trim(cfo+1,0)")

FrameEvaluate(last, "

## preparation ##
cifr = current_frame % round(irate*1000)
cut = (lifr+1) % round(irate*1000) == cifr ? 0 : 1
global lifr = cifr

## value calculating & shifting ##
global cp2 = cut==0 ? cp1 : YDifferenceToNext(det3.trim(1,0))
global cp1 = cut==0 ? cn0 : YDifferenceToNext(det3.trim(2,0))
global cn0 = cut==0 ? cn1 : YDifferenceToNext(det)
global cn1 = YDifferenceToNext(det.trim(1,0))

global mp2 = cut==0 ? mp1 : LumaDifference(det3.trim(1,0),det)
global mp1 = cut==0 ? mn0 : LumaDifference(det3.trim(2,0),det.trim(1,0))
global mn0 = LumaDifference(det,det.trim(2,0))

## output calculation ##
global cfo = (cp1+cn0)/mp1>(cp2+cp1)/mp2 || (cp1+cn0)/mp1>(cn0+cn1)/mn0 ? 0 :
\ cp1<cn0 ? -1 : 1

")

return last
}
A simple and fast detection.:)
But I don´t get it fluid with the decimators I tested. There are singles and often three dups. It`s not easy to decimate it. The only satisfied results give your manual method (needs some time because there are edits, but of course works better than every automatic machine) and Mrestore v1.9 (no release until v2.0, produces two dups in this short sample, because code for dup detection not implemented yet, if find the time I`ll finish it during the next two weeks).