TDeint and TIVTC

[tritical]

Yeah, TDeint could be improved quite a bit. I actually have a lot of ideas stored away for improving static area detection, interpolation, and temporal stability, but it would really need to be a complete rewrite starting from scratch at this point. Also, I spend a lot more time on TIVTC because I actually use it for 99.9% of what I encode whereas I almost never deal with interlaced material. Therefore, I don't have as much motivation to work on TDeint. In fact, I don't think I've ever actually encoded a clip longer than a minute or two with TDeint .

[Didée]

Sorry for being sluggish again, tritical. Report will come.

For now, TDecimate(mode=7) works pretty good. At the finish line, it's stepping right into SmartDecimate's hoes

But I think there's a bug in it:

Used within Restore24, converting 25->23.976, it works fine up to frame ~19000. (output frame. Sorce frame ~19800, bobbed frame ~39600). From there on, duplicates are created every second. It seems that some miscounting (or rounding error?) is happening.
I confirmed that both SmartDecimate and TDecimate(mode=2) work correctly with the same setup. The error can also be reproduced by loading the script, jumping directly to 19000, and playing from there (so it's not R24's blend replacement doing something wrong after a certain amount of frames). And with trim(19000,0) the formerly b0rked section comes out fine, but again the errors start at ~19000. So it's not the source, either.

[Egh]

Originally Posted by tritical

Yeah, TDeint could be improved quite a bit. I actually have a lot of ideas stored away for improving static area detection, interpolation, and temporal stability, but it would really need to be a complete rewrite starting from scratch at this point. Also, I spend a lot more time on TIVTC because I actually use it for 99.9% of what I encode whereas I almost never deal with interlaced material. Therefore, I don't have as much motivation to work on TDeint. In fact, I don't think I've ever actually encoded a clip longer than a minute or two with TDeint .

Tritical:

Thanks for you job But the thing is that TDeint is needed when DVD producers created something new and strange again Like now i'm dealing with source where there're fadings added to 24fps animated source. Ofc, the fadings are 30fps. And applying of TDeint ofc removed combing... Creating *very* powerful noise. And it's so powerful that PixieDust doesn't work on that scene (creates blocks). Amongst casual filters you need something like hqdn3d(5) at the very least to reduce the noise (but the picture looks not good in terms in quality after that). Sangnom doesn't produce noise (although the picture quality is not good either).

Luckily in this case I used one of my pwn "sledgehammer" filtering presets and managed to remove that heavy noise without any serious detail loss. But it would be great if TDeint didn't make that noise in the first place.

Also, not so recently, while working on hellsing ultimate ova trailer, i noticed strange artefacts in one of the interlaced flash scenes. TDeint created big ugly grey spots in areas where there's nothing similar to that at all. Sangnom didn't have any artefacts there. If you need, I can dig that project up and show you the screenshots. (I didn't release my version cause in the end it was only marginally better than Fluffy's one. Btw he also noticed that artefacts and had to use a workaround with different deinterlacing for that scenes).

And while working on saikano ova (yes, i'm the one responsible for #PSNR release ^^), more precisely on the "Second Mission preview" (note that trailers, promos, previews and so on usually have lots of interlaced content, more than actual episode does, so deinterlacer is highly needed while encoding), in one scene i noticed strange thing -- despite quite heavy combing all other the picture several frames in a row, TDeint *ignored* that combing at all. Some advised me to tweak the settings for TDeint, but I just switched to sangnom for that preview (and sangnom picked that combing w/o any problems).

And note that I do think TDeint is better than sangnom in general, the quality of picture is better and more sharp (in the way I like it). But using TDeint still has some issues atm, you have to treat it carefully and look for possible artefacts.

Also, if possible, I'd like more explanation/recommendation on different modes of TDeint. Especially the difference between 1<->3 and Kernel modes.

[tritical]

@Didée
Any possibility I could get a sample? Cause I honestly can't think of anything that would cause that to happen... I will try testing a longer sequence when I get home and see if it behaves strangely.

@Egh
All your descriptions sound like typical motion adaptive artifacts to me, and since sangnom discards one whole field it would not show any of that type. If you set the motion thresholds in tdeint to -1 do the artifacts go away? or you could use AP=0,APType=0, which would eliminate those type of artifacts as well. Of course doing that means you're giving up motion adaptation. I have used TDeint to deinterlace some bad sections of anime episodes and often end up setting the motion thresholds to -1 because the temporal order of the fields is all screwed up (separatefields() is jerky with both assumetff() and assumebff()) which will make TDeint create some interesting effects that would fit your description:

TDeint created big ugly grey spots in areas where there's nothing similar to that at all.

Also, motion-detection in tdeint by default is 5 fields and only pixels from the same field are compared, but motion of the top and bottom neighbor pixels in the other field are considered. That 5 field window is behind/ahead/across the current field. So often you get parts where it clearly looks like an area is in motion to a person, but if you look at it on the single pixel level the way TDeint does then it appears stationary. That is what often leads to the type of artifacts you describe. Especially, flashing scenes will be a problem.

I've got to go now, but I'll try to explain the modes in more detail later tonight sometime.

[Didée]

tritical - no additional sample is needed. Just pad the sample's start by X frames with Loop() or BlankClip(). Load the script, jump to frame X, and play from there on.

Interestingly, now on the other PC the effect does not start around output frame 19000, but around 40000 instead.

Dunno what it is, but it's not R24 itself. When jumping far into the source directly after loading the script, then R24 is making a "cold" start - it uses absolutely no reference to the actual position in the stream. Whereas I suppose the decimator to use such a reference, in some way.

[tritical]

Could you describe some exact steps to follow to reproduce the problem using the clip you sent before? I tried appending 50000 and 100000 frames using blankclip to the clip before sending it into restore24 and saving the clip that gets fed into tdecimate inside of restore24 to a lossless file then opening that avi file back in avisynth and adding 50000 and 100000 frames to the front of it. None of those scenarios produced problems.

[Didée]

I just use

padding = 50000

src=mpeg2source("ENT_Marodeure_snip2.d2v")
src.trim(1,1).loop(int(padding/23.976*25.0)) + src
Restore24( blabla )

Results (updated 20:45 - had put the wrong snapshots in it).
This little padding trick reproduces exactly what I am getting in normal full-lenght encodings.

Could it somehow be related to the used Avisynth version? On my 2 PCs I am, still, using AviSynth 2.55 from Dec.19.2004 resp. Jul.29.2004.
(I stuck with those because having SmartDecimate working reliably was always a must.)


[edit] Update:

I tried with the Avisynth RCs from your website (avisynth 2.5.6 - 9.18.2005 / - 16):

- No change for TDecimate - mode=7 still produces dupes on high frame numbers

- Now, if I try to load SmartDecimate.dll, VirtualDub vanishes. (That's why I still sit on those old Avisynth versions.)

[tritical]

I'll try your script and see what happens.

Now, if I try to load SmartDecimate.dll, VirtualDub vanishes. (That's why I still sit on those old Avisynth versions.)

If you use mine make sure you use avisynth_c_loadcplugin() after loading avisynth_c.dll. In my builds I made it so external plugins such as loadpluginex/avisynth_c cannot replace avisynth's internal loadplugin() and loadcplugin() functions, but you can still access the functions of those dll's using dllname_loadplugin(). Unfortunately, I didn't test it enough... it should have given you an error, but avisynth's internal loadcplugin() routine now assumes __stdcall and smartdecimate exports avisynth_c_plugin_init as _cdecl so it finds the function, but when it attempts to call it it crashes becauses of the mismatched calling conventions. Will have to fix that on the next build.

EDIT: I put up new builds to fix the above crash, there had been a few other memory leak fixes since the last builds anyways.

[Egh]

Tritical:

I've seen yet another crazy bug in TDeint It's crazy one, but true

So i have again real source, not some test, and in some places applied text is interlaced. So naturally one needs deinterlace for it.

Here TFM+yatta made P-match on that frame.

Here's source frame: http://xs49.xs.to/pics/05402/sourc1.png

Here's what fielddeinterlace does, not good, but at least does the job http://xs49.xs.to/pics/05402/sourc1_blended.png

Here's what TDeint does :P
http://xs49.xs.to/pics/05402/sourc1_tdeint_frame1.png
http://xs49.xs.to/pics/05402/sourc1_tdeint_frame2.png

Not one but *two* frames :P And this behaviour seems independent on the mode chosen in TDeint. Also that's not the single frame which causes that frame doubling, in all similar cases in both episodes the result was same.

[TheBashar]

Originally Posted by Egh

Here's what TDeint does :P

What's your exact TDeint command call look like?

[Revgen]

Originally Posted by TheBashar

What's your exact TDeint command call look like?

I'd like to know too.

Perhaps we can start using TDeint to remove logos!

[tritical]

Change the field that is interpolated if you want to keep the text on that frame because the writing on the source frame you posted is only in the bottom field, but the top field is the one being kept.

[Egh]

Originally Posted by tritical

Change the field that is interpolated if you want to keep the text on that frame because the writing on the source frame you posted is only in the bottom field, but the top field is the one being kept.

Well, that's NOT a problem there. Two frames instead of one -- that's a problem. Meaning on those scrolling scenes that means broking smoothness of animation because of additional duplicate.

And it can't be decimated -- cause original animation is 23.976, it has duplicates to decimate already.

So do you always use top field only? How to change that only for some particular frames?

For others: the command is exactly standard thing which yatta uses.

YattaPreMatchClip = last
FieldHint(ovr="G:\1\himm01.pet\himm01.d2v.fh.txt")
TDeint(clip2=YattaPreMatchClip,hints=true,order=1,type=3,sharp=false)
That's copied from my upcoming HiMM R2 project, of course Since I had to use FieldDeinterlace for Ichigo Mashimaru. Retaining text on those frames is not particulary important, it's only one frame at a time. But getting additional duplicates is out of question for panning/scrolling scenes :P

[tritical]

Which field are you doing frame matching off of? You should set tdeint to keep the same field as you are matching from (if you are matching off top set field=1, if you are matching off bottom set field =0).. by default field is set to the same value as order. You can override the value of field for one frame or a range of frames using an overrides file. If you could upload the clip to my ftp I will take a look at it.

68.119.245.113:17252
upload/upload

[Egh]

Originally Posted by tritical

Which field are you doing frame matching off of? You should set tdeint to keep the same field as you are matching from (if you are matching off top set field=1, if you are matching off bottom set field =0).. by default field is set to the same value as order. You can override the value of field for one frame or a range of frames using an overrides file. If you could upload the clip to my ftp I will take a look at it.

Thanks, i will cut some part from vob with those frames and upload it.

Remember that i do stuff from yatta. So if it's yatta's fault somehow, tell me and I will ask Myrsloik to fix/improve it. How to assign frame/range field override in yatta?

=Update=
Sending the file to ftp atm. I used TFM (older than current version) and yatta on it.

[tritical]

@Egh
Thanks, I'll take a look at it tommorrow.

@Didée
I finally figured out what was happening using the script you posted. It wasn't actually related to the frame number at all. I had modified the decision code to specially handle a common case for restore24 processed video, but didn't make it exclusive enough and it was being triggered for other cases. When that happened it selected the next frame instead of the current frame, and if the stream was in just the right place it would throw things off such that eventually it would end up in a situation trying to select between two frames that were both duplicates of the previously delievered frame. Anyways, I will put up a new version tommorrow, I've also expanded the debug/display output for mode 7 to include more info.

[Didée]

That's good news
Since, apart from this issue, mode 7 seems to play very nice ... didn't find anything else I could complain about

[tritical]

@Egh
I looked at your clip real quick and it is fine as long as the deinterlacer is keeping the same field as is being matched from.. i.e. the following produces a smooth result:

mpeg2source("C:\test.d2v")
deinted = last.tdeint(order=1,type=3)
tfm(d2v="C:\test.d2v",micmatching=0,clip2=deinted)
tdecimate(mode=1)

in the above script both tfm/tdeint will use field=1 by default since order=1. It will also work if you set field=0 in both. Also note the micmatching=0, in the last version I made it default to 1, but it will need to be zero for this clip else it will use a u on the combed frames creating an extra duplicate. However, if you are using a version prior to v0.9.11.0 it defaults to 0 or isn't implemented so don't have to worry about it.

You could replace tdeint in the script above with any deinterlacer you like, just make sure it is keeping the correct field.

If I remember correctly yatta makes the field parameter selectable in the tfm configuration window. So just make sure it is set to the same value that TDeint is using in your script or vice versa.

[Egh]

Originally Posted by tritical

@Egh
Also note the micmatching=0, in the last version I made it default to 1, but it will need to be zero for this clip else it will use a u on the combed frames creating an extra duplicate. However, if you are using a version prior to v0.9.11.0 it defaults to 0 or isn't implemented so don't have to worry about it.

You see, I used TFM version prior to 0.9.11.0 and i got those duplicates. So how to make sure in yatta that those duplicates would NOT appear? Should I always use micmatching=0 in ymc on precalculating metrics? Does disabling micmatching provide worse results? BTW, it could be possible that micmatching was on by default in *ymc* while importing that project.

Also, since I use yatta, TFM is not used in script at all. Only TDeint used (and FieldHints, of course). And really strange thing is that only TDeint was producing duplicates. So if you change TDeint into something else in the following script, duplicates are not produced [e.g. FieldDeinterlace(blend=true, dthreshold=0), which was eventually used in Ichigo project, see manhole-fansubs release of it]

the script:

dgdecode_Mpeg2Source("G:\1\shan\shana.d2v")
YattaPreMatchClip = last
FieldHint(ovr="G:\1\shan\shana.d2v.fh.txt")
TDeint(clip2=YattaPreMatchClip,hints=true,order=1,type=3,sharp=false)

It's different project though, since it's my current one and I use 9.11 TFM metrics in it.

[tritical]

Alright, I went ahead and downloaded the latest ymc/yatta and know what is happening.

You see, I used TFM version prior to 0.9.11.0 and i got those duplicates.

Yeah... but you got them because TDeint wasn't keeping the same field as was being matched from, not because of micmatching.

Should I always use micmatching=0 in ymc on precalculating metrics? Does disabling micmatching provide worse results? BTW, it could be possible that micmatching was on by default in *ymc* while importing that project.

The latest version of ymc has micmatching options 0 and 2 and not 1 because yatta doesn't support tfm's u/b matches. Setting micmatching to 2 wont change anything in your clip because 2 can only change the matches to matches that could be used within the current matching mode. Using micmatching should improve things vs not using it, but micmatching=2 wont usually do much at all especially if the matching mode is limited to 0, 1, 2, or 4. All versions of tfm prior to v0.9.11.0, which you said you used one, either didn't have micmatching at all or it defaulted to 0 so there is nothing to worry about. Obviously, older ymc/yatta versions that don't set the micmatching parameter wont work with v0.9.11.0+ of tivtc because micmatching defaults to 1.

Also, since I use yatta, TFM is not used in script at all. Only TDeint used (and FieldHints, of course). And really strange thing is that only TDeint was producing duplicates. So if you change TDeint into something else in the following script, duplicates are not produced [e.g. FieldDeinterlace(blend=true, dthreshold=0), which was eventually used in Ichigo project, see manhole-fansubs release of it]

The problem is the mismatch between what field tfm is matching from and what field TDeint is keeping. After looking into fieldhint, and remembering one of the TDeint's workarounds, I know the reason. It is because fieldhint uses the same hinting as decomb... when TDeint sees decomb hints and field is set to -1 (Auto), instead of setting field equal to order, TDeint sets field to 0 because decomb matches off the bottom field. Seeing those hints, TDeint thinks telecide came before it and that it should keep the bottom field. However, fieldhint assembles the matches according to how tfm matches the frames (assuming you used tfm in ymc)... and what field tfm matches from depends on how "field" is set in ymc. If field is set to "Auto" (-1) then it will use the same value as order... BFF=0 TFF=1.

So, what you need to do is in the TDeint() line of your script, add "field=1" w/o the quotes if your tfm configuration in ymc matches any of the following:

1.) order = TFF and field = AUTO
2.) order = TFF and field = 1
3.) order = BFF and field = 1

I am guessing you had field = AUTO in ymc, so if you set "field=1" in the TDeint line of your script the duplicates should go away.