TDeint and TIVTC

[manono]

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.

[manono]

Been testing:

+ Added trimIn parameter (trim before tfm w/ d2v support)

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!" This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)

[Leak]

Originally Posted by manono

I also reworded that error message slightly in case someone somehow gets it again

"manono is a dumbass" maybe?

Darn, now I'll have to try and break it to see what the message is. Thanks for the fast update.

Or you could just cheat and look at the source files... not that I would do or encourage it, of course...

[TheBashar]

Originally Posted by manono

However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

Isn't this exactly what the trimIn parameter is for?

[tritical]

I could actually encode with the previous version, but it didn't honor the Trim, as I found out much to my chagrin. However, using the new version, this doesn't open in VDubMod:

Trim(450,0)
TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
TDecimate(mode=0)

The message is, "D2V frame count doesn't match filter frame count!"

Previous to this version tfm didn't require that the number of frames it had info for from the d2v file actually matched the input frame count. Instead, it simply used the first frame count number of entries (if the d2v had more) or it used nothing for the extras (if the d2v had less). That wasn't a very good solution, but it did stop tfm from crashing when filling the d2v info array if the d2v had more info. With the addition of the trimIn parameter I decided to require that the frame info from the d2v file match the input frame count (that is where the new error msg comes from). The whole reason that the trim before requires special support is that tfm has no way to determine if a trim statement actually came before it or not.

This does open and encodes properly:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0)
Trim(450,0)
TDecimate(mode=0)

Trimming after tfm is a viable option, the only thing it messes up is that when TDecimate gathers the hint information from tfm it assumes that the incoming frames are in the same order as when they came out of tfm. For example, to determine duplicates via matches tdecimate looks at the frame matches delievered by tfm. It uses that info to see if the same field has been used in two frames in a row... i.e. if the current frame match is 'p' and the previous match was 'c' (and neither match was marked as combed and deinterlaced) then there was a repeated field. If you use trim() before tdecimate then those assumptions are no longer correct for the first frame after the cut position. TDecimate also considers rff duplicate info that is passed by tfm, and that information would also be incorrect for the first frame following a cut. Currently there is no way to disable tfm's hinting or to force tdecimate not to use the information if it sees that it is present.

Changing your script to use trimIn would work like this:

TFM(d2v="K:\Samurai Rebellion\4-1 Movie\Movie.d2v",PP=0,trimIn="trim.txt")
TDecimate(mode=0)

with trim.txt containing the following line:

0,449

Here 0,449 is marking the frames that were cut out (inclusive).

[manono]

Yep, manono is a dumbass. Thanks for the heads up, TheBashar, and for the detailed explanation, tritical.

[tritical]

Unfortunately, school and other things have set me back on getting TDeint2 completed, as well as getting TIVTC and TDeint released (but they will be out eventually). I have had a little bit of time to do some low level optimizing of TIVTC, which I have been putting off. Here is the first take which focuses on tdecimate... [link removed], changes:

TDecimate:

   + optimized c metric calculation routine (~2.5-3x faster)
   + removed width restrictions on isse yuy2 scenechange detection routine
   + added mmx yuy2 scenechange detection routine
   + removed all pitch and width restrictions on isse sad/ssd block metric
         calculation routines
   + added mmx sad routines
   + require mmx and not isse for the assembly ssd routines because they use
         only mmx instructions
   + removed width restrictions on mmx denoise routines
   - fixed possible divide by zero crash with vidDetect = 4

Next, I'm going to spend a little time on optimizing tfm and porting the above tdecimate changes into framediff/framediffc.

[MacAddict]

Originally Posted by tritical

I guess it is not that clear in the documentation, but for mode 5 it needs all the stats so it can calculate everything at the beginning, which means two passes need to be made. In the first pass use/run this script:

mpeg2source("c:\sg1614.d2v",cpu=4,idct=7,ipp=true)
assumetff()
converttoyv12(true) <= is your source 4:2:2?
clp = last.rgbob().selecteven()
tfm(pp=4,clip2=clp,output="matches.txt")
tdecimate(mode=4,output="metrics.txt")
crop() <= change this to crop the image down to 32x32 or 16x16 to speed things up

That pass is only to allow tfm/tdecimate to gather the needed info (i.e. create the output files), so the actual video output of that pass doesn't matter.

Just to clarify, I could essentially turn off all extra video codec options I'd typically have on for this first pass right? For example I'll disabe Qpel, VHQ, Motion Search, B-Frames and even set a constant quant of 31 within XviD. I'm assuming that would be correct

Edit- Thanks again for your effort on this project, greatly appreciated.

[tritical]

Yep, that would work. For the first pass when tivtc gathers info, literally anything that requests all the frames of the script will work... a getall() (from avstimer) at the end of the script, using preview in vdub, etc... whatever runs fastest for you. I usually just open the script (which after crop outputs 16x16 or 32x32 res) in vdub, select fast recompress with huffyuv as the codec (though at that size which codec you use doesn't make much difference), and then save as avi. That way is very fast and you can select the process priority.

[DarkNite]

I'm always happy about faster metrics calculation.

The funny thing is this news actually made my day several degrees better than it was. For a moment there I was about one spreadsheet or phone call away from DEFCON 4. This was just enough good news to lift myself out of a rut.

I'd hand you a beer if I could.

[foxyshadis]

Originally Posted by tritical

That way is very fast and you can select the process priority.

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.

[MacAddict]

Originally Posted by foxyshadis

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.

Hmmm I'm not having any success using Vdub 1.6.11 doing 'run video analysis pass' feature. The analysis runs fine without error but then I go to run the 2nd pass and immediately get an error: Input Error(mode 5 & 6, all frames must have entries).

mpeg2source("D:\ep17.d2v")
assumetff()
#
#First pass VFR
#tfm(d2v="D:\ep17.d2v",order=1,output="matches.txt")
#tdecimate(mode=4,output="metrics.txt")
#crop(344,224,-344,-224)
#
#second pass VFR
tfm(d2v="D:\ep17.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=0,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")

Any ideas or am I just missing something obvious?

[tritical]

@DarkNite
Thanks, and I would definitely take the beer if I could .

@foxyshadis
Didn't even know about or ever notice that function, will definitely have to try it out.

@MacAddict
Gonna try out the 'run video analysis pass' function now, will report if it works for me or not.

EDIT: It worked fine for me. I don't see anything wrong in your scripts... does it work correctly if you actually use "save as avi"? If so, could you create the output files once using that method and then again using the "run video analysis pass" method and see how they differ?

[MacAddict]

@tritical
You read my mind. VdubMod 1.5.10 b2540 works flawlessly of course as we normally use it with different passes. Vdub 1.6.11 does work fine with the same script using "save as AVI" but unfortunately I'm in the middle of a 11 hour TDeint bob encode and can't do an analysis on the matchcode files. I'll try and reproduce the problem on another PC tomorrow and post my findings to see if a difference does exist between the two methods. Thanks for trying it out.

@foxyshadis
Thanks for the 1st pass tip in Vdub. Too bad VdubMod isn't being developed and including that feature, I prefer it for the extra functionality and configuration.

[ChronoCross]

Originally Posted by foxyshadis

Virtualdub actually has a 'run video analysis pass' which is pretty much the same as what you do, without having to select a codec or save file. No big difference, just thought you might like to know. It gave me a bit of trouble in 1.6.10, but not since 1.6.11.

Additionally you can just hit the play button, that works well. Just diable previews. but a reminder to all who use this method you have to remember to close out of the avs when you finish the pass. any additionaly frame jumping will also be recorded into the metrics file which is bad.

[MacAddict]

I'm not able to reproduce the the issue I mentioned above, even using the same files/episodes and scripts on the same PC. I tested 2 other PCs and it appears to work fine. Only difference I can think of now is that I rebooted this PC. If all else fails reboot! Sorry for the waste of time tritical.

@ChronoCross
I noticed the same thing early on. It appears the text files aren't created until Vdub/VdubMod is closed. Good tip.

@all
I'm just starting to get my head wrapped around TFM/Tdeint finally and understanding the basic parameters for my material. Does anyone have examples thats worked well for them on standards converted movies where Restore24 and Cpackage has failed? I currently have some NTSC->PAL and vice versa film material thats driving me insane due to it not being smooth. Mode=7 helps in some cases on the blended fields but I'm still seeing some jerkiness on occassion. Combed isn't a problem at all so would it be safe for me to use PP=0 in order to prevent jerkiness?

[scharfis_brain]

tritical: is the a pre-build of TDEint2 somewhere to play with?

[tritical]

I'll try to put one up in the next few days. Currently, the motion stuff is in one program and the interpolation is in another... I just haven't had the time to merge it all and get everything working together.

I am gonna go ahead and release a standalone edge directed interpolation filter that resizes by 2x in the vertical direction using my new ela method. TIVTC has the clip2 option so it could make use of it already, and it would be very simple to add a clip2 type option to TDeint as well (and that is a feature I think it should really have).

[tritical]

Here's [link removed]... it resizes by 2x in the vertical direction by copying the current image to every other line in the resized image and then interpolating the missing field. Basically, it works the same way as "elaresize" which was a filter I posted on neuron2's forum some time ago. This filter is my latest edge-directed interpolation for deinterlacing attempt. The goals have been to preserve the filter's ability to connect edges and operate without the need for value capping (a sanity threshold), while at the same time eliminating the typical artifacts that usually produces. In order to do that it uses a two step process so that it can force spatial consistency and coherency of the direction map... in other words it is SLOW . While not as perfect as I would like it to be, it is, under most conditions, more stable then TDeint's type=3 or type=1 methods and does a much better job.

Anyways, here is a sample... I took this image from a thread on the virtualdub forums where it was posted by neuron2. In each case one field from the original image has been discarded, and the remaining field has been used to construct a new frame:

original:


avisynth's bob:


tdeint_type=1:


tdeint_type=3:


eedi2:


In this example EEDI2 easily beats both type=1 and type=3 of TDeint. The lines are too dark and small for type=1 to allow them to be connected (it's sanity threshold kicks in), and it drops back to cubic interpolation. Type=3 does a better job since it doesn't work by selecting one candidate and then testing it against the sanity threshold, but tests all other possible candidates as well. However, it still can't actually connect the lines due to the sanity threshold.

To build a dumb deinterlacer out of EEDI2 you can use the following:

1.) tff, keep top field:

separatefields().selecteven().EEDI2(field=1)

2.) tff, keep bottom field

separatefields().selectodd().EEDI2(field=0)

3.) bff, keep bottom field

separatefields().selecteven().EEDI2(field=0)

4.) bff, keep top field

separatefields().selectodd().EEDI2(field=1)

or to make a bobber:

1.) tff

separatefields().EEDI2(field=3)

2.) bff

separatefields().EEDI2(field=2)

In this manner it is possible to use EEDI2 in combination with TIVTC via TIVTC's clip2 parameter. For the moment it isn't possible to use EEDI2 with TDeint... but hopefully there will be a way to use it in conjunction with a motion-adaptive or motion-compensated deinterlacer sometime soon. Needless to say this filter was developed testing exclusively on anime and the sample image posted above... how well it works on real life images is still a mystery .

[Mug Funky]

that's really impressive! it's finding diagonals that i didn't think it was possible to find with any reasonable speed.

crossing objects appear to artefact in a similar way to sangnom though... try an "x" shape that crosses at an angle of about 30 degrees and you'll probably see them.

i'm only using defaults at the moment though.

[edit]

it also makes a very good comb mask