TDeint and TIVTC

[Fizick]

tritical,
thanks for update!

May be somebody can help you with html doc,
in order to you concentrate on programming?

[aichan]

@tritical

oh..okay.. i see now about it.

i'll try to mux it to mkv later..

thx

[DarkNite]

@malouf

Some things you could try are the functions mentioned previously in this thread using eedi2 in cunjunction with tdeint.

If all else fails: I use FreezeFrame for issues where I know the frames that are consistently giving me problems (or rather giving the automated solution problems). Then again, I'm used to using YATTA and most people just aren't that masochistic. FreezeFrame would be used best after deinterlacing and before anything else.

In bad game captures I would use it before the motion blur to replace the usual junk frames here and there with the previous or next frame. If it's a duplicate frame or static scene no one will ever know, but if it's a hard panning sequence it may introduce a stutter.

[malouf]

Hi,

I tried the method with eedi2 and tdeint, it produces the same artifacts at the same place...

And for freezeframe, the problem is that I need to have something that works automatically on every video, I make lots of videos, and don't want to review them frame by frame to correct them :-(

The ideal solution would be that tdeint, before deinterlacing, checks if the current interlaced frame is perfectly identical to the previous one. If it is identical, just output again the last progressive frame. I guess it wouldn't be difficult, but maybe I'm mistaken ?

I can post a small part of one of the videos that has the problem, maybe it would be more clear?

[johnmeyer]

[See last line of post, if you don't have time to read all this].

I am getting occasional failures in the TFM v0.9.12.1 matching. I have tried every mode, each option for slow, and each option for micmatching. What happens is that the MICS parameters show, for example

p=0, c=5, n=25, b=4, u=0

yet TFM chooses the current rather than the previous field. 99.9% of the matches are correct. Here is the script:

converttoYUY2(interlaced=false)
AssumeBFF()
colorYUV(autogain=true)
tfm(display=true,micout=2,mode=7,cthresh=115,mi=35,pp=1,field=0,metric=0,micmatching=3,slow=1,sco=-1,debug=false)

and here are two frames that are at the same point in the cadence. The first one shows TFM not doing what I want it to do; the second shows what I think is the correct operation:

[1568] TFM:  mode 7 - non-linear access detected!
[1568] TFM:  frame 10693  - comparing c to p  (SLOW 1)
[1568] TFM:  frame 10693  - nmatches:  547252 vs 827794 (1.5)  mmatches:  106221 vs 128984 (1.2)
[1568] TFM:  frame 10693  - match c:  Detected As NOT Combed! (6 <= 35)
[1568] TFM:  frame 10693  - match p:  Detected As NOT Combed! (0 <= 35)
[1568] TFM:  frame 10693  - final match = c  MIC = 6
[1568] TFM:  frame 10693  - mics: p = 0  c = 6  n = 256  b = 256  u = 0
[1568] TFM:  frame 10693  - mode = 7  field = 0  order = 0  d2vfilm = F
[1568] TFM:  frame 10693  - CLEAN FRAME


[1568] TFM:  mode 7 - non-linear access detected!
[1568] TFM:  frame 10704  - comparing c to p  (SLOW 1)
[1568] TFM:  frame 10704  - nmatches:  1186349 vs 1009180 (1.2)  mmatches:  583070 vs 500389 (1.2)
[1568] TFM:  frame 10704  - match c:  Detected As NOT Combed! (10 <= 35)
[1568] TFM:  frame 10704  - match p:  Detected As NOT Combed! (5 <= 35)
[1568] TFM:  frame 10704  - final match = p  MIC = 5
[1568] TFM:  frame 10704  - mics: p = 5  c = 10  n = 256  b = 256  u = 0
[1568] TFM:  frame 10704  - mode = 7  field = 0  order = 0  d2vfilm = F
[1568] TFM:  frame 10704  - CLEAN FRAME

As you can see, in the first case (frame 10693), p=0 and c=6, yet TFM chooses c. In the second case c=10 and p=5, and it correctly chooses p.

...

I just took a break before posting and looked some more. I think that any time either c=0 or p=0, TFM makes the wrong choice. It is as simple as that. Let me know if this is correct.

[Edit] Update a few minutes later. My input is NTSC DV (BFF). However, I tried changing field to field=1, and it seems to work better. So, field=0 and also field=-1 preceded by AssumBFF() both create the problem.

[tritical]

@malouf
The problem is that tdeint's motion check is only 5 fields, 2.5 frames, so if an interlaced frame is repeated one time the chance that interlaced areas will be declared static and weaved is high. If such a frame is repeated twice then it will definately be declared static. Having tdeint check for absolutely identical frames and consider all pixels to be moving would prevent the artifacts, but definitely wouldn't be good for normal operation. You could try using securedeint() which produces longer temporal masks (which should prevent the problem)... or you might be able to hack up a function in avisynth that checks difference to previous frame and if it is zero replaces the frame will all white (255), which should make it be detected as moving.

@Fizick
If someone wanted to help on the docs I definitely wouldn't say no . So far I have manged to convert most of the stuff for tivtc except for the two biggest readmes (tfm/tdecimate).

@johnmeyer
Would you be able to post a clip that I could test with? Your settings seem strange off hand... specifically mode 7 and cthresh=115. Also, the MIC values aren't normally used for selecting matches, but only for determining which frames are combed. The nmatch/mmatch numbers generated by the field matching routine are what determine which match is chosen (lower is better). With micmatching enabled the MIC's can override the match decision, but the 0 vs 6 difference in the first example isn't large enough to trigger it (with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).

@All
I found another little bug in eedi2 that could occasionally cause an access violation by reading/writing 8 bytes past the end of a buffer. The affected routine is only used if the input is yuy2 and the cpu supports sse2. I'll try to put up a fix sometime soon.

[johnmeyer]

Would you be able to post a clip that I could test with?

Here is a link (good for seven days) to a short DV AVI clip, along with the script I am currently using:

http://download.yousendit.com/16F3395A7B1B6689

Frame 9 is where the problem occurs. If you change the Field parameter from 0 (which is where I think it should be for NTSC DV) to 1, TFM works.

Your settings seem strange off hand... specifically mode 7 and cthresh=115.

Yes, I have changed those. If you look at the script in the above download, the TFM line that is commented out that is directly above the one that I made active just for your testing, is the one I'm actually using now. The reasons for the strange settings is that this is the script for recovering matched fields from my film to video transfer device (see my earlier posts). With this device, I will get two good fields for every frame of film. The next field will either be a field captured during pulldown, or will be a third matching field. If it is a field captured during pulldown, the resulting frame will appear combed. I throw that out.

(with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).

Would it be better to use blockx/y = 4?

I actually made a test DVD last night, and I almost have this working. I export the TFM parameters in pass one, import it to Excel, and use Excel formulas to look at the TFM values to create a decimate file. In pass 2, I feed that file to Multidecimate, and feed the almost-unaltered (after removing the CRC line -- thanks for that hint) pass-1 TFM parameters file back into TFM.

In the second pass, I remove the "colorYUV(autogain=true)" line.

Speaking of autogain, for anyone reading this thread, I found -- at least in my application -- that using autogain makes a HUGE improvement in the consistency of TFM's matching. Many of the movies I am transferring consist of poorly exposed, low contrast footage, and as the exposure and contrast changes, so do the TFM matching parameters. Using Autogain equalizes things sufficiently that I can use one script for the entire reel of film.

In fact, the improvement is so good that I suggest that if there is a way to feed an autogain version of a clip to one instance of TFM, and then have the resulting parameters be used by a second instance of TFM to actually operate on the clip it might be a very worthwhile addition. This way it wouldn't require two passes (although my application will still require a second pass because I don't have a predictable "n of m" decimation pattern).

In summary, now that I understand that MICmatching requires a bigger difference, I can try to deal with that, so I guess you don't need to look into that any further. However, I still think that there is something strange going on with the Field= parameter. I get all sorts of combing artifacts with Field=0, and none with Field=1, even though I am using a DV source.

Finally, I have read your documentation 100 times, and read through every post in this thread, but I can't find the answer to this:

What does "MIC" stand for?

[HOLiC]

Hello, I'm trying to encode hyrid video to mkv-vfr using megui as an encoder, and Tivtc filter. But I'm having a problem using one pass method as you can check in this post:
http://forum.doom9.org/showthread.ph...055#post814055

I don't know the reason for this error message in megui, but using two pass method, i was able to open the script via megui!!

in your read me:

7.) NTSC, two pass (enables use of conCycleTP parameter) mkv vfr for hybrid source.

First pass:

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",output="matches.txt")
tdecimate(mode=4,output="metrics.txt")

Second pass (anime or cartoon):

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=1,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")

I understand that I have to play the first pass to get the metrics, and then encode using second pass script.. What I don't know is.. is it okey if my output file is mp4? (but I plan to mux with aac, and timecode to MKV using mkvmerge) Or do I need to make output file to mkv right away? And I also plan to do 2pass encoding, and I read in the avisynth site, that vfr encoding will mess up the bitrate calculation..? Is this still apply?


from: http://www.avisynth.org/VariableFrameRateVideo

If you're encoding to a specific size using a bitrate calculator, vfr decimation will mess up the calculations. To make them work again add these to your script:

Before decimation:

oldcount=framecount # this line must be before decimation
End of script:

oldfps=framerate
averagefps=(float(framecount)/float(oldcount))*oldfps
assumefps(averagefps).Nicefps()

Do I have to apply above script if i want to do 2pass mkv-vfr encoding? but I tried nicefps(), and it just gives me an error message. Any feedback would be great! Thanks!!

[foxyshadis]

You don't need nicefps (which is a separate plugin, see warpenterprises) starting with Avisynth 2.5.7 alpha. All that part does is extend the length of your newly decimated video to be exactly as long as your old video, so that all bitrate calcs are kept in sync, so yes, unless you want to do the algebra yourself every time (or use a quality-based encode), you do need that, whether 1 or 2 pass.

You can output mp4, but you still have to mux to mkv. But see the updated version of the guide for a few more options if you want to end up in mp4.

1-pass vfr can't be seeked into, and megui always seeks to the middle frame if you open the preview, so set it to not open the preview and you should be okay. Another problem is you can't really correct the bitrate skew in 1-pass mode, so you might have to go quality-based for that.

[foxyshadis]

I'm just kind of curious, but what sort of improvements are in store for eedi? Anything I should wait around on, or just minor speed/quality tweaks? (I've been using it a lot lately on some too-small stuff, helps a lot.)

[HOLiC]

You save me again, foxyshadis!!

[Fizick]

tritical,
again about html doc.

Do you know, that avisynth 2.56 includes Tdeind and TIVTC html doc ?
(outdated a little, of course, but formatted).

[swaaye]

I'm getting an error with TFM "Illegal Transitions found in dvd2avi file". It makes me a "fixed" file that still gives the error. 2 out of about 15 episodes have this issue, using identical settings.

edit: I think the fixed file is working after all.

[tritical]

First, sorry for the lack of responses... I've got a big project due in two weeks and I'm having to spend insane amounts of time on it.

@swaaye
It appears your problem was fixed? If you do have a d2v file that tfm generates a fixed version of and then says something is wrong with the fixed version could you post it somewhere?

@Fizick
Yep, I know that tdeint/tivtc html docs already exist.. I've been using those as the basis for the new ones (updating, rewriting, and layout changes).

@foxyshadis
The main changes are to making it more stable with larger search areas (new default for maxd will be 24) and better at connecting lines with very small slopes. I've changed some hard thresholds to relative thresholds based on the angle direction and added an extra gap/hole filling routine to the edge map filtering and directon map filtering. Due to the new defaults and extra processing it is a little bit slower.

@johnmeyer
I'll try to look at the clip tommorrow though it sounds like you've found a method to accomplish what you need. The problems you have with the field parameter may be related to using mode 7 in tfm. In mode 7 tfm internally switches the field parameter between 0/1 (it starts out on the initially set value) based on combed frame detections to try and follow a specific pattern found in some field blended material. In almost all other cases you want to always match of the same field to maintain smoothness. Try using matching mode 0 or 1 and setting field=0 and then field=1.

I guess MIC stands for "max (or maximum) interlacing count". Originally, tfm never kept track of the "MIC" value it just checked to see if any of the blocks in the image produced counts over MI. When I decided to start keeping track of the values I just added C onto MI to get MIC for a new variable name.

[johnmeyer]

I gave up on mode 7 shortly after my post and have been using mode 0. Still haven't been able to get reliable detection in low motion areas. However, I am now trying to create my own decimation routine that uses a form of guidance that is based on my unusual application. I'll post back here when I've either got it working, or have another question.

[Alizar]

Tritical:

I'm sorry to bother you, but I've noticed a weird output bug with tdecimate. Sometimes it simply refuses to write out the stats using mode=4 and specifying an output file. I run the pass to collect the stats, the file is created, but it stays blank. Any notion what I might be doing wrong?

[foxyshadis]

The file won't be flushed until virtualdub (or whatever is running the pass) is closed. Closing the video with ctrl-W and reopening off the recent menu is what I always do. Must have the biggest buffer in the world or something...

[JuanC]

TDecimate request: exclusion band of lines (y0/y1) as in TFM.
Hi Tritical, This is a humble request: I regularly do NTSC analog TV captures that are telecined material broadcasted with the original audio and the subtitles (interlaced!) with the translation blended on top of the telecined material. The exclusion band of lines (y0/y1) for TFM has allowed me to successfully match the fields correctly. This is great! But the subtitles are still causing me problems with TDecimate:

After using TFM, the telecined material is correctly matched, but almost every frame where each subtitle starts or ends (only the first and last frames where the subtitle appears) is detected as combed because of the subtitles. These “combed” frames (2 on each subtitle, with 2000+ subs gives more than 4000! on a 20 minutes capture) interfere with TDecimate metrics calculation resulting in the wrong frames being deleted, and if hybrid > 0 with unnecessary 30p to 24p frame blending processing.

I have also tried setting PP=0 and hints=false, but the metrics calculation on TDecimate gets confused by the subtitles, particularly if the subtitles starts or ends exactly on a duplicated frame (the ones that should be decimated).

Last night I discovered “MergeHints” on your TIVTC package, which allowed me to get better results by excluding from the TFM hints generation the lines where the subtitles are, using this AVIsynth script: (704x480 yv12 material)

Save_Hints=crop(128,64,480,288,align=true).Tfm(order=1, mode=0, PP=0)
Tfm(order=1, mode=0, y0=352, y1=448, PP=6, Hint=FALSE, opt=3) #, display=true)
MergeHints(hintClip=Save_Hints)
TDecimate(Hint=true, opt=3, hybrid=0) #, display=true)

One could of course get these or better results, easier and a lot faster, if there was an option in TDecimate to exclude lines that contain the subtitles when doing the metrics calculation, just like it is in TFM.

I hope you’re doing well with your project, and I’d like to thank you for the time and energy you devote to this filters you give us all.

Regards, JuanC

[minos5000]

I've a question concerning the speed. I use these settings for VDub to convert my captured movies into Xvid

LoadPlugin("c:\avisynth\dgmpgdec146b2\DGDecode.dll")

audio=MPASource("c:\Charmed.-.S03E04 T01 DELAY 96ms.mpa")

video=MPEG2Source("c:\Charmed.-.S03E04.d2v")

video=TDeint(video,order=1).lanczos4resize(720,540)

AudioDub(video,audio)

The quality is really great but I'm not so happy with the perfomance as it dropped by 50% from 30fps to about 16fps. Ist this loss normal or are there any improvements possible?


so long

[scharfis_brain]

every filter has an impact on encoding speed.
so will tdeint.

and 16fps still are a reasonable good speed.

So it seems you never got into the range of spf for your encoding speeds (spf == seconds per Frame)