TDeint and TIVTC

[Boulder]

I'd expect that cropping horizontally is OK, and cropping vertically mod-4 also to be OK.

[Mystery Keeper]

Originally Posted by Boulder

I'd expect that cropping horizontally is OK, and cropping vertically mod-4 also to be OK.

Only cropping mod16 is safe. One should crop mod16, do what needs to be done and then crop the rest.

[Didée]

Originally Posted by Mystery Keeper

Only cropping mod16 is safe. One should crop mod16, do what needs to be done and then crop the rest.

Ah, a statement. Please explain why it should be so.

(I don't see why mod16 should be required for purposes of IVTC or deinterlacing in general. mod4 vertically is a technical requirement for YV12 sources, since that's the "luma distance" between same-parity chroma samples. That's all.)

[Mystery Keeper]

Originally Posted by Didée

Ah, a statement. Please explain why it should be so.

(I don't see why mod16 should be required for purposes of IVTC or deinterlacing in general. mod4 vertically is a technical requirement for YV12 sources, since that's the "luma distance" between same-parity chroma samples. That's all.)

I tried cropping before deinterlacing with TempGaussMC and it gave me ghosting ^_^'

[Didée]

During testing TGMC, I'm often cropping wildly around on the input, only caring for mod-4, not -16, and never got any unusual ghosting. Feel free to post script + material that makes your observation reproducable.

Again, mod4 is the only technical requirement in this case.

[Adub]

Ah, so that was the trick to it. it's okay to crop horizontally. but when cropping vertically, always respect mod 4.

[thetoof]

Hi,
I've got something fairly complicated to do via vfr decimation, so I've got a help request if it's doable and a feature request if it isn't

Let's say I have these framerates :
a=23.976
b=25
c=29.97
d=59.94
They were then spliced together with
a.changefps(d)+b.changefps(d)+c.changefps(d)+d
So, I have a CFR clip @ 59.94fps with tons of duplicates (that I want to remove via vfr decimation). How can I do that???

Also, there are many duplicates in the 23.976 clip and it could be decimated to very low framerates for a couple of frames (even below 8 fps) So, I was wondering if it would be possible to have a vfr decimation that adapts to the amount of motion and uses framerates other than the standards ones to display the same motion to encode a lot less frames with no visual difference (in anime you can even have the same frame for more than 1 second after all the noise has been removed).

Here is a test clip I have created for the occasion that replicates the situation I just described: http://rapidshare.com/files/14149600...stclip.7z.html

[sander815]

how do i call the multithreaded version of this plugin? EEDI2_imp.dll

[foxyshadis]

You replace EEDI2.dll with that one. That's it.

[aand]

Question about TDecimate:
I have a series of black frames; instead of cutting some of them, it removes all of them and leaves more 'visible' dups behind.
Is there a way of setting <max nr of dups in a row> ? If not, I'm making an official feature request .
Thanks.

[r00t61]

Is there any way I can set the location of the debug output information provided by TFM/TDecimate (i.e, when display=true)? Currently, the output is always fixed to the upper left-hand corner, so if I have display=true on for both TFM/TDecimate, the debug output from TDecimate overlays on top, obscuring the debug output for TFM.

I'd like to be able to see both sets of debug data at the same time.

[thetoof]

I didn't check the doc, but a quick and dirty way of doing it is by using stackvertical/horizontal to see the same frame with different info, or by cropping the part of the frame where the info is to overlay it on another corner.

source=your source
tfminfo=source.tfm(settings).crop(select the part of the frame containing the info here)
tdecimateinfo=source.tdecimate(settings)
overlay(tdecimateinfo,tfminfo,coordinates where you want to overlay)
#uncomment the next line to tweak the crop settings
#return tfminfo

[r00t61]

Well, thetoof, your suggestion didn't quite work out the way I wanted to, but I'll keep experimenting. Thanks.

In the meantime, is there any to alter TDecimate's behavior for vfr output (i.e., when mode=5), for handling 30p video sections? In particular, I would like to make TDecimate perform a bob (59.94 fps) instead of a blend decimation for those sections designated as video, while still IVTCing/decimating the film portions to 23.976 fps.

[thetoof]

You may be interested in AnimeIVTC, as it bobs interlaced sections & IVTC telecined ones to create a VFR clip. See mode=3, 4 or 6 with omode=2.

[canuckerfan]

i have a clip here which i'm trying to deinterlace correctly... it's hard telecined without any blends so an ivtc should work. however, I'm having a hard time determining the field order. I've tried the separatefields().assumetff test but both tff and bff show no backward motion. weird. so far I've thrown 2 scripts at it:

interp = nnedi(field=1)
deint = tdeint(mode=0,order=1,field=1,edeint=interp,slow=2,emask=TMM(mode=0,order=1,field=1))
tfm(mode=3,order=1,clip2=deint,slow=2)
tdecimate()

interp = nnedi(field=1)
deint = yadifmod(edeint=interp)
tfm(mode=3,order=1,clip2=deint,slow=2)
tdecimate()

both produce pretty much the same result to my eyes and the ivtc looks pretty decent. but I'm wondering if this is right with the field order discrepancy. here's the clip(23 mb): http://www.sendspace.com/file/upa8m7

[AVIL]

IMHO your clip is progressive. No temporal difference between fields. Only spatial one. There is some residual combing that you can fight with plugin vinverse. Internal function Info() says that the clip is bff .In fact, when assumed as bff, after separatefields() the first field has the top line. But deinterlace this progressive clip is unnecesary (again IMHO). In scenes with motion there is blending. Try to deblend first.

[canuckerfan]

Originally Posted by AVIL

IMHO your clip is progressive. No temporal difference between fields. Only spatial one. There is some residual combing that you can fight with plugin vinverse. Internal function Info() says that the clip is bff .In fact, when assumed as bff, after separatefields() the first field has the top line. But deinterlace this progressive clip is unnecesary (again IMHO). In scenes with motion there is blending. Try to deblend first.

thanks for your input. why i seem to think it's partially interlaced is because of the horizontal lines evident throughout the clip. classic sign of interlacing. in fact, it seems to follow a 3p/2i pattern. as for blending... i separated the fields and didn't see any myself. during high motion there is plenty of blurriness, however.

[manono]

AssumeTFF().SeparateFields()#plays smoothly
AssumeBFF().SeparateFields()#plays jerky

The sample is TFF and any simple IVTC seems to work. It's not field-blended, although there does seem to be some sort of motion blur or similar going on.

[canuckerfan]

Originally Posted by manono

AssumeTFF().SeparateFields()#plays smoothly
AssumeBFF().SeparateFields()#plays jerky

The sample is TFF and any simple IVTC seems to work. It's not field-blended, although there does seem to be some sort of motion blur or similar going on.

yea, I don't know what the hell that stuff is. thanks. your input has confirmed my thoughts.

[AVIL]

I have repeated my test but using dgindex/dgdecode. Formerly I've used directshowsource (an enourmous mistake). My new results agree totally with manono's ones.