weird interlacing prob. NTSC -> PAL

[aand]

I've got this intelaced video that looks like chewed pizza :). It's probably NTSC->PAL.
After separatefields() I get this sequence of fields:

udu du dud s du du du dud ud s du dud ud udu s ud udu du du s etc.

u - up field
d - down field
dud -down-up-down sequence of fields from the same frame
s- single field from another frame (didn't check if it's up or down)

Any idea on "cleaning" this? I've tried removing duplicate fields with selecteven/odd.TDecimate.interleave, but it's complicated getting the frames back in order...

[Guest]

Post a sample of the unprocessed source.

[aand]

7sec 7.5MB sample (http://www.mediafire.com/?i2mscxcv40b)
:thanks: for helping!

[Nightshiver]

animeivtc(mode=2,aa=2)

and

tfm(order=1).tdecimate(hybrid=1)

seem to work.

[aand]

Look at the quality. There's no detail. order=1 means tff but this video is changeing order and some frames only have one field. Also tdecimate's hybrid=1 blends 30p into 24,976p, so more blurring... I think.
I've written a series of 50 fields and after removing the duplicates, there remain 5 frames with one field and 19 with two fields->24 frames (NTSC IVTCed).

I was talking about TFM, I've never used avimeivtc. Isn't that for anime?

[Nightshiver]

No. Just because it has anime in it doesn't mean it crashes on regular movies. It works for all kinds of videos. And from DGIndex, your video is pal, 25fps, interlaces, and TFF.

[45tripp]

with all the orphans
i'd probably try what seems easiest,
to bob, and then multidecimate().
trim to sections of differing thresholds,
and kill dups.

[thetoof]

#tcomb for dotcrawl
animeivtc(2,aa=0,iregion="pal",oregion="ntsc",edimode="nnedi", wavaudio="youraudiofile.wav")

[aand]

Unfortunately I can't get AnimeIVTC to work. I'm using Avisynth 2.5.8RC3. The problem plugin is ReduceFlicker. If I don't explicitly use LoadPlugin() in the script, I get an error: cannot load plugin ReduceFlicker.dll. Also can't load RemoveGrain.
If I use LoadPlugin(ReduceFlicker.dll) in the beginnig of the script, one core of the CPU goes to 100% and the program becomes unresponsive (I'm using MeGUI; AvsP crashes). Any idea? I'm gonna try to remove some of the plugins, maybe there's a sort of conflict, I don't know. I'll post in ReduceFlicker thread too.
PS: I've read about AnimeIVTC, can't wait to try it out :)

[Nightshiver]

Use avisynth 2.5.7 (it's what I'm using until 2.5.8 becomes official)

[thetoof]

Try changing your version (sse3 if your comp can use it, sse2 if it can't and "normal" at last resort)

[Comatose]

I've had the RemoveGrain issue before. Make sure you have AVSRecursion.dll in system32.
Who knows, it might be the same issue as ReduceFlicker too.

[aand]

I've got AVSRecursion in SysWOW64 (I'm using 64 bit XP).
I've tried every variant... Uninstalled 2.5.8 RC3 and installed 2.5.7.
Removed all plugins except for those needed by AnimeIVTC.
Now i'm using removegrain (no sse) and when I hit preview in MeGUI or AvsP, one CPU core jumps to 100% and that's all.
I've waited a few minutes and nothing appears. I'll try some more things and get back to you.

[aand]

TempGaussMC_beta1mod did a great job (I don't think it gets better then this). Now, AnimeIVTC mysteriously works. The resulting frames are identical to those resulted from only using TempGauss, but AnimeIVTC is 15 times slower (0.1 to 1.6 fps)... And the mode 4 blend detection leaves some dupes. I'm sticking to TGMC and I'll see what I can throw away from it's 50fps.

[TheRyuu]

Try changing your version (sse3 if your comp can use it, sse2 if it can't and "normal" at last resort)

No, don't use the sse3 version. Causes random crashes.
Consider the sse2 version to be the highest one for any cpu that supports sse2 or higher.

[Nightshiver]

*Sigh* If you want it to go faster, do a rendering pass.

[thetoof]

v1.0 pre-release Latest edition with SSE3 fix (http://avisynth.org/mediawiki/Removegrain) is the version distributed with animeivtc.

AnimeIVTC uses TGMCb1 for bobbing with precision=3 (default) so yes, it'll lead to the same visual result... and about speed, animeivtc decimates the bobbed stream after removing the blends, so of course it'll be slower.
As Nightshiver said, you can speed up the overall process if your comp can't handle everything animeivtc does at the same time. FYI, the script I gave you runs @ 1.11fps on mine. How much RAM do you have?
Regarding the dups, I noticed it, but after testing it showed that no motion was lost, meaning that the actual framerate of your clip is lower than 23,976fps. I'll come back at you with the pattern (or you could test it yourself to find it). Another solution would be to go vfr with dedup().

[aand]

I have 1GB of RAM.
I'm trying to decimate 26 of the resulting 50fps with TDecimate but in a certain point it cuts a series of black frames, leaving more 'visible' dups behind. It considers all the 7-8 black frames in the series as dups because there's not much difference between them. Only 3-4 of them should be discarded. Any advice?

[thetoof]

1 - to use tgmc + other filters, you need a LOT of ram, so you may have to split your script and do lossless rendering passes with a high setmemorymax
2 - The animeivtc call I gave you does exactly that : tgmc().tdecimate(1,13,25) (decimates 13 frames out of 25... 26 out of 50)
3 - As I said before, the problem lies in the fact that your clip doesn't have 24 frames with motion in the bobbed 50fps clip, but 23 (checking frame by frame reveals that), so you must use tdecimate(1,27,50) and it'll give you a restored clip @ 23fps... You can speed it up afterwards if you wish to get a standard framerate, but to avoid getting dups and keep the full temporal resolution or your source, that's what you need.
4 - for the black frames.... dunno, since you know about it you could use a simple trim... maybe a setting exists in tdecimate to correct that, but I'm not aware of it