Decomb beta thread (current 4.10 beta 4 -- NEW RELEASE)

[Guest]

This thread will receive all new betas for Decomb. Note that Decomb now is supported only under Avisynth 2.5. Feedback to this thread will be appreciated.

Current release:
http://shelob.mordor.net/dgraft/decomb/decomb410b4.zip

[Stereodude]

Don,

You might want to make sure you tell people not to use both the x and - in their overide file if they're doing a decimate(mode=3)

For example and OVR file of this:811,845 x
811,845 -
972,7707 x
972,7707 -
8399,8538 x
8399,8538 -
8781,8882 x
8781,8882 -
8930,8963 x
8930,8963 -when combined with this scriptLoadPlugin("c:\HDTV Tools\mpeg2dec\MPEG2Dec3_2.5.dll")
LoadPlugin("c:\HDTV Tools\decomb\decomb_406b4.dll")
mpeg2source("d:\faith\faith_04.d2v",idct=5,cpu=4,iPP=true,
moderate_h=20, moderate_v=40)
Telecide(guide=1, ovr="faith_04.ovr",show=true)
Decimate(mode=3)
ConvertToRGB()gives adjacent frames like these. Note the banding in the 2nd screenshot (15bit color?).

#1: http://stereodude.cjb.net:900/bad_combo0.jpg

#2: http://stereodude.cjb.net:900/bad_combo1.jpg

Stereodude

[Guest]

Originally posted by Stereodude
You might want to make sure you tell people not to use both the x and - in their overide file if they're doing a decimate(mode=3) No. There's no reason to avoid that usage combination.

...gives adjacent frames like these...The only version of mpeg2dec supported is mpeg2dec3_094. Don't you read help files? Please repost when you've met the documented Decomb requirements.

If you are complaining that the frames are combed, you have forced the postprocessing off in the overrides file. So if the frame cannot be matched because it is video, or there is a missing field, or any of several other legal stream conditions, you will pass a combed field to Decimate, which may pass it on.

Regarding bands, I don't know what you are talking about; I didn't see anything.

[Stereodude]

Originally posted by neuron2
No. There's no reason to avoid that usage combination.Sure there is. I've outlined it in my post.The only version of mpeg2dec supported is mpeg2dec3_094. Don't you read help files? Please repost when you've met the documented Decomb requirements.

If you are complaining that the frames are combed, you have forced the postprocessing off in the overrides file. So if the frame cannot be matched because it is video, or there is a missing field, or any of several other legal stream conditions, you will pass a combed field to Decimate, which may pass it on.

Regarding bands, I don't know what you are talking about; I didn't see anything. I am using mpeg2dec3_094. Just cause I don't call it that doesn't mean I'm not using it. I'm not the complete idiot you make me out to be. To me the banding is rather obvious, but I'll try to make it more visible to you.

Stereodude

[Stereodude]

Don,

Take a look at these two images

http://stereodude.cjb.net:900/banding_00.jpg

http://stereodude.cjb.net:900/banding_01.jpg

Stereodude

[Guest]

Originally posted by Stereodude
Take a look at these two images Now I see some banding.

What is the evidence/steps you have taken to isolate this to a responsible piece of software, i.e., why do you think Decomb is at fault? Knowing this can help me locate the problem.

Have you, for example, tried using mode=0 to see if it might be caused by the blending?

[Guest]

Never mind, I have a theory about it. Stand by for a revised beta for testing. I assume you only see this in the frames blended by Decimate. Yes?

[InfoCynic]

Can you give more details about what mode 3 is doing? with show=true, I see things like "Decimating all-video cycle," so then is it blending 4 pairs of frames into the 4 we see? Or is it passing 3 and blending the other 2? For FILM (or frames with a duplicated as determined by threshold) obviously it's dropping 1, and what does it do in mixed cycles?

I'm excited to see what this can do for TNG and B5, I have carefully crafted thresholds for mode=1, I expect they'll transfer over directly... Thanks for the work!

[Stereodude]

Originally posted by neuron2
Now I see some banding.

What is the evidence/steps you have taken to isolate this to a responsible piece of software, i.e., why do you think Decomb is at fault? Knowing this can help me locate the problem.

Have you, for example, tried using mode=0 to see if it might be caused by the blending? It doesn't show up when mode=1. However, As I outline in my other thread ( http://forum.doom9.org/showthread.php?s=&threadid=41483 ) it doesn't actually blend when mode=1 anymore either. At this point I don't know what's wrong with it. I do know that beta 2 did not have any issues when I plugged it into the script instead (in mode =1).

Edit: No it doesn't show up with mode=0. It shows up for two adjacent frames, the first (6753) is blended from 8441 and 8442. The 2nd frame (6754) is just a blend of 8442 and 8443. 8440 (6752) and 8444 (6755) don't have this. This pattern occurs repeatedly. 2 good frames and 2 banded frames. 2 good, 2 banded for as long as it's in the section that is flagged with both x's and -'s.

Stereodude

[Guest]

OK, thanks. Let's concentrate on the banding for now and get back to mode=1 later.

I will post a potential fix for the banding either tonight or tomorrow.

[Guest]

Here is Decomb 4.06 beta 5. It has fixed blending in mode 3. This should get rid of the banding. Please let me know.

EDIT: Attachment removed. More recent version attached below.

[Guest]

Originally posted by InfoCynic
Can you give more details about what mode 3 is doing? with show=true, I see things like "Decimating all-video cycle," so then is it blending 4 pairs of frames into the 4 we see? Or is it passing 3 and blending the other 2? For FILM (or frames with a duplicated as determined by threshold) obviously it's dropping 1, and what does it do in mixed cycles?In film cycles, it drops a frame as it would normally. In video cycles, it takes the 5 input frames of the cycle and generates 4 frames as follows:

0 -> 0
75% of 1 + 25% of 2 -> 1
75% of 3 + 25% of 2 -> 2
4 of input cycle -> 3 of output

Other strategies are possible. Let's see what works best. All suggestions welcome. Maybe we should blend the fields. :devil:

I'm hoping this will be a great improvement for hybrid clips, once we work the bugs out, thanks to the efforts of yourself and Stereodude.

[InfoCynic]

TNG isn't looking too hot with the current settings... I was testing with beta4, but there was horrible jerkiness present in large chunks of NTSC material (exterior pans, shots of the ship flying by, etc.).

Interesting though, I wouldn't have thought of that combination. My first (and I know MrFunnyBunny or someone with a nick like that suggested this too) would be to blend 4 pairs (01)(12)(23)(34)-> 0123, although I suppose that could be done in ratios other than 50%, it seems that a straight 50% blend across the board would make the most sense for consecutive VIDEO cycles, so the timing would match up.

The script I'm using for TNG (changed from my mode 1 scripts by simply replacing mode 1 with mode 3)...

LoadPlugin("c:\program files\gordianknot\mpeg2dec3.dll")
LoadPlugin("c:\program files\gordianknot\decomb.dll")

mpeg2source("h:\nextgen\103naked now.d2v",cpu=0,ipp=true)

#w= beginning (hybrid) before opening credits on FILM
#x= opening credits over FILM, needs high Decimate thresh (.38 highest verified)
#y= rest of movie (hybrid)
#z= end credits
w=trim(0,11075)
w=w.Telecide(chroma=true,threshold=3,dthreshold=0,show=false)
w=w.Decimate(mode=3,cycle=5,threshold=0.001,show=true,quality=3)
#x=trim(11076,12786)
#x=x.Telecide(chroma=true,threshold=3,dthreshold=0,show=false,y0=270,y1=385)
#x=x.Decimate(mode=3,threshold=0.4,cycle=5,show=false,quality=3)
#y=trim(12786,80451)
#y=y.Telecide(chroma=true,threshold=3,dthreshold=0,show=false)
#y=y.Decimate(mode=3,cycle=5,threshold=0.001,show=false,quality=3)
#a=w+x+y
#a=a.crop(6,0,-6,480)
#a=a.BicubicResize(512,384,0,0.5)

#z=trim(80452,0)
#z=z.FieldDeinterlace(full=true,chroma=true,dthreshold=0,show=false)
#z=z.crop(6,0,-6,480)
#z=z.BilinearResize(512,384)
#a+z
return w.BicubicResize(512,384,0,0.5)


As you can see from all the commented out line, my tests are just done on the first part (w) for speed, the sequence contains enough video and film scenes to get a good sense of the entire episode.

[Guest]

I chose that because I wanted to blend the fewest number of frames.

We can try the method you suggested (also suggested in other threads). Let me think about it for a while.

Thank you for your feedback.

[Stereodude]

Originally posted by neuron2
Here is Decomb 4.06 beta 5. It has fixed blending in mode 3. This should get rid of the banding. Please let me know. It does get rid of the blending problem (banding).

Stereodude

Edit: Don't post before 8AM in the morning or you make mistakes.

[Guest]

Originally posted by Stereodude
It does get rid of the blending.
Hope you meant to say "banding"!

Thank you for the results, Stereodude, and for pointing out the problem. I will experiment to find the best blending strategy (smoothest result) for the video cycles and report back.

If you'd like to address the mode=1 issue now, I am willing. Would you mind summarizing the problem again here? Thank you for your valuable assistance in improving Decomb.

[Stereodude]

Originally posted by neuron2
Hope you meant to say "banding"!

Thank you for the results, Stereodude, and for pointing out the problem. I will experiment to find the best blending strategy (smoothest result) for the video cycles and report back.

If you'd like to address the mode=1 issue now, I am willing. Would you mind summarizing the problem again here? Thank you for your valuable assistance in improving Decomb. Yeah I mean to say banding.

Using it decimate(mode=1) it doesn't appear to blend any of the frames (ever) in this usage. It does not blend true interlaced sections (denoted by x and - in the .ovr file) so seems to follows the .ovr file loaded in telecide. That's good (maybe, if it's working), but it doesn't replace the duplicated frame (from from the IVTC operation) with a blended one either. The duplicated frame just passes through. This leads me to think that blending is just completely turn off in mode=1.

In a given section of my test clip which has over 600 telcine'd frames in a row (7708 to 8398) it didn't create a single new frame, but instead passed every duplicated frame through.

Here's the scriptsLoadPlugin("c:\HDTV Tools\mpeg2dec\MPEG2Dec3_2.5.dll")
LoadPlugin("c:\HDTV Tools\decomb\decomb_406b4.dll")
mpeg2source("d:\faith\faith_04.d2v",idct=5,cpu=4,iPP=true,moderate_h=20,moderate_v=40)
Telecide(guide=1, ovr="faith_04.ovr",show=true)
Decimate(mode=1)
ConvertToRGB()811,845 x
811,845 -
972,7707 x
972,7707 -
8399,8538 x
8399,8538 -
8781,8882 x
8781,8882 -Stereodude

[Guest]

Thank you, StereoDude. I am investigating.

[Guest]

@Stereodude

I am unable to duplicate your problem. It blends just fine for me. Can you please post a small VOB and script that demonstrates the problem you see? Thank you.

[CruNcher]

@ neuron2

with the new decomb beta for avisynth 2.5 and the newest avisynth 2.5
chroma=true in FieldDeinterlace(full=true,chroma=true,blend=false)causeing ugly distortions is this normal ? it wasn't before and chroma=true helped in compresibility a bit

[Guest]

It works just fine for me. Please post a clip and script if you want me to look at it.

I have no idea what you mean by "ugly distortion". Can't you at least either explain yourself or post a screenshot? Best of course is to make available a clip and script.

[CruNcher]

@neuron2
sorry for being so unprecise it looks like as if pixel "drifting away" in hight motion areas i attached a picture of the problem this time :)

Avisynth 2.5 10th January 2003

the simple script i used

LoadPlugin("MPEG2Dec3YV12.dll") / latest Marc Fd 0.94
LoadPlugin("DecombYV12.dll") / latest 4.06 beta 5
MPEG2Source("deintertest.d2v",idct=2,iPP=false)
FieldDeinterlace(full=false,chroma=false,blend=false)
LanczosResize(512,384)

[Bulletproof]

I'm not sure if FieldDeinterlace has this parameter, but try tweaking the dthreshold.

[Guest]

Yes, tweak (reduce) dthreshold. If that doesn't help, please post an unprocessed VOB fragment or AVI. It only needs to have one frame!

[CruNcher]

@ neuron and bulletproof
i tried a lower dthreshold but that doesn't helped only beginning with a dthreshold of 200 helped but causeing ghosting effect now i atttached a sample clip of the sequence but i doubt that that the sequence is the problem becaouse the problem is visible with chroma=true in all content i got :(

[Guest]

Thank you, CruNcher. It does look like a real problem. I'll debug it later today. DecombLegacy doesn't do this. And it doesn't happen with YUY2. If you put in a converttoyuy2() the problem goes away. So it affects only YV12.

[Guest]

OK, I found it through code inspection. The fix is attached. Thank you once again, CruNcher, for pointing this out.

EDIT: Attachment removed. More recent version attached below.

[Guest]

I figured out a way to allow random access for pattern guidance. This would mean you would always get the same results no matter where you started in the clip. Seems to me that it would make tweaking much easier.

Is this something users would consider important enough for me to do?

[InfoCynic]

Hm. Usually if I need to tweak a random scene i just jump back about 20 frames before it and figure the pattern guidance will kick in before I get to the scene I care about. I guess if you needed to cut directly into a scene... of course, I almost never use pattern guidance because I can't get it to identify FILM and VIDEO correctly without extensive manual overrides.

[Calculon]

Originally posted by neuron2
I figured out a way to allow random access for pattern guidance. This would mean you would always get the same results no matter where you started in the clip. Seems to me that it would make tweaking much easier.

Is this something users would consider important enough for me to do?


Could this benefit hybrid material(specifically on the switch from film to video segments...)? If so, then I'd love it. Sorry if I misunderstand what random access for pattern guidance means exactly. ;) And I'd like to say good job on the decimate mode 3. Clearly better for the ST: TNG rips I've done in comparison to mode 2, though not perfect.

[InfoCynic]

TNG "Clearly better?"

I'd like to know what settings you're using, because I can get very good results using mode 2 (see above script) but can't stand the jerkiness of motion present in the VIDEO scenes in mode 3.

[Guest]

OK, first some clarification...

When it displays FILM vs. VIDEO that is misleading. What it really means is IN 3:2 PATTERN vs. NOT IN 3:2 PATTERN. You can be NOT IN 3:2 PATTERN either because of a pattern break (e.g., phase change or inserted extra non-RFF frames) or because it is pure VIDEO. So there should be 3 categories:

PROGRESSIVE IN PATTERN (shows as FILM in beta)
PROGRESSIVE NOT IN PATTERN (shows as VIDEO in beta)
VIDEO (shows as VIDEO in beta)

The changes I have in mind will permit these three categories to be properly discerned, so I think it will be a significant improvement, as well as allowing deterministic behavior and proper random access.

Regarding mode 3: Can InfoCynic make available a good-sized VOB for me to work with? Be aware you're never going to get perfect results and there will always be some compromises when dealing with hybrid material. But if two users report such different results, I'd like to try to get to the bottom of it.

[Calculon]

Originally posted by InfoCynic
TNG "Clearly better?"

I'd like to know what settings you're using, because I can get very good results using mode 2 (see above script) but can't stand the jerkiness of motion present in the VIDEO scenes in mode 3.


Here's what I used:

LoadPlugin("D:\MPEG2Dec3.dll")
LoadPlugin("D:\Convolution3DYV12.dll")
LoadPlugin("D:\Decomb.dll")
mpeg2source("F:\TNGS4D5\VIDEO_TS\1.d2v")
Telecide(guide=1,chroma=true,post=true,gthresh=30)
Decimate(mode=3,cycle=5,quality=3,threshold2=2.0)
Crop(8,0,-8,0)
LanczosResize(640,480)



It still isn't perfect, but mode 2 doesn't look very good to me at all. Probably just a personal preference.

[MrBunny]

Originally posted by Calculon
Here's what I used:

LoadPlugin("D:\MPEG2Dec3.dll")
LoadPlugin("D:\Convolution3DYV12.dll")
LoadPlugin("D:\Decomb.dll")
mpeg2source("F:\TNGS4D5\VIDEO_TS\1.d2v")
Telecide(guide=1,chroma=true,post=true,gthresh=30)
Decimate(mode=3,cycle=5,quality=3,threshold2=2.0)
Crop(8,0,-8,0)
LanczosResize(640,480)


As far as I know, threshold2 doesn't do anything for mode=3, only mode=2, I think threshold is used for mode=3. From my limited experience with TNG vobs, it seems to me that threshold=2.0 is much too high. Even in many of the NTSC video scenes, the threshold doesn't go that high. Generally I've found that around the 0.35-0.7ish area, both film, pure NTSC, and hybrid frames are showing up. In my opinion, with mode3, it would be better to have a threshold that would decimate less rather than more (ie be lower). Mode3 interpolating some extra film sequences should be less noticeable than decimating some NTSC sequences.
BTW, as a sidenote, what codec are you encoding with? If it's xvid or SBC, those settings look really aggressive for anything less than 1 ep/CD, in which case, for these horrible ivtcing DVDs, SVCD might be a better choice.

@neuron2
In the decomb beta helpfile you should probably mention that threshold also applies to mode=3, although it seems logical :) Check PM too pls, I have a vob sample up for you.

Mr. B

Edit: Sorry, in case I wasn't clear above, I meant that putting the threshold lower rather than higher was better because a film sequence detected (because of low threshold) and treated as video (interpolated) is better than a video sequence being detected as film (because of high threshold) and thus decimated.
Edit 2: Confused threshold2 and threshold ;)

[Guest]

Man, this TNG trek stuff is tough!

Now, what can I say that we don't already know? :)

Well...(thinks feverishly)...how about we make this into a challenge? You know, to stimulate creative thinking. The challenge is to take MrBunny's VOB and decimate it to 23.976, treating the film and video portions in the best possible way. The VOB is here (right click and Save As):

http://shelob.mordor.net/dgraft/misc/TNGsample.vob

My humble attempt is here (right click and Save As):

http://shelob.mordor.net/dgraft/misc/trekdivx.avi

The challenge of course is to do it better than me. But be warned, you're going to have to be really good to better this encode (I say with maximum humility). ;)

At the end we will all reveal our methods. Have fun!

[Guest]

Whoops. Download the AVI again. I had a little jerk on the little walking man. That is fixed now.

[Calculon]

As far as I know, threshold2 doesn't do anything for mode=3, only mode=2, I think threshold is used for mode=3. From my limited experience with TNG vobs, it seems to me that threshold=2.0 is much too high.


Thanks for catching that. I guess that's what I get for just pluggng in mode 3 in a mode 2 script...


BTW, as a sidenote, what codec are you encoding with? If it's xvid or SBC, those settings look really aggressive for anything less than 1 ep/CD, in which case, for these horrible ivtcing DVDs, SVCD might be a better choice.



Xvid. 1 episode per CD is what I'm going for actually.

[Guest]

Please post entries or comments about the TNG encoding to the new sticky I made. Thank you.

[sh0dan]

Recieved this file from Donald.


- Slight speedup in Telecide YV12 mode. (no duplicate detection)
- Relaxed width size restriction - YV12 works on all valid resolutions.


Edit: ok - attachments are not working - I'll get in contact with the staff.

Until we can get the file attached, you can download it from this link (http://cultact-server.novi.dk/kpo/avisynth/decomb406b7.zip~). Do NOT use this link anywhere - it is only TEMPORARY, the file will be removed as soon as attachments are working again!

EDIT: Link disabled. More recent version attached below.

[jarthel]

Thanks Neuron2 and shodan. :)

jayel

[Guest]

Attached please find Decomb 4.10 beta 1. The changes are listed below. Please note that some low-level optimizations for YV12 submitted by sh0dan are still pending. I wanted to get the functionality stabilised and tested first.

Decomb Version 4.10 beta 1 Change List
--------------------------------------

[Please refer to the help file for details.]

1. Improved deinterlacing for YV12 (less residual
combing at a given 'dthreshold').

2. Added 'map' option to Telecide and FieldDeinterlace.
This option allows the deinterlacing motion map to
be visualized.

3. Added 'mthresh' option to Telecide. This option can
significantly reduce the processing burden of
postprocessing. It defines a "goodness of match"
criterion for frames coming out of the field matching
process; postprocessing is applied only to those frames
whose field match falls below a threshold of goodness.

4. Renamed Telecide's 'x' manual override to 'v' and added
an 'f' override (for specifying video and film sections).

5. Revised the meaning of the 'chroma' option for Telecide and
FieldDeinterlace. Now, chroma is always deinterlaced
when a frame is detected as combed. The chroma
option now determines only whether chroma combing is included in
deciding whether a frame is combed (full=false). Often, luma/chroma
crosstalk can appear as interlacing and falsely trigger deinterlacing.
The chroma option is now defaulted to false to avoid this.

6. Fixed a problem in YUY2 which caused Telecide to erroneously
report whether a pattern override occurs.

7. Telecide now accepts mod 2 width for input instead of mod 4.

8. 'gthresh' now defaults to 25. 'theshold' defaults to 20.
'dthreshold' defaults to 7.

EDIT: Attachment removed. More recent version attached below.

[N_F]

@Neuron2 - It may be a good idea making a pointer here to the third page on your first post page 1. I almost overlooked it.

[Guest]

You're baffling me. What are you talking about? :)

[Guest]

Sorry, folks, 4.10 beta 1 had a big bug in YUY2 such that postprocessing didn't work right with chroma=false. Hey, that's why they call it a beta. :)

Please get the fixed version below.

[N_F]

I meant that when you press on this thread you may be likely to believe the file available in your first post (decomb406b4 or something like that) is the newest one. Sure ~50 people downloaded this one so far, but if I don't remember wrong the amount of downloads of decomb406b4 (the one from your first post in this thread) were less than 800 yesterday, today it's more.

Suggestion: Remove the old file completely or simply add a comment sending people here to the third page. Perhaps it'd also be a good idea adding the newest version number to the title of the thread?

[N_F]

Regarding map
I tried this setting on an episode where a normal IVTC should be performed:

Telecide(show=true, post=true, map=true, mthresh=5, threshold=150)

The threshold is set so high that combing will come through. I would have thought that with map=true those combings would have been marked in some way, but I wasn't able to see anything in the combed areas. Have i misunderstood the way it should work?


Regarding mthresh
I played around a bit with this with show=true, and I noticed that when mthresh is left untouched (=0 I guess) every frame is reported as postprocessed. With mthresh=5 there are a lot less frames reported as postprocessed.

The question here is: When show=true reports "postprocessed", does that mean (1) the frame has been examined, looking for combes or (2) does it mean the frame has really been postprocsessed, that is some kind of deinterlacement have been made?

If (2), that'd mean as default every frame is postprocessed, that can't be right, can it?


Regarding the help document
Isn't the text size a bit extreme? Looks like 18 or 20 something.

[Guest]

Originally posted by N_F
Regarding map
I tried this setting on an episode where a normal IVTC should be performed:

Telecide(show=true, post=true, map=true, mthresh=5, threshold=150)

The threshold is set so high that combing will come through. I would have thought that with map=true those combings would have been marked in some way, but I wasn't able to see anything in the combed areas. Have i misunderstood the way it should work?You've misunderstood what 'threshold' does. 'threshold' sets the sensitivity for the test of whether a frame is considered combed. After that long thread about the difference between threshold and dthreshold, I'm surprised you still confuse these. If threshold is too high, no frames will be considered combed and the help for 'map' says that the map is shown only for frames considered combed. Try setting threshold=0 to get the maps to show. Then 'dthreshold' will control the detection of combed areas within the frames. Also, you have a high 'mthresh', which will spare some frames from postprocessing.

Regarding mthresh
I played around a bit with this with show=true, and I noticed that when mthresh is left untouched (=0 I guess) every frame is reported as postprocessed. With mthresh=5 there are a lot less frames reported as postprocessed.

The question here is: When show=true reports "postprocessed", does that mean (1) the frame has been examined, looking for combes or (2) does it mean the frame has really been postprocsessed, that is some kind of deinterlacement have been made?There are threee things that can be printed:

1. "Clean frame" -- means wasn't examined for combing

2. "Clean frame [postprocessed] -- means was examined for combing but considered not combed.

3. "Combed frame!" -- means was examined for combing and was considered combed.

If (2), that'd mean as default every frame is postprocessed, that can't be right, can it?"Postprocessed" means the frame is examined and deinterlaced if necessary. See above.

Regarding the help document
Isn't the text size a bit extreme? Looks like 18 or 20 something. It looks fine to me, but I think I know what is happening. I'll see what I can do.

Finally, thank you for your suggestions regarding attachments, versions, etc. I think you will be happy now. :)

[gamr]

just wanted to report that it is all working well for me

mthresh=1.9 is giving me nice results and a noticeable boost in speed and map has been quite useful to tweak settings

only problem is i can never find perfect settings (damm these pal dvds), oh well, cant win them all.

my only question is what do p c and n mean when show=true? im assuming their previous current and next frame but what exactly do they mean?

1 more thing i forgot, does chroma=true do anything useful in yv12?

[Guest]

Originally posted by gamr
my only question is what do p c and n mean when show=true? im assuming their previous current and next frame but what exactly do they mean? Please read APPENDIX A in the help file. There you will find that the field match for each frame involves comparing the bottom field of a given frame to the top frame of the previous (p), current (c), and next (n) frames. In the show output, the letter displayed for a frame is the chosen (best) match of the three just mentioned, and which is used to assemble the output frame. For example, if n is printed, the output frame is made from the bottom field of the current frame and the top field of the next frame.

1 more thing i forgot, does chroma=true do anything useful in yv12? Yes. It has the same effect in YUY2 and YV12 color spaces, as described in the help file and the changes log text file. As described, chroma=false excludes chroma combing from the decision about whether a frame is combed. This is useful for preventing frames from being erroneously considered as combed due to luma/chroma interference (the commonly excountered rainbowing effect caused by poor comb filtering). If you have a clip that does not have luma/chroma interference, setting chroma=true can improve the detection of combed frames in cases where the combing affects only the chroma planes (you can have pixels that have colors that are different but lumas that are the same or very close).

Thank you for reporting your results with the new version.

[gamr]

my bad, i should'v explained that a bit better, now that i read it again i see why you replied with that. what i want to know is what the numbers on p c n mean

eg.
p=499 c=249 n=139 [using n]

im assuming they mean what it considers are combed artifacts or something similar?

now that decomb has its map setting im just trying to tweak it just right for my sources so im trying to understand everything that it gives out incase it can help with it