TDeint and TIVTC

[StainlessS]

LSmashVideoSource is for ISO containers only, according to my list M2TS is not type ISO.

Function IsISOFileName(String s) {s=RT_GetFileExtension(s) Return(s==".mov"||s==".mp4"||s==".m4v"||s==".3gp"||s==".3gpp2"||s==".3g2"||s==".mj2"||s==".dvb"||
\ s==".dcf"||s==".m21"||s==".m4a"||s==".m4b"||s==".m4p"||s==".k3g"||s==".jpm"||s==".jpx"||s==".mqv"||s==".ismv"||s==".isma"||s==".f4v")}


https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format

https://en.wikipedia.org/wiki/Comparison_of_video_container_formats

EDIT: Sort of related, ftyp's :- http://www.ftyps.com/
Also see note 1 [what is an ftyp] (a sort of FourCC).

[colinhunt]

Enabled Display option for TDecimate to see what the heck it was doing, and discovered that TFM is outputting duplicate frames that break the cadence which seems to confuse TDecimate. In the attached pic you see six duplicates instead of five in a 25 frame cycle, and TDecimate leaves duplicate frame 636 in.

[hello_hello]

I think you've already tried increasing the cycle size for TDecimate, but have you tried giving it total discretion? You could try mode=7 first, but mode=2 on a second pass is sometimes a little better.

1st pass:
TFM(Output="TFM.txt")
TDecimate(Output="TDecimate.txt", Mode=4, rate=24.0/1.001)

2nd pass:
TFM(Input="TFM.txt")
TDecimate(Input="TDecimate.txt", Mode=2, TFMIn="TFM.txt", rate=24.0/1.001)

You sure it's not the broken cadence that causes TFM to create an extra duplicate frame when it has to rather than it being the other way around. If the cadence keeps changing, TFM can't do more than work with what it's given, so to speak.

[hello_hello]

Why old? ffms2 C plugin XP compatible was last updated on the 3rd of May 2020 here: https://rwijnsma.home.xs4all.nl/files/ffms2/
You'll find next updated builds on that website.
Reino keeps both ffmpeg and ffms2 updated and XP Compatible.

Before this moment I was complete oblivious to it. I've done my ffmpeg shopping there for quite a while, but never thought to move away from that page (I bookmarked it) and browse the other aisles.

Cheers.

[colinhunt]

I think you've already tried increasing the cycle size for TDecimate, but have you tried giving it total discretion? You could try mode=7 first, but mode=2 on a second pass is sometimes a little better.
Yeah, I've tried various cycle sizes, and also mode 2 as well. There's been so many variations that I can no longer remember which mode I used when doing 2pass like you outlined. I'll give it a shot regardless.

You sure it's not the broken cadence that causes TFM to create an extra duplicate frame when it has to rather than it being the other way around. If the cadence keeps changing, TFM can't do more than work with what it's given, so to speak.
You're right; I can't be sure what's causing the extra duplicate(s) that break the cadence so TDecimate can't do its job. To be honest, I would not be surprised to learn that the original has somehow been borked in production.

[zybex]

@colinhunt

You can try use some filters from "Duplicate Frame Detectors" after "Tdecimate", to remove remaining duplicate frames.

http://avisynth.nl/index.php/External_filters#Duplicate_Frame_Detectors

[colinhunt]

@colinhunt
You can try use some filters from "Duplicate Frame Detectors" after "Tdecimate", to remove remaining duplicate frames.
Sure, but simply dropping the dups would mess up the frame rate.

[colinhunt]

@pinterf

I'm running TDecimate 1.0.4 in Staxrip 2.1.1.4, with display=true. While most frames give values like "53.94 182819" and "1.03 3485", every now and then I see things like "5442416468121445.00 18446744073709551615" which feels like it can't be correct.

[FranceBB]

Since nobody is mentioning it, for those who don't have Github Notifications turned on, I'm gonna say it: Ferenc released a new version of TDeint (v1.7) to address an high bit depth issue related to edeint. https://github.com/pinterf/TIVTC/releases

[pinterf]

Yep, new versions out there: TDeint 1.7 (September 2020) and TIVTC 1.0.22 (August 2020) (https://github.com/pinterf/TIVTC/releases/tag/v1.0.22b)
Bugfix versions.

[Katie Boundary]

I've mentioned this elsewhere, but tfm's comb-detection algorithms are crap. The cthresh and mthresh have to be set as low as 1 or 2 to detect all combing that is readily visible to the human eye, and yet anything below 7 produces staggeringly high false positives. What are the chances that we'll ever get better comb-detection?

[videoh]

Katie, you're welcome to have a go at it. Distinguishing combing from detail is a very difficult problem. Calling people's heuristic solutions crap is over-the-top, especially when the solution is widely used.

[FranceBB]

Donald is right. Besides, Ferenc is the only person who picked up the project and maintained it after it was abandoned by tritical, so he didn't create it and he's not accountable for what you consider a design flaw of an automated solution.
For what it's worth, it's not perfect, but it works and if it wasn't for Ferenc we wouldn't have had it compatible with proper high bit depth...
Still, it's an open source project, if you think there are some things that can be done better, anyone can fork it, modify it, test it and open a push request. :)

[pinterf]

New TIVTC version: TDeint 1.7 (September 2020) and TIVTC v1.0.23 (20201020) (https://github.com/pinterf/TIVTC/releases/tag/v1.0.23)
[TIVTC] RequestLinear: fix: initial "internal error - frame not in cache"

The startup of the filter contained an unhandled case which occured in multithreading environment when clim>0

[FranceBB]

Thanks for the update. :)

[hello_hello]

I've mentioned this elsewhere, but tfm's comb-detection algorithms are crap. The cthresh and mthresh have to be set as low as 1 or 2 to detect all combing that is readily visible to the human eye, and yet anything below 7 produces staggeringly high false positives. What are the chances that we'll ever get better comb-detection?

I'm sure I've suggested this elsewhere, but try adjusting the combing detection in a different way. Reducing cthresh & mthresh so much isn't necessarily the best way to do it.

I was working with a problem source a few days ago. TDeint was missing small sections of combing. All it took to fix it was reducing the value for MI and changing the metric used for combing detection.

TDeint(mode=1, tryWeave=true, MI=50, metric=1)

TFM has the same MI and metric arguments as TDeint.

[StainlessS]

Good point H.H.
Also, methinks Metric=0 by default, whereas Metric=1 seems to work betterer :)

[wonkey_monkey]

I had to get rid of some residual interlacing and I found a [-1,2,6,2,-1] kernel (vertical) did a decent job. The source material wasn't fantastic quality to begin with, though:

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

[hello_hello]

I had to get rid of some residual interlacing and I found a [-1,2,6,2,-1] kernel (vertical) did a decent job. The source material wasn't fantastic quality to begin with, though:

Excuse my lack of understanding, but how do you use a custom kernel?

[real.finder]

Excuse my lack of understanding, but how do you use a custom kernel?

mt_convolution("1","-1 2 6 2 -1",u=3,v=3) should do it

[Dwedit]

I have a question. After using tfm and tdecimate, you've turned a 60 fields/sec interlaced video into 24 FPS progressive video.

Given a frame number within that 24 FPS video, how do you determine which fields were combined to make that given frame?

Is there a function I can call to query for the field numbers? Do I need to parse the TFM log file? Do I need to manually match the pixels of the frames?

(whoops, this probably belongs in a different thread)

[poisondeathray]

I have a question. After using tfm and tdecimate, you've turned a 60 fields/sec interlaced video into 24 FPS progressive video.

Given a frame number within that 24 FPS video, how do you determine which fields were combined to make that given frame?

Is there a function I can call to query for the field numbers? Do I need to parse the TFM log file? Do I need to manually match the pixels of the frames?

(whoops, this probably belongs in a different thread)


If the internal display=true (p, c, n, b, u) matches and/or debugmode output are not enough info for the field matching step, and display=true not enough for the decimation step, and you want original field numbers -

You can explicitly label the field numbers pre field matching (e.g. using stackvertical with blankclip, separatefields(), selecteven/odd and showframenumber (now field number), with top and bottom labels ;exclude those labels from the actual calculations by using the TFM y0,y1 exclusion band parameters. Tdecimate has the clip2 parameter, so you calculate metrics on the input clip (without labels), but display clip2 with the field info for preview purposes. (Of course you don't want to encode the display version with field info, adjust the script for final encode)


eg.


orig=MPEG2Source("blah.d2v)

origpad = stackvertical(blankclip(orig, height=64), orig)

toppad=origpad.assumetff().separatefields().selecteven().showframenumber(x=0, y=20)

bottompad=origpad.assumetff().separatefields().selectodd().showframenumber(x=100, y=20)

padded=interleave(toppad, bottompad).assumetff().weave()

fieldmatchedpad=padded.TFM(pp=0, y0=0, y1=64)

origfieldmatched=orig.TFM(pp=0)

IVTC = origfieldmatched.TDecimate(clip2=fieldmatchedpad)

IVTC



This example was for a TFF video, and you can change the display formatting if you want - but the way this is setup is the left number is the original source top field numbering , right number is bottom field numbering

So if current frame was 90, but top left says 113, top right says 112, it means IVTCed frame 90 was derived from top field of original frame 113, bottom field of original frame 112

[Dwedit]

Okay, a bit more information...

I'm working on a plugin that will detect 60FPS motion (end credits and other moving text) overlayed over 24FPS telecined video.

Telecined video has a repeating 2-field, then 3-field sequence. If you are looking for moving text at 60 fields per second, you'd want to look at a 3-field sequence. First and Third field will have an identical background, and only the text should move.

This filter would run in conjunction with TFM and TDECIMATE. But in order to figure out whether we are in a 3-field sequence or a 2-field sequence, I'd need to go from Decimated Frame Number to two source Field Numbers, and also know which field number was discarded from a 3-field sequence.

Is there any good place to add such a query function?

[poisondeathray]

Okay, a bit more information...

I'm working on a plugin that will detect 60FPS motion (end credits and other moving text) overlayed over 24FPS telecined video.

Telecined video has a repeating 2-field, then 3-field sequence. If you are looking for moving text at 60 fields per second, you'd want to look at a 3-field sequence. First and Third field will have an identical background, and only the text should move.

This filter would run in conjunction with TFM and TDECIMATE. But in order to figure out whether we are in a 3-field sequence or a 2-field sequence, I'd need to go from Decimated Frame Number to two source Field Numbers, and also know which field number was discarded from a 3-field sequence.

Is there any good place to add such a query function?



That info is not retained in a filter chain with different plugins or filters. You'd have to modify TFM and TDecimate

Is it for a detection plugin only? or is the plugin going to do something about it eg. create mask , or filter it, or something ?

What is the end goal or intended purpose? e.g. lets say you detect frames 100-200 have 59.94 overlay motion over 23.976 BG. Now what ?

[real.finder]

the change log seems to say that greyscale supported, but with

source
Converttoy8()
TFM()
I get
https://i.postimg.cc/Ss9qk7fG/New-File-25-000326.png (https://postimages.org/)

[pinterf]

Thanks for the report.
Download TIVTC 1.0.24 (https://github.com/pinterf/TIVTC/releases/tag/v1.0.24)

EDIT: see 1.0.25 later

**v1.0.24 (20201214)**
- Fix: TFM: do not give error on greyscale clip

[real.finder]

Thanks for the report.
Download TIVTC 1.0.24 (https://github.com/pinterf/TIVTC/releases/tag/v1.0.24)

**v1.0.24 (20201214)**
- Fix: TFM: do not give error on greyscale clip

thanks, but seems there are the same problem in tdecimate :rolleyes: maybe the others too

[pinterf]

thanks, but seems there are the same problem in tdecimate :rolleyes: maybe the others too
Yep, that poor TDecimate has 'chroma'=true by default. What a cruel world. Had to mod all other TIVTC filters as well to silently set chroma=false for greyscale clips. Because you could still set chroma=true for them manually. Stay tuned.

[pinterf]

Download TIVTC 1.0.25 + TDeint 1.8 (https://github.com/pinterf/TIVTC/releases)


** TDeInt v1.8 (20201214)
- Fix: TDeint: ignore parameter 'chroma' and treat as false for greyscale input

**v1.0.25 (20201214)**
- Fix: TFM, TDecimate and others: treat parameter 'chroma' as "false" for greyscale clips

**v1.0.24 (20201214)**
- Fix: TFM: do not give error on greyscale clip

[StainlessS]

Phew!, that was qwik.
Thanks.

[real.finder]

Download TIVTC 1.0.25 + TDeint 1.8 (https://github.com/pinterf/TIVTC/releases)


** TDeInt v1.8 (20201214)
- Fix: TDeint: ignore parameter 'chroma' and treat as false for greyscale input

**v1.0.25 (20201214)**
- Fix: TFM, TDecimate and others: treat parameter 'chroma' as "false" for greyscale clips

**v1.0.24 (20201214)**
- Fix: TFM: do not give error on greyscale clip



it's seems work now, thanks!

[mp3dom]

I'm getting often "Access Violation" on HD clips with YV16 colorspace (the one I'm testing with, but haven't tried with other colorspaces or bitdepth) when calling TDecimate, and some other times I'm getting corrupted video with green horizontal/vertical stripes on the image (using AVS 3.7)
It doesn't happens always, but with a good amount.
For example with this script:

colorbars(width=1920,height=1080,pixel_type="yv16")
assumefps("ntsc_video")
assumetff()
tfm(order=-1,slow=2,micmatching=3,PP=6,mode=3)
tdecimate(mode=1,cycle=5)


Is this happening to others as well?

[poisondeathray]

I'm getting often "Access Violation" on HD clips with YV16 colorspace (the one I'm testing with, but haven't tried with other colorspaces or bitdepth) when calling TDecimate, and some other times I'm getting corrupted video with green horizontal/vertical stripes on the image (using AVS 3.7)
It doesn't happens always, but with a good amount.
For example with this script:

colorbars(width=1920,height=1080,pixel_type="yv16")
assumefps("ntsc_video")
assumetff()
tfm(order=-1,slow=2,micmatching=3,PP=6,mode=3)
tdecimate(mode=1,cycle=5)


Is this happening to others as well?

Works for me, seek around, no problem

avs+ x64 3.7 r3382
TIVTC v1.0.25

[patul]

Doesn't work for me either

AVSMeter 3.0.7.0 (x64), (c) Groucho2004, 2012-2020
AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: D:\App\AVS\plugins64+\TIVTC.dll
Address: 0x00007FFE1DA2F8CD

TIVTC.dll v1.0.25

[poisondeathray]

Works for me, seek around, no problem

avs+ x64 3.7 r3382
TIVTC v1.0.25


avspmod - ok
avsmeter - ok

vdub2 - access violation
ffmpeg - crash (unhandled exception)

[pinterf]

oh, what a nice Monday morning :) But we all like reproducible bugs, aren't we?

[mp3dom]

Well all I can say is that this happens to me on VDub2 and avsmeter too (but never tried avspmod or ffmpeg), the address changes every time so I think it's not useful (?)
On avsmeter, sometimes it doesn't complete the pre-pass process (exits without any warning to the command prompt) and some other times it show the access violation (and sometimes it completes the process as well). Can't find the rule behind this. I'm using the x86 version now, but looking at the posts below me, it seems this happens on x64 too...

[pinterf]

Check v1.0.26
https://github.com/pinterf/TIVTC/releases

[mp3dom]

Thanks, that was really quick and seems to be fixed. :)

[patul]

Amazing.. I can confirm the script no longer crashes on x64 with avsmeter or avspmod.

[Emulgator]

Deepest respects for all that cleanup work across so many plugins, pinterf ! (again)

[pinterf]

Sometimes the cleanup process is going too well, jackoneill has just noticed an old regression-type bug in TDecimate

[Statick]

having an issue with TFM micmatching not apparently doing anything at all

I'm trying to process a DVD animation, and I keep getting bad matches which I can correct with overrides, but this is a very long and tedious process. I would rather find a way to get better matches automatically

with debug=true I can see the mics for each frame, and various other info, in a debug console, and no matter what mode I set micmatching to, it makes no difference at all to the final match. if I disable it entirely, I get the exact same results as if I choose any of the micmatching settings. it apparently does nothing except slow the process down to calculate mics that arent used.

also, the final match chosen invariably has a high mic value compared to other frames. the readme for TFM says for micmatching mode 1 "mics are only used to determine if of the 5 possible matches there is one match that has a significantly lower mic value than all of the other four matches" which suggests to me that lower mics are preferred for better matches. yet invariably when TFM chooses a bad match, the mic of the chosen bad match will be something like 58 and the mic of the good match that I override with will be about 11. I'm not entirely sure how this is supposed to work but as changing the micmatching setting doesn't even change anything in the output, I'm at a bit of a loss. any help understanding this would be appreciated! cheers

using TFM 1.0.7

[LigH]

I wonder about your source. May it contain field blends?

[Katie Boundary]

Katie, you're welcome to have a go at it.

And I did. The question now is whether anyone wants to try the algorithm I suggested.

Distinguishing combing from detail is a very difficult problem.

It's not difficult at all. The two are extremely dissimilar.

Calling people's heuristic solutions crap is over-the-top

Not when they produce crap results.

especially when the solution is widely used.

Lots of things that are widely used are still crap. Windows 10, for example.

Donald is right.

No he isn't.

Still, it's an open source project, if you think there are some things that can be done better, anyone can fork it, modify it, test it and open a push request. :)

Anyone who knows how to code AVIsynth plugins, you mean. I've tried learning C++ several times in my life. I've never gotten very far. As it turns out, there are some things that even I'm not autistic enough for.

[real.finder]

what about https://github.com/pinterf/TIVTC/issues/27 ?

[LigH]

It's not difficult at all. The two are extremely dissimilar.

Easy for humans. Quite a challenge for computer algorithms. If that was as easy as you believe, there wouldn't be numerous attempts, more or less successful.

[StainlessS]

As it turns out, there are some things that even I'm not autistic enough for.
Dont give up so easily, I'm sure there is nothing that you are not autistic enough for.

[FranceBB]

Easy for humans. Quite a challenge for computer algorithms. If that was as easy as you believe, there wouldn't be numerous attempts, more or less successful.

Precisely.

Katie, you think they're different 'cause you "see" them as being different, but a computer doesn't see, a computer works with numbers.
The whole frame is divided in blocks and macroblocks of a certain size, they can be 4x4, 8x8, 16x16 etc. Each one goes through a transform which assigns a value to it. The next frame goes through the same process and values are assigned to each block. Those two frames are then compared by comparing the values of each individual block and, based on that, the algorithm tries to find out whether those blocks are the same or not.
In theory, everything works out, but in practice it might not.
You see, there can be tons of things that can go wrong in the motion vectors detection and it's far from easy to get this done perfectly in every scenario.
If you think that the alternative would be specifying a pattern by hand and modify it over and over again when and if it changes like at commercial breaks etc by manually handling exceptions, suddenly you realize what an amazing job TDecimate is actually doing. Sure, it might not be perfect every time, but still a lot of effort has been put into it and I'm very glad that we have it.

[Boulder]

Dont give up so easily, I'm sure there is nothing that you are not autistic enough for.

A truly autistic person would go through the videos frame by frame and create an override file for a 110% perfect result.