TDeint and TIVTC

[tritical]

You know it's funny, Ive only ever been able to find one other written account (admittedly a while ago) of somoene using vector matching instead of pel matching with an ELA type approach ... and that was in medical imaging to reconstruct dropped scanlines.
I'm not sure if my use of vector here is what you are referring to or not. By vector I just mean that instead of doing:

abcdefghi
o
jklmnopqr

diff = abs(h-k)
to test the +3 direction you do:
abcdefghi
o
jklmnopqr

diff = abs(j-g)+abs(k-h)+abs(l-i)

Or you can use 5, 7, 9, etc... pixels. Of the papers I read only one was using that method. However, that paper was still only using two vectors (one 1 line above and one 1 line below) and sliding them in the standard x+x tap ela style. One of the other papers was using single pel differences but kept points anchored above and below and added 2 extra taps (one 2 lines above and one 2 lines below) so that you then have 2 stationary points and 4 moving points. That helps quite a bit in preventing the line crossover tendency. My method just combines the vectors with the anchor idea and extended it to include additional anchors another scanline above and below the current anchors. So in total there are 10 vectors... 4 stationary (bolded below) and 6 moving.


abcdefghi

jklmnopqr
o
stuvwxyzA

BCDEFGHIJ

Of course, that alone still isn't accurate enough to be used without a sanity threshold. The processing/filtering of the resulting direction map helps eliminate most of the incorrect directions but is far from perfect.


I have a question about TDecimate modes 0 and 1. Do they both support random access, or do either of them expect the frames to come in a linear order?
Assuming that information from tfm (match info, d2v info, etc...) is not present in the stream:

mode 1 does not support random access. mode 0 does support random access.

Assuming information from tfm is present:

Currently, neither mode truely (i.e. 100% reliably) supports random access. Though once the next version of tivtc is out (so that tdecimate allows using a tfmIn file when hybrid=0) it will be supported in mode 0 by using:

tdecimate(input="metrics.txt",tfmIn="matches.txt")

Mode 1 can never 100% support random access since its decision's on the current cycle can be effected by what frame was dropped from the previous cycle.

Next version will also have an option to stop tfm from putting any information into the stream which is not possible atm (it will always put at least the match used and combed/not combed), and an option in tdecimate to ignore the extra information and go purely on metrics (also not possible atm). Unfortunately, I haven't had the time to work on avisynth stuff lately... should change soon.

[tritical]

I sat down last night and did some work on tivtc... I gave up on the having a separate 1.1 branch and only doing bug fixes to 1.0 because I'm too lazy to maintain both. So there might be quite a few more release candidates before a final 1.0. Current working changes:

- fixed cthresh < 0 problems (was broken for both assembly and c routines)
- allow tfmIn file when hybrid=0 in tdecimate
- if the field order of a d2v file does not match the user specified order an error is thrown
- noblend defaults to true
- added new spatial comb metric to tfm and is/showcombedtivtc (from decomb's iscombed/fielddeinterlace)
- added hint option to tfm to disable putting hints in the stream
- added hint option to tdecimate to disable reading of hint information
- replace all frame copying with env->makewritable() where possible
- seeking is fully supported for both modes 0/1 of tdecimate when a metrics input file and a tfmIn file (if hints=true) are used
- added clip2 option to tdecimate (metrics are calculated off the input clip but frames are returned from clip2, all modes supported)
- added hclip option to tdecimate (hybrid=1/3 take frames from hclip instead of doing blend conversion, modes 0/1)
- added RequestLinear filter (makes sure all requests for frames are linear and that all frames are requested)

There is one problem though, the hclip option works perfectly well for hybrid=1 by doing:

mpeg2source()
tfm()
mc = last.mcconvertfps()
tdecimate(hybrid=1,hclip=mc)

However, it is not possible to handle hybrid=3 in the same manner since the clip fed to the mc filter would first need to have the duplicates removed. That causes another problem because the resulting clip (w/ dups removed in film sections) after being fps converted would not have a constant relation to the frames in the input clip. Atm, it looks like for hybrid=3 it will take two passes and the following second pass setup:

mpeg2source()
tfm()
mc = last.tecimate(input="",tfmIn="",mode=8).mcconvertfps()
tdecimate(input="",tfmIn="",hybrid=3,hclip=mc)

where mode=8 would be a special mode for the purpose of dropping the correct frames. If anyone has any other ideas I'm all ears.

[tritical]

[link removed], changes:
+ Added mode 2, and blim parameter

After talking to Zarxrax, I decided to add a same frame rate mode to tdeint that is similar to Blendbob(). How it works is it bobs the input stream like normal mode=1. When asked to deliver frame n it grabs frames n*2-1, n*2, and n*2+1 from the bobbed stream (could be n*2, n*2+1, n*2+2 if field != order). It then differences the middle frame with the previous and next frames. If both differences are over the blim value then it delivers the source frame as is, otherwise it blends the source frame with the frame that produced the smallest difference and returns that frame.

The difference to blendbob is that it will never try to deliver a p/n blend (which is what makes blendbob not support seeking since the decision to blend p/n is based on previous differences) and that it has the max difference value at which point it will not blend the source frame with prev or next.

The main reason for mode 2 is pping for ivtc. Namely:

deinted = tdeint(mode=2)
tfm(clip2=deinted)

mode 2 can work with tdeint's edeint option perfectly fine (the edeint clip has to be as though it is being used in mode=1), so something like:

interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp)
tfm(clip2=deinted)

is also possible.

[Mr. Brown]

@tritical
i wanted to test Tdeint(mode=2) but it crashed always (avisynth 2.5.6a)

setmemorymax(384)
### Plugins ###
LoadPlugin("C:\dgmpgdec146\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Tdeint.dll")

### Source ###
mpeg2source("C:\fliegen\flying.d2v")

crop(4,0,-12,-0)

tdeint(mode=2,order=1)

Here is the source
http://rapidshare.de/files/15891931/flying.m2v.html

[tritical]

What type of cpu do you have? Also, when it crashes is it a hard exit or does it give you an error message?

[Mr. Brown]

1. Athlon XP 3000+ (Barton) look at my signature for more information
2. hard exit

my OS is wxp sp2

[tritical]

[link removed], changes:
+ output MIC values in debug info when tryweave=true or full=false
+ added value 70 to emask input
+ added mmx versions of isse/sse2 compare/blend routines for mode=2
- refactored/rewrote a lot of the code to clean up and simply things,
no changes that effect output... should give a slight speed up

@Mr. Brown
Unfortunately, I wasn't able to reproduce your problem. Does it crash if you use tdeint(mode=1,order=1)? Could you also put debug=true in the tdeint() line and use debugview to capture whatever it outputs before crashing?

[berrinam]

tritical, I just wanted to say that I tried out using IsCombedTIVTC instead of IsCombed for my Source Detection, and it performed much better. MeGUI now uses IsCombedTIVTC for its comb detection.

Thank you.

[DarkNite]

I see what you're talking about Mr. Brown. I'm using RC4 in AviSynth 2.5.6a with DGIndex 1.4.6 and VirtualDub 1.6.14 on an AthlonXP 3200+, Windows XP SP2.

mpeg2source()
deinted = tdeint(mode=2,debug=true)
tfm(clip2=deinted)


Here's what DebugView has to say:

[964] TDeint: v1.0 RC4 (03/19/2006) by tritical
[964] TDeint: mode = 1 (bob - double rate)
[964] TDeint: frame 1066: accumP = 1464846 accumN = 10990531
[964] TDeint: frame 1066: field = interp top (0) order = tff (1)
[964] TDeint: frame 1066: mthreshL = 6 mthreshC = 6 type = 2
[964] TDeint: frame 1067: accumP = 11032302 accumN = 1905505
[964] TDeint: frame 1067: field = interp bottom (1) order = tff (1)
[964] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[964] TDeint: frame 1067: accumP = 1308674 accumN = 1368299
[964] TDeint: frame 1067: field = interp top (0) order = tff (1)
[964] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2


Does it crash if you use tdeint(mode=1,order=1)?

Not here, or at least not within the 40544 frames my test source consisted of.

[Mr. Brown]

I wasn't able to make debug file because vdub(mod) close directly after loading the skript

Does it crash if you use tdeint(mode=1,order=1)?
No it works fine

and i try this
deinted=tdeint(mode=1,order=1,debug=true)
tfm(order=1,clip2=deinted)
now it load the skript but it crash after starting the encoding an no debug file was made

[AVIL]

@Mr. Brown

Have you tried without crop?

setmemorymax(384)
### Plugins ###
LoadPlugin("C:\dgmpgdec146\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Tdeint.dll")

### Source ###
mpeg2source("C:\fliegen\flying.d2v")

crop(4,0,-12,-0)

tdeint(mode=2,order=1)

certain filters don't work well on cropped clips

[Mr. Brown]

@Avil
also without crop it crashed

[tritical]

The fact that you don't get any output at all with debug=true is very strange. The first message it outputs is at the beginning of the constructor right after error checking for valid parameters (taken from DarkNite's post):

"[964] TDeint: v1.0 RC4 (03/19/2006) by tritical
[964] TDeint: mode = 1 (bob - double rate)"

If you don't at least get that then it isn't even getting through the constructor.

I'll put up a build here in a bit with some debug output strings that should identify which routine it is crashing in. If you and DarkNite could run the scripts that cause crashes with that build and capture the debug output it would help a lot. I am guessing it is a problem with one of the asm routines in mode 2, but I've run them all on my comp without problems.

Debug Build: [link removed]

The extra messages will be output w/ or w/o debug=true.

[DarkNite]

Here's what DebugView has to say now:

[2844] Create_TDeinterlace
[2844] Creating TDeinterlace object
[2844] TDeint constructor
[2844] TDeint: v1.0 RC4 (03/19/2006) by tritical
[2844] TDeint: mode = 1 (bob - double rate)
[2844] TDeint constructor returning...
[2844] Creating TDHelper object
[2844] TDHelper constructor
[2844] TDHelper constructor exiting...
[2844] TDHelper getframe
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1066: accumP = 1464846 accumN = 10990531
[2844] TDeint: frame 1066: field = interp top (0) order = tff (1)
[2844] TDeint: frame 1066: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1067: accumP = 11032302 accumN = 1905505
[2844] TDeint: frame 1067: field = interp bottom (1) order = tff (1)
[2844] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDeint getframe
[2844] TDeint getframe yv12
[2844] TDeint: frame 1067: accumP = 1308674 accumN = 1368299
[2844] TDeint: frame 1067: field = interp top (0) order = tff (1)
[2844] TDeint: frame 1067: mthreshL = 6 mthreshC = 6 type = 2
[2844] TDHelper subtract frames
[2844] TDHelper subtract frames isse

@Mr. Brown

You can get DebugView here (http://www.sysinternals.com/Files/DebugViewNt.zip). Just start it up, load your script in VirtualDub, and hit the play input button. The magic will happen on it's own. ;)

[tritical]

Thanks, I found the problem... had paddq's in the isse routine when it is an sse2 instruction. Unfortunately, it looks like I made that same mistake in a few places in TIVTC, but it only effects fielddiff() and a few of tdecimate's yuy2 routines. I'll put up fixed versions tommorrow.

[DarkNite]

:thanks:

[Mr. Brown]

my debug

00000000 0.00000000 [3744] Create_TDeinterlace
00000001 0.01130898 [3744] Creating TDeinterlace object
00000002 0.01135899 [3744] TDeint constructor
00000003 0.01139055 [3744] TDeint: v1.0 RC4 (03/19/2006) by tritical
00000004 0.01141737 [3744] TDeint: mode = 1 (bob - double rate)
00000005 0.01143441 [3744] TDeint constructor returning...
00000006 0.01146179 [3744] Creating TDHelper object
00000007 0.01149476 [3744] TDHelper constructor
00000008 0.01152381 [3744] TDHelper constructor exiting...
00000009 0.42560494 [3744] TDHelper getframe
00000010 0.42565188 [3744] TDeint getframe
00000011 0.42567924 [3744] TDeint getframe yv12
00000012 0.43208677 [3744] TDeint: frame 0: accumP = 0 accumN = 0
00000013 0.53284848 [3744] TDeint: frame 0: field = interp bottom (1) order = tff (1)
00000014 0.53289932 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000015 0.53293365 [3744] TDeint getframe
00000016 0.53295994 [3744] TDeint getframe yv12
00000017 0.54167360 [3744] TDeint: frame 0: accumP = 0 accumN = 0
00000018 0.64207071 [3744] TDeint: frame 0: field = interp bottom (1) order = tff (1)
00000019 0.64211595 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000020 0.64214361 [3744] TDeint getframe
00000021 0.65502572 [3744] TDeint getframe yv12
00000022 0.76859599 [3744] TDeint: frame 0: accumP = 3386725 accumN = 4707391
00000023 0.77290606 [3744] TDeint: frame 0: field = interp top (0) order = tff (1)
00000024 0.77300441 [3744] TDeint: frame 0: mthreshL = 6 mthreshC = 6 type = 2
00000025 0.77540302 [3744] TDHelper subtract frames
00000026 0.80813426 [3744] TDHelper subtract frames isse

[tritical]

[link removed], only change was fixing the paddq problem.

[Mr. Brown]

@ tritical
now it works
thank you!

[tritical]

Glad it works :). Now time for the 4th release in four days... [link removed], changes:
+ optimized motion map and field comparison routines
+ added opt parameter
- fixed missing cache in mode 2

In my tests versus RC5, w/ default settings, I got the following speed increases:

mode 0 ~ 25-30%
mode 1 ~ 35-40%
mode 2 ~ 100%

For the amount of work it took I was hoping for a bit more, but it's still pretty good. The checkcombed routine could still be optimized (just need to bring over the code from tivtc), but I decided to put that off for another time. None of the changes effect output.

[DarkNite]

Nicely done! I would love to do more testing with this right away (there's a few sources I have that would love to meet mode 2), but Oblivion calls.

[Zarxrax]

Wow! Nice speedups!

A question on TIVTC:
Does using hybrid=1 or hybrid=3 with TDecimate affect random seeking in the file? Do the output files from either tfm or tdecimate store the metrics used to handle the hybrid stuff?

[hwti]

mode 1 ~ 35-40%
I gain 80% with mode 1 between RC4 and RC6.

But I wonder : does the opt parameter really work ?
opt=0 (C routines) is only 12% slower than opt=1, 2 or 3, which have the same speed.

My CPU is an opteron 144 (same as A64 SanDiego core) : MMX, SSE, SSE2, SSE3

[tritical]

@hwti
The opt parameter works, the reason there isn't much difference is because the routines that have simd versions just don't take up that much processing time overall. In mode 1, with default settings, there are only two routines that have simd versions, and there are only mmx/sse2 versions of those (I wouldn't expect much if any speed difference between them). Those two routines w/ c versions only take up about 10-15% of tdeint's total processing time.

Most of the speed gain in RC6 was from internal buffering of frame differences. Previously, the differencing/logic for motion mapping was all done at once in a single loop. Now, those operations are split up into separate functions which allows the differences to be buffered. This makes more of a difference for mode 1 then mode 0 since mode 1 processes each frame twice (just swap the value of field)... so the second time through on each frame it doesn't need to caculate any differences at all. For each new frame only a single frame needs to be diff'd and added to the buffer (same for mode 0). That makes more of a difference for mtnmode=1/3 which use 5 frames and test 2/4 field distances then for mtnmode=0/2 which only use 4 frames and test only 2 field distances.

@Zarxrax
Yep, the output files do include everything that is used for hybrid detection. Seeking with hybrid=1/3 and default settings will currently not work 100% even when using complete input files. Actually, it depends on what vidDetect is set too. If it is set to metrics only then seeking will work, but if it includes checking match/rff info from tfm then it will not. That will be fixed in the next release.

[tritical]

[link removed], changes:
TFM:
+ Added metric parameter and new spatial combing metric
+ Added hint parameter
- throw an error if the field order of a d2v does not match the user
specified field order
- replace frame copy with makewritable where possible
- fixed cthresh < 0 not working correctly

TDecimate:
+ Added clip2 parameter
+ Added hint parameter
+ Modes 0/1 fully support seeking when complete input/tfmIn files are
present (tfmIn file not required if hint=false)
- fixed a few mmx/isse routines containing paddq sse2 instruction
- replace frame copy with makewritable where possible
- fixed not allowing tfmIn file with hybrid=0
- changed noblend default to true

Other:
+ added new combing metric and metric parameter to is/showcombedtivtc
- fixed cthresh < 0 problem in is/showcombedtivtc
- fixed paddq in mmx functions in fielddiff()
+ added RequestLinear Filter

[berrinam]

Other:
+ added new combing metric and metric parameter to is/showcombedtivtcThe documentation doesn't say what the default value is -- I presume 0?

Roughly speaking, the number of combed pixels present in frames from an interlaced clip is directly proportional to the amount of motion. Based on that, the amount of combing that the combed frame detection routine looks for (controlled by MI, blockx, blocky) when tryWeave=true should be based on the amount of motion, and it should be requiring less combing as the amount of motion decreases.
Could this idea also be furthered through the use of motion masking?

Also, what is the reason for keeping TDeint separate from TIVTC? From what I've gathered, both can do field-matching and deinterlacing, just TDeint uses better deinterlacing and TFM uses better field-matching. Couldn't those different algorithms all be listed together so that there would be one TSourceFixer function, which could have a "ivtc" preset which focuses on field-matching and a "deint" preset which focuses on deinterlacing. I feel like I'm missing something...

[foxyshadis]

Cool! RequestLinear will make using certain functions with others a lot simpler, thanks! I haven't had any great ideas on how to use hclip better, short of psychic functions (maybe sse4 will come with that? :p). It's too bad, since the extra pain in the ass means people probably won't use it. On the other hand, conversion to 24p seems to be a lot more common than 30p.

[tritical]

@foxyshadis
The hybrid=3/hclip problem is the main reason hclip wasn't included. I've been thinking about just adding hybrid=1/hclip functionality since it is easy to do.

@berrinam
Yep, the default value is 0, forgot to put it in there. I'm not sure having metric 1 will be all that useful or not... the main reason I included it was so iscombedtivtc could be set to operate exactly as iscombed does, aside from the overlapping windows.

TIVTC and TDeint could be combined the way you mention. The main reason they aren't is just because I started them as separate filters. TFM may not have as good deinterlacing abilities as TDeint, but it can have access to them via the clip2 parameter. In fact, I prefer TFM having separate, faster functionality... tfm's pping could be made quite a bit faster using simd (it's the only part of tivtc that I haven't worked on optimizing), which I plan to do in the future. The main thing that isn't possible atm is TDeint having access to tfm's better field matching ability, but I could simply copy tfm's routines into tdeint. My plan for now is to make TDeint's field matching equal to slow=0 in tfm. The only change to make that happen is to have it difference at both a high/low motion level instead of just the low motion level. Obviously a big gain of combining the two would be not having to duplicate as much code.

[Fizick]

tritical,
Sorry, but why you afraid to release it as 1.0 without "RC99" ? :)
or 1.1.

"RC" is usually used for bug fixes only.

[tritical]

Any potential reasoning behind the version numbers was lost too long ago to remember, and I just like the way RC sounds I guess :p. Maybe I should downgrade it to v0.10.x.x for a while and just randomly increase the numbers (basically what I do now), since I don't plan to make a final v1.0 until there is nothing on the todo list. For some reason though, things keep getting added to it right when it's about to become empty.

[aichan]

tritical, i encoded dvd anime the castle of cagliostro and deinterlaced it with TIVTC RC1 2pass. but why the frame on 2nd pass is fewer than 1st pass (140k vs 180k) ?

i dont remember exactly but the script was :
mpeg2source("lupan.d2v")
tfm().tdecimate() # (i forgot the parameter, but i copy exactly just like '2 pass anime hybrid' example you include on the package)
crop()
fft3dfilter() #default parameter
limitedsharpen() #default paramater

the result of 2nd pass is the video length is shorter than the source.
source : 1 hour 40 minutes
result : 1 hour 22 minutes

what is wrong with my script?
sorry, but i'm really new in encoding with avisynth :)

[foxyshadis]

Second pass should always be less frames; for films it'll usually be near 1/5 less (unless it's really hybrid). But it shouldn't be shorter! Sounds like something else is setting the framerate wrong. You're muxing it with the timecode file after encoding, right?

[aichan]

no, the result file was not muxed yet. i encoded it using Megui (in x264 r477 package). encoded the first pass first, then the 2nd pass(result file). i encoded it in full length of the film so the output file was only 1 (video only).

i know 2nd pass frame is fewer cause x264 warned me that 2nd frame is fewer. i played the result and it has a shorter duration.

[foxyshadis]

Tritical, if you have time in the future, can you check on something for me? I get a lot of crashes using eedi2 on hi-res material ( > 500 lines or so, increasingly common the higher it goes, but sometimes it even works just fine on 2000 lines, eg, 1500x2000 images) in both yv12 and yuy2. They're not hard crashes, but Avisynth System Exception - Access Violations. I can provide samples where it consistently fails on almost every open (it usually works the first time, but not after), and if I dig around maybe less common ones. Trying it with a few large pics with imagesource should do it though.

Alternately, if it doesn't happen for you, I could try to debug, but I guess I'd need a debug avisynth? (I can make eedi2.)

fft3d does this sometimes as well, which is why I suspect it's an out-of-memory error (although I have 2gb, I'm not sure what avisynth can access), just weird that it happens at all different sizes.

[tritical]

[link removed], changes:
+ Added pp parameter and pp modes 1, 2, and 3
- A few minor internal changes
- Fixed some documentation errors (field parameter)
- do a vi.SetFieldBased(false) in constructor
- fixed a bug causing reads past the last line and incorrect interpolation
of the very top or very bottom line in some cases
I'd meant to release this two months ago, but forgot about it. I would bet that that last change fixes the access violations. In a couple of routines the y checks were off by one and could lead to reading past the last line. If it still occurs let me know.

For debugging those types of errors it's probably the best/easiest if you can make a debug build of the filter + a debug build of avisynth and then open the script that causes the problem in vdub with the vs.net debugger running. Make sure it is set to break into the debugger on win32 exceptions. A debug build of avisynth also does some tracking of the values immediately before and after vfb's which can help catch outside writes.

@aichan
Did you get your problem worked out or no? The second pass having fewer frames is normal unless the entire video is hybrid like foxyshadis said. If you are doing a two pass encode with a codec then you'll need to run the first/second pass for the codec on the second tivtc script (I gather from your post that you ran the first pass on the first tivtc script and the second pass on the second script).

[johnmeyer]

In this thread:

http://forum.doom9.org/showthread.php?t=106837

I described the unique method I have devised for transferring film to video at a full 24 fps. The one sentence description of what is in that thread is that I remove the shutter from a 16mm film projector; videotape the output using a high shutter speed in the video camera; and then use modified IVTC software (TFM) to recover the original frames.

Here is a link to a 5-second AVI sample of what the raw capture from the projector looks like. This is a free server, so the link will only be good for seven days.

http://download.yousendit.com/4769F7937CBF6A84

This film transfer process always guarantees two good fields of video for each frame of film. The field immediately after the two good fields can either be:

1. A third duplicate (rare, but can happen).
2. A good field of the next frame of film.
3. A "bad" field showing the film in motion between frames.

The TFM portion of TIVTC.dll is absolutely awesome, and the new parameters -- especially the metrics parameter -- have gotten me to the point where everything is almost working.

However, I need help in two areas.

First, is there a way to have TFM make its decisions on a modified version of the clip, but then operate on the original clip? Much of the film I am transferring has sections that were poorly exposed (low contrast). TFM's comb detection, which on normally-exposed film works well, fails on the portions that are low contrast. A solution to this problem is to use "Levels" to increase the contrast. (Actually, this improves detection even for normally exposed film.) However, I don't want to do the exposure correction in AVISynth, because I can do a far better job later in Vegas (my video editing program). Thus, I want TFM to do its detection based on a modified version of my clip, but than do its frame recovery on the original clip. Perfect comb detection is essential to this process because the only time it occurs is when a video frame contains a field that was captured during pulldown (#3 in my list above). If you download the clip, you'll see that these are normally very easy to see visually, and with normal contrast material, TFM catches them quite easily (although if the pulldown has just barely started, the combing can be pretty slight).

I think I can write values to a file in one pass (using the "output" parameter) and then read them back in the next pass (using "input"), but I thought I'd ask if there is an easier way to handle this. The "clip2" parameter seems like it might be designed to do this, but I am not quite sure whether it can do what I am trying to do.

Second, decimation in my film transfer system cannot strictly be "1 of n" because the ratio of the projector speed to camera capture speed is not synced and is not absolutely, perfectly constant. I can get pretty close using cycleR=9,cycle=44 in tdecimate, but I still end up with a few duplicate frames (obviously I want to err on the side of having duplicates rather than drops). My current solution is a real kludge: I write parameters to a file, and then based on those parameters, create a file that can be read by MultiDecimate. Given that AVISynth has to know the total number of frames when it loads a file, this may be the only way to make arbitrary decimation work, but I'd thought I'd ask.

[Fizick]

johnmeyer,
A little offtop, but do you know about my GetDups plugin?

[johnmeyer]

A little offtop, but do you know about my GetDups plugin?

No I don't, which is surprising because I thought I had used everything you've ever written. I'll go right now to check and see what it does.

[johnmeyer]

Very interesting plugin. It is close to what I was looking for, but it appears to be "hard-wired" for 16.67 fps. The projector I am using uses a synchronous motor that is set for 24 fps. Because of belt slippage, etc., it actually doesn't run precisely at that speed, so the decimation can't make any assumptions.

Even though I may not be able to use GetDups, I found HotSpot, which may help me eliminate the residual hot spot from the condenser/aerial lens arrangement I am using.

[Revgen]

@johnmeyer

The clip2 parameter allows you to use deinterlaced frames from another source instead of using TFM's own postprocessing. I typically use this feature to postprocess my clips with EEDI2.

However, it doesn't allow you to process a different video than the one you analyse.

I'm not a programmer, but I don't think it would be too hard for Tritical to add this. Just go to his website (http://bengal.missouri.edu/~kes25c/) and you can find his email at the bottom of the page.

[johnmeyer]

I think I just about have this figured out. With all the new controls in the latest versions of TFM, coupled with the "new" (to me) "Output" capability, I can output all the TFM decisions to an external file. From this, using my own software, I create an input file that MultiDecimate can use in the second pass. Since the whole thing has to be two passes, I use the Levels filter to increase the contrast on the first pass in order to get MUCH improved field matching and comb detection. I then, in the second pass, use the identical script, but without the Levels filter, but WITH the Multidecimate filter, using the external file I created as input.

The only thing I haven't yet figured out how to do is to get TFM to use all the decisions that it made during the first pass. The problem is that without the Levels filter, TFM wants to choose different fields. I'm still stumped on that.

Also, I'm posting elsewhere about a separate, smaller problem, namely that the film apparently wiggles sideways in the gate in the projector, sometimes causing the two good captured fields to not align. I need to figure out how to take each recovered frame from TFM and then re-align the two fields using Depan. I can get this to work field-to-field-to-field, but I don't want it to work between the second field of one frame and the first field of the next frame; I just want it to line up the two fields from one frame.

[foxyshadis]

input=YourOutputFile.txt

Thus, the results of the first pass are imported and no testing takes place (faster that way, too!).

I'm glad to know I'm not the only one who does things to filters they were never meant for. ;)

[johnmeyer]

input=YourOutputFile.txt

I'll work on that tonight and tomorrow morning and see how it works. Thank you!!

Yes, I'm definitely using this in a way that wasn't intended. I have a "Workprinter" for transferring 8mm movies, but when it came time to do 16mm, I couldn't bring myself to spend $2,000 for the equivalent machine in the larger format. I started to build my own, but after I took out the projector's shutter and started to think about things, it became clear that once the projector shutter is gone, if you captured using a REALLY fast video camera shutter speed (e.g., 1/1000 second), you would be absolutely assured of getting two consecutive fields of video for each frame of film. As I looked at the timing diagrams I drew, they looked identical to the IVTC problem, and that's how I ended up here.

The darn thing really works: "Workprinter" discrete frame film transfer, but at full 24 fps, including sound. My next step is to do the transfer with my HDV camera, something that cannot be done with workprinter (because HDV uses long GOP and therefore you cannot do frame-by-frame "grabs").

[tritical]

Running tfm with output="" on the adjusted clip and then using the generated file as input when processing the normal one will work (it will use the matches and combed frame decisions from the input file). The one thing you will probably have to do is adjust the crc value stored in the file as it most likely wont match the non-adjusted clip. To get the crc for the non-adjusted clip use the output="" option to generate a file for it (it doesn't need to process any frames, just load the script in vdub and then close it). Once that file is generated just copy the crc value from it into the other output file. The crc value is computed from the first 15 frames of the clip.

[foxyshadis]

Or just delete it like I do. :p

Anyway, Tritical, so far the new EEDI2 hasn't crashed on me yet, so I guess that was it. Thanks! I haven't strenuously tested it, if I do happen to catch anything later I'll give you a heads up.

[aichan]

@tritical
my 2pass problem not worked out yet, alternatively i used 1 pass NTSC hybrid. when i compare the picture quality,2 pass tivtc is better than 1pass. btw, 2pass tivtc script is mkv vfr right? but i used it on mp4, is that okay?

i think yes, Megui detected it as hybrid film interlaced.

i'm going to try your suggestion, doing the 2nd pass with 2nd tivtc script. but if i do this, what about the 1st pass tivtc script?

thx

[tritical]

I forgot that deleting it would also work. For backwards compatibility with super old versions a crc value isn't strictly required to be present :D.

@aichan
btw, 2pass tivtc script is mkv vfr right? but i used it on mp4, is that okay?
The 2 pass vfr mode will only work when muxing to mkv as the final container because the a/v sync is maintained by using the generated timecode file when you mux the video. Even though mp4 supports vfr, there is no way to do this when creating an mp4 file (that is, there is currently no way the user can directly specify frame durations for individual frames in the same way you can with an mkv timecode file). AFAIK, the only ways to create an mp4 file with this type of vfr are:

1.) encode each fps section separately to mp4 and then concatenate them.

2.) use my tc2cfr program with the timecode file that tdecimate generates as input to generate a 120fps avi file. Then mux that avi file into mp4 which should remove the null frames. Of course, this method requires the video to be in the avi container.

I would recommend reading http://www.avisynth.org/VariableFrameRateVideo if you haven't already.

i'm going to try your suggestion, doing the 2nd pass with 2nd tivtc script. but if i do this, what about the 1st pass tivtc script? My statement wasn't very clear. I just meant the relationship between tivtc passes (for 2 pass vfr) and codec passes (when doing a 2 pass encode with xvid/x264/etc...) needs to be:

1.) run 1st tivtc script - no codec pass
2.) run 2nd tivtc script - codec first pass
3.) run 2nd tivtc script - codec second pass

which you were probably already doing.

[tritical]

[link removed], changes:
TFM:
+ minor field matching improvements
+ optimized postprocessing (mmx/sse2 cubic/blend deint, mmx/sse2 motion
map creation, mmx/sse2 clip2 mask copy, faster link/denoise routines)
+ added ovr help information listing to bottom of output file
- call setcachehints for clip2 when used

TDecimate:
- fixed opt parameter not be respected in the blurring functions used
when predenoise=true

RequestLinear:
- fixed not testing if n <= rlim if the current request was <= to the last
request (it was only testing if rall=true)


The ovr help info that gets added to the end of tfm's output files lists the following:
1.) detected combed frames
a.) frame #, mic value
b.) ranges allowing small breaks with non-combed frames

2.) possible missed combed frames
a.) frame #, mic value

3.) u/b and against order (either n or p) matches
a.) frame #, match

[tritical]

[link removed], changes:
+ optimized combed frame detection functions (now match tivtc)
+ added second spatial combing metric and "metric" parameter (same
as tfm and is/showcombeditvtc)
+ optimized denoise routines
+ improved the field comparison routine (now equal to slow=0 in tfm)
+ mode 2 uses the field comparison routine instead of full frame
subtract for determining the best matching frame (more accurate)
- directly assign frames from emask clip (no need to copy)
- changed blim default to -2.0 (disabled)
- call setcachehints for emask/edeint clips when used

While working on tdeint I noticed a bug in one of tivtc's mmx routines that is used during combed frame detection on yuy2 clips in tfm/iscombedtivtc. It will only be used if you do not have a processor which supports isse or sse2... a workaround is to use opt=0 in tfm and iscombedtivtc. The bug will be fixed in the next version of tivtc.

As far as tdeint/tivtc go, the following are left on the list of things to do:

tdeint:
1.) possibly add slow=1/2 and mchroma field matching functionality so that tdeint matches tfm
2.) html doc

tivtc:
1.) hclip for tdecimate hybrid=1/3
2.) fix bug in mmx routine
2.) html docs

I would like to get that stuff done and release final versions sometime soon. I've made some improvements to eedi2 so there'll be a new version of that as well. After that I'm planning to finally get back to making a motion masking filter capable of producing longer masks (8 or more fields) to be used with tdeint via the emask parameter.

[malouf]

Hi,

I have a problem with TDeint. I'm using it to deinterlace an interlaced video, captured from a videogame with a capture card.

It works wonderfully, except on some frames (pretty rare), that I found are normal interlaced frames, but repeated 2 times or 3 times, probably a bug when the stream was captured.

The problem is that the 2 identical frames are interlaced, and handled like 2 different frames by tdeing, and it generates some very ugly artifacts... And if I just delete them, I have a sound that keeps getting more out of sync.

Is there any parameter that can be used to not have this problem, or something I can do on the video before deinterlacing it? A perfect thing would be a parameter on tdeint that tells it to ignore a frame when it is perfectly identical to the last, and just output a duplicate deinterlaced frame (to keep sound sync).

Anybody had this kind of problems?

Thanks.