Decomb 5.0.0 beta 15: Fix for crashing problem will, available, carefully, reference

andy

A beta of New Generation Decomb is now available for your testing. Please carefully read the accompanying tutorial and reference manual as a lot of things have changed in Telecide(). FieldDeinterlace() and Decimate() are unchanged.

Get the beta here:

dgraft/decomb/decomb500b15.zip

As always, feedback will be greatly appreciated.

Thanks neuron2.

I'll give it a try and I'll come back when I have some results.

EDIT :
I've tried Decomb 5.0.0 beta 1 with some anime source that I had, reading your tutorial to set the parameters. But I have a question : is the possibility to match the current frame with the next one gone ? I ask this because new generation Decomb has problems where the good old Decomb 4.10 beta 2 chooses to match the frame with the next one. And with show=true, Decomb 5.0.0 beta 1 doesn't show any information about quot;nquot; anymore, just about quot;cquot; and quot;pquot;.

I've taken 2 screenshots, the first with Decomb 4.10 beta 2 which chooses to match the frame with the next one, and the second with Decomb 5.0.0 beta 1 which chooses to match with the previous one (it seems it doesn't care about next frame).
Sorry but the images are PNGs which are about 400 kb.
Decomb 4.10 beta 2
Decomb 5.0.0 beta 1

I hope you'll understand my problem. It seems obvious to me that Decomb 4.10 beta 2 performs better than Decomb 5.0.0 beta 1 on this source (I have this problem very often on the anime source tested).

The function calls were :
- Decomb 4.10 beta 2 : Telecide(post=false,blend=true)
- Decomb 5.0.0 beta 1 : Telecide(order=1,post=0,show=true)

It doesn't perform any better if I use guide=1 (I have some 3:2 pulldowns on this source). I have chosen order=1 accordingly to the test suggested in your Decomb 5.0.0 tutorial.

Damn great, DG!!!I've been waiting for this since I read your journal.
Infinite thanks!!
I'm gonna give it a shot, right away!

=======
Edit: So far it's just great!
I assume quot;vthreshquot; is similar to the quot;thresholdquot; in v4. right? It seems to me that vthresh becomes more accurate now!(Maybe because it has more divisions than quot;thresholdquot;?).
Edit in this edit: Beyond that, what previously version4 had to decide as combed frames (even at a very low threshold) now have been quot;decombedquot; as clean frames, progressive but no interlaced, and in my eyes they are indeed clean now

But one thing, DG, is quot;dthresholdquot; actually working? When I wasn't touching it, it was fine; but when I specified dthreshold=7 in Telecide(), vdmod reported quot;...Telecide does not have a named argument 'dthreshold'...quot;
My script was this:
LoadPlugin(quot;MPEG2Dec3.dllquot;)
LoadPlugin(quot;Decomb.dllquot;)
mpeg2source(quot;01.d2vquot;,cpu=4)
ConvertToYUY2()
Telecide(order=1,guide=1,vthresh=13,dthreshold=7,post=2,show=true)
Decimate(cycle=5,quality=3)

By the way, my material is a normal movie(well, an mtv), not an anime.
=======

~~~~~~~
2nd Edit:
Comfirmed by my friend, quot;dthresholdquot; didn't work. Instead, he found out that quot;dthreshquot; worked(at least no error reported by vdmod). The manual should've been updated now.

hi some feedback and questions

why is field dominance/parity now important?
is it working correctly?  on some bottom-field PAL material i have, telecide(order=0) seems to leave more combed frames than telecide(order=1)

also, is telecide(post=1) meant to display some metrics?  i don't see any

@cipher

1. Yes, dthreshold is now dthresh. It's mentioned in the Tutorial but I forgot to update the reference manual. Thank you for pointing it out.

@wotef

vmetric is displayed only when post != 0. When post=1 vmetric is calculated and displayed but not used.

Are you reading the journal at my web site? It describes why field order is now important. Basic summary: it's faster and less error-prone to do 2 comparisons rather than 3. Did you verify the field order using the technique I described in the tutorial? If so, and you still think there is a problem, please make a source clip available for my inspection.

@HomiE FR

Yes. The forward match is gone. At some scene changes you may generate a combed frame that will be deinterlaced. Is this occurring for you only at some scene changes? If not, please make a source clip available for inspection. I personally do not see this as a big deal as long as it is limited to some scene changes and since postprocessing is now so fast.

@neuron2 : These problems don't only show up on scene changes, but all over the source (sometimes it's really visible, sometimes not) and postprocessing (deinterlacing?) can't do anything good to these frames. I've tried to lower the vthresh so that these frames are postprocessed, but it is not any better...
And I haven't any knowledge on deinterlacing, but the forward match wasn't supposed to be useful elsewhere than only some scene changes ? On the source I'm talking about, the forward match quot;nquot; was used very often ! And now the frames where quot;nquot; was used with Decomb 4 have the problems I've described above (maybe not all, but many since I can see the problem on different scenes).

I'm ready to give you a part of the vobs I'm playing with (a Z1 anime) but I don't know how you want the source clip. Do I have to cut the vob and give you a part, ar do I just compress the part unprocessed with MPEG-4 (XviD) @ quantizer 2 ? If you want a vob file, I don't know how to cut easily a vob where I want to (Google didn't find what I was looking for) so I will need your advice.

Thanks for checking my problem !

@Homie FR

It's really important to get me this clip!

I need a good-sized VOB fragment. Use VOB splitter or other tool, available on  download page.

Thank you!

didn't know about your journal til your reply - look forward to reading it!

i did some more testing on 10 random/different clips (all verified bottom-field dominant) and take back what i said

on 8 of these clips, specifying order=0 gave better frames

on the other 2 clips, there was no difference in quality between specifying either order (both left some residual combing at default settings) - and for these two, tomsmocomp seemed to fare better than telecide - presumably these were quot;true videoquot; clips

@wotef

I can only comment on specific clips if you make them available for inspection.

You can tell if a clip is video by doing separatefields and then stepping through it. If there is motion only on every other field (or every second or third for 3:2 pulldown), then it is progressive. If there is motion on successive fields, it is video.

ah, thanks, ok, that helps a lot, yes they were both video

Originally posted by neuron2 FieldDeinterlace() and Decimate() are unchanged.

so does this mean there is no difference in those two to their predecessors in v4? or did you just not change any parameteres?

thanks for the great new filters, going to do some testing now (:

steVe

Originally posted by neuron2
... At some scene changes you may generate a combed frame that will be deinterlaced. Is this occurring for you only at some scene changes?
For me it is ocurring at not some but almost every scene change. Also, I get many interlaced (and quot;out of patternquot;) frames in static scenes where only small objects/parts are moving...

Tweaking GThresh: The show / debug options output include two metrics: p and c. I understand they are Previous and Current. Am I right? It would then be great to see in the show/debug output the metrics for Predicted and Calculated. I've been using different values for Gthresh: 0, 10, 100, even 1000, and haven't been able to undestand the difference in behavior.

In latest betas of Telecide v4.10 I was using mm=2: matching mode considering only Current and Next. In general it was giving me better matches for my TV captures. Will there be an option to do something like that in Decomb 5.xx?

Great improvements! Thanks again, :J

@neuron2 : I've cut a part of a vob where the artifacts are visible. It's about 72 MB. But I don't know how I can give it to you. We can do it through IRC I guess, or through ICQ or anything you want. My connection is a DSL line, so 128 kbps UP (16 KB per second).

My ICQ number is 76019744 if you want to contact me directly.

@killingspree

They are identical to the previous versions. Is that clearer than unchanged?

@JuanC

You have to provide a source clip if you want me to look at any issue.

P = Previous, C = Current

I will add display of the predicted and calculated metrics. Gthresh sets how big of a difference between those two can exist without preventing a pattern override. Set gthresh=0 and all overrides will be prevented. Set it to 100 and none will be prevented.

Setting mm=2 in old Telecide is exactly the same thing as not doing the backward match operation, i.e., it makes Telecide field order dependent. If you are having difficulty with a specific clip in this regard, please make the source clip available for inspection.

@Homie FR

I will send you FTP access details in a PM.

Originally posted by neuron2
Setting mm=2 in old Telecide is exactly the same thing as not doing the backward match operation, i.e., it makes Telecide field order dependent. If you are having difficulty with a specific clip in this regard, please make the source clip available for inspection.
As soon as I get home back from work I will chop a relevant part of one of my unprocessed mpeg2 tv captures, about 10-20MB, and I would also appreciate if you send me a PM with details on temporary FTP access. (I´ve got a slow cable connection)

Thanks, :J



@neuron2 : I just sent you a PM. The vob file should be ok. Thanks for trying to locate the problem, I'll keep checking this thread for news !

I was wondering about the handling of fade in/out in the new decomb, so I tested it on quot;Zone of the Enders: Idoloquot; and noticed that while the frame was mostly black with the white intro credits fading in, the vmetric was very small (started at vmetric=0.000000), and slowly increased as the credits bacame brighter (up to vmetric=31.xxxxx).  The effect was that even though the credits had combing, telecide wouldn't detect them as combed, but when they reached their full brightness, it would detect them as combed, event though they were not.Code:
Telecide(order=1, guide=1, vthresh=33, post=2, blend=true, chroma=true, show=true)
Decimate(cycle=5, mode=2, quality=3)
Not sure if this is a special case or what have you, but I figured Id point it out and be on the safe side.  If Im wrong, please feel free to bring out the tar and feathers.

Originally posted by DoW
Not sure if this is a special case or what have you, but I figured Id point it out and be on the safe side.  If Im wrong, please feel free to bring out the tar and feathers.
Does Decomb 4 handle it any better?

Originally posted by neuron2
@killingspree

They are identical to the previous versions. Is that clearer than unchanged?  

oh well... thanks for the info... i guess /me was stupid once again. i just checked the new version on some captured pal material and it worked well.

thanks for your work
steVe