Srestore cannot do the trick (Problem with unblending)

[kenpachi]

example: http://www.speedyshare.com/files/23364732/example.rar

The upper link contains a sample cut of a clip being the reason why I'm posting. Usually with 3:2 pulldown sources I use combination of Bob deinterlecing (double framerate) and next Srestore() function but this time encoding of such a script generates something similar to duplicates. It is less noticeable after encoding whole clip but still. Is there anything I can do about it? I have tried some other deinterlacers and Unblending methods but with no result. Also've tried to change thresh param in Srestore() but with no effect. I think I can imagine why it's all so: Srestore with default param rate(22) is performing unblending to desired 23.976 and got to keep a certain amount of frames to do this. This is why there are frames very similar to each other because of kinda interleaving between prev and next frame which are both nearly similar at some point after Yadif(mode=1, order=-1). Although I can imagine why I don't like it. This is the script I use:


mpeg2source(".\example.d2v")

Yadif(mode = 1, order = -1)
#DGBob(order=1, mode=1)
#Tdeint(mode=1)
#KernelDeint(order=1, threshold=10, twoway=true)
Srestore()
#AnimeIVTC(mode=2)
#Cdeblend(omode=1)
#RestoreFPS(24/1.001, 0.00)

#ord = last.getparity() ? 1 : 0
#a = leakkernelbob(order=ord, sharp=true, twoway=true, threshold=7)
#deint = Cdeint(bob=a, bmode=2, nlv=0)
#tfm(order=-1, mode=0, cthresh=6, MI=64, display=false, mChroma=true, pp=2, clip2=deint)

#fdecimate(rate=23.976,threshold=1.0, metrics=false)

Undot()

Crop(14, 4, 690, 570)
Lanczos4Resize(608, 496)

Info()

[dansrfe]

I don't understand. Why don't you just use fielddeinterlace()? This appears to be a simple 25i stream. What's the use of unblending and using all these restore functions?

[kenpachi]

Because simple deinterlacing leaves 'ghost effect' in this precise example. I'm pretty sure this is that famous 3:2 pulldown. The example doesn't show it maybe 'cause there's little movement but elsewhere ghosts are more visible. The point is the clip probably came original from NTSC tv, then released on PAL dvd. This is how I see it.

[Didée]

@ dansrfe: Yeah, it's simple 25i, indeed ...
It's simple 25i, containing simple fieldblending, due to a simple NTSC>PAL normconversion. You can simply deinterlace it, leading to simple crappola. :)


@ kenpachi
That sample is simp... sorry, is just too short to judge whether-or-not Srestore is working properly. Though, from this too short sample it seems like it's basically working correct, only the test scenario is chosen unluckily.

a) There are some dups at the very start - that doesn't really count, since the very start is always a bit whacky with such blend-restaurations

b) there are some dups immediately after the scenechange. Well okay ... scenechanges sometimes are a bit problematic as such. And moreover, in this sample the scenechange is very shortly after the start of the sample ... Srestore didn't yet have a fair chance to lock onto any pattern/rythm, and -boom- is presented with a scenechange.

After this problematic start, everything seems well so far.

On its own, this short sample doesn't tell very much. For a more reliable evaluation, you really need to look at longer sequence/s.

[kenpachi]

@Didée: Well, I've already encoded the whole clip (6min) with Srestore() and as You notice, the dups appear after every scenechange - in the rest of the clip Srestore() works fine. These 'few' dups still worry me, though. This is because the same DVD contains another clip (trailer of the movie) interlaced with the same method (leaving same ghosts after simple deinterlacing) which when encoded with Srestore(), contained no dups at all and this is why I'd been alarmed. You all say it's just simple 25i. If so, why does it leave so much blending? Other interlaced DVD movies (main movie tracks though) do not leave any blending after deinterlacing. Am I oversensitive? What I need to add is I'm a rookie. What does 'simple crappola' reference to? Should I just deinterlace it as dansrfe said and leave the subject? Down here another example with some more movement:

http://www.speedyshare.com/files/23368008/example2.rar

[Gavino]

What does 'simple crappola' reference to?
http://www.urbandictionary.com/define.php?term=crappola
Simple! :)

[dansrfe]

:o this does have ghosting

[Didée]

You all say it's just simple 25i. If so, why does it leave so much blending?

Hey, don't take the "simple" part serious. I just tried to cast some humour towards dansrfe. This is defintetly a task for blend-restauration. Plain deinterlacing won't get you very far.

Alas, my best (poor) advice is to play with Srestore's various parameters, and see if something makes a difference. I'm fairly familiar with the theoretical side of blendconversions, and with the processing methods that I once had build for this problem (some might remember Restore24, R.I.P.). But I'm not very familiar with the inner working of Srestore ... the code is cryptic, the creator never bothered to explain the cryptics, and personally I've almost no need anymore for deblending. Hence I don't know how to tame Srestore in case it goes wild. Sorry.

[manono]

I don't see the problem. SRestore does a good job on the second sample. I don't know why you've mentioned 3:2 pulldown twice, though. There's nothing to do with pulldown in these samples.

[foxyshadis]

If every scenechange is broken, the video was re-cut and edited after being fieldblended. There's not a lot you can do, though parameter playing might get you closer: try lowering thresh to 12 or adding cache=2.

[dansrfe]

...the video was re-cut and edited after being fieldblended.

:eek: Sometimes I wish film prints are given more care :( They go through so much crap to reach the dvd when it's simpler to have performed the transfer to dvd the right way imho. I guess it amounts to the transfer department's communication with the authoring department and how much either of them care about doing it right.

[kenpachi]

@Didée: Shame I didn't get it. Must've not read the joke properly ;] And talking about Your Restore24 - can You give it a try on Your own with the first example? I did try myself but haven't managed to get the plugin working yet.

@manono: Can be but it's just a sample. The dups do exist but probably just not in this cut.

[Emulgator]

Just by chance I fed your file into my bergwerk script and unintentionally had AnimeIVTC still commented in.
After SeparateFields I saw quite usable progressive frames and wondered...
I had overlooked this line, it was still commented in.

This did the trick:

AnimeIVTC(mode=2, aa=4, precision=3, killcomb=0, cache=15, normconv=true, bbob=3, omode=1, dark=0.2, thin=10, sharp=120)

[kenpachi]

@Emulgator: I was full of hope at first but as the matter of fact it doesn't work on my machine. The preview of the IVTC script doesn't contain dups but only when enabling bbob=4 in my case. However it's unimportant. After encoding dups still exist. Have You encoded it?

I believe this is no more matter of plugin techniques. You all try encode example1 with Srestore or IVTC but including Info() on the end. Then preview it in VirtualDub frame after frame. When it comes to dups (about 25th frame) Info() FrameCount shows the dups are eventually only duplicates - I've just noticed. I think this is all to keep framerate accurate. AnimeIVTC doesn't show it on preview sometimes but this is due to its internal cache, I guess. Comparing with preview of Srestore Info() TotalTime is the same but Info() TimeOfFrame is different. I wish there was a solution to that.


EDIT:
I got good news and bad news. The good is I managed to fix the dups and the bad is I did it using simple Trim()s ;] Fortunately it was just ~9800 frames to look through.

[Emulgator]

I haven't encoded your short sample yet,
just in my application the expected framecount seemed to match the decimation to be executed,
so I will have to report if it really works with my source. Preview was very promising.
The preparation passes are not finished yet,
I had to start all over again because of necessary fixes in half top/bottom scanline repairs,
but since I finally split repair this into fields it should work better now...

[Emulgator]

No, unfortunately my find is unusable for your source.
Applying ComplementParity before AnimeIVTC:
Dupes 0=1=2, 7=8, 32=33, 55=56, 81=82, 83=84
Blended: 19
Dropped: 21, 44, 70.