Decomb 5.0.0 beta 15: Fix for crashing problem

[DoW]

I think an addition on the usage of nt might be nice. I know that I'm experimenting with it, but I have no idea what sort of values are way high, low, etc.

[Guest]

It's already mentioned in the fourth question. Is it not enough?

[Guest]

I've released beta 5. Please see the first post in the thread for the link.

Pattern guidance has been improved. I'll be starting soon to write an account of pattern guidance at my website journal. It will exlain the issues and challenges, what can reasonably be expected and accomplished, and how Decomb actually performs its pattern guidance.

Executive summary: Pattern guidance is necessarily an approximate heuristic procedure. It can never be perfect. If it is too strong it can do more harm than good. Used in moderation it can improve matching.

Consider this: We have a new frame and the previous 5 are perfectly in lock with a 3:2 pattern. But the current frame blind match choice is out of this pattern. Do we override it? If it's a mismatch due to a small metric difference (due to noise or picture content spoofing the difference detection), we want to override it. If it's an actual pattern change, we don't want to override it. Decomb uses the gthresh mechanism to try to distinguish the cases. There are other things to try, e.g., see if the following frames have the same pattern as the previous 5. If so, then it's more likely that we should override. But no matter what you do, it always comes down to probabilities.

That's just to whet your interest so you'll read my journal. :)

[HomiE FR]

Yup that's really interesting. :) I'll try now your new beta 5, especially pattern guidance since it seems to be your point of interst for the time being. Thanks.

About the FAQ, I can't see now anything which could be added, I'll come back if I find something.

[Guest]

HomiE,

One of the scripts you sent me had gthresh=100. Don't do that. Anything higher than 15-20 starts to do more damage than good.

[HomiE FR]

Sorry neuron2, but I don't remember sending you any scripts. :confused: When am I supposed to have done this ? Maybe I do some tests with Decomb in my sleep but if this is the case I should go to a doctor I guess... :D

Seriously I don't think that I sent you any script, moreover I haven't played yet with gthresh, so I can't have sent you anything with gthresh=100 in it (besides my possible tests during my sleep obviously). :)

But your post made me learn a new thing about Decomb : never put gthresh over 20. If it was 100 I must have been totally asleep ! :)

[Guest]

Originally posted by HomiE FR
Sorry neuron2, but I don't remember sending you any scripts. :confused:
It seems I too am confused, because I mixed you up with JuanC. Sorry. But to be fair to Juan, I believe he was doing it to isolate a Decomb bug.

@JuanC

Don't use gthresh=100. :)

[HomiE FR]

No problem, neuron2. Moreover it seems that there is even less combed frames (which were already very few with beta 4) after Telecide. I guess patern guidance is doing its job even better. :) But I need to do some more tests to be sure.

[cipher]

@DoW

I've been ripping a lota music videos, and fading scenes are very common in mvs, which often drive me crazy, coz I have to set very low thresholds to deal with them, and that certainly is "ruining the rest of the movie".
However, I found that enabling "chroma=true" might be a little useful if we were trying to handle fading scenes better.

Below are two identical scenes from an interlaced fading-out frame, of whose vmetric values one was calculated without taking chroma into account, and the other was set to "chroma=true". You can see, with "chroma=true" the vmetric value increased by about 3(29.3%) in such a fading-out frame, which is good coz we really want a higher vthresh value(or threshold in Decomb classic).
fading.out.interlaced.chroma=false.vmetric=8.853428 (http://photos.gznet.com/photos/1111960/1111960-212RBl6Ko$.jpg)
fading.out.interlaced.chroma=true.vmetric=11.453900 (http://photos.gznet.com/photos/1111960/1111960-SSCHsRZKqH.jpg)

As a basis for comparison, here below are two identical frames from a "normal" scene. The difference in vmetric values between "chroma=false" and "chroma=true" is only 0.26(2.8%)
normal.chroma=false.vmetric=9.208037 (http://photos.gznet.com/photos/1111960/1111960-8FQh6P5aNz.jpg)
normal.chroma=true.vmetric=9.468085 (http://photos.gznet.com/photos/1111960/1111960-MS5vobLNwE.jpg)

That makes sense(edit: hmm...whether calculating vmetric difference in that way makes sense or not still needs validation, but you get the idea:D). Because usually in a frame that is fading out, what changes rapidly is luminance. If this frame is interlaced, the luma difference between two vertically adjacent pixels becomes less than what it should be in a "normal" scene, which telecide() find it hard to detect. But setting "chroma=true", now chroma has been considered, and I think the chroma and hue values of EACH OF these two pixels wouldn't differ too much than their "normal" states, and the vmetric value now becomes closer to a "normal" interlaced scene that has a higher vmetric. So it seems to me that "chroma=true" acts as an offset here to evaluate vmetrics more accurately in such fading scenes.
But, If I remember right, chroma=true was default in previous Decomb classic, but it has been changed to be false in current version. This is what I found in the doc:

It is useful for clips which have a large amount of luma/chroma interference, as might result from a poor comb filter. The interference can cause frames that are not combed to be detected as combed when chroma=true. By setting chroma=false, the effect of the interference can be eliminated.

As in my example above, a vmetric=11.4 even after enabling chroma is still very low(and the combs are really noticable when playback!). In addition, I don't really know if this method is universally effective to handle fading scenes.(ie.we need more tests).So just for curiosity, DG, is it practical to add a sort of switch, when enabling it, Telecide() becomes more sensitive to chroma and/or hue, after it detects a rapid/sudden but differentiable decrease/increse in luminance?(that's what I characterize fading scenes in terms of the three factors of color) :D
Please correct me if I'm wrong, and thanks!:)

[gizmotech]

Hmm, at this point will work begin on YV12 support?

Just curious. I look forward to seeing how fast it will run in YV12 mode. :)

[JuanC]

Originally posted by neuron2
@JuanC

Don't use gthresh=100. :) Thanks, you're right, I used that before in my erlier tests. I don't use it that high anymore. :) :J

BTW, in order to tweak GThresh, It would be great to have the metrics for Predicted / Calculated in the show/ debug options. :J

[Guest]

Originally posted by cipher
DG, is it practical to add a sort of switch, when enabling it, Telecide() becomes more sensitive to chroma and/or hue, after it detects a rapid/sudden but differentiable decrease/increse in luminance?(that's what I characterize fading scenes in terms of the three factors of color) I will not consider such changes in the absence of a clip that demonstrates a problem. You are welcome to submit one and I will give it careful attention.

[Guest]

Originally posted by gizmotech
Hmm, at this point will work begin on YV12 support? As soon as user feedback indicates that the functionality is stabilized, I will add YV12 support. I hope that will be within days.

[gizmotech]

I'm waiting with baited breath as my current tests with the patern matching on 5b4 was FANTASTIC. Handled stuff that 4.1b2 just died horribly on. Now I haven't check b5 yet, however I don't really see how it can get any better.

Once again thanks for the hard work. Greatly appreciated.

GizmoTech

[DoW]

@cipher:
I am using chroma=true. I tried adding in nt=20 and it helped a good deal (ZoE has a pretty decent amount of mosquito noise in it) with detection. After some tweaking and using some manual overrides, Im gonna see if any of the frames that cant be handled correctly (because of poor TC in the source) can just be manually decimated out. As with all things, its a matter of tweaking:D.

[cipher]

I will not consider such changes in the absence of a clip that demonstrates a problem. You are welcome to submit one and I will give it careful attention.

Yeah, sure! I have posted a vob section here (~12M). It's my FTP so the speed may be slow (Rogers AT&T, upload limit only about 20-22kb/s).
Not only DG, but anyone interested could also download it for inspection; but it would only be available for a couple of days. ;).
Thank you very much!!:)

Here is the vob splited (ftp://doom9:doom9@65.49.49.22/Tests.zip)

@DoW
I am using chroma=true. I tried adding in nt=20 and it helped a good deal
It's good to hear that. But it doesn't work for me.:) coz if I add some nt values, the vmetric drops quickly, probably because the clips in my hands are clean. But I have some animes that really have bad quality and I think setting some nt values would be of great help, thanks!

[dsmith]

Not sure I can comment on Cipher's problem, but playing around with the VOB I noticed an oddity. If I set the override [frames 321,324,325; haven't done enough to tell if there's a pattern] to 'c', the Show info tells me it's forcing 'n', and if I set 'n', it tells me it's using 'p' (the default). If I set it to 'p', it says it's forcing 'p'. Not sure how to get it to select 'c'.

AVS script:


LoadPlugin("E:\DVDTools\AviSynth25\plugins\MPEG2Dec3.dll")
LoadPlugin("E:\DVDTools\AviSynth25\plugins\decomb5.dll")
MPEG2Source("E:\Clips\Video\Testing\cipher\test.d2v")
ConvertToYUY2(interlaced=true)
Telecide(ovr="test.tel.txt",order=1,guide=0,chroma=true,post=2,vthresh=14,dthresh=14,show=true)

[Guest]

@cipher

I am downloading...

@dsmith

Thank you for pointing that out. Beta 6 fixes it:

http://shelob.mordor.net/dgraft/decomb/decomb500b6.zip

[Guest]

@cipher

The idiots applied the fades with field granularity after 3:2 pulldown, which makes the fade sections interlaced.

What your clip shows is that the difference metric is great for field matching and not so great for comb detection. That leaves me two options: 1) go back to the previous metric for both matching and comb detection, or 2) try to normalize the metric for luminance level, as I did in the original Dup. I will experiment and choose the best of the two. I agree that the current behavior is not acceptable.

EDIT: There's a third option: 3) find a new better metric. :)

[DoW]

@cipher:
Yeah, ZoE is pretty noisy for an DVD anime. Im experiencing a simliar problem to what you are with fading intro credits (fading in part interlaced, middle static part not, fade out interlaced). The vmetric is very low or zero when you have a background of almost all one color that is solid (black, gray, what have you) and the vmetric slowly increases as the credits fade in, and decrease on the fade out. For right now, Im gonna try using the override to ignore interlacing on the credits and then comming back and triming them off and using FieldDI() on them. Cant wait to see the magic that neuron2 pulls off, as he always does:D.

[HomiE FR]

@neuron2 : It might be a bit off topic, but I have just found out your journal on your website (I had never looked at it before) and it seems really interesting ! :) Thanks for sharing your knowledge, I will try to understand what is explained there.

About beta 6 : it seems to me that new generation Decomb performs at least as good (and often better in my tests with the anime source I gave you) as old Decomb 4. Just my experience with it. I guess YV12 support is not too far away then ! :p

[Ulm]

Just an FYI...

I've been having the dickens of a time with Avisynth 2.52 and Decomb (all versions).

If I just do a decomb with no other processing, there's no problem. However, if I convert the colorspace from YUV2 (Huffyuv, actually) to RGB32 (or YV12, I found), Avisynth starts to throw access violations out frequently, but seemingly at random. This was with both the 5.0 betas and the last 4.0 Decomb.

I backed off to 2.51 and Decomb 5.0 beta6, and I don't seem to be having the same problem. I'll know more after my process runs for a few hours.

Whether this would be a problem with Avisynth, Decomb, or a combination, I don't know. I can reproduce it pretty easily right now, if I can do anything to help.

Here's an example script that didn't work with Avisynth 2.52.


<SNIP>
AVISource("D:\Capture.avi")
Telecide(order=1, guide=1, post=2, vthresh=10, nt=50, blend=true, show=false)
Decimate()
dup(blend=true, chroma=false, threshold=5)
Crop(8,8,-8,-8)

ConvertToRGB32()
Levels(0,0.85,255,16,236)
MSmooth(threshold=10, strength=3, mask=false)
MSharpen(threshold=20,strength=100,mask=false)
<SNIP!>

If I remove the 'ConvertToRGB32()' (and everything that depends on RGB space) everything seems to work okay. Otherwise, seemingly random access violations while feeding either VirtualDub or TMPGenc (or feeding TMPGenc via Vdub's frameserver). BTW, I made sure it wasn't an issue with MSmooth or MSharpen. Any filter after the RGB conversion section will cause the access violations.

Otherwise, Beta 6 seems to work well for me, except that my source is heavily combed after the telecine is done. I have to set my vthresh fairly low to make sure they get postprocessed. I think it's either my cap card, or VCR jitters. Ah well.


Thanks...

[cipher]

@DoW
Forget about my suggestion on enabling "chroma=true". Lately I've found its annormal behaviour:

Playing with Shania Twain's Any Man of Mine, when I set chroma=true I found:
1. Some frames which were not supposed to be combed were detected as combed, as DG mentioned in his docs.

2. At least one frame that I noticed had its vmetric value changed if I changed the "vthresh". The vmetrics, as far as I've understood,should've been INDEPENDENT of what "vthresh" we set.

3. And that frame I mention in 2) was combed, but the combs can't be de-interlaced well no matter how low the vthresh and dthresh were set. I mean, the "show" said it was "interlaced" so it must have been deinterlaced by post=2, but my eyes could still see the combs no matter how low a vthresh and/or dthresh was(actually, the combs didn't even change in my eyes when I altered the 2 thresholds).

4. vmetric of one single frame differed in Avisynth v2.51beta and v2.52, and the difference was huge.

Setting chroma=false made all these 4 strange behaviours disappear. Since the Decomb docs metion the instabilities of chroma=true, it's NOT a bug. And now knowing this, I take my word back and really recommend you not to use chroma=true. It's better a low threshold than a wrong decombed movie, right?:D And let's wait for DG's new idea on handling fades.:)

@Donald,
The idiots applied the fades with field granularity after 3:2 pulldown, which makes the fade sections interlaced.

So it's not even an inability of Decomb in anyways, even if we do a completely perfect IVTC on these stupidly-edited frames, we may not get rid of those lines, right?
But I'm still looking forward to your new beta, which can even beat those crazy badly-edited frames.:D

Edit:
Sorry, I was wrong, and Donald corrected me that the 2) I mentioned here was pretty normal, as:
The reason the vmetric can change with vthresh is if you force the desperation mode to pick the next (forward match frame 'n'), it gives you the metric for that match

[Guest]

Originally posted by cipher
So it's not even an inability of Decomb in anyways, even if we do a completely perfect IVTC on these stupidly-edited frames, we may not get rid of those lines, right?The fields are matched as good as they can be. You can see that the actual action has had its 3:2 combing removed, but the fade effectively overlays a video clip on top of the 3:2 content. The old Decomb has exactly the same problem with this, and even FieldDeinterlace() by itself has trouble seeing the fade frames as interlaced unless you set threshold really low. And then if they are detected as interlaced, you need dthresh really low to fix them. The problem is that the field-to-field change is very small.

But never fear, I think I may have a new metric that will easily pick up these things.

For now, you could postprocess Decomb's output with TomsMoComp, but it will do smoothing (a kind of median filtering) on every frame.

[DoW]

Like Neuron2 was saying, you can use a low threshold and dthreshold to deal with it. Not to repeat, but previously in the thread I mentioned that I dealt with credits like these by trimming them and using using threshold=4 and dthreshold=4 in FieldDI. If Neuron2 says that hes comming up with a new metric, this may be a very mute point soon:D.

[Guest]

MetricX kicks butt on the cipher fade clip, giving a vmetric increase of 2000% (20 times) as soon as the fade starts! Field matching is unchanged. Get this: the new metric has no multiplies or divides and only 3 additions; all the rest is compares and boolean logic.

I have to regression test it against my test suite and then tie up some loose ends (support both field orders, chroma true/false) and then it looks good to go.

I'll describe the metric in my journal tomorrow.

@cipher

The reason the vmetric can change with vthresh is if you force the desperation mode to pick the next (forward match frame 'n'), it gives you the metric for that match.

[cipher]

Originally posted by neuron2
MetricX kicks butt on the cipher fade clip, giving a vmetric increase of 2000% (20 times) as soon as the fade starts! Field matching is unchanged. Get this: the new metric has no multiplies or divides and only 3 additions; all the rest is compares and boolean logic.

I have to regression test it against my test suite and then tie up some loose ends (support both field orders, chroma true/false) and then it looks good to go.

Can't wait~~~!:D
And trillions thanks!

[cuisinart]

Hi,

I was playing around with beta6 and noticed that enabling show=true always displayed metrics for _only_ p and c, regardless of the value of order=. As I understand it, when order=1 Telecide() will determine the best match between the current and next frame, which is equivlent to setting mm=2 in decomb4. I was wondering if I was missing something here; show=true should give a metric for n, correct? Or is the metric displayed for p actualy the metric for n? I tried to figure it out but just managed to confuse myself. :D

By the way, great job on the new decomb version! I've put it through my torture clips and noticed a definate improvement. Keep up the good work :)

EDIT:
Ah, I answered my own question, I think. Reading back on previous posts I noticed you mention that forward matching in now gone, except in special situations.

[gizmotech]

Quick Question,

@neuron2 What is the current default gthresh value? in the documentation it sais 30, however it also sais in the documentation that anything over 20 is starting to get dangerous.

Is the current default value 30, or something lower then that?

Gizmotech

[Guest]

Originally posted by gizmotech
Is the current default value 30, or something lower then that?
Current default is 15. I will correct the documentation.

The beta to be released shortly will have MetricX and display of the pattern guidance mismatch percentage to let you tweak gthresh.

[HomiE FR]

Waiting for MetricX... :) Thanks neuron2, I will test it against my anime source tomorrow if it's out.

[gizmotech]

@neuron2:
Just gonna report some VERY strange behaviour. (decomb 5b6) I've just created an AVS file for my encode, and stepped through a number of scenes in vdubmod to check and make sure the "mouth problems" are gone, and frame for frame they are completely gone. Now after having run this avs through a 1 pass divx somehow a frame which shows up in vdubmod running the avs as decombed is now combed.

So this frame, by avs prior to encoding, is perfect. After encoding, using the same avs is now combed. The unusual part is I've reproduced this 2 encodes in a row now. I'll wait for b7 for your new matriX and see if this trend continues. If it does I will send a vob segment and avs script.

Gizmotech

[Guest]

@gizmotech

Please post your script when describing problems. It saves me from having to guess at things.

The only thing I can think of is that you have pattern guidance enabled with a highish gthresh. Guidance is not completely deterministic in that starting from different points in the clip may give slightly different results.

EDIT: The magnitude of "slightly" increases with gthresh. :)

[gizmotech]

Appologies.


# PLUGINS
LoadPlugin("C:\newfilters\mpeg2dec3.dll")
LoadPlugin("C:\newfilters\decomb5.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\WarpSharp.dll")
LoadPlugin("C:\newfilters\convolution3d.dll")
# SOURCE
mpeg2source(idct=6,d2v="C:\CrestoftheStars\Episode5\Episode5.d2v")
YV12toYUY2(interlaced=true)
# IVTC
Telecide(order=1,post=2,guide=1,vthresh=34.5,nt=30,
dthresh=9,blend=true,gthresh=15)
Decimate(cycle=5,quality=3,mode=1)
# Smoothing
Convolution3d(preset="animeLQ")
# CROPPING
crop(8,0,704,480)
# RESIZING
BilinearResize(640,480)
# Sharpen
WarpSharp(depth=80, blur=3, bump=80, cubic=-0.6)


I'm honestly confused at this point as why would it show up correctly when the avs is viewed in vdubmod, however after the encoding process result in a bad dicision?
If nescessary I can post pics/small vobs to demo w/.
EDIT:
So basically you're saying that by skipping to various parts of the video in vdubmod it will change how it is attempting to perform patern matching? That will make it very difficult to preview a whole telecide run, as hitting stop at any point will restart the partern matching.

[Guest]

@gizmotech

As I hope to describe soon in my journal, you can either have poor deterministic pattern guidance or good slightly indeterministic pattern guidance. Have you established whether it is indeed a guidance problem? If the frame is rendered correctly with guide=0 in VDubMod, try an encode with guide=0 and tell me whether it is still rendered correctly.

@all

I am just finishing up the docs for the new beta. One thing I've noticed about the new metric: it is more sensitive and can pick up the fades but that makes it more sensitive to content that mimics combing as well. This only bothered me with one clip in my test suite, but I think it would be worthwhile to enhance the override capability to allow specifying the vthreshold to use for different frame ranges (perhaps other parameters as well, why not all?).

[gizmotech]

Alright. Looks like guide=0 fixed it. I look forward to reading that journal entry.

And adjustable vthresh by frames was actually something I was gonna ask about. I look forward to seeing it in the next release.

Gizmotech (Looking for that YV12 :)

[Defiler]

neuron2: I've had vastly better luck with hybrid footage using the new Telecide/Decimate. Thanks again for your efforts. The new parameters are extremely useful.

[Guest]

@Defiler

Thank you for the feedback.

@gizmo

OK, I will hold up the beta and add overridable vthresh.

[DoW]

@neuron2
Well, since your working on the override functionality, would it be possible to do both manual field selection and post override on the same frame (I tried last night and couldnt get it to work (if im missing something, please let me know)).
Also, the increased sensitivity to content that mimics combing, what would this do to the vob that I sent you from ZoE?

[Guest]

Originally posted by DoW
@neuron2
Well, since your working on the override functionality, would it be possible to do both manual field selection and post override on the same frame (I tried last night and couldnt get it to work (if im missing something, please let me know)).
Also, the increased sensitivity to content that mimics combing, what would this do to the vob that I sent you from ZoE? Why do you guys never give me the scripts and override files so that I have to either guess or ask for them???

You should already be able to combine the two overrides. Please post your overrides file. :)

What would the new metric do to your clip? I'll try it when I get home from work. But if I remember correctly, you were talking about that title fade that is impossible to see normally. I think it requires an extremely low vthresh to be detected. The best thing to do would be to set a normal vthresh and then override it very low during that portion.

I will also post the new beta then as I have the vthresh override working and all the docs done.

@gizmo

I haven't forgotten about YV12. But as long as functionality is changing I don't want to do stuff twice.

[DoW]

@neuron2:
Sorry for not posting the file, I was uber busy and late for a meeting. Came up with an idea about the override, I wanna try it first, and if it solves it, then I should try more things before I open my mouth.
I was refering to the section of vid where the image gets all these horizontal lines when its zooming in on the cannon, ~frame 528-880ish.

[gizmotech]

@neuron2

Don't mind me I'm just impatient. I look forward to seeing matriX in action, and trying out a vthresh overide script.

[Guest]

Here's the new beta:

http://shelob.mordor.net/dgraft/decomb/decomb500b7.zip

Please read the tutorial to see how to use the new vthresh metric.

This version adds:

* New combing metric that is more sensitive.
* vthresh manual overrides per frame range.
* display of pattern mismatch percent to tweak gthresh.
* gthresh, dthresh, vthresh now integers, not floats

Example of vthresh override:

500,650 v 35

Make vthresh 35 for frames 500 to 650, then restore the vthresh as defined in the vthresh parameter.

[cipher]

I knew it! I knew it would work miracles!!
And what I didn't know was that it is much more effective than I imagined!! The vmetric distinguishes the really combed fading frames and clean frames so easily that it's just like...WOW!

Tha~~~~nk you~~~!:D

Edit:
Okay, for those who might still be in doubt, this is what I got for the clip I provided:
After I set an appropriate vthresh,
NONE of the clean frames has vmetric above 30,and
ALL of the combed frames are way above 100, usually around 150.

I don't know how DG did it, but guys, as Morpheus would say:"He is the one.":D

[Guest]

Originally posted by cipher
I knew it! I knew it would work miracles!!
And what I didn't know was that it is much more effective than I imagined!! The vmetric distinguishes the really combed fading frames and clean frames so easily that it's just like...WOW!

Tha~~~~nk you~~~!:D Of course, regulars here know that I aim to please. It is gratifying to me to know when I have succeeded. :D

But let's not count our chickens yet. The other users need to weigh in.

[cipher]

Okay, there are a few music videos that are standing by.
I will post my results later tonight.

[Guest]

Originally posted by gizmotech
Alright. Looks like guide=0 fixed it. Try a lower gthresh rather than turning off pattern guidance altogether. As I say in the docs, 15-20 is already dangerous.

Also, are you sure there is significant 3:2 content?

[gizmotech]

Heyo,

I'm back with a silly question. How does the pattern mismastch percentage relate to the gthresh value? for instance I have a number of frames which were overriden incorrectly which have percentage mismatches greater then 10 but less then 15, yet my gthresh has been set to gthresh=15.

Is there a directly correlation between gthresh =15 and a patern mismatch =15%? can I safely assume that setting gthresh=20% means that any frame which is 20% mismatched will be overriden?

telecide(order=1,post=3,guide=1,gthresh=15,vthresh=18,show=true)

As well, does the hints=true affect the patern matching in any way or is it just passing information along?

Gizmotech.

[dsmith]

Having trouble with the override file.

Script:

LoadPlugin("E:\DVDTools\AviSynth25\plugins\MPEG2Dec3.dll")
LoadPlugin("E:\DVDTools\AviSynth25\plugins\Decomb5\decomb.dll")
SetMemoryMax(16)
MPEG2Source("E:\Clips\Video\Dual\Raw\OP.d2v")
ConvertToYUY2(interlaced=true)
Telecide(ovr="op.tel.txt",order=1,post=1,show=true)
#Decimate(cycle=5,mode=2)

Override file (E:\Clips\Video\Dual\op.tel.txt):

174 p
175 p


However, Show indicates that those frames are still using the C match, not being forced with the override. Giving an absolute path didn't make any difference. The AVS and override files are in the same directory.

--
David

[Guest]

Originally posted by gizmotech
I'm back with a silly question. How does the pattern mismastch percentage relate to the gthresh value? for instance I have a number of frames which were overriden incorrectly which have percentage mismatches greater then 10 but less then 15, yet my gthresh has been set to gthresh=15.

Is there a directly correlation between gthresh =15 and a patern mismatch =15%? can I safely assume that setting gthresh=20% means that any frame which is 20% mismatched will be overriden?

telecide(order=1,post=3,guide=1,gthresh=15,vthresh=18,show=true)

As well, does the hints=true affect the patern matching in any way or is it just passing information along?

Gizmotech. Yes, the numbers are commensurate. If your mismatch is 10 and the gthresh is 15, then the override will be allowed, even if *you* know it is incorrect. That is why I said 15% is
dangerous. :) Try setting gthresh to 10 and see what happens.

Hints do nothing except inform Decimate modes 1 and 3.

EDIT: It occurred to me that maybe you are misinterpeting "override" in this context. If the pattern guidance thinks a blind field match is not what it predicts based on pattern analysis, it tries to override the blind field match. The override is allowed if the mismatch is less than the gthresh.