TDeint and TIVTC [Archive] - Page 2

tritical

4th May 2007, 04:28

@Chainmax
The script looks right, but you'll need to use TMMv1 (http://bengal.missouri.edu/~kes25c/TMMv1.zip) instead of mmask.dll for that syntax to work.

@foxyshadis
I'll do that.

@Zarxrax
Next, is it really necessary to specify the d2v parameter manually? Can't dgdecode pass the data to tfm as a hint or something? And also, is there anyway that tfm could simply fix the d2v file on the fly, rather than making a new one and requiring you to go back and change your script?
It would be possible for dgdecode to pass the information to tfm, but dgdecode doesn't currently have this ability. Also, it is slightly easier reading from the d2v and it's faster. TFM could fix the d2v on the fly (meaning it could simply overwrite the existing file instead of creating a new one), but the dgdecode object would still need to be recreated (script closed/reopened) for the changes to effect decoding. My main reason for not overwritting the existing file is I sometimes like to examine the two side by side.

If I set the d2v parameter, then tfm will check the d2v for illegal field order, and create a new d2v if necessary. Also, tfm will use hints from the d2v to help its field matching process? Will this theoretically give more accurate results, or will be be faster?
What exactly happens depends on the 'flags' parameter. With the default setting of 4, tfm will check the d2v for illegal transitions and create a new d2v if necessary. It will also pass rff information to tdecimate. The rff information is only used to help aid hybrid detection (detection of 30p parts), so unless you are using hybrid > 0 it won't effect anything (and if the d2v is just all 2's or 0's it won't effect anything either). tfm will also use the trf flags for field matching in film sections (areas of the d2v with the 012301230123 pattern). That means it will determine what match to use based on the d2v flags. It will then check each of these d2v based match decisions to see if the resulting match is combed or not. If it is, then tfm will go back and run its usual match algorithm. Otherwise, it will use the d2v match. This can give a significant speed up if the video has a lot of sections that follow the 01230123 trf pattern, since it means tfm wont have to run its match algorithm. It can also improve things since tfm isn't always correct in its match decisions.

I will say that if you work mostly with r1 anime, the d2v parameter is usually not that helpful since most r1 anime never has 01230123 flagging (the d2v will just have 0's and 2's, 100% NTSC reported by dgindex). In that case, all that setting the d2v parameter accomplishes is checking for illegal transitions.

Zarxrax

4th May 2007, 17:13

Alright, thanks for the clarification.

ChiDragon

5th May 2007, 22:16

tritical, can you check this out?

Metrics file ("cap9_TDec.txt") (http://chidragon.thedessie.com/cap9_TDec.txt)
BlankClip(length=80061,pixel_type="YV12",fps=30000,fps_denominator=1001)
TDecimate(mode=2,rate=23.483,input="cap9_TDec.txt",batch=true,display=true)

This gives me a "System exception - Access Violation." Other rate values also cause it. 23.482 works fine, as do these rates with mode=7 instead of 2.

I've also got a request... would it be possible to add standalone "+" to the override options to force a decimated frame to be kept? From what I've gathered through use and TDecimate's doc, "+" is currently only used to separate kept and dropped frames for override cycles (which are hard to write out for hundreds of frames at a time) and doesn't actually override anything itself. Currently I usually just edit my TDecimate metrics files and give frames I want to keep huge values, but it's not really practical, especially when I mess up and want to undo something.

chipzoller

6th May 2007, 18:18

Would someone mind taking a look at this sample (http://www.megaupload.com/?d=ZJ2I3WHE). I'm trying to figure out how to setup tfm and tdecimate to restore progressive frames from this apparent 2p4i pattern clip but after reading the help files for both and trying samples/experimenting around with decimation cycles am not sure how to restore this. It actually looks like blended fields, but I know this series (Sherlock Holmes with Jeremy Brett) was shot in film, and all the DVDs in the series except the one from which this episode was taken were just soft pull-downs. Or is this not a candidate for tfm+tdecimate but rather some function like restore24 or the likes? Thanks much for the advice.

Boulder

7th May 2007, 07:43

The series were originally shot as progressive 25fps I think. Does RePAL do any good?

Livesms

7th May 2007, 16:01

@All
Can anybody suggest good Bob deinterlace
I tried Tdeint as a bob deinterlace for my TFF PAL video
topf = separatefields().selecteven().createMM()
botf = separatefields().selectodd().createMM()
tdeint(mode=1,order=1,emask=buildMM(topf,botf,mode=1,order=1,dis=2)) and got this
http://img5.imagevenue.com/loc385/th_50064_TDeint_122_385lo.jpg (http://img5.imagevenue.com/img.php?image=50064_TDeint_122_385lo.jpg)
Yadif(mode=1) give me better result with straight lines but has lots of artifacts
http://img175.imagevenue.com/loc379/th_50068_Yadif_122_379lo.jpg (http://img175.imagevenue.com/img.php?image=50068_Yadif_122_379lo.jpg)

chipzoller

8th May 2007, 00:55

@Boulder,
Yes I think you may be right. It's just that with the majority of the releases in the "Adventures of..." series they did a proper telecine job, but with this one it seems they went the lazy route and just did a blend-conversion. I'm really not "up" on the methods and processes to get PAL to NTSC so I can't speak from a knowledgeable position...In any case, RePal seemed to do a good job, although I had to use convertfps(25) at the end as it was outputting a 24.75 frame rate otherwise. I really wish there were some tutorials out there that gave examples of various field blendings and avisynth scripts/plugins to try and tackle them.

Boulder

8th May 2007, 03:27

Instead of ConvertFPS, use AssumeFPS.. then again, Restore24 has a RePAL equivalent which outputs 25fps IIRC. You might want to post in the R24 thread or create a new one in the Avisynth usage forum so it will get noticed by the pros :)

ChiDragon

8th May 2007, 05:13

You should probably use AssumeFPS(25,1,true) followed by an audio resample instead of ConvertFPS. Bump up the video framerate and alter the audio pitch slightly instead of adding blends to your unblended video...

EDIT: Sorry, I see Boulder already said that. I had a cached version open.

chipzoller

8th May 2007, 13:52

Thanks ChiDragon. I'll try AssumeFPS with those params as AssumeFPS(25) produces out of sync audio. However since I'm dealing with a demuxed DVD source, how would, once you demux the audio track, you get AssumeFPS and avisynth to consider and alter the AC3 file?

manono

8th May 2007, 15:58

@Boulder,
In any case, RePal seemed to do a good job, although I had to use convertfps(25) at the end as it was outputting a 24.75 frame rate otherwise.
What's the matter with 24.975fps? Is it any more peculiar than 23.976? If for AVI, keep it there. If for DVD, run the MPV through DGPulldown with the Custom box ticked and 24.975->29.97 filled in. That way you can keep the audio unchanged. ConvertFPS just reblends what RePAL unblended, and AssumeFPS, as you discovered, requires stretching the audio.

If you are going to use AssumeFPS and stretch the audio, you may as well make it for 23.976fps if, as you say, it was shot on film.

chipzoller

8th May 2007, 18:14

Manono, these are destined for my iPod and it needs a frame rate of PAL, film, or ntsc to comply with spec.

manono

8th May 2007, 19:00

OK, but if I'm not mistaken, I believe that's the first time you've mentioned requiring specific framerates.

Me, I'd make it 23.976fps (that's what you mean by film, isn't it?), and stretch the audio to do away with the PAL speedup and higher pitched audio. If you want to keep the same audio, then you can do a ChangeFPS(25) after RePAL, which will add one duplicate frame every 1000 frames, or 1 every 40 seconds, to produce a slight stutter which may or may not be noticeable.

ChiDragon

8th May 2007, 22:50

However since I'm dealing with a demuxed DVD source, how would, once you demux the audio track, you get AssumeFPS and avisynth to consider and alter the AC3 file?

I use NicAC3Source, part of NicAudio (check http://avisynth.org/warpenterprises/). You could also use AC3Source or DirectShowSource with an AC3 codec/filter installed. The AC3 wll be decompressed to uncompressed PCM of course.

laserfan

11th May 2007, 14:14

I know this is a Purist thread, in a (mostly) Purist forum, but I'm looking for some simple advice in handling conversions of my HDTV captures to Xvid. I routinely capture ABC TV shows that have been converted by the local affiliate station from the network's original 720p to 1080i, and then sometimes they are also time-compressed. Bottom line is they started life as Film and along the way get messed with--they're mostly 3-2 but then sometimes 3-2-2-2-2-1-3-2-3-2 etc w/no repeating pattern. 95% of the time my conversions look great, or at least "good enough for me" using this:

tfm().tdecimate(hybrid=1)

On rare occasions the above doesn't do quite as good a job as I might've hoped (the 23.976 result is more herky-jerky than I'd like) and I wonder if there is a new-or-better script I can or should use for these captures.

Bear in mind please that I don't want to analyze/count frames for each & every conversion I do--I'm not looking for perfection; I just want to choose a "good enough" method (a compromise) and stick with it if possible. TIA for any advice...

Mug Funky

12th May 2007, 06:33

@ chipzoller:

if something was shot on film for TV in PAL land, the cameras will have been run at 25fps as there is no reason to run them at 24. so i'd assumefps, and be assured the audio pitch will be correct as it was shot at that speed to begin with (and nobody would bother with a timestretch for a 1/1000 difference in speed).

it's possible this episode was either never aired in NTSC land, or a tape could not be found and thus a conversion was done off a PAL master.

laserfan

14th May 2007, 23:35

tfm().tdecimate(hybrid=1)
...is [there] a new-or-better script I can or should use for these captures.Hmmm, I wonder why no one has an opinion about this? I didn't think my question was too off-the-wall?

ChiDragon

15th May 2007, 07:44

laserfan,

EDIT: Nevermind, I tried my suggestion and it doesn't work... your script is the best I can think of, of the solutions that don't require manual intervention.

Atak_Snajpera

15th May 2007, 13:34

TDeint() generates strange artefacts.
Source is 1440x1080i (Canon HV20)
http://www.archive.org/download/jvc_hd7/hv20_05.m2t.mpg

After TDeint() look what happens

http://img524.imageshack.us/img524/3817/tdeintfx5.th.png (http://img524.imageshack.us/my.php?image=tdeintfx5.png)

I've also uploaded sample after conversion to 1280x720 (x264)

http://www.megaupload.com/?d=71Z12QI0

Another example:
Source: http://www.archive.org/download/jvc_hd7/hv20_07.m2t.mpg

Once again strange spots show up
http://img517.imageshack.us/img517/4987/tdeint2cd3.th.png (http://img517.imageshack.us/my.php?image=tdeint2cd3.png)

I used very simple script

LoadPlugin("C:\Users\Dawidos\Documents\Delphi_Projects\RipBot264\Tools\dgindex\DGDecode.dll")
MPEG2Source("c:\TEMP\job1\job1.d2v")

tdeint()
LanczosResize(1280,720)

laserfan

15th May 2007, 17:47

...your script is the best I can think of, of the solutions that don't require manual intervention.Thanks for that--I just had to ask, given the many, many pages of enhancements discussed here, most of which I just don't understand. :(

But thanks for responding! :)

tritical

16th May 2007, 10:26

Almost ready to start working on tivtc/tdeint again. I read back through the last few pages and this is the list of current issues:

tdecimate mode 2 problem non-standard framerates - Xesdeeni/ChiDragon
tdecimate problem with mode 0 decimation - ChiDragon
add tfm hints to tdeint - ChiDragon
tdecimate '+' override - ChiDragon
tdecimate problem with video section decimation in mode 5 (starting in version 0.9.12.7) - Asrial

If there are any other items I've forgotten please let me know :).

JuanC

18th May 2007, 05:59

Well, now that you mention other forgotten items, there's this old request (http://forum.doom9.org/showthread.php?p=821397#post821397), for an exclusion band for Tdecimate. Not really a "current issue" but it will certainly help people like me dealing with 30fps interlaced subtitles blended on top of 24fps hard-telecined material. Thanks ;)

tritical

18th May 2007, 06:40

DarkNite

18th May 2007, 15:03

However, it is on the list of things to add in the tdeint/tivtc rewrite.

Did I miss something, or have you been working on a whole new code base in your secret other life while cackling like a mad scientist who just built two tesla towers with just enough space for an operating table between them? ^_^

tdecimate problem with video section decimation in mode 5 (starting in version 0.9.12.7) - Asrial

Thank you for adding that to your current to do list.

max24

18th May 2007, 17:42

How is one this SOURCE Deinterlacen?
I despair of it :helpful:

Sampler:
http://rapidshare.com/files/31967235/Sampler.m2v.html
http://simpleupload.net/download/88293/Sampler.m2v.html

Thanks for your Help

JarrettH

19th May 2007, 05:02

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

Maybe I should ask this here instead.....

I'm trying to encode Pan's Labyrinth and MeGUI detects it as Partially Film (correct) with Top Field First. What's the difference between choosing TIVTC alone vs TIVTC+TDEINT?

:thanks:

ChiDragon

19th May 2007, 12:28

TFM by default will use PP=6 which is motion-adaptive cubic interpolation on frames detected as combed. TFM+TDeint by default will use TDeint's different motion masking and kernel interpolation instead of cubic.

Maybe you should post of a sample of the unprocessed VOB in a section where you say TIVTC creates jerkiness.

JarrettH

19th May 2007, 15:44

I think I figured it out. So apparently clicking analyze will make a different avs script than if I were to choose Partially Film + Top Field + TIVTC manually.

If I select myself:
tfm(order=1).tdecimate(hybrid=3)

If I click analyze
tfm(order=1).tdecimate(hybrid=1)

:devil:

ChiDragon

19th May 2007, 16:44

hybrid=1 is for mostly film (blends 30p->24p), hybrid=3 is for mostly video (blends 24p->30p).

JarrettH

19th May 2007, 16:55

It definitely did fix it though. The stream is 23.97 fps and looks proper. So TIVTC+TDEINT should produce better quality?

Thanks Chi:)

ChiDragon

19th May 2007, 17:20

@max24, except for 2 shots of the plane in the opening (before and after the kangaroo at the end), that is just plain old easy field shifting. Use "TFM()" or even "TFM(mode=0,PP=0)". The two plane shots mentioned have some duplicated fields which will cause the video to be a bit jerky there, but they're short sequences anyway.

ChiDragon

19th May 2007, 17:25

JarrettH, I believe tritical would agree that TDeint's deinterlacing is superior to what's built into TFM yes.

JarrettH

19th May 2007, 21:57

It probably is, but I was bored and made some captures :devil:

I think this movie only begins to have interlacing problems near the end. Three shots, one TIVTC alone the other TIVTC+TDEINT

If anyone wants to compare:

http://rapidshare.com/files/32249715/TIVTC_and_TDEINT.rar.html

Thanks!

JarrettH

19th May 2007, 22:23

http://img503.imageshack.us/img503/5196/tivtc1px1.png

http://img128.imageshack.us/img128/2616/tivtctdeint1kg5.png

http://img264.imageshack.us/img264/2695/tivtc2qk7.png

http://img503.imageshack.us/img503/2765/tivtctdeint2ue0.png

http://img264.imageshack.us/img264/46/tivtc3hp1.png

http://img264.imageshack.us/img264/4259/tivtctdeint3sh4.png

Top one in each set is TIVTC alone, bottom is TIVTC+TDEINT

foxyshadis

20th May 2007, 00:54

I don't think the TFM clip2 parameter is working as it should. I've been using:

clipt=TDeint(field=1,emask=TMM(field=1),edeint=separatefields.selecteven.eedi2(field=1))
clipb=TDeint(field=0,emask=TMM(field=0),edeint=separatefields.selectodd.eedi2(field=0))
TFM(clip2=clipt,pp=4)

But the frames I get back are exactly the same as with TFM(), and very different from clipt. I haven't had any luck figuring out why.

tritical

20th May 2007, 01:33

@DarkNite
You wouldn't happen to have a clip that results in different mode 5 output (latest version vs. older versions) would you? I've been trying to duplicate the issue but haven't been successful. I pm'd Asrial a couple days ago about getting a clip, but I don't think he visits very often.

@foxyshadis
Thanks for the report. I'll try to duplicate it.

foxyshadis

20th May 2007, 06:58

Never mind, I just didn't understand the docs well enough. I didn't realize that it only uses clip2 for combed frames, so I was checking the wrong frames, but using a much lower cthresh for testing forced it to work. Sorry!

DarkNite

20th May 2007, 12:03

I don't recall exactly what portion of which source it was atm (I have 6 projects going on now), but for you I will attempt to hunt it down in my free time.

tritical

20th May 2007, 23:27

@DarkNite
Thanks, though if you don't remember where it was don't worry about it too much... I'm sure you have better things to do with your free time :).

@All
I have managed to fix the mode 2 problems. The drifting on long sequences that Xesdeeni reported was caused by having a '>' instead of a '>='. The crash ChiDragon reported was caused by a bug in the sorting algorithm that was used for very large cycles (could only happen when using mode 2 with an input file and non-standard framerates). I also made some minor improvements.

I'm still trying to duplicate the mode 5 problem. I've been comparing TIVTC v1.0 RC1 vs v1.0.1 on a few hybrid sources and have yet to see any major differences. Although, I did find a bug in tfm's cubic pping. The handling of the very last line (for field=1) and very first line (for field=0) has been slightly messed up since ~ April, 06.

Terranigma

20th May 2007, 23:36

tritical, any new news on EEDI (http://forum.doom9.org/showthread.php?p=966991#post966991)'s successor? How is it progressing? :cool:

Livesms

21st May 2007, 06:42

tritical

22nd May 2007, 01:08

@Livesms
clipt/clipb are just tdeint deinterlaced versions of the original source... clipt keeping top fields and clipb keeping bottom fields. In both cases TMM() is being used to build the motion mask instead of tdeint's built in motion masking, and eedi2 is being used to interpolate pixels instead of one of tdeint's built in interpolation methods. One of those two clips is then being used by tfm's clip2 parameter (in this example it is clipt). That means that when tfm detects a combed frame combing out of field matching it requests that frame from clipt instead of deinterlacing it itself. When pp is set < 5, the frame from clip 2 will be delivered as is. If pp is >= 5 then tfm will still apply its own motion masking.

@Terranigma
It's doing quite well. I haven't commented on it for a while because I'm planning on using the idea as part of my master's thesis, which means that a public binary is still a ways off.

foxyshadis

22nd May 2007, 20:45

Maaaaaaaaan, that would be nice to see indeed. ;_;

The reason I used two different tdeints, if you're curious, was because I had a filter in between that would swap in frames from the other (a quick hack of fizick's badframes). It was an old VHS capture and had an annoying amount of partially smeared lines that could be mostly fixed by interpolating over the other field. I got sick of finding bad frames pretty quickly, though.

Terranigma

22nd May 2007, 20:51

tritical, thanks for keeping me informed. I can only imagine the possibilities this new filter will be able to achieve (Specifically when it comes to aliasing/deinterlacing). :D

audyovydeo

23rd May 2007, 15:35

@tritical

This is just a word of appreciation as I really like TDeint. I've read around the forums and seen some speed comparisons with other deinterlacers. I dont do comparative testing as it's precious time taken off real encoding.
I find TDeint is a real workhorse : I have two avs scripts each TDeinting two DV_PAL.avi files and layering them, both scripts fed into Adobe Premiere for yet another transparency, and it works like a beauty (on a T5200 cpu). That means very good workload scaling, which to me is more important than absolute speed.

So, for me, every minute you spend on multithread optimization is wecome.

cheers
audyovydeo

zdark

24th May 2007, 17:52

I am having certain lag in slow scenes. If I to use...telecide() for But its filter it is better, I changed setting.

source original: DVD NTSC 720x480
my script for desintrelaced

interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp,type=3)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2)

now its fine?

is for anime Vision of escaflowne

You can say me because she is giving lag?

http://rapidshare.com/files/33066521/teste2.mp4.html

Leak

24th May 2007, 17:59

source original: DVD NTSC 720x480
[...]
interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp,type=3)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2)
Since I very much doubt Escaflowne was animated at 30 FPS - where's your call to TDecimate?

Your current script will result in eveyr fifth frame being a duplicate.

Also, what's the deal with "fansubbing" something that's been released all over the world (at least Japan, America, Canada, UK, Germany and France) for years? :mad:

np: Legiac - Dide Skin (Mings Feaner)

zdark

24th May 2007, 18:19

I taste of you liven up old. I go to test adding the TDecimate!

zdark

24th May 2007, 20:41

leak my test.

no filter: http://rapidshare.com/files/33178778/escaflowne_no_filter.mp4.html
filtered: http://rapidshare.com/files/33175940/escaflowne_filter.mp4.html

now its fixed.

I used

edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
deinted = TDeint(order=1,edeint=edeintted)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2).tdecimate(hybrid=3)

thanks for help!

DarkNite

25th May 2007, 20:04

Also, what's the deal with "fansubbing" something that's been released all over the world (at least Japan, America, Canada, UK, Germany and France) for years?

Well, it may be that the translation was weak and erroneous (if it's anything like the English translation) or that it may not be available in his native language.

Or, it may just be that karaoke scripts are indeed that important to some people. :)

tritical

25th May 2007, 23:00

Haven't been able to reproduce the mode 5 problem, so I'm just gonna go ahead and release a new version with the fixes so far. [link removed], changes:
tdecimate:
- Lots of fixes for mode 2 and non-standard framerates
- Fixed problem in mode 0 decimation when using tfm hints and looking for
singleton match duplicates

tfm:
- Fixed incorrect handling of the top/bottom lines in cubic post-processing

Terranigma

25th May 2007, 23:26

You know the drill ;) :goodpost:

zdark

26th May 2007, 07:23

tritical thanks, good job!

plugh

26th May 2007, 19:41

An exclusion band in tdecimate could be accomplished by using the clip2 parameter:

mpeg2source()
tfm()
saved = last
stackvertical(crop(),crop()) # set crops to remove lines containing subtitles
tdecimate(clip2 = saved)

In this case, tdecimate will calculate everything based on the input clip, but will output frames from clip2. The clip2 clip only has to have the same number of frames as the input. All other properties: height, width, and colorspace can be different. You could replace cropping/stackvertical with another method of removing the subtitles (set the subtitle area to black using overlay, etc...)..

If I may inject a question:

In a thread in the avisynth usage forum, I'm trying to use tdecimate on an animated film that was sped up slightly for broadcast. One of the problems I'm having is (I believe) related to vertical film jitter; the animation has its own dups, but frame to frame film jitter means they don't always align perfectly leading to higher difference metrics.

How can I get the dup matching code to search up/down a few lines to find the min difference metric? That is, given current frame "C" and previous frame "P" calc metrics between

lines C 1 thru N vs lines P 1 thru N as usual,
but also
lines C 1 thru N-1 vs lines P 2 thru N
lines C 1 thru N-2 vs lines P 3 thru N
and
lines C 2 thru N vs lines P 1 thru N-1
lines C 3 thru N vs lines P 1 thru N-2

and use the min metric for the dup check.

BTW, I also encountered a mode 2 rate dependant accvio with this movie. I see your latest version addresses this - I'll give it a whirl.

Thanks!

ChiDragon

26th May 2007, 20:21

plugh, I don't get why you'd want it to detect these animation duplicates as dups and decimate them. If anything the higher metrics caused by the jitter should help you only remove the telecine dups.

plugh

27th May 2007, 01:19

The jitter isn't consistent. Sometimes it is there, sometimes it isn't. If they aren't detected as dups, then it seems as though mode 1 can't properly apply 'longest run' (and with 720p source at 60fps, there are long runs of dups).

Thank you for your interest. Do you have a suggestion on how to do this type of matching? I was reading about the FrameDiff function, and the post I quoted gave me the idea that there might be some way to tackle this. But 1) I'm not proficient at avisynth scripting, and 2) perhaps tcritical knows some trick in his code that will do this (or could)...

Thanks again.

plugh

28th May 2007, 18:58

In an effort to understand and verify the impact of the film jitter on the dup matching, after much RTFMing and experiments I came up with the following (probably horribly inefficient) script which uses tcriticals' CFrameDiff function to evaluate the current frame against vertically offset previous framessep=" "
file = "i:\work5\dupinfo.log"
c=mpeg2source("lk1.d2v",cpu=0)
c=converttoyuy2(c)
c=WriteFile(c, file, "current_frame","sep","u2","sep","u1","sep","at","sep","d1","sep","d2")
c=FrameEvaluate(c, "crop(0,0,0,-4).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global u2 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,1,0,-3).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global u1 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,2,0,-2).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global at = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,3,0,-1).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global d1 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,4,0, 0).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global d2 = CFrameDiff(norm=true)")
return(c)

which I ran on the opening sequence of my 'problem' film. The opening consists of a black background and red stationary letters which fade in and back out (no scroll, pan, or zoom). The following (editted for formatting) is a portion of the script output, which clearly shows the jitter and it's impact on the dup metric (middle column is the non-shifted metric) 29 17.001106 9.122610 0.000000 9.624715 18.472639
30 17.005119 9.123948 0.305900 9.626945 18.470409
31 8.893853 1.430508 9.107002 17.618704 25.334885
32 16.609142 8.854167 0.000000 9.027629 17.556274
33 16.600225 8.830979 0.531535 9.004441 17.549141
34 23.565033 16.905233 9.010684 0.497200 9.523937
35 16.892748 9.003550 0.366991 9.539098 18.390589
36 16.899437 9.008454 0.141356 9.540436 18.392818
37 16.897207 9.009792 0.472674 9.546233 18.392372
38 16.891855 9.009792 0.520387 9.545341 18.389698
39 16.891855 9.009792 0.131100 9.545341 18.389698
40 16.891855 9.009792 0.663973 9.545341 18.389698
41 16.891855 9.009792 0.051727 9.545341 18.389698
42 16.891855 9.009792 0.223851 9.545341 18.389698
43 16.885612 9.008009 0.367437 9.543557 18.387022
44 16.882936 9.002658 0.085616 9.538206 18.380779
45 8.827412 0.139127 9.002658 17.533087 25.325075
46 16.597103 8.827412 0.140910 9.002658 17.533087
47 23.467377 16.760756 8.859072 1.454142 9.607770
48 16.890518 8.935324 0.127087 9.490047 18.414669
49 16.896315 8.933540 0.127087 9.491831 18.411993
50 16.896315 8.937553 0.059307 9.493169 18.415115
51 16.896315 8.937553 0.057078 9.493169 18.415115
52 16.896315 8.937553 0.021404 9.493169 18.415115
53 16.896315 8.937553 0.000000 9.493169 18.415115
54 16.896315 8.937553 0.000000 9.493169 18.415115
55 16.896315 8.937553 0.000000 9.493169 18.415115
56 16.896315 8.937553 0.000000 9.493169 18.415115
57 16.896315 8.937553 0.000000 9.493169 18.415115
58 16.890518 8.932649 0.296982 9.484696 18.396832
59 16.884722 8.934878 0.000000 9.488709 18.390144
60 16.884722 8.934878 0.074468 9.488709 18.390144
61 8.926851 1.258383 8.865761 17.437660 25.249269
62 16.601563 8.854167 0.000000 9.027629 17.555384
63 16.602455 8.850599 0.572114 9.026737 17.558950
64 23.569492 16.901220 9.017373 0.302779 9.555597
65 16.890965 9.003996 0.000000 9.546233 18.386129
66 16.886505 9.003103 0.074914 9.553368 18.386129
67 16.890965 9.006671 0.117277 9.542665 18.381670
68 16.890965 8.997752 0.000000 9.539990 18.386129
69 16.890965 8.997752 0.111034 9.539990 18.386129
70 16.886505 8.991509 0.084725 9.534639 18.384346
71 16.888288 8.987943 0.000000 9.530180 18.383455
72 16.888288 8.987943 0.049051 9.530180 18.383455
73 16.885612 8.992401 0.070009 9.535531 18.382563
74 16.888288 8.997752 0.000000 9.539990 18.383455
75 16.888288 8.997752 0.041025 9.539990 18.383455
76 16.890072 8.997752 0.058861 9.544449 18.384346
77 16.890965 9.002212 0.000000 9.544449 18.386129
78 16.890965 9.002212 0.028093 9.544449 18.386129
79 8.972335 1.400185 8.910353 17.450592 25.309467
80 16.681828 8.883597 0.000000 9.057952 17.646797
81 16.678707 8.892962 0.112372 9.062857 17.645458
82 23.489672 16.706354 8.810467 1.412225 9.757599
83 16.869560 8.952269 0.000000 9.469089 18.372753
84 16.852169 8.947364 0.178814 9.475778 18.369631
85 16.857965 8.955836 0.325967 9.457495 18.347780
86 16.857965 8.949594 0.000000 9.466413 18.361158
87 16.859749 8.951377 0.114155 9.468197 18.357592
88 16.868668 8.949594 0.233216 9.461954 18.372753
89 16.867777 8.948702 0.000000 9.465522 18.370970
90 16.867777 8.948702 0.101224 9.465522 18.370970
91 16.933773 9.023616 0.807559 9.457495 18.341537
92 8.798427 0.397314 8.938891 17.521938 25.271564
93 16.578375 8.795752 0.345141 8.941566 17.532640
94 23.573059 16.888288 8.977241 0.266660 9.506992
95 16.885612 8.963417 0.000000 9.511451 18.387468
96 16.883829 8.962525 0.047267 9.510559 18.385685
97 16.883383 8.960296 0.131992 9.506546 18.389698
98 16.889181 8.962525 0.000000 9.510559 18.391035
99 16.889181 8.962525 0.049943 9.510559 18.391035
100 16.890965 8.964309 0.083387 9.515018 18.391928
101 16.891855 8.968768 0.000000 9.516802 18.393711
102 16.891855 8.968768 0.019620 9.516802 18.393711
103 16.893639 8.972335 0.060645 9.520370 18.393711
104 16.893639 8.973228 0.000000 9.521261 18.395494
105 16.893639 8.973228 0.037457 9.521261 18.395494
106 8.951823 1.404199 8.871112 17.413136 25.279591
107 16.641695 8.820277 0.000000 8.976794 17.601313
108 16.645262 8.826520 0.063320 8.980362 17.606665
109 16.646601 8.822061 0.104345 8.983037 17.607109
110 23.477633 16.704124 8.805116 1.358269 9.680009
111 16.858858 8.943796 0.155180 9.464184 18.346889
112 16.864208 8.942904 0.277808 9.463292 18.343323
113 16.860195 8.941566 0.000000 9.461954 18.345552
114 16.860195 8.941566 0.182381 9.461954 18.345552
115 16.860195 8.941566 0.285834 9.461954 18.345552
116 16.860195 8.941566 0.000000 9.461954 18.345552
117 16.860195 8.941566 0.111926 9.461954 18.345552
118 16.858412 8.940675 0.073131 9.457495 18.341093
119 16.855736 8.938000 0.000000 9.458386 18.341093
120 16.855736 8.938000 0.050389 9.458386 18.341093
121 16.904787 8.992401 0.869988 9.332638 18.212667
122 16.764769 8.830087 0.000000 9.356717 18.253693
123 16.754066 8.819385 0.838328 9.339772 18.286690
124 16.777700 8.822952 0.162315 9.373662 18.305418
125 16.782606 8.844802 0.000000 9.385702 18.307648
126 16.782606 8.844802 0.045484 9.385702 18.307648
127 16.781713 8.847478 0.109696 9.397296 18.315676
128 16.791525 8.852829 0.000000 9.396404 18.318350
129 16.807577 8.865314 0.045484 9.397296 18.314783
130 8.812250 1.475546 8.881814 17.469320 25.242580
131 16.695652 8.853721 0.000000 9.028075 17.658836
132 16.694759 8.857288 0.221622 9.021832 17.658836
133 16.691193 8.849261 0.185948 9.030750 17.663296
134 16.695652 8.853721 0.000000 9.028075 17.658836
135 23.490564 16.802671 8.834546 1.364066 9.674212
136 16.913260 8.971443 0.074023 9.495399 18.441423
137 16.913260 8.971443 0.000000 9.495399 18.441423
138 16.913260 8.971443 0.035674 9.495399 18.441423
139 16.916826 8.966092 0.177030 9.486480 18.437857
140 16.911476 8.966092 0.000000 9.490939 18.437857
141 16.913260 8.963417 0.049943 9.490047 18.437857
142 16.908800 8.965200 0.109250 9.492723 18.440533
143 16.907909 8.966092 0.000000 9.490939 18.434290
144 16.907909 8.966092 0.075806 9.490939 18.434290
145 16.909246 8.967430 0.075806 9.491385 18.431168
146 16.907017 8.966092 0.000000 9.489155 18.429831
147 16.907017 8.966092 0.028539 9.489155 18.429831
148 16.907017 8.966092 0.020512 9.489155 18.429831
149 16.907017 8.966092 0.000000 9.489155 18.429831
150 16.907017 8.966092 0.034782 9.489155 18.429831
151 16.907017 8.966092 0.818261 9.489155 18.429831
152 8.831425 1.478221 8.898759 17.474672 25.225636
153 16.578821 8.812250 0.465985 8.980807 17.546465
154 16.578375 8.816263 0.243918 8.975456 17.537546
155 23.445526 16.752729 8.821169 1.395280 9.590825
156 16.902557 8.950485 0.075360 9.480682 18.391481
157 16.903450 8.951377 0.155626 9.480682 18.391481
158 16.900774 8.948702 0.000000 9.478899 18.390589
159 16.899881 8.948702 0.101670 9.478007 18.389698
160 16.899881 8.947809 0.071347 9.478007 18.389698
161 16.899881 8.947809 0.000000 9.478007 18.389698
162 16.899881 8.947809 0.028093 9.478007 18.389698
163 16.899881 8.947809 0.061091 9.478007 18.389698
164 16.899881 8.947809 0.000000 9.478007 18.389698
165 16.899881 8.947809 0.026755 9.478007 18.389698
166 16.897654 8.942904 0.132884 9.467752 18.384792
167 16.889181 8.935324 0.000000 9.465522 18.378996
168 16.889181 8.935324 0.063320 9.465522 18.378996
169 16.897207 8.949594 0.308130 9.445901 18.353132
170 16.887842 8.925068 0.000000 9.452144 18.378103
171 8.778360 0.121290 8.932649 17.531303 25.325521
172 16.603792 8.785941 0.099440 8.922392 17.517481
173 23.601599 16.879816 8.924176 0.089184 9.446793
174 16.881599 8.922392 0.089184 9.449469 18.371861
175 16.880262 8.926406 0.065104 9.448131 18.375874
176 16.884275 8.926851 0.000000 9.453928 18.374537
177 16.886505 8.926406 0.070901 9.454373 18.374983
178 16.886951 8.926851 0.035228 9.453928 18.377213
179 16.886951 8.926851 0.000000 9.453928 18.377213
180 16.886951 8.926851 0.021404 9.453928 18.377213
181 16.894531 8.980807 1.240992 9.342002 18.245667
182 16.768335 8.822061 0.000000 9.369649 18.282677
183 16.808023 8.876908 0.541791 9.366528 18.268854
184 16.777700 8.829641 0.197096 9.382581 18.296501
185 8.801994 1.439872 8.876908 17.434093 25.210920
186 16.674248 8.835884 0.132884 9.004441 17.635649
187 16.678707 8.834101 0.102115 9.007117 17.632973
188 23.485214 16.761648 8.834101 1.318136 9.659050
189 16.888735 8.941121 0.072685 9.481575 18.413332
190 16.893194 8.952715 0.061091 9.473548 18.407089
191 16.886951 8.944688 0.000000 9.479791 18.412439
192 16.886059 8.942904 0.042808 9.479791 18.410656
193 16.886505 8.945134 0.152504 9.472210 18.407534
194 16.882492 8.941121 0.000000 9.475331 18.405304
195 16.879816 8.938445 0.092751 9.475331 18.404413
196 16.879816 8.938445 0.105683 9.473548 18.405304
197 16.879816 8.938445 0.000000 9.473548 18.405304
198 16.879816 8.938445 0.054402 9.473548 18.405304
199 16.879816 8.938445 0.042808 9.473548 18.405304
200 16.879816 8.938445 0.000000 9.473548 18.405304
201 16.879816 8.938445 0.021404 9.473548 18.405304
202 8.798427 0.161869 8.917933 17.520155 25.292522
203 23.536940 16.863317 8.924176 0.157855 9.488709
204 16.878923 8.942013 0.034782 9.477116 18.404413
205 16.878923 8.942013 0.034782 9.477116 18.404413
206 16.878923 8.942013 0.000000 9.477116 18.404413
207 16.878923 8.942013 0.028539 9.477116 18.404413
208 16.879370 8.942458 0.028539 9.477561 18.403967
209 16.879370 8.942904 0.000000 9.478454 18.403521
210 16.878923 8.942458 0.018729 9.478007 18.403967
211 16.865992 8.942458 0.513253 9.470427 18.378103
212 16.839684 8.918379 0.000000 9.456158 18.359821
213 16.872681 8.943351 0.648366 9.388377 18.300068
214 16.797321 8.855059 0.108804 9.396404 18.313000
215 16.792416 8.867990 0.000000 9.406660 18.310770
216 16.792416 8.867990 0.047713 9.406660 18.310770
217 16.798658 8.871557 0.253728 9.408443 18.316120
218 16.804010 8.873342 0.000000 9.412011 18.322363
219 8.829195 1.440764 8.871112 17.425175 25.205568
220 16.671572 8.841681 0.329088 9.001766 17.619595
221 16.662207 8.830533 0.000000 8.995077 17.610231
222 16.664883 8.830533 0.135559 8.995969 17.612907
223 23.627907 16.955622 8.971443 0.342466 9.528842
224 16.968554 8.987050 0.000000 9.507884 18.472193
225 16.972120 8.989726 0.105237 9.506100 18.470409
226 16.966770 8.976349 0.125303 9.508776 18.480219
227 16.965878 8.989726 0.000000 9.510559 18.469517
228 16.965878 8.989726 0.050835 9.510559 18.469517
229 16.964987 8.990618 0.151167 9.512343 18.470409
230 16.965878 8.987943 0.000000 9.508776 18.469517
231 16.965878 8.987943 0.034782 9.508776 18.469517
232 16.965878 8.987943 0.051727 9.508776 18.469517
233 16.965878 8.987943 0.000000 9.508776 18.469517
234 16.965878 8.987943 0.025863 9.508776 18.469517
235 16.965878 8.987943 0.047713 9.508776 18.469517
236 16.965878 8.987943 0.000000 9.508776 18.469517
237 16.965878 8.987943 0.018729 9.508776 18.469517
238 16.964987 8.987050 0.168557 9.511451 18.466841
239 8.920609 1.451020 8.909461 17.604879 25.417826
240 16.713488 8.907231 0.101670 9.061519 17.660173
241 16.715271 8.906340 0.717484 9.063303 17.657499
242 23.522671 16.802671 8.948702 1.434075 9.559610
243 16.783052 8.868436 0.312589 9.417362 18.320580
244 16.791969 8.863976 0.120398 9.406660 18.302744
245 16.789295 8.872004 0.000000 9.411119 18.308094

plugh

2nd June 2007, 01:49

buglet report:

In the process of working with CFrameDiff, I discovered the following:

As expected, (mode=0,norm=false) and (mode=1,norm=false) return radically differant values.
However, (mode=0,norm=true) and (mode=1,norm=true) give IDENTICAL results.

Appears you can't get the normalized 'mode=min' values.

And FWIW, building upon my previous post, I put together a 'vertical jitter correction' script, which I have posted in the other forum here (http://forum.doom9.org/showthread.php?p=1009932#post1009932)

WorBry

6th June 2007, 07:56

I actually find the idea behind yadif quite interesting, but the major drawback IMO is the edi method it is uses is overly prone to artifacts. It uses the typical two sliding window method which is highly likely to choose the wrong direction around anything more than a single, thick, lone edge. Every other filter/program that I know of that uses this method caps the output value to be within +-2 or 3 of the min/max of the vertical neighbors to prevent major artifacts. Just to see what would happen, I created a c only version with such capping and to me it looked much better. I also made it possible to take spatial predictions from an external clip. I have some results here: deinterlace_comparison.txt (http://bengal.missouri.edu/~kes25c/deinterlace_comparison.txt) from a comparison I am working on, which I think show the benefits.

Hi Tritical,

The metrics obtained with your modified version of Yadif are very interesting.

Is it possible that the potential interpolation errors introduced by not 'capping' the output might explain the 'vertical jittering' (shimmering) that Yadif seems (by my observation at least) quite susceptible to, or is that a quite different phenomenon?

http://forum.doom9.org/showthread.php?p=1010873#post1010873

tritical

6th June 2007, 10:15

@plugh
Yep, it is indeed a bug (actually a missing return statement). As for using the minimum of metrics calculated with different vertical offsets, the method you came up with is probably the simplest. There isn't an easy way to modify tdecimate to do this internally.

@WorBry
Is it possible that the potential interpolation errors introduced by not 'capping' the output might explain the 'vertical jittering' (shimmering) that Yadif seems (by my observation at least) quite susceptible to, or is that a quite different phenomenon?
I think they are slightly different. The artifacts I'm talking about stem from running yadif's type of edi interpolation on something like:

006 202 004 200 004 199 004
o
003 200 005 204 005 198 003

which is an extreme case. However, it would choose to replace 'o' with 4, while it should simply use vertical interpolation. This causes problems mainly around fine lines and details (thick edges are usually fine).

Could you describe more what you mean by 'vertical jittering' or 'vertical shimmering'. I think I know what you are talking about but just want to be sure before writing a lengthy reply :p.

WorBry

6th June 2007, 13:30

Could you describe more what you mean by 'vertical jittering' or 'vertical shimmering'. I think I know what you are talking about but just want to be sure before writing a lengthy reply :p.

Sure. I'm referring to a slight jumping up and down ('over-bobbing' you might say) of relatively static objects from frame to frame, resulting in a vertical jitter or shimmering type effect. Most noticable with fine detail - patterns, lettering etc.

There are good examples in the src reference clips that you have been using in your comparison tests, for example the pattern on the shirt of the piano player in the 'Musicians' Clip' and in the 'Toy Train' clip, the sheep on the wall-paper and the dates on the calender.

I'm also posting a short home DV clip that shows the effect quite well

http://rapidshare.com/files/35553085/Shimmer_example_PAL_DV_Type_II.avi

If you run it through Yadif (Mode=1, Order=0) you'll note the marked 'shimmering' of the toy car mat. With MCBob, it is effectively 'calmed-down'.

plugh

6th June 2007, 14:30

the method you came up with is probably the simplest. There isn't an easy way to modify tdecimate to do this internally.
OK, thanks.

The mode4 / mode2 combo with the de-jittered stream has produced the best decimation results so far, but it still isn't quite right. I *have* identified the telecining pattern used in this 720p broadcast - 576 film frames into 1409 video frames, which works out to 59.94*(576/1409) = 24.503506032, which yeilds
rate = 24.503506 actual rate = 24.503515
mode2_num = 1 mode2_den = 2 numCycles = -20 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 99792
or (60000/1001)*(576/1409) = 24.503530536, which yeilds
TDecimate: mode 2 error, number of frames after decimation doesn't match!
Specifically - the dup counts are
212121212121212121 45->18
112121212121212121 44->18
112121212121212121 44->18
202121212121212121 44->18
202121212121212121 44->18
211121212121212121 44->18
211121212121212121 44->18
212021212121212121 44->18
212111212121212121 44->18
212111212121212121 44->18
212120212121212121 44->18
212121112121212121 44->18
212121112121212121 44->18
212121112121212121 44->18
212121202121212121 44->18
212121211121212121 44->18
212121211121212121 44->18
212121212021212121 44->18
212121212111212121 44->18
212121212111212121 44->18
212121212120212121 44->18
212121212120212121 44->18
212121212121112121 44->18
212121212121112121 44->18
212121212121202121 44->18
212121212121211121 44->18
212121212121211121 44->18
212121212121212021 44->18
212121212121212021 44->18
212121212121212111 44->18
212121212121212111 44->18
212121212121212120 44->18
The most notable 'feature' of the resulting decimation (using 24.503506032) is that sometimes tdecimate eliminates three frames in a row (you can see runs of three telecine dups never occur in the above pattern) and thus ends up including dups elsewhere (see attached images - you can clearly see where dups are getting through). Thus, screen motion is jerky in places.

So my question is, how can I get this 'right', short of hand crafting an ovr file? Are the decimation cycles being derived by mode2 not quite correct? Is there any way to tell it 'max dup length=2' (if that would help)? Or am I doing something fundamentally wrong :confused:

Thanks in advance

tritical

6th June 2007, 15:56

@plugh
Could you post the metrics file? Or just send it to my ftp:

12.216.251.99:17262
upload/upload

tritical

6th June 2007, 16:32

@WorBry
Here are my results on the clip you posted:

yadif_test.zip (http://bengal.missouri.edu/~kes25c/yadif_test.zip)

The four clips included are:

yadif-type0 - same as yadif(mode=1,order=0)
yadif-type1 - w/ capped edi
yadif-edeint0 - w/ tdeint's temporally switched kernel interpolation for spatial prediction
yadif-edeint1 - w/ eedi2 for spatial prediction

plugh

6th June 2007, 17:55

@plugh
Could you post the metrics file? Or just send it to my ftp:

You got it - lk2-try5-tdout.txt
...

So, I thought I'd try something simpler...

Noting the basic blocks of 44 pattern, I decided to try to eliminate just the '2's - ie remove 8 from 44.

Thus:
tdecimate(mode=1,cycleR=8,cycle=44,sdlim=-2,hint=false,blockx=64,blocky=64,nt=1,input=base+tag+"-tdout.txt",batch=true,debug=true)

No joy. For example
TDecimate: 2376: 6.07 0.14 0.10 11.20 0.34 20.93 0.83 23.67 0.15 23.06 0.82 0.13 20.12 0.44 17.25 0.15 0.08 20.86 0.15 18.62 0.14 0.15 27.64 0.34 25.47 0.81 0.39 26.08 0.51 31.60 0.81 0.08 30.27 0.28 25.64 0.19 0.22 16.07 0.41 20.31 0.12 0.30 29.53 0.50
TDecimate: 2376: 0 1 1 0 1 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
TDecimate: 2376: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 2420: 28.05 0.44 0.19 30.24 1.34 29.10 0.21 25.14 0.66 19.43 0.36 0.06 20.21 0.14 39.44 0.20 0.17 59.02 0.17 54.47 0.06 0.23 56.35 0.87 32.10 0.21 0.08 31.95 0.22 36.14 0.18 0.32 38.80 0.36 54.67 0.12 0.39 57.76 0.49 54.34 0.51 0.51 58.11 0.49
TDecimate: 2420: 0 1 1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
TDecimate: 2420: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 2464: 0.49 0.12 0.13 50.22 0.12 1.44 0.02 0.05 3.34 1.04 0.07 0.10 3.36 0.05 0.13 0.03 0.05 3.41 0.74 1.42 0.07 0.03 3.03 0.17 1.15 0.06 0.26 3.27 0.19 1.30 0.02 0.04 2.93 0.06 1.30 0.10 0.04 3.01 0.13 1.08 0.05 0.04 2.92 0.06
TDecimate: 2464: 1 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 1 1 1 0 1
TDecimate: 2464: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 1980: Dropping Frames: 2422 2431 2436 2440 2446 2450 2455 2463
to do what I wanted, it should have dropped 2461, not 2463

I'm guessing it got confused by 2462 being followed by 4 dups - a telecine dup, a FILM dup, then two telecine dups.
But that is why I specified sdlim. Oh, sdlim only kicks in for mode1 if not enough dups found.
Uh, wouldn't it make more sense for it to kick in if too many dups are found, so it could enforce a spacing?

EDIT: hmmm. no, this really needs pattern guidance.
Note the seventh and eighth lines in the pattern above
211121212121212121 44->18
212021212121212121 44->18
Here is my breakdown of the above debug output
TDecimate: 2420: 0 1 1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
F d d F d F d F d F d d F d F d d F d F d d F d F d d F d F d d F d F d d F d F d d F d
2 1 1 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1

TDecimate: 2464: 1 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 1 1 1 0 1
D d d F d D d d F D d d F d D d d F d D d d F d D d d F d D d d F d D d d F d D d d F d
2 1 2 0 2 1 2 1 2 1 2 1 2 1 2 1 2 1
('F' is Film, 'D' is film dup, and 'd' is telecine dup)
threshhold dup longest run based algo, even with a full blown sdlim constraint probably can't cope with those film dups on top of the telecine dups.

EDIT (again): OOPS - it is '8 out of 44' only in the blocks with '111' in the pattern. All others have 9 dup pairs. Back to the drawing board...

plugh

6th June 2007, 22:33

a stream of consciousness / thought experiment...
-----------------------------------------------------
Given a telecine pattern input, and a set of frame metrics:

assume pattern is expressed as say, 0,1,1,0,... (0=frame, 1=dup)

convert metrics to pattern form using threshold test
(eg less than threshold = -1, more = 0)

pattern match

pat_end = pat_lng-1
for i = 0 to pat_end
for j= 0 to pat_end
correlation(i)= pattern( mod( i+j, pat_lng) ) + metric(j)

This tests every possible rotation of the pattern against the metric.
A perfectly aligned match would give a correlation value of zero.

hmmm. but so would an 'off by one' alignment
pattern = 1 0 1 0 1 0
metric = 0-1 0-1 0-1

perhaps metric should be tri-state (like mode7)
-1 = definite dup, 1 = definite non-dup, 0 = indeterminate?

then pattern is expressed same way
-1 = dup, 1 = non-dup (no zeroes?)

[perhaps 'pattern zeroes' allows fuzziness later?]
[[hmmm... 'fuzzy logic' & pattern matching - where is that text from school?]]

[thoughts -
other choices of 1/0/-1 mapping?
choice of correlation computation? (SAD? SSD?, stats 'correlation coefficient'?)
perhaps binary representation and XOR? ]

Continuing---

With 'best' correlation established, and rotation of pattern aligned,
start decimation process, 'rolling' the pattern along the input.

hmmm. What about pattern breaks? (commercial edits, etc)?

OK, instead of simply rolling the pattern along the input,
at each frame you find the 'best' correlation.

If there was no pattern break, the current rotation should
provide the best correlation.

Yuck - but as you approach the break from upstream, your current 'correct'
rotation of the pattern produces increasingly worse correlation.

So we need a way to recognize discontinuities: hmmm -

-Behind the discontinuity, for the preceding pat_len frames,
we are 'highly' correlated with the 'old' pattern alignment.
-In front of the discontinuity, for the following pat_len frames,
we are 'highly' correlated with the 'new' pattern alignment.
-The discontinuity causes a decrease in correlation as you
approach it (from either side) with a given pattern alignment.
-As you approach the discontinuity, NO (?) pattern alignment will
give a 'good' correlation (what is 'good'?)

Hmmm. perhaps a 'lookahead'?

Given a correlated pattern alignment at frame/metric(n),
ie pattern matches metric(n) through metric(n+pat_lng)
at each frame we check the current alignment against
metric(n + pat_lng) through metric(n +pat_lng +pat_lng)

ie Does the current pattern alignment correlate for two cycles?

If it matches metric n thru n+pat_lng but not n+pat_lng thru n+2*patlng
you have found a discontinuity / pattern break . You need to re-sync
the pattern alignment when you get to that point !

SO - the algo becomes

at the start, you align / correlate pattern to metric.

At each frame, you check to see if the current alignment is
still 'best choice' one full cycle ahead of your current position.

If so, you continue rolling the pattern along the frames.

If not, you finish the current cycle up to the discontinuity,
and start over with new 'best choice' at the new position.

Cool! I think that would work!

Requires input of guidance pattern,
and ability to look ahead two full cycles.

Just leaves choice of 'pattern matching' / correlation algo TBD

Where is that fuzzy logic textbook?
Should also review the stats textbook.
The key is the pattern matcher!!!

plugh

7th June 2007, 16:34

576 film frames into 1409 video frames, which works out to 59.94*(576/1409) = 24.503506032, which yeildsrate = 24.503506 actual rate = 24.503515
mode2_num = 1 mode2_den = 2 numCycles = -20 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 99792
or (60000/1001)*(576/1409) = 24.503530536, which yeilds TDecimate: mode 2 error, number of frames after decimation doesn't match!

I trim()'d a few frames off the end, deleted the same number from end of metrics file, and second case now yeildsdrop count = 174539 expected = 174539
rate = 24.503531 actual rate = 24.503535
mode2_num = 1 mode2_den = 2 numCycles = 24603 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 103356

Which is interesting in several ways.

1) That's how to 'fix' that error condition

2) numCycles is a positive number this time (?)

3) an extra line of debug output that wasn't present before

Seems obvious to me now, but the correct way to calculate the tdecimate target frame rate is in terms of the rate passed in from mpeg2source - in this case 60000/1001 = 59.94005994...

Don't expect it will make a big difference, but we'll see...

plugh

8th June 2007, 17:14

I noticed some puzzling results from a script that uses cframediff.

Dug into it, and eventually distilled it down to the following which illustrates the behaviour.

Version().converttoyuy2()

frameevaluate("NOP()")

Writefile("avstst1.txt"\
, "((current_frame==3) && (cframediff(prevf=false) >= 0))"\
, "current_frame"\
)

This generates the following output:
false0
false1
false2
true4
false4
false5
false6
false7

If prevf is set true, you get correct output (ie 'true3').
If the frameevaluate is deleted, you get correct output.

a cframediff buglet?
avisynth weirdness??
stupidity on my part???

Is this cosmetic, or is something getting fundamentally borked?

My application script uses both prevf=true and prevf=false, uses writefileIF rather than writefile, and has a number of scriptclips rather than the frameevaluate. It also has a fair number of references to 'current_frame' other than in the output statement.

I am using avisynth 2.5.6 and tivtc 1.0.2

EDIT: Oh yeah, forgot to ask...

When I look at the debug output of, for example, tdecimate(mode=0), part of the display are some number that I assume are 'normalized framediff metrics'. I also assume that the results from cframediff should be the same as those.

They are not. With identical args (blockx, blocky, chroma, nt) I get somewhat similar, but not identical results.

Are one of my assumptions incorrect?

For example:
TDecimate: 968: 0.02 0.03 0.03 0.01 2.54 0.04 0.09 0.04 1.09 0.08 0.12 0.09 0.02 2.55 0.00 0.03 0.14 0.01 0.76 0.08 0.00 0.08 0.05 1.46 0.02 0.03 0.06 0.01 0.62 0.00 0.02 0.12 0.01 2.71 0.05 0.01 0.16 0.05 1.56 0.03 0.04 0.16 0.01 1.77
TDecimate: 968: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 792: Dropping Frames: 969 974 978 983 987 993 997 1003
output from a script (related to above) -
first value is prevf=true, second is prevf=false
(I think; as you can see 'true' output is borked,
so I'm not sure what I'm *really* getting, but
the first column is similar to the above)
true969 - 0.137566 0.115047
false969 - 0.137566 0.115047
false970 - 0.115047 0.063989
false971 - 0.063989 2.397595
false972 - 2.397595 0.086843
true974 - 0.208690 0.134556
false974 - 0.208690 0.134556
false975 - 0.134556 1.227280
false976 - 1.227280 0.184499
false977 - 0.184499 0.239236
true979 - 0.178479 0.062206
false979 - 0.178479 0.062206
false980 - 0.062206 2.563254
false981 - 2.563254 0.001561
false982 - 0.001561 0.115493
true984 - 0.266325 0.045261
false984 - 0.266325 0.045261
false985 - 0.045261 0.952706
false986 - 0.952706 0.173351
false987 - 0.173351 0.000000
true989 - 0.185837 0.134333
false989 - 0.185837 0.134333
false990 - 0.134333 1.654136
false991 - 1.654136 0.104568
false992 - 0.104568 0.128536
true994 - 0.180597 0.069563
false994 - 0.180597 0.069563
false995 - 0.069563 0.793401
false996 - 0.793401 0.000000
false997 - 0.000000 0.088180
true999 - 0.270673 0.060756
false999 - 0.270673 0.060756
false1000 - 0.060756 3.016084
false1001 - 3.016084 0.183273
false1002 - 0.183273 0.029654
true1004 - 0.237340 0.162092
false1004 - 0.237340 0.162092
false1005 - 0.162092 1.813664
false1006 - 1.813664 0.117277
false1007 - 0.117277 0.149383
true1009 - 0.245924 0.060756
false1009 - 0.245924 0.060756
false1010 - 0.060756 2.123355
false1011 - 2.123355 0.041470
false1012 - 0.041470 0.095538

dude051

10th June 2007, 08:40

I got a few questions about the two pass vfr function of TIVTC, and have searched the entire day but found no concrete answers. I am interested in how the vfr function exactly outputs its frames, I am used to Decomb512VFR so bare with me on this. My source is an anime DVD just for reference.

I realize that in using the two pass method, it makes the video seekable by use of the metric files, and the output uses non-padded frames at a cfr output (24fps?). When using the timecodes file this adapts the framerate of the listed frame ranges (correct if I am wrong please) to, in my case, either 23.976024(FILM) or 17.982018(?) with 29.970030(VIDEO) as the rest. This is what creates the variableness of vfr?

My question though is does the process actually remove or insert any frames? I was under the assumption that the process worked mainly by removing frames and using the timecode file to change the frame rate of the range of frames that were removed to make it run at full speed in each cycle. I've noticed that when I have always run Decomb512VFR that the output video was always shorter, and I noticed the parts that sped up from the resulting missing frames. In my source this results in a video with 33474 frames at 18:36.

But when I ran TIVTC's vfr, the resulting number of frames was shorter but also 31 frames larger than the cfr 23.976 counterpart using tdecimate(mode=1,hybrid=1). Resulting in a video with 33381 frames at 23:10 (equal time). So is the vfr output sped up to true FILM 24fps? Does the vfr routine differ from the two, and that accounts for the frame difference? The only thing I can think of, since the time/frame ratio is so drastically different (18:36 more frames to 23:10 less frames), is that Decomb512VFR outputs 29.976fps material and TIVTC outputs 24fps material in their vfr routines. Unfortunately, development has ceased and none of the documentation of Decomd512VFR addresses this for me.

One last thing, could it ever be possible to implement a similar thing in TIVTC where the filter in itself will run the first pass for metrics on the video and create the time codes file? Decomb512VFR is able to run the first pass somehow where ever the avisynth script has been called, so I know its possible, not that I am wining and complaining; but I'm not a programmer and this would just be a nicer feature. Thanks to MeGUI I had to dust off VirtualDub to get the first pass done with TIVTC. On a lighter note, TFM is the best around combined with eeid2 and tdeint, it tears through anime like swiss cheese.

As always, any help appreciated, please correct me if I'm wrong. Thanks.

plugh

10th June 2007, 15:56

An OVR file in conjunction with tdecimate mode 7 does not seem to work.

Example:
extract from ovr file
6793 -
6803 -
6808 -

debug output
TDecimate: inframe = 5563 useframe = 6799 chosen = 2
TDecimate: prev = 6798 curr1 = 6799 curr2 = 6800 next = 6800
TDecimate: 6796: 18.79 276299 (N) *
TDecimate: 6797: 0.13 1909 (D) *
TDecimate: 6798: 14.07 206950 (N) *
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N)
TDecimate: 6802: 0.71 10417
TDecimate: ------------------------------------------
TDecimate: inframe = 5564 useframe = 6801 chosen = 1
TDecimate: prev = 6799 curr1 = 6800 curr2 = 6801 next = 6801
TDecimate: 6798: 14.07 206950 (N) *
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417
TDecimate: 6803: 14.78 217278 (N)
TDecimate: 6804: 1254484575869219.00 18446744073709551615 (N)
TDecimate: ------------------------------------------
TDecimate: inframe = 5565 useframe = 6802 chosen = 2
TDecimate: prev = 6801 curr1 = 6801 curr2 = 6802 next = 6802
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417 (D) *
TDecimate: 6803: 14.78 217278 (N)
TDecimate: 6804: 0.30 4364 (D)
TDecimate: 6805: 1254484575869219.00 18446744073709551615 (N)
TDecimate: ------------------------------------------
TDecimate: inframe = 5566 useframe = 6803 chosen = 1
TDecimate: prev = 6802 curr1 = 6802 curr2 = 6803 next = 6804
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417 (D) *
TDecimate: 6803: 14.78 217278 (N) *
TDecimate: 6804: 0.30 4364 (D)
TDecimate: 6805: 0.07 979 (D)
TDecimate: 6806: 13.25 194905 (N)

As you can see, it chose to use 6803 in spite of the ovr file.

Terranigma

10th June 2007, 16:03

As you can see, it chose to use 6803 in spite of the ovr file.
Maybe to retain synchronization?

juhu

22nd July 2007, 16:29

Hi
I'm currently trying to remove dupes from a dvb-t capture (silent flick). A basic tdecimate(cycler=9,cycle=32) gets rid of the large majority of the dupes...but there are still some

So I played a bit with tdecimate mode2 and maxndl parameter.
As it seems there are never more than 3 real consecutive frames, I used maxndl=3, but to my surprise it doesn't seem to work : with debug (display) mode, I can clearly see almost each time a dupe is still there, it's in a SIX consecutive frames sequence (ie let's say displayed useframe= 1000 to 1005, dupe @ 1003.)
I shouldn't have 6 consecutive frame numbers with maxndl set to 3... What did I miss ?

tritical

28th September 2007, 05:53

@plugh
An OVR file in conjunction with tdecimate mode 7 does not seem to work.
Yeah, overrides in mode 7 of tdecimate are not currently possible. I will add that to the readme.

I noticed some puzzling results from a script that uses cframediff.

Dug into it, and eventually distilled it down to the following which illustrates the behaviour.

prevf is set true, you get correct output (ie 'true3').
If the frameevaluate is deleted, you get correct output.

a cframediff buglet?
avisynth weirdness??
stupidity on my part???
I can confirm this happens, but am not sure 100% sure why. The code in cframediff is correct in that it calculates the difference between frames n and n+1. What I think happens is that when cframediff requests frame n+1 it increments the "current_frame" value. As a test I changed cframediff to request frame n+2 instead of n+1 and I got true5. I'm not sure how to change cframediff so this works correctly, or if it is possible to.

When I look at the debug output of, for example, tdecimate(mode=0), part of the display are some number that I assume are 'normalized framediff metrics'. I also assume that the results from cframediff should be the same as those.

They are not. With identical args (blockx, blocky, chroma, nt) I get somewhat similar, but not identical results.
Can you post the script for this. I tried it here and get identical results.

tritical

28th September 2007, 06:06

@dude051

My question though is does the process actually remove or insert any frames? I was under the assumption that the process worked mainly by removing frames and using the timecode file to change the frame rate of the range of frames that were removed to make it run at full speed in each cycle. I've noticed that when I have always run Decomb512VFR that the output video was always shorter, and I noticed the parts that sped up from the resulting missing frames. In my source this results in a video with 33474 frames at 18:36. Yes the process only removes frames from film sections. Video sections are left undecimated. It never inserts extra frames. The timecode file is then used to set the appropriate display length for each frame.

But when I ran TIVTC's vfr, the resulting number of frames was shorter but also 31 frames larger than the cfr 23.976 counterpart using tdecimate(mode=1,hybrid=1). Resulting in a video with 33381 frames at 23:10 (equal time). So is the vfr output sped up to true FILM 24fps? Does the vfr routine differ from the two, and that accounts for the frame difference? The only thing I can think of, since the time/frame ratio is so drastically different (18:36 more frames to 23:10 less frames), is that Decomb512VFR outputs 29.976fps material and TIVTC outputs 24fps material in their vfr routines. Unfortunately, development has ceased and none of the documentation of Decomd512VFR addresses this for me.
tdecimate sets the framerate of mode 3/5 output such that the duration of the output is the same length as the input (some gui's with bitrate calculators need this). If you actually play it at that rate without using the timecode file it will be out of sync. I am pretty sure DecombVFR just sets the frame rate to 29.970 or leaves it the same as the input.

One last thing, could it ever be possible to implement a similar thing in TIVTC where the filter in itself will run the first pass for metrics on the video and create the time codes file? Decomb512VFR is able to run the first pass somehow where ever the avisynth script has been called, so I know its possible, not that I am wining and complaining; but I'm not a programmer and this would just be a nicer feature. Thanks to MeGUI I had to dust off VirtualDub to get the first pass done with TIVTC. It is possible, but I'm not going to go the trouble of adding in a gui window that pops up. So it would simply be an option to request every frame in the constructor.

tritical

28th September 2007, 07:50

[link removed], changes:
FrameDiff/CFrameDiff:
+ added display modes 3/4 to framediff
+ added ability to return block position to cframediff
- fixed bug in cframediff which caused mode=0 to return the highest value instead of
the lowest when norm was set to true

TFM:
+ added relative indexing from end frame number for trimIn files
+ added ability to set trimIn to a string containing a single frame range

TDecimate:
- fixed "number of frames after decimation doesn't match" error being incorrectly
thrown in mode 2

I plan to look into the reported problems and shortcomings of tdecimate's mode 7 and mode 2 when I have some more time.

MOmonster

28th September 2007, 19:11

:eek:
tritical you are great!

Thanks so much for adding these features so fast. I´ll try out as soon as possible.

:thanks: for all your expertise.

zdark

3rd October 2007, 04:11

thanks for your job tritical!!!

tritical

22nd November 2007, 06:21

[link removed], changes:
- fixed CFrameDiff returning invalid positions when rpos=true and there
was no motion
- added elim parameter to RequestLinear

Thanks to MOmonster for the CFrameDiff bug report and RequestLinear idea.

kilik

27th November 2007, 11:22

hello, i have a source with 5 frame interlaced and 1 frame progressive, is NTSC source, music dvd. I thing is called combed?

In dgindex i got NTSC Interlaced.

How to filter this source? only Tivtc or tivtc + tdeint?

Thank in advance.. bye :thanks::scared:

manono

27th November 2007, 12:15

Neither. You use some sort of an unblender most likely, RePAL or some such. It's hard to be positive without a sample, though.

Vesi

9th December 2007, 17:10

Need help for using TFM with tdeint.

I analyse my source with megui's analyse and show it film partially and suggest this.

DGDecode_mpeg2source("C:\...)
ColorMatrix(hints=true,interlaced=true)
tfm(order=1).tdecimate(hybrid=1)
crop( 2, 48, -2, -50).

Most of my source are 29 fbps and i want to bring them to 23.976 fbps.

as i am new to this filter, i want to know how to get good quality for my outputs.

manono

9th December 2007, 21:49

Indian DVD? Got a small sample you can upload somewhere so we can have a look? I'd trust the MeGUI analysis about as far as I can throw it.

Vesi

9th December 2007, 22:27

sample http://maxupload.com/7670C9B1

manono

9th December 2007, 23:29

Hi-

The next time you upload a sample, please try and have more movement. There's not much that can be learned from a sample where 2 people are sitting and talking. Anyway, you asked via PM for a full tutorial, something I have no intention of doing. By keeping it public, others can learn as well, and others who know more about the subject than I can also add to the discussion.

It's from an Indian DVD, as I suspected. However, this one is just hard telecined, and based solely on the sample, a simple:

TFM()
TDecimate()

will work fine. The reason I said I wouldn't trust MeGUI's analysis (or any automatic analysis), especially for NTSC Indian DVDs, was because over 90% of the classic film DVDs and probably over half of modern film DVDs are field blended, and no analysis is going to pick up on that. In such cases you use the RePAL filter, Restore24, MRestore, CDeblend, or some other unblender.

One way to determine what you have is to separate the fields (SeparateFields()), or put on a bobber (Bob()), and examine the fields carefully. In this case, after seeing that DGIndex confirmed it to be NTSC and Interlaced, and making the D2V with Honor Pulldown Flags, followed by bobbing it, I saw there were 2 fields the same followed by 3 fields the same, a sure indication of an already telecined source. For field blended sources, after separating the fields or bobbing the source, an examination of the fields will show a good percentage of them being blended, or ghosted, or having double images. In such cases an IVTC such as TIVTC won't work well, and I prefer to use rePAL. But sometimes they're even worse, being field blended 23.976->29.97fps, or even double blended, and those are especially difficult to work with.

To learn more I would suggest reading at the AviSynth site, reading the documentation included with TIVTC, reading the documentation included in the DGMPGDec package, and reading the DVD2AVI tutorial, outdated as it is:

http://www.doom9.org/ivtc-tut.htm

Vesi

10th December 2007, 03:19

Thanks alot manono for your replay.

I will do more reading on this subject as you suggest me. and will upload a sample with more details next time.

o.Since i am dealing with xvid and new to riping dvd to xvid, what is the good way or which way you recommend to analysis my source and chose the right deinterlacing type?

manono

10th December 2007, 04:33

In the case of your movie, the MeGUI analysis worked fine. There may be some real interlaced stuff elsewhere - studio logo, maybe - which might be why it called it hybrid, but mostly film.

The only good analysis is done with your eyes, in my opinion, again, especially true where Indian DVDs are concerned. And the knowledge of how to interpret what you see can only come with experience. Make a basic Avisynth script, separate the fields, and open it in VDub(Mod). Then scroll to a place with movement and start advancing a frame at a time. Since this is the TIVTC and TDeint thread, one or the other can handle most types of video, but not blended fields since I don't consider just deinterlacing a field blended video an option.

I have maybe 250 Indian DVDs, and more than 200 of them have blended fields. I prefer the classics, but the situation is only marginally better with DVDs of newer films. As long as you remember that the DVDs produced by the Indian DVD production companies are the worst in the world, that whatever can go wrong will go wrong, and that working with them requires a great deal of knowledge and experience, then you'll be better prepared for what you're going to encounter.

Vesi

10th December 2007, 13:49

Edit:
I made this simple script with out any deinterlacing line. And put the (SeparateFields()) line at the end of script and load it in VDM, now I see the image change to half size. Nothing else

DGDecode_mpeg2source("C:\Documents and Settings\vesi\Desktop\Test\Test.d2v",cpu=4)
crop( 2, 62, -2, -62)

Spline36Resize(640,272)
(SeparateFields())

I just download the DGMPGDec package and reading the documents on it, i am trying to understand what each things means, a bit hard for me since i have never done such thing before.I am some how lost in this, and trying to learn it
manono told me to do that, but it is hard for me to get him what he relay meant.

laserfan

10th December 2007, 15:17

how i separate the fields? should i remove the SeparateFields line when my script is ready for rip?You need to understand what manono has already told you: you use SeparateFields in Vdub in order to step-thru your video field-by-field to see what you have, and thus what you need to do.

As he has said already too, especially the DGMPGDec package contains excellent information/guides for examining video.

tyee

17th December 2007, 01:44

Can I use TDeint on HD-DVD to ivtc a movie?

I'm backing up to divx and H.264 but I get jerkyness every couple of seconds when I set my encoder to 23.976 output. AFAIK all HD-DVDs are flagged for 29.97fps but are 23.976fps on the disk.

Am I heading in the right direction to solve this?

Chainmax

30th December 2007, 03:58

While preparing a filterchain for ripping Robot Chicken based on advice MOmonster gave me a long time ago, I came across a section that has issues with modes 3 and 5 in TFM. Here's the current filterchain:

Mpeg2source("C:\Robot Chicken\Eps\RC_S1E1.d2v")

Interp = nnedi()
Deint = TDeint(type=1,cthresh=8,mi=66,edeint=Interp,emask=TMM())
TFM(mode=6,PP=7,slow=2,ubsco=false,cthresh=8,mi=66,clip2=deint)

Here's the problem (source) frame:
http://img165.imageshack.us/img165/8099/sourcesq9.png (http://imageshack.us)

Here's mode = 3:
http://img247.imageshack.us/img247/2712/mode3oo3.png (http://imageshack.us)

Here's mode = 5:
http://img292.imageshack.us/img292/6558/mode5eb0.png (http://imageshack.us)

All the other modes handle this frame perfectly. [link removed] a short clip with the frame in question.

tedkunich

10th January 2008, 06:37

@tritical

Is there any special trick/dlls needed for the output feature of TFM to actually generate an output file? Playing the script in Vdub, a file is created, but it is blank/empty. I am using TFM v1.0.3

AVISource("C:\test.avi")
AssumeBFF()
converttoYUY2(interlaced=false)
tfm(,output="C:\tfm.txt")

LigH

10th January 2008, 08:22

1) From my experience with clip comparing functions and plugins, which are able to output files, they held the output file exclusively open until you close the script or the application. So, for example: Loading a script in VirtualDub, and running it once, gives you an open file, which gets finalised only when you close the script or exit VirtualDub.

2) It may not harm, but the comma before "output" is strange. Possibly unnecessary.

tritical

10th January 2008, 08:22

TFM creates the file in the constructor, but it doesn't write anything to the output file until the destructor is run so either go to "file->close video file" after you've requested all the frames or just quit vdub and it will write everything to the file.

LigH beat me to it.

@Chainmax
I tried to download the clip, but the download link on the page you linked to wont work for me.

tedkunich

11th January 2008, 15:54

Chainmax

12th January 2008, 02:00

...
@Chainmax
I tried to download the clip, but the download link on the page you linked to wont work for me.

It doesn't for me either. Please try this link (http://rapidshare.com/files/83086326/sample.demuxed.m2v.html) instead.

tritical

13th January 2008, 01:54

It's caused by the combination of tfm's internal motion masking (PP>4) and the external deinterlacing. If you set PP=4 instead of PP=7 (or use only nnedi as the clip2 input) the problem goes away. It's a good idea to disable tfm's internal motion masking, which is run post field matching, when using TDeint (or another motion-adaptive deinterlacer) for post-processing since TDeint's/TMM's motion masking is run on the original stream.

Fizick

14th January 2008, 20:30

jeffy

15th January 2008, 00:23

Recently I saw some thread about comparing various deinterlacers (and its modes) by speed and quality. Some mode of TDeint was a winner (optimal). I want point some user to it, but I can not find it. Anybody can pont me to this thread? Or it was deleted?
Some hints:
http://forum.doom9.org/showthread.php?p=1059016#post1059016

http://heptium.sh.cvut.cz/~integra/deint/
linked from:
http://forum.doom9.org/showthread.php?p=900011#post900011

Chainmax

15th January 2008, 02:43

tritical

15th January 2008, 09:40

@Chainmax
Well, I was sure until I started to write an explanation of why it occurs, and it didn't actually make sense. Turns out there was a bug in modes 3/5 with micmatching > 0, which would cause tfm to sometimes return a u or b match when it thought it was returning a p, c, or n match. That error could only happen if all 5 matches were combed. I'll put up a fixed version later tonight or tommorrow.

@Fizick
I can't recall reading a thread comparing deinterlacers by both speed and quality.

EDIT:

Maybe it was this thread: http://forum.doom9.org/showthread.php?t=117025 ? It has some speed/filesize numbers plus some quality (ssim/psnr) numbers.

I did a comparison back in April 07 that I never finished, but I think that when taking both speed and quality (ssim/psnr wise) into account that it is difficult to beat:

yadifmod(mode=1,edeint=tdeint(mthreshL=0,mthreshC=0))

If only quality is considered than mcbob/mvbob are the clear winners (usually mcbob is best). If only speed is considered than the winners are leakkerneldeint/bob, yadif, or tomsmocomp (leaving out avisynth's internal bob() of course).

Fizick

15th January 2008, 18:07

Thanks for responds, but it was some other thread...
I found it ! :)

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

tritical

17th January 2008, 08:25

TIVTC v1.0.5 (http://bengal.missouri.edu/~kes25c/TIVTCv105.zip), changes:
- Fixed a bug that would cause tfm to return a 'u' or 'b' match when it thought it was
returning a 'p', 'c', or 'n' match. This problem only occured if mode was set to
3 or 5, micmatching was enabled (not set to 0), and all five matches were combed.

Mottodj

1st February 2008, 23:33

Hi everybody! I have question about results field maching by TFM. I have DVD with NTSC(film but without pulldown flags) anime and i pass it through TFM using avisynth. Field maching is nice but there is artifact in picture that was already mached(on fade to dark and in other way). Lines on picture have different brightness and it changing each other(ex. http://mini.100-games.ru/4super/artifact.png ). Have you ever seen that thing, what to do with this? Passing through tomsmocomp don't produce such artifact but tomsmocomp blur picture and it isn't solution...

Dreassica

2nd February 2008, 00:26

That's not missed interlace, but common in fades. I usually just applyrange(x,x,"blur",0,0.7) it, works perfectly.

Leak

3rd February 2008, 04:13

That's not missed interlace, but common in fades.
To be totally precise, that's a fade that has been applied AFTER the telecine was applied, so you have a 30 frames (or maybe even 60 fields) per second fade over pulled down 24 FPS material, so you can have either of them cleaned up, but not both - but then again, in a fade it's usually not noticeable UNLESS of course you take a screenshot... :)

A similar thing would be 30p/60i end credits (for extra smoothness that's easily produced) scrolling over 24p animation, which also happens often.

foxyshadis

3rd February 2008, 12:58

Use Vinverse for mild residual combing, not a destructive blur. Works wonders with some post-telecine editing, unless it's a very fast fade.

NorthPole

5th February 2008, 05:06

I've been using the following sort-of generic catch-all script for re-encoding ATSC digital broadcast caps to 23.976. I had a couple of questions..

Do I need to determine the order or does DGDecode_mpeg2source set the order correctly?

When converting from 59.94 fps progressive to 23.976 fps, sometimes I get some jerkiness in using the tdecimate(cycler=3, cycle=5). Is there anything I could do to tweak this?

I'm kind of lazy about counting frames in VirtualDub....Sorry

I have used the tdecimate(hybrid=1) setting on 29.97 fps to 23.976 fps and seem to get good results but I don't think I can use that for 59.94 fps conversions.

Any input would be appreciated.

PS.. Thanks tritical for you work!

DGDecode_mpeg2source("__vid__",info=3)
LoadPlugin("C:\Program Files\Media\AviSynth\plugins\tivtc.dll")
LoadPlugin("C:\Program Files\Media\AviSynth\plugins\eedi2.dll")
LoadPlugin("C:\Program Files\Media\AviSynth\plugins\tdeint.dll")
(last.height == 480)? SD(last): HD(last)
last.letterbox(4,2,2,2) # to mask screen edge noise

Function SD(video) {
ord = video.getparity() ? 1 : 0
ord == 1 ? video.AssumeTFF() : video.AssumeBFF()
edeintted = video.SeparateFields().SelectEven().EEDI2(field=ord)
tdeintted = video.TDeint(edeint=edeintted,order=ord,hints=false)
video.tfm(order=ord,clip2=tdeintted).tdecimate(hybrid=1)
#last.Lanczos4Resize(720,480,0,0,704,480)
}

Function HD(video) {
(video.height == 720)?
\ video.tfm().tdecimate(cycler=3,cycle=5):
\ video.tfm().tdecimate(hybrid=1)
}

foxyshadis

5th February 2008, 05:47

Do I need to determine the order or does DGDecode_mpeg2source set the order correctly?
mpeg2source will do that.

When converting from 59.94 fps progressive to 23.976 fps, sometimes I get some jerkiness in using the tdecimate(cycler=3, cycle=5). Is there anything I could do to tweak this?
Well, not everything is telecined. You're sure these are, rather than true 30 or even 60 fps segments? You can try tweaking chroma, nt, and dupthresh parameters to see if they help your stuff.

I have used the tdecimate(hybrid=1) setting on 29.97 fps to 23.976 fps and seem to get good results but I don't think I can use that for 59.94 fps conversions.
You'll get better results out of mvflowfps if you must force an fps change.

NorthPole

5th February 2008, 15:28

@foxyshadis
Thank you for the input.

mpeg2source will do that.

Good, I'll take it out.

Well, not everything is telecined. You're sure these are, rather than true 30 or even 60 fps segments? You can try tweaking chroma, nt, and dupthresh parameters to see if they help your stuff.

I believe most, if not all, is just 24p slowed down and telecined... Mostly movies and sitcoms.

If I understand the hybrid mode, it does normal 1 out of 5 decimation for 30 fps video segments provided it has a match. If it doesn't then it does blended decimation to get to 24 fps. I was kind of looking for something like that for 59.94 fps or 60 fps.

like say this...
tfm().tdecimate(cycle=2).tdecimate(hybrid=1)

I will try the dupThresh, chroma and nt options but then I think I have to use mode 1. So perhaps say something like..

tfm().tdecimate(mode=1, dupThresh=0.9, chroma=true, nt=1, cycler=3,cycle=5)
or
tfm().tdecimate(mode=1, dupThresh=1.2, chroma=false, nt=1, cycler=3,cycle=5)

You'll get better results out of mvflowfps if you must force an fps change.

I'm not sure what this is?

NorthPole

5th February 2008, 22:30

I did a couple of test encodes on a 1280 x 720p ATSC cap with:

tdecimate(cycler=3,cycle=5)
and
tdecimate(cycle=2).tdecimate(hybrid=1)

I wasn't thinking earlier but I wouldn't need the field matcher, tfm, since the source is all progressive.

the frames pattern go as follows: 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 etc.

1 = new frame, 0 = duplicate frame

I get the correct resulting frame selections with both methods and the encoding time is very similar. I believe that tdecimate(cycle=2).tdecimate(hybrid=1) might be a better way to go because it could correctly handle true 24 fps and 30 fps sources. The 24 fps source would be returned to the original frame rate and the 30 fps source would be blend decimated to 24 fps and hopefully avoid any jerkiness.

I tried the dupThresh, chroma and nt options with no noticably difference however, unfortunately, I deleted the original 720p video clip that was giving me jerkiness. I will have more in the next week or two and will report whether those tweaks helped.

rebkell

5th February 2008, 23:07

ABC is notorious for dropping frames, one of their favorite sequences is:
3:2
3:2
3:2
3:2
3:2
3:2
3:2
3:2
3:1
3:2
3:2
3:2
3:2
3:2
3:2
3:2
2:2

and then they repeat, it will cause the jerkiness when trying to get to the 23.9675 FPS. It works out to actually be 24.553735 FPS. I've seen it on several shows, LOST, Men In Trees, and some others, occasionally they will add an extra frame.

Adub

6th February 2008, 02:34

Ok, so how do you deal with it?

rebkell

6th February 2008, 03:31

Ok, so how do you deal with it?

Check out this thread, I'm not sure why it's in the DVD2AVI / DGIndex section, but it is.

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

I use FDecimate, I use megui and I actually built a profile to step through the frames, normally you can determine the cadence, basically you use the metrics=true to try to determine the best threshold value to use and of course after stepping through you can determine the FPS. The cadence I posted is the most frequent one I've run into, it's not perfect, but if you can figure out a good threshold value it works pretty well. All the above will make more sense when you read the thread I linked to above. I've also run into 10 consecutive 3:2 sequences and 1 2:2, that repeats every 11 cadences(I guess that's the correct word)

I've seen some cadences on the Fox Network that I never could determine any pattern for.

Adub

6th February 2008, 06:44

Thank you for that. I have to learn how to count fields. Anyone have a "guide" for doing it?

NorthPole

6th February 2008, 15:23

@rebkill,

Thanks for your input... I haven't counted as many frames as you have (not fun). I will check out the thread you suggested.

@merlin777,

I just count frames in virtualdub as I go through the video manually. I don't know of any specific method or program that does it automatically.

Adub

6th February 2008, 19:13

Wait, I thought they were counting fields, not frames. Am I mistaken?

rebkell

6th February 2008, 19:19

Wait, I thought they were counting fields, not frames. Am I mistaken?

Frames, you probably got confused by the conversation of our Texas friends that have the ABC 720p that is broadcast in 1080i, it's a fairly unique situation. If your ABC and/or Fox broadcasts in 720p, then we're only dealing with frames.

Adub

6th February 2008, 19:22

Okay,
Originally Posted by scharfis_brain
Actually I did excatly this: wirting down the pattern of the first frames until a pattern was visible. I counted 160 fields. Then I estimated the other pattern breaks with the simple math (every 67 fields a break) to be sure that the pattern stays constant.
That took about 5 minutes concentrated work. Not more.

I am confused by this however.

laserfan

6th February 2008, 20:14

Here is my last "Inspect for Motion.avs"

MPEG2Source("Cane - Brotherhood.d2v")
assumetff()
separatefields()

Then I open this w/VDub and count. So it's fields that are counted when it's a 1080i program.

Adub

7th February 2008, 03:54

Okay, thanks for that clarification. Now when you are counting fields, what are you looking for?

laserfan

7th February 2008, 16:57

Okay, thanks for that clarification. Now when you are counting fields, what are you looking for?Looking for the cadence. If you find 3 alike then 2 alike then 3 again then 2 again and it never changes, you're golden. You can do a simple

Telecide(guide=1).Decimate()

and proceed to re-encode from there. If you have an odd cadence then it gets an order-of-magnitude more complicated! ;)

If you're new to this stuff, my advice is to find neuron2's website (Donald Graft) and look at the Readmes & tutorials he's created for the above, and his tools--I'd start with Decomb and study the DecombTutorial.html therein.

NorthPole

7th February 2008, 23:47

Adub

8th February 2008, 00:55

See now some of the reasons I get confused is that the 3:2 pattern applies to both fields and frames.

Ex. 3 progressive frames, 2 interlaced.
AND
Ex. 3 fields that "current", 2 fields that are "next".

I just need to tie that together in my head.

foxyshadis

8th February 2008, 08:54

Don't know if this is correct, but I find it easier to look at frames. For 480i and 1080i, I look for a repeating pattern of 3 progressive frames followed by 2 interlaced frames. If the pattern stays consistant for say 50 frames, I just go with a tfm().decimate(). If the pattern is not consistant, then I try tfm().decimate(hybrid=1). 720p would be just frames.

You can pull your hair out trying to figure out field-shifted video by doing that, though, or just make the wrong choice. All interlaced video is naturally fields, so you might as well start at that level unless the pattern is instantly obvious.

NorthPole

9th February 2008, 22:58

All interlaced video is naturally fields, so you might as well start at that level unless the pattern is instantly obvious.

OK, I will take your advise and go the fields route.

Had the best luck to date at getting smooth playback @ 23.976 fps on 1280 x 720p ABC ATSC OTA cap of movie meet the fockers with:

tdecimate(mode=7,nt=1,dupthresh=1,vidthresh=3.5)

pattern was 3:2:3:2:3:2:3:2:3:1:1:2 got lost (gave up) at that point...Not good at that.

NorthPole

10th February 2008, 15:15

Spoke to soon... Still not happy with the results.

Tried a script by plugh from this thread to get and idea of where the dupthresh might be.

http://forum.doom9.org/showthread.php?t=122472&page=2

Going to try mode 7 again with different dupthresh and vidthresh values. Had one question....

Assuming 720p 59.94 fps material as source.

Is this correct in stating that the frames with a difference value that falls between the dupthresh and the vidthresh are the frames that are subject to blending during decimation?

Sorry, I just realized that this is in the development forum. Should have posted in the usage forum.

Thanks.

thetoof

15th February 2008, 22:21

Dunno if it's the right place to post this, but I've been told TIVTC can be helpful for interlaced footage encoded as progressive. However, everything I've tried can't produce any good results.

Source = NTSC DVD (anime)
DGIndex tells me: 99.98% FILM, Progressive, frame-based

Honor pulldown flag: no pattern at all, about 50% of the frames have interlacing artefacts

Here's the first chapter ripped with DGIndex (decrypted vob)

http://www.megaupload.com/fr/?d=TVCZAWUB

For those who'd like to help, but not download a 156 MB file, here's a m2v generated using demux in DGIndex with "honor pulldown flags"
http://www.megaupload.com/fr/?d=87FM0ENK

Chainmax

16th February 2008, 20:13

I have a trouble sample as well. It's from the X-Men 1992 series' intro. For some reason, on certain spots peppered throughout it, a pretty messed-up frame is chosen instead of a considerably cleaner version of it. The IVTCing portion of the script is this one:

AssumeTFF()
Interp = nnedi(field=1)
Deinted=TDeint(order=1,field=1,type=1,edeint=Interp,emask=TMM(order=1,field=1))
TFM(d2v="X:\wherever\Sanctuary1.d2v",mode=6,order=1,PP=7,slow=2,mChroma=false,Clip2=Deinted)
TDecimate(mode=1)

You can download a sample with the intro here:
http://rapidshare.com/files/92404386/Intro.demuxed.m2v.html

tritical

19th February 2008, 01:57

@thetoof
The main problem with your clip is that it has blended fields. Worse than that they seem to be causing jerkiness, as though the field order is incorrect, but it isn't. Maybe someone else can recommended something better, but

mpeg2source()
tdeint(mode=2)
tdecimate()

seems to give ok results.

@Chainmax
I downloaded your clip, and ran it through dgindex to generate a d2v file. However, when I try to load that d2v file with mpeg2source() in virtualdub it just hangs. I'm using dgindex/dgecode v1.5 RC2. The downloaded file has 59768148 bytes and the crc is 9F0C270B, is that correct?

Chainmax

19th February 2008, 03:42

Unfortunately, I deleted the file as soon as it was uploaded. I'll make another cut with the intro and make sure Mpeg2Source is able to pick it up before uploading it. I apologize for the inconvenience.

[edit]I get the same eror when trying to open a d2v generated (from a freshly cut intro) with DGIndex 1rc2 on VDubMod 1.5.4.1 via MPEG2Source. The m2v opens fine by itself in VDubMod though. I'll post this in the DGIndex thread, maybe I hit a bug.

thetoof

19th February 2008, 17:38

Not perfect, but those settings give better results than everything I'd tried. Thanks!

'course, if someone finds a way to completely remove the temporal blending (not sure that this is how it's called... I'm talking about the frames that are present as "almost transparant" in previous or next ones), it'd be even better... but heh, I guess there are some things that just can't be fixed.

Anyways, thanks again!

plugh

20th February 2008, 00:31

Usage Q:
Can I use an override file to specify 'keep' frames? The doc only refers to using '+' "as place holders" in a "decimation pattern", not as an override directive unto itself.

Doc Q:
The write up on 'maxndl' is confusing and seems to have errors wrt the examples.
For example, say we have the following pattern in a video:

5 5 7 7 2

where the numbers indicate how many frames there are between duplicates. In this case we want to remove 5 in every 26 frames.
If the numbers indicate the number of frames between duplicates then the total number of frames in the sequence is 31, not 26. This affects the rest of the discussion of the example.
Also note this sentence:This decimation ratio (5/26) would indicate that there is one duplicate in every 5.2 frames (5/26 = 1/5.2).
The numerator is your 'number of dups to be removed'
The denominator is -- well it's not clear what it is (see above)
Let's look at the next example:
Another example would be decimating a 59.94fps video to 23.976. This ratio would indicate one duplicate in every 1.667 (5/3) frames.
Hmmm. In this case
the numerator is the total number of frames in a cycle
the denominator is the number of dups to be removed

But in both examples the ratio is stated to represent the same quantity - "one duplicate in every N frames"

I am very :confused:

rebkell

21st February 2008, 22:40

I posted this in another thread, but this probably a better place to discuss it:

Ran into another weird cadence on Jericho the other night:

21112111211121112111211121112111211111
21112111211121112111211121112111211111

Looks like it's keeping 38(dropping 9) out of every 47 frames, which would work out to 24.231 FPS. I only examined one section of it, but that section seemed to be consistent .... I wanted to cry, CBS has been so great, I think it's the first strange pattern I've ever run into on CBS broadcasts.

would the maxndl=5 or would it = 6 in the above cadence.

The 2 in the above pattern equals two frames that are the same. At the end of the first row I have 5 nonduplicates in a row and then the 6th frame on the next row would also be different and the seventh would be a duplicate of the 6th, so I would assume that maxndl would = 6?

If the pattern stays consistent I assume I would use:

tdecimate(mode=2, rate=24.231, maxndl=6)

K0zi

23rd February 2008, 14:43

rebkell

23rd February 2008, 17:14

I have a Chinese movie released on NTSC DVD.
I tried both tfm().tdecimate and tfm().tdecimate(cycle=6), but the results didn't seem to be what I was looking for.

Sample: http://rapidshare.com/files/89421694/sample.rar.html

tfm(order=1).tdecimate(hybrid=1,cycle=6) seemed to work well, the hybrid was only applicable to one section of 6 frames, the rest were definitely one duplicate in 6. It appears it was 25.0(24.975) FPS.

K0zi

1st March 2008, 18:47

What if I wanna get some "proper" fps instead? I mean, the source video was apparently PAL, as it's also a Chinese standard these days. Is it possible to get the original framerarte back without any seriuos issues (like audio track sync for instance)?

rebkell

1st March 2008, 19:23

tritical

5th March 2008, 01:29

@plugh
Yep, the maxndl explanation explanation is not very clear. In the first example with (5 5 7 7 2) the numbers aren't the number of frames inbetween each duplicate frame, but the number of frames from the current duplicate to the next duplicate. So the sequence is really:

dnnnndnnnndnnnnnndnnnnnndn

Here, you would want to remove 5 in every 26 or 1 in every 5.2.

In the 59.94 to 23.976 case there are more duplicates in the stream then there are new frames, which means you want to remove more than 1 out of every 2 frames and you can't state that in 1/N terms using only whole numbers. That's why I used 5/3. However, 1/0.6 specifies the desired value just as well.

What the fraction actually means is that in every 5 frames you want to remove 3 frames (or in every 1 frame you want to remove 0.6 frames). The top number in the fraction is just some arbitrary cycle length, and the number in the bottom is the number of frames you want to remove within that cycle length. The actual values you use don't matter as long as the decimal resulting from the fraction is the same.

On the keep frame overrides, I can't remember for sure. I want to say that it isn't possible.

@rebkell
On the maxndl value for mode 2 I think you will just need to experiment and see what works best. In all honesty, I've never really spent a lot of time working on mode 2 to get it to a solid/stable state, so sometimes it produces good results and sometimes it just sucks horribly.

rebkell

5th March 2008, 18:20

I have a question about TDecimate and using the ovr (Override file)

I tried using it and it wasn't doing anything, when I looked at it. Just want to make sure I'm using it correctly.

I'm hopelessly looking for ways to cut out those weird ABC-HD captures and their strange cadences. Anyway.

If I include a line in my avs script like:
TDecimate(ovr="C:\test.ovr", display=true)

and have a file named test.ovr in the C:\ directory
with one line like so:

0,130 +-------+

this should from my understanding keep 1 frame starting at frame 0 and then drop the next 7 and keep the next one and then repeat this through the first 130 frames, then it would revert back to dropping one frame in every five as the normal TDecimate without any parameters does. When I step through an avs script using display, it doesn't appear to be using the .ovr file at all, it just seems to be using the normal 1 drop in every 5 frames.

Am I doing something wrong? the above test.ovr file is just for a test, but it should definitely be easy to tell if it's working.

Zarxrax

7th March 2008, 21:03

I'm having some difficulty understanding the d2v fixing.

I indexed a d2v file with dgindex, and dgindex said it had illegal field order transitions, so I let dgindex fix it. Then when I was trying to use TFM on the file, it was just utterly failing everywhere, it wasn't matching hardly any of the combed fields.

I then tried the original "broken" d2v file, and everything worked great!

Ok, so then I thought maybe I'll let tfm try fixing the file. So I use the d2v parameter to let tfm fix the file, and then I tried the one that it output. Once again, the fields aren't being matched.

Now, I can use the "bad" d2v and its giving me awesome results, but it's just really bugging me that I don't understand what's going on here. I'm being told that my original d2v has some bad stuff going on in it, so I should use a fixed one... but the fixed ones are the ones that end up not working right!

NorthPole

8th March 2008, 17:47

I'm having some difficulty understanding the d2v fixing

What is the type of your source material. If it is 720p, then the field fix would not apply. If it is 480i or 1080i then you have to make sure you do not have frame repeats. (not sure if you have to preview the whole clip to get that info).

Another option is to use the "bad" file and use tfm(mode=4) which I believe can handle illegal field order because of the 3 way matching.

Zarxrax

8th March 2008, 18:36

It's just a regular dvd of old telecined anime material.

reepa

21st April 2008, 11:51

I'm not sure if this is a bug or if I'm misinterpreting the documentation, but TDeint averages pixels that are woven even when mtnmode is set to 2 ("no averages, replace with most similar field"). I'm using TDeint(mode=1, mtnmode=2, map=1) and nearly all woven pixels are either 153 ("use average of curr/next") or 204 ("use average of curr/prev"). Mtnmode=3 doesn't have this problem (i.e. all woven pixels are either 51 or 102).

plugh

2nd May 2008, 21:43

I'm trying to process a TV cap, and tfm + tdecimate(hybrid=1) are doing ok with it EXCEPT in areas where an insert fades in/out or slides on/off the bottom of the screen.

If I do something like this
mpeg2source(d2v=)
cropbottoim(80)
tfm(d2v=)
tdecimate(hybrid=1)
everything works correctly (except I've lost the bottom of the picture). Smooth motion, no unnecessary blends, nice clean field match and decimation...

Great, I sayz, I'll use an exclusion band...
oops - tfm has y0/y1 args, but tdecimate doesn't! grrr...

REQUEST: exclusion band input for tdecimate

OK, so do it the 'hard way'
mpeg2source(d2v=)
tfm(d2v=,y0=400,y1=480)
orig=last
cropbottom(80)
mergehints(hintclip=orig)
tdecimate(hybrid=1,clip2=orig)

Only problem is, it don't work. I'm back to frame blends again. As far as I can figure, the above two scripts should be yielding the same ivtc decisions, but they aren't.

What am I missing / doing wrong?

Thanks!

PS - are Y0/Y1 zero-based or one-based? Do they count from top of frame?

thetoof

29th May 2008, 07:17

Sorry for the noobish questions, but I don't have any hybrid source atm, so I can't run any tests to be sure that my scripts are done the right way.

I found some info floating around about creating a VFR clip for hybrid sources, but I just want to be sure... Leaving post-processing aside, what would be the settings to use for 1st and 2nd pass of TIVTC?

Also, what is the format of a timecode file? I'd like to create one manually to select which part of the movie will run at which framerate.

Adub

29th May 2008, 08:15

It's a little dated, but check this out:
http://avisynth.org/mediawiki/VFR#encoding_to_vfr_.28mkv.29

thetoof

29th May 2008, 08:28

Yeah, I read it... but I thought I had done something wrong, because nothing was being written in the "tfm.txt" and "stats.txt".

I've tried running a preview, an analysis pass and a lossless pass in vdub without getting anything... any ideas why it doesn't work?

And, do you know the format of the timecode?

Thx

Adub

30th May 2008, 18:34

You did let the passes finish fully, correct? Because no information is written until the script is done. I was doing the same thing and I realized that I had to wait until the end before the info was written.

as for the timecodes, I would have to look at them to tell you. Or you could do it yourself: Check which of these the file looks like:
http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#EXTERNAL%20TIMECODE%20FILES

thetoof

1st June 2008, 09:57

That's exactly what I needed, thanks! Everything's working perfectly fine now.

Adub

1st June 2008, 10:02

Glad to help.

shadell

3rd June 2008, 04:53

I have tried using TDeint with the blend interpolation option as a replacement for fielddeinterlace(), which I find produces pleasing results in some situations, despite the ghosting. The call was TDeint(type=4). This produced a lot of jagged artefacts, such as the following:

http://i297.photobucket.com/albums/mm223/shadelll/artifact013crop.png

When I look at the map=2 output, I see that the effected areas have (mostly) not been marked as 'interpolate pixel'. When I look at the interlaced input, the area is combed.

Reducing mthreshL and mthreshC down to 1 reduces the number of artefacts, but there are still quite a few.

Since there is a blend interpolation option, I thought it should work OK. Are there other options I need to use to get it to work without producing these artefacts?

Nikos

29th August 2008, 20:57

a. The denoise option of TDecimate is for internal metric calculations only or not?

denoise -

Sets whether or not to denoise frames prior to doing difference metric calculations.
This can greatly improve metrics for noisy sources (i.e. stabilize duplicate frame
metrics and make it easier to tell the difference between duplicates and non-duplicates).
It also works very well for sources with lots of dot-crawl because the denoising
effectively cancels all dot-crawl, whereas the dot-crawl would usually inflate difference
values of duplicates. Using denoising will slow things down somewhat, but it is MMX
optimized and pretty fast.

true - use denoising
false - don't

b. May i crop before IVTC with tfm and TDecimate?

mpeg2source("Black&White-source.d2v")
Greyscale()
crop(32,16,-32,-24)
tfm(d2v="source.d2v", mode=1, mChroma=false)
Tdecimate(chroma=false)

c. The greyscale place is right?
The source is Black&White telecine 29.97 fps film.

Adub

29th August 2008, 23:23

Since your clip is already black and white, why add the greyscale parameter? Greyscale() is usually used when converting color clips to greyscale.

Also, I believe that it is never good to crop before an ivtc, or whenever dealing with interlaced material. I thought I heard there was a way some time ago, but I have always found it safer to crop afterward.

Nikos

29th August 2008, 23:44

Thanks Merlin7777 for the answer.
Althought the clip is black and white, sometimes there is noise in the uv planes.
For interlaced or telecined material i know that it's safe to resize horizontal before IVTC but i am interesting if it's safe to crop before IVTC or deinterlace.

Adub

30th August 2008, 00:36

Althought the clip is black and white, sometimes there is noise in the uv planes.

Ah, I understand then.

And like I said before, cropping before IVTC or Deinterlacing is never a safe thing to do. I have never gotten it to work correctly at least.

Boulder

30th August 2008, 09:03

I'd expect that cropping horizontally is OK, and cropping vertically mod-4 also to be OK.

Mystery Keeper

30th August 2008, 16:43

I'd expect that cropping horizontally is OK, and cropping vertically mod-4 also to be OK.

Only cropping mod16 is safe. One should crop mod16, do what needs to be done and then crop the rest.

Didée

30th August 2008, 17:46

Only cropping mod16 is safe. One should crop mod16, do what needs to be done and then crop the rest.
Ah, a statement. Please explain why it should be so.

(I don't see why mod16 should be required for purposes of IVTC or deinterlacing in general. mod4 vertically is a technical requirement for YV12 sources, since that's the "luma distance" between same-parity chroma samples. That's all.)

Mystery Keeper

30th August 2008, 19:13

Ah, a statement. Please explain why it should be so.

(I don't see why mod16 should be required for purposes of IVTC or deinterlacing in general. mod4 vertically is a technical requirement for YV12 sources, since that's the "luma distance" between same-parity chroma samples. That's all.)

I tried cropping before deinterlacing with TempGaussMC and it gave me ghosting ^_^'

Didée

30th August 2008, 19:49

During testing TGMC, I'm often cropping wildly around on the input, only caring for mod-4, not -16, and never got any unusual ghosting. Feel free to post script + material that makes your observation reproducable.

Again, mod4 is the only technical requirement in this case.

Adub

30th August 2008, 20:09

Ah, so that was the trick to it. it's okay to crop horizontally. but when cropping vertically, always respect mod 4.

thetoof

31st August 2008, 10:05

Hi,
I've got something fairly complicated to do via vfr decimation, so I've got a help request if it's doable and a feature request if it isn't :p

Let's say I have these framerates :
a=23.976
b=25
c=29.97
d=59.94
They were then spliced together with
a.changefps(d)+b.changefps(d)+c.changefps(d)+d
So, I have a CFR clip @ 59.94fps with tons of duplicates (that I want to remove via vfr decimation). How can I do that???

Also, there are many duplicates in the 23.976 clip and it could be decimated to very low framerates for a couple of frames (even below 8 fps) So, I was wondering if it would be possible to have a vfr decimation that adapts to the amount of motion and uses framerates other than the standards ones to display the same motion to encode a lot less frames with no visual difference (in anime you can even have the same frame for more than 1 second after all the noise has been removed).

Here is a test clip I have created for the occasion that replicates the situation I just described: http://rapidshare.com/files/141496007/VFR_testclip.7z.html

sander815

1st September 2008, 12:12

how do i call the multithreaded version of this plugin? EEDI2_imp.dll

foxyshadis

4th September 2008, 11:17

You replace EEDI2.dll with that one. That's it.

aand

8th October 2008, 21:30

Question about TDecimate:
I have a series of black frames; instead of cutting some of them, it removes all of them and leaves more 'visible' dups behind.
Is there a way of setting <max nr of dups in a row> ? If not, I'm making an official feature request :D.
Thanks.

r00t61

20th October 2008, 06:45

Is there any way I can set the location of the debug output information provided by TFM/TDecimate (i.e, when display=true)? Currently, the output is always fixed to the upper left-hand corner, so if I have display=true on for both TFM/TDecimate, the debug output from TDecimate overlays on top, obscuring the debug output for TFM.

I'd like to be able to see both sets of debug data at the same time.

thetoof

20th October 2008, 15:07

I didn't check the doc, but a quick and dirty way of doing it is by using stackvertical/horizontal to see the same frame with different info, or by cropping the part of the frame where the info is to overlay it on another corner.
source=your source
tfminfo=source.tfm(settings).crop(select the part of the frame containing the info here)
tdecimateinfo=source.tdecimate(settings)
overlay(tdecimateinfo,tfminfo,coordinates where you want to overlay)
#uncomment the next line to tweak the crop settings
#return tfminfo

r00t61

24th October 2008, 06:18

Well, thetoof, your suggestion didn't quite work out the way I wanted to, but I'll keep experimenting. Thanks.

In the meantime, is there any to alter TDecimate's behavior for vfr output (i.e., when mode=5), for handling 30p video sections? In particular, I would like to make TDecimate perform a bob (59.94 fps) instead of a blend decimation for those sections designated as video, while still IVTCing/decimating the film portions to 23.976 fps.

thetoof

26th October 2008, 06:46

You may be interested in AnimeIVTC, as it bobs interlaced sections & IVTC telecined ones to create a VFR clip. See mode=3, 4 or 6 with omode=2.

canuckerfan

15th December 2008, 22:06

i have a clip here which i'm trying to deinterlace correctly... it's hard telecined without any blends so an ivtc should work. however, I'm having a hard time determining the field order. I've tried the separatefields().assumetff test but both tff and bff show no backward motion. weird. so far I've thrown 2 scripts at it:

interp = nnedi(field=1)
deint = tdeint(mode=0,order=1,field=1,edeint=interp,slow=2,emask=TMM(mode=0,order=1,field=1))
tfm(mode=3,order=1,clip2=deint,slow=2)
tdecimate()

interp = nnedi(field=1)
deint = yadifmod(edeint=interp)
tfm(mode=3,order=1,clip2=deint,slow=2)
tdecimate()

both produce pretty much the same result to my eyes and the ivtc looks pretty decent. but I'm wondering if this is right with the field order discrepancy. here's the clip(23 mb): http://www.sendspace.com/file/upa8m7

AVIL

15th December 2008, 23:26

canuckerfan

16th December 2008, 01:27

IMHO your clip is progressive. No temporal difference between fields. Only spatial one. There is some residual combing that you can fight with plugin vinverse. Internal function Info() says that the clip is bff .In fact, when assumed as bff, after separatefields() the first field has the top line. But deinterlace this progressive clip is unnecesary (again IMHO). In scenes with motion there is blending. Try to deblend first.
thanks for your input. why i seem to think it's partially interlaced is because of the horizontal lines evident throughout the clip. classic sign of interlacing. in fact, it seems to follow a 3p/2i pattern. as for blending... i separated the fields and didn't see any myself. during high motion there is plenty of blurriness, however.

manono

16th December 2008, 02:10

AssumeTFF().SeparateFields()#plays smoothly
AssumeBFF().SeparateFields()#plays jerky

The sample is TFF and any simple IVTC seems to work. It's not field-blended, although there does seem to be some sort of motion blur or similar going on.

canuckerfan

16th December 2008, 02:15

AVIL

16th December 2008, 20:30

I have repeated my test but using dgindex/dgdecode. Formerly I've used directshowsource (an enourmous mistake). My new results agree totally with manono's ones.

@Tron@

15th February 2009, 02:00

Interested in a plan to update the gorgeous plug -TFM!? I take them a long time and would like to know whether in the near future, its updating and some "delicious"))) because there is no limit to perfection, and should always be striving towards the ideal ))

And what with TDecimate and MergeHints???

ikarad

4th April 2009, 17:46

TIVTC is multithread or not?

tritical

7th April 2009, 02:37

@ikarad
No, tivtc isn't multithreaded.

@@Tron@
Atm, I don't have any plans to update tivtc further. My original motivation for coding/working on tivtc was the fact that I actually used it regularly, but as I haven't encoded anything in 2-3 years that motivation is pretty much gone. Now I tend to stick to filters that interest me academically.

rebkell

7th April 2009, 02:45

Is there anyway to get tdecimate to ignore the bottom part of the clip, when making decisions on which frames to drop, all the animated logos, and popups on all the network shows that I capture really plays havoc with trying to get the right frames dropped.

tritical

7th April 2009, 02:59

I think 'clip2' parameter of tdecimate can accomplish what you want. Something like:

saved = last
crop()
tdecimate(clip2=saved)

It will make decisions based on the cropped clip, but return frames from clip2. If you only crop the bottom of frames it shouldn't effect hint passing.

rebkell

7th April 2009, 03:04

rebkell

7th April 2009, 07:44

ikarad

18th April 2009, 21:40

tritical

19th April 2009, 02:43

Is it possible to hope a multithreading version of TIVTC or is it an utopia?
It is very unlikely. With the way the code is, it would be a major task to multithread tivtc interally.

ikarad

10th May 2009, 15:04

I have a problem with TIVTC and ffdshow.
If I use TIVTC with libavcodec (MPeg 2 codec), I d'ont have 24 fps but 28 fps.
If I use libmpeg2 instead of libavcodec, I have 24 fps

with libmepg2
http://nsa07.casimages.com/img/2009/05/10/mini_090510040236829569.jpg (http://www.casimages.com/img.php?i=090510040236829569.jpg)

with libavcodec
http://nsa08.casimages.com/img/2009/05/10/mini_090510040442784974.jpg (http://www.casimages.com/img.php?i=090510040442784974.jpg)

without TIVTC
http://nsa08.casimages.com/img/2009/05/10/mini_090510040600831936.jpg (http://www.casimages.com/img.php?i=090510040600831936.jpg)

If I use decomb there isn't any problem with libavcodec or libmpeg2

I use MPC-HC and ffdshow-mt 2940

It is very unlikely. With the way the code is, it would be a major task to multithread tivtc interally.

The problem is that with blu-ray movie at 30 fps, even my cpu Q6600@3.0ghz isn't enough powerfull. I must use Decomb but Decomb is less good than TIVTC

tritical

11th May 2009, 05:51

Some options that could speed up processing are:

tfm:
slow = 0
micmatching = 0 or 2

tdecimate:
chroma = false

Of course, changing those could change the output, but in most cases it probably wont be noticeable. I would try slow=0 in tfm and chroma=false in tdecimate, and see if it is fast enough.

PzSniper

22nd September 2009, 01:34

***removed because my crossposting was a rule #8 infringement***

Sorry neuron2 :(

but...

why i keep gettig this error?
http://i36.tinypic.com/2d7de1k.jpg

DivxBr

14th November 2009, 04:24

Sorry for a (maybe) stupid question, but when the TFM plugin sends a popup message telling me that it created an xxxx-FIXED.d2v file, to use, this file (FIXED) must be used on TFM command only or in the mpeg2source command too? This FIX increases/decreases the movie's total frame count?

tritical

15th November 2009, 07:01

In both. It could increase or decrease the count... it tries to keep the frame count as close as possible to the original while fixing the field order changes. dgmpgdec also has a tool to do this fixing.

DivxBr

15th November 2009, 13:30

I tried the Fix d2v option (in DGindex), but it show no errors to correct(!).
My concern is that this increase/decrease or frames could lead to audio synch errors.

tritical

15th November 2009, 19:56

B.F.

16th November 2009, 09:34

DivxBr

17th November 2009, 19:47

Can you post the d2v file? Usually, the change in frame count is only 1 frame so not noticeable. If you are concerned then you could always ignore it, and use a matching mode that can deal with changing field order.

I dont have this file anymore (If it helps, I can generate it again). But I checked the corrected file against the uncorrected, and found one difference only in the last frames, so no problem.

My concern, is if there's a possibility with bad encoded material that the frame count difference accumulates (within corrected file), so we get "a lot of" frames of difference?

thetoof

8th January 2010, 16:22

Hi,

I can't find how to detect the small 30p vertical motion of this clip to create good VFR timecodes. http://forum.doom9.org/showthread.php?p=1361082#post1361082

Script:
i=source
match=i.tfm(slow=2,clip2=i.tdeint(2,edeint=i.nnedi2(-2),emask=i.tmm(1)))
bob=i.tgmc.selecteven() #use whatever tgmc version you like to test
match.trim(0,454)+bob.trim(455,503)+match.trim(504,0)
TDecimate(4, output="stats.txt",denoise=true)
#TDecimate(5,hybrid=2,input="stats.txt",mkvout="timecodes.txt")

Any help please?

On a side note, it would be nice to have the option of creating a vfr clip that'd mix 23.976, 29.97 and 59.94 for situations like these (where full motion is actually 60p and is mixed with 24p content).

tritical

8th January 2010, 23:58

In mode 5 with vidDetect=3 and no tmfIn file, tdecimate assumes all matches are c. So the only reason a cycle (every 5 frame group, so 0-4,5-9,10-14,etc...) wouldn't be marked as 30 fps is if one or more of the frame difference metrics in that cycle is < vidThresh. Thus, try lowering vidthresh (you can look at the debug/display output in mode 4 to find the lowest difference value in that range of frames). I replaced tgmc with bob() for quick testing, but it looks like with denoise=true you need vidThresh=0.8 for that section. However, in a few cycles I can't tell if there is or is not a duplicate... sometimes the difference metrics go down to 0.3x, but those look like dups to be me. Alternatively, you could use manual overrides to force video detection or manually edit the tdecimate stats file (increase the difference values).

On a side note, it would be nice to have the option of creating a vfr clip that'd mix 23.976, 29.97 and 59.94 for situations like these (where full motion is actually 60p and is mixed with 24p content).
I agree :), but at the time I wrote the hybrid handling in tdecimate I was only concerned with mixes of 24p and 30p content.

thetoof

22nd January 2010, 23:39

Could you add a feature in tdecimate to handle 23.976, 29.97 and 59.94?

Hm, just thought about this:

Can I manually edit the timecodes to look like this - I mean, will it work? (I know I could test, but it's faster to get an answer here :p)

# timecode format v1
Assume 29.970030
0,39,23.976024
775,778,59,940060
994,997,23.976024

tritical

25th January 2010, 21:59

It's possible, but I don't have the time or desire to do it. It isn't a simple modification, at least an easy method isn't coming to mind. The code for tfm/tdecimate is a big mess. It might actually be easier to create a separate filter/program to do it based off tfm stat file and tdecimate stat files from tfm output and bobbed output.

I don't know why manually editing the timecodes file wouldn't work... assuming you splice sections (add the 60p video in the right place)/modify frame numbers as needed.

thetoof

26th January 2010, 17:13

Alrighty, thanks for the answer.

Gser

15th February 2010, 21:06

johnmeyer

16th February 2010, 04:07

Is there a way to force TDecimate to decimate all combed frames? I have a source where TFM flags really bad frames as combed frames. I want to decimate these first, and then remove the remaining duplicates to achieve a given frame rate. The MIC metric in TFM shows 255 on these bad frames, so TFM is providing the information I need. I don't mind doing a two-pass, but I cannot figure out how to pass a file back into TDecimate that will force it to decimate these "255" frames first, and then use the metrics from TFM to further decimate by removing the true duplicates.

[edit]
I figured it out. This does what I want:tfm(display=false,mode=1,pp=1,cthresh=25,micmatching=3,mmsco=false)
tdecimate(mode=7,display=false, rate=23.976)

ikarad

22nd February 2010, 14:17

turbojet

1st March 2010, 23:55

Hi, is there any chance adding support for reading frame type (film or ntsc) from dgi files to TFM like the d2v function?

Here's an example (http://www.mediafire.com/?n1yl2w5t2n1) of a dgi file that has both ntsc and film frames.

D3C0D3R

7th May 2010, 11:35

i've use TIVTC couple of years. it amazing filter pack.

I've found serious memory leak (about 1MB-2MB per second) when use tdecimate mode=5 (2nd pass of hybrid)
with serious filter chain - couple of them writted by tritical too )) *BIG RESPECT*

i've placed this chain before and fter tDecimate, but leak is still appear I even remove some memory & cpu most hungry filters but it seems doesnt depend from type of filters and it position in script.

my settings
tdecimate(mode=5, hybrid=2, vfrDec=1,mkvOut=mkvTimeCodeOut,input=metricStats, vidThresh=15,dupThresh=10, vidDetect=1, cycleR = 1, cycle=2)
encoded by VDub+x264vfw one of latest versions/revisions

I didnt use TFM to do output="matches.txt" at first pass.
I haven't use TFM at all, only TDecimate - to remove duplicates in progressive stream.

In mode=3 all works fine, but mode=3 produces blackness at the end of stream and dont change count of frames.

But I wanna use 2-pass (mode=4 stats -> mode=5 work) because i run batch and dont want to crop end of every file manually

Maybe exists some option that I havn't set or i've found a bug?

tritical

7th May 2010, 15:55

Could you provide an exact full script that causes the issue? I'm not sure how tdecimate could be leaking memory since in mode 5 it doesn't allocate any memory during frame requests... only during script initialization. Does the memory issue happen if you add setmemorymax(64) to the script (i.e. is this 1-2MB per second just due to avisynth's cache filling up at the beginning).

D3C0D3R

11th May 2010, 11:50

>>setmemorymax(64)
yes, i did it at immediately when i found this leak. didnt help.

>>> (i.e. is this 1-2MB per second just due to avisynth's cache filling up at the beginning).
no, it grows all time during encode and finally eat all 3Gb :( and throw Exception

here my a bit simplified script that causes leak

common init part

src = "s02e01.avi"
metricStats = "metrics_01.txt"
mkvTimeCodeOut = "mkv-timecodesfile_01.txt"
SetMemoryMax(80)
LoadVirtualDubPlugin("MSU_cartoon_restore.vdf","MSUCartoonRestore", 0)
AviSource(src,audio=false)
Lanczos4Resize(width*2, height*2)
ConvertToRGB32()
MSUCartoonRestore("bilateral", 1, 56, 36, 1)
spline64resize(width/2, height/2)
ConvertToYUY2()

1st pass

tdecimate(mode=4, output=metricStats)
crop(0,0,8,8)

2nd pass

tdecimate(mode=5, hybrid=2, vfrDec=1,input=metricStats, mkvOut=mkvTimeCodeOut, vidThresh=15,dupThresh=10, vidDetect=1, cycleR = 1, cycle=2)

Zep

24th September 2010, 18:28

1280 x 720p source
Set MT build 2.5.8

=================================

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)

116 FPS

=================================

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)
Selecteven()

58 FPS

=================================

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)
Selecteven()

TDecimate(mode=0,cycleR=1,cycle=5)

39 FPS

=================================

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)
Selecteven()

BilinearResize(320,180)
TDecimate(mode=0,cycleR=1,cycle=5)

28 FPS

More time used to resize down than decimate at full size. interesting!
Though 47 FPS if I MT() the resize but that is for another thread.

=================================

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)
Selecteven()

ResizedVideo=BilinearResize(320,180)
TDecimate(ResizedVideo,mode=0,cycleR=1,cycle=5,clip2=last)

3.1 FPS

I thought it would be around 28 FPS like the previous example.
Is this a bug? Did i do something wrong?

Thanks

tritical

24th September 2010, 21:40

Without looking into it in depth, I'd guess it's a cache issue. Try:

mpeg2source("D:\whatever.d2v",idct=5)
ChangeFPS(last,last,true)
Selecteven()

ResizedVideo=BilinearResize(320,180)
TDecimate(ResizedVideo,mode=0,cycleR=1,cycle=5,clip2=last.blur(1.0,0))

Or replace blur(1.0,0) with some other fast filter.

Zep

25th September 2010, 14:19

Zep

25th September 2010, 14:28

ok just now i tried

TDecimate(ResizedVideo,mode=0,cycleR=1,cycle=5,clip2=ChangeFPS(last,last,true))

and FPS is at 9 FPS

that is the only filter I have passed thus far that has helped.
Since that filter grabs 10 frames and caches them it appears it is
as you said a cache issue.

mastrboy

8th July 2011, 11:37

Any chance we will see a updated version of TFM with support for .dgi files (DGDecNV) similar to the support already implemented for d2v files?

Lyle_JP

8th July 2011, 19:39

Any chance we will see a updated version of TFM with support for .dgi files (DGDecNV) similar to the support already implemented for d2v files?

I have no trouble using TFM with DGDecodeNV as my source filter. :confused: You just need to set field order manually.

mastrboy

9th July 2011, 11:41

Not meaning as a source filter, off course that works. TFM has the parameter called d2v="filename", which aids in the IVTC process, currently it only seems to support the format from DVD2Avi and DGIndex d2v files.

From the manual:

d2v -

This option is intended to be used if you are using an mpeg2source() with a d2v file.
It sets the name and path to a d2v file, which TFM will analyze to see if there are any
illegal field order changes and optionally set the order parameter using the field
order of the d2v file. If the d2v file is found to have illegal field order transitions,
TFM will create a fixed d2v file with the string "-FIXED" attached to the end of the file
name. The new file will be located in the same directory as the original. You can then
use this fixed d2v file for processing. If the order parameter is set to "-1" then TFM
will detect the field order from the d2v file and set the order parameter to match. Depending
on the value of the "flags" parameter, TFM will also use the d2v info for field matching
and will pass info from the d2v on to tdecimate to help aid duplicate detection and hybrid
detection.

*NOTE: This option currently supports all d2v formats that I am aware of... which
include: dvd2avi 1.76, 1.77.3 and its variants, all dvd2avidg versions, and
all dgindex versions.

example => TFM(d2v="myd2v.d2v")

Default: "" (String)

flags -

Controls how much of the info from the d2v file is used when the "d2v" parameter is set.
Possible options:

0 - Check the d2v file for illegal transitions and set the order parameter if it
is not already manually set. Also, pass on rff flag duplicate info to
tdecimate.
1 - Same as 0, plus use the trf flags for field matching in film sections (sections
where the trf flags follow the 012301... pattern)
2 - Same as 1, but use the trf flags for field matching in all areas (doesn't have
to be in 0123 pattern) (very much not recommended!)
3 - Same as 0, but don't pass on any info to tdecimate (i.e. only set order and check
for illegal transitions)
4 - Same as 1, but d2v matches are checked for being combed. If a d2v match is detected
as combed then tfm uses its own matching routine for that frame.
5 - Same as 4, but d2v matches are only checked for being combed around scenechanges.

VERY IMPORTANT (MUST READ): For options 0, 1, 2, 4, and 5 to work correctly, tfm/tdecimate
must either immediately follow the mpeg2source() command or
any filters inbetween them must not modify the order or number
of fields in the stream in any way. Or use a trimIn file to
tell TFM what frames have been discarded.

Default: 4 (int)

Stereodude

27th November 2011, 23:58

I just wanted to post a thank you here for tritical for the great work on TIVC (tfm / tdecimate). The ability to use one clip as the basis for another's decimation with TDecimate ( clip2= ) really helped out my workflow on a few clips I was working on getting back to p24.

Thanks! :cool:

manolito

28th November 2011, 00:38

I.E. optimum quality vs. speed solution

Just want to find out if this line (posted by tritical a few years ago) is still state of the art:

yadifmod(edeint=tdeint(mthreshL=0,mthreshC=0))

A simple TomsMoComp or Yadif has too many quality issues, and all those ultra high quality (and ultra slow) deinterlacing scripts are just unusable for my rather slow machine. I always liked the quality and the speed I got from the above command. Is there anything new out there which surpasses it in terms of speed vs. quality?

Cheers
manolito

tritical

28th November 2011, 19:55

A simple TomsMoComp or Yadif has too many quality issues, and all those ultra high quality (and ultra slow) deinterlacing scripts are just unusable for my rather slow machine. I always liked the quality and the speed I got from the above command. Is there anything new out there which surpasses it in terms of speed vs. quality?

My recommendation would be QTGMC (http://forum.doom9.org/showthread.php?t=156028) with the slowest preset that meets your speed requirements. I don't think there is much question that QTGMC is the way to go for deinterlacing in Avisynth nowadays. Getting it setup can seem difficult, but Vit has made it very easy if you read the first post. If you can't find a preset that betters your current script in speed/quality report back :).

manolito

28th November 2011, 21:57

Thanks a lot for the tip, I will give it a thorough test run tonight...

Cheers
manolito

manolito

29th November 2011, 01:58

Alright, here's what I've come up with:

First of all, setting up QTGMC really was a little difficult, because my CPU (P3 Coppermine) does not support SSE2. Some of the plugins Vit provides are SSE2 plugins, and of course I got a floating point error. So I had to replace the SSE2 plugins with different versions while still trying to not brake LSFMod or LimitedSharpenFaster. Took me some time, but it works now.

Now for the speed tests:

I took an interlaced TFF DVD source, no filters except the deinterlacer, feeding it to QuEnc. These are the speeds for the different deinterlacers:

TomsMoComp: 11.77 fps
Yadif: 11.02 fps
YadifMod(edeint=tdeint(mthreshL=0,mthreshC=0)): 6.34 fps
QTGMC very fast: less than 1 fps
QTGMC draft: 4.65 fps

QTGMC is only usable with Preset="Draft" on my machine, and I do have my doubts if the resulting quality can match the quality of "yadifmod(edeint=tdeint(mthreshL=0,mthreshC=0))". I don't have the knowledge to analyze the QTGMC script enough to understand what the "Draft" preset really does, but it seems to use Yadif with Yadif's own spatial prediction, and I have the feeling that YadifMod using TDeint's prediction might do a better job....

Cheers
manolito

-Vit-

29th November 2011, 02:32

"Draft" is an extremely cut-down version of the core TGMC algorithm. It doesn't use Yadif, it performs a motion-compensated temporal binomial smooth to remove shimmer, but it only uses a bob as an interpolate, does not mask against creating blur and does no resharpening. As it's name implies it's not intended for final usage. QTGMC only really becomes useful at "Super Fast" and above IMO.

No offense intended, but you can't really ask for the "state of the art" if you intend to use a Pentium 3.

OvejaNegra

4th August 2012, 10:46

Hi: I'm trying to create a tool for simplify the process of creating VFR with 59.97, 29.97 and 23.97 fps using the metrics output of tivtc.
Can anyone explain to me what the metrics of TDecimate means:
0 0 0
1 1824 470069
2 1296 322363
3 1328 316633
4 1563 299634
5 2136 447795
6 2617 397772
7 3621 471805
8 3872 508060
9 5221 487823
10 5963 546645

Also, what the h matching means on TFM metrics?

And one more question:

(sorry the quote button does not works on my explorer, probably the antivirus is blocking scripts on the page):

This is from tritical:
"It might actually be easier to create a separate filter/program to do it based off tfm stat file and tdecimate stat files from tfm output and bobbed output."

"tfm output and bobbed output" mmmm why? and how can i give two outputs to tdecimate (or is actually about apply bob to the tfm output and give it to tdecimate? that is a mess i think? can anyone elaborate a little more please.

english is not my language, maybe i'm not undertanding properly.
thanks

cretindesalpes

4th August 2012, 11:52

Can anyone explain to me what the metrics of TDecimate means
"Each line will include a frame number, plus the difference metric, and the scene change metric." IIRC the metrics are not scaled, they are more or less proportional to the picture area (they are sums of absolute differences or something related).

Also, what the h matching means on TFM metrics?
From the TDecimate source code:

#define ISDB 0x00000005 // l = (deinterlaced c bottom field)
#define ISDT 0x00000006 // h = (deinterlaced c top field)

OvejaNegra

4th August 2012, 17:44

And how TDecimate goes from something like:
1 1824 470069

To calculate the video threshold or dup threshold (wich is something like 1.1 , 2.8, etc).

I just want to parse a tdm metrics file to get the video and film sections by myself. tfm metrics are clear to me but not the tdm.

Another question please:
why tfm has out of order matching modes like:
5 = 3-way match + 4th/5th matches on combed (p/c/n + u/b)

because hard telecine sources have field order changes because bad edits or cuts?
but such changes wont produce jumpy movement when displaying on tv set?
or to reformulate my question: Why mode 0 is not enough?

And another one:

Why tdm detects 17 fps ranges? (i'm talking about mode 5 with timecodes output).
Thanks.

j7n

2nd October 2012, 13:29

I just got a recurring error in Avisynth v2.5.8 and TIVTC 1.0.5:

TDecimate: mode 2 internal error (ret less than 0). Please report this to tritical ASAP!

I was trying to trim and further process the output of TDecimate(mode=2,rate=25.0,maxndl=30,m2PA=true,chroma=false). The error occurred after the end of the decimated clip.

Whops. I was trying to request more frames than there actually were after decimation. Scaling back the trim range by a few frames did away with the error.

I could reproduce the same message just by having a script with two lines and playing it from start to finish. The source was progressive with dupe frames, running at 29.97 fps.

SubJunk

1st April 2013, 00:01

I'm trying to get rid of some residual combing. Here's the result after just doing TFM + TDedimate:

http://i.imgur.com/evbdoDn.png

I tried default settings and mode=1 but no change, the only thing that fixed it was cthresh=-1.
Other than taking longer to process, are there any problems with using cthresh=-1? Could it reduce quality? Any suggestions?

DeathAngelBR

1st April 2013, 04:10

I used to use 2-pass encodes with retarded awful sources. Something like this:

# 1st pass
tfm(d2v=_d2v,order=-1,slow=2,mode=4,pp=1,cthresh=5,mi=20,blockx=128,blocky=128,output="tfm.txt")
tdeint(slow=2,mi=20,cthresh=5,blockx=128,blocky=128)
tdecimate(hybrid=2,mode=4,expp=true,output="decimate.txt")

# 2nd pass
tfm(d2v=_d2v,order=-1,slow=2,mode=4,pp=1,cthresh=5,mi=20,blockx=128,blocky=128,input="tfm.txt",ovr="over.txt")
tdeint(slow=2,mi=20,cthresh=5,blockx=128,blocky=128)
tdecimate(hybrid=2,mode=5,expp=true,input="decimate.txt",mkvout="mkv.txt")

OvejaNegra

3rd April 2013, 18:57

Usually, using cthresh=1 is enough for me to detect all the residual combing (on anime sources).
Using cthresh=-1 sets all teh frames as interlaced and applys deinterlacing on all the frames.

SubJunk: ARE YOU USING COLOR MATRIX?
If you are usign it, please set the interlaced parameter to true, because if dont, it creates those artifacts if the source is interlaced.

Try this:
#this is a deinterlacer that gives very good results, even on false positive detection
interp = full.separatefields().eedi2(field=-2)
deint = full.tdeint(mode=2,edeint=interp)
TFM(display=false,micout=0,mode=6,pp=2,slow=2,mChroma=true,chroma=false,cthresh=1,micmatching=0,clip2=deint)

#set chroma=false is your source has many chroma problems like rainbow or dot crawl

Good luck

SubJunk

6th April 2013, 05:36

Thanks guys :) Neither of them worked though. Anyway the rest of the clip is fine with the regular defaults, it's just that one part which only lasts for less than a second so it will be OK. Thanks anyway!

osgZach

12th April 2013, 20:40

If you set cthres=-1 then it treats all frames (pixels really) as combed and would be deinterlacing every frame in the clip. This can certainly lead to quality loss if you are throwing out good data.

The proper thing to do is to use an overrides file and specify the frame numbers (or frame range) in question for deinterlacing.

sikboy1029

14th April 2013, 08:07

Hey guys, you mind helping my out on the script for this one? The interlacing is pretty significant & I can't get rid of it.

http://www.mediafire.com/?u2buiev9awsgsdt

LigH

14th April 2013, 08:23

One of your mistakes was uploading not the original video, but the result of a failed filtering; yet, a frame-by-frame forward stepping still reveals a 3-2 pattern; and it has NTSC framerate. Therefore I would expect it being telecined (3:2 pulldown). In this case, "Deinterlacing" is wrong, "Inverse Telecine" (IVTC) is right.

sikboy1029

14th April 2013, 08:44

It's actually a cap of a netfix stream, been noticing the same issue with a lot of the animation they have on the service & it was bugging me. You would think they would have some sort of QA...it is visible with the naked eye watching it on TV & very distracting...I did try this

Telecide(guide=1)
Decimate(cycle=5)

Any recommended change?

johnmeyer

15th April 2013, 00:14

I have found that captures from Netflix often contain dropped frames, so you may need to deal with that. What surprises me is that the original was sent as 29.97 rather than 24 or 23.976. Did you force your capture card to capture 29.97? If the original was normal NTSC film rate (23.976), I have always found that this is what Netflix sends. Therefore, perhaps you have the wrong capture settings.

sikboy1029

15th April 2013, 20:13

I also capped in 23.976 & it looks the same, when you say I need to deal with the dropped frames what do you mean?

johnmeyer

15th April 2013, 23:37

I also capped in 23.976 & it looks the same, when you say I need to deal with the dropped frames what do you mean?I said you may need to deal with dropped frames. I have observed dropped frames in video I have captured from the analog port on my XBox. They do not occur at a regular interval, and probably depend on many things, including my local connection speed as well as issues at the Netflix server. Some services, like Hulu, can be even worse.

I don't know what more clarification I can provide as to what I mean: a dropped frame usually results in a discontinuity in the video (a "jump") and is usually followed by a duplicate frame in order to keep the sound from drifting out of sync.

Netflix may also be using variable frame rate encoders that respond to connection speed changes, in which case I don't know what to recommend.

Lenchik

18th October 2013, 21:30

Can anyone create build of TFM and TDecimate (or whole TIVTC package) that supports YV24, please? Or maybe there is one already?

turbojet

20th November 2013, 09:20

Currently there doesn't seem to be any way to multithread tdecimate. Would anyone have interest in trying to implement it? Tritical has said in the past that openmp might work.

Also some combed frames slip through with tfm default mode=1, while they don't with mode=3 with no noticeable drop in speed. Any consideration on changing the default mode?

ChiDragon

21st November 2013, 00:52

Sure you have fewer combed frames, but the frames you get are just extra duplicates that can't be decimated normally, no?

johnmeyer

21st November 2013, 01:12

Currently there doesn't seem to be any way to multithread tdecimate. Would anyone have interest in trying to implement it? Tritical has said in the past that openmp might work.I don't think that TDecimate is particularly CPU intensive and therefore I don't think multi-threading would help much. The only time I've found TDecimate to be slow is when using really large Cycle/CycleR values, but that is a different problem, I think.

turbojet

21st November 2013, 01:58

Tritical mentioning openmp (http://forum.doom9.org/showthread.php?p=1405365#post1405365) there's also another good idea in that message that's been unrealized.

Sure you have fewer combed frames, but the frames you get are just extra duplicates that can't be decimated normally, no?

Nope, all clean, no dupes. I'll hunt for a sample, with any luck at all will have one by the end of the week.

I don't think that TDecimate is particularly CPU intensive and therefore I don't think multi-threading would help much. The only time I've found TDecimate to be slow is when using really large Cycle/CycleR values, but that is a different problem, I think.

When it's encoding HD on a typical 2/4/6/8 core cpu it can keep the cpu loaded but when encoding smaller resolutions or with more cpus (untested) there's a lot to be desired.

Here's some 1080i to 720x404 on FX8320 results:
tfm() 51.15 fps, 50-60% cpu
tfm().tdecimate() 36.64 fps 40-50% cpu
setmtmode(2,4).tfm() 66.29 fps 95-100% cpu
setmtmode(2,4).tfm().tdecimate() 29.79 fps 30-40% cpu
nnedi3() 59.51 fps 95-100% cpu

Sorathread/threadrequest used between tfm() and tdecimate() can give ~5% fps and cpu increase that's the only increase I've been able to achieve. Openmp was a huge increase in nnedi3, if it gave half the returns with tivtc it would be a much welcome increase. If tfm().tdecimate() used 100% cpu in this case is 70-80 fps a good estimate?

turbojet

3rd December 2013, 23:04

I haven't been able to find another source where tfm(mode=3) helps yet but I did find one where it causes missing frames.

Also after some testing it doesn't seem like tdecimate is the bottleneck but rather tfm(). Using telecide() or uncomb() with tdecimate() greatly increases fps and cpu usage.

Stereodude

26th January 2014, 20:27

I realize the TIVTC package hasn't been updated in a long time, but I'm going to make a feature request anyhow...

It would be nice when if TDecimate mode=5, hybrid=2 (2nd VFR pass) was more verbose with display=true. Something similar to what TDecimate does for mode=0, hybrid=3. I do the first pass with TFM and TDecimate and make the necessary output files and feed them into the 2nd pass. Easy enough, but on the 2nd pass I have no easy, displayed for me on the video, visibility into the metrics calculated in the first pass that determine what frames are dropped or when it switches in or out of video/film mode. As a result it's hard to visually tune the vidThresh or dupThresh parameters.

johnmeyer

27th January 2014, 00:07

What I do is to use the "output" parameter. It provides a file in Pass1 that gives you all the metrics.

You might also have a look at the "debug" parameter.

Stereodude

27th January 2014, 01:20

What I do is to use the "output" parameter. It provides a file in Pass1 that gives you all the metrics.I'm aware the information is ultimately in the file, but it's a huge pain in the butt to find the frames you're interested in and look at a file of numbers without the context of seeing the video frames at the same time.

You might also have a look at the "debug" parameter.FWIW, in TDecimate mode=5 The information that comes via the debug parameter is as useless as in the information displayed on the screen.

johnmeyer

28th January 2014, 00:29

I'm aware the information is ultimately in the file, but it's a huge pain in the butt to find the frames you're interested in and look at a file of numbers without the context of seeing the video frames at the same time.That is most definitely true. I just wanted to make sure you knew that the information was available.

I wonder ... is there an "overlay" plugin that could that this output file, which has the frame number as the first parameter, read it, and then display the parameters onto each frame?

Stereodude

28th January 2014, 01:27

That is most definitely true. I just wanted to make sure you knew that the information was available.

I wonder ... is there an "overlay" plugin that could that this output file, which has the frame number as the first parameter, read it, and then display the parameters onto each frame?Not sure, but it still wouldn't tell which frame was dropped, and the metrics for the removed frame.

turbojet

13th March 2014, 08:41

TFM(clip2=nnedi3())
a=last
crop(0,0,0,-height/6).TDecimate(mode=3,clip2=a,hybrid=2,mkvout="timecodes.txt")

I'm getting a runtime error with this any idea why?

Also getting crc errors 5 of 5 times with
#pass1
TFM(clip2=nnedi3(),output="matches.txt").TDecimate(mode=4,output="metrics.txt",hybrid=2)
#pass2
TFM(clip2=nnedi3(),input="matches.txt").TDecimate(mode=5,input="metrics.txt",tfmin="matches.txt",mkvout="timecodes.txt",hybrid=2)

osgZach

16th March 2014, 18:20

CRC error usually means your metrics do not match your file or something like that.

Try removing the hybrid=2 in your first pass? If its just metrics it shouldn't be used anyway, if I understood the manual correctly.

Or perhaps it has something to do with the way you are using nnedi3 as your clip2?

edit:

I tested out your commands, running a first pass in Vdub (analyze video)
And then a 2nd pass as a rendered output.

Didn't get any CRC errors with the source clip I used.. Maybe its your source filter? Are you using DirectShow or something? It's possible you might not be getting frame accurate input that is being altered in some way?

turbojet

16th March 2014, 21:36

Did the first command (1 pass vfr) work for you?

According to readme, hybrid is ignored in mode=4 so that shouldn't be an issue but can be removed.

I usually use DSS2 but changing to lsmash had no effect, the error had identical crc's.

If tfm(output=matches.txt) and tdecimate(tfmin=matches.txt) are removed it works. Readme says tfmin is required for mode 5 but it runs without however the output is still interlaced. When working with 60p sources I never use tfm and vfr works fine then.

Somehow 2 pass is working now, I removed clip2=nnedi3() which didn't work on the first try but did on the second try. Now timecodes don't match the video.

osgZach

19th March 2014, 14:16

Well like I said, yes both passed worked fine for me.. exactly as you had posted them. If you were referring to something else ( different mode) I didn't test that.

I'm not familiar with Lsmash or DSS2, but generally when I am working with telecined content my sources are DVD's so I always index with DGindex and decode w/ the .d2v output and dgdecode.

If the source file isn't mpeg/can't be indexed I'd try getting it into an intermediate AVI container. If it needs to be decombed/deinterlaced you could just bob it with a good filter like QTGMC, or TGMC_mod, with a .SelectEven() and then save that output. Then run 1stpass stats for Tdec on the intermediate AVI, then run your 2nd pass to another output (intermediate for more filtering, or straight into your output like x264, etc) to see if you could get your VFR that way?

I haven't tested this, but I would assume it would work to some acceptible degree

turbojet

20th March 2014, 22:49

I was able to get 2 pass vbr working. The mismatched frame count of timecodes file and video was an issue of calling mp4fpsmod, it works fine in an mkv.

With single pass after stripping the function I was able to get an understandable error, instead of a crash. It needs linear access but I haven't manage to get that. Tried ffvideosource(seekmode=-1 and 0) directshowsource(seekzero=true,seek=false) both are supposed to give linear access. Couldn't find a way to get it with lsmash or dss2, my preferred source filters. Any ideas?

osgZach

22nd March 2014, 01:46

Try Vdub with ffmpegsource or DirectShow input drivers.

These days when I process Blurays that's what I use (ffinput driver) to load the source files for filtering with Neat Video

turbojet

23rd March 2014, 22:01

It must have been an issue with the source. This worked fine on a few other sources:

DSS2("source.mpg",preroll=60, lavd="hm1")
TFM(clip2=nnedi3())
a=last
crop(0,0,0,-height/6).TDecimate(mode=3,clip2=a,hybrid=2,mkvout="timecodes.txt")

turbojet

1st April 2014, 00:24

Since development seems to have ceased years ago, I don't know how much this will help. I came across a clip that tivtc removes the wrong frames but decomb and madvr ivtc remove the correct ones. It's a typical 3:2 pattern http://180upload.com/jeqngmb3uy7p. It is a little crude, basic cable, best not to listen to at work or around kids.

Guest

1st April 2014, 00:29

Since development seems to have ceased years ago, I don't know how much this will help. I came across a clip that tivtc removes the wrong frames but decomb and madvr ivtc remove the correct ones. It's a typical 3:2 pattern http://www.mediafire.com/download/z5kgg4ysc9j3a60/tivtc_issue.mpg. It is a little crude, basic cable, best not to listen to at work or around kids. The link does not work for me. Please correct it only if it doesn't violate rule 4, no profanity. Thank you.

turbojet

1st April 2014, 06:05

Mediafire filter doesn't comply with fair use, uploaded it to another site and updated it. It's only talk of human anatomy.

Okeeffe1881

15th August 2014, 07:45

I use this script

DirectShowSource ("F: \ Asi - Against Destiny \ ASI \ Asi - Against Destiny Ep 2 RoSuB HD.ts", fps = 25.000, convertfps = true, audio = true) .ConvertToYV12 ()

Video format is .ts video resolution is 1920x1080i and want to conver it in 1920x1080p and I want to delete Interlaced
Any idea?

LigH

15th August 2014, 18:22

Don't do that. After using DirectShowSource(..., convertfps=true ...), the previously existing field/frame structure will be destroyed so that no deinterlacer will work anymore. Serious AviSynth users will always try to prefer native AviSynth source plugins, and avoid norm conversions if applicable. Most modern HD TV sets will adapt to all available TV norms.

Okeeffe1881

16th August 2014, 11:34

Can you please tell me in more detail, or link with more information.
Thanks

LigH

16th August 2014, 16:03

If I knew you would understand German, I would link you to "exotisches Interlacing" by scharfis_brain; unfortunately, I don't know which similarly comprehensive explanations of interlacing and good or bad norm conversions exist in English... In brief: If you really have regular interlacing you want to remove, ensure that your source will be read as exactly as possible; DirectShow cannot guarantee that, there may be decoders which already try to "deinterlace" with very bad-because-fast algorithms...

DirectShowSource is disfavoured by AviSynth purists for many years now. Hard to miss so many threads about the disadvantages of a source filter relying on unreliable sets of filters every user may have a different set of and different settings of.

Preferable alternatives should be: L-SMASH Works as free-of-charge software-only solution, or DGDecNV as unexpensive interface to the hardware decoder chip of Nvidia cards generation 8+.

PeterYu

11th September 2014, 13:59

The cArray's size is 4 times the block number not equal to block number.

"cArray = (int *)_aligned_malloc((((vi.width+xhalf)>>xshift)+1)*(((vi.height+yhalf)>>yshift)+1)*4*sizeof(int), 16);"
in TFM.cpp, corresponding in TFMYV12.cpp, TFMYUY2.cpp
"cArray[temp1+box1+0] += sum;
cArray[temp1+box2+1] += sum;
cArray[temp2+box1+2] += sum;
cArray[temp2+box2+3] += sum;"

Can someone please tell me why?

Thanks!

StainlessS

11th September 2014, 15:38

@ Ligh,

Here's the best I can do (EDIT: English Translation) for "'exotisches Interlacing' by scharfis_brain" (exotic Interlacing),
Probably a temporary link:

EDIT: LINK REMOVED:

Several links included in zip (120KB).

EDIT: See DATA Folder via Mediafire Link in sig below this post.
Will now be permanently available.

LigH

11th September 2014, 19:58

:eek: :thanks: Great, I am impressed how much leisure time you had... :cool:

StainlessS

11th September 2014, 20:50

I did it about 2 years ago, I Asked S_B if he minded if I posted it (PM or post in thread, cant remember), never got a reply so left it.
Hardest part was aligning all of the symbols and letters representing frames, they were all over the place after Google translation.
Corrected what I could but was lost for the meaning of some sentences.

StainlessS

19th September 2014, 16:25

Exotic Interlacing (English translation) by Scharfis_Brain will now be available via my Mediafire account (in sig below this post) in the DATA
folder. Has had 57 downloads so is quite popular, perhaps a good candidate for the Wiki if someone could correct
any mis-translations and fix the sentences that I could not figure out.
Link deleted in post #1266 above.

turbojet

17th October 2014, 19:17

Sparktank

17th October 2014, 19:49

Would anyone be so kind as to add dgi support to tfm's d2v parameter? It would speed things up and overcome some potential ivtc issues.

I don't want to minimize the workload but there's only a few instances of d2v outside of tfmd2v.cpp. I don't think vast c++ knowledge is needed, just a bit more than I have which is almost none.

If something is needed feel free to ask. TIA.

+1 for DGdecNV support.

I just emailed tritical and he currently has no plans to update TFM himself.

I'll ask to see if ex-Neuron knows much to help with this.

Seedmanc

27th July 2015, 00:54

Doesn't 100fps.com do a better job at explaining interlacing? At least compared to autotranslation from a foreign language that we have here.

ChiDragon

27th July 2015, 07:08

The "exotic interlacing" page explains norm conversions, not just interlacing. And 100fps.com misdiagnoses some things like improper 4:2:0 conversion.

Sparktank

13th September 2015, 06:44

DGdecNV support aside, any chance of a modern update with something newer then 2003?

Avisynth Info Tool 1.3.1 gives error: R6034

C:\AVS\AVS_Ver\AVS260_MT\plugins\TIVTC.dll
Timestamp: January 17, 2008, 14:01:48
MD5 Hash: 0416E3D06AD70685C6ECE448713928AE
DLL Dependencies: KERNEL32.dll
Linker version: 7.10 (VS2003)
Plugin version: AVS 2.5 Plugin
FILEVERSION: 1.0.5.0
PRODUCTVERSION: 1.0.5.0
Language: English (United States)
Comments:
CompanyName:
FileDescription: TIVTC v1.0.5 for Avisynth 2.5.x
FileVersion: 1, 0, 5, 0
ProductVersion: 1, 0, 5, 0
InternalName:
LegalCopyright: Copyright (C) 2004-2008 Kevin Stone
LegalTrademarks:
OriginalFilename:
PrivateBuild:
ProductName:
SpecialBuild:

I got every version of MSVS redistributables installed. Error only happens when using AIT but no errors while actually using it in anything else.

Groucho2004

13th September 2015, 09:29

Avisynth Info Tool 1.3.1 gives error: R6034

...

Error only happens when using AIT but no errors while actually using it in anything else.
Please try this version (https://www.dropbox.com/s/h2bl44k2f6u00dx/AVSInfoTool.7z?dl=0) of AIT.

Sparktank

13th September 2015, 09:33

Please try this version (https://www.dropbox.com/s/h2bl44k2f6u00dx/AVSInfoTool.7z?dl=0) of AIT.

Still has r6034 error. :(

Groucho2004

13th September 2015, 09:38

Still has r6034 error. :(
Please post both AIT logs. I can't reproduce this. Have you tried with just that DLL in your auto-load directory?

Groucho2004

13th September 2015, 10:54

DGdecNV support aside, any chance of a modern update with something newer then 2003?
Here it is (https://www.dropbox.com/s/mchng7jokx0wwn8/TIVTC.7Z?dl=0) built with VC10. You'll need the runtimes for VC2010.

Sparktank

13th September 2015, 10:55

I got every version of MSVS redistributables installed. Error only happens when using AIT but no errors while actually using it in anything else.[/QUOTE]

So I isolated and it turns it really wasn't tivtc. It was "toon".
I even downloaded and re-installed the redist but it just went through so quickly I don't know if it actually installed.

Avisynth info log: http://www.mediafire.com/view/ajzlcw6j6pw3kat/AvisynthInfo.txt
Full plugin info: http://www.mediafire.com/view/971sdh9yprhc5fl/AvisynthPluginInfo.txt
Isolated DLL's for just Toon + AwarpSharp2: http://www.mediafire.com/view/c77ieaul1qhxrik/AvisynthPluginInfo_isolated.txt

This is the one I had downloaded, Toon v1.1
http://avisynth.nl/index.php/Toon

Sparktank

13th September 2015, 10:58

Here it is (https://www.dropbox.com/s/mchng7jokx0wwn8/TIVTC.7Z?dl=0) built with VC10. You'll need the runtimes for VC2010.

Thanks for the update, though! :)

bilditup1

7th June 2016, 22:31

Here it is (https://www.dropbox.com/s/mchng7jokx0wwn8/TIVTC.7Z?dl=0) built with VC10. You'll need the runtimes for VC2010.

Hmm. appears to be dead now - do you think you could put this up somewhere again, please?

Groucho2004

7th June 2016, 23:01

Hmm. appears to be dead now - do you think you could put this up somewhere again, please?
I added it to my "Avisynth Stuff (http://forum.doom9.org/showthread.php?p=1759271#post1759271)" thread.

bilditup1

8th June 2016, 01:16

I added it to my "Avisynth Stuff (http://forum.doom9.org/showthread.php?p=1759271#post1759271)" thread.

Ah, thanks a lot.

Katie Boundary

11th June 2016, 00:24

The missouri.edu server seems to be down at the moment. Has anyone mirrored the non-VC10 versions of these?

Reel.Deel

11th June 2016, 00:55

The missouri.edu server seems to be down at the moment. Has anyone mirrored the non-VC10 versions of these?

http://avisynth.nl/index.php/External_filters#IVTC_.26_Decimation

Katie Boundary

11th June 2016, 01:23

http://avisynth.nl/index.php/External_filters#IVTC_.26_Decimation

"The requested URL /~kes25c/TIVTCv105.zip was not found on this server."

Maybe because that page just has a link to the copy on the missouri.edu server, which is down...

Reel.Deel

11th June 2016, 01:37

"The requested URL /~kes25c/TIVTCv105.zip was not found on this server."

Maybe because that page just has a link to the copy on the missouri.edu server, which is down...

Oops, here's the correct link: http://web.archive.org/web/20140420181748/http://bengal.missouri.edu/~kes25c/TIVTCv105.zip.

Edit: not sure why the archive.org link on the wiki is no longer working, it was when I added it not too long ago. :confused:

Edit 2: updated the wiki.

Katie Boundary

11th June 2016, 05:00

Ooh, nice! I shall add it to my regrowing library of tools.

Katie Boundary

10th January 2017, 05:34

I'm confused. This part:

TDeint will try either weaving the average of f and i, or simply f or i

...seems to contradict this:

Second, this filter is using a new form of modified ELA interpolation that I have been working on recently. It takes into account the direction of the normal line to the gradient vector when deciding in which direction to average, and attempts to tune the interpolation so that it can adapt to any edge direction within its range.

So... does it average two pixels like linear interpolation, or does it perform wacky edge-detection motion-compensation magic?

Also, how does it handle situations in which neither f nor i looks like what the "target" pixel should be, a common situation in 60hz content, particularly with animated text? YADIF has a spatial interlacing check for this.

EDIT: I performed a side-by-side test with TDeint(mode=1) and YADIF(mode=1), running the Andromeda episode "Ouroboros" through each of them, downscaling to 624x352, and then exporting to an Xvid Full Quality First Pass. File sizes were 739 MB for TDeint and 788 MB for YADIF, indicating that TDeint is quantifiably less "noisy".

https://wowkent.co.uk/wp-content/uploads/2015/05/Maidstone-Museum-premium-listing.jpg

pinterf

21st April 2017, 19:23

Hi, after having spent some weeks (didn't know that this would take this much time :) ) on porting TIVTC to 64-bit (and an SSE2 capable 32 bit version), finally finished the first step of the update.

Download TIVTC 1.0.6 (beta) (https://github.com/pinterf/TIVTC/releases)

32 bit users would also try it, it is faster than the original one, at least or my machine (not to mention the x64 version, which is much faster).

Since all inline asm was rewritten in simd intrinsics or C, along with new SSE2 additions, and none of the old mmx/isse code is running in this version, please don't kill your existing 1.0.5, treat it as a beta, though I was trying to test it until it gave identical results to the (fixed) original code. Feedbacks are welcome.

# TIVTC v1.0.6 (20170421)

This is a modernization effort on tritical's TIVTC (v1.0.5) plugin for Avisynth

**v1.0.6 (20170421) - pinterf**
- project migrated to VS 2015
- AVS 2.6 interface, no Avisynth 2.5.x support
- some fixes
- x64 port and readability: move all inline asm to simd intrinsics or C
- supports and requires SSE2
- MMX and ISSE is not supported, but kept in the source code for reference
- source code cleanups

**v1.0.5 (2008) - tritical**
- see old readmes

Future plans: support additional color spaces, now YV12 and YUY2 is supported

DJATOM

22nd April 2017, 10:22

It seems Tfm can't properly analyse with Prefetch and just skipping frames.
#TFM v1.0.4 by tritical
field = top
crc32 = 5dcb7f8a
4 c - [0]
8 c - [0]
12 c - [0]
16 c - [0]
20 c - [0]
24 c - [0]
28 c - [0]
32 p - [0]
...
TDecimate mode 1 is not working with Prefetch:
Error requesting frame 1199
TDecimate: internal error during pre-buffering (n1=1509,n2=1510,pos=0,nbuf.FrameSO=1505,nBuf.frameEO=1510)!
TDecimate mode 5 is slower with Prefetch (I think it's due to Tfm: ~140fps vs ~400fps on my HW).
I didn't checked other modes.

pinterf

22nd April 2017, 11:25

Thanks, the MT things did not change in this version, what mt mode is effective for that?
And some scripts would be wecome, there are so many parameters and combinations that I cant figure out the frequent use cases (and since I never had to use this plugin, nor have I experience with it)

DJATOM

22nd April 2017, 11:34

The main purpose of MT is fully working chain. TFM/TDec might not benefit from MT, but other filters do. Also about analysing: we should forbid non-sequential access if possible.
Ok, I'll give you my test case after work.

stax76

22nd April 2017, 11:59

Since I'm adding it to staxrip profile suggestions are welcome.

real.finder

27th April 2017, 00:16

TIVTC 1.0.6 is unstable in little complex script with 1080i, it's slower than the 1.0.5 and crash after few seconds

pinterf

27th April 2017, 07:26

How can I reproduce? If it is too complex then effective parameters would help.

real.finder

27th April 2017, 10:02

How can I reproduce? If it is too complex then effective parameters would help.

I see it show this message too https://s14.postimg.org/ohd4vits1/New_Avi_Synth_Script043157.png

a=ColorBarsHD(width=1440, height=1080)
a+a+a
converttoyv12
#~ ThreadRequest()
DecombUCF() (https://pastebin.com/GNX0UCrh)
#~ ThreadRequest()
Crop(0, 0, 0, -160).StackVertical(Crop(0, Height()-80, 0, 0)).TDecimate(1,clip2=last)
#~ ThreadRequest()
Spline36Resize(1280, 720)

this not crash but it will crash if I uncomment the ThreadRequest lines (in avs 2.6 ofc)

pinterf

27th April 2017, 10:49

...this not crash but it will crash if I uncomment the ThreadRequest lines (in avs 2.6 ofc)
Thanks. I need only a FrameCache plugin. I can't find the binaries, there is no link in http://avisynth.nl/index.php/External_filters

real.finder

27th April 2017, 10:54

Thanks. I need only a FrameCache plugin. I can't find the binaries, there is no link in http://avisynth.nl/index.php/External_filters

it's in warpsharp.dll (web.archive.org/web/20120212062428/http://vfrmaniac.fushizen.eu/seraphy_mirror/warpsharp/bin/warpsharp_20080325.7z)

pinterf

27th April 2017, 11:55

Reproduced, but so far it's not TIVTC 1.0.6 specific for me.

It crashes in
avs [error]: Avisynth: access violation at 0x00003CBC in C:\Program Files (x86)\AviSynth\plugins\TDeint.dll
attempting to read from 0x69706D6F
or from AvsMeter:
AviSynth 2.60, build:Feb 20 2015 [03:16:45] (2.6.0.5)
Avisynth: access violation at 0x00003CBC in C:\Program Files (x86)\AviSynth\plugins\TDeint.dll,
attempting to read from 0x00000000

AVS 2.6.0.5
Original TIVTC 1.0.5
TDeint 1.1 (2007) (crash above)
TDeint 1.1 (2012 version - rebuild(?)) (hang)

EDIT: Crashes also without ThreadRequest.

real.finder

27th April 2017, 12:23

pinterf

27th April 2017, 13:13

With the great help of real.finder:

New release:
TIVTC 1.0.7 (x86/x64) (https://github.com/pinterf/TIVTC/releases/tag/v1.0.7)
Please, still treat it as beta (due to moving all inline asm parts to simd intrinsics, plus new SSE2 parts), but of course feedback is appreciated.

**v1.0.7 (20170427)**
- fix crash in FieldDiff (in new SIMD SSE2 rewrite)

**v1.0.6 (20170421) - pinterf**
- project migrated to VS 2015
- AVS 2.6 interface, no Avisynth 2.5.x support
- some fixes
- x64 port and readability: move all inline asm to simd intrinsics or C
- supports and requires SSE2
- MMX and ISSE is not supported, but kept in the source code for reference
- source code cleanups

**v1.0.5 (2008) - tritical**
- see old readmes

pinterf

27th April 2017, 17:08

Tested four versions:
1.0.5 original
1.0.5 vc10 rebuild
1.0.7 with inline asm (my internal test build)
1.0.7 with simd intrinsics (release)
All 32 bits for comparison

The latter two is bit identical which is good news.

Speedwise: all same, vc10 build is slower by 4-5%.

The two 1.0.5 builds gave slightly different result.

1.0.7 build is showing differences to 1.0.5 on frame by frame comparison, they are almost the same, but it general 1.0.7 gave less false combed frames.

Tested on an interlaced anime clip, that I was given once in PM.

pinterf

30th April 2017, 07:34

New TIVTC build.
TIVTC 1.08 (beta (https://github.com/pinterf/TIVTC/releases))

(simd intrinsics rewrite fix)
Thanks to mizumanju for the report.

**v1.0.8 (20170429)**
- Fix: TFM PP=2 and PP=5 (Blend deint)

downloaded

5th June 2017, 15:18

When using with QTGMC with presets Medium to Very Fast it just crashes for me.

QTGMC with presets Slow+ works fine.

Regardless QTGMC preset works fine using http://www.mediafire.com/file/i2qtli1mxik/TIVTC_3-13-2010.rar .

cork_OS

5th June 2017, 16:20

When using with QTGMC with presets Medium to Very Fast it just crashes for me.
No problems with Xeon E3-1270 V3.

Groucho2004

5th June 2017, 17:12

When using with QTGMC with presets Medium to Very Fast it just crashes for me.Define crash. No error message?

downloaded

5th June 2017, 23:26

Preview on Avspmod trows a generic error "%d format: a number is required, not float." but it previews anyway.

Launching x264 on cli just makes process stop responding without any error msg. I'm available to debug it, but i need some help on what to do.

Groucho2004

6th June 2017, 07:05

Preview on Avspmod trows a generic error "%d format: a number is required, not float." but it previews anyway.I think that's an error Python throws so this is probably some Avspmod issue, not sure.

Launching x264 on cli just makes process stop responding without any error msg. I'm available to debug it, but i need some help on what to do.You should try running your script with AVSMeter (https://forum.doom9.org/showthread.php?t=173259) to see if that reveals any problems.

downloaded

6th June 2017, 13:10

AVSMeter 2.5.7 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2504, MT, x86_64) (0.1.0.0)

Number of frames: 30508
Length (hh:mm:ss.ms): 00:21:12.438
Frame size: 1274 x 712
Framerate: 23.976 (24000/1001)
Colorspace: i420

Frames processed: 501 (1000 - 1500)
FPS (min | max | average): 0.423 | 155004 | 17.31
Memory usage (phys | virt): 1306 | 1326 MiB
Thread count: 22
CPU usage (average): 32%

Time (elapsed): 00:00:28.943

Works fine. And yet it still crashes x264.

downloaded

6th June 2017, 13:13

pinterf

6th June 2017, 13:49

Yes,
AVSMeter -avsinfo
would definitely help. And that would answer some other questions, too, such as Avs version, 32 or 64 bits, etc.
My 1.08 build is SSE2 only, requires it and does not use higher processor features than that.

downloaded

6th June 2017, 15:25

AVSMeter 2.5.7 (x64) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2504, MT, x86_64)
VersionNumber: 2.60
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\xxxxxxxxxxxxxxxx\AviSynth.dll
Avisynth.dll time stamp: 2017-06-03, 21:06:38 (UTC)

[Plugin errors/warnings]
___________________________________________________________________________________________________________________________________________________________

No plugin directory references found in the registry.
Plugin auto-loading disabled.
___________________________________________________________________________________________________________________________________________________________

AVSMeter 2.5.7 (x64) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2504, MT, x86_64) (0.1.0.0)

Number of frames: 30508
Length (hh:mm:ss.ms): 00:21:12.438
Frame size: 1274 x 712
Framerate: 23.976 (24000/1001)
Colorspace: i420

Frames processed: 501 (1000 - 1500)
FPS (min | max | average): 0.423 | 155004 | 17.31
Memory usage (phys | virt): 1306 | 1326 MiB
Thread count: 22
CPU usage (average): 32%

Time (elapsed): 00:00:28.943

Works fine, but it still crashes with x264.

Groucho2004

6th June 2017, 15:57

pinterf

6th June 2017, 16:06

I suppose you are using 64 bit x264. Still, since you have no autoloaded plugins, I cannot tell from this avsinfo the DLL versions you are exactly using.
I tried to encode a qtgmc'd clip with similar frame dimensions and frame rate, but no crash at all. x264 x64 version of r2665

downloaded

6th June 2017, 16:54

@downloaded
Hard to say why it crashes with x264 but it doesn't seem to be a problem in the filter chain since it works with AVSMeter.

As for the missing plugin directory references - How exactly did you install Avisynth+ and how did you update to the latest version?

You should do a clean install as I suggested here (https://forum.doom9.org/showthread.php?p=1808637#post1808637).

I didnt install, i never did. I just use the dll directly on same dir as x264 binary and inside avspmod dir.

I suppose you are using 64 bit x264. Still, since you have no autoloaded plugins, I cannot tell from this avsinfo the DLL versions you are exactly using.
I tried to encode a qtgmc'd clip with similar frame dimensions and frame rate, but no crash at all. x264 x64 version of r2665

Yes, i'm using 64bit x264. I use AddAutoloadDir inside avs script instead of load plugins. I forgot a detail, maybe its important. Height its not mod4 so i addborders first and crop after decimate. Script follows:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
AddAutoloadDir("C:/xxxxxxxxxxxxxxxxxxxx")
ffvideosource("C:\xxxxxxxxxxxxxxxxxxx.mkv")
ConvertToYV12()
AddBorders(0, 2, 0, 0)
QTGMC(Preset="Very Fast",EdiThreads=2).selecteven()
tdecimate(cycleR=1,cycle=5)
Crop(2,2,-4,-2)
Prefetch(4)

Groucho2004

6th June 2017, 19:46

I use AddAutoloadDir inside avs script instead of load plugins.Ah, OK.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
AddAutoloadDir("C:/xxxxxxxxxxxxxxxxxxxx")
ffvideosource("C:\xxxxxxxxxxxxxxxxxxx.mkv")
ConvertToYV12()
AddBorders(0, 2, 0, 0)
QTGMC(Preset="Very Fast",EdiThreads=2).selecteven()
tdecimate(cycleR=1,cycle=5)
Crop(2,2,-4,-2)
Prefetch(4)
Have you tried without the Prefetch statement?

downloaded

6th June 2017, 23:55

Yes, same exact problem.

pinterf

7th June 2017, 07:31

Ok, now I know your script, I will run tests with those parameters

EDIT: successfully crashed after changing x264 version to r2762.
EDIT 2: Exception thrown at 0x000000014001D63F in x264_64.exe: 0xC0000005: Access violation reading location 0x00000000C101AD62.
EDIT 3: latest Komisar build x264.2833.x86_64.exe is working again, please try that one.

downloaded

7th June 2017, 09:30

This is the one i was using and crashing:

x264 0.150.2833 df79067
(libswscale 4.7.101)
(libavformat 57.72.101)
(ffmpegsource 2.23.0.0)
built by Komisar on May 26 2017, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Tested with this one and same issue:

x264 0.150.2833kMod df79067
(libswscale 4.7.101)
(libavformat 57.72.101)
(ffmpegsource 2.23.0.0)
built by Komisar on May 26 2017, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

hello_hello

7th June 2017, 18:44

If TIVTC is updated again sometime in the future, the version numbers it writes to the output files it creates (2 pass or VFR mode) could do with an update too.

The TFM metrics file starts like this:

#TFM v1.0.4 by tritical
field = top
crc32 = 385d356e
0 h + [256]

The TDecimate output file looks like this:

#TDecimate v1.0.3 by tritical
crc32 = f76ebc82, blockx = 32, blocky = 32, chroma = T
21885 12119 361525

And the timecodes file created by TDecimate:

# timecode format v1
Assume 29.970030
# TDecimate v1.0.3 by tritical
# Mode 5 - Auto-generated mkv timecodes file

pinterf

8th June 2017, 08:12

Found something, there are two things.
First, I don't know if it is allowed or not: TDecimate class constructor is calling a GetFrame for the child clip to establish whether there are special encoded "hints" in the previous frame.
When I moved this decision into TDecimate's GetFrame, the x264 problem disappears.

The problem is also disappearing when I'm using my mvtools2 build 2.7.0.22d (this was built with ICL), but appears when 2.7.1.22 (which had a bunch of changes compared to 2.7.0.22d besides being built by VS2015) or newer mvtools2 is present.
I suspect that some resources is not being freed up or handled properly when the filter (e.g MAnalyze) is called before the whole filter graph is evaluated by avisynth.

Anyway, I think that moving frame hint detection out from class constructor is solving this problem.

Question: decimation does not seem to like multithreading, so it should be a MT_SERIALIZED filter in AVS+ terminology? (in 1.08 there is no autoregistration for this filter yet)

Boulder

8th June 2017, 09:54

IIRC, it was always recommended to use SetMTMode(5) with TDecimate to disable multithreading that function. I'm not even sure if I got it working without that line when I used AVS 2.6 MT.

pinterf

8th June 2017, 10:14

pinterf

8th June 2017, 14:45

New build

Download TIVTC 1.0.9 (https://github.com/pinterf/TIVTC/releases/tag/v1.0.9)

**v1.0.9 (20170608)**
- Fix (workaround): Move frame hints detection from constructor into the first GetFrame (x64 build with 64 bit x264 crash under mysterious circumstances)
- Filters autoregister themselves as MT_SERIALIZED for Avisynth+, except MergeHints (MT_MULTI_INSTANCE)
Note: for proper serialized behaviour under Avisynth+ MT, please use avs+ r2504 or later.

Thanks downloaded for the report.

XStylus

13th July 2017, 01:22

Thanks so much for the updates. By any chance is there potential for support for other color spaces (such as YV16, YV24) at some point in the future?

hello_hello

13th July 2017, 12:14

pinterf,

I've been using TDecimate, mode=2 for 2 pass decimation, and now and then I find the second pass won't run and I get an access violation error. I've only checked once, but it also appears to be a problem with the earlier versions of TIVTC, so it's not something you've caused. Oddly though, every time it's happened I've been able to work around it by reducing the frame count by one with Trim() and deleting the entry for the last frame from the metrics file, or by adding a frame to the total and creating another one at the end of the metrics file. Changing mode 2 to mode 7 also fixes it, but it's not a two pass method.

If I can create a sensible sample (something of a decent size for uploading) are you interested in having a look? It might take me a while to create a small sample through trial and error, which is why I'm asking first.

Cheers.

B.F.

17th July 2017, 09:34

Hm, as far as I remember original TIVTC can't detect purely horizontal motion.
Is it fixed in the new builds or not?

pinterf

17th July 2017, 16:23

pinterf,
If I can create a sensible sample (something of a decent size for uploading) are you interested in having a look? It might take me a while to create a small sample through trial and error, which is why I'm asking first.

Cheers.
Thanks, then please prepare that sample, I can check it.
(When I disappear it's because of the summer holidays, then extra work because of holiday and I better run and prepare for marathon than sitting behind the computer in this nice weather)

hello_hello

18th July 2017, 15:26

Run a marathon???? I'm unusually out of breath by the time I get to the end of the driveway to collect the mail. ;)

Everything below is a combination of myself, Windows XP, Avisynth 2.6 and TIVTC 1.09, although I think it also applies to the original TIVTC (1.05, or whatever version that is). I've only tested the old version once but the result was the same.

I think I've managed to dwindle a script down to one that'll produce the error regardless of the source. In case it matters, I was using a 4:3 NTSC DVD as the source, but I've tested it with three different NTSC DVDs with the same result each time, so hopefully it's source independent.
Here's the steps required for error reproduction. Sorry if some of it's a bit obvious, but just to be clear....

This is the script:

DGDecode_mpeg2source("D:\test.d2v")
Yadif(mode=1)
AssumeFPS(60000,1001)
Trim(0, 39582)
TDecimate(mode=2, rate=50, Input="D:\metrics.txt")
AssumeFPS(50)

And here's the metrics file (same file, different links):
metrics.zip (https://files.videohelp.com/u/210984/metrics.zip)
http://www.filedropper.com/metrics

When you first run the script, you'll bump into a crc32 mismatch error such as the following:

https://image.ibb.co/jgGmVF/crc32.gif

You can try using batch=true for TDecimate to bypass the crc32 check but when I started testing I thought it stopped the problem from occurring a couple of times, although maybe I did something silly. If it does, you might need to manually change the crc32 at the top of the metrics file to match your source.

Re-opening the script should then take you directly to the problem I've been encountering (now and then).

https://image.ibb.co/jMTpja/access_violation.gif

TDecimate doesn't seem to care if there's less frames in the metrics file than in the video itself, although it gets upset if there's more, but anyway.... to work around the problem you can simply delete the reference to the last frame in the metrics file. You can also reduce the trim range by a frame to match and the problem shouldn't return. ie Trim(0, 39581)

It seems the trick is to have just the right number of frames. If that's the cause there's no doubt more than one magic number, but if you keep the metrics file as it was originally, and move the trim range up by 6 frames ie Trim(6, 39588), you should still bump into the same access violation error.

Thanks.

PS. Did you happen to notice this? I'm just wondering if it's a bug or me having a silly. Thanks.
https://forum.doom9.org/showthread.php?p=1810264#post1810264

TheFluff

18th July 2017, 19:35

Radical, think-outside-the-box, "out there" suggestion: have you tried using a metrics file that actually matches the clip you're operating on?

hello_hello

19th July 2017, 11:29

Believe it or not, that's how the metrics file was created originally, so it did match the source, but it doesn't seem to matter as it results in an access violation error whether I use the same source or a different one, so I went with the "no need to upload video" option as my internet connection is slow.

Aside from having to change the crc32 or use batch=true, how would TDecimate know the source is different? If it checked the whole video, wouldn't that defeat the purpose of running the first pass and creating the metrics file in the first place?

zambelli

15th August 2017, 00:18

burfadel

15th August 2017, 01:07

For every 5 frames you need to return 2, say the second and fifth frames. This can be done with selectevery function but I'm not sure of the syntax.

poisondeathray

15th August 2017, 01:48

How about SelectEven().TDecimate() ?

This works on 24p in 59.94p broadcasts here, but not sure why you would drop original frames in that first case - perhaps you have irregular cadence issues ? or source filter issues ?

GMJCZP

15th August 2017, 01:54

Here are several ways to perform IVTC (included TIVTC): Here (https://forum.doom9.org/showthread.php?t=173654&highlight=tivtc+gmjczp).

tebasuna51

15th August 2017, 10:51

For every 5 frames you need to return 2, say the second and fifth frames. This can be done with selectevery function but I'm not sure of the syntax.

SelectEvery(5, 1, 4)

But the pattern must be the same along all the movie.

hello_hello

15th August 2017, 12:47

I'm trying to use TDecimate to remove a progressive 3:2 pulldown (where ABCD frames are duplicated as AAABBCCCDD frames, for example, such as in 720p60 broadcasts of 24p content).

I'm using this:
TDecimate(mode=1, cycleR=6, cycle=10)

It seems to work well, but based on the original burned-in timecode I can see that it's occasionally dropping entire frames from the original 24p sequence.

Is there a better combination of parameters I should be using for progressive 3:2 pulldown removal? Is there a better plugin than TIVTC for that specific use case?

You can try stretching out the cycle.

TDecimate(mode=1, cycleR=12, cycle=20)

Or not specifying one:

TDecimate(mode=7, rate=23.976) # or rate=24, depending on the source frame rate.

Mode 7 usually does a good job, but if you find it's not getting it quite right, two passes generally does it better.

1st pass something like:

TDecimate(mode=4, rate=23.976, Output="D:\metrics.txt")

2nd pass:

TDecimate(mode=2, rate=23.976, Input="D:\metrics.txt")

A few posts up I reported a problem I was having with two pass mode. I've experienced it a couple more times since then. If you start the second pass and get an access violation error, open the metrics file and delete the very last entry. For whatever reason, that always fixes it.

I haven't used it this way, but the help file says mode 2 can produce the same result with one pass as it would with two passes if you set m2PA=true. It reads ahead quite a bit though, so a script will initially take a while to open, and encoding could appear to stall at times when one "cycle" finishes and TDecimate reads ahead again. When there's no metrics file specified, mode 2 normally reads ahead by a maximum of 100 frames. m2PA=true over-rides that.

hello_hello

23rd December 2017, 01:30

I have a question, and while I imagine the answer will be "too much work" or something similar, you never know if you don't ask.

Currently TIVTC can output combinations of 23.976fps and 29.970fps in variable frame rate mode, but would it be possible to have it output combinations of 23.976 and 59.94 instead (while bob de-interlacing the interlaced sections)? TDecimate would probably need an update to give it a PAL hybrid mode, or so it's current hybrid mode would know not to decimate PAL, but I assume even for PAL sources, TDecimate would still be needed to create a timecodes file.

8day

28th December 2017, 16:10

hello_hello

28th December 2017, 22:14

Anyone had this issue with TDecimate that it ignores sections of <5 frames defined as video (possibly film as well)? I tried to use TDecimate to create VFR video, but I found that it ignores, or even shrinks some segments (possibly due to scenecuts, but that's less important). E.g., when I supplied these overrides to test clip with TDecimate(mode=5, hybrid=2)

I think it's definitely about cycles, although I'm not sure I understand the logic behind specifying a couple of consecutive frames (or even 4 consecutive frames) as being video, because for TDecimate, isn't the difference between video and film frames effectively the presence or absence of a duplicate frame in each group of five? So the question would be.... did TDecimate remove any of the frames you specified as video?

For example, you specified frames 10 and 11 as video but that covers 3 cycles of 5 frames, so if frames 4, 9, and 13 were duplicates and removed, frames 10 and 11 would now have a duration of roughly 41.7ms instead of their original "video" durations of 33.4ms, as they've become part of a film cycle, but as long as they're still there....

Plus if specifying frames 10 and 11 as video forced frames 6 thru 15 to be considered video (assuming cycles of five) and there were a couple of duplicates amongst them, would keeping the duplicates be better than removing them and calling the remaining frames film? If TDecimate did keep the original "video durations" for 10 and 11 while removing frame 12 because it was a duplicate, that'd mean frames 13 and 14 would have to be (taking a guess) 20fps to complete the cycle.

I'm not answering your question as such.... just thinking about it out loud.... ;)

hello_hello, I face(d) a similar issue with NTSC. The biggest problem with doing bob-deinterlacing is the one I posted.

I've worked out a system for doing it manually, including creating a timecodes file, and it works well, but it can be quite time consuming when there's a large number of film and video sections, although I've never wanted to bob de-interlace just a few consecutive frames. It's always "sections" of film and "sections" of video, and for the film sections you really do need to stick to multiples of five, given after decimation, four film frames = five video frames in duration, otherwise you'd have to start fiddling with frame rates for individual sections of film or video, or add/remove frames in video sections to compensate for any change in duration after decimating the film sections etc.... and that'd make it even harder.

8day

29th December 2017, 21:47

I'm not sure I understand the logic behind specifying a couple of consecutive frames (or even 4 consecutive frames) as being video
It's not about small segments per se. It's that it behaves like it adjusts boundaries of overriden segments to fit mod5 blocks/detected telecine GOPs, and small segments seemed like the most obvious choice to test this. I think it will behave same way with segments of length 102, 103 and 104 frames.

So the question would be.... did TDecimate remove any of the frames you specified as video?
Yes, it did. For 10,11 #11 was removed/not used, for 20,22 #21 and for 30,33 it was #33. And that's the problem: it ignores overrides. What should've happened is if previous and/or next telecine GOP got split, incomplete part must've been shown at 29.97 fps, and the defined video segment itself should've been shown at 29.97 fps. If anything, such segments should've been larger, not smaller, and definitely not ignored completely.

hello_hello

30th December 2017, 10:56

Yes, it did. For 10,11 #11 was removed/not used, for 20,22 #21 and for 30,33 it was #33. And that's the problem: it ignores overrides. What should've happened is if previous and/or next telecine GOP got split, incomplete part must've been shown at 29.97 fps, and the defined video segment itself should've been shown at 29.97 fps. If anything, such segments should've been larger, not smaller, and definitely not ignored completely.

The frames you specify in the overrides file do have to correspond to what TDecimate considers to be a whole cycle, which seems to always begin at frame 0.

I created a metrics file where frame 12 was obviously a duplicate. Specifying "10,14 v" caused TDecimate to keep frame 12 and set a frame rate of 29.970 for those frames in the timecodes file. Specifying "9,13 v" however had no effect. Those frames were still considered to be film and frame 12 was dropped.

According to my metrics file, frames 12, 17 and 22 were duplicates. When I specified "9,23 v" for the overrides file, frames 12 & 17 were kept but not frame 22.

I'm not sure it's a problem though, as it seems it's easy enough to work around once you know you need to specify ranges of 5. To ensure all frames in the range 17 to 22 are treated as video instead of film, you'd need to specify the range as "15,24 v". Admittedly if that's how it works, and so far it seems to be, it would've been better to make that clear in the help file.

The same applies to not putting a space after the comma like so:
42, 59 v
The help file doesn't warn not to and there's no error if you do. I couldn't work out why my overrides file was being ignored completely until the penny dropped and I realised I'd added a space.

8day

30th December 2017, 17:51

hello_hello, this thought never crossed my mind, but you seem to be right, it kind of makes sense. Now I hope I'll be able to write necessary scripts in a day or two...

8day

3rd January 2018, 19:27

hello_hello, I think I've done it. It took longer than expected, but should work.

All the files, including links to custom plugins, can be found here: https://github.com/8day/avs-tivtcex All the stuff you need to know is described in the readme.md on that page.

hello_hello

7th January 2018, 03:54

I haven't checked it out properly yet but it looks interesting. I definitely will.

Out of curiosity, what do you use for this part of the phase 2 script?

# favourite filter chain for analysis of hybrid video.

Cheers.

8day

7th January 2018, 12:04

Anything that makes combing more visible and choices more easy will do. ATM I can't share my filter chain for various reasons (I'll share it later, when I'll finish another project, which hopefully won't take more than a month: it's mostly ready, but I want to write replacement for TDecimate), but considering what's expected from TIVTCEx, Histogram("luma") should be more than enough.

In case you didn't know, TFM generates misc stats at the end of its metrics file on combed frames, ranges, and supposedly missed combed frames. All you have to do is inspect them and create overrides file for TFM and/or TIVTCEx (I suspect that's what YATTA is built around).

Gser

18th January 2018, 21:39

8day

18th January 2018, 22:57

pinterf

19th January 2018, 09:37

I doubt it. My understanding of C++/AviSynth is relatively primitive. The only reason there's this "hack" is because TIVTC compiled straight out of the box. But I'll try to compile pinterf's mod once again and maybe I'll get lucky this time... Otherwise you'll have to ask pinterf to copy this hack and recompile DLL with it.
No problem adding that hack, which source files should I check for modifications? I have filecompared TDecimate and found one place, but it would be easier to know that w/o comparing all files. I can see only root and initial commits in your git repo.
EDIT: found them and integrated. Who wants to test it?

EDIT: New build: TIVTC 1.0.10 (https://github.com/pinterf/TIVTC/releases/tag/v1.0.10)
**v1.0.10 (20180119)**
- integrate new orgOut parameter for TDecimate (by 8day) (see TDecimate - READ ME.txt)

8day

19th January 2018, 17:03

Just realized why Gser was talking about multiple DLLs... Here's EDL compiled using latest AviSynth+ headers in VS2017: https://github.com/8day/avs-edl/releases/tag/0.1. But please note that I haven't tested it since I don't have AviSynth+ on my system.

Gser

24th January 2018, 17:14

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

26th January 2018, 15:55

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

23rd March 2018, 17:27

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

24th March 2018, 03:29

Thanks.

hello_hello

28th March 2018, 00:48

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

29th March 2018, 16:35

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

Katie Boundary

10th September 2018, 18:17

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

11th September 2018, 13:20

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

11th September 2018, 13:39

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

11th September 2018, 13:43

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

Stereodude

8th April 2020, 19:44

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

10th April 2020, 09:18

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

pinterf

10th April 2020, 10:02

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

10th April 2020, 13:21

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

10th April 2020, 13:29

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

10th April 2020, 14:20

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

10th April 2020, 14:50

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

10th April 2020, 21:07

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

10th April 2020, 23:45

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

11th April 2020, 13:51

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

12th April 2020, 06:10

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

13th April 2020, 10:18

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

pinterf

13th April 2020, 21:41

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

15th April 2020, 18:19

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

5th May 2020, 20:37

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

5th May 2020, 22:28

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

5th May 2020, 22:44

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

LigH

6th May 2020, 08:40

TDeint in 64 bit! My hero!

:thanks:

mp3dom

6th May 2020, 17:49

Veeery nice!
Big thanks!

Sparktank

7th May 2020, 04:58

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

8th May 2020, 21:31

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

9th May 2020, 00:53

FranceBB

10th May 2020, 00:27

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

10th May 2020, 01:10

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

10th May 2020, 06:46

Thanks for the report, I'll fix it soon

pinterf

10th May 2020, 17:58

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

12th May 2020, 22:30

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

12th May 2020, 22:43

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

13th May 2020, 00:48

Thanks, it seems is growing nicely! :)

LigH

13th May 2020, 08:06

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

13th May 2020, 08:24

pinterf

13th May 2020, 17:32

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

14th May 2020, 07:33

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

14th May 2020, 07:53

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

21st May 2020, 15:47

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

21st May 2020, 16:54

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

21st May 2020, 19:48

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

22nd May 2020, 08:16

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

22nd May 2020, 16:03

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

22nd May 2020, 21:25

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.

Stereodude

22nd May 2020, 21:58

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.
:confused: How is it not TFM related?

1) MPEG2Source is frame accurate. I don't know about ffms2 as I don't use it for MPEG-2.

2) I transcoded both of the samples to a lossless AVI that is absolutely frame accurate and used that in place of the MPEG-2 source the same thing happens. The short file works as expected the longer one doesn't.

3) What other filter in the filter chain is responsible for TFM's field matches? Why would TFM behave differently when the sequence occurs 40 frames into the clip vs. 321 frames into the clip?

pinterf

22nd May 2020, 22:23

Going back using mpeg2source.

So that y0 parameter (band exclusion) is only used in the very first check in field matching decision (they call it of compareFields inside).
And then, bacause micmatching>0 the combing check algorithms (for myself: CheckComb) is working again on the whole frame.
The "micmatching" parameter is default = 1
When I set "micmatching"=0 the combing decision became identical for the stacked and non-stacked case.
Debug display output will report different MIC however but it seems that it does not overrides the first field matching decision.

Stereodude

23rd May 2020, 01:08

pinterf

23rd May 2020, 21:12

Thank you for digging into this.

So the documentation isn't really correct. That band is not excluded from the entire field matching decision, only part of it. It seems counter-intuitive that the band is not excluded from all checks/processing that influence matching since that's the very reason why you'd want to exclude the defined band in the first place.

IMHO the y0/y1 feature is broken.

I agree, it took quite a few hours to shed light on this. At least I gained a more insider look over the internal processes. :)

The docs will be modded, and the source? Well, at the moment I do not dare to touch the other stuff to really exclude the y0-y1 bands from the checking. There are other things to do first.

Any thoughts on why the two clips behave differently?
No time now for that, we can return to it some weeks later.

Currently the whole TIVTC project is under heavy changes/refactoring (since weeks and there are some more weeks ahead) in order to have a clean and maintainable source.

What can you expect:

My target is finishing the porting to 10+ bits, and make some AVX2 stuff, and the general lookout of the source code, remove as much ciphered and copy-pasted part as I can.

As for high bit-depth project: FrameDiff is already working in 16 bits, display=true is working on my test bench for YV16 and YV24 (and 8-16 bits) as well (current release is - inheritedly - can display only for YV12 and YUY2)

And an old TFM crash bug was fixed as well.

Stereodude

23rd May 2020, 23:55

I agree, it took quite a few hours to shed light on this. At least I gained a more insider look over the internal processes. :)

The docs will be modded, and the source? Well, at the moment I do not dare to touch the other stuff to really exclude the y0-y1 bands from the checking. There are other things to do first.
The feature was introduce in the 11/21/2004 v0.9.1 and it apparently took about 15.5 years for someone to notice that it doesn't really work as promised, so what's the hurry? :p

bruno321

3rd June 2020, 09:09

New computer, new installation of avisynth+ 64 and megui 64. I'm having a problem with TDecimate and megui, I don't know who's the culprit. Script:

MPEG2Source("D:\projects\tests\segment.demuxed.d2v", cpu=0)
tfm()
TDecimate(hybrid=1)

AVSMeter64 output of the script:

AVSMeter 3.0.0.4 (x64), (c) Groucho2004, 2012-2020
AviSynth+ 3.5 (r3106, 3.5, x86_64) (3.5.0.0)

Number of frames: 1315
Length (hh:mm:ss.ms): 00:01:05.750
Frame width: 720
Frame height: 576
Framerate: 20.000 (20/1)
Colorspace: YV12

Frames processed: 1315 (0 - 1314)
FPS (min | max | average): 84.27 | 276.4 | 150.8
Process memory usage (max): 34 MiB
Thread count: 8
CPU usage (average): 23.6%

Time (elapsed): 00:00:08.722

However, megui 2913 x64 gives me this error:

--[Information] [6/3/2020 10:05:21 AM] Started handling job
--[Information] [6/3/2020 10:05:24 AM] Preprocessing
-[NoImage] MPEG2Source("D:\projects\tests\segment.demuxed.d2v", cpu=0)
-[NoImage] tfm()
-[NoImage] TDecimate(hybrid=1)
--[Information] [6/3/2020 10:05:24 AM] AviSynth input script
--[Information] [6/3/2020 10:05:25 AM] resolution: 720x576
--[Information] [6/3/2020 10:05:25 AM] frame rate: 20/1
--[Information] [6/3/2020 10:05:25 AM] frames: 1315
--[Information] [6/3/2020 10:05:25 AM] length: 00:01:05.750
--[Information] [6/3/2020 10:05:25 AM] aspect ratio: 5:4 (1.250)
--[Information] [6/3/2020 10:05:25 AM] color space: YV12
--[Information] [6/3/2020 10:05:25 AM] Job command line: "C:\encoding\MeGUI-2913-64\tools\x264\x264.exe" --preset veryslow --tune film --crf 20 --keyint 200 --sar 1:1 --frames 1315 --output "D:\projects\tests\segment.demuxed tfm.264" "D:\projects\tests\segment.demuxed.avs"
--[Information] [6/3/2020 10:05:25 AM] Process started
--[Information] [6/3/2020 10:05:25 AM] Standard output stream
--[Information] [6/3/2020 10:05:25 AM] Standard error stream
--[Error] [6/3/2020 10:05:27 AM] Process exits with error: 0xC0000005 STATUS_ACCESS_VIOLATION (-1073741819)
--[Information] [6/3/2020 10:05:27 AM] Job completed

When I use only tfm(), megui doesn't have a problem. Here's avsmeter64 avsinfo in case it helps:

AVSMeter 3.0.0.4 (x64), (c) Groucho2004, 2012-2020

VersionString: AviSynth+ 3.5 (r3106, 3.5, x86_64)
VersionNumber: 2.60
File / Product version: 3.5.0.0 / 3.5.0.0
Interface Version: 7
Multi-threading support: Yes
Avisynth.dll location: C:\Windows\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2020-04-02, 16:27:26 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64\DGDecode.dll [1.5.8.0, 2010-03-18]

[C++ 2.6 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll [n/a, 2020-04-02]
C:\Program Files (x86)\AviSynth+\plugins64\DePan.dll [2.13.1.6, 2020-05-22]
C:\Program Files (x86)\AviSynth+\plugins64\DePanEstimate.dll [2.10.0.4, 2020-05-22]
C:\Program Files (x86)\AviSynth+\plugins64\DupStep.dll [0.0.3.0, 2020-06-03]
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll [2.2.23.0, 2020-05-14]
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll [2.7.43.0, 2020-06-02]
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll [0.9.4.55, 2020-05-05]
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll [1.0.0.0, 2020-04-27]
C:\Program Files (x86)\AviSynth+\plugins64\TIVTC.dll [1.0.17.0, 2020-05-12]

[Scripts (AVSI)] [Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.avsi [2020-03-12]
C:\Program Files (x86)\AviSynth+\plugins64\QTGMC.avsi [2020-06-02]
C:\Program Files (x86)\AviSynth+\plugins64\Zs_RF_Shared.avsi [2020-06-03]

[Uncategorized files] [Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\colors_rgb.txt [2020-03-12]

[Plugin errors/warnings]
____________________________________________________________________________________________________________

"C:\Program Files (x86)\AviSynth+\plugins64\DePanEstimate.dll" requires the FFTW library for some functions.

Note: 'libfftw3f-3.dll' can be downloaded here:
http://www.fftw.org/install/windows.html

'libfftw3f-3.dll' should be placed in "System32" and/or "SysWoW64"
____________________________________________________________________________________________________________

"C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll" requires the FFTW library for some functions.

Note: 'libfftw3f-3.dll' can be downloaded here:
http://www.fftw.org/install/windows.html

'libfftw3f-3.dll' should be placed in "System32" and/or "SysWoW64"

pinterf

3rd June 2020, 18:03

Could you please test this build:
https://drive.google.com/open?id=1kUsTcYXtQHE7F2wrasDp8xivUFIQws0q
Replace your existing v1.0.17 TIVTC.DLL with the appropriate dll from the package.

bruno321

3rd June 2020, 20:35

Same error.

Groucho2004

3rd June 2020, 21:06

Same error.Are you using the "portable" (or whatever it's called) Avisynth in megui?

bruno321

4th June 2020, 05:58

You mean "use the included avisynth"? That's disabled.

pinterf

4th June 2020, 08:42

Then I'd need a source sample for which the crash still occurs because with my samples I cannot reproduce the issue.

bruno321

4th June 2020, 12:16

Sure. Here it is https://fex.net/s/plnfycz

Thanks for looking at it :)

pinterf

5th June 2020, 12:52

Sure. Here it is https://fex.net/s/plnfycz

Thanks for looking at it :)
Thanks, everything is o.k. for me, could not reproduce your issue.

bruno321

5th June 2020, 15:42

Seems it was a problem with DGDecode. I switched to MPEG2DecPlus and it's fine now.

kedautinh12

9th June 2020, 02:32

AzraelNewtype

10th June 2020, 23:33

Japanese broadcast is often kind of messy like this. Look into JIVTC, which is much slower and harder to use but designed specifically around this problem.

kedautinh12

11th June 2020, 01:31

Japanese broadcast is often kind of messy like this. Look into JIVTC, which is much slower and harder to use but designed specifically around this problem.

thanks, but i meet error: "invalid arguments to function 'JIVTC'"

my scripts:
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\yadifmod.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\masktools2.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\nnedi3.dll")
Import("E:\MeGUI-2924-64\tools\avisynth_plugin\JIVTC.avsi"

JIVTC()

StainlessS

11th June 2020, 13:16

function JIVTC(clip c, int pattern, int "thr", bool "draft", clip "ivtced", string "bobber", bool "show")

Clip c and pattern, are non optional, so of course "JIVTC()" error aborts for missing arguments.

pinterf

11th June 2020, 13:29

tdecimate() error, i meet too much artifact

Code: tfm().tdecimate()
Video test: https://drive.google.com/open?id=1IxbWmo4Iu5eKivW7XZmv8IN7MnS3qIjq
Frame 2533: https://drive.google.com/open?id=14jFXF_JRVTtUiwVurPaRaI-9rPS31ZJ-
That specific part is like zooming into a fire fractal. It is really a tough task for an automatic recognition. Problem is that for some square blocks (greenish artifacts) the mask creation and thus the merge-it? decision was not successful. Since there are a zillion parameters of both filters, one can spend a week with trial and error.

LigH

11th June 2020, 15:35

@kedautinh12: "clip c" may implicitly be "last" after a source filter; but the explicit pattern will be mandatory.

pinterf

11th June 2020, 16:16

Myrsloik

11th June 2020, 16:34

pinterf

11th June 2020, 17:20

A sort of entertainment. Instead of solving crossword puzzles.

real.finder

11th June 2020, 17:38

FranceBB

11th June 2020, 23:25

And finally after many months of reverse engineering, de-copypasting, refactoring and feature adding:

Download TIVTC 1.0.19 and TDeint 1.6 suite (https://github.com/pinterf/TIVTC/releases/tag/v1.0.19), supporting full 8-16 bits and all planar formats (and YUY2)

That was probably my hardest project so far.

I hope not much bugs will be reported but since it was a huge reconstruction there will surely be some of them.

Enjoy.

Probably there will be at least one more update later with more SIMD accelerated stuff for 10+ bits (not to mention the bugfixes)

10bit tdeint is definitely useful for Panasonic P2 since they're based on AVC-Intra Class which is essentially is H.264 10bit interlaced, so it's indeed something nice to have.
I haven't found anything interlaced higher than 10bit planar, but still since you made it 16bit compatible I'll just say that it's just good to have. :)

A sort of entertainment. Instead of solving crossword puzzles.

Please never turn to crossword puzzles, we need your dedication to this other kind of "entertainment" xD

Jokes aside, thank you. :)

LigH

12th June 2020, 07:40

Cheers to the dedicated restless...

https://cosgan.de/images/smilie/musik/n015.gif

kedautinh12

13th June 2020, 07:57

@kedautinh12: "clip c" may implicitly be "last" after a source filter; but the explicit pattern will be mandatory.

Thanks, it's work but didn't fixed my problem

LigH

14th June 2020, 15:49

Then - how does your script look now, and which error appears now?

LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\yadifmod.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\masktools2.dll")
LoadPlugin("E:\MeGUI-2924-64\tools\avisynth_plugin\nnedi3.dll")
Import("E:\MeGUI-2924-64\tools\avisynth_plugin\JIVTC.avsi"

# JIVTC() -- invalid arguments to function 'JIVTC' -- pattern is missing

# you have to try one of the following:
JIVTC(0)
# JIVTC(1)
# JIVTC(2)
# JIVTC(3)
# JIVTC(4)

kedautinh12

14th June 2020, 21:27

LigH

15th June 2020, 10:17

So, what exactly is the problem? Is there an error message instead of a filtered video? Or is just the result of the filtering not satisfying?

StainlessS

15th June 2020, 12:33

kedautinh12
That cannot be your full script, where do you get your clip from ?, post your FULL script as asked already by LigH,
and also answer LigH questions in prev post.

kedautinh12

17th June 2020, 05:48

So, what exactly is the problem? Is there an error message instead of a filtered video? Or is just the result of the filtering not satisfying?

The result of the filtering not satisfying

My full scripts:
FFVideoSource("D:\RADWIMPS - Daijoubu [1440x1080i MPEG2 M-ON! HD].ts", fpsnum=30000, fpsden=1001, threads=1, colorspace="YUV420P8")
tfm().JIVTC(5)

Result have many artifact, my example in frame 2544:
https://drive.google.com/open?id=1IetWJ4aiNnM1XNWZZ6xYoZCrR3pIfIzG

LigH

17th June 2020, 07:06

I got clip from private torrent page ...

In this case, your answer may be in chapter #6 of this document (http://forum.doom9.org/forum-rules.htm).

colinhunt

27th June 2020, 00:26

Gents, I need help with TFM/TDecimate. I ripped a Japanese music video from Blu-ray for deinterlacing and ivtc'ing from 29.97 to 23.976, but it refuses to co-operate and driving me bonkers. I'm seeing duplicate frames mostly around scene changes, before or after, and nothing I try gets rid of the duplicates. I'm using
Staxrip as the front-end. Mediainfo reports source .m2ts as 29.970 fps MBAFF & TFF.

So far I've tried, in addition to defaults, various combinations of TFM and TDecimate modes, some of TFM's PP modes, TFM set to slowest/best accuracy, outputting metrics into an external file during 1st pass and reading it in pass 2 (both TFM and TDecimate), both short and long cycle/cycleR values on TDecimate, sceneThresh settings both small & large, noise threshold of 0 and 1 for metrics calculations, blockx and blocky values of 4 and 8, hints enabled & disabled, and maxndl values between 4-6.

I'm pretty much tearing my hair out here so any advice/tips are very much welcome.

FranceBB

27th June 2020, 01:56

pinterf

27th June 2020, 07:54

Meanwhile a v20 was released with a hotfix addressing a crash in v19 when PP=1 and display=true

colinhunt

27th June 2020, 11:36

and let me know? That's what I use whenever I find something telecined.
Thank you for replying, I appreciate it!

I tested your config, and while I saw less duplicates, some still lingered. I also saw blended frames which didn't happen in my previous experiments.

Here's a 45 second clip from the start of the video, cut with ffmpeg -c copy and output to .m2ts to match the original: https://drive.google.com/file/d/1sToixVK2_pPiAYpKzpRaON9Vsf2APEcP/view?usp=sharing

There's a scene change at 00:22.109 or thereabouts which seems like a very tricky bit; there's always a duplicate frame either right before the cut or immediately after. Previous cut, at approx 00:20.941, comes also out with a duplicate frame before or after, most of the time. That's where your config created a blended frame at, btw.

It also occurred to me that perhaps this video was actually shot in 29.97 fps instead of 23.98, but looking at the clip frame-by-frame in its original interlaced form, for example the hand movement starting at 00:22.843, makes it seem like the original frame rate wasn't 29.97. I could be mistaken, of course.

colinhunt

27th June 2020, 11:49

Meanwhile a v20 was released with a hotfix addressing a crash in v19 when PP=1 and display=true
I can't even begin to tell you how much I appreciate your continuing contributions. Keep up the great work!

kedautinh12

27th June 2020, 13:48

https://drive.google.com/file/d/1stoixvk2_ppiaypkzpraon9vsf2apecp/view?usp=sharing

snsd?

colinhunt

27th June 2020, 14:17

snsd?
Absolutely.

zybex

27th June 2020, 19:54

I need help with TFM/TDecimate. I ripped a Japanese music video from Blu-ray for deinterlacing...
I'm pretty much tearing my hair out here so any advice/tips are very much welcome.

Is it OK for you ?
https://mega.nz/file/X4oTCaAR#gk4A2PwVxalWVtyZ2Hpnre5oGuOG48Na5MVXVCDqOXQ

colinhunt

27th June 2020, 21:28

Is it OK for you ?
https://mega.nz/file/X4oTCaAR#gk4A2PwVxalWVtyZ2Hpnre5oGuOG48Na5MVXVCDqOXQ
Well, no. That's been deinterlaced only and runs at 29.97 fps with a duplicate frame in every 5-frame segment. Not what I was trying to achieve. Thanks for giving it a shot, though.

hello_hello

28th June 2020, 19:28

I'm a bit rushed so I can't check the whole thing frame by frame now, but the scene change you mentioned seems to be duplicate free if you do this:

TFM(micmatching=0).TDecimate()

I think there's telecine each side of the scene change, and possibly an orphaned field or two (shoot me if I sound like Katie), and maybe in an attempt to make it a whole frame TFM is trying too hard to find a matching field, so when it does it creates an extra duplicate frame instead of dropping the orphaned fields. Or maybe that's a load of bullocks.... :)

taxi_clip.mkv (https://www.udrop.com/a0g/taxi_clip.mkv)

colinhunt

28th June 2020, 20:41

I'm a bit rushed so I can't check the whole thing frame by frame now, but the scene change you mentioned seems to be duplicate free if you do this
Thank you for taking the time! I went through your clip frame-by-frame, and found only two instances of frame duplicates (at 00:27.110 and 00:44.169), neither of which were in the tricky section I described. Very promising indeed! I'll process the entire video with micmatching disabled and we'll see what happens. Thanks!

hello_hello

28th June 2020, 22:08

00:44.169 is the last frame, so I'm not sure it should count, especially as the video was cut at the end.

It looks as though the duplicate frame around 00:27.110 might have been a decoding oddity. I've decided to pretend it didn't happen once I've finished typing this post, but I couldn't work out why there was a duplicate frame encoded, yet I couldn't see one looking at the script, until I remembered I indexed and decoded with ffms2 last time and Lsmash this time, so I tried ffms2 again and sure enough, the duplicate frame re-appeared. Back to Lsmash, no duplicate.

I'm using XP compatible versions of lsmash and ffms2, so hopefully it's just an "old ffms2" thing.

colinhunt

29th June 2020, 14:19

00:44.169 is the last frame, so I'm not sure it should count, especially as the video was cut at the end.
Yeah, good point.

It looks as though the duplicate frame around 00:27.110 might have been a decoding oddity.
I'll stick with Lsmash then; should have time to finally test this out today. Thanks!

FranceBB

29th June 2020, 15:21

I'm using XP compatible versions of lsmash and ffms2, so hopefully it's just an "old ffms2" thing.

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.

manolito

29th June 2020, 15:39

Reino keeps both ffmpeg and ffms2 updated and XP Compatible.

Not only XP compatible, Reino's builds do not even require a SSE2 capable CPU. Plus these builds are extremely well tested and totally reliable.

Now that the Zeranoe forum has disappeared it is a little bit hard to find Reino's builds. I hope that he will open a new thread about his builds right here at Doom9... :D

StainlessS

29th June 2020, 15:50

FranceBB,
Methinks that you are just the guy to maintain thread/list of all things XP compatible,
wadya think HH, is he the guy ?
EDIT: Same Q to Mani.

colinhunt

29th June 2020, 15:53

Back to Lsmash, no duplicate.
For some unfathomable reason LSMASH refuses to open the source .m2ts. I can't understand why. An issue with Staxrip 2.1.1.4?

LWLibavVideoSource opens it fine, but micmatching=0 doesn't produce the results I hoped for: a duplicate frame raises its ugly head at 00:21.355. Did not bother to check the rest of the file, tbh.

Tested DSS2 as a source filter; opens .m2ts fine but same duplicate frame pops up. I even gave VapourSynth a shot, with VFM and VDecimate, to a horrible result of duplicate frames everywhere.

StainlessS

29th June 2020, 16:00

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

29th June 2020, 17:30

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

29th June 2020, 23:19

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

29th June 2020, 23:30

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

30th June 2020, 13:56

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

30th June 2020, 14:27

@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

30th June 2020, 15:17

@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

30th June 2020, 15:52

@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

23rd September 2020, 15:51

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

25th September 2020, 12:24

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

23rd October 2020, 19:07

videoh

23rd October 2020, 21:58

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

24th October 2020, 17:35

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

25th October 2020, 09:06

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

26th October 2020, 09:29

Thanks for the update. :)

hello_hello

29th October 2020, 16:28

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

29th October 2020, 18:31

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

wonkey_monkey

29th October 2020, 20:06

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

30th October 2020, 17:21

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

30th October 2020, 17:39

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

5th November 2020, 23:39

poisondeathray

7th November 2020, 03:26

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

7th November 2020, 22:03

poisondeathray

8th November 2020, 02:54

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

14th December 2020, 04:21

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

14th December 2020, 16:07

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

14th December 2020, 18:55

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

14th December 2020, 20:07

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

14th December 2020, 20:26

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

14th December 2020, 20:34

Phew!, that was qwik.
Thanks.

real.finder

15th December 2020, 00:06

mp3dom

22nd February 2021, 01:12

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

22nd February 2021, 03:16

patul

22nd February 2021, 05:03

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

22nd February 2021, 05:39

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

22nd February 2021, 08:53

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

mp3dom

22nd February 2021, 09:30

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

22nd February 2021, 09:54

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

mp3dom

22nd February 2021, 10:05

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

patul

22nd February 2021, 10:09

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

Emulgator

27th February 2021, 23:10

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

pinterf

28th February 2021, 20:36

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

Statick

30th August 2021, 16:44

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

31st August 2021, 10:50

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

Katie Boundary

1st September 2021, 05:37

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

1st September 2021, 05:52

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

LigH

1st September 2021, 10:08

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

1st September 2021, 13:21

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

2nd September 2021, 13:33

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

2nd September 2021, 18:56

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.

ChaosKing

2nd September 2021, 21:17

So all fansubber? :D

FranceBB

3rd September 2021, 12:05

So all fansubber? :D

ROTFL
I've seen fansubber doing that in the 2006-2008 era.
Madness... and far too much free time those youngsters had back in the days...

(and I was "guilty" of being one of them back in the days :P )

TheFluff

9th September 2021, 15:41

Even back when some anime nerds did do "manual" IVTC, they never actually went through every frame one by one. The typical workflow in tools like YATTA and its successors was to use pattern guidance; that is find sequences of frames with a consistent 3:2 cadence and then generate an override file for those sequences that forced that pattern. When you were lucky you only had like 3-4 pattern breaks for an entire episode (e.g. it was produced as progressive and telecined very late in the production process); if you were unlucky you had hundreds, but that's still far short of looking at every frame.

Katie Boundary

11th September 2021, 19:52

Easy for humans. Quite a challenge for computer algorithms

LOL no. Interlacing is a mathematically very unique phenomenon that has nothing to do with image-recognition or any other human visual system bullshit. The key characteristic that makes it incredibly easy to distinguish from normal detail is that non-adjacent pixels are more similar to each other than adjacent pixels. In particular, for any given column of five pixels A, B, C, D, and E:

- pixels B and D will be more similar to each other than either one is to A, C, or E; and

- pixel C will be more similar to A and E than it is to B or D

This is literally all you need to distinguish interlacing from detail or from noise. If the problem seems "difficult", it's because certain people are ignoring differences between non-adjacent pixels and dicking around with multiplication and arbitrary user-defined threshold parameters, as if they were just copying and pasting from edge-detection algorithms. Hell, neither of TFM's combing metrics even bother to look at the differences between A and B, or between D and E, and Metric 1 doesn't bother looking at pixels A or E at all.

Katie, you think they're different 'cause you "see" them as being different, but a computer doesn't see, a computer works with numbers.

No, they are different because they are MATHEMATICALLY different. In fact, I've sometimes had to use sharpening or other filters to reveal interlacing that was too subtle for the human eye to notice, but which a competently designed algorithm would have picked up easily.

The whole frame is divided in blocks and macroblocks of a certain size, they can be 4x4, 8x8, 16x16 etc.

Macroblocks have nothing to do with deinterlacing because deinterlacing filters don't work on encoded video. They work on decoded video, which is a bunch of individual pixel values.

FranceBB

12th September 2021, 12:04

Macroblocks have nothing to do with deinterlacing because deinterlacing filters don't work on encoded video. They work on decoded video, which is a bunch of individual pixel values.

By motion vectors I mean newly created Vectors to find differences on an uncompressed AV Stream frameserved by Avisynth. Vectors are created from scratch trying to compare blocks temporarily and thus finding out repeating patterns (this is how TDecimate gets rid of telecine for instance) but sometimes this doesn't work well and I've already explained why...

StainlessS

12th September 2021, 12:57

If only we had some coders that were as brilliant as Katie, wouldn't that be something.

Katie Boundary

15th September 2021, 06:19

By motion vectors I mean newly created Vectors to find differences on an uncompressed AV Stream frameserved by Avisynth. Vectors are created from scratch trying to compare blocks temporarily

Again, nothing to do with interlacing.

repeating patterns (this is how TDecimate gets rid of telecine for instance) but sometimes this doesn't work well and I've already explained why...

YOU DON'T NEED TO LOOK FOR PATTERNS. YOU ONLY NEED TO COMPARE DIFFERENCES BETWEEN ADJACENT AND NON-ADJACENT PIXELS.

If only we had some coders that were as brilliant as Katie, wouldn't that be something.

Coding = taking existing ideas and translating them into computer code.

I'm not good at that. I'm better at correcting stupid ideas before they reach the "translated into code" stage.

LigH

15th September 2021, 10:55

So don't forget to consider all the possible kinds of motions that could appear in a video. There is not only "uniform linear horizontal", although it may be the most common. I am pretty sure one can find "academic examples" of motion which does not clearly calculate to lower differences for non-adjacent lines (like even pixel wide vertical).

I remember a more or less entertaining approach of (IIRC?) HDConvertToX: Let x264 encode a tiny crop one time with --tff and another time with --bff, and compare the resulting statistic outputs... :D

FranceBB

15th September 2021, 13:01

So don't forget to consider all the possible kinds of motions that could appear in a video. There is not only "uniform linear horizontal", although it may be the most common. I am pretty sure one can find "academic examples" of motion which does not clearly calculate to lower differences for non-adjacent lines (like even pixel wide vertical).

Yep, precisely. :)
That's exactly what I was trying to tell her...
It's not "that easy" nor "that simple" as she stated.
Anyway, I'm not gonna reply any further, I feel like I can't get my message through, but after all, I've always been terrible in talking with women even when it was weather-related chit-chat, let alone about encoding xD

wonkey_monkey

15th September 2021, 16:55

In particular, for any given column of five pixels A, B, C, D, and E:

- pixels B and D will be more similar to each other than either one is to A, C, or E; and

- pixel C will be more similar to A and E than it is to B or D

This is literally all you need to distinguish interlacing from detail or from noise.

Nonsense. Interlaced video doesn't always meet these criteria and non-interlaced video doesn't always fail to meet them.

Besides, there's more to it than simply deciding (imperfectly) whether or not an individual pixel is "interlaced".

There's no perfect solution to this problem. Any attempt will involve compromises.

If you haven't even implemented your solution, how do you know it's better than any other?

Katie Boundary

15th September 2021, 19:17

So don't forget to consider all the possible kinds of motions that could appear in a video.

Motion has nothing to do with interlacing.

videoh

15th September 2021, 19:35

Motion has nothing to do with interlacing. Of course it does. If there is no movement between the fields then there will be no combing and no need for deinterlacing.

Katie Boundary

16th September 2021, 01:22

Of course it does. If there is no movement between the fields then there will be no combing and no need for deinterlacing.

Unless it's around a scene change. Or it's a fade. Or there's literally any other change in the image that isn't caused by motion (someone turns a light on, for example).

videoh

16th September 2021, 02:44

Sure, those qualify as "motion between fields" too. But you made the false claim that motion has nothing to do with interlacing. What matters is whether the picture content changes across a field pair. Real motion is certainly a major instance thereof, and that explains why motion-adaptive methods can work better.

LigH

16th September 2021, 09:57

"Interlacing" means that two fields of a frame have been shot at different moments of time. If there is no motion, there is no difference to a progressive frame. "Combing" (while watching a whole frame) gets only visible for areas in motion because their content has different locations at different moments of time.

StainlessS

16th September 2021, 10:08

I've always been terrible in talking with women even when it was weather-related chit-chat, let alone about encoding xD

Me too, always seems like they would fail in a Turing Test :) :- https://en.wikipedia.org/wiki/Turing_test
EDIT: Or do I mean pass, or even Indeterminate.

Katie Boundary

18th September 2021, 03:36

Sure, those qualify as "motion between fields" too.

Linguists and physicists, and pretty much the entire english-speaking world, disagree with you.

But you made the false claim

There was nothing false about it. You can have motion without interlacing (it's called "progressive" video) and I already gave several examples of visible interlacing without motion.

What matters is whether the picture content changes across a field pair.

Agreed. And that's not the same thing as motion.

"Combing" (while watching a whole frame) gets only visible for areas in motion

Or if the picture changes for any other reason.

Frank62

18th September 2021, 11:47

Interlacing or even combing has (directly) nothing to do with motion.
The detection of interlacing and combing has.

wonkey_monkey

18th September 2021, 12:14

Linguists and physicists, and pretty much the entire english-speaking world, disagree with you.

This isn't a linguistic or physics forum. We have our own vernacular that doesn't always align with general usage, as does any field, and it's clear in this case that everyone except you is quite comfortable using the word "motion" to describe changes in pixel values. If you insist on being so pedantic (if that's even the right word when someone is incorrect), motion is at the very least one of the main causes of combing in interlaced video, so the claim that "motion has nothing to do with interlacing" is patently ridiculous in any case.

You might as well claim that there is no such thing as motion in a video at all, because it's just a collection of pixels changing over time.

Katie Boundary

19th September 2021, 05:28

The detection of interlacing and combing has.

Nope. Detection only requires that the two fields be from slightly different images.

Frank62

19th September 2021, 14:26

...the two fields be from slightly different images.

That exactly is how "motion" in connection with video is "defined", at least used: The two fields contain different images. Shot at a slightly different time. So what happened from the first to the second point in time is "motion" of some or all objects in the pictures.
If you can't accept this, w_m seems to be right with his last sentence. A question of terminology.

StainlessS

19th September 2021, 18:06

Shot at a slightly different time.
So progressive is temporally from the same position in time [excluding time taken for left to right, top to bottom, raster scan],
and interlaced fields are from temporally and also spatially different positions in time and space.
Katie should really teach herself to code, then she could better acquaint herself with the problem, that would be an education.
Miss Boundary is real exasperating, I bet its hell in their hourse deciding whats for supper.

FranceBB

20th September 2021, 09:35

Katie should really teach herself to code, then she could better acquaint herself with the problem, that would be an education.

Hear hear.
(Ok, I might have been watching the house of commons channel too much xD)

Jokes aside, she would grasp some of those things much much better if she was able to read and write code herself 'cause this way she would be able to actually test her ideas while right now she can only "trust" us with what we're telling her.

I bet its hell in their house deciding whats for supper.

ROTFL
Think about the chat with her husband, like:

Honey, how did your day go?

- Fine, I went to work, it was a normal day, I got stuck in traffic a bit on my way back home, but anyway... What about you?

Terrible, I came up with a revolutionary idea about duplicates detection, but everyone on Doom9 is saying it can't be used as it's not that simple... :(

Katie Boundary

22nd September 2021, 03:20

That exactly is how "motion" in connection with video is "defined", at least used:

No. Motion means that a thing used to be in one place in space, and now it's in another.

Think about the chat with her husband,

I'm not likely to ever have a husband, given that I'm only attracted to women.

FranceBB

22nd September 2021, 13:30

Motion means that a thing used to be in one place in space, and now it's in another.

Let's just stick with "difference" and we're good XD
No, jokes aside, we understand what you're saying, honestly, we do, but on the other hand it's just not as easy to detect differences (motion in your case) through an algorithm, but hey, if in the future someone will try to improve TDecimate and co. further he's gonna be more than welcome, but right now, if it doesn't fulfill your / our needs with any of the modes available, I guess we're just gonna have to live with it... :')

I'm not likely to ever have a husband, given that I'm only attracted to women.

Ah! Of course! Sorry, my fault, everything makes sense now eheheh.

(I'm joking of course :rolleyes:)

Ok, I should really get back to work now, I shouldn't check stuff on Doom9 while I'm at work, but I'm... like... addicted to this forum as I end up here most of the time anyway since I use Avisynth at work on a daily basis. :P

Katie Boundary

23rd September 2021, 00:14

Let's just stick with "difference" and we're good XD
No, jokes aside, we understand what you're saying, honestly, we do, but on the other hand it's just not as easy to detect differences (motion in your case) through an algorithm,

It totally is. There's an unlimited number of algorithms that you can make based on the guidelines that I posted, but pretty much any algorithm based on those guidelines will be better than the options present in TFM.

Example algorithm 1:

Find average of A and E.
Find average of B and D.
If C is closer to the average of A and E than to the average of B and D, then treat C as interlaced.

Example algorithm 2:

m1 = |A-B|
m2 = |B-C|
m3 = |C-D|
m4 = |D-E|
n1 = |A-C|
n2 = |B-D|
n3 = |C-E|
If m1, m2, m3, and m4 are all bigger than n1, n2, and n3, then treat C as interlaced.

Frank62

23rd September 2021, 11:43

No. Motion means that a thing used to be in one place in space, and now it's in another.

That's correct. But I wrote: "In connection with video", where your explanation/definition never happens. We are talking of pixels, bits, information, representations of pictures, not of "things".

SaurusX

24th September 2021, 19:53

Anyone ever run into this problem with TFM? The field matching fails to use the correct field combination and you end up with chunky aliased edges, particularly apparent in animation lines. It never happens if the source is completely stable, but if there's gate weave from a film source then hold on to your hat. You have to manually override with the correct field combo.

https://imgsli.com/NzA0MjU

This is a small-fry example. On occasion the entire frame will be huge chunky (but not combed) scanlines.

VoodooFX

25th September 2021, 03:37

This is a small-fry example.

Share a short snippet of original video and your script.

SaurusX

25th September 2021, 18:38

Share a short snippet of original video and your script.

Check out frame 32 and 33 in this clip using the following script.

MPEG2SOURCE("E:\Media\Video Editing Tools\MeGUI-2913-64\scripts\SwatKats\Tests\SwatKats Example.d2v")
TFM(slow=2,pp=4,mode=4)
TDecimate(mode=1)

https://mega.nz/file/qjpgXRqK#kS4NW-0oxPp_4qyearShAsfnTvHTuOPjYM7B-Y-mYmE

VoodooFX

25th September 2021, 20:56

Anyone ever run into this problem with TFM?
Many times, especially on animations like this.

Instead of TFM try this line (check if it fixes more than it destroys):
QTGMC(Preset="Slower").SelectOdd.TDecimate(mode=1).QTGMC( Preset="Medium", InputType=1, Sharpness=0.2)

Katie Boundary

26th September 2021, 08:35

I wrote: "In connection with video", where your explanation/definition never happens.

LOL, are you high? It happens all the time in video. It's the primary cause of differences between frames.

Frank62

27th September 2021, 08:57

Senseless. :rolleyes:

markfilipak

9th October 2021, 01:25

Katie Boundary! Hahaha... The joke's on you, folks. I visualize a T.Rex eating a guy who's sitting on a toilet as a comet streaks across the sky.

Edit: Oh, I see "Miss Boundary" has a T.Rex as an avatar -- that, after enlarging it to see it well. Well, "Miss Boundary", you need a better looking/better defined avatar. People are missing the joke.

videoh

9th October 2021, 14:22

I think you are the only guy that missed it.

VoodooFX

9th October 2021, 17:32

Unless it's around a scene change. Or it's a fade. Or there's literally any other change in the image that isn't caused by motion (someone turns a light on, for example).
But photons are moving from a bulb to a camera's lens...
A scene change and a fade... thermodynamics would tell that there is no motion, but quantum mechanics would disagree, I think. Anyway, a film editor moved his hand to make those effects, so literally they are caused by motion too. :p

markfilipak

9th October 2021, 20:32

I think you are the only guy that missed it.
I missed it? Hahaha... Missed what? I laughed my ass off. This whole thread segment with "Miss Boundary" is the silliest thing I've read in a long time. Thanks for the laughs.

LigH

10th October 2021, 13:46

Well, unfortunately it distracts from the topic. Much of the "discussion of basics of interlacing" deserves a separate thread. And a lot less personal insults. After all the time and number of involved people, it is now a bit hard to separate.

kedautinh12

16th September 2022, 00:55

Latest ver:
https://github.com/pinterf/TIVTC/releases

Blankmedia

16th September 2022, 20:21

From time to time I get this error with requestlinear:

"avs+ [FLAW]: RequestLinear: internal error (frame not cached)! occurred while reading frame 0"

And this is while running the same script, like I stopped the encode for whatever reason, start it back, get the error, flush intermediate files, get the error, reboot, get the error, type this message, no more error and encode is proceding (??).

Maybe I have trouble settings the parameters, so is there bigger documentation somewhere with requestlinear.

I run it because apparently there's a random bug in mvtools where it shoots a random frames from time to time.

This is the line I use :

RequestLinear(rlim=60, clim=100, elim=40)

it seem more stable than what I used before

RequestLinear(rlim=50, clim=100, elim=25)

Edit:

I run the script through x265 patman.

And even in avsmeter it started to fail. Avsmeter doesn't say anything, it just close quickly.

Edit 2:
it is not more stable.

I don't get it.

ClearAutoloadDirs()
#~ AddAutoloadDir("D:\A encoder\avs_simpsons_plugin")
AddAutoloadDir("D:\A encoder\simps_s02_60FPSv3\simps_s02_60FPSv3_plugin")
AddAutoloadDir("D:\A encoder\simps_s02_60FPSv3\simps_s02_60FPSv3_plugin\SMDegrain v3.5.3d")
SetMemoryMax(8192*3)
SetCacheMode(0)

chemin = "D:\A encoder\simpsons s02_enc\Simpsons_S02E01.d2v"

d2vsource(chemin, idct=5)

RequestLinear(rlim=50, clim=100, elim=25)
# RequestLinear(rlim=60, clim=100, elim=40)

RoboCrop(LeftAdd=2, TopAdd=0, RightAdd=0, BotAdd=0)
Convertbits(16)
QTGMCp( Preset="Very Slow", SourceMatch=3, Lossless=2, Tr2=3, Nnsize=3, NNeurons=3, EdiMode="BWDIF+NNEDI3").Selecteven()
TDecimate(Mode=1)

### Color Conversion ###
fmtc_bitdepth(bits=32, fulls=False, fulld=True)
fmtc_resample (css="444")
fmtc_matrix (mats="601", col_fam="RGB")
fmtc_transfer (transs="1886", transd="linear")
#~ fmtc_primaries (prims="470bg", primd="709")
fmtc_primaries (prims="601-525", primd="709")
fmtc_transfer (transs="linear", transd="1886")
fmtc_matrix (mat="709", col_fam="YUV")
fmtc_resample (css="420")
fmtc_bitdepth(bits=16, dmode=1, fulls=True, fulld=False)

### Adjust Color ###
MergeChroma(aWarpSharp2(Depth=14))

### Gibbs Noise Block ###
a=last
ex_boxblur(0,1,mode="mean")
turnright()
ex_median("verticalS")
turnleft()
ex_median("IQM")

# Valley Mask
edge=FlatMask(1, scale=10).removegrain(2)
Mask=ex_makediff(Edge.MT_Inflate().ex_Expand(4).ex_gaussianblur(6,UV=1),Edge.MT_Inflate(),dif=false).Blur(1.0) #.ex_gaussianblur(6,UV=2)

a.MT_Merge(a.ex_median("EMF").ex_median("EMF").ex_Minblur(1).ex_median("STWM"),Mask,Luma=True)

# ex_adddiff(mask.converttoyuv420(), dif=False)

### Derainbow ###

masklisse = ex_median("IQM").blur(0.25).Removegrain(17).Flatmask(lo=4,MSR=80,scale=8).ex_inflate(2).Removegrain(7).Removegrain(17) #.maa2().ex_median("STWM") #.ex_expand(1,"disk").ex_inpand(1,"disk")#.mt_binarize(threshold=25).ex_smooth(2,sharp=true)
masklisse = masklisse.ex_Expand(2, "disk").ex_median("STWM")
MT_Merge(last , ChubbyRain3().DFMDeRainbow(maskthresh=10, mc=False, use_Flux5framesT=False).ex_median("STWM"),masklisse,Luma=True)
#~ return ex_adddiff(masklisse.converttoyuv420(), dif=False)

### Overall Temporal Denoise ###
ConvertBits(bits=8)
#~ TemporalDegrain2(degrainTR=3, grainLevel=2, postFFT=5, postSigma=0.75, fftthreads=8,degrainPlane=0)
TemporalDegrain2(degrainTR=4, grainLevel=3, postFFT=5, postSigma=0.75, fftthreads=8,degrainPlane=0)
ConvertBits(bits=16)

### Resize ###
Crop(2,2,-2,-2)
deep_resize(960, 720,flat="nnedi3",grain=0,qual=1)

aWarpSharp2(type=1,Depth=4)
Sharpen(0.2)

### Darken-Thin Lines ###

#~ F=last
#~ S=F.FastLineDarkenMod(Strength=24,Prot=6).aWarpSharp2(Blur=4,Type=1,Depth=9,Chroma=2)
#~ D=ex_MakeDiff(S,F)
#~ ex_adddiff(Last,D,Dif=True,UV=2)

F=last
S=F.FastLineDarkenMod4(Strength=72,Prot=36,thinning=36).halobuster(thr=2, elast=2).aWarpSharp2(Blur=4,Type=1,Depth=4,Chroma=1)
D=ex_MakeDiff(S,F,UV=1)
ex_adddiff(Last,D,Dif=True,UV=2)

# F=last
# S=F.FastLineDarkenMod4(Strength=72,Prot=36,thinning=36).halobuster(thr=2, elast=2).aWarpSharp2(Blur=4,Type=1,Depth=4,Chroma=1).DRK(10)
# D=ex_MakeDiff(S,F,UV=1)
# ex_adddiff(Last,D,Dif=True,UV=2)

### Resize ###
deep_resize(1440, 1080,flat="nnedi3",grain=0,qual=1)

# aWarpSharp2(Blur=16,Type=1,Depth=3,Chroma=4)

# LSFplus(preset="slow", strength=50, smode=5, edgemode=0, preblur="""ex_median("IQM")""")
LSFplus(preset="slow", strength=150, smode=5, edgemode=0, preblur="""ex_median("IQM")""")

### Deband ###
# GradFun3plus(ThR=0.45,SMode=2) # 0.45 ep 1 à 6
# Merge(GrainFactory3mod(),0.225) # 0.225 ep 1 à 6

GradFun3plus(ThR=0.55,SMode=2) # 0.45 ep 1 à 6
Merge(GrainFactory3mod(),0.3) # 0.225 ep 1 à 6

# trim(9000,12000)
# trim(9000,9200)
trim(9000,10000)
# Prefetch(12,8) # 1.491
# Prefetch(4,8) # 1.096
# Prefetch(8,8) # 1.254
# Prefetch(12,12) # 1.557
Prefetch(2,8) #

Edit 3:

I have now split the code in 2 pass, just after the Gibbs noise block.

I can run 5 encode simultaneously without problems. At least in some tests. I will let it run over night to see what happens.

Yesterday I ran 3 encode at same time in one script and I had no problem. ¯\_(ツ)_/¯

I someone have input as to why it could happen I'm open.

Also I know the script seems intense, and it is. I'm open about it. But they get pretty clean. At least cleaner than Disney+

StainlessS

19th September 2022, 05:59

Sorry for late answer, I did not see your post, not been about much lately.

I think requestLinear would be best placed AFTER RoboCrop(),
you probably get the frame not cached thingy because RoboCrop() by default samples 40 frames, spread evenly throughout the source clip,
and requestLinear might need to cache entire clip for it to work correctly.
After its pre-scan, RoboCrop delivers cropped frames as per normal.

EDIT:
I did experience some problems with DGSource some months ago [dont know if same prob in current DGSource, updated several times since],
where RoboCrop failed to find good border, and I examined RoboCrop() Debug Info output to DebugView to view 1st frame which showed no border at all.
I then inserted "Return Last" immediately after DGSource [ie no RoboCrop], reloaded clip into VDub2, and jumped to that no-border frame.
Was a full-frame multi-colored mess due to DGS not decoding frame properley at that frame entry point. Repeat with jump to 10 or so frames before the offending frame,
then stepping forward, shows that there is no decode problem, only when decode from problem frame, ie not a source clip problem, is DGS x264 decode problem [was in MKV].

Maybe its fixed now in DGS [EDIT: DGS == DGSource, DGIndexNV source filter], I dont know.

Is it similar problem that you are having, I think I just did manual crop on clips exibiting that [fairly uncommon, maybe 1 in 20 or 30 clips] prob.

EDIT: You might be able to encourage frame decode failure [for experiment] by changing RoboCrop(SAMPLES=Src.FrameCount/50) [about 2%] on a clip of
200,000 frames or so. Maybe prob happens only on clips encoded by a certain encoder, or on all clips, dont know.

EDIT: eg

DGSource("D:\Source.dgi")
FC = FrameCount
PERCENT = 2.0 / 100.0 # 2.0 %
SAMPLES = Round(FC*PERCENT)
THRESH = -40 # -40 Default with AutoThresh Prescan, use eg THRESH=56 to set Explicit Threshold without AutoThresh prescan before border detect scan [ie faster but not as good if dodgy levels clip].
RT_DebugF("FRAMECOUNT=%d %.3f%% SAMPLES=%d THRESH=%f",FC,PERCENT,SAMPLES,THRESH)
Return RoboCrop(Samples=SAMPLES,Thresh=THRESH,Debug=True)

DebugVew

00006340 0.48317650 RT_DebugF: FRAMECOUNT=150401 0.020% SAMPLES=3008 THRESH=-40.000000

00006342 0.54735380 RoboCrop: v1.13 - 07 Feb 2020 - By StainlessS
00006343 0.54740667 Input: Width=1920 Height=1080 FrameCount=150401
00006345 0.54753429 Thresh set to user supplied -40.00
00006346 0.54755449 Thresh -40.00 recognised as DEFAULT AUTOTHRESH
00006347 0.54757363 Potential Auto Credits Skip Start@5%=7520 End @90%=135360 : Range=127841
00006348 0.54759288 Skip Start(7520) and End(135360) : Range=127841
00006350 0.54766637 Samples=3008 Thresh=-40.000 Laced=True Matrix=3
00006351 0.54774839 WMod=4 HMod=4 {Colorspace/Laced Restricted XMod=2 YMod=4}
00006352 0.54783821 RLBT=15 Ignore=0.400 Baffle=4
00006353 0.54789507 ScaleAutoThreshRGB=Yes ScaleAutoThreshYUV=No
00006354 0.54799873 CropMode=2(CropMore) Blank=No Align=Yes Show=No Log=No
00006355 0.54801899 Atm=4.000 SampStart=7520 SampEnd=135360 SampRange=127841
00006356 0.54803818 LeftAdd=0 TopAdd=0 RightAdd=0 BotAdd=0
00006357 0.54805768 LeftSkip=0 TopSkip=0 RightSkip=0 BotSkip=0
00006358 0.54807669 ScanPerc=49.000000
00006359 0.54809052 Prefix='ROBOCROP_'
00006361 0.62823510 AutoThresh 1) [ 7520] YPlaneMin = 16 (16)
00006362 0.69479620 AutoThresh 2) [ 7563] YPlaneMin = 16 (16)
00006363 0.75452262 AutoThresh 3) [ 7605] YPlaneMin = 16 (16)

# ...

00009366 126.16909790 AutoThresh 3006) [135275] YPlaneMin = 16 (14)
00009367 126.23580170 AutoThresh 3007) [135317] YPlaneMin = 16 (14)
00009368 126.29372406 AutoThresh 3008) [135360] YPlaneMin = 16 (14)

# ...

00009370 126.29382324 YPlaneMin=14 : Automatic set Thresh=54.000
00002917 122.82308197 Top 1) [ 7520] AveY= 92.22 Y1= 20
00009373 126.36152649 Bot 1) [ 7520] AveY= 81.78 Y2=1059
00009374 126.36154938 Lft 1) [ 7520] AveY= 90.43 X1= 1
00009375 126.36158752 Rgt 1) [ 7520] AveY= 70.37 X2=1919
00009376 130.46037292 Lft 100) [ 11729] AveY= 77.79 X1= 0
00009378 249.04609680 Active Frames (where image coords first found) = 2
00009379 249.04611206 Sampled ImageEdge: X1=0 Y1=20 X2=1919(W=1920,0) Y2=1059(H=1040,-20)
00009381 249.04624939 Crop(ModW/H): X = 0 Y = 20 W =1920(0) H =1040(-20)
00009382 249.04632568 Input: Width=1920 Height=1080
00009383 249.04640198 Crop(0,20,1920,1040)
00009384 249.04647827 Crop(0,20,0,-20)
00009385 249.04650879 Constructor Scan Total Time=248.555 secs

Border Edge
Sample Number
Frame Number
Scanline_H/V Luma Y
Coord
Above, Top, Bot, and Right borders found on first sample frame, but Left edge not found until 100'th sample,
prior to 100'th sample, best Left border was at X coord 1, at 100'th sample Left X coord found to be 0.
The test clip above did NOT reveal any bad decode in current DGS.

Blankmedia

22nd September 2022, 02:09

StainlessS

29th September 2022, 19:08

EDIT: Current Pinterf mod TIVTC, Both x64 & x86 versions.

Presume this is some kind of diff overflow bug in FieldDiff(),

#WhateverSource(...)
OPT=4 # (default) Auto
#OPT=0 # Use C routines
FieldDiff(debug=true,display=true,opt=OPT)
return last

Similar to both display and DebugView, thoughout video clip.

OPT=4 (Default)

00007315 3.68521953 FieldDiff: Frame = 14233 Diff = -207589436161 (sad)
00007316 3.73933315 FieldDiff: Frame = 14234 Diff = -207589439628 (sad)
00007317 3.76845598 FieldDiff: Frame = 14235 Diff = -207589438673 (sad)
00007318 3.81965804 FieldDiff: Frame = 14236 Diff = -207589375022 (sad)
00007319 3.85039353 FieldDiff: Frame = 14237 Diff = -207589400222 (sad)
00007320 3.88973689 FieldDiff: Frame = 14238 Diff = -207589383803 (sad)
00007321 3.93053317 FieldDiff: Frame = 14239 Diff = -207589353349 (sad)
00007322 3.97270870 FieldDiff: Frame = 14240 Diff = -207589428124 (sad)
00007323 4.05432177 FieldDiff: Frame = 14241 Diff = -207589397993 (sad)
00007324 4.05959177 FieldDiff: Frame = 14242 Diff = -207589429589 (sad)
00007325 4.08584976 FieldDiff: Frame = 14243 Diff = -207589433196 (sad)

OPT=0 # C

00000093 12.88996887 FieldDiff: Frame = 14233 Diff = -412316210604 (sad)
00000094 12.89195728 FieldDiff: Frame = 14234 Diff = -412316214071 (sad)
00000095 12.89433861 FieldDiff: Frame = 14235 Diff = -412316213116 (sad)
00000096 12.89671803 FieldDiff: Frame = 14236 Diff = -412316149465 (sad)
00000097 12.89924335 FieldDiff: Frame = 14237 Diff = -412316174664 (sad)
00000098 12.90135288 FieldDiff: Frame = 14238 Diff = -412316158245 (sad)
00000099 12.90339375 FieldDiff: Frame = 14239 Diff = -412316127792 (sad)
00000100 12.90548992 FieldDiff: Frame = 14240 Diff = -412316202567 (sad)
00000101 12.90757942 FieldDiff: Frame = 14241 Diff = -412316172435 (sad)
00000102 12.90983963 FieldDiff: Frame = 14242 Diff = -412316204032 (sad)
00000103 12.91174793 FieldDiff: Frame = 14243 Diff = -412316207639 (sad)

Above SAD.
[sse=true, = similar results (sum of squared errors, I think)].
Also different result for auto or C.

EDIT: PAL DVD source.
720 * 576 * 255 = only 105,753,600.

EDIT: Perhaps not limited to 0, after subtract of noise threshold. [avoid -ve addition to unsigned SAD]
Something like
Abs(a-b) - nt instead of Max(Abs(a-b) - nt, 0), just guessing.

FieldDiff(int nt, bool chroma, bool display, bool debug, bool sse, int opt)

kedautinh12

30th September 2022, 02:24

EDIT: Current Pinterf mod TIVTC, Both x64 & x86 versions.

Presume this is some kind of diff overflow bug in FieldDiff(),

#WhateverSource(...)
OPT=4 # (default) Auto
#OPT=0 # Use C routines
FieldDiff(debug=true,display=true,opt=OPT)
return last

Similar to both display and DebugView, thoughout video clip.

OPT=4 (Default)

00007315 3.68521953 FieldDiff: Frame = 14233 Diff = -207589436161 (sad)
00007316 3.73933315 FieldDiff: Frame = 14234 Diff = -207589439628 (sad)
00007317 3.76845598 FieldDiff: Frame = 14235 Diff = -207589438673 (sad)
00007318 3.81965804 FieldDiff: Frame = 14236 Diff = -207589375022 (sad)
00007319 3.85039353 FieldDiff: Frame = 14237 Diff = -207589400222 (sad)
00007320 3.88973689 FieldDiff: Frame = 14238 Diff = -207589383803 (sad)
00007321 3.93053317 FieldDiff: Frame = 14239 Diff = -207589353349 (sad)
00007322 3.97270870 FieldDiff: Frame = 14240 Diff = -207589428124 (sad)
00007323 4.05432177 FieldDiff: Frame = 14241 Diff = -207589397993 (sad)
00007324 4.05959177 FieldDiff: Frame = 14242 Diff = -207589429589 (sad)
00007325 4.08584976 FieldDiff: Frame = 14243 Diff = -207589433196 (sad)

OPT=0 # C

00000093 12.88996887 FieldDiff: Frame = 14233 Diff = -412316210604 (sad)
00000094 12.89195728 FieldDiff: Frame = 14234 Diff = -412316214071 (sad)
00000095 12.89433861 FieldDiff: Frame = 14235 Diff = -412316213116 (sad)
00000096 12.89671803 FieldDiff: Frame = 14236 Diff = -412316149465 (sad)
00000097 12.89924335 FieldDiff: Frame = 14237 Diff = -412316174664 (sad)
00000098 12.90135288 FieldDiff: Frame = 14238 Diff = -412316158245 (sad)
00000099 12.90339375 FieldDiff: Frame = 14239 Diff = -412316127792 (sad)
00000100 12.90548992 FieldDiff: Frame = 14240 Diff = -412316202567 (sad)
00000101 12.90757942 FieldDiff: Frame = 14241 Diff = -412316172435 (sad)
00000102 12.90983963 FieldDiff: Frame = 14242 Diff = -412316204032 (sad)
00000103 12.91174793 FieldDiff: Frame = 14243 Diff = -412316207639 (sad)

Above SAD.
[sse=true, = similar results (sum of squared errors, I think)].
Also different result for auto or C.

EDIT: PAL DVD source.
720 * 576 * 255 = only 105,753,600.

EDIT: Perhaps not limited to 0, after subtract of noise threshold. [avoid -ve addition to SAD]
Something like
Abs(a-b) - nt instead of Max(Abs(a-b) - nt, 0), just guessing.

FieldDiff(int nt, bool chroma, bool display, bool debug, bool sse, int opt)

Can you report to him here?? Cause he access to doom9 rarely

flossy_cake

3rd October 2022, 10:55

Hello, I have some 30p streams which contain a mix of 1:1 (30fps) and 1:1:1:2 (24fps) cadences inside them. Is it possible to use TDecimate to convert these into a 60p stream containing 2:2 (30fps) and 3:2 (24fps)?

The closest I can get is 2:2 and 3:3:2:2 with this bodge:

ChangeFPS(120000,1001)
TDecimate(mode=1,hybrid=0,cycle=4,cycleR=2,vidThresh=1.1,display=true)

Test clip: https://drive.google.com/file/d/10pqePJ3oYjwDmKES233k7Il61sufzIy-/view

The first 8 seconds are 1:1:1:2 followed by 5 seconds of 1:1. If you are using MPC-HC you can step through each frame with ctrl+arrows to count the cadence manually.

Katie Boundary

3rd October 2022, 22:24

Hello, I have some 30p streams which contain a mix of 1:1 (30fps) and 1:1:1:2 (24fps) cadences inside them. Is it possible to use TDecimate to convert these into a 60p stream

TDecimate is for reducing your frame rate, not increasing it.

StainlessS

3rd October 2022, 23:09

not increasing it
I think he/she knows that.
Is increasing to 119.880 FPS [NTSC weird 120fps], then decimating to NTSC 60fps.
[intention to get smoother playing result without losing any source frames, I think, something like that.]

His/her other thread:- https://forum.doom9.org/showthread.php?t=184448

hello_hello

4th October 2022, 17:46

Hello, I have some 30p streams which contain a mix of 1:1 (30fps) and 1:1:1:2 (24fps) cadences inside them. Is it possible to use TDecimate to convert these into a 60p stream containing 2:2 (30fps) and 3:2 (24fps)?

Are there a lot of video sections? I ask, because the only way I could get the 3:2 cadence was to do it the hard way (samples downscaled to reduce the file size).

Trim(0,274).TDecimate().ChangeFPS(60000,1001) ++ \
Trim(275,0).ChangeFPS(60000,1001)

CFR.mkv (https://files.videohelp.com/u/210984/CFR.mkv)

Variable frame rate easier?

# Analysis pass (comment out any filters after TDecimate so they don't run)
# TFM(Output=FTFM()).TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# Encoding pass (uncomment any filters after TDecimate)
TFM(Input=FTFM()).TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())

Sample x264 command line:
x264.exe --level 4.1 --preset slow --tune film --crf 18.0 --tcfile-in "D:\VFR_TIMES.txt" --output "D:\VFR.mkv" "D:\VFR.avs"

VFR.mkv (https://files.videohelp.com/u/210984/VFR.mkv)

Functions for automatic file name creation based on the script name.
Creates files in the script folder. If no script exists (ie before saving a script when using AVSPMod) they're configured to save to the root of drive D, but without using the script name (obviously).

# ===============================================================================

function FTFM() {

Try{
ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
FileName = ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName) + "_TFM.txt" }
catch(err){ FileName = "D:\_TFM.txt" }

return FileName }

# -------------------------------------------------------------------------------

function FTDec() {

Try{
ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
FileName = ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName) + "_TDecimate.txt" }
catch(err){ FileName = "D:\_TDecimate.txt" }

return FileName }

# -------------------------------------------------------------------------------

function FTC() {

Try{
ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
FileName = ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName) + "_TIMES.txt" }
catch(err){ FileName = "D:\_TIMES.txt" }

return FileName }

# ===============================================================================

flossy_cake

5th October 2022, 00:27

Thank you, the result of VFR.mkv is perfect :)

But is there a reason why TFM() needs to be used if it's not interlaced?

hello_hello

5th October 2022, 03:06

At one stage TDecimate required a TFM metrics file for mode=5, but the help file now says:

As of version 0.9.11.8 of TDecimate, an input and tfmIn file are no longer
required for mode 5. If an input file is not specified then a value of
ULLONG_MAX-1 (the maximum value tdecimate has) is assigned to all metrics.
Likewise, if a tfmIn file is not specified then all matches are assigned as 'c',
not combed, and not a d2v duplicate.

I'm not sure I fully understand that though. Including TFM shouldn't do any harm.

flossy_cake

5th October 2022, 10:54

Variable frame rate easier?

# Analysis pass (comment out any filters after TDecimate so they don't run)
# TFM(Output=FTFM()).TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# Encoding pass (uncomment any filters after TDecimate)
TFM(Input=FTFM()).TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())

After some faffing about it seems for my purposes I can just go:

TDecimate(mode=3, hybrid=2, viddetect=2, cycle=5, cycleR=1, mkvOut="TIMES.txt")

But TDecimate requires "linear access" for mode3 and won't let me call it from ffmpeg. Maybe Virtualdub can manage it?

Anyway I did manage to get ffmpeg crunching with this:

ffmpeg -i "VFRpass1.avs" -threads 4 -f null NUL && ffmpeg -i "VFRpass2.avs" -threads 4 -f null NUL

VFRpass1.avs:
LWLibavVideoSource(source="1112-11.mkv", cache=false)
TDecimate(mode=4, hybrid=2, viddetect=2, cycle=5, cycleR=1, output="FTDEC.txt")

VFRpass2.avs:
LWLibavVideoSource(source="1112-11.mkv", cache=false)
TDecimate(mode=5, hybrid=2, viddetect=2, cycle=5, cycleR=1, input="FTDEC.txt", mkvOut="TIMES.txt")

Skipping the TFM() step doubles my framerate from 150fps to 300fps, and it seems to be working -- the TIMES.txt file it generates is identical. The viddetect=2 is required though. Seems to be something buggy going on with that.

ffmpeg says it supports vfr encoding with "-vsync vfr" but I couldn't get it to work. ffmpeg doesn't seem to support matroska timecode files either but hoping someone can correct me on that.

hello_hello

5th October 2022, 12:21

Skipping the TFM() step doubles my framerate from 150fps to 300fps, and it seems to be working -- the TIMES.txt file it generates is identical. The viddetect=2 is required though. Seems to be something buggy going on with that.

What happens without viddetect=2?

I'm hopeless with ffmpeg so hopefully someone else can help you there. Although....

The first line of the timecodes file should be
# timecode format v1

This is just a guess, but try changing it to
# timestamp format v1
to see if ffmpeg will play with it then.

flossy_cake

5th October 2022, 13:25

What happens without viddetect=2?

Nevermind I was mistaken about that. The default is 3 which requires both TFM matches and TDecimate metrics to recognise it as "video". Since I never used TFM it would always fail this condition and that's why the stairs section wouldn't switch to blend. And in your example it didn't fail since you were feeding it TFM matches via the txt file.

This is just a guess, but try changing it to
# timestamp format v1
to see if ffmpeg will play with it then.

Problem is I can't even find any ffmpeg argument relating to mkv timestampcode files. The ffmpeg GUI XMediaRecode also has no such option and no control over framerate mode. Seems like ffmpeg doesn't support it at all but hoping I'm mistaken.

hello_hello

6th October 2022, 00:57

If you're not married to XMediaRecode but want to use a GUI, try MeGUI. You can just add the timecodes file in the x264 encoder configuration. https://i.ibb.co/QvhkcMG/1.png
I still don't know if x265 has a VFR mode and MeGUI's x265 encoder configuration is pretty basic anyway.

I'm not sure I understand the "linear access" problem you mentioned earlier, but the TIVTC plugin has a RequestLinear() function if that's any help.

flossy_cake

6th October 2022, 03:52

# Analysis pass (comment out any filters after TDecimate so they don't run)
# TFM(Output=FTFM()).TDecimate(Mode=4, Hybrid=2, Output=FTDec())

# Encoding pass (uncomment any filters after TDecimate)
TFM(Input=FTFM()).TDecimate(Mode=5, Hybrid=2, Input=FTDec(), TFMIn=FTFM(), mkvOut=FTC())

Sample x264 command line:
x264.exe --level 4.1 --preset slow --tune film --crf 18.0 --tcfile-in "D:\VFR_TIMES.txt" --output "D:\VFR.mkv" "D:\VFR.avs"

I'm trying to reproduce this and am totally confused, because the file VFR_TIMES.txt won't exist until after the "encoding pass" in your VFR.avs is complete, so I'm not sure how you are feeding that as an input to x264.exe if it hasn't been created yet.

If you wouldn't mind, could you split it up into:

VFR pass1.avs
VFR pass2.avs
Inputfile for x264.avs

edit: also this is my VFR_TIMES.txt, it seems correct though as I've stepped through the video and identified frame 219 is the last of the 24p section

# timecode format v1
Assume 29.970030
# TDecimate v1.0.8 by tritical
# Mode 5 - Auto-generated mkv timecodes file
0,219,23.976024
# vfr stats: 51.02% film 48.98% video
# vfr stats: 275 - film 264 - video 539 - total
# vfr stats: longest vid section - 0 frames
# vfr stats: # of detected vid sections - 0

flossy_cake

6th October 2022, 04:17

I'm not sure I understand the "linear access" problem you mentioned earlier, but the TIVTC plugin has a RequestLinear() function if that's any help.

It works!

CreateTimestampFile.avs:

file = "clips\1112-11.mkv"
LWLibavVideoSource(source=file, cache=false)
TDecimate(mode=3, hybrid=2, viddetect=2, cycle=5, cycleR=1, mkvOut="TIMES.txt")
RequestLinear()

To run it from ffmpeg:

ffmpeg -i "CreateTimestampFile.avs" -threads 4 -f null NUL

So now I have this TIMES.txt file with the required information, I just need to figure out how to use it to encode the new VFR file.

btw I tried mkvtoolnix and handbrake without success but I'm probably doing something wrong, just can't figure out what.

I'm still not clear on what the input file is when encoding the new VFR file -- is it the original 1112-11.mkv or the TDecimated version of it?

hello_hello

6th October 2022, 04:18

I'm trying to reproduce this and am totally confused, because the file VFR_TIMES.txt won't exist until after the "encoding pass" in your VFR.avs is complete, so I'm not sure how you are feeding that as an input to x264.exe if it hasn't been created yet.

If you wouldn't mind, could you split it up into:

VFR pass1.avs
VFR pass2.avs
Inputfile for x264.avs

The timecodes file should be created as soon as you open the 2nd pass script. The 2nd pass doesn't need to be run as such, just opened, and the timecodes file is created in an instant (assuming the 1st pass files exist).

When I'm doing a bunch of VFR encodes I often add the same scripts to MeGUI twice, once as an analysis pass and then again as an encoding job, modifying MeGUI's encoder configuration to adjust the name of the timecodes file each time if need be. The encoding pass would be commented out at that stage.

Once all the analysis passes have finished I open the scripts and comment out the analysis pass and uncomment the encoding pass, then let MeGUI run the encoding jobs. As soon as MeGUI opens each script for encoding it's timecodes file is created and as long as the name of the timecodes file added to the x264 command line matches, the encodes run normally.

If you're running the encodes via the command line yourself or using a batch file etc, you should still be able to do much the same thing.

Each script can use the same name for the timecodes file, if you prefer, because as soon as you open the 2nd pass script the existing timecodes file will be over-written, but I tend to give them unique names when encoding a bunch of scripts.

PS. The first pass files are similar. As soon as you open the 1st pass script any existing metrics files with the same names will be over-written with blank ones and you'll have to run the analysis pass again, so once it's run, be careful about opening the 1st pass script again.

hello_hello

6th October 2022, 04:29

So now I have this TIMES.txt file with the required information, I just need to figure out how to use it to encode a the new VFR file.

btw I tried mkvtoolnix and handbrake without success but I'm probably doing something wrong, just can't figure out what.

If you're VFR encoding with x264 and it's configured to write the encoded video to an MKV you don't need to add the timecodes file when muxing. It'll be created as VFR.

If you're encoding at a CFR (and probably when x264 is writing to a raw AVC stream) you'd add the timecodes to MKVToolNix under the Timecodes tab, assuming it hasn't changed (I'm using a pretty old version as I mostly use XP). Make sure the video track is the one selected when you add it.

https://i.ibb.co/WKC3fh2/Clipboard01.jpg

I don't think Handbrake will use a timecodes file for encoding. Does it accept Avisynth scripts as the input video anyway?

I'm still not clear on what the input file is -- the original 1112-11.mkv or the TDecimated version of it?

The original for encoding and the decimated/re-encoded version for muxing.

hello_hello

6th October 2022, 04:37

edit: also this is my VFR_TIMES.txt, it seems correct though as I've stepped through the video and identified frame 219 is the last of the 24p section

# timecode format v1
Assume 29.970030
# TDecimate v1.0.8 by tritical
# Mode 5 - Auto-generated mkv timecodes file
0,219,23.976024
# vfr stats: 51.02% film 48.98% video
# vfr stats: 275 - film 264 - video 539 - total
# vfr stats: longest vid section - 0 frames
# vfr stats: # of detected vid sections - 0

As long as you mean frame 219 in the output file it looks about right (unfortunately I've deleted the one I created yesterday so I can't compare them).

Edit: Here's the timecodes file I extracted from VFR.mkv. It's extracted as version 2 timecodes, but line #222 seems to be where it changes from 42ms between timestamps to 33ms. Subtract two from that because the first line isn't a timecode and the first frame is zero rather than one, and the video section starts on frame #220 (I think that's right).

VFR_track1__eng_.tc.txt (https://files.videohelp.com/u/210984/VFR_track1__eng_.tc.txt)

flossy_cake

6th October 2022, 05:25

The timecodes file should be created as soon as you open the 2nd pass script

Oh you're right it does! I was confused because I was using mode3 to generate the TIMES.txt file, and mode3 doesn't finish creating the file until the video has finished playing in MPC-HC, or finished processing in ffmpeg.

But in your case mode5 seems to be taking the TFM metrics and immediately generating the TIMES.txt file from it.

I got your code working on my end and the result is good. I tested the VFR file on my set top box @ 60hz and to my surprise it does actually manage it correctly, although there is a slight pause on the rate change.

I'm seeing some comments that VFR may not be a good idea as many devices don't handle it correctly. Given those comments I'm leaning towards the 60p CFR solution again but there doesn't seem to be a way to automate it.

hello_hello

6th October 2022, 05:50

flossy_cake

7th October 2022, 00:31

I've never had a problem with VFR but that doesn't mean it's always fine.
The Samsung TV here with a built in media player seems to play them fine and it's 11 years old. Both the Bluray players with USB inputs for video also play them fine. I have a bunch of cartoons I decimated with Dedup so the frame rate is all over the place. They're not the combinations of 24fps and 30fps you get with TDecimate. I haven't had problems with those.

Maybe it's ok then. Have you had any issues with audio going out of sync?

Wish I could get VFR working in mkvtoolnix as that seems to offer the possibility of muxing in the VFR timecodes without having to re-encode the video. But in your x264 example it requires the output of TFM().TDecimate() in order for it to work, and avisynth outputs uncompressed video so that would seem to imply it does need to be re-encoded i.e generation loss and many hours/days of 100% CPU usage (trying to preserve my PC -- don't want hotspots accumulating on the motherboard).

Are you using your normal encoder settings? Keyframe interval and that sort of thing?

The only thing I meddled with is 10-bits instead of 8 (high10 for x264; main10 for x265).

hello_hello

7th October 2022, 21:15

Maybe it's ok then. Have you had any issues with audio going out of sync?

No.

Wish I could get VFR working in mkvtoolnix as that seems to offer the possibility of muxing in the VFR timecodes without having to re-encode the video.

You can't do that because the timecodes need to have the same number of frames as the video. You can't use timecodes to skip a duplicate frame or anything like that.

flossy_cake

18th October 2022, 07:01

kedautinh12

18th October 2022, 07:15

Are you try prefetch??

flossy_cake

18th October 2022, 08:35

Are you try prefetch??

Yes but I'm probably doing it wrong. It looks very complicated like different filters need different modes and stuff: http://avisynth.nl/index.php/SetFilterMTMode#Enabling_MT

When 1080i video is choppy and audio crackling, cpu usage is around 20% but every core seems to be getting usage. Not sure if that means it's truly multithreading or not.

Anyway I did manage to get this 1080i test clip (https://drive.google.com/file/d/1AMmHwIfJrJAPb1Uv17tcGDVy_576kCZf/view?usp=sharing) TDeinting at full frame rate by setting mtnmode=0 & slow=0, eg.

FFmpegSource2("1080i25, 1-1 cadence.ts", fpsnum=25, fpsden=1, atrack=-1)
TDeint(mode=1, full=false, tryWeave=true, mtnmode=0, slow=0)

edit: nope, it seems TDeint(slow=0) causes 2:2 sections to no longer get weaved
edit2: but setting opt=0 fixes that, but then I'm back to square 1 with CPU bottleneck on 1080i playback :rolleyes:

Compatibility with source filters:
Working with AudioDub(LWLibavVideoSource(), LWLibavAudioSource()).
DSS2() working but no audio.
DirectShowSource() working but wrong field order it seems

flossy_cake

18th October 2022, 10:10

Definitely seems to be a CPU bottleneck as I can pause the video, wait a few seconds for the framebuffer to fill up, press play, then it plays smooth for about 5 seconds before choking. Then I can pause again, wait, repeat the process. Setting the CPU buffer in MadVR also extends the period of smooth playback but in the end it always catches up cause it can't fill the buffer faster than it's reading out of it.

takla

18th October 2022, 13:18

flossy_cake

18th October 2022, 15:40

Try this

FFmpegSource2(whatever)
TDeint(whatever)
Prefetch(4, 50)

Interesting result. Video starts playing, then as usual bogs down to slow motion framerate with stuttering audio, but then after about 10 seconds CPU usage spikes up to 40%, playback becomes smooth again. But then a few seconds later it bogs down with slow motion fps and stuttering audio and CPU usage back at 20%. This whole cycle then repeats itself at infinitum.

Is this happening to anyone else with that 1080i clip (https://drive.google.com/file/d/1AMmHwIfJrJAPb1Uv17tcGDVy_576kCZf/view?usp=sharing)?

i.e with TDeint("1080i, 1-1 cadence.ts", mode=1, full=false, tryWeave=true, cthresh=6, mtnmode=0, slow=1)

As mentioned previously, I can set slow=0 and get smooth playback, but then the 2:2 weave detection stops working and 2:2 sections of video are needlessly dropping to half vertical res for moving parts of the image. Which is actually worse than not deinterlacing it at all.

That 1080i clip doesn't contain any 2:2 sections but here is a 576i 2:2 cadence clip (https://drive.google.com/file/d/1HkOfMlb4P0KaqMyvoA4ZZFAsaHu54Koh/view?usp=sharing).

So just to clarify: I'm trying to get both the 1080i clip to play at full frame rate 50fps without combing artefacts, and the 576i clip to play at 25fps without vertical resolution dropping to half. This can be achieved with the TDeint settings above, however then I get slow frame rate and stuttering audio with 1080i.

But it works so it's just a matter of trying to give TDeint enough CPU cycles to work with. Something is bottlenecking it. Using other source filters doesn't seem to have any effect other than FFmpegSource2 seems to crash if I seek the 1080i clip, so I would recommend using AudioDub(LWLibavVideoSource(), LWLibavAudioSource()) .

kedautinh12

18th October 2022, 15:43

Use only prefetch(4)

flossy_cake

18th October 2022, 16:25

tdeint(mode=1)
4 threads - 496 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0,ap=25,aptype=1)
4 threads - 845 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0)
4 threads - 1150 fps
tdeint(mode=1,slow=0,type=0,mtnmode=0,edeint=nnedi3(-2))
4 threads - 209 fps
s

Ffmpeg command line says I'm only getting 54fps when calling the script from ffmpeg with

ffmpeg -i "c:\temp\scripts\avisynth\tdeint.avs" -threads 4 -f null NUL

https://i.ibb.co/sJLvrWn/fps.png

Same cpu usage as realtime avisynth with MPC-HCx64, around 15-20% :confused:

https://i.ibb.co/tczGQNw/cpu.png

edit: oh, he used a NTSC DVD. I'm getting 900fps on that 576i 2-2 clip so yeah I guess 1080i is 5x the pixels but should still be at least 60fps. Maybe something else about 1080i... maybe pixel format is different.

Use only prefetch(4)

Yep that was one of the first things I tried...

flossy_cake

18th October 2022, 18:33

I compared this configuration of TDeint to Nvidia's DXVA "video mode" deint and they seem to do a similar job with both of them using the same strategy on 1:1 sections but NVidia is slightly less responsive at switching to weave for 2:2 sections.

I forgot about how Nvidia DXVA deint screws up the chroma position and blurs it, even when unticking "use DXVA chroma upscaling when doing DXVA deinterlacing" in the renderer (it's better than not ticking it, but still noticeably wrong).

Therefore TDeint is looking better than NV DXVA deint... just need to solve the bottleneck for 1080i

takla

18th October 2022, 23:01

Just stick to yadif_cuda from ffmpeg. Your cpu is too weak for realtime 1080i.

hello_hello

19th October 2022, 01:55

Has anyone managed to get TDeint working for realtime deinterlacing of 1080i?

My system is i7-4790k & GTX1070, and TDeint realtime deint of 480i and 576i seems fine -- only 6% CPU usage and playback is smooth. But for 1080i, CPU usage is around 17% and video plays slow and stutters.

I want realtime processing as I want to avoid generation loss through transcoding.

Yeah, but that argument falls apart once you realise it has to be re-encoded to remove the monumentally annoying station logo anyway. ;)

As mentioned previously, I can set slow=0 and get smooth playback, but then the 2:2 weave detection stops working and 2:2 sections of video are needlessly dropping to half vertical res for moving parts of the image. Which is actually worse than not deinterlacing it at all.

That 1080i clip doesn't contain any 2:2 sections but here is a 576i 2:2 cadence clip (https://drive.google.com/file/d/1HkOfMlb4P0KaqMyvoA4ZZFAsaHu54Koh/view?usp=sharing).

Are you sure that's what's happening?

Edit: I now realised you said "moving parts of the image" so maybe I misunderstood what you meant, but I'll leave the post as-is in case it's useful for someone else. There's info you may not be aware of at the end of this post regarding TryWeave and your progressive sample though.

I haven't used TDeint much so I'm trying to make sure I understand what it's options do, but the way I read the TryWeave info, it tries to match each field with both the previous and next one before repairing any combing, rather than rigidly combining fields in a set order. Either way though, it only messes with pixels where combing is detected (at least by default).

An easy way to see the pixels it's fiddling with is to do something like this. The pixels that would normally be taken from a de-interlaced version of the video to repair combing are the red ones.

A = last
B = BlankClip(A, color=color_red)
TDeint(edeint=B)

For the frame below, TryWeave=true results in a match without combing, whereas there's combing when TryWeave=false, but it's only fiddling with the combed pixels and the resolution remains the same for the rest of the frame. For some frames the detected combing is the same regardless of the TryWeave setting. Slow=true does seem to prevent TryWeave working though.

https://i.ibb.co/NNzZSss/1.jpg

A = last
B = BlankClip(A, color=color_red)
TDeint(TryWeave=true, edeint=B)

https://i.ibb.co/WD1XSVQ/2.jpg

I've read the description for the Full argument about 20 times and I'm still not sure I get it, but I think it's only intended for when TDeint is being used as a post-processor for another filter such as TFM.

The important parts of the description seem to be these.

With the addition of full=false, another way to use TDeint as a post-processor is to have it use its own combed frame detection as follows (this also allows it to work with any field matcher, not just telecide or tfm)

true - normal processing
false - check all input frames for combing first

So for the example below... I think......
When full=true, TDeint checks TFM's output and repairs any combing.
When full=false, it appears to check the original video (clip2) along with TFM's output, and uses the frames requiring the least amount of combing repair. Something like that.... I think....

A = last
B = BlankClip(A, color=color_red)
TFM(pp=1)
TDeint(Full=false, edeint=B, clip2=A)

By the way, pretty much all PAL DVDs are encoded as interlaced even if they're progressive, and for whatever reason, it's not uncommon for the fields to be misaligned, or out of phase. So they can look and smell quite interlaced even when they're not. Before I knew better I de-interlaced quite a few progressive PAL DVDs requiring nothing more than TFM() to match the fields up correctly. I'm pretty sure that's the case for your sample. Even if you tell it not to repair combing, TFM(pp=1) still fixes most of it. For TDeint, TryWeave allows it to do the same thing. For normal interlaced content though, or for progressive content that's not messed up the same way, I don't think TryWeave would be able to magically make so much combing disappear.

flossy_cake

19th October 2022, 14:23

Thanks for the advice. Given what you said about lots of PAL DVD's having screwed up field order then it sounds like TDeint alone wouldn't be sufficient as a "1 size fits all" solution and I would need to use TFM as well.

btw TDeint can do the pixel debug thing with eg. slow=0, map=2, then you should see a lot of pixels in purple being unnecessarily interpolated on the 576i 2:2 clip . Then set slow=1 and the purple pixels go away, at least that's how it's behaving on my machine. Or just step through frame-by-frame and notice the interpolation aliasing on fine details.

It's weird though cause the interpolation only lasts for a single 20ms frame of the 50p output -- on the 2nd 20ms frame it's full progressive, like this:

0ms: frame A field 1 interpolated to 576p (purple pixels)
20ms: frame A field 1+2 weaved to 576p (no purple pixels)
40ms: frame B field 1 interpolated to 576p (purple pixels)
60ms: frame B field 1+2 weaved to 576p (no purple pixels)

Annoyingly just enough to ruin the output and produce line twitter and the perception of half res :)

I'm super annoyed about the chroma issue with NVidia DXVA deint! That was my main solution that I remembered isn't such a great solution anymore. I can sort of compensate with z_ConvertFormat(chromaloc_op="top_left=>center", interlaced=true) which shifts the chroma location from center to top left, but it's still not right. The chroma is duller and more blurry. Great job NVidia!

I tried also a few hours fiddling with DGTelecide() and PVBob(). Couldn't get the former to do full framerate, and the latter doesn't have any 2:2 detection so half res on moving 2:2 sections.

*sigh*

flossy_cake

19th October 2022, 16:51

I suppose my ideal realtime deinterlacer would go something like this

if cadence != 1:1
use TFM().TDecimate() or MadVR's film mode deint
else
use full framerate deint, eg. TDeint(mode=1) or BWDIF(field=-2) or yadifmod2(mode=1)

This should result in something where no frames or resolution is lost.

I have found that MadVR's film mode deint is very competent at detecting a whole range of cadences in realtime and dealing with dynamically changing cadences and field orders (it even gets the 1080i cheese slices right which is a stupid clip that would never occur in reality). It also runs flawlessly on my i7-4790k with very low CPU usage (<10%) and runs on the CPU apparently.

If anyone knows how to implement such a solution in Avisynth, please advise :thanks:

flossy_cake

20th October 2022, 07:44

Just stick to yadif_cuda from ffmpeg. Your cpu is too weak for realtime 1080i.

Yadif is ok. At full frame rate it makes some nice smooth diagonal lines when typical field interpolation results in more aliasing. But it can't resolve the stationary 1px black & white lines pattern and some other high contrast 1px height parts of the image. It also seems to look slightly softer on details eg. texture in a person's hair. Softer but smoother and less aliased. I think I would prefer BWDIF but even that is still only "ok". Neither will weave 2:2 motion in full frame rate mode so that's throwing away half the available resolution for no good reason and that is why I can't accept them as a general purpose deint.

For 1080i25 1:1 cadence with TDeint(slow=1) my CPU is at 18% usage and getting only 45fps which is not enough for realtime use. Doesn't this seem like a bottleneck? Theoretically shouldn't it do 90fps @ 36% CPU?

takla

20th October 2022, 17:06

Multithreading doesn't scale linearly. But you can try Prefetch(8) if you're fine with high cpu usage. Also, use ffmpeg -benchmark -i whatever to see your fps

flossy_cake

20th October 2022, 18:12

Also, use ffmpeg -benchmark -i whatever to see your fps

I was just outputting to NUL:

ffmpeg -i "c:\temp\scripts\avisynth\tdeint.avs" -threads 4 -f null NUL

https://i.ibb.co/sJLvrWn/fps.png

Is that the same or did you mean something different?

On an unrelated note, there seems to be a small errata with this:

Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates. The duplicate detection uses the dupThresh parameter.
http://avisynth.nl/index.php/TIVTC/TDecimate

The bit in bold doesn't seem to be the case, as I can lower dupThresh to a very low value like 0.2 so that the duplicate is above the threshold and gets detected as "(new)" in the display=true debug, and yet it still says underneath it "DROP" and drops the frame decimating the 30p stream to 24p:

https://i.ibb.co/CtW4DhF/drop2.png

Not that this really matters for my usage purposes but it leaves me curious about which scenario dupThresh would actually get used.

hello_hello

20th October 2022, 18:57

Thanks for the advice. Given what you said about lots of PAL DVD's having screwed up field order then it sounds like TDeint alone wouldn't be sufficient as a "1 size fits all" solution and I would need to use TFM as well.

I'm not sure why TryWeave wouldn't work well for a progressive source, as long as there's no telecine and it's just matching the fields to restore the progressive frames. Although for 3:2 pulldown I think it should work and the result would probably be the same as for TFM, assuming TDeint(mode=0).
TFM's field matching does a fair bit more checking to find the best match though, and unlike TryWeave the best match is used even if there's combing to repair, and of course TFM can't output a double frame rate. There's all sorts of horrors for a field matcher to deal with at times, especially for NTSC. For quite a while it was common practice to overlay one type of video on another, such as applying telecine to film to make it 29.97i, then overlaying the telecined fields with something truly interlaced or progressive. When that sort of thing happens you can't just remove the telecined fields without effecting the interlaced stuff overlaid on top, or just de-interlace and remove the telecine too. For an interlaced display it's fine, but not so much for making progressive frames. Anyway for progressive PAL, if lining the fields up correctly is all that's required, TryWeave should be fine.

btw TDeint can do the pixel debug thing with eg. slow=0, map=2, then you should see a lot of pixels in purple being unnecessarily interpolated on the 576i 2:2 clip . Then set slow=1 and the purple pixels go away, at least that's how it's behaving on my machine. Or just step through frame-by-frame and notice the interpolation aliasing on fine details.

It's weird though cause the interpolation only lasts for a single 20ms frame of the 50p output -- on the 2nd 20ms frame it's full progressive, like this:

0ms: frame A field 1 interpolated to 576p (purple pixels)
20ms: frame A field 1+2 weaved to 576p (no purple pixels)
40ms: frame B field 1 interpolated to 576p (purple pixels)
60ms: frame B field 1+2 weaved to 576p (no purple pixels)

Annoyingly just enough to ruin the output and produce line twitter and the perception of half res :)

When you include slow=0 for your 25i sample
TDeint(mode=1, tryweave=true, map=2, slow=0)
TryWeave no longer works and TDeint is only managing to find a perfect match for every second field.
Therefore every second frame needs to be repaired after field matching, so they alternate between having and not having purple pixels.
With slow=0 removed, TryWeave works properly (or it's more accurate because it's slower) and the purple pixels disappear. It's not because map=2 doesn't work without slow=0, it's because there's no longer any combing repair required.

In my head at least, for a truly progressive source, and assuming there's always movement between frames, each field can only match correctly with one other, which is the one belonging to the same progressive frame. So when mode=1 and TryWeave=true, each field should have a matching one while also being the other field's match. Or to put it another way, when field one needs a partner it might be matched to field two, and when it's time to find field two a partner it'll be matched to field one and you have two identical progressive frames and double the frame rate.
Of course for a truly interlaced source each field is a different moment in time, so assuming there's movement between frames there's no perfect match, and the help files says if the frame produced by TryWeave contains combing it's not used and normal interpolation takes over.

If for whatever reason there's a need to repair combing after field matching, and of course when de-interlacing, line twitter and aliasing etc will always be a problem. Much less so if you de-interlace with QTGMC though. Has anyone mentioned QTGMC yet? :) It's slow because it spends time repairing that sort of thing. It always bobs the entire frame though, which I don't always mind, because it's efforts to repair the de-interlacing means it naturally denoises and sharpens a little, but you can compromise.

A = last
B = A.QTGMC()
A.TDeint(edeint=B)

If TDeint needs to repair combing in every frame it'll be as slow as using QTGMC on it's own, but if not it'll be faster to some degree.

Or try changing TDeint's de-interlacing method. Sometimes even blend interpolation can look quite good, especially if it's relative to the other methods and they don't.

I'm super annoyed about the chroma issue with NVidia DXVA deint! That was my main solution that I remembered isn't such a great solution anymore. I can sort of compensate with z_ConvertFormat(chromaloc_op="top_left=>center", interlaced=true) which shifts the chroma location from center to top left, but it's still not right. The chroma is duller and more blurry. Great job NVidia!

I'm not familiar with the problem. Does it shift the chroma or upsample it incorrectly?

flossy_cake

20th October 2022, 19:33

I'm not familiar with the problem. Does it shift the chroma or upsample it incorrectly?

Both kind of. It's a known issue in the MadVR thread, and MadVR even has an setting to "avoid using DXVA chroma upscaling when doing DXVA deinterlacing", and it improves it, but still is slightly shifted and blurred. Apparently once DXVA gets its hands on the chroma, it's game over and we can't restore the original chroma back out of it. Because I think DXVA deint needs to upscale the chroma to 4:4:4 before it can analyse pixels for combing etc. and that's where the damage is being done. Or so I'm lead to believe.

On a perfect source it's kind of tolerable but if I get a dodgy source with chroma alignment issue like TV channel 44 (you may have noticed it in the clip that chroma is shifted to the right) then it results in 2 generations of chroma mishandling and that is too much to tolerate.

edit: animated png
https://i2.lensdump.com/i/1xVHg5.png

hello_hello

20th October 2022, 19:52

The bit in bold doesn't seem to be the case, as I can lower dupThresh to a very low value like 0.2 so that the duplicate is above the threshold and gets detected as "(new)" in the display=true debug, and yet it still says underneath it "DROP" and drops the frame decimating the 30p stream to 24p:

When Hybrid=0 and for Cycle=5 and CycleR=1, each group of five frames is considered to be film and one of them has to go. If there's no duplicate in the group then it's the next best candidate. The following probably should have said "the longest remaining strings of duplicates per cycle".

Mode 1 = Exactly like mode 0, except instead of decimating the M most similar frames, frames are decimated from the longest remaining strings of duplicates.

The defaults are fine because for normal 3:2 pulldown, for every eight fields that go in, ten come out, or referring to frames instead of fields, for every four that go in five come out, so ideally you only want to reverse that. If you give TDecimate more wiggle room, for example Cycle=50 and CycleR=10, it'll still remove the same number of frames over-all, but not necessarily the same frames. I assume, in theory at least, TDecimate could decide to keep the first 40 frames in the group and remove the last ten as duplicates. Adjusting dupThresh would change the number of frames considered to be legit duplicates, and therefore the number of legit duplicates in succession for any given cycle.

For very large cycles it's possible to effect the A/V sync if the duplicates aren't distributed/decimated evenly throughout. Therefore you could look at the beginning of each cycle as also being a reset for the A/V sync.

flossy_cake

20th October 2022, 21:42

I suppose my ideal realtime deinterlacer would go something like this

if cadence != 1:1
use TFM().TDecimate() or MadVR's film mode deint
else
use full framerate deint, eg. TDeint(mode=1) or BWDIF(field=-2) or yadifmod2(mode=1)

Hmm, might be possible to do something with ConditionalFilter ?

The conditional functions are IsCombedTIVTC, CFieldDiff, and CFrameDiff which can be used via AviSynth's conditional filtering environment to test if frames are combed, determine how well two fields fit together, or calculate the difference between frames.
http://avisynth.nl/index.php/TIVTC#Description

Maybe something like...

ConditionalFilter(last, bwdif(field=-2), TFM().TDecimate(), "IsCombedTIVTC", "=", "true")

No idea what I'm doing though :o

hello_hello

21st October 2022, 12:38

Both kind of. It's a known issue in the MadVR thread, and MadVR even has an setting to "avoid using DXVA chroma upscaling when doing DXVA deinterlacing", and it improves it, but still is slightly shifted and blurred. Apparently once DXVA gets its hands on the chroma, it's game over and we can't restore the original chroma back out of it. Because I think DXVA deint needs to upscale the chroma to 4:4:4 before it can analyse pixels for combing etc. and that's where the damage is being done. Or so I'm lead to believe.

What color formats can DXVA play with?
If it'll de-interlace RGB, maybe convert to RGB before anything else. Or if you're using filters that don't work with RGB, you could try full chroma YUV instead.

For HD
ConvertToRGB32(interlaced=true, matrix="Rec709")
or
ConvertToYV24(interlaced=true)

There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right).

A = last
MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080))

On a perfect source it's kind of tolerable but if I get a dodgy source with chroma alignment issue like TV channel 44 (you may have noticed it in the clip that chroma is shifted to the right) then it results in 2 generations of chroma mishandling and that is too much to tolerate.

If you're referring to the 1080i sample I'm not seeing any chroma shift. I'm still on XP and I don't think DXVA2 works for MPC-HC any more, but I enabled Cuvid DXVA de-interlacing in LAV filters and it's a little less sharp than BWDIF but nothing too drastic. My video card's probably 12 years old and the drivers would probably be 11 years old as I never update them, so maybe they pre-date the problem.

I'd have to experiment myself to see if I could get the de-interlacing to work as you've described with ConditionalFilter. I don't use conditional filtering much. It'd probably also slow things down even more.

flossy_cake

22nd October 2022, 08:02

If you're referring to the 1080i sample I'm not seeing any chroma shift.

It was the 576i clip with the channel 44 watermark. That TV channel has issue with chroma shifted to the right slightly. Actually I have 3 generations of chroma mishandling not 2:

1. TV channel error
2. DXVA deint error
3. My Samsung TV downsampling to 4:2:2 internally

But you can see 1 vs 2 on that animated png and it still looks bad on a 4:4:4 monitor.

If it'll de-interlace RGB, maybe convert to RGB before anything else.

Great idea, but unfortunately there doesn't seem to be a way of calling DXVA deint from Avisynth. This is the deint mode MadVR uses when selecting "video mode" deint in MadVR's settings, or by tagging the file or parent folder with [deint=video]. It's unique because it is a full fps deint like bwdif(field=-2) but also has some 2:2 motion detection as well (but it's not sensitive enough for my liking... needs too much motion before it senses 2:2 so any slight camera wobble or very slow pan will still be only bobbing and look blurry/flickering -- doh! I think they set the motion threshold for 1080i which has smaller pixels so slight camera movement will travel more distance in pixels per distance camera movement).

I've tried to achieve a better result with TDeint(mode=1, full=false, tryWeave=true, slow=1) but after testing with some more clips eg. The IT Crowd DVD, its combing detection just isn't good enough either. Basically the intro sequence to the show is 2:2 then the show proper is all 1:1. The intro gets weaved nicely, but the show proper has issues on scenes where actors are sitting very still and the only thing moving is their mouth. In this case their mouth movement gets combed cause it's not above the combing detection threshold. There are myriad settings to play with: cthresh, blockx, blocky, MI etc. but despite playing with these for hours I could not achieve a good balance where the intro would get weaved and no mouth combing. The best I could get was with cthresh=3 and those other parameters left alone.

I guess I will try with just TFM() which should weave the intro sequence but I don't know how it's going to handle those problematic 1:1 scenes.

In the end I suspect I will have to use an override file to handle the intro sequence separately. It's kind of cool that we can even do such a thing, but at the same time I feel like we're annoyingly close to having a "set it and forget it" option.

edit:

Great idea, but unfortunately there doesn't seem to be a way of calling DXVA deint from Avisynth.

Actually now that I think about it, I don't think it needs to be called from Avisynth. I will give your suggestion a try -- thanks.

hello_hello

22nd October 2022, 12:32

I thought you were opening scripts in MPC-HC and using MadVR to de-interlace or something like that. Maybe I misunderstood. I almost never watch interlaced video as I always de-interlace with QTGMC and re-encode, so I haven't had much experience with "player" de-interlacing issues.

Try Metric=1 for TDeint (and TFM). It often does better on small amounts of fine combing than the default metric.
Failing that, try following TDeint with VInverse. http://avisynth.nl/index.php/Vinverse

flossy_cake

22nd October 2022, 14:49

I thought you were opening scripts in MPC-HC and using MadVR to de-interlace or something like that.

MadVR has 2 deinterlacing modes: film and video. Film uses MadVR's own CPU code to perform IVTC much like TFM().TDecimate() and it works quite well with very little CPU usage. Video I've been told just hands the frames off to the GPU driver to perform DXVA deinterlacing. This is also quite good and cheap for mixed 1:1 and 2:2 content (but not 3:2) but has the chroma issue on NVidia cards. Admittedly I'm using an old driver so I should probably update that to see if NVidia fixed it.

I tried metric=1 and saw a slight improvement allowing me to increase cthresh by 1 to achieve the same result. Ultimately still visible artefacting though and I'd still prefer bwdif which doesn't have the issue at all, but of course bwdif doesn't weave 2:2 moving sections.

Tried VInverse() which does seem to work but it's only half framerate so I can still see actor's mouths moving at 25fps compared to the rest of their face animating at 50fps. I guess human vision is very critical when it comes to facial recognition -- if something is even slightly off it will be noticed. VInverse also seems to soften the image slightly? bwdif is slightly softer than TDeint as well though so I shouldn't complain. I guess that tight weave threshold of TDeint is contributing to its slightly sharper output.

I'm applying avs scripts by simply opening them with MPC-HC so they get applied in realtime. This realtime functionality is essential to me as I want to avoid transcoding and have the flexibility of making per-season or even sometimes per-episode adjustments.

Another issue I'm dealing with is the Avisynth source filter isn't passing interlaced flags which breaks DXVA deint which for some reason requires them in order to work.

There is something unique about the interlacing in this particular show The IT Crowd. Even DXVA struggles with it and sometimes weaves pixels when it shouldn't be, leaving 1 pixel wide combing artefacts in certain patterns. Which is weird because DXVA deint looks quite clean on that 576i SDI Public Senat clip in the other thread.

flossy_cake

22nd October 2022, 15:34

Another issue I'm dealing with is the Avisynth source filter isn't passing interlaced flags which breaks DXVA deint which for some reason requires them in order to work.

Finally got to the bottom of this one -- unticking Avisynth in MPC-HC's source filters. Apparently this tells MPC-HC not to use its internal version of LAV decoders. Instead it uses Avisynth source filter only. Whereas with the box ticked I think Avisynth source filter gets passed through LAV decoder afterwards which can't see any interlaced flags cause Avisynth is just a raw uncompressed square pixel frameserver apparently.

edit: aaaand it looks like there are all kinds of audio sync issues , so it seems I need to pass it through LAV to avoid that. edit2: using a different audio renderer seems to solve that.

flossy_cake

22nd October 2022, 17:50

What color formats can DXVA play with?
If it'll de-interlace RGB, maybe convert to RGB before anything else. Or if you're using filters that don't work with RGB, you could try full chroma YUV instead.

For HD
ConvertToRGB32(interlaced=true, matrix="Rec709")
or
ConvertToYV24(interlaced=true)

There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right).

A = last
MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080))

Thanks for this.

I couldn't get any improvement with converting to 444/RGB -- whatever NVidia is doing to the chroma is some kind of permanent damaging processing regardless of what pixel format I send it.

However with MergeChroma I am able to get a "better" result, but chroma is still blurred around edges, even though it is aligned. I think NVidia's DXVA implementation might be downsampling the chroma internally as part of its deint process.

DTL

23rd October 2022, 00:07

In typical endusers motion pictures distribution formats chroma is downsampled so can not have naturally same sharpness as luma. With conversions to RGB and any 4:4:4 chroma is upsampled by some process (filter/interpolator) that can give different sharpness. Current digital subsampled formats have build-in bugs and they are not still removed and also industry do not have any standards on YUV<->RGB spatial conversions. So every hardware/software developer uses its own ideas how it can be. Also there is 2 different processings in converting subsampled->full sampled: intermediate and final (display/monitor). Intermediate is designed to keep sharpness in many sub<-> full conversions (production chain) and final is for viewing (end-user consumption). So only final conversion to display RGB have anti-gibbs conditioning filter that looks like some blurring of chroma. Intermediate production converters do not have anti-gibbs filtering so looks sharper (but can/must produce chroma/RGB ringing in some processings like scaling - so it is up to upscaler designer to keep track what is feed to its input).

Typical production workflow (1 iteration):
YUV 4:2:0 storage/delivering -> 4:4:4 RGB -> RGB adjust/blend/tuning/mix/artistic -> YUV 4:2:0 storage/delivering. Do not change digital sample count of luma (format). It uses intermediate unfiltered chroma processing to keep chroma sharpness in many iterations.

Typical end user consumption process:
YUV 4:2:0 distribution -> 4:4:4 RGB for display -> display scaling (or DAC for analog that is equal to infitine samples upscale) -> optical image for viewing. It should use final (end of chain) anti-gibbs filtered chroma upscale in 4:2:0->4:4:4 conversion.

NVIDIA for home (video playback) and DXVA are endusers processing for typical motion pictures consumption so typically should be designed with not as sharp (unfiltered) prof conversions for intermediate processing.

AVS currently do not separate intermediate/final chroma upscale so may look sharper in compare with DVXA/NVIDIA upscale for displaying.

flossy_cake

23rd October 2022, 10:30

The problem with DXVA chroma handling is that it also shifts the chroma position down and to the right by 0.5 pixels according to my tests with a 4:2:0 chroma pattern.

Also if I feed DXVA deint a true 4:4:4 test pattern and/or 4:4:4 pixel format, it STILL downsamples it to 4:2:0. Disabling DXVA deint passes full chroma.

Here is my best guess at what might be happening with DXVA deint for a 4:2:0 source:

LAV decoder outputs 4:2:0 -> MadVR upscales to 4:4:4 -> DXVA deint downscales to 4:2:0 & shift chroma location 0.5 -> final output is upscale to 4:4:4 again.

I am not sure who is doing the final output upscale to 4:4:4, it might be DXVA or it might be some other part of the GPU driver matching it to whatever chroma is set in NVCP.

In any case the extra redundant step of downscaling to 4:2:0 and back up to 4:4:4 seems to be imbuing the chroma with a bit of softness, plus the 0.5 shift makes the end result noticeably poor. Then on top of this the TV network has its own chroma shift issue, plus my TV is downsampling to 4:2:2 internally and the end result is starting to look a bit shabby.

Take those last 2 steps out and I might not be able to tell anything is wrong in a double blind test on typical content. But on a test pattern I would for sure.

I'm not really a stickler for chroma -- I see people in the MadVR thread fussing over various chroma upscaling algorithms, spending a lot of GPU cycles to do NGU chroma upscaling. But honestly I can't see much difference on anything but test patterns or sources that have chroma problems baked into the source. As long as the alignment is right, I'm satisfied with the typical filters like Bicubic, Lanczos, Spline etc. The sharper algorithms tend to do worse on sources with chroma issues baked into the source.

DTL

23rd October 2022, 11:21

DXVA2 support chroma placement signalling - https://learn.microsoft.com/en-us/windows/win32/api/dxva2api/ne-dxva2api-dxva2_videochromasubsampling .

typedef enum _DXVA2_VideoChromaSubSampling {
DXVA2_VideoChromaSubsamplingMask = 0xf,
DXVA2_VideoChromaSubsampling_Unknown = 0,
DXVA2_VideoChromaSubsampling_ProgressiveChroma = 0x8,
DXVA2_VideoChromaSubsampling_Horizontally_Cosited = 0x4,
DXVA2_VideoChromaSubsampling_Vertically_Cosited = 0x2,
DXVA2_VideoChromaSubsampling_Vertically_AlignedChromaPlanes = 0x1,
DXVA2_VideoChromaSubsampling_MPEG2,
DXVA2_VideoChromaSubsampling_MPEG1,
DXVA2_VideoChromaSubsampling_DV_PAL,
DXVA2_VideoChromaSubsampling_Cosited
} DXVA2_VideoChromaSubSampling;

Same is for DXVA (1.0) - https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dxva/ne-dxva-_dxva_videochromasubsampling

So your workflow need detect (or other ways found) correct chroma placement in your source of 4:2:0 subsampled and pass this data to the DXVA. So it is expected the DXVA processing result will be more correct. If not - you may also report issues to Microsoft support and may be NVIDIA support if you use DXVA and NVIDIA hardware - may be somewhere this chroma placement processing is broken in some Microsoft or NVIDIA layer (DirectX or NVIDIA driver or hardware).

If you use DXVA via MadVR may be you need to consult its developer or try manual set DXVA chroma placement flags to see if your execution layers of DXVA (DirectX + NVIDIA driver + NVIDIA hardware) correctly process it.

May be we need additional accept/detect/pass and manual override of chroma placement signalling to DXVA in MadVR if it still not have this interface and functions. Same as with interlacing in the old days.

flossy_cake

23rd October 2022, 13:03

May be we need additional accept/detect/pass and manual override of chroma placement signalling to DXVA in MadVR if it still not have this interface and functions. Same as with interlacing in the old days.

You could be right, however I have tested on GTX 1070 vs R9 380 and the latter has no chroma shift with DXVA deint. So it looks to be an NVidia driver issue perhaps not honouring or misinterpreting the meaning of the chroma positioning value. But I need to update my driver to see if Nvidia fixed it.

StainlessS

23rd October 2022, 14:45

I need to update my driver to see if Nvidia fixed it.

[NVidia Official Advanced Driver Search]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

DTL

23rd October 2022, 16:14

You could be right, however I have tested on GTX 1070 vs R9 380 and the latter has no chroma shift with DXVA deint. So it looks to be an NVidia driver issue perhaps not honouring or misinterpreting the meaning of the chroma positioning value. But I need to update my driver to see if Nvidia fixed it.

If your calling software do not provide correct chroma placement signalling to DXVA - it may be simply better defaults or better auto-detection in AMD/ATI driver and/or hardware.

Do you get confirmation that calling software (madVR ?) really sends required chroma placement signalling to DXVA ?

In both madVR and LAV decoder controls I do not see any settings for chroma placement signalling (auto/passthrow/manual or others).

flossy_cake

23rd October 2022, 17:25

[NVidia Official Advanced Driver Search]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

Thanks but what is the significance of advanced?

If your calling software do not provide correct chroma placement signalling to DXVA - it may be simply better defaults or better auto-detection in AMD/ATI driver and/or hardware.

Do you get confirmation that calling software (madVR ?) really sends required chroma placement signalling to DXVA ?

In both madVR and LAV decoder controls I do not see any settings for chroma placement signalling (auto/passthrow/manual or others).

I don't know if author Madshi is signalling chroma placement. I'd give him the benefit of the doubt though as his whole renderer is geared towards videophile levels of accuracy. I can safely assume it is something he would care a lot about & I doubt he would just ignore DXVA function params and think to himself "don't worry about it".

Although maybe it is LAV Video Decoder (ffmpeg) which is providing the incorrect chroma placement and MadVR is just passing that incorrect info on? But in that case AMD shouldn't get it right either.

I guess that tight weave threshold of TDeint is contributing to its slightly sharper output.

After further scrutinising and pixel peeping with DVD IT Crowd using frame advance and seeing which pixels are getting weaved, it seems TDeint is still noticeably superior to BWDIF when both are in the same full framerate mode where 2:2 motion doesn't get weaved but static unmoving parts of image does get weaved & the rest interpolated.

i.e BWDIF(field=-2) vs TDeint(mode=1, mtnmode=1, slow=2)

But, TDeint produces some junk interpolated pixels around the edges of raster so I have to zoom in 2px to make sure there is no underscan. But really the texture detail preservation on TDeint is a lot better on static shots -- the slightest bit of video noise or camera movement triggers BWDIF into interpolation so in practice I am very rarely actually achieving true 576p resolution with BWDIF.

TDeint does seem to use about double the amount of CPU though, but fmpeg says 170fps for 720x576i @ 15% CPU usage so that is plenty of headroom still.

DTL

23rd October 2022, 18:26

Correct metadata signalling from demuxer-decoder-renderer is expected only in prof level developed environment like microsoft windows and its multimedia extensions like DirectX or other. So may be try to play your content by DirectShow if possible and check the correct chroma decoding and RGB dematrix.
Example: Take standard prof authored DVD interlaced and try to playback using DirectShow. The microsoft MPEG2 decoder should provide correct chroma placement flags to renderer.
May be your content do not have metadata encoded into and decoder can not provide anything for unknown source. Only the author of content may be know what is the correct chroma placement and need to found way how to to put this to content or pass to decoding and playback environment by other ways.
So in good playback devices for pixel-peepers the manual control for chroma placement is expected to support playback from unknown sources with better result.

StainlessS

23rd October 2022, 20:15

but what is the significance of advanced?
Not Advanced:- https://www.nvidia.com/en-gb/geforce/drivers/

Advanced:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#

Advanced can also select "Windows Driver Type", ie Standard / DCH.
Just a bit better selection control [Advanced can also select Beta].

Advanced Driver Search, is NVidia's [not mine] description on that page.

EDIT: There are also more choices under Product Type, eg
NVS, Data Center/Tesla, GRID,
Perhaps additional diffs.

EDIT: + More OS selections, I'm not gonna look for more, you look if you like :)

flossy_cake

24th October 2022, 14:28

A = last
B = BlankClip(A, color=color_red)
TDeint(TryWeave=true, edeint=B)

Is it possible to manually implement something like the above but for BWDIF , in order to visually expose which pixels it weaves and which ones it interpolates?

BWDIF does actually have an edeint param but it does something else:

clip edeint =

Clip from which to take spatial predictions. This clip must be the same width, height, and colorspace as the input clip.
If using same rate output, this clip should have the same number of frames as the input. If using double rate output, this clip should have twice as many frames as the input.

http://avisynth.nl/index.php/BWDIF

I'm sure there's got to be some way to "diff" it with the original clip.

I'm asking because although I subjectively prefer the sharper look of TDeint, it does have a tendency to corrupt fine details, eg. text becomes a bit distorted. Only noticeable on test patterns though, but I'm still curious to see whether BWDIF is really so sensitive to motion that it will interpolating almost the whole time and only weaving under rare perfectly still conditions i.e test patterns or static computer generated overlays.

poisondeathray

24th October 2022, 15:06

Is it possible to manually implement something like the above but for BWDIF , in order to visually expose which pixels it weaves and which ones it interpolates?

BWDIF does actually have an edeint param but it does something else:

I'm sure there's got to be some way to "diff" it with the original clip.

I'm asking because although I subjectively prefer the sharper look of TDeint, it does have a tendency to corrupt fine details, eg. text becomes a bit distorted. Only noticeable on test patterns though, but I'm still curious to see whether BWDIF is really so sensitive to motion that it will interpolating almost the whole time and only weaving under rare perfectly still conditions i.e test patterns or static computer generated overlays.

subtract, or overlay with difference mode . You can use levels to amplify the differences

eg.

.
.
.
a = last
b = a.bwdif(some settings)

Subtract(a,b)

#Levels(127, 1, 129, 0, 255) # for 8bit
#Levels(511, 1, 513, 0, 1023) # for 10bit

If the distortions in text, fine patterns from tdeint (or bwdif) are due to the interpolation algorithm, you can specify a different deinterlacer or interpolation algorithm with edeint (for tdeint, or bwdif) . QTGMC is a commonly used one, or NNEDI3 if you want faster

StainlessS

24th October 2022, 16:58

eg.

.
.
.
a = last
b = a.bwdif(some settings)

Subtract(a,b)

#Levels(127, 1, 129, 0, 255) # for 8bit
#Levels(511, 1, 513, 0, 1023) # for 10bit

I think that the levels are not quite there, are centered around 128 instead of TV levels center ie 126, (16+235)/2.0=125.5 rounded to 126. Subtract centers on 126 whereas the MT_tools subtract thingy centers on 128.

So something like

.
.
.
a = last
b = a.bwdif(some settings)

Subtract(a,b)

#Levels(125, 1, 127, 0, 255) # for 8bit
#Levels(503, 1, 505, 0, 1023) # for 10bit : (126*4)-1=503 : (126*4)+1 = 505

EDIT: Also, if a is original and b is filtered, then maybe should use Subtract(b,a) rather than Subtract(a,b), so result will be above mid grey
if filtered is lighter than original, and below mid grey if darker than original (Subtract(a,b) will be opposite).

None of above tested.

flossy_cake

24th October 2022, 17:57

Thank you for all the help, I'm learning a lot here.

On another note...

There's a ChromaShift plugin, but for YV12 it's 2 pixel increments, or 4 if it's interlaced, or if you're really keen and know the exact shift you can use a resizer to compensate. To shift the chroma of a 1080p video 7.3 pixels to the left (it'd be -7.3 to shift it right).

A = last
MergeChroma(A, A.Spline36Resize(1920,1080, 7.3,0,1920,1080))

Regarding the numbers in bold, according to ChromaShiftSP plugin (http://avisynth.nl/images/ChromaShiftSP.avsi) the values 7.3 and 0 need to be added to them -- is this correct?

I've spent hours trying to understand how the resize crop params work but I can't get my head around whether it's shifting the chroma or if it's actually stretching the chroma out from a fixed point (and if so, which point -- center or a corner?).

edit: just realised I can set the offset to a high value and measure the pixels in photoshop. In this case it seem hello_hello's code is correct: good 50px offset (https://ibb.co/BCSjwwM), bad chromashiftSP code (https://ibb.co/fdM395p)

A separate problem I'm dealing with is how to crop n lines off the top and bottom, and then zoom in to hide the black bars while preserving aspect.

For a 720x576 16:9 video (which Avisynth sees as square pixels 720x576 with aspect 1.25:1) I've got this code for cropping 50 off the top and bottom:

Resize(Round(576*(16.0/9.0)), 576, 50*(720.0/576.0), 50, -50*(720.0/576.0), -50)

In other words, if I'm cropping 50 off the top and bottom, then I need to crop 1.25 times more pixels of the left and right in order to main aspect (I have no idea if this is right, it's just my thinking) and then finally stretch to 1024 wide to compensate for anamorphic pixels.

flossy_cake

24th October 2022, 19:13

subtract, or overlay with difference mode . You can use levels to amplify the differences

Hmm which one is correct:

Subtract(ChangeFPS(last,50),BWDIF(field=-2))
https://i.ibb.co/61NxCtQ/8.png

Subtract(ChangeFPS(last,50),BWDIF(field=-2))
Levels(127, 1, 129, 0, 255)
https://i.ibb.co/SxRnC72/9.png

clip: https://drive.google.com/file/d/1WfW3yXmGhIvUCiexQGYD18gSiXRe2bze/view?usp=sharing

edit: perhaps need a threshold so it wont amplify pixels that barely changed at all?

StainlessS

25th October 2022, 10:55

perhaps need a threshold so it wont amplify pixels that barely changed at all?
Maybe try

Th =16 # or whatever
center = 126 # TV else 128 PC levels
Levels(center-Th, 1, center+Th, 0, 255)

StainlessS

25th October 2022, 16:09

I think that the levels are not quite there,
No, they were right, @PDR, you could've pointed out that I was the one that was wrong :(
(Levels defaulted to Coring=True, so was correct).

Anyways, I've done this before I twigged that I was the wrong'un.

BlankClip(pixel_type="YV12")
#ConvertBits(10)

#

TV = true # Use True if Subtract TV levels.
Th8 = 16 # Threshold, 1 = Max AMP, > 1 reduce AMP.

###
bpc = Last.BitsPerComponent()
shift = bpc - 8
mul = BitLShift(1,shift)
center = (TV) ? 126 : 128 # 126 TV else 128 PC levels
center = center * mul # center at current bit depth
Th = Th8 * mul # Th at current bit depth
oMax = BitLShift(1,bpc)-1 # 255 @ 8bit, 1023 @ 10 bit
RT_DebugF("bpc=%d Shift=%d mul=%d Center=%d Th=%d oMax=%d",bpc,shift,mul,center,Th,oMax,Name="LEVELS: ") # Write to DebugView (google it)
Levels(center-Th, 1.0, center+Th, 0, oMax, coring = FALSE)

Sorry PDR :(

flossy_cake

26th October 2022, 19:26

poisondeathray

26th October 2022, 19:43

Should TFM() be capable of correctly deinterlacing the cheese slices (https://drive.google.com/file/d/1xdV5_me-pbafnPo6yXhaZKIhe8IP4Ipq/view?usp=sharing) clip?

Apparently (https://www.avsforum.com/threads/hd-1080i-test-pattern-to-determine-vector-adaptive-deinterlacing-others-icl-ticker.1157287/post-22862294) all it needs for perfect progressive reproduction is to weave frame A field 1 with frame B field 2, but I can't get TFM to do that (tried all the modes and setting different cthresh & MI values).

I suspect what's happening is it's just detecting all frames as combed.

I can confirm that MadVR can correctly deinterlace it with its "film" mode deinterlacing which I'm told is madshi's own custom CPU code for detecting cadences aka "field matching" like TFM.

Yes, false positive

When you have patterns such as thin horizontal lines, that situation is always going to be detected as false positive and be deinterlaced. You can disable post processing globally with TFM(pp=0) . Or you can use are overrides or exclusion bands (eg. moving text, lower thirds)

In real life, you're typically not going to encounter thin lines such as test patterns, and in real life, you're going to have to use overrides to get it perfect for non standard content

flossy_cake

26th October 2022, 20:44

Ok cool. I always thought that test pattern was kind of ridiculous.

Regarding TDeint though, do you reckon it would work better if it used per-block combing detection? i.e if 16x16 block is combed, then treat only that 16x16 block as combed. Currently it seems to think that means the whole frame should be treated as combed:

blockx:
Sets the x-axis size of the window used during combed frame detection. This has to do with the size of the area in which MI number of pixels are required to be detected as combed for a frame to be declared combed.
http://avisynth.nl/index.php/TDeint

The way I'm imagining it, a lower cthresh/MI could be used and false positives could be confined to that 16x16 block instead of writing off the whole frame.

flossy_cake

29th October 2022, 03:11

I can't seem to detect any difference between:

TDeint(tryWeave=true, full=true)
TDeint(tryWeave=true, full=false)

In both cases it seems to perform combed frame detection according to cthresh,MI,blockx,blocky etc., and returns the full frame if it wasn't detected as combed.

Is my understanding correct, or should there be some difference between the two?

flossy_cake

5th November 2022, 03:58

I've been getting into NTSC DVDs a bit lately, but was disappointed to find a few of them appear to be using "soft telecine" where the actual frames seem to be stored in the MPEG2 stream as 23.976p. This sounds great in theory as it wouldn't need any deinterlacing, but I'm finding a few of them have these split-second combing artefacts on scene changes. Annoyingly just enough to produce a visual annoyance that can't be ignored.

What's the best way to deal with this kind of content -- TFM? Decimate? Can it handle these split-second combing artefacts or are they too short to be detected? Keeping in mind this is "soft telecine" not "hard telecine" (the latter being 23.976p living inside a 29.97i stream using the 3:2 pattern -- this is not that).

Also does anyone know what is actually happening with these artefacts -- are they "baked into" the 23.976p image, or is the MPEG2 stream actually changing to 29.97i mid-stream (i.e variable framerate, which MediaInfo reports is true for all of these DVDs).

Of course I could just throw BWDIF at it, but then I'd be wasting half res on anything that moves.

And sadly DXVA deint chokes on "soft telecine" -- produces constant bob artefacts. I don't think it knows the stream is 23.976p and is trying to treat is as hard telecine 29.97i or something.

And MadVRs own "film" deint also cannot detect and repair these split-second combing artefacts either, so it looks like I'll need an Avisynth solution.

Emulgator

5th November 2022, 13:12

Use DGIndex and watch what pulldown results it throws: 100%film, 98,57%film, etc.
Inspect the .d2v index file with Editor.
If the content stems from film there shouldn't be any pulldown transitions.
If you find them these places got to be repaired and left as 23,976p.
Video (credits, VFX) on top of film: there are lots of suggestions, I would go dgmpgdec, QTGMC to 59,94p
If content is animation any valid MPEG-2 pulldown pattern could have been used to match intended animation flow:
The same, dgmpgdec, QTGMC to 59,94p.

I have still a Sponge Bob sample floating around, and it has been discussed here in doom9

flossy_cake

6th November 2022, 01:33

Here is a clip of soft telecine 24p containing 2 problematic scene cuts: https://drive.google.com/file/d/1dwa7gB3HHuSPXroA2ifm4LtLX0fSs2bM/view?usp=share_link

For some reason DirectShowSource won't open the file on my system, but FFmpegSource2 and LWLibavVideoSource will. Their parameters rffmode and repeat seem to affect whether they will output it natively as 24p or convert to 60i using the repeat flags stored in the stream. LAV Video Decoder seems to use repeat flags to convert it to 60p and doesn't seem to offer a choice.

edit: actually after more testing, MadVR's film mode deint seems to be handling those combed frame transitions perfectly. DXVA almost gets it right but interpolates those ones and jumps back a field for some reason. Not sure why I was having trouble with it before.

edit: it seems LWLibavVideoSource documentation is wrong: the repeat param seems to default to true or perhaps some auto setting, since not setting it results in repeat fields mode. Setting it to false actually causes the video to play back way too fast at 30fps.

A separate issue is that because Avisynth outputs square pixels I have to scale it to 720x540 but that offsets the field lines which makes it impossible to do MadVR or DXVA deint which happen after Avisynth.

flossy_cake

6th November 2022, 02:37

kedautinh12

6th November 2022, 03:55

Emulgator

6th November 2022, 19:18

How has the .mkv been obtained ?
Throwing it at VirtualDub2 gets repeated frames and the mentioned combs.
MPEG2Source sees FINISHED 95.69% FILM
Flagging borked or DVD borked ?
I would suggest to go back to the .vob and work from there.

StainlessS

6th November 2022, 20:02

go back to the .vob and work from there.
+1

If its DVD VOB, then better use DGIndex [EDIT Mpeg2Source(d2v] and TFM(d2v=d2v_Filename), DGSource dont work with d2v arg. [EDIT: or rather, TFM, dont work with d2v=dgi_Filename]
(you sometimes get mid frame edits (edits split on 2nd field) and Perverse Telecine where progressive fields split across frames.)

TFM on VOB will also announce presence of illegal field transitions with d2v arg. [throw error]

poisondeathray

6th November 2022, 21:17

So this seems to work perfectly for handling the problematic combed transitions:

LWLibavVideoSource(clip)
TFM()
TDecimate()
LanczosResize(720,540)

But as I feared TFM() is having issues with combed frame detection (note the aliasing on the table edges -- the sequence is 24p soft telecine and contains no combing artefacts)

<snip>

I'll have to play around with the thresholds to see if it can be improved, but my experience with TDeint seems to imply it's going to be difficult and/or need per-scene thresholding.

edit: PP=0 seems to help with that.

Yes, you just have to tweak the parameters for your source

Leaving PP=0 will leave combed frames (scene transitions, orphan fields - fields 220, 490 that have unique full content , but missing their "partner" field pair) , because this is not a 100% soft pulldown source (decimated frame numbers 88, 196 will be combed -ie. the frame before the next scene)

You can use display=true to debug MI , cthresh values. eg. The grid pattern of yellow laundry basket might elicit false positive comb detection because it "looks" like combing. (or any scene that looks like combing, maybe some types of horizontal venetian window blinds).

e.g you can see MI values going as high as 166 in the laundry scene. But the true combed frames have mic of 246 and 228. So if you set mi>166 but <228 eg. mi=170, you should catch everything in this clip (you'd have to check the rest of the DVD to see if those settings are ok), and the orphaned fields will be deinterlaced properly, while not deinterlacing the progressive content frames

DGSource("soft telecine.dgi")
TFM(mi=170, clip2=QTGMC().SelectEven(), display=true)
TDecimate()

hello_hello

7th November 2022, 02:16

But as I feared TFM() is having issues with combed frame detection (note the aliasing on the table edges -- the sequence is 24p soft telecine and contains no combing artefacts)

That doesn't quite make sense because as you said, if it's soft telecine there should be no combing to detect. That looks like some sort of production mess.

It's been mentioned already but after remuxing the MKV as a TS file and opening it with DGIndex:

Frame Rate: 29.970030 fps
Video Type: Film 95.90%
Frame Type: Progressive
Coding Type: B
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Field Order:
Coded Number: 256
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0

According to DGIndex (and MediaInfo) it's been encoded as progressive, but given the hard telecine, I assume it should have been encoded as interlaced?

Even without using QTGMC to de-interlace, this fixes 90% of it, but it creates a blended frame on at least one scene change (I only checked one).

TFM(pp=5)
TDecimate()

flossy_cake

7th November 2022, 05:01

That doesn't quite make sense because as you said, if it's soft telecine there should be no combing to detect. That looks like some sort of production mess.

Indeed there shouldn't be, but TFM incorrectly detects there are because of the stippled patterns on various objects in the scene. Disabling TFM and stepping through each frame at a time shows no combing artefacts on that motion sequence. But what I learned recently was that this is only happening because the source filter is disobeying the repeat field flags -- if they are obeyed then I see the expect pattern of 2 combed frames followed by 3 progressive frames.

How has the .mkv been obtained ?

I bought the DVD discs the other day and used MakeMKV (https://www.videohelp.com/software/MakeMKV) to remux it to mkv. So there hasn't been any transcoding (I expect it to be just the original MPEG2 stream living inside mkv file) but I'm not sure if the mkv container uses timecodes as well which could be interfering with it somehow. The snippet was then extracted using XMediaRecode in "copy" mode -- again avoiding any transcoding, but still possible that it could be altering metadata or timecodes in the original mkv file. In theory it shouldn't.

In any case that clip is definitely soft telecine 24p, not 30i or 30p. The earlier seasons of that same show seem to be using hard telecine.

StainlessS

7th November 2022, 05:29

DGIndex Mpeg2Source(d2v) on a DVD VOB d2v would do it better, gives TFM more to work with.

flossy_cake

7th November 2022, 08:46

DGIndex on a DVD VOB d2v would do it better, gives TFM more to work with.

Sounds complicated and difficult :scared:

Isn't it interesting though how human vision can tell immediately if there are combed pixels in the frame, but coming up with an algorithm for it is very difficult. Just thinking about it gives me a headache, I mean how are we going to tell if the pixels are real image data or combing artefacts? The difference in colour between neighbouring pixels could be virtually anything and that could still be a real texture in the image.

It seems Tritical and D.G have created their own algorithms for dealing with it (metric=0/1) but both of them still seem to need per-scene or per-video thresholding.

The only suggestion I could come up with was to perhaps apply the combing detection on a per-block basis, but I'm guessing Tritical and D.G had thought of that already.

NVidia's DXVA deinterlacing has combing detection (controlled by the "use inverse telecine" checkbox in NVCP) and it seems to avoid the issue by playing it safe with a very low threshold so it needs only a small amount of combing before it reverts to interpolation. Similar thing with my PVR's deinterlacer (chipset HiSilicon 3790mv200).

Still, TFM seems to do a pretty good job with PP=0 -- I'd rather have the rare 1-2 frame combing artefact on scene splices than tens of frames dropping to 240p.

StainlessS

7th November 2022, 09:26

Sounds complicated and difficult
Really.

d2v="...Whatever.d2v"
Mpeg2Source(d2v) # OOoops, was DGIndex(d2v). I use templates, so never have to type it in myself.
TFM(d2v=d2v, ... additional args you use)

Allows TFM to see the source d2v and detect illegal field transitions etc, instead of hoping that the source filter (eg LWLibavVideoSource or whatever) did everything correctly.
(allows it to see how the source was actually encoded, and DGIndex settings eg "Honour Pulldown Flags" etc)

TFM() on an decoded clip, cannot see any illegal field transitions or exactly how it is encoded, eg soft telecine, only has access to the decoded video provided by the source filter.
DGSource file type dgi, cannot be used by TFM, never implemented.

EDIT:
DGIndex settings eg "Honour Pulldown Flags" etc
Well, this lot from d2v

Stream_Type=1
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=4:3
Picture_Size=720x576
Field_Operation=0 Honour/Ignore Pulldown Flags/Forced Film
Frame_Rate=25000 (25/1)
Location=0,0,3,4757c

900 5 0 2048 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 319488 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 710656 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1075200 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1474560 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1847296 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2228224 0 1 1 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2

# ...

900 5 3 598341632 0 1 8 92 b2 b2 a2 a2
900 5 3 598458368 0 2 1 d2 ff

FINISHED 100.00% VIDEO

If TFM(d2v=d2v) detects illegal field transition, it will create a OriginalName_fixed.d2v (or something like that) file, and throw error telling you to change to the fixed d2v.
TFM() without d2v cannot tell illegal field transitions, nor create fixed d2v.

d2v for TFM() just makes for less guesswork by TFM.

EDIT:
I'm not sure if DGIndex MPeg2Source(d2v).Tfm(d2v=d2v)
has any advantage over eg SomeOtherVideoSource(d2v).Tfm(d2v=d2v)

But both gotta be better than DGSource(dgi).Tfm()
or SomeOtherVideoSource(dgi [B]OR d2v).Tfm()

EDIT:
I believe that DGIndex Mpeg2Source() is 100% frame accurate, SomeOtherVideoSource() may tend to vary.

hello_hello

7th November 2022, 10:10

Indeed there shouldn't be, but TFM incorrectly detects there are because of the stippled patterns on various objects in the scene. Disabling TFM and stepping through each frame at a time shows no combing artefacts on that motion sequence. But what I learned recently was that this is only happening because the source filter is disobeying the repeat field flags -- if they are obeyed then I see the expect pattern of 2 combed frames followed by 3 progressive frames.

You'll probably also be decoding at the wrong frame rate. If you're using ffms2 or lasmash and they're not obeying the repeat flags, they output the average frame rate. I thought one of them was changed to make obeying repeat flags the default recently. I could be wrong. I'm using the old lsmash that plays with XP and possibly not the latest ffms2.

Decoding with lsmash or ffms2 it looks progressive, except for around the scene changes, and Info() says:

LWLibavVideoSource("D:\soft telecine.lwi", repeat=true)
29.97fps, 317 frames, 10.577 sec

LWLibavVideoSource("D:\soft telecine.lwi")
29.97fps, 256 frames, 8.541 sec

FFVideoSource("E:\soft telecine.mkv", cachefile="D:\soft telecine.ffindex", threads=1, RFFMode=1)
29.97fps, 318 frames, 10.610 sec

FFVideoSource("E:\soft telecine.mkv", cachefile="D:\soft telecine.ffindex", threads=1)
24.3789fps, 256 frames, 10.5 sec

The frame rate for the second ffms2 example is usually the indicator there's repeat flags being ignored, because there's hard telecined or video sections too, making the average frame rate non standard. It'll also mess with the audio sync. I don't know why lsmash didn't output the same frame rate.

I don't know why the repeat flags are resulting in such horrible telecined fields, or why
Field Repeats: 0
from the log file I posted earlier appears to be wrong.

FYI, you can split MKVs into sections with MKVToolNixGUI.
Even if I rip a DVD with MakeMKV (which I rarely do) I always remux the MKV as a TS file with TSMuxer so I can index it with the old DGIndex as it obeys the repeat flags by default. I never use "force film" mode.

Edit: I tried showing the d2v (index) file to TFM after indexing with DGIndex (decoding with DGDecode) but it didn't seem to help.

DGDecode_mpeg2source("D:\soft telecine.d2v")
TFM(d2v="D:\soft telecine.d2v")

flossy_cake

7th November 2022, 11:58

I don't know why the repeat flags are resulting in such horrible telecined fields, or why

I suspect it's where the video editing equipment back in the 90's/00's didn't make sure to maintain field order when the next scene was spliced in. It just spliced it on whatever field happened to be the last at that point when it should have gone 1 more to make sure the next scene started at top field or whatever the order was. It's so annoying cause it damages the video in a way that makes it really difficult to undo. If previewed on interlaced CRT the viewer probably wouldn't be able to tell anything was wrong as it just scans field after field anyway kind of like how if simple bob deinterlacing was used that would also avoid it.

The back of the DVD case says "Every possible effort has been made to produce the highest quality DVD release. Due to the quality of some of the original elements, some visual imperfections may be experienced". Maybe this is what they are referring to but then again maybe they're just covering themselves against refunds.

edit: actually now that I re-read your comment, I think you are referring to why the repeat flags don't match whatever muckup the 90's scene splicer did. In other words, if splicer cut the end of the scene 1 field too early then the repeat flag should reflect that. The answer is of course: I don't know :)

Emulgator

7th November 2022, 15:24

I wanted to say MPEG2Source of course, just correcting that.
Yes, framecuts go right through the wrong place, leaving an orphaned field.
I remember CCE accepting a .i32 pulldown file to avoid that.
Means extra work that might have been neglected.

flossy_cake

11th November 2022, 15:54

Is it possible to have TFM or TDeint set frame property _Combed like eg.

hints = TFM(hint=true, PP=1)
ConditionalFilter(last, deint, last, """propGetAny(hints, "_Combed")""", "=", "true", show=true)

Trying to make it output clip "deint" when _Combed=true

edit: I should probably use

IsCombedTIVTC(clip, int "cthresh", int "MI", bool "chroma", int "blockx", int "blocky")
but it would be nice to know how the hints work as well.

flossy_cake

12th November 2022, 10:19

Kind of stuck with the conditional filters. Trying to evaluate luma diff since prev frame in a 25fps clip and then based on that value conditionally select one of two 50fps output clips.

Problem is this doesn't seem possible due to the way Avisynth evaluates things in real time -- the evaluation of the 25fps clip slows down the 50fps clip to half speed as the evaluation is always performed in the same "code block".

I can kind of get around it by doubling the fps of the 25fps stream but then this breaks things like luma comparisons with the previous frame since it's comparing it to a repeat of itself so it often evaluates to 0 change in luma when it shouldn't. Then tried to work around this with some bodge code but can't get it to do what I want. It seems the only way to get what I want is to perform the evaluations on the original 25fps clip.

LWLibavVideoSource("576i25 mixed cadences 1-1 and 2-2.mkv")
orig25 = last
orig50 = ChangeFPS(orig25, 50)
bwdif50 = ChangeFPS(BWDIF(last, field=-2, thr=3), 50)

ConditionalFilter(orig50, bwdif50, orig50,
\"IsCombedTIVTC(cthresh=9, MI=64) || (YDifferenceFromPrevious() < 2.0)",
\ "=", "true", show=true)

I need to swap the blue orig50 for orig25 to get the correct evaluations, but that causes the playback of the conditionally selected clip (bwdif50/orig50) to become slow. Seems the Avisynth thread that performs the conditional evaluation is somehow tied to the timing of the input clip which it's evaluating.

Tried using FrameEvaluate on orig25 prior to the conditional like this:

FrameEvaluate(orig25, "global isCombed = IsCombedTIVTC(cthresh=9, MI=64)")
FrameEvaluate(orig25, "global yDiff = YDifferenceFromPrevious())

but couldn't access the vars isCombed and yDiff inside the conditional.

edit: in case it's not obvious what I'm trying to do here. Basically I want to use Tritical's IsCombedTIVTC() with one modification: if IsCombedTIVTC says the frame is NOT combed, then I will only obey that if the luma diff since the last frame was suitably small. This is my attempt at trying to mitigate combing artefacts from scenes where there is just a tiny bit of motion and IsCombedTIVTC is erroneously reporting "not combed".

hello_hello

12th November 2022, 11:47

Edit: I haven't read your latest post yet. Got to visit the real world for a bit. Hopefully someone else will come along in the mean time.

TFM's hints have been around for a long time (I can't remember how they work exactly). They're not the same thing as frame properties which are relatively new. Not many plugins support them yet (nor do Avisynth's internal filters).
I can't imagine it could work the way you're doing it.

TIVTC has ShowCombedTIVTC & IsCombedTIVTC functions you can use to check for combed frames. The help file says they use TFM's comb detection.

Here's some functions you may want to play with. They might give you some ideas. I put them together for a discussion in a thread a long time ago, but I'm hopeless with conditional filters too. I remember a lot of frustrated messing around to get them to work and I've never used them myself so I only vaguely remember them. The script has to exist. That is, they probably won't work in AvsPmod until the script is saved.

FindCombing1() writes a log file (run an analysis pass) with the frame number of any combed frame and a running count of combed frames.

12 - Combing 1
13 - Combing 2
14 - Combing 3
15 - Combing 4
16 - Combing 5
17 - Combing 6
18 - Combing 7
19 - Combing 8

FindCombing2() as three MI thresholds and writes a log file of the threshold levels with a running count for each.

91 - Thresh Hi 75
92 - Thresh Hi 76
93 - Thresh Low 1
94 - Thresh Low 2
95 - Thresh Hi 77
96 - Thresh Hi 78
97 - Thresh Hi 79
98 - Thresh Hi 80
99 - Thresh Hi 81
100 - Thresh Med 1
101 - Thresh Low 3
102 - Thresh Med 2

FindCombingRed() - I'm not 100% sure. It was a while ago.
It looks like it creates a B/W version of the clip, runs TFM without de-interlacing followed by TDecimate, makes the combed pixels red, runs IsCombedTIVTC on the B/W clip and also checks the second clip for the amount of red, or something....
It displays the clip with the combed pixels red and the log file looks like this:

76 - Combing 62 - 12.74
77 - Combing 63 - 112.00
78 - Combing 64 - 112.00
79 - Combing 65 - 112.00
80 - Combing 66 - 14.88
82 - Combing 67 - 13.51
83 - Combing 68 - 112.00

I think the idea of that one was to field match and decimate without repairing combing and then checking for it. Or something....

# -------------------------------------------------------------------------------
# FindCombing1
# -------------------------------------------------------------------------------

function FindCombing1(clip Vid, bool "Append", string "FileName", bool "All") {

Append = default(Append, false)
FileName = default(FileName, "")
All = default(All, false)

global Count = 0
ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
Dir = (StrLen(ScriptDir()) < 2) ? "D:" : ""
File = ((FileName != "") ? FileName : \
Dir + ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName)) + "_Combing.txt"

Vid = FrameEvaluate(Vid, """

A = IsCombedTIVTC()
Count = A ? Count + 1 : Count
TheCombing = A ? string(Count, " - Combing % 6.0f") : ""

""")

Vid = !All ? WriteFileIf(Vid, File, "A", "current_frame", "TheCombing", Append=Append) : \
WriteFile(Vid, File, "current_frame", "TheCombing", Append=Append)

return Vid }

# -------------------------------------------------------------------------------
# FindCombing2
# -------------------------------------------------------------------------------

function FindCombing2(clip Vid, bool "Append", string "FileName", bool "All") {

Append = default(Append, false)
FileName = default(FileName, "")
All = default(All, false)

ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
Dir = (StrLen(ScriptDir()) < 2) ? "D:" : ""
File = ((FileName != "") ? FileName : \
Dir + ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName)) + "_Combing.txt"

global FCA = 0
global FCB = 0
global FCC = 0
Vid=Vid

Vid = FrameEvaluate(Vid, """

A = IsCombedTIVTC(MI=30)
B = IsCombedTIVTC(MI=80)
C = IsCombedTIVTC(MI=130)

FCA = A && !B && !C ? FCA + 1 : FCA
FCB = B && !C ? FCB + 1 : FCB
FCC = C ? FCC + 1 : FCC

TheCombing = " - " + \
(A && !B && !C ? string(FCA, "Thresh Low % 6.0f") : \
B && !C ? string(FCB, "Thresh Med % 6.0f") : \
C ? string(FCC, "Thresh Hi % 6.0f") : "")

""")

Vid = !All ? WriteFileIf(Vid, File, "A || B || C", "current_frame", "TheCombing", Append=Append) : \
WriteFile(Vid, File, "current_frame", "TheCombing", Append=Append)

return Vid }

# -------------------------------------------------------------------------------
# FindCombingRed
# -------------------------------------------------------------------------------

function FindCombingRed(clip Vid, bool "Append", string "FileName", bool "All", bool "Write") {

Append = default(Append, false)
FileName = default(FileName, "")
All = default(All, false)
Write = default(Write, true)

ScriptName = ScriptFile()
EndLength = FindStr(LCase(ScriptName), ".avs") - 1
Dir = (StrLen(ScriptDir()) < 2) ? "D:" : ""
File = ((FileName != "") ? FileName : \
Dir + ((EndLength > 0) ? LeftStr(ScriptName, EndLength) : ScriptName)) + "_Combing.txt"

global Count = 0
Vid = Vid.GreyScale()
global Vid1 = Vid.TFM(pp=1).TDecimate()
CombTest = BlankClip(Vid, Color=color_red)
Vid2 = Vid.TFM(Clip2=CombTest).TDecimate()
global Everything = All

Out = FrameEvaluate(Vid2, """

IsComb = IsCombedTIVTC(Vid1)
IsRed = (AverageChromaV() > 128)
IsEnd = (FrameCount() == (current_frame + 1))
Count = IsComb ? Count + 1 : Count

WriteThis = \
(!IsComb && !IsRed && !Everything ? "" : string(current_frame)) + \
(!IsComb && !IsRed ? "" : \
IsComb && IsRed ? (string(Count, " - Combing %.0f") + string(AverageChromaV()-128, " - %.2f")) : \
IsComb ? string(Count, " - Combing %.0f") : \
(" - No Combing" + string(AverageChromaV()-128, " - %.2f"))) + \
(!IsEnd ? "" : \
(!IsComb && !IsRed && !Everything ? "" : chr(10)) + string(FrameCount(), "%.0f - Frame Count"))

""")

Out = !Write ? Vid2 : \
!All ? WriteFileIf(Out, File, "IsComb || IsRed || IsEnd", "WriteThis", Append=Append) : \
WriteFile(Out, File, "WriteThis", Append=Append)

return Out }

flossy_cake

12th November 2022, 13:34

Thanks hello_hello, I'll get stuck in again tomorrow as I already spent the day working on this without luck.

The Avisynth wiki (http://avisynth.nl/index.php/FrameEvaluate#Advanced_conditional_filtering:_part_I) gives this code example which seems to indicate that I should be able to use FrameEvaluate to perform the IsCombedTIVTC test on the 25fps clip and then reference the results of it from elsewhere in the script:

function g(clip c)
{
global w = c
c2 = ScriptClip(c, "subtitle(t)")
c3 = FrameEvaluate(c2, "me()")
c4 = FrameEvaluate(c3, "global text = YDifferenceFromPrevious(w)")
return c4
}

function me()
{
global t = String(text)
}

But I had no such luck, every time I try to reference it I get the error "I don't know what <varname> means".

On another note...

You can disable post processing globally with TFM(pp=0)

Somehow I missed this and indeed TFM can weave cheese slices silly weird cadence just fine with pp=0. In fact pp=0 seems to do well on actual content as well, even dodgy stuff like my Caroline in the City NTSC DVDs which has all these weird 1-field edits on scene splices, while MadVR's [deint=film] chokes badly with lots of stutter (tfm's mode=0 helps with that too, and then tdecimate's hybrid=1 to blend over single-field splices:

TFM(mode=0, PP=1)
TDecimate(mode=1, hybrid=1, hint=true, cycle=5, cycleR=1,
\ viddetect=2, vidthresh=2.2, display=false)

So in fact I am very grateful and pleased that we have TFM as it's doing a significantly better job than Nvidia's DXVA and MadVR's film mode!

So a big :thanks: to Tritical

StainlessS

12th November 2022, 16:38

That Advanced Scripting on Wiki is way headbanging stuff, and I personally think the necessity is questionable.
Everything that can be done in the weird back-to-front and upside down order can more easily be done with scriptclip.
(and in sane order)

but anyways, for anybody wants to play with this [equivalent of flossy prev given script from Wiki]

#v = AviSource("E:\Temp\Test3\atomic_kitten.avi").ConvertToYV12
KCLIP=BlankClip(Pixel_Type="YV12",color=$000000)
WCLIP=KCLIP.BlankClip(color=$FFFFFF)
MCLIP=KCLIP.BlankClip(color=$808080)

V = Interleave(KCLIP,WCLIP,MCLIP)

function g(clip c)
{
global w = c
c2 = ScriptClip(c, """RT_DebugF("%d] Subtitle(t)='%s'",current_frame,t) subtitle(t)""")
c3 = FrameEvaluate(c2, """RT_DebugF("%d] Calling me()",current_frame) me()""")
c4 = FrameEvaluate(c3, """RT_debugF("\n%d] Setting Global text with YDifferenceFromPrevious(w)",current_frame) global text = YDifferenceFromPrevious(w)""")
return c4
}

function me()
{
# RT_DebugF("%d] me(): Setting Global t to %s",current_frame,string(text)) # DONT WORK. current_frame not available here
RT_DebugF("me(): Setting Global t to %s",string(text))
global t = String(text)
}

g(v)

shows this

00004140 15:29:36.029 RT_DebugF:
00004141 15:29:36.029 RT_DebugF: 0] Setting Global text with YDifferenceFromPrevious(w)
00004142 15:29:36.029 RT_DebugF: 0] Calling me()
00004143 15:29:36.029 RT_DebugF: me(): Setting Global t to 0.000000
00004144 15:29:36.029 RT_DebugF: 0] Subtitle(t)='0.000000'
00004145 15:29:37.761 RT_DebugF:
00004146 15:29:37.761 RT_DebugF: 1] Setting Global text with YDifferenceFromPrevious(w)
00004147 15:29:37.761 RT_DebugF: 1] Calling me()
00004148 15:29:37.777 RT_DebugF: me(): Setting Global t to 219.000000
00004149 15:29:37.777 RT_DebugF: 1] Subtitle(t)='219.000000'
00004150 15:29:38.662 RT_DebugF:
00004151 15:29:38.662 RT_DebugF: 2] Setting Global text with YDifferenceFromPrevious(w)
00004152 15:29:38.662 RT_DebugF: 2] Calling me()
00004153 15:29:38.662 RT_DebugF: me(): Setting Global t to 109.000000
00004154 15:29:38.662 RT_DebugF: 2] Subtitle(t)='109.000000'
00004155 15:29:39.548 RT_DebugF:
00004156 15:29:39.548 RT_DebugF: 3] Setting Global text with YDifferenceFromPrevious(w)
00004157 15:29:39.548 RT_DebugF: 3] Calling me()
00004158 15:29:39.548 RT_DebugF: me(): Setting Global t to 110.000000
00004159 15:29:39.548 RT_DebugF: 3] Subtitle(t)='110.000000'
00004160 15:29:41.511 RT_DebugF:
00004161 15:29:41.511 RT_DebugF: 4] Setting Global text with YDifferenceFromPrevious(w)
00004162 15:29:41.511 RT_DebugF: 4] Calling me()
00004163 15:29:41.511 RT_DebugF: me(): Setting Global t to 219.000000
00004164 15:29:41.511 RT_DebugF: 4] Subtitle(t)='219.000000'

Current_Frame is not available in me() func, but can use this and supply current_frame as arg to new me2() func

#v = AviSource("E:\Temp\Test3\atomic_kitten.avi").ConvertToYV12
KCLIP=BlankClip(Pixel_Type="YV12",color=$000000)
WCLIP=KCLIP.BlankClip(color=$FFFFFF)
MCLIP=KCLIP.BlankClip(color=$808080)

V = Interleave(KCLIP,WCLIP,MCLIP)

function g(clip c)
{
global w = c
c2 = ScriptClip(c, """RT_DebugF("%d] Subtitle(t)='%s'",current_frame,t) subtitle(t)""")
c3 = FrameEvaluate(c2, """RT_DebugF("%d] Calling me2()",current_frame) me2(current_frame)""")
c4 = FrameEvaluate(c3, """RT_debugF("\n%d] Setting Global text with YDifferenceFromPrevious(w)",current_frame) global text = YDifferenceFromPrevious(w)""")
return c4
}

function me2(int n)
{
# current_frame = n # Cheat if current_frame required for something
RT_DebugF("%d] me2(%d): Setting Global t to %s",n,n,string(text)) # current_frame provided as arg n
global t = String(text)
}

g(v)

result

00000246 15:43:25.380 RT_DebugF:
00000247 15:43:25.380 RT_DebugF: 0] Setting Global text with YDifferenceFromPrevious(w)
00000248 15:43:25.380 RT_DebugF: 0] Calling me2()
00000249 15:43:25.380 RT_DebugF: 0] me2(0): Setting Global t to 0.000000
00000250 15:43:25.380 RT_DebugF: 0] Subtitle(t)='0.000000'
00000251 15:43:27.315 RT_DebugF:
00000252 15:43:27.315 RT_DebugF: 1] Setting Global text with YDifferenceFromPrevious(w)
00000253 15:43:27.315 RT_DebugF: 1] Calling me2()
00000254 15:43:27.315 RT_DebugF: 1] me2(1): Setting Global t to 219.000000
00000255 15:43:27.315 RT_DebugF: 1] Subtitle(t)='219.000000'
00000256 15:43:28.523 RT_DebugF:
00000257 15:43:28.523 RT_DebugF: 2] Setting Global text with YDifferenceFromPrevious(w)
00000258 15:43:28.523 RT_DebugF: 2] Calling me2()
00000259 15:43:28.523 RT_DebugF: 2] me2(2): Setting Global t to 109.000000
00000260 15:43:28.523 RT_DebugF: 2] Subtitle(t)='109.000000'
00000261 15:43:29.360 RT_DebugF:
00000262 15:43:29.360 RT_DebugF: 3] Setting Global text with YDifferenceFromPrevious(w)
00000263 15:43:29.360 RT_DebugF: 3] Calling me2()
00000264 15:43:29.360 RT_DebugF: 3] me2(3): Setting Global t to 110.000000
00000265 15:43:29.360 RT_DebugF: 3] Subtitle(t)='110.000000'
00000266 15:43:30.346 RT_DebugF:
00000267 15:43:30.346 RT_DebugF: 4] Setting Global text with YDifferenceFromPrevious(w)
00000268 15:43:30.346 RT_DebugF: 4] Calling me2()
00000269 15:43:30.346 RT_DebugF: 4] me2(4): Setting Global t to 219.000000
00000270 15:43:30.346 RT_DebugF: 4] Subtitle(t)='219.000000'
00000271 15:43:31.295 RT_DebugF:
00000272 15:43:31.295 RT_DebugF: 5] Setting Global text with YDifferenceFromPrevious(w)
00000273 15:43:31.295 RT_DebugF: 5] Calling me2()
00000274 15:43:31.295 RT_DebugF: 5] me2(5): Setting Global t to 109.000000
00000275 15:43:31.295 RT_DebugF: 5] Subtitle(t)='109.000000'

EDIT: I guess that you could Ultra Cheat and use

Function me3(int current_frame) { ... }

But I had no such luck, every time I try to reference it I get the error "I don't know what <varname> means".
You did not post what it was that you were trying to do, but whatever it was, it could only be used within runtime environment eg ScriptClip.
(and maybe only with After_Frame=true)

ScriptClip(clip clip, string filter [, bool show, bool after_frame, AVS+ bool local]
AVS+ ScriptClip(clip clip, function func [, bool show, bool after_frame, bool local] )

If after_frame=true, the script should be evaluated after the frame has been fetched from the filters above. Default is false.

ScriptClip on Wiki:- http://avisynth.nl/index.php/ConditionalFilter#ScriptClip

Note,

SSS """
# ...
Y = AverageLuma() # After any kind of fetching/sampling of current_frame frame in ScriptClip,
# code following will act as if After_frame=True
# ie, all upstream filters would have been called to provide the frame for AverageLuma()
# ...
"""
ScriptClip(SSS,After_Frame=FALSE) # FALSE is default

If using eg Scriptclip(...,After_frame=False), and some FrameEvaluate() style function is supposed to set a global var,
on FIRST FRAME, that global var may not have been set EVER unless upstream filters have been processed ie FrameEvaluate() not yet called,
and on subsequent frames, the global var set by FrameEvaluate would be as when set on the FrameEvaluate of previous frame.
So may need the After_frame=true thingy.
(if that makes any sense)

flossy_cake

13th November 2022, 10:31

Thanks, got it working with ScriptClip and after_frame=true.

I still need to keep the input and output clips at the same frame rate (in this case 50fps since bwdif will be outputting 50fps) otherwise I encountered other sync issues, but managed to work around it by making the luma check ignored if the diff is < 0.1, i.e if it was a duplicate frame, i.e 25fps. But it still seems to need denoising otherwise a static shot can have luma diff of 0.3 ish.

edit: neither of those ended up being reliable solutions. Should be able to workaround it tho with YDifferenceToNext(-2) which should always look at the real previous frame instead of the duplicate. Actually I'm impressed with what is possible with these realtime functions. It's giving me an explosion of ideas and possibilities like detecting 4 combed frames in a row could be used to infer 1:1 cadence and then if that was untrue it may even be possible to dynamically switch to TFM(). The problem is with handling of edge cases. So many edge cases it seems :scared:

flossy_cake

14th November 2022, 09:23

Presume this is some kind of diff overflow bug in FieldDiff(),

#WhateverSource(...)
OPT=4 # (default) Auto
#OPT=0 # Use C routines
FieldDiff(debug=true,display=true,opt=OPT)
return last

Similar to both display and DebugView, thoughout video clip.

OPT=4 (Default)

00007315 3.68521953 FieldDiff: Frame = 14233 Diff = -207589436161 (sad)

Were you able to resolve this?

I'm asking as I need to use more metrics as I'm finding that IsCombedTIVTC still results in a lot of false negatives compared to the one used by TDeint, and I can't compensate with YUV diffing as there are still edge cases, so I'm looking at using CFieldDiff as well to somehow mitigate that but...yeah :rolleyes:

Maybe it's possible to workaround by subtracting/multiplying/bitshifting it by something and still get a meaningful value out of it? What is the range of the value supposed to be?

StainlessS

14th November 2022, 11:23

Were you able to resolve this?
Nope.

There is this lot for 8 bit only.

****************************************************
********** RUNTIME CLIP COMPARISON FUNCTIONS ********
*****************************************************

The compiletime/runtime clip functions share some common characteristics.
The 'n' and (where used) 'n2' args are the optional frame numbers and default to 'current_frame' if not specified.
The x,y,w,h, coords specify the source rectangle under scrutiny and are specified as for Crop(), the default 0,0,0,0 is full frame.
If 'interlaced' is true (sometimes use Altscan arg name instead), then every other line is ommited from the scan, so if eg x=0,y=1, then
scanlines 1,3,5,7 etc are scanned, if eg x=0,y=4 then scanlines 4,6,8,10 etc are scanned. The 'h' coord specifies the full height scan ie
same whether interlaced is true or false, although it will not matter if the 'h' coord is specified as eg odd or even, internally the
height 'h' is reduced by 1 when interlaced=true and 'h' is even.
Some of the functions have 'x2' and 'y2' args for a second frame (which could be the same frame).
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.
v2.0, Where two clip comparison, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to
0 which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions
as c.

RT_YDifference(clip c,int "n"=current_frame,int "delta"=1,int "x"=0,int "y"=0,int "w"=0,int "h"=0,int "x2"=x,int "y2"=y,
bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600?3:2))
Returns FLOAT value luma difference (0.0 -> 255.0) between frame n area x,y,w,h, and frame (n+delta) area x2,y2,w,h.
Note, by default it will be equivalent to YDifferenceToNext as delta defaults to 1 and x,y,w,h defaults full frame.
BEWARE, x2 and y2 default to x and y.

Eg, RT_YDifference(clip,delta=0,y2=1,interlaced=true)
Would difference the even and odd lines of the same frame,

***
***
***

RT_LumaDifference(clip c,clip c2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,
int "n2"=current_frame,int "delta2"=0,int "x2"=x,int "y2"=y,bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600?3:2))
Returns FLOAT value luma difference (0.0 -> 255.0) between clip c frame (n+delta) area x,y,w,h, and clip c2 frame (n2+delta2) area x2,y2,w,h.
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

***
***
***

RT_LumaCorrelation(clip c,clip c2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,int "n2"=current_frame,
int "delta2"=0,int "x2"=x,int "y2"=y,bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600||clip2.Width>1100||clip2.Height>600?3:2))
Returns FLOAT value luma correlation (-1.0 -> 1.0) between clip c frame (n+delta) area x,y,w,h, and clip c2 frame (n2+delta2) area x2,y2,w,h.
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

Pearson's Sample Correlation Coefficient.
http://en.wikipedia.org/wiki/Correlation_and_dependence
http://en.wikipedia.org/wiki/Pearson_product-moment_correlation_coefficient
Uses equivalent routine to the JMac698's JCorr plugin here:
http://forum.doom9.org/showthread.php?t=165386
and here:
http://forum.doom9.org/showthread.php?p=1495098#post1495098

***
***
***

RT_LumaPixelsDifferent(clip c,clip c2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0, \
int "n2"=current_frame,int "delta2"=0,int "x2"=x,int"y2"=y,bool "interlaced"=false, \
int "matrix"=(Width>1100||Height>600?3:2),int "Thresh"=0)

Compares clip c frame (n+delta) at x,y,w,h, and clip c2 frame (n2+delta2) at x2,y2,w,h, and returns amount of pixels
whose pixel luma difference is greater than Thresh (RGB converted to Luma-Y using Matrix).
Matrix 0=Rec601, 1=Rec709, 2=PC601, 3=PC709.
If Interlaced=True, then skips every other raster line, eg process only y, y+2, y+4 etc.
Thresh Default 0, returns number of pixels that are not exactly the same.
Return value is in range 0.0 (meaning none) to 255.0 meaning 100% of pixels.
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

***
***
***

RT_LumaPixelsDifferentCount(clip c,clip c2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0, \
int "n2"=current_frame,int "delta2"=0,int "x2"=x,int"y2"=y,bool "interlaced"=false, \
int "matrix"=(Width>1100||Height>600?3:2),int "Thresh"=0)

Compares clip c frame (n+delta) at x,y,w,h, and clip c2 frame (n2+delta2) at x2,y2,w,h, and returns number of pixels
whose pixel luma difference is greater than Thresh (RGB converted to Luma-Y using Matrix).
Matrix 0=Rec601, 1=Rec709, 2=PC601, 3=PC709.
If Interlaced=True, then skips every other raster line, eg process only y, y+2, y+4 etc.
Thresh Default 0, returns number of pixels that are not exactly the same.
Note, returns the number of pixels whose difference is greater than Thresh, so ranges 0 -> (Width*Height).
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

***
***
***

RT_FrameDifference(clip c,clip c2,int "n"=current_frame,int "n2"=current_frame,Float "ChromaWeight"=1.0/3.0,
int "x"=0,int "y"=0,int "w"=0,int "h"=0,int "x2"=x,int "y2"=y,bool "Altscan"=false,bool "ChromaI"=false,
Int "Matrix"=(Width>1100||Height>600)?3:2)
Returns difference between clip c frame n area x,y,w,h and clip c2 frame n2 area x2,y2,w,h. (range 0.0 -> 255.0).

Args:-
c, c2, clips to difference.
n, default = current_Frame. Frame from clip c.
n2, default = current_Frame. Frame from clip c2.
ChromaWeight, default 1.0/3.0. Range 0.0 -> 1.0.
Y8, returns same as LumaDifference. ChromaWeight ignored.
YUV,
Weighting applied YUV chroma:- (1.0 - ChromaWeight) * Lumadif + ChromaWeight * ((Udif + Vdif)/2.0).
RGB,
If ChromaWeight > 0.0, then returns same as RT_RGBDifference() [ie average RGB pixel channel difference].
If ChromaWeight == 0.0, then returns same as RT_LumaDifference() using Matrix arg to convert RGB to YUV-Y Luma.
x,y,w,h. All Default 0 (full frame), for clip c.
x2,y2. x2 defaults x, y2 defaults y, for clip c2.
Altscan, default false. If true then scan only every other scanline starting at clip c y coord, and clip c2 y2 coord.
ChromaI, default false. If YV12 and ChromaI, then do YV12 interlaced chroma scanning.
Ignored if not YV12. Both YV12 clips must be same, cannot difference one that is progressive and one that has interlaced chroma.
Matrix, default (c.Width>1100||c.Height>600||c2.Width>1100||c2.Height>600)?3:2
Conversion matrix for conversion of RGB to YUV-Y Luma. 0=REC601 : 1=REC709 : 2 = PC601 : 3 = PC709.
Default = (c.Width > 1100 OR c.Height>600 OR c2.Width > 1100 OR c2.Height>600) then 3(PC709) else 2(PC601). YUV not used
Matrix only Used if RGB and ChromaWeight == 0.0, where returns same as RT_LumaDifference().
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

Using Delta, Interlaced (later renamed to AltScan for some functions), and Y args to compare pretty much any fields.

EDIT: From the RT_YDifference example given,

diff = RT_YDifference(clip,delta=0,y2=1,interlaced=true)
# Would difference the even and odd lines of the same frame,

and

diff = RT_YDifference(clip,delta=1,y2=1,interlaced=true)
# Would difference the current_frame even and Next_frame odd lines, etc

flossy_cake

14th November 2022, 11:30

I guess there is also something like

LumaDifference(SeparateFields().SelectEven(), SeparateFields().SelectOdd())

But I don't know how meaningful it is.

edit: yep, not very meaningful it seems. I'm getting more meaningful numbers out of CFieldDiff / 1000000 + 207590 -- a value of about 0.25 on noncombed pans and 7 on combed pans. If it's less than about 0.125 then it seems safe to believe the result of IsCombedIVTC.

I'll have to try your RT_ funcs to see how they compare -- thanks.

StainlessS

14th November 2022, 11:39

LumaDifference takes two clips (where could be same clip).

similar is

RT_LumaDifference(clip c,clip c2,int "n"=current_frame,int "delta"=0,int "x"=0,int "y"=0,int "w"=0,int "h"=0,
int "n2"=current_frame,int "delta2"=0,int "x2"=x,int "y2"=y,bool "interlaced"=false,int "Matrix"=(Width>1100||Height>600?3:2))
Returns FLOAT value luma difference (0.0 -> 255.0) between clip c frame (n+delta) area x,y,w,h, and clip c2 frame (n2+delta2) area x2,y2,w,h.
Note, 'x2' and 'y2' default to 'x' and 'y' respectively.
v2.0, c and c2 need not be same dimensions but BEWARE, x2 and y2 default to x and y also w and h default to 0
which is converted to c.width-x and c.height-y, may be best to provide x2, y2, w and h where c2 not same dimensions as c.

StainlessS

14th November 2022, 11:44

Maybe of interest,
mod of snippit posted by TheCoreyBurton, [cant find his post, TheCoreyBurton account deleted]
https://forum.doom9.org/showthread.php?p=1785099#post1785099

Function DoubleRate(clip c,Bool "Blend") {
c
Blend=Default(Blend,False) # Avoid blends at scene change (copy previous frame)
prefilt = DeGrainMedian() # some smoothing
superfilt = MSuper(prefilt, hpad=16, vpad=16, rfilter = 4) # all levels for MAnalyse
super = MSuper(pel=2, hpad=16, vpad=16,rfilter=4,levels=1) # one level is enough for MRecalculate
bw_1 = MAnalyse(superfilt, chroma = false, isb = true, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
fw_1 = MAnalyse(superfilt, chroma = false, isb = false, blksize = 16, OverLap=2, searchparam = 3, plevel = 0, search = 3, badrange = (-24))
bw_2 = MRecalculate(super, chroma = false, bw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap (currently broken for final vectors)
fw_2 = MRecalculate(super, chroma = false, fw_1, blksize = 8, searchparam = 1, search = 3) # No Overlap
MBlockFps(super, bw_2, fw_2, num=FramerateNumerator(c) * 2, den=FramerateDenominator(c), mode=0, Blend=Blend)
Return Last
}

Function HybridDoubleRate_QTGMC(clip c,String "Preset",Bool "Blend",Bool "Show") {
c
Preset=Default(Preset,"Very Slow")
Blend=Default(Blend,False) # for DoubleRate. False dont blend scene change, copy previous frame, true blend.
Show=Default(Show,False)
DeInt=QTGMC(preset=Preset) Deint=(Show) ? Deint.AddBorders(0,0,0,20,$FF0000).Subtitle("QTGMC "+Preset+" Deinterlaced",Align=1) : Deint
Dbl=DoubleRate(c,Blend) Dbl =(Show) ? Dbl.AddBorders(0,0,0,20,$000000).Subtitle("DoubleRate",Align=1) : Dbl
A=ConditionalFilter(last,DeInt.SelectEven,Dbl.SelectEven,"IsCombedTIVTC","=","true")
B=ConditionalFilter(last,DeInt.SelectOdd, Dbl.SelectOdd, "IsCombedTIVTC","=","true")
Interleave(A,B)
Return Last
}

Function HybridDoubleRate_NedYad(clip c,Bool "Blend",Bool "Show") {
c
Blend=Default(Blend,False) # for DoubleRate. False dont blend scene change, copy previous frame, true blend.
Show=Default(Show,False)
NED = NNedi3(Field=-2, nns=2) # Field -2 = double rate, internal parity value to start (set by AssumeT/BFF)
DeInt= YadifMod(Order=-1,Mode=1,edeint=NED) # Order -1 = Internal Parity. Mode 1=double rate do spactial
Deint=(Show) ? Deint.AddBorders(0,0,0,20,$FF0000).Subtitle("Ned/Yad Deinterlaced",Align=1) : Deint
Dbl=DoubleRate(c,Blend) Dbl =(Show) ? Dbl.AddBorders(0,0,0,20,$000000).Subtitle("DoubleRate",Align=1) : Dbl
A=ConditionalFilter(last,DeInt.SelectEven,Dbl.SelectEven,"IsCombedTIVTC","=","true")
B=ConditionalFilter(last,DeInt.SelectOdd, Dbl.SelectOdd, "IsCombedTIVTC","=","true")
Interleave(A,B)
Return Last
}

VideoFileName ="D:\BAB-59\VIDEO_TS\bab59.d2v"
MPEG2Source(VideoFileName)
AssumeTFF

#HybridDoubleRate_QTGMC(Preset="Slow",Show=True)
HybridDoubleRate_NedYad(Show=True)

Is really pretty good.
Deinterlace interlaced sections, and MC doubled framerate for progressive sections.
Perhaps change YdifMod to YadifMod2

EDIT: something I was playing with (Work in Progress - not sure if in working condition or not)

vExt = GetFilenameExtension(VideoFileName)

If(vExt == ".dgi") { DGSource(VideoFileName) }
Else { Mpeg2Source(VideoFileName)}

AudioExt=RT_GetFileExtension(AudioFileName)

Audio= (AudioExt==".ac3") ? NICAC3Source(AudioFileName,channels=2,DRC=0)
\ : (AudioExt==".mpa"||AudioExt=="mp1"||AudioExt==".mp2"||AudioExt==".mp3") ? NicMPG123Source(AudioFileName,Normalize=False)
\ : (AudioExt==".wav") ? RaWavSource(AudioFileName)
\ : (AudioExt==".dts") ? NicDTSSource(AudioFileName)
\ : (AudioExt==".w64") ? RaWavSource(AudioFileName,samplerate=6)
\ : 0

Assert(!isInt(Audio),"NO AUDIO")

(!isInt(Audio)) ? AudioDub(Audio).DelayAudio(AudioDelay).Trim(0,0) : NOP # Trim, chop/add audio to length

(!isInt(Audio) && AudioRate() <> 44100) ? ResampleAudio(44100) : NOP

####### CONFIG ##########

/*
PalHybridToProgressive().

Optional:
Calls TFM() to match fields for Phase Shifted. [When showing Stacked result, shows original pre-TFM clip as Src]
Calls Spotless() on Separated Fields and re-weaves. [more temporally stable than separate calls for interlaced/progressive]

IsCombedTIVTC() Interlaced de-interlaced via YadifMod2, Progressive double rated via JohnFPS() [even fields Lossless].

Optional:
McDegrainSharp() on now fully progressive result. [also helps smooth and migrate detail into even result frames when returning singlerate (well thats the idea anyway)].

*/

If(vExt == ".d2v") {
TFM(d2v=VideoFileName) # field match, fix Perverse Telecine + other crap
} Else {
TFM()
}

return last

DBLRATE = True # Double Rate result.
DOTFM = false # Basic fix phase shifted
TFM_Mode = 0
DS_RADT = 2 # Spotless Radius
DS_THSAD = 128*(8/2*8/2) # noise + small spots on interlaced [255*(8/2*8/2) / 2 : /2 for interlaced field despot]
DS_PEL = 1 #
CMB_CTHRESH = 9 # 9)
CMB_MI = 80 # 80)
CMB_Chroma = False # False)
CMB_BlockX = 16 # 16)
CMB_BlockY = 16 # 16)
CMB_Metric = 1 # 0)
MCD_FRAMES = 1 #
MCD_CSHARP = 0.3 #
Show = True # True to switch on subs etc
Stack = True # True to Show Source as well as result (If Show)

# Requires setting Field Order before calling.
PalHybridToProgressive(DBLRATE, DoTfm=DOTFM,TFM_mode=TFM_Mode, DS_RadT=1, DS_ThSAD=DS_THSAD,DS_Pel=DS_PEL,CMB_CThresh=CMB_CTHRESH,CMB_Mi=CMB_MI,CMB_Chroma=CMB_CHROMA,CMB_Metric=CMB_Metric,Mcd_Frames=MCD_FRAMES,Mcd_Csharp=MCD_CSHARP,Show=SHOW,Stack=STACK)

Return Last

Prefetch(4)
Return Last

Function PalHybridToProgressive(clip c, Bool "DblRate",bool "Chroma",
\ Bool "DoTfm", Int "TFM_Mode",
\ Int "DS_RadT", Int "DS_ThSAD", Int "DS_ThSAD2", Int "DS_Pel", Int "DS_BlkSz", Int "DS_TM", String "DS_Dc", [* Spotless Args *]
\ Int "CMB_CThresh",Int "CMB_MI",Bool "CMB_Chroma", Int "CMB_BlockX",Int "CMB_BlockY",int "CMB_Metric", [* IsCombedTIVTC *]
\ Int "MCD_Frames", Float "MCD_CSharp", [* McDegrainSharp *]
\ Bool "Show", Bool "Stack" [* Debug *]
\ )
{
DblRate = Default(DblRate, True)
Chroma = Default(Chroma, True) # Make False for Greyscale.
#
DoTfm = Default(DoTfm,False) # False) True=Field matching. Basic fix for Phase Shifted (AKA Perverse) Telecine
TFM_Mode = Default(TFM_Mode,1) # 0) If DoTfm then TFM(Mode=TFM_Mode). If more exotic TFM() required, then set DoTfm=False & call Your Tfm() before this function.
# SpotLess, Set frame radius DS_RADT 1 or more to switch on.
DS_RadT = Default(DS_RadT, 0) # 0) SpotLess temporal radius (spots on RadT consecutive frames)
DS_ThSAD = Default(DS_ThSAD, 255 * (8/2 * 8/2)) # 255 * (8/2 * 8/2) = 4080 = 1/4 of 8x8 block @ 255 or Maybe eg 24 * (8*8) = 1536 for general noise. ::: Spotless/MvTools default = 10,000, about 156*(8*8)
DS_ThSAD2 = Default(DS_ThSAD2, DS_ThSAD - ((DS_RadT-1)*(8*8))) # A bit less.
DS_Pel = Default(DS_Pel, 2) # 2), or max = 4
DS_BlkSz = Default(DS_BlkSz, 8) # 8) Maybe dont change
DS_Tm = Default(DS_Tm, False) # False). TrueMotion, some like true, some like False.
DS_Dc = Default(DS_Dc,"RemoveGrain(22).Blur(0.3)")

# CombedTIVTC args, Defaults, 1st after comment hash.
CMB_CThresh = Default(CMB_CThresh, 8) # 8), Area combing threshold [ ~ 8 -> 12].
# Valid settings are from -1 (every pixel will be detected as combed) to 255 (no pixel will be detected as combed).
# This is basically a pixel difference value. A good range is between 8 to 12.
CMB_Mi = Default(CMB_Mi, 80) # 80), Number of combed pixels inside any of the BlockX by BlockY size blocks on the frame, for the frame to be detected as combed.
CMB_Chroma = Default(CMB_Chroma,False) #
CMB_BlockX = Default(CMB_BlockX, 16) # 16), X-axis size of the window used during combed frame detection.
CMB_BlockY = Default(CMB_BlockY, 16) # 16), Y-axis size of the window used during combed frame detection.
CMB_Metric = Default(CMB_Metric,1) #
# So in any single block, if 85[MI] out of 256[BlockX x BlockY] pixels pass CThresh as combed, then is Interlaced.
#
MCD_Frames = Default(MCD_Frames, 0) # 0) Acts on both Deinterlaced and JohnFPS doubled Progressive frames. McDegrainSharp(frames=MCD_Frames), (0=Dont McDegrainSharp)
MCD_CSharp = Default(MCD_CSharp, 0.3) # 0.3) McDegrainSharp() , defaults to 0.6 in McdegrainSharp.

#
Show = Default(Show,False) # Show Titlebar and Deinterlaced Sub.
Stack = Default(Stack,True) # Shows Src as well as result [Ignored if Show=False]
###
c
Stack = (Show&&Stack)
Src = Last
myName = "PalHybridToProgressive: "
Assert(!c.Is420 || Height % 4 == 0,myName+"Interlaced Height MUST be mod 4")

COMBDET = "IsCombedTIVTC(cthresh="+string(CMB_cthresh)+",MI="+String(CMB_MI)+",chroma="+String(CMB_Chroma)+",blockx="+String(CMB_blockx)+",blocky="+String(CMB_blocky)+",metric="+String(CMB_metric)+")"

MatchedSrc = (DoTfm) ? Src.TFM(Mode=TFM_Mode,PP=0,Slow=1,mchroma=false,micMatching=0) : Src

# Field based despotting, for both interlace and progressive [avoid inconstancy between interlaced and progressive]
if(DS_RadT>0) {
DeSpot_E = MatchedSrc.SeparateFields.SelectEven.SpotLess(Radt=DS_RadT,thsad=DS_ThSAD,thsad2=DS_ThSAD2,Pel=DS_Pel,chroma=Chroma,blksz=DS_BlkSz,tm=DS_Tm,glob=True,dc=MatchedSrc.SeparateFields.SelectEven.Eval(DS_Dc))
DeSpot_O = MatchedSrc.SeparateFields.SelectOdd.SpotLess( Radt=DS_RadT,thsad=DS_ThSAD,thsad2=DS_ThSAD2,Pel=DS_Pel,chroma=Chroma,blksz=DS_BlkSz,tm=DS_Tm,glob=True,dc=MatchedSrc.SeparateFields.SelectOdd.Eval (DS_Dc))
DeSpot = Interleave(DeSpot_E,DeSpot_O).Weave
} Else { DeSpot = MatchedSrc }

# Deinterlaced = DeSpot.YadifMod2(Order=-1,Mode=1,edeint=DeSpot.NNedi3(Field=-2, nns=2)) # Order -1 = Internal Parity. Mode 1=double rate do spatial : Field-2=double rate internal parity,
Deinterlaced = DeSpot.BWDif(Field=-2,edeint=DeSpot.NNedi3(Field=-2, nns=2)) # field -2=Double rate internal parity.
# Deinterlaced = DeSpot.QTGMC(Preset="fast",NoisePreset="Fast",SourceMatch=2,Lossless=2,EZKeepGrain=0.4,Sharpness=0.1, tr2=0)

Progressive = Despot.JohnFPS()

DoubleRateE = GConditionalFilter(MatchedSrc, Deinterlaced.SelectEven, Progressive.SelectEven, COMBDET,"=","true")
DoubleRateO = GConditionalFilter(MatchedSrc, Deinterlaced.SelectOdd, Progressive.SelectOdd, COMBDET,"=","true")
DoubleRate = Interleave(DoubleRateE,DoubleRateO)
Last = (MCD_Frames>0) ? DoubleRate.McDeGrainSharp(frames=MCD_Frames,csharp=MCD_CSharp,chroma=Chroma) : DoubleRate # McDegrainSharp on resultant doublerate Progressive

if(SHOW) {
Tit = (!DblRate) ? "SingleRate" : "DoubleRate"
SrcD = Interleave(Src,Src)
MatchedSrcD = Interleave(MatchedSrc,MatchedSrc)
ResultBar_K = Last.BlankClip(height=20,Color=$000000).ScriptClip("""Subtitle(""""+"(P)"+Tit+"""")""")
ResultBar_R = Last.BlankClip(height=20,Color=$FF0000).ScriptClip("""Subtitle(""""+"(I)"+Tit+"""")""")
ResultBar = GConditionalFilter(MatchedSrcD, ResultBar_R, ResultBar_K, COMBDET,"=","true")
Last = StackVertical(ResultBar,Last)
if(Stack) {
Tit = (!DblRate) ? "Src" : "Src (DblRate:Dupes)"
if(DoTfm) {
bpc = Src.BitsPerComponent()
Src8D = (bpc==8) ? SrcD : SrcD.ConvertBits(8)
MSrc8D = (bpc==8) ? MatchedSrcD : MatchedSrcD.ConvertBits(8)
LftWin_A = StackVertical(Last.BlankClip(height=20).ScriptClip("""Subtitle(""""+Tit+"""")"""),Src8D)
WW_L = (LftWin_A.Width / 4) * 2
WW_R = LftWin_A.Width - WW_L
LftWin_BL = LftWin_A.Crop(0,0,WW_L,0)
LftWin_BR = StackVertical(MSrc8D.BlankClip(Width=WW_R,height=20,Color=$0000FF).Subtitle("TFM"),MSrc8D.Crop(WW_R,0,0,0))
LftWin_B = StackHorizontal(LftWin_BL,LftWin_BR)
LftWin = LftWin_A.GConditionalFilter(LftWin_A,LftWin_B,"LumaDifference(Src8D,MSrc8D)","=","0.0",Args="LftWin_B,Src8D,MSrc8D",Local=True)
#SSS="return (LumaDifference(Src8D,MSrc8D) == 0.0) ? Last : LftWin_B"
#LftWin = LftWin_A.GScriptClip(SSS ,Args="LftWin_B,Src8D,MSrc8D",Local=True)
} Else {
LftBar = Last.BlankClip(height=20,Color=$000000).ScriptClip("""Subtitle(""""+Tit+"""")""")
LftWin=StackVertical(LftBar,SrcD)
}
StackHorizontal(LftWin,Last)
}
}
Return ((DblRate) ? Last : Last.SelectEven).AudioDubEx(Src)
}

Function GetFilenameExtension(String fn) {
fn=fn.RevStr i1=fn.FindStr("\") i2=fn.FindStr("/")
i=(i1==0) ? i2 : (i2==0) ? i1 : min(i1,i2)
fn=(i>0) ? Fn.LeftStr(i-1) : fn
i=fn.FindStr(".")
Return (i>0)?fn.LeftStr(i).RevStr:""
}

# Stack Overhead Subtitle Text, with optional FrameNumber shown.
Function TSub(clip c,string Tit,Bool "ShowFrameNo",Int "Col"){
c.BlankClip(height=20,Color=Default(Col,0))
(Default(ShowFrameNo,False))?ScriptClip("""Subtitle(String(current_frame,"%.f] """+Tit+""""))"""):Trim(0,-1).Subtitle(Tit)
Return StackVertical(c).AudioDubEx(c)
}

EDIT: Above EDITED

EDIT: qCombed() v1.03, mod of IsCombed (c)Donald Graft.:- https://forum.doom9.org/showthread.php?p=1776495#post1776495

flossy_cake

15th November 2022, 06:49

I couldn't get DG's IsCombed() working on my system, it always returns false regardless of threshold param. But your qCombed mod works -- cheers. I'll have to play around with it for a few hours to see what it thinks of various content. Preliminary results are that it is similar to IsCombedTIVTC but with a lower threshold.

Honestly though I'm a bit frustrated as I can't seem to get a grip on how NTSC soft telecine actually works. For instance, do the repeat flags mean repeat FIELD or repeat FRAME? Is the stream really 24p with repeat flags, or is it the same 30i stream but with duplicate fields simply containing no picture data and just a "repeat me" flag. One source filter behaves different to another even with the same "repeat" param, so I can't even do experiments to get enough data to make a reliable inference.

Anyway, I decided to dig out my old Sony DVD player to see how it handles it. The test video was S03E01 of NTSC Caroline in the City (from which that laundry scene was taken). The rest of that season is hard telecined, so I can easily compare how the DVD player handles both types.

The hard telecined episodes are motion compensated deinterlaced (same as bwdif with threshold set to a value of around 2-3). So static stuff gets weave, anything that moves drops to 240p. Therefore on hard telecine content, TFM is producing superior results compared to my DVD player, and this is highly satisfying. The only issue with TFM is that because some scenes begin on a combed frame, the first field of the scene is only a half image without any other field to match it to, so it gets dropped, resulting in a repeated frame at the beginning of some scene changes. This is actually noticeable and kind of annoying, but I think still preferable to 240p on motion. I've tried to get TDecimate to produce a blend on such frames but couldn't get it to work reliably. Played around with the scene threshold params too but couldn't find the magic setting.

As for the soft telecined episodes, those seem to be handled better by the DVD player: progressive frames are presented unaltered, while any combing on scene changes is interpolated. And it seems to get this perfect -- never interpolates when it shouldnt, never weaves when it shouldn't. The final output format of the DVD player is p60 though, so 3:2 judder. But all frames are progressive and contain maximum resolution available at all times. I'm not able to achieve this with TFM or TDecimate unfortunately, so far.

Seems to be an issue with the source filter. I think the source filter needs to signal repeat FIELDS correctly so that downstream knows which exact fields need to be interpolated. I can't seem to get this happening, so for now I'm just forcing the soft telecined episodes to hard telecined by setting "obey repeat flag" to true in the source filter, and letting TFM and TDecimate convert it back to 24p again.

I'm not keen on adding a lot of extra post processing like additional decombing or deint passes and such, as those can degrade the image and I'm yet to find a combing detection filter that is reliable enough to avoid false positives and therefore cause unnecessary drops to 240p (or conversely, failing to detect combing).

So I keep coming back to this idea that the source filter needs to flag FIELDS as needing interpolation, and the downstream processor/renderer needs to use that to decide when to interpolate FIELDS. And, I need this to be done in realtime, just like with a DVD player. This seems possible in theory, but in practice?

StainlessS

15th November 2022, 10:10

do the repeat flags mean repeat FIELD or repeat FRAME?
I believe only fields are repeated (but I live in pal land and rarely have NTSC 'stuff'.)

So I keep coming back to this idea that the source filter needs to flag FIELDS as needing interpolation, and the downstream processor/renderer needs to use that to decide when to interpolate FIELDS.
I think that is why its best to use

d2v = "..."
Mpeg2Source(d2v)
TFM(d2v=d2v,...) # maybe PP = 0 for no post processing

tormento

15th November 2022, 11:01

As I am getting mad at Cowboy Bebop, I need your help as expert "defielders". :p

There have been different attempts in the past but nowadays we have a lot more of powerful plugins, so I decided to give it a personal run.

The video is an "intentional" mix of 23.976p (animations, the 80% of the video), 29.97p (pannings) and 60i (CGI), all soft tagged as 29.97p. The author tells us that that was the best way to preserve the "feeling" and "crispness" of the anime.

I'd like to have a uniform fps, possibly a standard one, such as 23.976p being the most used there, without sacrificing quality too much (CGI has different images at every 60i frame).

Can you, please, help me with a proper script to deal with it?

Here (https://krakenfiles.com/view/ZCTElUsXUN/file.html) is a sample.

PoeBear

16th November 2022, 07:38

LWLibavVideoSource("Bebop.m2ts")
TFM().TDecimate()

Unless you're going to VFR or comb through them by hand and do something special with the 29.97/59.94 scenes, that's all you really can do. Your output would match how the US Blu-ray was done

tormento

16th November 2022, 17:52

Your output would match how the US Blu-ray was done
That has terrible rendering of the 60i frames. :(

flossy_cake

17th November 2022, 05:54

I'm working on a realtime solution for such "mixed cadence" content, where it will output all sequences at 60p, such that the 24p sequences become 3:2, 30p sections become 2:2, and 60i sections are 1:1. All in a 60p "container". hello_hello managed to solve this already by making it into a VFR file using timecode file, but it wasn't ideal for me as I wanted a realtime solution that didn't require transcoding (generation loss).

The logic of it is actually simpler than I was expecting: just choose either TFM.TDecimate.ChangeFPS(60000,1001) or TFM.BWDIF(field=-2, thr=3) depending on whether the last 5 consecutive frames of the output of TFM are unique, i.e if the YDiff or CFrameDiff are all above a certain value for the last 5 frames. The hard part is trying to get Avisynth to do what I want it to do on a per-frame basis given the quirks and limitations of its runtime functions, but, I think I've finally got it doing what I want using a combination of ScriptClip and FrameEvaluate. But I'm not optimistic as I really need to "look ahead" 5 frames otherwise the transition between 24p and 30p/60i sections could have a stutter. And the per-frame evaluations need to be done in a controlled order, which is difficult given how Avisynth handles multithreading (the docs warn that messaging through global variables is "unsafe" inside a runtime function due to this).

What would really help though is if Tritical's CFrameDiff had a parameter to calculate the diff between current frame and n frames ahead, just like the internal YDiffToNext does. Because I have a feeling YDiffToNext is not going to be sufficient & Tritical is using more robust metrics with CFrameDiff (and even that gets some false positives eg. if there's composite video dotcrawl that changes every field -- coincidentally that's why sometimes the duplicate frame in the TFM stream looks ever so slightly different -- because it's matching it with a field that although correctly matched in the sense it comes from the same frame, it comes from a different "copy" of that field, i.e the third of the "3" in "3:2" sequence instead of the first).

PoeBear

17th November 2022, 07:50

That has terrible rendering of the 60i frames. :(

Then you can edit out all the 60i parts by hand, and use that Dogway script on them. It's always going to look rough unless you interpolate more frames before bringing back down to 23.976

Dogway

17th November 2022, 10:09

The video is an "intentional" mix of 23.976p (animations, the 80% of the video), 29.97p (pannings) and 60i (CGI), all soft tagged as 29.97p. The author tells us that that was the best way to preserve the "feeling" and "crispness" of the anime.

I'd like to have a uniform fps, possibly a standard one, such as 23.976p being the most used there, without sacrificing quality too much (CGI has different images at every 60i frame).

Can you, please, help me with a proper script to deal with it?

Here (https://krakenfiles.com/view/ZCTElUsXUN/file.html) is a sample.

Now your explanation made it more clear and with the source I could have a look.
Interesting practice as it has been a very long time since I had to deal with fields...

The script below treats each mode separately, augmenting them to 60fps progressive with duplicates.

DGSource("Bebop.dgi",cl=236,ct=0,cr=236,cb=0)
src=last

### NTSC ###
N=Interleave(src,src)

### FILM ###
DGTelecide()
TDecimate(mode=1) # anime
Interleave(last,last,last)
TDecimate(1,1,6) # Decimate on longest strike so the pace shift ratio is minimal
F=last

### INTERLACED ###
src
QTGMCp(tr2=1,preset="very slow",sourcematch=2,sharpness=0.2,MatchEnhance=0.0,MatchPreset="Slow", MatchPreset2="Slow",border=false)
I=last

ClipClop(F,N,I,sCMD="N(0,5125); F(5126,5455); N(5456,9180); I(9181,9349);")

# VFR in 60fps CFR progressive

In the end you run the fabolous ClipClop to stitch them back together.
The way to look for frame numbers in this 60fps mashup is to take the source and simply:
src
Interleave(last,last)

in another tab in AvsPmod, then go through it and mark with bookmarks the frames where each mode starts.
A script for detection could be possible I think. Simply look for combed frames, if all progressive it's 29.97, if all combed it's 60i, otherwise it's telecine. It's not that easy since you have to keep into account long streaks of no movement, and also scene changes.
As I said yesterday I'm a bit busy finishing my scripts but many people can help on this regard.

A remark on augmenting FILM to 60fps, this works only because it's anime. As I observed the animation pattern goes mostly 3x3, sometimes 3x2, and rarely 2x2. The framerate augment is not linear so the animation pace can be altered but on the good side the shift is minimal 1/60 = 0.017 seconds at most every 10 frames. Or for a 3x3 pattern, multiplied by 2.5 gives 7.5x7.5 or 8x7 after 1 out of 6 decimation.
The only problematic area is when there's 30fps content going on through the windows (the asteroids), there you'll see 3 dups followed by 2 dups, and this can cause some stutter, but it would be the same if played on TV.

In my opinion this is better than interpolation, which doesn't work nice for anime.
It would involve interpolating 24p to 120p, then selectevery(4,0).Interleave(last,last)

timecode VFR I don't recommend as the TV will be jumping through refresh rates.

tormento

17th November 2022, 13:08

I'm working on a realtime solution
That would be really nice! Please keep us informed about progress.

tormento

17th November 2022, 13:24

The script below treats each mode separately, augmenting them to 60fps progressive with duplicates.
Great! Does it keep the original duration? I don't want to mess with audio or subs.
in another tab in AvsPmod, then go through it and mark with bookmarks the frames where each mode starts.
This point is obscure to me. Using interleave(last,last) outputs a 59.97 video, how is possible to find the exact places where fps changes?
A script for detection could be possible I think.
It would be much better, please ;) That script could be really usefulm even in ExTools, to have a swiss knife to deal with "variable" fps sources.

Reel.Deel

17th November 2022, 18:11

@tormento

There's NTSCanalyze (https://forum.doom9.org/showthread.php?p=1251823#post1251823), from experience it does an OK job, but it's prone to some errors on some frames. There was a discussion on how to improve it here (https://forum.doom9.org/showthread.php?t=173905).

flossy_cake

18th November 2022, 06:54

Yeah the big issue is dealing with false positives and false negatives. And @Dogway mentioned also: "It's not that easy since you have to keep into account long streaks of no movement, and also scene changes". If the content is like 90% 24p and 10% 30p/60i then I suppose you could bias the error in the direction of assuming 24p in such "when in doubt" scenarios. eg. if YDiff or CFrameDiff of last 5 frames are ALL below some threshold, then treat it as 24p. In this case 24p sections should look good, but slight stutter when there is very small amount of motion on 30p sections.

flossy_cake

18th November 2022, 14:38

There seems to be a bug with TFM's motion adaptive deinterlacing, eg. when PP=6 (the default). It seems to drop the entire frame to half vertical resolution when it detects combing, when it should only be doing that for moving parts of the image, as that is the whole "motion adaptive" feature (otherwise I think it would have been called field discarding or drop field or something like that). To reproduce it set cthresh=-1 so that TFM thinks everything is combed.

It seems we can work around this though with eg. clip2=bwdif, which then seems to activate TFM's better internal logic of only using deinterlaced pixels for moving parts of the image, and those pixels then become bwdif's pixels. edit: actually now that I think about it, it's probably just replacing the entire frame with bwdif's pixels when isCombed, but I can't tell for sure. If it were the case, it just means TFM's motion adaptive deinterlacing is extremely primitive... but that doesn't seem likely either given the author's other work with TDeint. Still, I don't know for sure.

Also on the other issue of scene changes having a repeat frame due to orphaned field, that seems workaroundable with scthresh=100, which causes combed frames on scene changes to stay combed, so that they get picked up by PP=6 & therefore clip2=bwdif'd. With this setting, image quality now is on par with my Sony DVD player for such soft telecined content which orphaned fields on scene changes - good.

flossy_cake

18th November 2022, 19:04

I'm working on a realtime solution for such "mixed cadence" content, where it will output all sequences at 60p, such that the 24p sequences become 3:2, 30p sections become 2:2, and 60i sections are 1:1. All in a 60p "container". hello_hello managed to solve this already by making it into a VFR file using timecode file, but it wasn't ideal for me as I wanted a realtime solution that didn't require transcoding (generation loss).

Wow it looks like TFM can do this all on its own!

Test clip: https://drive.google.com/file/d/1KdE0np8016zr7ovRassdbH7OtbKU7e-a/view?usp=sharing

source = "480i 3-2 and 1-1.mkv"

LWLibavVideoSource(source=source, stream_index=-1, repeat=true, cache=false)

TFM(last.ChangeFPS(60000,1001), mode=5, PP=6, cthresh=3, MI=80,
\ scthresh=100, slow=2, ubsco=false, mmsco=false, micmatching=4,
\ clip2=bwdif(last, field=3, thr=3), display=true)

LanczosResize(720,540)

The above assumes you have the latest BWDIF which has the new thr param: https://github.com/Asd-g/AviSynth-BWDIF/releases. Also its negative field param values won't work anymore if the file has _FieldBased=0 (progressive) which soft-telecined content seems to have. That's why I've set it to 3 instead of -2 (this particular clip is hard-telecined though).

Still have the issue with combing detection not being quite good enough on actors mouths when they are sitting perfectly still (eg. the female newsreader in the clip) their mouth will get combed cause there just isn't enough motion. That's why I've lowered cthresh from 9 to 3, and it still fails a little bit there. If your content has a lot of 60i you might want to lower it to 2 and then lower MI as well to 48-64 or something. But then you'll probably get more false positives on 24p sections and have resolution dropping to 240p on motion when it shouldn't.

edit: BWDIF and yadifmod2 seem to have an issue where they can't detect dynamic changes to the field order (git issue (https://github.com/Asd-g/AviSynth-BWDIF/issues/4#issuecomment-1321062436)). TDeint(mode=1) and Bob() seem to be fine and can detect dynamic field order changes. The test clip in this post is not affected as the field order is static.

flossy_cake

19th November 2022, 05:30

imo the combing detection is the real weak point with TFM and TDeint. I've tried DG's isCombed (qCombed) as well and that is not reliable enough either. It needs per-scene threshold tweaks to work reliably. Even on one scene I raised the threshold to 50 and it was still declaring the whole frame as combed. I need a better metric, and it has to be fast for real time use.

Or maybe I need to come up with a whole new strategy like a new type of mask with some hysteresis characteristic. Or a mod of IsCombedTIVTC which assigns each 16x16 block a boolean isCombed and only deinterlaces blocks with true.

flossy_cake

19th November 2022, 10:57

I'm finding TDecimate's mode2 seems to be doing a better job at managing bad edits and orphaned fields in problematic 3:2 content. In mode2 we don't specify cycle & cycleR but instead just give it a frame rate value like 23.976 and it uses an alternate algorithm to decide which frames to remove. Whereas with mode0 & mode1 I was finding there would be some scenes where there would be 2 candidate frames for decimation within a cycle of 5 frames, and it would pick the wrong one. Not necessarily by virtue of bad logical reasoning, as in one case it picked the one with the lower framediff value, but it just so happened the frame with the slightly lower framediff value was the real frame and the other was the duplicate. It's a tricky situation.

tormento

20th November 2022, 11:53

And what about duration? Does all that lead to audio desync? I could be really hard to fix it per scene based.

flossy_cake

20th November 2022, 12:12

And what about duration? Does all that lead to audio desync?

I don't see any reason why it would, since 60 frames are going in & 60 frames are coming out. Nothing is getting re-timed, it's just doing field matching and deint on the 60 frame input.

For some reason TFM needs micmatching=4/5 to work when the input framerate is duplicated from 30 to 60, and I'm not sure why. I don't even know what micmatching is & couldn't find any documentation explaining it. It looks like something to do with the field matching process -- if anyone knows the details please enlighten me.

flossy_cake

20th November 2022, 12:41

I think that is why its best to use

d2v = "..."
Mpeg2Source(d2v)
TFM(d2v=d2v,...) # maybe PP = 0 for no post processing

It seems the clip already contains the necessary flags to handle it with ScriptClip.

Test clip (laundry sequence, soft telecine with bad edits on scene change): https://drive.google.com/file/d/1dwa7gB3HHuSPXroA2ifm4LtLX0fSs2bM/view?usp=share_link

file = "soft telecine.mkv"

LWlibavVideoSource(file, repeat=false)

ScriptClip(last,
\ """

fieldbased = propGetAny("_FieldBased")
parity = GetParity(current_frame)

if (!IsInt(fieldbased)){fieldbased="undefined"}
else if (fieldbased==0){fieldbased = "progressive"}
else if (fieldbased==1){fieldbased = "bottom field first"}
else if (fieldbased==2){fieldbased = "top field first"}

if (!IsBool(parity)){parity="undefined"}
else if (parity==true){parity = "top field first"}
else if (parity==false){parity = "bottom field first"}

SubTitle("_FieldBased: " + fieldbased + "\n" + "GetParity: " + parity, font="courier new", size=24, lsp=10)

\ """)

LanczosResize(720, 540)

Notably the _FieldBased frame property stays "progressive" the whole time, except for those combed frames on scene change.

It seems LWLibavVideoSource is the only source filter which actually sets the _FieldBased and parity values for each frame.

But it should be a trivial matter of returning a deinterlaced clip when _FieldBased != progressive.

Hard telecined is still problematic but I'm already getting ideas :devil:
edit: it looks like hard telecined doesn't contain any information to detect orphaned fields -- both _FieldBased and Parity remain locked at the same value for all frames.

flossy_cake

21st November 2022, 15:35

Here's an updated version which handles the combing detection issue with a latching system where if a scene contains 4 or more combed frames, the remainder of the scene is treated as combed until the next scene at which point the latch is reset.

# Convert 30i to 60p
# 3:2 sections IVTC'd to 24p and 3:2'd
# 2:2 sections weaved to 30p and 2:2'd
# 1:1 sections deinterlaced to 1:1

global isCombed = false
global combedCount = 0
global yDiff = 0
global sceneThresh = 35
global lastScene = 0
global lastSceneYDiff = 0
global lastFrameNum = 0
global latchDeint = false

file = "https://drive.google.com/file/d/1KdE0np8016zr7ovRassdbH7OtbKU7e-a/view?usp=sharing"
global orig30 = LWLibavVideoSource(source=file, stream_index=-1, repeat=true, cache=false)
global bwdif60 = bwdif(orig30, field=3, thr=2)
global tfm24as60 = TFM(orig60, mode=5, PP=0, cthresh=9, MI=80, scthresh=100,
\ slow=2, ubsco=false, mmsco=false, micmatching=4, display=false)

Select(tfm24as60)
LanczosResize(720,540)

function Select(clip c)
{
c = ScriptClip(c,
\ """

global yDiff = YDifferenceToNext(tfm24as60, -2)
global isCombed = IsCombedTIVTC(tfm24as60, cthresh=9, MI=64)

if (yDiff > sceneThresh || current_frame > lastFrameNum+2 || current_frame < lastFrameNum-2 ){
global latchDeint = false
global lastScene = current_frame
global lastSceneYDiff = yDiff
global combedCount = 0
}

if (isCombed){
global combedCount = combedCount + 1
}

if (!latchDeint && isCombed && combedCount >= 3){
global latchDeint = true
}

global lastFrameNum = current_frame

debug = "frame: " + String(current_frame)
\ + "\n" + "yDiff: " + String(yDiff)
\ + "\n" + "isCombed: " + String(isCombed) + "\n" + "combedCount: " + String(combedCount)
\ + "\n" + "latchDeint: " + String(latchDeint) + "\n" + "lastScene: " + String(lastScene)
\ + " (" + String(lastSceneYDiff) + ")"

if (latchDeint || isCombed) {
bwdif60.SubTitle("BWDIF \n" + debug, font="courier new", size=24, lsp=10)
}
else {
tfm24as60.SubTitle("TFM \n" + debug, font="courier new", size=24, lsp=10)
}

\ """ , after_frame=true)

return c
}

edit: I'll be reworking this considerably over the next few days. I'll try to make something more generic as well so it should work for any 25i or 30i file, hopefully it can function as a "one size fits all" general purpose deinterlacer.

SaurusX

22nd November 2022, 16:52

I've mentioned it before, but a feature of TFM I'd love to see is a "pattern bias" feature. It would attempt to keep to a defined telecine pattern as it compares the combing metrics for each field combination. The pattern would be adhered to if the matches pass the deinterlacing test even if another field combo has a slightly better metric. I'm hoping this would make field matching for shaky animation telecine transfers better and not have those random chunky frames where the two matched fields are basically identical.

flossy_cake

22nd November 2022, 18:08

and not have those random chunky frames where the two matched fields are basically identical.

That sounds like an issue I'm having when using bwdif on 3:2 sections. For some reason it generates a weird looking aliased frame every now and then, as if it had just copied field 1 into field 2 or something. Here are 2 consecutive frames coming out of bwdif:

https://i.ibb.co/pnRHYjy/2-bad.png
https://i.ibb.co/68MdYtP/1-good.png

The second one is how an interpolated field should look. The first one is too aliased for some reason. Now here are the same 2 frames coming out of TDeint:

https://i.ibb.co/3Fxdqk9/3-good.png
https://i.ibb.co/YD2ZBPx/4-good.png

Now that looks better, just interpolation as I would expect to see. So perhaps bwdif is only good for 1:1 content? When I think about it, 3:2 is kind of a strange beast to deinterlace what with the pattern of 2 combed frames followed by 3 progressive frames. I'm sure that is somehow making things confusing for the deinterlacer.

edit: seems to be an issue with LWLibavVideoSource, as the issue goes away when using FFmpegsource2 with the same clip. Hard telecined clips works fine with both though.

edit2: false alarm. The issue appears to be with the clipping software that I used to generate the short clips from the full 22 minute episode (XMediaRecode, which uses ffmpeg). It must have mucked up the repeat field flags during the clipping process, because everything is working fine with the full 22 minute clip and both LWLibav & FFMpegSource2, except for the latter with rffmode=1, which causes the issue to occur again. Also the full episode shows more consistent frame rates and timecodes, in relation to:

LWLibavVideoSource("D:\soft telecine.lwi", repeat=true)
29.97fps, 317 frames, 10.577 sec

LWLibavVideoSource("D:\soft telecine.lwi")
29.97fps, 256 frames, 8.541 sec

FFVideoSource("E:\soft telecine.mkv", cachefile="D:\soft telecine.ffindex", threads=1, RFFMode=1)
29.97fps, 318 frames, 10.610 sec

FFVideoSource("E:\soft telecine.mkv", cachefile="D:\soft telecine.ffindex", threads=1)
24.3789fps, 256 frames, 10.5 sec

The frame rate for the second ffms2 example is usually the indicator there's repeat flags being ignored, because there's hard telecined or video sections too, making the average frame rate non standard. It'll also mess with the audio sync. I don't know why lsmash didn't output the same frame rate.

Sorry about that, I guess we can't use short clips to debug this kind of issue, which is really annoying.

edit3: forgot to mention, must use the latest version of BWDIF which contains some fixes, and use it like this:

propDelete("_FieldBased") # latest version bwdif requires this
BWDIF(field=-2) #-2 = auto detect field order, which is necessary to avoid above aliasing problem

flossy_cake

22nd November 2022, 18:11

I've mentioned it before, but a feature of TFM I'd love to see is a "pattern bias" feature. It would attempt to keep to a defined telecine pattern as it compares the combing metrics for each field combination.

Are you sure it's not TDecimate causing that? TDecimate has [mode2, rate, maxndl] params which should do what you are after. With some of my videos I need to use this configuration to get a consistent decimation pattern.

SaurusX

22nd November 2022, 20:08

Are you sure it's not TDecimate causing that? TDecimate has [mode2, rate, maxndl] params which should do what you are after. With some of my videos I need to use this configuration to get a consistent decimation pattern.

Pretty sure. TFM is the one combining the fields into a full frame and it's the one giving a string of frames for TDecimate to choose from. That combined frame is the problem since two essentially identical stacked fields will of course have a lower combing metric.

hello_hello

23rd November 2022, 17:14

After having another play, I'm still at a loss as to why field matchers/deinterlacers think the progressive frames need deinterlacing and why they make such a mess of it when they do, but for re-encoding.....

What seems to work for the sample at least, is to use much less enthusiastic field matching than TFM's defaults and to back off the combing detection quite a lot. The easiest way to do the former is to use TDeint instead of TFM, and they both have the MI argument.

This fails to find a match for the orphan fields around the scene changes so it de-interlaces them instead, which IMHO is better than duplicate frames.

TDeint(MI=200, TryWeave=true)

Trouble is, there's somehow aliasing built in anyway, and even denoising seems to make it worse, and anti-aliasing tends to blur so I'd sharpen to counter-act it, and of course I'd also be keen not to sharpen noise much....

Both screenshots are the script output upscaled to 1080p by MPC-HC.

FFVideoSource("E:\soft telecine.mkv", FPSNum=24000, FPSDen=1001, threads=1)
CropResize(0,0, 9,0,-7,0, InDAR=15.0/11.0, ResizeWO=true)

https://i.ibb.co/N9Hhd4S/Cropping-and-resizing-only.png

FFVideoSource("E:\soft telecine.mkv", FPSNum=24000, FPSDen=1001, threads=1)
TDeint(MI=200, TryWeave=true)
MCDAA3()
MDegrainNL(Tr=3, thSAD=300)
LSFMod()
CropResize(0,0, 9,0,-7,0, InDAR=15.0/11.0, ResizeWO=true)

https://i.ibb.co/f2f6SMZ/Filtered-cropped-and-resized.png

soft telecine encode.mkv (https://files.videohelp.com/u/210984/soft%20telecine%20encode.mkv) (5.1MB)

flossy_cake

24th November 2022, 13:52

After having another play, I'm still at a loss as to why field matchers/deinterlacers think the progressive frames need deinterlacing

Actually Asd-g is changing all that and making it so that for yadif & bwdif, if frame flag _FieldBased=0 (progressive) then it won't deinterlace and throws an error. I'm trying to convince them here (https://github.com/Asd-g/AviSynth-BWDIF/issues/4#issuecomment-1326042092) to just passthrough the frame instead of throwing error.

This fails to find a match for the orphan fields around the scene changes so it de-interlaces them instead, which IMHO is better than duplicate frames.

Yep, and that is how my Sony DVD player handles it when playing the disc as well, which I find ideal. LWlibavVideoSource actually flags those frames as _FieldBased=2 so it's trivial to do a ScriptClip to switch to bwdif/tdeint etc. when _FieldBased=2.

Also I edited one of my previous comments to mention that the short clips I've been cutting appear to have mucked up metadata in the process of clipping them from the full episode, so I wouldn't necessarily trust the result on those short clips. For instance bwdif was producing some unexpected aliasing but TDeint was not, and I never got to the bottom of it apart from finding that both performed as expected on the full episode but not the short clip.

Anyway, I can see the first screenshot of yours is full resolution progressive frame, and the second one appears blurred on the white rims of the blue cups. I'm not sure if it's weaving or not (I'm guessing it should since you set the MI so high?) but it still looks rather clean and nice -- looks like you are doing antialiasing, denoise & sharpen. For sharpening I'm using MadVR's options but I'm definitely keen on using an antialiasing filter for some of my content so I'll check out MCDAA3 ... just hope it's fast enough for real time.

hello_hello

24th November 2022, 18:09

Actually Asd-g is changing all that and making it so that for yadif & bwdif, if frame flag _FieldBased=0 (progressive) then it won't deinterlace and throws an error. I'm trying to convince them here (https://github.com/Asd-g/AviSynth-BWDIF/issues/4#issuecomment-1326042092) to just passthrough the frame instead of throwing error.

I suspect, given they're fairly new, frame properties will cause a lot of pain for a while.

A friend PM'd me last week wanting to know why some of his scripts were being encoded as interlaced without him changing the encoder command line. I assumed it was operator error until I remembered he likes to pipe scripts to ffmpeg and it supports frame properties now. It turned out the source filter was setting _FieldBased=1 & he was mostly deinterlacing with bwdif and it set _FieldBased=0, but when he used anything else to de-interlace.....

I'm not an expert on this, but is there any way a source filter can know if a video is really progressive unless it's something like an NTSC DVD with repeat flags for applying telecine? If there's no repeat flags I assume it could be interlaced, progressive or hard telecined, and if it's combinations of each then it's probably all encoded as interlaced anyway.

Yep, and that is how my Sony DVD player handles it when playing the disc as well, which I find ideal. LWlibavVideoSource actually flags those frames as _FieldBased=2 so it's trivial to do a ScriptClip to switch to bwdif/tdeint etc. when _FieldBased=2.

In your case there's orphaned fields so you want to treat them as interlaced, but is _FieldBased=2 just a safe assumption that could be incorrect?
As far as I know a progressive scan player would output either 23.976 or 59.97 etc, but without repeat flags it has to physically check for repeated fields and combing as plugins do and choose to de-interlace or apply IVTC on the fly.

Also I edited one of my previous comments to mention that the short clips I've been cutting appear to have mucked up metadata in the process of clipping them from the full episode, so I wouldn't necessarily trust the result on those short clips. For instance bwdif was producing some unexpected aliasing but TDeint was not, and I never got to the bottom of it apart from finding that both performed as expected on the full episode but not the short clip.

I did see a mention of bwdif crapping out at the beginning of the sample, and I did notice the first three frames had the same timecodes, Maybe that had something to do with it, but I think the reason I used FPSNum=24000, FPSDen=1001 instead of repeat=false is the former dropped two of them so there wasn't a pause for a second at the beginning.

If you use rffmode=1, the output would be 60i and all fields would need to be set to interlaced, even for the soft telecined sections. It's then up to the de-interlacer/field matcher to look at them and decide if they're video or film and handle them accordingly.
If rffmode=0, in a perfect world the film sections would be output as progressive and could be marked as progressive, but any sections without repeat flags would still need to be checked. If there's hard telecine I don't think bwdif is the right tool for the job, but I can't imagine why it should throw an error if _FieldBased=0.

Well here's a fun fact for you. I'm going to bang my head against the desk very hard shorty to punish myself, because I think your sample is actually soft telecine from start to finish. If you use rffmode=0 with ffms2 there's no orphaned fields on the scene changes. My guess is it's outputting 24.379fps because without FPSNum=24000, FPSDen=1001 it operates in variable frame rate mode and outputs the average frame rate, and those three frames with the same timecodes at the beginning have fudged the average.
It looks like it's rffmode=1 shuffling fields around scene changes, maybe because of the first three frames, but &%$@ me! How did I not notice that until now??!?

In my defence I did remux the MKV as a TS file to index it with DGIndex, which probably created more problems, and I think LSmash was decoding it differently again, but still.... &%$@ me!

Anyway, I can see the first screenshot of yours is full resolution progressive frame, and the second one appears blurred on the white rims of the blue cups. I'm not sure if it's weaving or not (I'm guessing it should since you set the MI so high?) but it still looks rather clean and nice -- looks like you are doing antialiasing, denoise & sharpen. For sharpening I'm using MadVR's options but I'm definitely keen on using an antialiasing filter for some of my content so I'll check out MCDAA3 ... just hope it's fast enough for real time.

The blurring of the cups would have been MCDAA3 cleaning up the all the wobble (alaising) on the cup rims, but it probably doesn't really exist. I think that's one of real.finder's functions.

flossy_cake

24th November 2022, 19:29

In your case there's orphaned fields so you want to treat them as interlaced, but is _FieldBased=2 just a safe assumption that could be incorrect?

I suppose it depends how reliable LWLibavVideoSource is at setting _FieldBased based on whatever metadata/flags are inside the MPEG2 stream. To be safe I'll probably do a check for _FieldBased and an additional IsCombedTIVTC check, although the latter should be sufficient most of the time.

Well here's a fun fact for you. I'm going to bang my head against the desk very hard shorty to punish myself, because I think your sample is actually soft telecine from start to finish. If you use rffmode=0 with ffms2 there's no orphaned fields on the scene changes. My guess is it's outputting 24.379fps because without FPSNum=24000, FPSDen=1001 it operates in variable frame rate mode and outputs the average frame rate, and those three frames with the same timecodes at the beginning have fudged the average. It looks like it's rffmode=1 shuffling fields around scene changes, maybe because of the first three frames, but &%$@ me! How did I not notice that until now??!?

Well, on my system with ffmpegsource2(rffmode=0) I'm still getting the orphaned field on scene change

https://i.lensdump.com/i/RRX1XC.png

Adding (fpsnum=24000, fpsden=1001) has no effect, except playback stutters for a few seconds every now and again, and the short clip isn't long enough to show it. I'm kind of at the point of giving up trying to understand what's going on under the hood with soft telecine. Although I came across this (good luck understanding it)

Some quotes from ISO 13818-2
note there are TWO different "progressive" flags

top_field_first -- The meaning of this element depends upon picture_structure, progressive_sequence and repeat_first_field.
If progressive_sequence is equal to ‘0’, this flag indicates what field of a reconstructed frame is output first by the decoding process:
In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.
In a frame picture top_field_first being set to ‘1’ indicates that the top field of the reconstructed frame is the first field output by the decoding process. top_field_first being set to ‘0’ indicates that the bottom field of the reconstructed frame is the first field output by decoding process

If progressive_sequence is equal to 1, this flag, combined with repeat_first_field, indicates how many times (one, two or three) the reconstructed frame is output by the decoding process.
If repeat_first_field is set to 0, top_field_first shall be set to ‘0’. In this case the output of the decoding process corresponding to this reconstructed frame consists of one progressive frame.
If top_field_first is set to 0 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of two identical progressive frames.
If top_field_first is set to 1 and repeat_first_field is set to ‘1’, the output of the decoding process corresponding to this reconstructed frame consists of three identical progressive frames.

repeat_first_field -- This flag is applicable only in a frame picture, in a field picture it shall be set to zero and does not affect the decoding process.
If progressive_sequence is equal to 0 and progressive_frame is equal to 0, repeat_first_field shall be zero, and the output of the decoding process corresponding to this reconstructed frame consists of two fields.
If progressive_sequence is equal to 0 and progressive_frame is equal to 1:
If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of two fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field.
If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of three fields. The first field (top or bottom field as identified by top_field_first) is followed by the other field, then the first field is repeated.
If progressive_sequence is equal to 1:
If this flag is set to 0, the output of the decoding process corresponding to this reconstructed frame consists of one frame.
If it is set to 1, the output of the decoding process corresponding to this reconstructed frame consists of two or three frames, depending on the value of top_field_first.

https://forum.videohelp.com/threads/163723-program-sequence-flag-and-program-frames-flag-always-same#post806241

As far as I know a progressive scan player would output either 23.976 or 59.97 etc, but without repeat flags it has to physically check for repeated fields and combing as plugins do and choose to de-interlace or apply IVTC on the fly.

I suspect my Sony DVD player is not analysing pixels for combing because the earlier seasons of that show are hard telecined and the Sony does mocomp deint for those (anything that moves drops to 240p). Therefore, I'm inferring that if it was obeying the repeat flags for the soft telecined seasons, then internally it would have 60i and do mocomp deint as well, but instead it outputs all frames progressively at 1080p60 and deints only those frames with orphan fields (I've stepped through frame-by-frame to observe those frames drop to 240p).

hello_hello

25th November 2022, 09:10

You're correct, there's still orphan fields. I was tired and too quick to get excited.

I've been seeing this on scene changes with rffmode=1, and when it went away with rffmode=0, I incorrectly assumed there'd no longer be orphans.

https://i.ibb.co/Lxw5MQ9/Clipboard01.jpg

Converting the frame rate with fpsnum=24000, fpsden=1001 doesn't seem to do much, but the frame count drops from 256 to 252. Naturally the frame rate changes from 24.379 to 23.976. Hopefully the glitches are only little pauses in decoding and it'll playback smoothly once it's encoded.... ummmmm sorry..... I'm used to that being the end goal... but if it's pure soft telecine rffmode=0 should give you 23.976fps and there'd be no need for ffms2 to do any frame rate conversion.

I suspect my Sony DVD player is not analysing pixels for combing because the earlier seasons of that show are hard telecined and the Sony does mocomp deint for those (anything that moves drops to 240p).

Thinking about it, maybe players do just interpolate "interlaced" fields into full frames, whether it's a hard telecined field or a video field. If not it'd have to field match first, and if it did that before weaving fields together it'd probably have to check the weaved frames for combing. I'm just guessing though as I have no idea what they do.

What about decoding this way?
Rather than obey the repeat flags, FFMS2 should decode the soft telecine sections as film while duplicating the progressive frames for 29.97fps.

Hopefully TryWeave will handle hard telecine, with TDecimate() removing the duplicates in the film sections, and if there's any video sections hiding amongst the film (opening or closing credits maybe), it'll be converted to 23.976fps using frame blending.

FFVideoSource("D:\soft telecine.mkv", threads=1, rffmode=0, fpsnum=30000, fpsden=1001)
A = last
TDeint(MI=200, TryWeave=true, clip2=A)
TDecimate(Hybrid=1)

flossy_cake

27th November 2022, 12:19

poisondeathray

28th November 2022, 04:56

It occurred to me that with 3:2 stuff containing orphaned fields on scene changes, it is logically/mathematically impossible to pull out a perfectly clean 24p. Because the source doesn't actually contain 24p, it contains 24p plus the occasional extra field here and there. This offsets the timing slightly such that over time those extra fields add up and would cause the video to go out of sync. So the only way to TFM such content is to use a final output mode of 60p -- only then we have the necessary time slice granularity to represent all images in the source without video going out of sync. Another option is to do frame blending of the orphaned field and its neighbouring 24p frame. This might be my preferred method as it avoids 3:2 judder of 60p, but I couldn't get it to work as it's implemented by TDecimate which comes after TFM, and TFM is making the decisions about orphaned field handling before TDecimate gets a chance at it.

It should be in sync - and I've never seen any those types of film (or film equivalent) based NTSC DVD's that are not because of those types of cadence interruption edits after IVTC

The "granularity" of 59.94p is potentially "finer" than 23.976p, but the running time is the same (same length as audio), and so the sync is pretty much the same (maybe a few ms difference, less than a frame duration, so not out of sync to human eyes/ears) . That interpolated 59.94p from film content actually has 3:2 duplicates, so the "granularity" isn't really better in that case (in terms of motion , or unique frames)

When you perform "normal" IVTC, the frame count @23.976p is the same whether or not you have a a) duplicate at that spot, b) or a blend, or c) a deinterlaced frame, so the timing is unchanged, sync is unchanged

The deinterlaced frame (a frame from an interpolated single field) is the best option in most cases (if a good algorithm is used) because is is an actual unique frame. It best represents what actually should have been there. Blends look bad, and duplicates aren't ideal either. Some cases where deinterlace might not be as good is if the remaining orphaned field is of noticable lower quality (e.g. at the end of a GOP, sometimes the bitrate allocation for the single field is lower than normal, it can be full of encoding artifacts - if you can't selectively clean them up, then a duplicate might look better)

flossy_cake

28th November 2022, 16:08

Sorry I should have been clearer - a sync issue would only arise if we tried to represent every unique image from the 3:2 source in the 24p output without any duplicates, skipped frames or blended frames. The point I'm trying to make is that the source isn't really genuine 24p, it's in a way "hard coded" to 60hz if you want to see every unique image in the source as it was intended to be seen. eg. if the first frame of a new scene is combed, and only contains image data from that scene, then field 1 is an orphan field and can't be matched to anything by TFM so it ends up getting removed in the subsequent TDecimate. So the first image from that new scene is actually lost, whereas if the final output is 60p, that orphaned field could have the opportunity to get deinterlaced and shown in the output.

flossy_cake

29th November 2022, 12:33

I'm kind of at the point of giving up trying to understand what's going on under the hood with soft telecine.

MPC Video Renderer's ctrl+J debug screen seems to show the frame rate changes in real time. MadVR doesn't show this and lead me into all kinds of wrong assumptions. With this clip (https://rationalqm.us/misc/lainvob.vob) for instance, MPC Video Renderer shows the frame rate actually changes between 29.97 and 23.976 dynamically depending on the scene. Sometimes it even changes between 29.97 and 29.97i as if to imply there are some frames flagged as interlaced. On top of this, the field order also changes dynamically from scene to scene, sometimes rapidly back and forth each frame! I wish I could just force it all to 29.97i TFF so I have a known quantity which I could then use TFM & TDecimate on like with normal hard telecined stuff. I've got a feeling the flags in the clip were also damaged by the software which clipped it (probably ffmpeg) as even using Bob() on it was resulting in wrong field order artefacts regardless of what field order I set. Or maybe that's an issue with the source filter, I don't really know.

flossy_cake

4th December 2022, 01:18

2:2-centric content with the occasional 1:1 scene, eg. The Office, Garth Marenghi's Darkplace

Had a look at these discs on the Sony DVD player and to my surprise it's quite bad at handling it -- the 1:1 sections are combed until there is a very large amount of motion, at which point the DVD player realises it's 1:1 and switches to mocomp deint. Then on switchback to 2:2 there is something different about the image quality, can't quite understand it. Some kind of really mild combing artefact that is almost imperceptible. It sort of looks progressive but then sort of doesn't? Can't describe it, but it's not the same clarity as the 2:2 section before the 1:1 section.

Anyway, I thought this was remarkable as the same DVD player has no trouble identifying those orphan fields from NTSC 3:2 soft telecine. I guess for NTSC content it's looking at the repeat field flags, whereas with PAL content there generally doesn't seem to be any such flags so it must be relying on trying to detect combing in the image itself (much like IsCombedTIVTC but way worse accuracy... or thresholds have deliberately been set high to maximise progressiveness on 2:2).

Genji

4th November 2023, 06:58

In TDecimate, if specify very large numbers for cycleR and cycle (ex. cycleR=7779,cycle=38895), cannot see the result on the screen.
(To begin with, setting display=true in this case will force AvsPmod to close.)

Is it possible to split the result display on the screen only, while leaving the cycleR and cycle specifications as they are?
For example, even if cycleR=7779,cycle=38895 is specified, if the screen display can show 250 frames at a time, etc., can check and make progress.

kedautinh12

4th November 2023, 07:19

You can create issue here
https://github.com/pinterf/TIVTC/issues

pinterf

10th December 2023, 11:37

Released TIVTC v1.0.28 (20231210) & TDeInt v1.9 (20231210)
https://github.com/pinterf/TIVTC/releases/tag/v1.0.28

For more details read the relevant documentations included in the packages.

TIVTC:
## TIVTC

**v1.0.28 (20231210)**
- Request #43: (https://github.com/pinterf/TIVTC/issues/43)
TDecimate debug parameters displayDecimation, displayOpt.
Able to show << or >> instead of ** on debug display by the distance from the last decimated frame compared to displayOpt.
- Fix minor display glitch (regression since v1.0.19pack): display=true would duplicate the
most bottom frame info text to the top position of the next column.

**v1.0.27 (20230511)**

- Fix #40: TDecimate: frame properties were not inherited at specific modes (20230511)
- Implement #39: CFrameDiff, FrameDiff: add offset parameter (int, default 1), to compare frames more than 1 distance away.
offset value must be >=1, already existing prevf parameter is used to set the direction.

**v1.0.27test (20220915)**
(bugfixes, frame property support backport from VapourSynth version -20220915)
- Fix: TDecimate mode 0,1 crash in 10+bits in blend (dubhater)
- Fixes in Mode 0,1 when clip2 is different format (dubhater)
- Fix: slow C code was used in calcMetricCycle.blurframe (dubhater)
- Fix: V14(?) regression TDecimate fullInfo was always false (dubhater), ("Don't know what it affected")
- MacOS build fixes (akarin)
- mingw build fixes
- Source code: refactorings, backported from VapourSynth port (dubhater, https://github.com/dubhater/vapoursynth-tivtc),
- Source code: backport other simplification changes.
- Frame properties (priority over burned-into-image hints). Similarly to bitmapped hints, they are used when parameter "hint" is true.
Frame properties set by TFM: TFMMatch, _Combed, TFMD2VFilm, TFMField, TFMMics, TFMPP
Frame properties read by TFM and TDecimate: TFMMatch, TFMD2VFilm, TFMField
Frame properties read by TFMPP: TFMField, _Combed
Frame properties read by TDecimate creation: TFMPP (but if Avisynth variable "TFMPPValue" exists then the variable has priority over it)
Frame properties never read: TFMMics
Traditionally, TFM is using a 32 bit "hint" encoded in the lsb bits of the first 32 pixels of a frame.
When Avisynth interface V8 is available, then frame properties are used instead of the image destructing bit hints.
- Bitmapped hint replacement frame property names are: TFMMatch, _Combed, TFMD2VFilm, TFMField.
Mapping:
Bits 0-2: (ISP, ISC, ISN, ISB, ISU, ISDB, ISDT) are filled upon match (TFMMatch) and combed (_Combed) and field (TFMField)
ISP: match == 0
ISC: match == 1 && combed < 2
ISN: match == 2
ISB: match == 3
ISU: match == 4
ISDB: match == 1 && combed > 1 && field == 0
ISDT: match == 1 && combed > 1 && field == 1
Bit 3: set to 1 if field == 1 (TFMField 0 or 1)
Bit 4: set to 1 if combed > 1 (_Combed)
Bit 5: set to 1 if d2vfilm is true (TFMD2VFilm)
- Other frame properties:
TFMMics: array[6] of integer
TFMPP: integer
Frame properties set by TDecimate:
TDecimateCycleStart (not used)
TDecimateCycleMaxBlockDiff uint64_t[] (not used)
TDecimateOriginalFrame (not used)
_DurationNum, _DurationDen (not used yet, for variable frame rate (?), backport from VapourSynth port is in progress)

TDeint

## TDeint
**v1.9 (20231209) - pinterf**

- Fix C reference code of YUY2+luma-only: check_combing_c_Metric1 metrics
Probably no one had problems with it on Intel, since it's implemented in SSE2 as well.

hello_hello

11th December 2023, 15:19

Released TIVTC v1.0.28 (20231210) & TDeInt v1.9 (20231210)
https://github.com/pinterf/TIVTC/releases/tag/v1.0.28

Thanks!

FranceBB

15th December 2023, 22:26

Thank you as always, Ferenc!
I actually followed the whole discussion on GitHub that led to this build (until you closed the issue) as I was getting the notifications via email (although I didn't reply) and it's highly appreciated. ;)
I just swapped it on prem in prod the other day on Windows Server 2019, while on my PC I can say that it works just fine on XP.
It will also be included in the upcoming FFAStrans 1.4.0 due to be released on Christmas Day. :)

pinterf

22nd December 2023, 19:22

Ikotas has published a nice detailed guide for IVTC from 29.97fps to 25fps utilizing TDecimate.
Activation emails are kinda slowish here at doom9, so I was asked to help in publishing.

Here it is (in Japanese)
https://ikotas.github.io/25fpsIVTCGuide/

And in English - easy-click-version - for those without auto-translate:
https://ikotas-github-io.translate.goog/25fpsIVTCGuide/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_pto=wapp

Thanks to Ikotas for taking the time to prepare this description.

Micheal813

26th December 2023, 00:49

I have some mpg video that is mostly hard telecined to play at 29.97 fps. There are some small sections that are just progressive 29.97 fps. I index it with DGIndex and it shows 100% video.

If I use this script and go frame by frame in VDub, some sections show pattern AABBCCDD (Progressive?) and some show AABBBCCDDD(Hard Telecine?).

mpeg2source("path\to\video.mpg")
AssumeTFF()
SeparateFields()

I'm using this script for the final product:

mpeg2source("path\to\video.d2v")
TFM(d2v="path\to\video.d2v")
TDecimate()

Is this correct? It seems to work and convert everything to 23.976, but just wanted to check.

Thanks

FranceBB

26th December 2023, 21:35

I have some mpg video that is mostly hard telecined to play at 29.97 fps. There are some small sections that are just progressive 29.97 fps.

You have two paths in front of you:

Option A) You deinterlace everything, so that the telecined parts will be duplicated to 29.970p but you'll save the progressive ones

Option B) You IVTC everything to 23.976p so that the telecined parts will be 23.976 and the progressive parts will be decimated to 23.976p

I'm using this script for the final product:

mpeg2source("path\to\video.d2v")
TFM(d2v="path\to\video.d2v")
TDecimate()

Is this correct? It seems to work and convert everything to 23.976, but just wanted to check.

Yes, that's option B, it will IVTC the telecined parts and decimate the progressive ones so that you're gonna get 23.976p in the end.

To be absolutely fair, I don't know what I would personally do. I had to make this decision long time ago with animations which were hard telecined in the normal parts ('cause animating stuff costs money) with 3 "good" and 2 repeated,
3 good and 2 repeated, 3 good and 2 repeated etc and 29.970p parts whenever a panning was occurring ('cause panning is done by a computer, so it didn't cost any money). I actually decided to go with option A and preserve the 29.970p parts by duplicating the 23.976p ones. This was back when I was working at Viewster after moving away from Crunchyroll, so around 2015.

Micheal813

26th December 2023, 22:33

You have two paths in front of you:

Option A) You deinterlace everything, so that the telecined parts will be duplicated to 29.970p but you'll save the progressive ones

Option B) You IVTC everything to 23.976p so that the telecined parts will be 23.976 and the progressive parts will be decimated to 23.976p

Yes, that's option B, it will IVTC the telecined parts and decimate the progressive ones so that you're gonna get 23.976p in the end.

To be absolutely fair, I don't know what I would personally do. I had to make this decision long time ago with animations which were hard telecined in the normal parts ('cause animating stuff costs money) with 3 "good" and 2 repeated,
3 good and 2 repeated, 3 good and 2 repeated etc and 29.970p parts whenever a panning was occurring ('cause panning is done by a computer, so it didn't cost any money). I actually decided to go with option A and preserve the 29.970p parts by duplicating the 23.976p ones. This was back when I was working at Viewster after moving away from Crunchyroll, so around 2015.

Thank you for the help. What would the script for option A look like?

FranceBB

27th December 2023, 00:36

What would the script for option A look like?

A simple tdeint should suffice:

MPEG2Source("video.d2v")

tdeint(mode=2, order=-1, field=-1, mthreshL=6, mthreshC=6, map=0, type=2, debug=false, mtnmode=1, sharp=true, cthresh=6, blockx=16, blocky=16, chroma=true, MI=64, tryWeave=true, link=1, denoise=true, slow=2)

kedautinh12

3rd March 2024, 02:10

TIVTC v1.0.29 (20240302) (https://github.com/pinterf/TIVTC/releases)

FranceBB

3rd March 2024, 14:33

Yep, TDecimate() is now populating frame properties correctly.
Another tiny step forward.
At this point it's been a while since frame properties were introduced alongside the old clip properties but we're still finding those things and filters/functions not handling them correctly.
I feel like the migration to frame properties in Avisynth will probably end up the same as the migration from 16bit stacked / interleaved to 16bit planar (i.e slowly lots of functions/plugins will use them, but there will forever be exceptions that will have to be handled manually with propSet()... :( )

pinterf

4th March 2024, 11:34

TIVTC 1.0.29 (https://github.com/pinterf/TIVTC/releases/tag/v1.0.29) released with flossy83's additions.

(20240302)
- TDecimate: allow noblend=true when hybrid=1, noblend default value is false when hybrid=1 to keep
backward compatibility. (flossy83)
- TDecimate to fill new frame properties. (flossy83)
TDecimateCycleMetrics, TDecimateCycleMetricsPrev, TDecimateCycleMetricsNext (float arrays),
TDecimateCycleFrameNums, TDecimateCycleFrameNumsPrev, TDecimateCycleFrameNumsNext (int arrays),
TDecimateCycleBlendStatus
See #48: https://github.com/pinterf/TIVTC/issues/48
- Fix #46: TDecimate(hybrid=3) blending with wrong frame. (flossy83)
https://github.com/pinterf/TIVTC/issues/46

(from TDecimate - READ ME.txt):

Frame properties set by TDecimate (since TDecimate v1.0.11, pack v1.0.29):

TDecimateCycleMetrics (float array): normalised metrics for all frames in current cycle
TDecimateCycleMetricsPrev and TDecimateCycleMetricsNext: same as TDecimateCycleMetrics but for previous/next cycle

TDecimateCycleFrameNums (int array): frame numbers corresponding to TDecimateCycleMetrics
TDecimateCycleFrameNumsPrev and TDecimateCycleFrameNumsNext: same as TDecimateCycleFrameNums but for previous/next cycle

TDecimateCycleBlendStatus (integer): indicates if frames in the current cycle are blended:
-20=undefined,
0=not blended,
1=blended,
2=not blended due to scenechange,
3=not blended due to 2 dup cycle workaround

Example usage:

ScriptClip("PrintProps(last, current_frame)", after_frame=true, local=false)
function PrintProps(clip c, int current_frame){
metrics = propGetAsArray(c, "TDecimateCycleMetrics")
fnums = propGetAsArray(c, "TDecimateCycleFrameNums")
blendStatus = propGetAny(c, "TDecimateCycleBlendStatus")
s = ""
for (i=0, ArraySize(metrics)-1) {
s = s + "Frame " + String(fnums[i]) + ": " + String(metrics[i], "%0.2f") + "\n"
}
s = s + "Blend status: " + String(blendStatus) + "\n"
c.Text(s, lsp=0, align=7, size=20, bold=true)
}

and change in noblend:

noblend -

With hybrid = 0 or 1 there is a special case when tdecimate will use blend decimation, and
that is when it detects two duplicates in a cycle, cycleR=1, and neither duplicate is next
to a scenechange. In such cases tdecimate will drop one of the duplicates and replace the
other with a blend of its neighbors. The "noblend" parameter is used to disable this behaviour.

From TDecimate v1.0.11 (pack *v1.0.29) noblend has effect for hybrid = 1, for backward
compatibility its default value is different for hybrid = 0 and 1.

true - no blending in the two duplicate case when hybrid = 0 or 1
false - use blending in the two duplicate case

Default: true (bool) when hybrid = 0, false (bool) when hybrid = 1

Matching_Mole

7th August 2024, 15:06

I'm currently using TFM/TDecimate with Avisynth Filter (and Avisynth+) to perform on the fly IVTC with some of my japan bluray and DVD. So I'm trying to optimise my script as the rendering time is critical in this case.

Where I'm quite lost is regarding SetMTMode. It seems that TFM, to perform the field matching, can't use it or in serialised mode which is not the better mode. Is it true or does SetMTMode or Prefetch could be useful to optimise my rendering time?

So far, the betters options to optimise TFM seems to be slow and PP (the encoding of my bluray seems pretty clean and sometime no PP seems required). AssumeTTF (or BFF but I didn't see any occurence for the moment) help also. Does any other options I should considerate to optimise the rendering time?

Thanks in advance!

Boulder

7th August 2024, 15:15

IIRC TDecimate is the one that doesn't like multithreading and automatically uses the serial mode, so maybe you could try placing Prefetch right after TFM for best results.

Matching_Mole

7th August 2024, 19:44

Thanks, I will try.

tormento

10th December 2025, 14:13

There is something about TDeint versions that I can't understand.

The last version I can find on Pinterf repo is 1.9 BUT reading README.md inside TIVTC-1.0.30 I can see:

# TIVTC and TDeInt

Current versions:

- TIVTC: v1.0.30 (20251210)
- TDeint: v1.10 (20250519)

Where is 1.10? :)

Jamaika

10th December 2025, 15:27

Really. Mine is fine.:D
#define TFM_VERSION "v1.0.30-9254cac"
#define TDEINT_VERSION "v1.10-9254cac"
#define TDEINT_DATE "12/10/2025"
https://www.sendspace.com/file/ko4smv

real.finder

10th December 2025, 15:34

Where is 1.10? :)

https://github.com/pinterf/TIVTC/issues/57#issuecomment-2888531564

tormento

10th December 2025, 15:39

https://github.com/pinterf/TIVTC/issues/57#issuecomment-2888531564
Great, thank you!

pinterf

10th December 2025, 22:00

Great, thank you!
What, I did not create official TDeint 1.10? Uh-oh :) Tomorrow's task.

hello_hello

11th December 2025, 03:03

I've been wondering about TFM's combing detection, as when I've compared it to TDeint, the areas they detect as combed are often very similar, but compared to TDeint, TFM often seems to want to de-interlace the entire frame more than I think it should.

The last video I experimented with was telecined, and I used the following script to compare what TFM and TDeint had decided should be de-interlaced in each frame.

mpeg2source("O:\SampleFile2.d2v")
L = Last
D = BlankClip(L, color=color_red)
TF = TFM(clip2=D)
TD = TDeint(edeint=D, TryWeave=true)
StackHorizontal(TF, TD)

Sometimes one of them will decide it's detected combing in areas where another doesn't, but often the result is fairly similar, such as in the example below.

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

But with almost every video I've tried, there'll be many frames where TFM feels the need to de-interlace the whole picture while TDeint does not. Often when that happens, the mask TFM creates even includes pure black borders, which I wouldn't think could be combed, hence my wondering if TFM's combing detection is behaving correctly, or does it have some sort of built in threshold that when it's exceeded, causes TFM to just de-interlace everything?

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

This is the video used for the screenshots above. It was uploaded by someone at VideoHelp as it has issues unrelated to my question, but it still serves as an example of the difference between TFM and TDeint. I'm using TIVTC 1.0.29.

SampleFile2.ts (https://files.videohelp.com/u/210984/SampleFile2.ts)

pinterf

11th December 2025, 08:19

1.0.30 pack is updated with TDeint 1.10.
https://github.com/pinterf/TIVTC/releases/tag/v1.0.30

FranceBB

23rd December 2025, 15:07

Thanks for the new release, as always, Ferenc.
Tested and working on Windows XP Professional x86 and Windows Server 2019 Standard x64. :)

flossy_cake

23rd December 2025, 20:25

I've been wondering about TFM's combing detection, as when I've compared it to TDeint, the areas they detect as combed are often very similar, but compared to TDeint, TFM often seems to want to de-interlace the entire frame more than I think it should.

Yes I observe the same issue with TFM's PP and that's precisely why I stopped using it and just use IsCombedTIVTC() insided a ScriptClip afterwards.

I haven't looked at the TFM code but my suspicion is that PP has some logic that sometimes forces all pixels to get deinterlaced (or should I say top field is duplicated into the bottom field?) to help with metrics in case bob shimmer on high contrast details would interfere with duplicate detection for TDecimate.

I don't know if that is the real reason for it without looking at the source code but that is my guess.

hello_hello

9th January 2026, 18:22

Following up on my earlier post (https://forum.doom9.org/showthread.php?p=2025967#post2025967) I played around a little more comparing ShowCombedTIVTC() with TFM() as I assume they should agree on which pixels are combed, given that's the purpose of ShowCombedTIVTC.

The help file seems to suggest that ShowCombedTIVTC should be used on it's own, but it doesn't field match, so I also added a comparison with TFM(pp=0).ShowCombedTIVTC(). If there's only a single problem it appears to be with the creation of the mask used when taking the pixels from a second clip, but someone more cleverer than me will have to look at this.

The clips used for comparisons, along with the source:

White = BlankClip(Last, color=color_white)
TFMatched = TFM(display=true, clip2=White)\
.Subtitle("TFM(clip2=White)", align=5, size=70)

SC1 = ShowCombedTIVTC(fill=true, display=0)\
.Subtitle("ShowCombedTIVTC()", align=5, size=70)
SC2 = TFM(pp=0).ShowCombedTIVTC(fill=true, display=0)\
.Subtitle("TFM(pp=0).ShowCombedTIVTC()", align=5, size=70)

then

StackVertical(\
StackHorizontal(Last.Subtitle("Source", align=5, size=70), TFMatched), \
StackHorizontal(SC1, SC2))

The result I expected was for clip "SC1" to show lots of combed pixels for frames where the fields don't match up, but for clip "SC2" to show far less after successful field matching, and that was usually the case. I also expected clips "SC2" and 'TFMatched" to generally be in agreement as to which parts of the picture were combed. Sometimes that's true, but often SC2 shows fine combing that TFM ignores (declaring the frame to be progressive), or according to the mask it creates, TFM thinks there's lots more combed pixels than ShowCombedTIVTC does.

Pic #1 shows ShowCombedTIVTC finding some combing that TFM does not. Display=true shows the clip to be clean for TFM.

Pic #2 is frame #203 and shows nothing unusual. It's included to show the movement between frames 203 and 204.

Pic #3 is frame 204. It's progressive, although ShowCombedTIVTC shows a little combing in places.
TFM(display=true, clip2=White) is quite odd for the same frame. The text appears to be overlaid twice using frame numbers 203 and 204, and the mask being created seems to be the result of the movement of objects between frames (as though TFM looked for combing and created the mask before it field matched, while using a field from the wrong frame). That sort of thing doesn't happen all the time, but I'm pretty sure it happens regularly throughout the video.

Pic #4 is also frame 204, but without the clip2 argument. With the clip2 argument removed it all looks normal.

Pic #5 is frame 205. One of the many frames TFM would de-interlace entirely when the clip2 argument is used, even though the frame is progressive and ShowCombedTIVT doesn't find much combing.

The video used for these screenshots is the one I linked to in post #1692 (https://forum.doom9.org/showthread.php?p=2025967#post2025967).
Each pic contains four 1080p images stacked together so I've zipped them up.

TFM ScreenShots.zip (https://files.videohelp.com/u/210984/TFM%20ScreenShots.zip) (3 MB)