TDeint and TIVTC

[Gser]

Okay I finally managed to write down the frames like so but I didn't quite understand the formatting of the extended overrides file. How would I format this information?
0 265 v
266 421 vc
422 470 v
471 480 e
481 2097 v
2098 2102 e
2103 2686 v
2687 2691 e
2692 3053 v
3054 3110 ii
3111 3902 v
3903 3963 ii
3964 5969 v
5970 5992 e
5993 10290 v
10291 10417 ii
10418 50437 v
50438 50460 e
50461 86904 v
86905 87064 ii
87065 90390 v

[DJATOM]

It seems I found a bug. 1.0.8 work as expected while 1.0.9 and 1.1.10 randomly produces timecodes without 30fps sections. It might be due to workaround, I didn't tried to research there. Just downgraded it step by step and 1.0.8 is safe.
How to reproduce:
1) run vfr 1st pass (I tried with Pokemon pearl and diamond 2007, that's definitely vfr content)
2) refresh video in avspmod few times (more often it contains less frames and shows less duration)

[pinterf]

New build, fix for the issue mentioned by DJATOM
It was fixed a bit earlier but only published now.
https://github.com/pinterf/TIVTC/releases/tag/v1.0.11

**v1.0.11 (20180323)**
- Revert to pre-1.0.9 usehint detection: conflicted with mode 5 (sometimes bad clip length was reported)
(reason of the workaround (crash at mysterious circumstances) was eliminated: mmx state was not cleared in mvtools2)
- Fix: bad check for emptiness of orgOut parameter

**v1.0.10 (20180119)**
- integrate new orgOut parameter for TDecimate (by 8day) (see TDecimate - READ ME.txt)

[GMJCZP]

Thanks.

[hello_hello]

Thanks for the update.

Out of curiosity, did you have a chance to look at this bug pinterf?
https://forum.doom9.org/showthread.php?p=1812705#post1812705

[FranceBB]

Thanks. I appreciate! I use TIVTC almost on a daily basis! :D

[Katie Boundary]

TFM's biggest weakness is that it's terrible at telling the difference between interlacing and any other kind of fine horizontal edge. Given these two parts of the same image...

https://scontent-sjc3-1.xx.fbcdn.net/v/t1.0-9/41512476_165322437691021_7845687562139074560_n.jpg?_nc_cat=0&oh=e11823661e6ff002b0c8bcdceab458d6&oe=5C34C690

https://scontent-sjc3-1.xx.fbcdn.net/v/t1.0-9/41412396_165322431024355_4547717527140040704_n.jpg?_nc_cat=0&oh=9d14be931e19340c9c57e93197d94ee1&oe=5BF0546C

There is no combination of settings (as far as I can tell) that will recognize the bottom part, but not the top, as interlaced; however, there is a huge range of settings where the opposite will happen, and the top part will get "deinterlaced" but the actual interlacing gets through. Does anyone know of a solution or workaround for this?

[hello_hello]

There is no combination of settings (as far as I can tell) that will recognize the bottom part, but not the top, as interlaced; however, there is a huge range of settings where the opposite will happen, and the top part will get "deinterlaced" but the actual interlacing gets through. Does anyone know of a solution or workaround for this?

What settings have you tried?
It's pretty hard to do anything but wildly guess without a sample, but you can always use an external deinterlacer instead, assuming you know of one that's better at "telling the difference between interlacing and any other kind of fine horizontal edge".

If you specify a clip for the clip2 argument, and PP<5, then TFM will take the entire frame from the specified clip whenever it detects combing.
The frame from the specified clip could be fully de-interlaced or partially de-interlaced or not de-interlaced at all, based on the decisions of the de-interlacer de-interlacing it.

When messing around with TFM's settings I've found doing this sort of thing useful at times:

A = Last
B = A.TFM(pp=1).GreyScale()
C = A.TFM(pp=6, Clip2=B)
Return C

Nothing gets de-interlaced, but the second instance of TFM builds the usual mask for the sections where it detects combing and takes them from clip2, the upshot being they'll be black and white, making it easier to see what it's doing.
Or try PP=1 with Display=true and TFM will draw a white box around the area that triggered the frame's detection as combed.

[StainlessS]

A = Last
B = A.TFM(pp=1).GreyScale()
C = A.TFM(pp=1, Clip2=B, PP=6)
Return C



HH, above cant be right, would throw an error as pp aready given.
I've CODE blocked your snippet for you in quote, shame I cant do that in your post, perhaps I should be a moderator :)

[hello_hello]

Thanks. I probably copied and pasted one of the lines, but failed to edit it properly. I'll fix the post.

[Stereodude]

I realize TIVTC is mostly dead, but if our hero pinterf is taking requests, I'd like a different way to control the hybrid mode of tdecimate. Like a percentage parameter. An absolute value with vidThresh isn't very helpful IMHO.

In hybrid mode I care about the frame with a low outlier metric, not the absolute value. If I have basically the same metric value for all 5 frames, say ~15 of course I want them blended. If I have 4 frames that are ~15 and one that's 2.5 I want to drop the 2.5, and do no blending. Currently I control that with vidThresh. So I can set vidThresh to 2.6 which works fine until there's a later scene that has four ~30 frames and a frame that's 3. It will miss that and instead blend. It may also force a frame drop where it should blend if all the frames have low metrics (like 2.5 for all 5) due to limited motion.

A ratio parameter that I can set to say 25% which will look difference between the smallest metric value in relation to the average metric of all 5 or the average metric of the highest 4 frames seems like it would be much more useful.

That way 5 frames with the same metric get blended whether they're all 2.5, all 15, or all 30. And the outlier gets tossed whether it's a 1 among 5's or a 4 among 30's.

[mp3dom]

Is it possible to add HBD/avs+3.x colorspaces support?

[pinterf]

Not in the near future. I spent some days on code cleaning which would need for any further development but I'm probably at 20% with that. It is a big achievement that last week I made TDeint compilable on msvc x64 and clang as well. More code clean will follow, drop yuy2 and add yv16. Only then can follow any hbd fun.

[Stereodude]

Is it possible to add HBD/avs+3.x colorspaces support?
Why would it need those? Is there i60 telecined content in 10 bits or color formats other than 4:2:2 or 4:2:0?

[real.finder]

Why would it need those? Is there i60 telecined content in 10 bits or color formats other than 4:2:2 or 4:2:0?

https://forum.doom9.org/showthread.php?t=180668

and maybe there are 4:4:4 mastereds

[MeteorRain]

Why would it need those? Is there i60 telecined content in 10 bits or color formats other than 4:2:2 or 4:2:0?

Not knowing any telecined but when 4K/8K60 TV station broadcast 24 content, they put 4 real pictures and 6 duplicates in every 10 frame group, so decimate process is needed at least. Although in my cast the rhythm if consistent and I ended up selectevery(10, ...).

[mp3dom]

Why would it need those? Is there i60 telecined content in 10 bits or color formats other than 4:2:2 or 4:2:0?

Yes, there are some broadcast sources recorded at 10bit and with telecined contents.
@pinterf: Thanks for the reply and explanation.

[FranceBB]

Why would it need those? Is there i60 telecined content in 10 bits

don't know about 10bit telecined (although perhaps I received some 10bit ProRes that were telecined very long time ago, I'm not sure), but there are definitely 10bit interlaced contents; for instance every camera that records in AVC-Intra 50, AVC-Intra 100, AVC-Intra 200 in FULL HD in PAL regions almost definitely is 4:2:2 planar 25i TFF 10bit H.264.
I've received tons of those files, generally stored in Panasonic P2 cards, but luckily I live and work in a PAL region so it wasn't a big deal, but it could be a nice present for those living in NTSC countries or for those who want to either bob or deinterlace it if tdeint supports high bit depth.

https://i1.creativecow.net/u/1/p2_e_linup.jpg

(I'm just thinking out loud, not really requesting it...)

[qyot27]

Why would it need those? Is there i60 telecined content in 10 bits or color formats other than 4:2:2 or 4:2:0?
I was thinking the same thing, and apart from the cases pointed out already (IMO, the fresh remastering/capture from video to 16bit 4:4:4 or RGB is a pretty compelling one), I wonder if maybe there's a chance that even if you don't have >4:2:0 >8bit content natively, that upsampling to 4:2:2 or (more likely) 4:4:4 beforehand can produce more accurate metrics to pass into the field matcher?

[mp3dom]

It's pretty rare to have "native" telecined sources, but it's not uncommon to have 10bit 24p sources telecined to 60i and edited afterwards at 60i, with bad edits and mixed real 60i footage (i.e extra contents for domestic releases). There's a solution obviously but you need to skip the 10+bit path. I don't think it's so "essential" to have a native 10+bit path, but it would be a nice addition.

[pinterf]

Could someone put together a bunch of minimal test cases (avs script with only one or two lines per case) for TDeint/TIVTC which covers most main modes, I'd use them for before-after tests (old YV12-new YV12 for regressions, YUY2-YV16) and comparing 420 and 422 results. And perhaps a short sample clip as well, which is a big uglyer than a simple ColorBars. Thanks in advance.

Since 4:2:2 chroma part is more significant than is in 4:2:0 I have a feeling it may result in different metrics during frame difference comparisons. I don't know yet if it is handled or not in present program, I haven't seen correction for that. But if not, I probably I have to provide the same method as in mvtools2: such frame difference metrics (SAD, SSD) are normalized to the 4:2:0 case and the chroma results for 4:2:2 or 4:4:4 are divided back to match with that. And with a parameter (like scaleChromaSAD in mvtools2) one can made chroma part to be more significant.

[real.finder]

test cases with original samples? or with making telecined/interlaced clip from some avs codes?

[pinterf]

Thanks I solved it. Because there is no 'typical' usage I have to test all relevant parameter combinations. Most of TDeint work is done, yv16 support is working, C and SSE2 is identical, yuy2 and yv16 is identical as well. Though yuy2 is faster at the moment than yv16. that was a huuuge work, still a lot of code refactor remained. TIVTC is in pieces as well, did not started re-testing its functionality, it still needs heavy refactor, along with eliminating much common copy paste parts with tdeint and even duplicated triplicated parts inside itself. Crazy. So work in progress for at least a few weeks.

[Stereodude]

Are the y0 and y1 parameters broken/limited in TFM or not used in quite the way that the documentation claims? :scared:

With this script:
source=MPEG2Source("VTS_02_1.d2v", idct=5, moderate_h=40, moderate_v=40, cpu2="xxoooo", info=0).crop(0,0,-4,-0)

moverlay = ImageSource("overlay.png", end=1000).ShowRed ("YV12")
mmask = ImageSource("mask.png", end=1000).ShowRed ("YV12")

c1 = mt_merge(source, moverlay, mmask, luma=true)

case1=StackVertical(c1, source).TFM(d2v="VTS_02_1.d2v", y0=480, y1=960, PP=1, flags=5, MI=24, clip2=deint, display=true, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")
case2=c1.TFM(d2v="VTS_02_1.d2v", mode=5, PP=1, flags=5, MI=24, clip2=deint, display=true, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")
I get different pattern matches between case1 and case2 despite the documentation saying that my use of y0 and y1 (to exclude the lower stacked video) will effectively cause TFM to use the same video for field matching decisions in both cases.

case1 (incorrect match):
https://i.imgur.com/RDPJjSC.jpg

case2 (correct match):
https://i.imgur.com/XfhXL52.jpg

I'm trying to exclude the titles fading in and out from messing up the pattern detection of the underlying telecined content by masking them out. The concept works as expected as shown by case2. However, despite excluding the entire lower (original) clip with the arguments for y0 and y1 so that it only uses the upper "masked" clip, TFM does not seem to actually ignore the bottom for the field matching.

:confused:

[pinterf]

Please check TDeint 1.2

(git project of TDeint is common with TIVTC. TIVTC has not changed since 1.0.14 but I have uploaded it again to have both TDeint and TIVTC together)

** TDeInt v1.2 (20200505 - work in progress) **
- Add AviSynth+ V8 interface support: passing frame properties
- Add planar YV16 and YV24 color spaces (The Big Work)
result: YV16 output is identical with YUY2 (but a bit slower at the moment)
- Fix mode=0 for yuy2 (asm code was completely off)
- Fix mode=0 (general), luma was never processed in CheckedComb
- Fix crash with AviSynth+ versions (in general: when frame buffer alignment is more than 16 bytes)
- TDeint: refactor, code clean, c++17 conformity, keep C and SSE2
- Inline assembler code ported to intrinsics and C code.
- Add some more SSE2 (MMX and ISSE code kept but is not active (since then it was removed))
- x64 version is compilable!
- Add ClangCL, and XP configurations to the solutions.


Although I have uploaded both TIVTC and TDeint as a common project on github, so far I worked only on the TIVTC the part.
This year I felt like TDeint could be updated as well.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.14b

[real.finder]

Please check TDeint 1.2
This year I felt like TDeint could be updated as well.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.14b

thanks for update TDeint :goodpost:

[FranceBB]

Thank you! :D
YV16 and YV24 were very much needed! :)

[LigH]

TDeint in 64 bit! My hero!

:thanks:

[mp3dom]

Veeery nice!
Big thanks!

[Sparktank]

There's a Leonardo DiCaprio meme going around that's popular right now...
And that was my first reaction to this. :)

Looking forward to updates.
Got some DVD's I want to crack again.

[pinterf]

TIVTC 1.0.15 and TDeint 1.3 with YV16, YV24 and YV411 support. (Along with former YV12 and YUY2 color spaces)
Enjoy.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.15

# TIVTC v1.0.15 (20200508)
# TDeInt v1.3 (20200508)

This is a modernization effort on tritical's TIVTC (v1.0.5) and TDeInt (v1.1.1) plugin for Avisynth by pinterf

# TDeint (see change log of TIVTC later)

** TDeInt v1.3 (20200508) **
- Add YV411 support, now all 8 bit planar YUV formats supported (except on debug display modes)
- more code clean and refactor
- Give error on greyscale or 10+ bit videos

** TDeInt v1.2 (20200505) **
- Add AviSynth+ V8 interface support: passing frame properties
- Add planar YV16 and YV24 color spaces (The Big Work)
result: YV16 output is identical with YUY2 (but a bit slower at the moment)
- Fix mode=0 for yuy2 (asm code was completely off)
- Fix mode=0 (general), luma was never processed in CheckedComb
- Fix crash with AviSynth+ versions (in general: when frame buffer alignment is more than 16 bytes)
- TDeint: refactor, code clean, c++17 conformity, keep C and SSE2
- Inline assembler code ported to intrinsics and C code.
- Add some more SSE2 (MMX and ISSE code removed)
- x64 version is compilable!
- Add ClangCL, and XP configurations to the solutions.

# TIVTC v1.0.15 (20200508):

**v1.0.15 (20200508)**
- Fix random crashes (due to old plugin assumed that Avisynth framebuffer alignment is at most 16 bytes)
- Other small fixes, which I do not know what affected
- Support planar YV411, YV16 and YV24 besides YV12 (YUY2 was not removed)
(except on debug display modes)
- Huge refactor and code clean, made some parts common with TDeint, code un-duplicate-triplicate
- only C and SSE2, no MMX, no ISSE
- parameter opt=0 disables SSE2, 1-3 enables (was: 1:MMX 2:ISSE 3:SSE2)
- Add ClangCL, and XP configurations to the solutions. (note: MSVC can be quicker(!))
- Add AviSynth+ V8 interface support: passing frame properties
- Give error on greyscale or 10+ bit videos
- Todo: more refactor needed before moving to 10+ bit depth support

[real.finder]

TIVTC 1.0.15 and TDeint 1.3 with YV16, YV24 and YV411 support. (Along with former YV12 and YUY2 color spaces)
Enjoy.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.15



thanks

greyscale will be added when HBD is ready, right?

[FranceBB]

Thank you for the update, but did something change in the syntax of TIVTC / tdeint?
'cause I just run a script I've been using for decades to inverse telecine and now TFM it's complaining that "clip2 colorspace must be the same as the input clip", however the input it's yv12 and it's supposed to stay yv12.


video=DGDecode_MPEG2Source("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421.d2v")
audio=FFAudioSource("\\VBOXSVR\Share_Windows_Linux\Production\RAW\417-423\421 T81 2_0ch 224Kbps DELAY -115ms.ac3")
AudioDub(video, audio)

tfm(mode=1,pp=5,slow=2,micmatching=2,clip2=tdeint(mode=2,type=3))
tdecimate()

TFM is indeed working in yv12 and it's expecting tdeint to work in yv12 too. If I run tdeint(mode=2, type=3) alone it does output yv12, so why is TFM complaining about different colorspaces?

https://i.imgur.com/tRyFFFo.png


I mean, this works:

Source()

tfm(mode=1,pp=5,slow=2,micmatching=2)

and it's getting yv12 input and outputting yv12 output.

This works:

Source()

tdeint(mode=2, type=3)

and it's getting yv12 input and outputting yv12 output

so why when I use the tdeint deinterlaced version as reference for TFM it complains that the colorspace is different? O_o

[mp3dom]

Guess there's a missing "not" (!) in the check, because actually it works if the colorspaces between the two clips are different.

if (vi.IsSameColorspace(vi2))
env->ThrowError("TFMPP: clip2 colorspace must be the same as input clip!");

[pinterf]

Thanks for the report, I'll fix it soon

[pinterf]

Download new version: TIVTC 1.0.16, (TDeint 1.3 unchanged)
https://github.com/pinterf/TIVTC/releases/tag/v1.0.16
**v1.0.16 (20200510)**
- Fix: TFMPP clip2 colorspace similarity check failed

[pinterf]

Important bugfixes (regressions: metrics saving to file was broken and clip2 colorspace check failed for TDecimate) for TIVTC.
And a TDeint with 10-16 bits + greyscale support.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.17

[FranceBB]

And a TDeint with 10-16 bits + greyscale support.

https://github.com/pinterf/TIVTC/releases/tag/v1.0.17

Wonderful! After so many years, now I can finally use tdeint to quickly deinterlace AVC-Intra 100 25i 10bit clips. :D
Thank you, as always, Ferenc.

[mp3dom]

Thanks, it seems is growing nicely! :)

[LigH]

Issue in a VideoHelp forum thread (https://forum.videohelp.com/threads/397201-TDecimate-scrip-problem) - can anyone imagine why TDecimate may not produce a video output if "mode=2" is given explicitly?

[pinterf]

Issue in a VideoHelp forum thread (https://forum.videohelp.com/threads/397201-TDecimate-scrip-problem) - can anyone imagine why TDecimate may not produce a video output if "mode=2" is given explicitly?
Yes, it can be in connection with the metric calculation bug which was fixed in v17.

[pinterf]

Service announcement.
Another fix for TDeint.
mode=2 with some other parameter combination resulted in green line on the right (SSE2, non mod16 width or chroma width)

Download TDeint 1.5.
https://github.com/pinterf/TIVTC/releases/tag/v1.0.17b

[LigH]

kalemvar1 reported that TDecimate (TIVTC v1.0.17) still gets stuck, in mode=2 only. You may need some of his material to check this case... :o

[pinterf]

kalemvar1 reported that TDecimate (TIVTC v1.0.17) still gets stuck, in mode=2 only. You may need some of his material to check this case... :o
Yes, I checked this morning, but I experienced no problem with my source.

[Stereodude]

Please check TDeint 1.2
I checked it using TIVTC v1.0.17b and the problem still exists. y0 and y1 do not do what the documentation suggests or there's some additional restrictions on what exactly they do that's not explained in the documentation.

[pinterf]

I checked it using TIVTC v1.0.17b and the problem still exists. y0 and y1 do not do what the documentation suggests or there's some additional restrictions on what exactly they do that's not explained in the documentation.
Parameters are almost good.
TFM(d2v="VTS_02_1.d2v", y0=480, y1=960, PP=1, flags=5, MI=24, clip2=deint, display=true, ovr="D:\DS9S6D1\E01\tfm_ovr.txt")

Documentation is good, active area is processed when
if ((y < y0) || (y0 == y1) || (y > y1))

With your settings: when y<480 or y>960

But upper and lower 2 lines of the whole frame are omitted from analysis (because they do not have previous top and next bottom lines)

Calculating:
original frame y coordinates go from 0 to 479.
stacked frame y coordinates go from 0 to 959.

So when stacked:
y goes from 2 to 957. You disabled lines over 480
So 2..479 is checked.

When your input is single (not stacked):
y goes from 2 to 477

That is different.

The stacked version would look into the top 2 lines of the bottom frame.

Try specifying 478 and let's see what happens.
Or is there any difference when you set y0=478 for both versions.

[Stereodude]

Try specifying 478 and let's see what happens.
Or is there any difference when you set y0=478 for both versions.
Using 478 / 960 does the same thing as 480 / 960.
No difference from y0=478 on both.

Still different matches on the stacked clips (restricted to the masked clip) vs. the single masked clip.

[pinterf]

Using 478 / 960 does the same thing as 480 / 960.
No difference from y0=478 on both.

And y0=476? (YV12 has vertical subsampling and may need 2*2 less than the original 480)

Still different matches on the stacked clips (restricted to the masked clip) vs. the single masked clip.
I cannot reproduce with my source, if my guess above does not work then could you arrange me a sample clip?

[Stereodude]

And y0=476? (YV12 has vertical subsampling and may need 2*2 less than the original 480)


I cannot reproduce with may source, if my guess above does not work then could you arrange me a sample clip?
478 -> 476 gives the same behavior.

So I cut a sample from the M2V to provide you, but it didn't fail on the sample. It works as expected. :confused:

I can't explain it, but whether it fails or not seems to depend on the size of the sample. The 183 frame sample does not have the failure. The 462 frame sample does. I tried to rule out the program I was using to cut the M2V file (Mpg2Cut2) by running the entire clip through it to see if it behaved the same (it did). I've included both small clips. Maybe having both will help you figure out the cause of the problem.

http://stereodude.net/DS9S06E01_TIVTC_bug.7z

[pinterf]

478 -> 476 gives the same behavior.

So I cut a sample from the M2V to provide you, but it didn't fail on the sample. It works as expected. :confused:

I can't explain it, but whether it fails or not seems to depend on the size of the sample. The 183 frame sample does not have the failure. The 462 frame sample does. I tried to rule out the program I was using to cut the M2V file (Mpg2Cut2) by running the entire clip through it to see if it behaved the same (it did). I've included both small clips. Maybe having both will help you figure out the cause of the problem.

Thanks. It's most probably not TFM filter related.
With VTS_02_1_bad_sample.M2V I got the difference right at frame 14. Debugging revealed nothing. But as I was single stepping until frame 14 in vdub2 and pressed a refresh, a totally different frame came in at the very same frame #14. Totally reproducible, so it's probably the source + source filter that behaves inconsistently, because it is not returning the same frame when the Nth frame is requested. I'm using ffms2 (don't know which version) but I think probably your issue has very similar roots.