Vthresh value for telecide

[MarkGrigsby]

I have read the tutorials on using the decomb filter, but I'm still having trouble figuring out a 'sensible' choice for the vthresh parameter in telecide.

My IVTC is always on 1080i film material (never anime), and my typical script looks like this:

loadplugin("C:\Program Files\dgmpgdec\DGDecode.dll")
mpeg2source("D:\DVD\Editing\Revelations\s01e01.d2v")
Telecide(order=1, guide=1, post=1, vthresh=30)
Decimate(cycle=5)
LanczosResize(720,480)

I don't want to spend a lot of time checking through the material each time, so I'm happy to gamble on an 'average' value for vthresh. But from most posts on here, and in the tutorial, it looks like '30' is a good choice, whereas the default value in the filter is '50'. I also saw that for 'good quality' material then there is less need for post-processing.

To be honest I'm a little confused by all this! I don't want to break any forum rules by asking 'what's best', so my question - IS THERE a 'suggested' good choice for vthresh in my case, or is that just impossible to say?

I would also be grateful if someone could explain why there is any need at all for post-processing? I thought telecine'd material is 3:2, so you can always get the original frame back. But I must be wrong??

Finally (I know a lot of questions, sorry I'm still learning!) - can someone please tell me what the 'cpu=x' parameter does in mpeg2source, and what is the default value?

THANK YOU to anyone who has time to reply :)

[Guest]

1. There's no good all-purpose threshold, because the nature of the clip is so important. You might have some clip that is really clean except for a few combed scene changes; for that you'd want a high vthresh because scene cuts are generally badly combed and you don't want to touch all the other good progressive frames. Or you might have another clip with hybrid video/film and you need to be sure to catch the video portions fully, so you'd use a lower vthresh than for the first example. The Quick Start guide explains the idea: use as high a vthresh as you can get away with.

2. The Decomb reference manual in the section "Notes on Field Matching" explains some of the reasons why post-processing may be necessary. Even when the source is flagged MPEG2, there can be combs due to careless editing/authoring. For non-flagged content, field matching is an imperfect process, and sometimes fields cannot be properly matched at all.

3. Formally:

cpu : 0 to 6 (default: 0)

Post-Processing options. (Y=luma C=chroma, H=horizontal V=vertical)
- 0 : DISABLE Post-Processing
- 1 : DEBLOCK_Y_H
- 2 : DEBLOCK_Y_H, DEBLOCK_Y_V
- 3 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H
- 4 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V
- 5 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y
- 6 : DEBLOCK_Y_H, DEBLOCK_Y_V, DEBLOCK_C_H, DEBLOCK_C_V, DERING_Y, DERING_C

Informally, "deblock" is a filtering that tries to smooth out those square blocking effects you sometimes see. "dering" attempts to filter out ringing artifacts. By selecting the right cpu number, you can select some combinations of which filters to use, whether to apply them to the luma and/or chroma planes (Y/C), and whether to apply them horizontally and/or vertically (H/V).

The DGDecode parameters are documented in the accompanying manual. Cyberia is preparing new, improved documentation that will ship with the next release.

[MarkGrigsby]

Thank you! Very helpful reply, really much appreciated :)

[GrofLuigi]

My observation:

Although mpeg2source's deblocking/deringing feature is very nice and usually the video looks more pleasing to human eye, it can 'confuse' ITVC-ining. It cost me a lot of lost hours and pulled hair (possibly because I overdid it. It's either cpu=0 or cpu=6 for me :) ).

I maybe completely wrong here, but I can't find any other explanation (i.e. all other parameters being equal, decomb not locking pattern with cpu=x).

I think this should be mentioned in some FAQ, or someone (neuron2?) could suggest good value for IVTC (horizontal direction only?).

GL

[Guest]

@GrofLuigi

That's a very interesting point that I've never thought about. Thank you for raising it. Would you be able to make available a small VOB fragment that demonstrates this effect? You could post a link to it or upload it to my FTP server.

[Cyberia]

Deblocking in DGDecode shouldn't affect the IVTC process if you are using the iPP parameter. And the latest versions automatically set this parameter accordingly on a per-frame-basis.

However, that assumes everything is working as designed. If you have an example that disproves this, please upload it.

[GrofLuigi]

About uploading: I'm on dialup (for now) and it's very hard for me to upload something larger than a megabyte. Never mind the time spent, but the connection usually "breaks" at some point and... you know (I mean the ftp or whatever connection, not phone line going down).

Nevertheless, I will try to dig up something, but unfortunately that too is gonna take some time (I am very busy with work right now). Meanwhile, I think this theory of mine can be quite easily checked with any not-so-clean a source (that shows substantial visual improvement with cpu=x). I call it theory, but I could swear that I did the test and it made the difference -- alas, when I need to prove it I have no evidence. :)

@Cyberia: I always use the latest version of dgmpgdec (sometimes even betas) and I noticed this thing I'm talking about somewhere around the versions 1.10 - 1.20. I have since been using plain Mpeg2Source () and haven't checked much against this. I haven't used iPP after it was changed to bool, assuming it works well (and it works, as far as I can tell).

Again, I repeat this is just a theory and I still don't know much about the inner workings of these filters, but it seems logical to me. I promise I will check the (original) DVDs and report back -- as soon as I can.

GL

[GrofLuigi]

I promise I will check the (original) DVDs and report back -- as soon as I can.
Wow, didn't realize how much time has passed...

Anyway, to keep my promise, I repeated the tests with one of the (better) DVDs I *thought* at the time were showing this problem and guess what... there is no difference.

So - no bug report for DGindex and someone would have to think out an appropriate punisment for me. :p

GL