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

[Guest]

Originally posted by gamr
I'm assuming they mean what it considers are combed artifacts or something similar?You are asking me to explain the metric. :eek:

The three candidate frames are each scanned to determine the numbers you see. To get the number for a frame, the frame's pixels are examined, subsampling by 4 in the X and Y directions (i.e., every 4th line and every fourth pixel horizontally is examined). The combing for each pixel is compared against a combing dthreshold of 10 (actually the square root of the nt parameter). If it is a combed pixel, a count is incremented. The number you see is the total count for the frame. So, yes, it amounts to a (subsampled) count of combed pixels. Note that the number is not normalized for frame size, so bigger frames will tend to have bigger numbers. It doesn't matter, because the three frame's numbers are compared and the lowest is chosen.

Generally you expect at least one of the three numbers to be relatively low, indicating a good field match. If they are all high, then there is no good match. For use by the mthresh parameter, the number corresponding to the chosen frame is normalized for frame size and a range of 0.0-100.0. Then if the normalized chosen number is greater than mthresh, the frame is postprocessed (assuming post=true). For tweaking mthresh, it might be better to display the normalized numbers rather than the raw counts.

[N_F]

Originally posted by neuron2
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.
Apparantely I missed this little detail. I reasoned like this: With a high threshold there will be frames left combed, which means I will be able to see the mapping. (I wasn't confused about the difference between dthreshold and threshold... :))

Thanks for clearing all up.

[Guest]

@N_F

Hmm. Never thought of it that way. Makes sense.

I've decided to make a Decomb FAQ to gather up all the useful material inspired by perceptive users such as yourself.

[N_F]

Originally posted by neuron2
I've decided to make a Decomb FAQ to gather up all the useful material inspired by perceptive users such as yourself.
Sounds very nice.

How's the situation with post=true? Will that also only be applied to frames detected as combed? That is, a high threshold would result in no postprocessing (I'm sure I could find out, but I don't have the material on this computer).

[Guest]

@N_F

Setting post=true is the same as not specifying the post parameter (because post=true is the default). It simply enables the entire postprocessing mechanism to operate as I have described. When post=false, frames are never examined for combing after field matching and never deinterlaced.

[Guest]

@N_F

Does the attached help file fix your issue with it?

[N_F]

Originally posted by neuron2
@N_F

Does the attached help file fix your issue with it?
Yes, much better. Thanks :)

[N_F]

First of all, two assumptions (for Telecide) I'm 98% certain are correct but it'd be nice if you could confirm them to avoid possible basic misunderstadings (you may already have answered some of this in other words... but still):

1) If threshold determines that a frame is not combed, this frame will be ignored for all further possible operations by decomb.

2) If post=false, then threshold (and consequently d and m thresh) will be ignored.

(If you read back on my previous posts in this thread you may notice that there are some errors that will hopefully be corrected by these assumptions)


Second, I have this idea for the mthreshold. I have no idea if it's realistic or even a good idea, you be the judge of that. Basically there'll be another parameter that can be set to true or false. If true, mthresh will be adaptive/automatic according to something like this:

main-algo
1) Set mthresh=1
2) If a frame is found that needs to be postprocessed within 5000 frames, goto backoff-algo
3) Else, set mthresh = mthresh + 1
4) goto 2)


backoff-algo
1) mthresh = mthresh - 0.5
2) Return to 2) in main-algo


*It would probably be a good idea to lower the mthresh increase as it grows higher as 1 seems rather high (but it may be justified for the first few steps IMHO).
*A max value of ~5 would probably be a good idea.
*I don't know if 5000 is a bit too high... guess it depends on what kind of mthresh intervall you'd use for step ~3+


The big advantage of this is of course that you could benefit from the extra speed of mthresh without having to tweak the parameter all the time while at the same time being more or less certain none or very few (depending on settings) interlaced artifacts will slip through.

What do you think?

[N_F]

Does the silence mean you don't like the idea (for whatever reason, perhaps it's not even doable?) or that you're thinking about it?

[Guest]

As they say in financial circles, "past performance is no guarantee of future results", and I would add that future performance is also no guarantee of current results. I've experimented with these kinds of time-adaptive algorithms for other purposes and found them unsatisfactory.

If you set a conservative 'mthresh', you can save a lot of processing with little danger of passing combing through. That is enough for me.

Your questions:

> 1) If threshold determines that a frame is not combed,
> this frame will be ignored for all further possible operations
> by decomb.

Well, of course you mean "by Telecide", or "by FieldDeinterlace". E.g., it won't stop decimation if Decimate() is invoked. :p

Just to pick more nits, even if the frame is declared not combed by Telecide(), all processing doesn't stop. Telecide() may still write the show=true data onto the image, and it may write hints to Decimate() in a special hidden place that nobody knows about (except maybe sh0dan). :)

But for all practical purposes, yes.

> 2) If post=false, then threshold (and consequently
> dthresh and mthresh) will be ignored.

Yes, unless deinterlacing is forced by a manual override using the 'ovr' option.

[Guest]

@N_F

600+ posts and you don't have an avatar yet? Get with the program!

[kxy]

avatar izzzt death.....:devil:

[Didée]

Dear Mr. Graft ;)

may I come up again with that idea already mentioned before in another thread: scene change detection for "fielddeinterlace".

I'll try again to explain my motivation.
When working with poorly pre-processed material (e.g. PAL transfers of Star Trek, and such things), often there is not much left to reconstruct, and the only thing left to do is to perform fielddeinterlace() with blending, to keep at least the motion smooth.
But that way, also very much scene changes get blended together. Not only that that looks particular annoying. Moreover, at least XviD tends to not set keyframes on most of these blended scenechanges, so that the codec often runs up to the maximum I-frame intervall, resulting in the noticeable "keyframe refresh effekt" in the middle of a scene. Also, seeking in the stream is not exactly optimal.

All of that could be resolved if it were possible to tell fielddeinterlace() to generally use blending, but to interpolate around scenechanges.

Hoping I was more understandable this time

Didée

[Guest]

@Didée

Scene detection is very expensive performance-wise. Would you be satisfied with a new manual override to force interpolation on specified frames?

[Didée]

Hm-hmmm.
I perfectly understand that scene change detection is expensive, performance-wise. But my thoughts were about a switchable feature ... maybe like "scenechange=threshold" (similar to temporalsoften), with a default of "0", meaning no detection, and no speed penalty. If one sets a threshold manually, one has to live with a little slowdown ;)
Manual override would be useful also, of course. However, I love the "set it and forget it" nature of decomb ... seeking through all the complete streams frame-by-frame manually, and noting down all blended scene changes? No, not me, I guess ;)

Anyone else sees the above as a useful feature?
Intercessor wanted!

[N_F]

Originally posted by neuron2
@N_F

600+ posts and you don't have an avatar yet? Get with the program! Happy? :) Now I just got to come up with some nice catchy signature and I'm all set!

It can be a bit unnerving having a high post-count while still being just a regular user. New people trust you more than you may deserve and other people come to expect things you may not live up to... I guess based on theReal's signature he feels the same.


Regarding decomb... I figured something like if the first 5-10 minutes where very nice and didn't need any postprocessing it would very likely be the same for the rest of the movie. But you're the expert; if I didn't trust your word I don't know whose I would.

[sh0dan]

Fairly accurate scenechange detection can be done with the same routines you use in decimate.
For temporalsoften I simply do a "summed abs difference between planes", and it works very well. The main problem could be that in deinterlacing a falsely detected frame is much worse than the impact in temporalsoften.

For instance a panning scene would in many cases be considered "scenechange", which is good for temporalsoften, but in deinterlace this would lead to interpolated frames, which makes them jerky (we want to use blend in panning sequences).

Complete scenechanges (cuts) DO have a larger abs-diff than panning scenes, but they are still not easy to spot accurately. I guess some tests are in place (if Donald has the time). Pans rarely have abs-diff larger than 15, but scenechanges often does (mostly 20-40).

Just realized - you should be able to test this using Conditionalfilter. 2 secs - I'll write a script.

[sh0dan]

You need the latest CVS AviSynth binary (just found a bug in the "show=true" code).


blended = fielddeinterlace(blend=true)
interp = fielddeinterlace(blend=false)
test = separatefields().selecteven()
conditionalfilter(test, interp, blended, "YDifferenceFromPrevious()",">","15", show=true)


It doesn't check between fields, but rather between frames - anyhow it is good enough for scenechange detection. My own initial tests show that it is quite good, and doesn't falsely detect many scenechanges.

[Didée]

Yup, shodan.
Conditional handling was the next thing I was going to try...

BTW, is "ScriptClip" already freezed, or are you still working on it? I have problems to find out what can be done with it, and what cannot.
But that belongs to another thread, sorry Donald.

[Guest]

Originally posted by N_F
Happy? :)Well, it's not Britney.

[HomiE FR]

Didée wrote :
Anyone else sees the above as a useful feature?
Intercessor wanted!

Hi all,

I'm very interested by scene change detection (and interpolation instead of blending) within Decomb, which I always use when I have to deal with PAL anime sources...

For instance, I have currently a few episodes that are waiting on my hard disk drive for this new feature, because I have this problem of annoying blended scene changes. I know that the sources I'm dealing with can't become perfect (I've read many topics about this subject on this forum) but I'm pretty sure that scene change detection in Decomb would be often useful for me (and others that use sources that have the same flaws).

And if I can help with some testing, I'm ready to give you all the feedback needed ! :) Thanks neuron2 for all the work done on Decomb and all your Avisynth filters, I use them all the time.

And thanks all too. ;)

HomiE FR

[Guest]

Can you guys even notice these blends when played at normal speed???

If so, please post a clip that I can look at to see if you are just pulling my leg. :)

[HomiE FR]

I guess it's time for apologies...

I was a bit (maybe even not just a bit) wrong when I said that Decomb was the one which was responsible for these awful blended scene changes... Maybe that's because I always put Decomb in my Avisynth filters when deinterlacing needs to be done.

But whatever, I've tried the same sequence with and without Decomb (FieldDeinterlace to be precise), and these blended scene changes are NOT coming from Decomb, they're all over the source (which is a PAL European Z2 anime DVD, with the crappy NTSC->PAL conversion)...

So I'm sorry for having assumed wrong facts without further testing.

But now that I can ask neuron2 something, I won't miss it :
I think that you've already posted in topics about crappy PAL anime DVDs, so I guess you know a bit the problems of those sources (sorry if it's a bit out of subject here).
Do you think it would be possible to write (I don't ask you to do it) a script which would :
- detect the scene changes (with a threshold maybe)
- replace the frame just before the scene change by the frame just after (which would just mean to duplicate the frame after, which is often clean). Please take in consideration that what I say here could easily NOT be a good solution, but I will think of something which would be better by trying over my samples.

I only think about the general idea, and I think it would be possible (I'm no Avisynth coder, but judging by all the existing filters that I've used).

It would be a sort of Dup, but it would work at the opposite of it, using the frames with a lot of difference (above a threshold specified by a user) to detect the scene changes and use duplicates to give a not-blended output (at least on the scene changes).

About the visual impact of these blended SC, I believe they're not always visible, but when one focuses on them it becomes very annoying... That's why I'd like to get rid of them ! :) I know that the sources that I use are crappy, but the ghosts that are staying on (nearly) EVERY scene change are the most annoying.

Thanks a lot if you read this post.

HomiE FR

[sh0dan]

@HomiE FR: I don't really think that's the job of decomb. Anyway here is a script that does what you need. Again, you need the CVS binary from today - see my sig.


avisource("file.avi")
orgclip = last
nextframe=trim(1,0)
conditionalfilter(nextframe,orgclip,nextframe,"YDifferenceFromPrevious()","lessthan","15")

[Guest]

@Didée

Can you convince me that the blends are bad enough when viewed at normal speed to justify the new work? A sample clip would be ideal.

[HomiE FR]

sh0dan : thanks ! :) I'll try this right now. I've just tried to manually delete/duplicate frames at the scene changes and it has (that's no surprise) worked right. So I guess if I can make it automatic with what you gave me it'll be just fine ! Thanks again and sorry for reporting without (enough) testing.

HomiE FR

[N_F]

Originally posted by neuron2
Well, it's not Britney. It most certainly isn't! ;)

[InfoCynic]

I know this has been requested before, but with this ConditionalFilter talk going on, maybe it can be simplified...

We're looking for a way to deal with hybrid clips (who isn't?!). Some scenes are clearly 23.976 fps FILM and should be handled by Telecide().Decimate(5) with extra params as needed to tweak. Some are clearly VIDEO, but the mode 3 processing just isn't that great... so we want to use something like FieldDeinterlace().ConvertFPS(23.976).TemporalSmoother(..). (Or whatever the function names are, that's the idea...)

So our idea is if we get a function which probably already exists in Decomb that can take a cycle of frames, analyze them for something we're calling "likelihood of FILM" and say, return a percentage that's the "probability" or so that the cycle is FILM. Using the ConditionalFilter, we could imagine something like this...

telec = trim(0,6).Telecide().Decimate(5);
fd = trim(0,6).FieldDeinterlace().ConvertFPS(23.976).TemporalSmoother(blah);
test = trim(0,6);
ConditionalFilter(test, telec, fd, "CycleIsFILM()", ">", "50");

my AVISynth scripting isn't that great so this would have to be adjusted to actually work with processing the whole file and such, but it's the idea I'm interested in discussing. Is this feasible? Pretend we, as encoders, really don't care about speed...

Comments?

[Guest]

Originally posted by InfoCynic
Some are clearly VIDEO, but the mode 3 processing just isn't that great... so we want to use something like FieldDeinterlace().ConvertFPS(23.976).TemporalSmoother(..). (Or whatever the function names are, that's the idea...) You're saying mode 3 could be better, but when I try to decipher from your post what your better process is all I find is "something like".

Please state exactly the process you want to apply to the video portions. Then I can test if it is really better and then contemplate revising Decomb's behavior appropriately. That would be a much more direct solution than messing around with ConditionalFIlter(). Thank you.

[InfoCynic]

For starters, there was this thread that MrBunny and I started a while ago: http://forum.doom9.org/showthread.php?s=&threadid=46905

He outlines some promising methods in there, along with explanations.

Otherwise revisit the ideas that we threw out when Mode 3 first became a possibility... I suggested blending 5 frames pairwise into 4 instead of what you're doing now, because it might reduce the temporal distortion.

I don't expect a perfect solution for TNG because some of its content is neither FILM nor VIDEO but some illegimate child of the two. Better, certainly, and maybe near-perfect for things like B5 that have only limited VIDEO content...

[MrBunny]

It's nice to hear this topic somewhat alive again. What I really meant to say in that long rant of mine in the other thread was something along the lines of what InfoCynic is saying. Simply, it would allow for filtering to based on the metric values that decimate mode=1 and mode=3 use. Whether this is better implemented withn decomb or using the conditional filter is up to people who have more expertise than I.

The rationale as InfoCynic has mentioned, would be to have more specific scripts for the two cases in a hybrid source. It'd allow for the possibility of using TomsMoComp intead of FieldDeinterlace on the NTSC scenes, or heavy temporal smoothing to mask some of mode 1 or mode 3's interpolation.

As was shown in the TNG hybrid challenge thread (http://forum.doom9.org/showthread.php?s=&threadid=43362), the seemingly best approach was to manually splice scenes from two different encodes, one having been IVTC'd normally (for the FILM scenes) and one filtered with MotionPerfect (for the NTSC scenes). What we're proposing would be similar, but more automated. While there is no avisynth port of MotionPerfect, at least with the flexibility of creating our own filterchains (without having to manually splice each scene) a solution giving similar results might be possible.

Thanks

Mr. B

[JuanC]

Has anyone else seen this? Here, some observations from my tests on some TV captures, mostly film with some video portions. This little video portions are most of the time progressive! :confused:

1. When Decimate changes from film (“dropping frame xxx, metric = xxx”) to video (“Decimating All-Video cycle”) you can see that when the first frame in the Decimated All-Video cycle, by coincidence was a duplicate of the last frame in the previous film cycle as a result from telecide, this duplicate gets through decimate, unchanged.

2. Sometimes this also happens (duplicated frames getting through decimate mode 3) during the nonfilm video portion, maybe when the first frame of a new cycle is a duplicate of the last one in the previous All-video cycle?

Here my script:

video=mpeg2source("D:\Videos\TV\F307.d2v")
audio= WAVSource("D:\Videos\TV\F307.WAV")
video1=AudioDub(video, audio)
Trim(video1,1814,5172)
Telecide(guide=1,gthresh=30)
Decimate(mode=3,threshold=1.0,show=true)
@neuron2: I could make an MJPEG AVI file (or chop the mpeg2 file?) with the, interlaced, relevant part of the video if you think it can help in any way...

EDIT: Overall observations. Using mode=3 some parts of the non-film portion play smoother in fact, but some other parts that weren’t jerky with mode=0 got jumpy with mode=3 (maybe because of the duplicated frames getting through, and, could it be that some “cycles” of the film portion are misidentified as non-film and then become “blended-decimated”??). So for me it’s hard to judge which of these two modes is giving me better results with my hybrid video captures. I will appreciate any advice on how to tweak the thresholds so that I get better results from mode=3. Thanks, :J

[bilu]

Originally posted by neuron2
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.


This was mentioned in the past on your site but I can't see it now.
Can we use mpeg2dec3 1.0 now?

[Guest]

@bilu

Yes.

[JuanC]

After some more testing with Decimate (mode=3) on my hybrid TV captures, (please see my previous post in this thread) I got confused:

I thought the threshold2 option should be understood and used the same way as “threshold” in the dup plug-in. But my observations indicate it should not:

1. The difference metrics displayed by show/debug options in Decimate are quite different (they are always lower) to those you get from the dup plug-in. So I guess the threshold2 in Decimate is not the same thing as threshold in Dup???

2. Also, threshold and threshold2 appear to do nothing when using Mode=3: The results are exactly the same no matter what value you use for them. In fact I used: 1.0, 10.0, 100.0, 1000.0 and 10000.0 and they will all produce the same result. Is it supposed to work that way?

Now, some more details on the duplicate frames getting through Decimate mode=3: Because of my doubts about the threshold options, I decided to use the Dup plug-in (copy=true) before decimate in order to make sure that duplicated frames were exactly the same frame so there was no need to tweak the decimate thresholds. Here my observations:

When changing from a “film” cycle to an “all-video” cycle, if the first frame of the “all-video” cycle happens to be a duplicate of the last frame in the “film” cycle, it will get, unchanged, through Decimate, causing a jerky result. In the following examples,
In original frames “U” stands for Unique and “D” for Duplicate of the previous frame; In Decimation: “d” for dropped, “c” for copied, “b” for blended; In Cycle as recognized by Decimate “F” for Film cycle and “V” for “all-video” cycle.

When Changing from Film to Video cycle:Cycle: F---- F---- F---- V---- V----
Orig. Frame: UDUUU UDUUU UDUUU DUUUU UUUUU
Decimation: cdccc cdccc cdccc cb bc cb bc
Problem: XWhen changing from All-Video to All-Video cycle:Cycle: V---- V---- V---- V---- V----
Orig. Frame: UUUUU UUUUU UUUUU DUUUU UUUUU
Decimation: cb bc cb bc cb bc cb bc cb bc
Problem: XI got rid of many of the second kind of duplicated frames (between "all-video" cycles) by using dup (maxcopies=1, copy=true, blend=true) just before Decimate, but then I got some problems with the static scenes.

So finally, I will appreciate some clarification/recommendation on the use of thresholds for Decimate, and I would like to point at what could be a great new feature for the duplicate detection engine in Decimate and Dup: An exclusion band (y0-y1, like the one in telecide) to take care of subtitles.

@neuron2: I would like you to take a look at an MPEG2 unprocessed clip (about 11MB) to better show you what my problem is, but I have no access to http/ftp servers and I think e-mail would not suffice. Could there be a way to send it to you?

Thanks, :J

[Guest]

JuanC, thank you for your valuable feedback on Decimate(mode=3). It has brought to light one bug that I have now fixed. Please get Decomb 4.10 beta 3 from here:

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

Use this new version in working through the answers I give to your questions below.

Originally posted by JuanC
1. The difference metrics displayed by show/debug options in Decimate are quite different (they are always lower) to those you get from the dup plug-in. So I guess the threshold2 in Decimate is not the same thing as threshold in Dup??? The two metrics may not be commensurate because Decimate subsamples in some quality modes. Have you compared them when quality=3?

2. Also, threshold and threshold2 appear to do nothing when using Mode=3: The results are exactly the same no matter what value you use for them. In fact I used: 1.0, 10.0, 100.0, 1000.0 and 10000.0 and they will all produce the same result. Is it supposed to work that way?Only threshold is relevant, not threshold2 (see the help file about mode=3). Here is the algorithm. It is applied at the beginning of each cycle.

1. assume film cycle.
2. if the metric of the closest dup in the cycle > threshold, then assume video cycle.
3. if hints are coming from Telecide (guide=1), then if Telecide thinks any of the frames in the cycle is "out of pattern", then assume video cycle.
4. if film cycle, decimate normally; else decimate the cycle using blending.

You can see then that sometimes Telecide can overrule the threshold test. To isolate the threshold test and see its effect, set guide=0 to Telecide. This will disable the hints. You should then be able to see that threshold has an effect on which decimation strategy is used for the cycle. My testing indicates that it is working in the new version. Please advise if you see any problem with it.

When changing from a “film” cycle to an “all-video” cycle, if the first frame of the “all-video” cycle happens to be a duplicate of the last frame in the “film” cycle, it will get, unchanged, through Decimate, causing a jerky result. I believe it. Hopefully, film/video transitions are infrequent (when the algorithm is working well, see below).

So finally, I will appreciate some clarification/recommendation on the use of thresholds for Decimate, See the explanation above. Only threshold is relevant for mode=3, and you can disable Telecide hinting to better tweak the threshold. As stated in the help file, set the threshold just above the metric of your duplicates. Then when a cycle without a duplicate comes along (video), it will force video-style decimation.

and I would like to point at what could be a great new feature for the duplicate detection engine in Decimate and Dup: An exclusion band (y0-y1, like the one in telecide) to take care of subtitles.Explain and justify this if you want me to consider it.

Now, I want you to know that the code in Telecide for detecting film versus video is not great, because it relies upon the pattern guidance, and that can take a cycle or more to get back in sync. Be advised that I am now working on a new filter specially designed for 3:2 IVTC that will resync as soon as possible, as well as work correctly with timeline random access (Telecide's pattern guidance does not). This will hopefully solve your remaining difficulties.

@neuron2: I would like you to take a look at an MPEG2 unprocessed clip (about 11MB) to better show you what my problem is, but I have no access to http/ftp servers and I think e-mail would not suffice. Could there be a way to send it to you? I don't think I need to see it, unless you feel I have missed some important point in how I answered you.

Thank you once again for your highly useful feedback.

[JuanC]

Originally posted by neuron2
Please get Decomb 4.10 beta 3 from here:... Great! will test immediatelly.The two metrics may not be commensurate because Decimate subsamples in some quality modes. Have you compared them when quality=3?Yes, I did. I will do some more testing.Explain and justify this if you want me to consider it. Many of my clips are TV captures of telecined material, and some of them are cartoons, with electronic subtitles at 29.97fps, sometimes after using telecide on them, duplicated frames are measured as non duplicates beacuse of some slight differences in the subtitles. By excluding the area where subtitles are, they would be correctly detected as duplicates.... Be advised that I am now working on a new filter specially designed for 3:2 IVTC that will resync as soon as possible, as well as work correctly with timeline random access (Telecide's pattern guidance does not). This will hopefully solve your remaining difficulties.This will be really great!!! :cool:I don't think I need to see it, unless you feel I have missed some important point in how I answered you. OK, I agree with you. You haven't missed anything.;)Thank you once again for your highly useful feedback. Thank YOU! :D :J :D

[JuanC]

Originally posted by neuron2
You can see then that sometimes Telecide can overrule the threshold test. To isolate the threshold test and see its effect, set guide=0 to Telecide. This will disable the hints. You should then be able to see that threshold has an effect on which decimation strategy is used for the cycle. My testing indicates that it is working in the new version. Please advise if you see any problem with it. It's working great now! :D

I disabled Telecide hints by setting guide=0. So threshold now works all over the video, and many cycles that were mistakenly identified as "all-video" (because my clips some times don't follow the pattern) are now correctly identified as "film". To compensate for the missing guidance, I tested the different settings for matching mode ("mm" option) and found that mm=2 makes better matches on my clips. It's working really great! After using decimate (mode=3) this way, I can hardly find duplicated frames now. Thanks again! :J

[InfoCynic]

mode 1 is completely ignoring my thresholds. (I'm using 4.10b3) I use show=true and every cycle is passed completely through, which I don't want. I can use mode = 3 and show = true to see what the appropriate tresholds are...

Telecide(threshold=9,chroma=false,dthreshold=5,show=false)
Decimate(mode=1,threshold=999,cycle=5,show=true,quality=3)

Really, I want Decimate's threshold to be about .5 or so, but since frames are supposed to be passed through only if metric > threshold, you'd think a thresh of 999 would effectively prevent anything from passing through. I confirmed that it's not the output of show=true, either... there are near-zero metric frames being passed through, which isn't very good.

[JohnMK]

Hey Don,

It's probably best to attach it at the top post.

[Guest]

Originally posted by InfoCynic
Really, I want Decimate's threshold to be about .5 or so, but since frames are supposed to be passed through only if metric > threshold, you'd think a thresh of 999 would effectively prevent anything from passing through. I confirmed that it's not the output of show=true, either... there are near-zero metric frames being passed through, which isn't very good. Let me explain how it is supposed to work and then you tell me if it isn't doing that.

Out of each cycle, one and only one frame is selected for decimation. Then that one frame can be either blended or not blended (passed through). If the difference metric of the frame is less than the threshold it will be blended. Are you perhaps expecting all frames in the cycle to be blended?

If you set threshold to 999, one frame in each cycle will be blended. My testing shows that it works as described except that sometimes you may not get a blend in the first cycle (because there is no frame number -1).

@JuanC

Glad to hear it is working OK for you now. Thank you once again for pointing out the problem.

@JohnMK

Good idea. I'll do that.

[InfoCynic]

No, sorry, I posted in a hurry and should have chosen my words more carefully. I'm familiar with how this is supposed to work. One frame should be blended in each cycle at thresh 999. When I turn show=true on, what I see is every single frame passed through, resulting in dupe frames in the FILM portions. If I use the exact same settings except mode=3 in decimate, I see "drop frm XXX metric = Y.YY%" or, changing to thresh = .5, I see a mix of "decimating all-video cycle" in there in the VIDEO portions.

[cipher]

Hi neuron2 :)
I'm not sure, but it seems to me that Decimate() with "mode=3" and/or "threshold" is not quite stable.
Before the first time I applied the para "mode", no error had ever occured even once to me. When I used "mode=3"(I didn't try the other 2 modes), sometimes it was okay; but sometimes it wasn't. vdmod(version 1.5.11a) stopped encoding unexpectedly(not crashed, but some frames hadn't been encoded yet). And the "status" said "error" when I checked the "Job control".
It was an anime that was encoded(DragonBall Z, Trunk's History). Say vdmod stopped at the 14000th frame. I trimmed the range to (13000, 15000) to doublecheck if it was the 14000th frame that went wrong. But this time the 14000th frm was okay, vdmod passed it through, but instead, say, vdmod erred at the 14500th frm.
And I noticed these:
Sometimes when vdmod stopped, an error message popped up, saying "access violation" blablabla, sometimes not, vdmod just stopped.
I applied C3D also, with C3d, it was always in the 2nd-pass that vdmod erred, and the 1st-pass was done completely(and correctly?:))
With sh0dan's MipSmooth, I didn't try a 2 pass encoding, but vdmod stopped when it was a "1 pass - quantizer" encoding(still at the 14000th frame as I remembered).
Using decimate's default setting(mode=0, threshold=0.0), with "cycle=5, quality=3" though, vdmod was happy.

So I concluded it was "mode=3" and/or "threshold" that was/were a little unstable, but still daulted if it was just my cpu that was unstable(because of the "access violation" message).

These were the settings when vdmod got errors:
Telecide(guide=1,threshold=8)
Decimate(cycle=5,mode=3,threshold=1.8,quality=3)

Correct me if it's just my wrong settings(thx!), and if it is a bug, I'll still be happy reporting this so that we can improve decomb.:)

Edit: or maybe it's just vdmod 1.5.11a? I've just read something about its instability.

[Guest]

@InfoCynic

You're right. There was a bug. I have posted the new version at the first post of the thread: Decomb 4.1.0 beta 4. Thank you for calling it to my attention.

When Telecide() has guide=0, Decimate() was seeing no film/video hints and assuming it was video. I made him assume it is film when no hints are present. That enables the blending qualified by threshold.

New generation Decomb lets you disable hinting so you can use only the thresholding in Decimate() without having to set guide=0. The alpha release just needs help files. I going to make a reference manual like the current one and a user manual to get people started quickly.

@cipher

No problems here or reported by others. If you've recently installed new versions of other programs, I suggest you back them out and try again.

[cipher]

Sorry, neuron2, my fault, and I found it was actually avisynth. The one I've got errors was the version "Avisynth 2.5.1 May 21". After I installed back the version provided by sourcepage (AviSynth 2.5.1 Beta 2003-03-12 15:00), nothing bad has happened.:)

[unimatrixzer0]

wasn't there a beta 15 or 16 for decomb 4.10 for avisynth 2.5? right before the decomb 5.00 betas started.

[Guest]

Decomb 4.1.0 beta 4 was the last version in the 4.x.x line.