TDeint and TIVTC

[Fizick]

tritical,
thanks for update!

May be somebody can help you with html doc,
in order to you concentrate on programming?

[aichan]

@tritical

oh..okay.. i see now about it.

i'll try to mux it to mkv later..

thx :)

[DarkNite]

@malouf

Some things you could try are the functions mentioned previously in this thread using eedi2 in cunjunction with tdeint.

If all else fails: I use FreezeFrame (http://www.avisynth.org/FreezeFrame) for issues where I know the frames that are consistently giving me problems (or rather giving the automated solution problems). Then again, I'm used to using YATTA and most people just aren't that masochistic. FreezeFrame would be used best after deinterlacing and before anything else.

In bad game captures I would use it before the motion blur to replace the usual junk frames here and there with the previous or next frame. If it's a duplicate frame or static scene no one will ever know, but if it's a hard panning sequence it may introduce a stutter.

[malouf]

Hi,

I tried the method with eedi2 and tdeint, it produces the same artifacts at the same place...

And for freezeframe, the problem is that I need to have something that works automatically on every video, I make lots of videos, and don't want to review them frame by frame to correct them :-(

The ideal solution would be that tdeint, before deinterlacing, checks if the current interlaced frame is perfectly identical to the previous one. If it is identical, just output again the last progressive frame. I guess it wouldn't be difficult, but maybe I'm mistaken ?

I can post a small part of one of the videos that has the problem, maybe it would be more clear?

[johnmeyer]

[See last line of post, if you don't have time to read all this].

I am getting occasional failures in the TFM v0.9.12.1 matching. I have tried every mode, each option for slow, and each option for micmatching. What happens is that the MICS parameters show, for example

p=0, c=5, n=25, b=4, u=0

yet TFM chooses the current rather than the previous field. 99.9% of the matches are correct. Here is the script:

converttoYUY2(interlaced=false)
AssumeBFF()
colorYUV(autogain=true)
tfm(display=true,micout=2,mode=7,cthresh=115,mi=35,pp=1,field=0,metric=0,micmatching=3,slow=1,sco=-1,debug=false)

and here are two frames that are at the same point in the cadence. The first one shows TFM not doing what I want it to do; the second shows what I think is the correct operation:

[1568] TFM: mode 7 - non-linear access detected!
[1568] TFM: frame 10693 - comparing c to p (SLOW 1)
[1568] TFM: frame 10693 - nmatches: 547252 vs 827794 (1.5) mmatches: 106221 vs 128984 (1.2)
[1568] TFM: frame 10693 - match c: Detected As NOT Combed! (6 <= 35)
[1568] TFM: frame 10693 - match p: Detected As NOT Combed! (0 <= 35)
[1568] TFM: frame 10693 - final match = c MIC = 6
[1568] TFM: frame 10693 - mics: p = 0 c = 6 n = 256 b = 256 u = 0
[1568] TFM: frame 10693 - mode = 7 field = 0 order = 0 d2vfilm = F
[1568] TFM: frame 10693 - CLEAN FRAME


[1568] TFM: mode 7 - non-linear access detected!
[1568] TFM: frame 10704 - comparing c to p (SLOW 1)
[1568] TFM: frame 10704 - nmatches: 1186349 vs 1009180 (1.2) mmatches: 583070 vs 500389 (1.2)
[1568] TFM: frame 10704 - match c: Detected As NOT Combed! (10 <= 35)
[1568] TFM: frame 10704 - match p: Detected As NOT Combed! (5 <= 35)
[1568] TFM: frame 10704 - final match = p MIC = 5
[1568] TFM: frame 10704 - mics: p = 5 c = 10 n = 256 b = 256 u = 0
[1568] TFM: frame 10704 - mode = 7 field = 0 order = 0 d2vfilm = F
[1568] TFM: frame 10704 - CLEAN FRAME


As you can see, in the first case (frame 10693), p=0 and c=6, yet TFM chooses c. In the second case c=10 and p=5, and it correctly chooses p.

...

I just took a break before posting and looked some more. I think that any time either c=0 or p=0, TFM makes the wrong choice. It is as simple as that. Let me know if this is correct.

[Edit] Update a few minutes later. My input is NTSC DV (BFF). However, I tried changing field to field=1, and it seems to work better. So, field=0 and also field=-1 preceded by AssumBFF() both create the problem.

[tritical]

@malouf
The problem is that tdeint's motion check is only 5 fields, 2.5 frames, so if an interlaced frame is repeated one time the chance that interlaced areas will be declared static and weaved is high. If such a frame is repeated twice then it will definately be declared static. Having tdeint check for absolutely identical frames and consider all pixels to be moving would prevent the artifacts, but definitely wouldn't be good for normal operation. You could try using securedeint() which produces longer temporal masks (which should prevent the problem)... or you might be able to hack up a function in avisynth that checks difference to previous frame and if it is zero replaces the frame will all white (255), which should make it be detected as moving.

@Fizick
If someone wanted to help on the docs I definitely wouldn't say no :D. So far I have manged to convert most of the stuff for tivtc except for the two biggest readmes (tfm/tdecimate).

@johnmeyer
Would you be able to post a clip that I could test with? Your settings seem strange off hand... specifically mode 7 and cthresh=115. Also, the MIC values aren't normally used for selecting matches, but only for determining which frames are combed. The nmatch/mmatch numbers generated by the field matching routine are what determine which match is chosen (lower is better). With micmatching enabled the MIC's can override the match decision, but the 0 vs 6 difference in the first example isn't large enough to trigger it (with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).

@All
I found another little bug in eedi2 that could occasionally cause an access violation by reading/writing 8 bytes past the end of a buffer. The affected routine is only used if the input is yuy2 and the cpu supports sse2. I'll try to put up a fix sometime soon.

[johnmeyer]

Would you be able to post a clip that I could test with?
Here is a link (good for seven days) to a short DV AVI clip, along with the script I am currently using:

http://download.yousendit.com/16F3395A7B1B6689

Frame 9 is where the problem occurs. If you change the Field parameter from 0 (which is where I think it should be for NTSC DV) to 1, TFM works.

Your settings seem strange off hand... specifically mode 7 and cthresh=115.
Yes, I have changed those. If you look at the script in the above download, the TFM line that is commented out that is directly above the one that I made active just for your testing, is the one I'm actually using now. The reasons for the strange settings is that this is the script for recovering matched fields from my film to video transfer device (see my earlier posts). With this device, I will get two good fields for every frame of film. The next field will either be a field captured during pulldown, or will be a third matching field. If it is a field captured during pulldown, the resulting frame will appear combed. I throw that out.

(with blockx/blocky=16 a difference of at least 15 between the selected match and the match with the lowest mic value is needed to even consider changing it).
Would it be better to use blockx/y = 4?

I actually made a test DVD last night, and I almost have this working. I export the TFM parameters in pass one, import it to Excel, and use Excel formulas to look at the TFM values to create a decimate file. In pass 2, I feed that file to Multidecimate, and feed the almost-unaltered (after removing the CRC line -- thanks for that hint) pass-1 TFM parameters file back into TFM.

In the second pass, I remove the "colorYUV(autogain=true)" line.

Speaking of autogain, for anyone reading this thread, I found -- at least in my application -- that using autogain makes a HUGE improvement in the consistency of TFM's matching. Many of the movies I am transferring consist of poorly exposed, low contrast footage, and as the exposure and contrast changes, so do the TFM matching parameters. Using Autogain equalizes things sufficiently that I can use one script for the entire reel of film.

In fact, the improvement is so good that I suggest that if there is a way to feed an autogain version of a clip to one instance of TFM, and then have the resulting parameters be used by a second instance of TFM to actually operate on the clip it might be a very worthwhile addition. This way it wouldn't require two passes (although my application will still require a second pass because I don't have a predictable "n of m" decimation pattern).

In summary, now that I understand that MICmatching requires a bigger difference, I can try to deal with that, so I guess you don't need to look into that any further. However, I still think that there is something strange going on with the Field= parameter. I get all sorts of combing artifacts with Field=0, and none with Field=1, even though I am using a DV source.

Finally, I have read your documentation 100 times, and read through every post in this thread, but I can't find the answer to this:

What does "MIC" stand for?

[HOLiC]

Hello, I'm trying to encode hyrid video to mkv-vfr using megui as an encoder, and Tivtc filter. But I'm having a problem using one pass method as you can check in this post:
http://forum.doom9.org/showthread.php?p=814055#post814055

I don't know the reason for this error message in megui, but using two pass method, i was able to open the script via megui!!

in your read me:

7.) NTSC, two pass (enables use of conCycleTP parameter) mkv vfr for hybrid source.

First pass:

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",output="matches.txt")
tdecimate(mode=4,output="metrics.txt")

Second pass (anime or cartoon):

mpeg2source("c:\oursource.d2v")
tfm(d2v="c:\oursource.d2v",input="matches.txt")
tdecimate(mode=5,hybrid=2,vfrDec=1,input="metrics.txt",tfmIn="matches.txt",mkvOut="mkv-timecodesfile.txt")


I understand that I have to play the first pass to get the metrics, and then encode using second pass script.. What I don't know is.. is it okey if my output file is mp4? (but I plan to mux with aac, and timecode to MKV using mkvmerge) Or do I need to make output file to mkv right away? And I also plan to do 2pass encoding, and I read in the avisynth site, that vfr encoding will mess up the bitrate calculation..? Is this still apply?


from: http://www.avisynth.org/VariableFrameRateVideo

If you're encoding to a specific size using a bitrate calculator, vfr decimation will mess up the calculations. To make them work again add these to your script:

Before decimation:

oldcount=framecount # this line must be before decimation
End of script:

oldfps=framerate
averagefps=(float(framecount)/float(oldcount))*oldfps
assumefps(averagefps).Nicefps()


Do I have to apply above script if i want to do 2pass mkv-vfr encoding? but I tried nicefps(), and it just gives me an error message. Any feedback would be great! Thanks!!

[foxyshadis]

You don't need nicefps (which is a separate plugin, see warpenterprises) starting with Avisynth 2.5.7 alpha. All that part does is extend the length of your newly decimated video to be exactly as long as your old video, so that all bitrate calcs are kept in sync, so yes, unless you want to do the algebra yourself every time (or use a quality-based encode), you do need that, whether 1 or 2 pass.

You can output mp4, but you still have to mux to mkv. But see the updated version of the guide (http://www.avisynth.org/mediawiki/wiki/VFR) for a few more options if you want to end up in mp4.

1-pass vfr can't be seeked into, and megui always seeks to the middle frame if you open the preview, so set it to not open the preview and you should be okay. Another problem is you can't really correct the bitrate skew in 1-pass mode, so you might have to go quality-based for that.

[foxyshadis]

I'm just kind of curious, but what sort of improvements are in store for eedi? Anything I should wait around on, or just minor speed/quality tweaks? (I've been using it a lot lately on some too-small stuff, helps a lot.)

[HOLiC]

You save me again, foxyshadis!! :thanks:

[Fizick]

tritical,
again about html doc.

Do you know, that avisynth 2.56 includes Tdeind and TIVTC html doc ? :)
(outdated a little, of course, but formatted).

[swaaye]

I'm getting an error with TFM "Illegal Transitions found in dvd2avi file". It makes me a "fixed" file that still gives the error. 2 out of about 15 episodes have this issue, using identical settings.

edit: I think the fixed file is working after all.

[tritical]

First, sorry for the lack of responses... I've got a big project due in two weeks and I'm having to spend insane amounts of time on it.

@swaaye
It appears your problem was fixed? If you do have a d2v file that tfm generates a fixed version of and then says something is wrong with the fixed version could you post it somewhere?

@Fizick
Yep, I know that tdeint/tivtc html docs already exist.. I've been using those as the basis for the new ones (updating, rewriting, and layout changes).

@foxyshadis
The main changes are to making it more stable with larger search areas (new default for maxd will be 24) and better at connecting lines with very small slopes. I've changed some hard thresholds to relative thresholds based on the angle direction and added an extra gap/hole filling routine to the edge map filtering and directon map filtering. Due to the new defaults and extra processing it is a little bit slower.

@johnmeyer
I'll try to look at the clip tommorrow though it sounds like you've found a method to accomplish what you need. The problems you have with the field parameter may be related to using mode 7 in tfm. In mode 7 tfm internally switches the field parameter between 0/1 (it starts out on the initially set value) based on combed frame detections to try and follow a specific pattern found in some field blended material. In almost all other cases you want to always match of the same field to maintain smoothness. Try using matching mode 0 or 1 and setting field=0 and then field=1.

I guess MIC stands for "max (or maximum) interlacing count". Originally, tfm never kept track of the "MIC" value it just checked to see if any of the blocks in the image produced counts over MI. When I decided to start keeping track of the values I just added C onto MI to get MIC for a new variable name.

[johnmeyer]

I gave up on mode 7 shortly after my post and have been using mode 0. Still haven't been able to get reliable detection in low motion areas. However, I am now trying to create my own decimation routine that uses a form of guidance that is based on my unusual application. I'll post back here when I've either got it working, or have another question.

[Alizar]

Tritical:

I'm sorry to bother you, but I've noticed a weird output bug with tdecimate. Sometimes it simply refuses to write out the stats using mode=4 and specifying an output file. I run the pass to collect the stats, the file is created, but it stays blank. Any notion what I might be doing wrong?

[foxyshadis]

The file won't be flushed until virtualdub (or whatever is running the pass) is closed. Closing the video with ctrl-W and reopening off the recent menu is what I always do. Must have the biggest buffer in the world or something...

[JuanC]

TDecimate request: exclusion band of lines (y0/y1) as in TFM.
Hi Tritical, This is a humble request: I regularly do NTSC analog TV captures that are telecined material broadcasted with the original audio and the subtitles (interlaced!) with the translation blended on top of the telecined material. The exclusion band of lines (y0/y1) for TFM has allowed me to successfully match the fields correctly. This is great! But the subtitles are still causing me problems with TDecimate:

After using TFM, the telecined material is correctly matched, but almost every frame where each subtitle starts or ends (only the first and last frames where the subtitle appears) is detected as combed because of the subtitles. These “combed” frames (2 on each subtitle, with 2000+ subs gives more than 4000! on a 20 minutes capture) interfere with TDecimate metrics calculation resulting in the wrong frames being deleted, and if hybrid > 0 with unnecessary 30p to 24p frame blending processing.

I have also tried setting PP=0 and hints=false, but the metrics calculation on TDecimate gets confused by the subtitles, particularly if the subtitles starts or ends exactly on a duplicated frame (the ones that should be decimated).

Last night I discovered “MergeHints” on your TIVTC package, which allowed me to get better results by excluding from the TFM hints generation the lines where the subtitles are, using this AVIsynth script: (704x480 yv12 material)
Save_Hints=crop(128,64,480,288,align=true).Tfm(order=1, mode=0, PP=0)
Tfm(order=1, mode=0, y0=352, y1=448, PP=6, Hint=FALSE, opt=3) #, display=true)
MergeHints(hintClip=Save_Hints)
TDecimate(Hint=true, opt=3, hybrid=0) #, display=true)
One could of course get these or better results, easier and a lot faster, if there was an option in TDecimate to exclude lines that contain the subtitles when doing the metrics calculation, just like it is in TFM.

I hope you’re doing well with your project, and I’d like to thank you for the time and energy you devote to this filters you give us all.

Regards, JuanC

[minos5000]

I've a question concerning the speed. I use these settings for VDub to convert my captured movies into Xvid


LoadPlugin("c:\avisynth\dgmpgdec146b2\DGDecode.dll")

audio=MPASource("c:\Charmed.-.S03E04 T01 DELAY 96ms.mpa")

video=MPEG2Source("c:\Charmed.-.S03E04.d2v")

video=TDeint(video,order=1).lanczos4resize(720,540)

AudioDub(video,audio)



The quality is really great but I'm not so happy with the perfomance as it dropped by 50% from 30fps to about 16fps. Ist this loss normal or are there any improvements possible?


so long

[scharfis_brain]

every filter has an impact on encoding speed.
so will tdeint.

and 16fps still are a reasonable good speed.

So it seems you never got into the range of spf for your encoding speeds (spf == seconds per Frame)

[foxyshadis]

If your system can't handle realtime tdeint, try leakkerneldeint. It's much simpler and faster, even though it tends to have more issues than tdeint.

A couple of ways to speed up tdeint are, use mtnmode=0 or 2, denoise=false; you should try mtnmode first.

[tritical]

@Alizar
As foxyshadis said, the file is created in tdecimate's constructor, but the data isn't actually written into the file until the tdecimate object is destroyed (happens on script close). The main reason for doing it that way is that it ensures the metrics will be in order even if frames aren't requested in linear order. That point doesn't really matter for reading the data back in, but it helps if you want to manually examine the stats file. I could change it to write to the file each time a frame is processed, but I don't see any real advantage... if you want to see the results for a frame immediately use the display option.

@JaunC
An exclusion band for tdecimate is a good idea... though it's a little more tricky to do than for tfm. The other issue brought up by your example is that the y0/y1 bands in tfm currently only effect field matching comparisons and not combed frame detection which doesn't make sense. I'll change that in the next release.

[foxyshadis]

Alizar told me offline that it actually wouldn't write the stats even after closing, even after multiple open-play-close cycles, so I'm afraid it was something else. No error message came up.

[tritical]

I take it that there isn't a set of steps that always cause the problem? I've personally never had it happen. The only thing I can think to do is put up a special build with some extra debug output to see what happens. I'll try to put one up later tonight.

EDIT:
Test Build (http://bengal.missouri.edu/~kes25c/TIVTC.dll)

Just have debugview open to catch the output strings and post the log here or pm it to me... it should show why it is failing.

[johnmeyer]

Say, if you're going to do anything with extra debug output, is there any chance that you could include a "verbose" function for the output file that would include the MIC values? Currently I am having to output via the debug mode and then parse that file to get both the p, n, c decision made by TFM, along with the MIC values. In my application, I have created an external parsing application that looks at the MIC values and uses that to determine where to override the TFM decisions. This is not a huge deal, but it would save me some extra work of parsing the debug file. What I am proposing is taking the current TFM Output file that looks like this:
31 n - [56]
32 c - [8]
33 c - [0]
34 n - [3]
and add the MIC values:
31 n - [56] 96 83 56 0 104
32 c - [8] 104 8 71 56 61
33 c - [0] 61 0 20 71 91
34 n - [3] 91 79 3 20 56

[JuanC]

@JuanC An exclusion band for tdecimate is a good idea... though it's a little more tricky to do than for tfm. ... It's great you like the idea. I hope there could be a chance for it in the future. @JuanC ... The other issue brought up by your example is that the y0/y1 bands in tfm currently only effect field matching comparisons and not combed frame detection which doesn't make sense. I'll change that in the next release. You know, I found it convenient, so that I can use PP=6 to deinterlace the subtitles at the first and/or last frame(s) where they appear. Is there a chance 'combed frame detection' could be optional for the exclusion band ?

Thanks for your comments, Juan

[tritical]

@johnmeyer
Yep, I can add that.

@JuanC
I'll make using the exclusion band in combed frame detection optional.

I'm still busy working on stuff for school, but should finally have free time next week to do some work on tivtc.

[swaaye]

either TFM or TDecimate is crashing on me for the first ep of Stargate SG-1. It will run for a few mins of the D2V but then the encode will just stop and Staxrip will move to the next pass and this will stop out too. I switched to telecide/decimate and that works so it must be a TIVTC bug. Can I send anything to help with this?

I've also been having a problem with a interlaced frame sneaking in after every scene change. Telecide/Decimate seem to not have this problem. I read that it could be a frame order switch problem with the DVD.


tfm(d2v="%source_file%")
tdecimate(hybrid=1)


vs. (didn't bother setting it up properly for hybrids cuz it isn't very good at that anyway)

Telecide(guide=1).Decimate()

[tritical]

If you could post a clip that causes a crash it would help. Otherwise, I have no idea where to start looking for a bug. Also, does it crash if you open that script with only tfm+tdecimate in vdub and encode? If so, then try taking out tdecimate and see if it still crashes (would at least narrow it down to either tfm or tdecimate).

If combed frames are getting through then you need to tweak the combed frame detection settings (MI, cthresh)... using display=true in tfm will help.

[swaaye]

Well it's TFM that's crashing. With just MPEG2Source and TFM in the filter stream, the clip will crash within 20 seconds of the show. I'm not really sure how to send you a part of the VOBs though....

I don't know if this is useful or not, but DGIndex says "Warning! Opening GOP is not closed. First few frames may not be decoded correctly". I've ripped the DVD a few times and it always has this error. I also tried using Trim to force TFM to work on a piece deeper in and it still crashes in that area too.

[tritical]

You can upload the vob to my ftp:

ip/port = 68.184.14.253:17252
user/pass = upload/upload

If you want to you can cut a chunk from the vob using dgindex (save project and demux video) or just stop the transfer after enough has been uploaded to reproduce the problem.

The open gop warning from dgindex wont effect things.

[swaaye]

I uploaded a test set of D2V, M2V, and AVS to your FTP. swaaye prefix on the files. It will crash Vdubmod very quickly on you.

[tritical]

It doesn't crash here on my comp so I've got a few more questions... What type of cpu do you have? If you set opt=0 in tfm does it crash? If you set pp=0 in tfm does it crash? What version of avisynth and tivtc are you using?

[swaaye]

It doesn't crash here on my comp so I've got a few more questions... What type of cpu do you have? If you set opt=0 in tfm does it crash? If you set pp=0 in tfm does it crash? What version of avisynth and tivtc are you using?

Setting pp=0 solved the crashing. pp=3 crashes as well. All other levels of pp are stable. Opt didn't help.

AVISynth 2.5.6a (StaxRip installs it)
TIVTC - 2006/04/09 v1.0 RC 3

I'm running a dual core Opteron 165. I've encoded roughly a bazillion (:)) vids with this setup and I think this is the first time I've had crashing problems with your filter. Though I haven't used this version of TIVTC much.

[tritical]

Yep, it's a problem with the combination of field=0 and cubic deint (pp=3/6) due to a change made in the last release. I'll put up a fixed version tommorrow.

[tritical]

[link removed], changes:
TFM:
+ output file generation is now effected by the micout parameter
+ if micout > 0 then calculate/output mics even when an override
or d2v match is used
- fixed a bug introduced in the last release in cubic deint pping (pp=3/6)
- fixed a bug in one of the yuy2 checkcombed mmx routines

[swaaye]

... :) glad to help.

[johnmeyer]

tritical,

Many thanks for the verbose output option. Makes my job a lot easier.

[Chainmax]

In my latest encode, using EEDI2 v0.91, TDeint v1RC7 and TIVTCv1RC4 resulted in some artifacting on several scenes. Here are some sample comparison screenshots:

MPEG2Source + ConvertToRGB:
http://img339.imageshack.us/img339/2373/source9je.png (http://imageshack.us)

Filtered:
http://img429.imageshack.us/img429/1121/result3tc.png (http://imageshack.us)


Here's the script I used:
mpeg2source("X:\wherever\GNS.d2v")

ColorMatrix()

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

Crop(8,2,700,466,align=true)

Levels(0,1,255,16,235)

hqdn3d(0,0,3,3)

DeGrainMedian()

aWarpSharp(depth=16,cm=1)

Lanczos4Resize(656,448)

DeHalo_Alpha()

LimitedSharpenFaster(SMode=4,LMode=3,Strength=200)

AddBorders(24,16,24,16)

ConvertToRGB()

(I put the ConvertToRGB lines in both scripts for a more accurate comparison as I'm using VDubMod)

This is much more frequent and evident in a previous high motion scene. I'll be trying just TIVTC soon, and get back with results. In the meantime, what do you think is the cause of this?

[foxyshadis]

Try using upconv=true in the Mpeg2Source, that might be bad chroma sampling. You can convert back to yv12 progressive after ivtc.

Since it's R1 the chance of an interlaced resize is pretty slim, and the field-blending would be more noticable. That'd be the other main reason for the artifacts.

[Chainmax]

I'll try upconv=true (how do I convert back to progressive yv12 after ivtc?) and report back. By the way, this comes from an R4 NTSC disc.

Anyway, I tried to IVTC with this

TFM(mode=3,PP=7,slow=2,mChroma=true)
TDecimate(mode=1)

and got pretty much the same result. You can download a sample vob with this scene and the high motion one I mentioned here (http://rapidshare.de/files/21733359/Sample.vob.html).

[Chainmax]

What do you know, upconv=1 eliminated the issue, thanks :). Now let's see if I can eliminate that annoying blocking in the sample without oversmoothing...

[scharfis_brain]

I simple do not have this problem at all...

[tritical]

@Chainmax
Do those artifacts occur if you use

colormatrix(interlaced=true)

w/o using upconv=1 in mpeg2source()? For interlaced yv12 interlaced=true needs to be set, but for yuy2 it doesn't effect things (might be the reason upconv=1 in mpeg2source fixed the problem). Guess before that question I should ask if the artifacts still occur if you don't use colormatrix at all?

[Chainmax]

I didn't try that, will do so and report back.

[edit]Both eliminating colormatrix and using it with the interlaced=true switch solved the problem as well. I didn't know that switch existed, as all the references to it in threads only used defaults.

[tritical]

EEDI2 v0.9.2 (http://bengal.missouri.edu/~kes25c/EEDI2v092.zip), changes:
+ various internal changes to help reduce artifacts around repeated
patterns and to improve construction of lines/edges with small slope
- Changed map from bool to int
- Changed default maxd value from 12 to 24
- Changed default pp value from 0 to 1
- a few minor bugfixes

After some thinking, I've figured out how eedi2 could be changed into a general purpose resampler able to resize to any requested resolution in one step. I think this could provide much better results than chaining multiple eedi2 calls together. I am busy on other projects atm so it wont happen immediately, but it is on the todo list for eedi2... hopefully the next release of eedi2 will have a general resize mode.

[Guest]

Thanks for the new version! :thanks:

[Chainmax]

Yeah, thanks for this new release :). The next release should greatly help me out on some of the stuff I've been messing around with, can't wait for it :).

[Adub]

This new version is wonderful news Tritical, thanks for your work.

[Revgen]

This new version is wonderful news TSP...

Don't you mean Tritical?