IMO DCTFilter should be the last item in the script, even after the borders. The author suggested this when he released the filter. I haven't done any filesize compares but I trust him :wink:

Thanks all :) I'll try the script right away. I see your not using Limiter() and scd_trigger What is the reason for that?

Ok, guys, check this script out :) By using Deen() + DCTFilter(1,1,1,1,1,1,0.5,0) file size goes way down while video quality goes up :)

nf=0
GripCrop(480,480,overscan=2,source_anamorphic=fals e)
GripSize(resizer="BiCubicResize")
Undot()
Deen()
Asharp(1,4)
STMedianFilter(8,32,0,0)
MergeChroma(blur(1.52))
MergeLuma(blur(0.2))
SwitchThreshold=(Width<=352)?4:(Width<=480)?3:2
ScriptClip("nf=round(YDifferenceToNext())"+chr(13) +"nf>=SwitchThreshold?unfilter(-(fmin(nf*2,100)),-(fmin(nf*2,100))):TemporalCleaner(6+nf,11+nf)")
GripBorders()
function fmin(int f1,int f2){return(f1<f2)?f1:f2}
DCTFilter(1,1,1,1,1,1,0.5,0)

Let me know how you like it

oh yes Holomatrix,

i did tests with deen and it's very cool. :wink:

but it don't make your encode too slow? :?

Found no speed decrease :) If any it would from DCTfilter but very small.

Deen is a convolution filter as is StMedianFilter. Using both is perhaps "too much". For sure file size goes down, but I fear details level also.

You're also using a fairly high Luma-Blur Value in your script (0.2), which will for sure lead to a much smaller filesize, however, as Phil said, details will not be preserved very well the way I see it. :?

I find that I still get tiny blocks in the video when I look close, is there anything in the script that I can modify to blend these blocks better? Blockbuster(dither) does not seem to help enough. Since I don't really know what all the commands in the script mean can I add scd_trigger or Limiter or up some values in the script? Thanks

Question for both Jorel and Holomatrix. I noticed that your Undot and Asharp lines were both after Gripfit, but I thought Jorel had already found that they are better placed *before* resizing (like in Kwag's MA script). Any reason why they're back down there now?

J-Wo my friend,
in the script that i posted i don't change the place of the filters.
and i'm using that script...asharp and undot are before Gripfit
giving better quality in the image and less size!

:wink:

Okay Jorel, now I'm confused! :? In page 1 of this thread you posted the following code:So here you have Undot and Asharp AFTER Gripcrop and Gripsize. Is this an error then?

oh yes, you're not confused and you're right !
d&c(gentle giant) where are you?
change your username with me d&c!

i forgot,sorry J-Wo!
i update the script like Kwag's MA but using temporalcleaner,
like Phil recomendations,then....
take undot and asharp to before Gripcrop.....like this:

nf=0
Undot()
Asharp(1,4)
GripCrop(480,480,overscan=1,source_anamorphic=fals e,dest_anamorphic=false)
GripSize(resizer="BiCubicResize")
.....etc!

this is right!
:wink:

I didn't think it really made a big difference but to each his own. What was the reason we took out Limiter() ?

Because I decide to and Jorel stuck to my advice :-).

I don't remember where I justified that choice but the idea is that TMPGEnc already does this limitation by defautl. So, why doing this twice ?

If you want to know where it's done in tmpgenc, it's there : settings, quantize matrix, output YUV as Basic YCbCr and not CCIR601. Unchecked (the defautl) = same effect than Limiter().

Ok, so I guess I'll leave it out then and keep that option unchecked. KWAG still has it in his optimal script that's why I was wondering.
Thanks

Holomatrix,

the Phil explanations about limiter are here in this same thread,page 2:

http://www.kvcd.net/forum/viewtopic....r=asc&start=16

:wink:

I don't see what explanation you are referring to but "Limiter" is entirely different as "output YUV as Basic YCbCr and not CCIR601". The first one just round [0,16] to 16 and [236,255] to 236, while the latter _scales_ [16,236] to [0,255] when leaving it checked (and not scaled when leaving it unchecked).

I don't know where you find that TMPGEnc scales up and not just clip values (if you can tell me where it's writen :?:). Btw, beside this thin diff, and despite what you seem to tell (do I misunderstand it ?), the result is the same : you end with values ranged from [16,235]. It's clearly said in the balloon that pops up on the screen when you let the cursor on the checkbox for a while (actually, with tmpgenc the lower limit is 8 and not 16).

So the question is still the same : why doing this twice ?

The resulting range is the same, but the result itself not (the values are distributed differently).

example: suppose pixel 1 has luma 24. With limiter this value remains 24. With the TMPGEnc checkbox it is changed to

y = x/2 + 8 [just an approx., don't know the exact formula]

x = 24 gives y = 24/2 + 8 = 20

I don't have the manual. But you always can do some tests to check this.

I don't have the manual. But you always can do some tests to check this.[/quote]

So it's just a supposition ? But it's not that is said in the pop-up help (balloon). The balloon said exactly this : "Then Y Mpeg range is 8-235 (and the help talk about 16-235 !), not 0-255". I don't see there any evidence of rescaling. So ? Did you make yourself any check or do you just take this out of your brain ?

BTW the correct formula is :

if input is [0,255] and output is [8,235], the right formula is :

y=x/255 * ( 235-8 ) + 8 = 0.89 x + 8

So x=24 becomes y= 29. What was I called a thin diff, but you're right, it is not so thin.

The problem there is to know who is right.

I can't imagine that it wouldn't have this scaling option. But I performed some tests.

I took a blankclip:

blankclip(color=$0000f0,pixel_type="yuy2")

coloryuv(analyze=true) # gives the values: YUV = 39, 234, 111

Then I made the following script as source (conversion to RGB24 done by AviSynth itself):

blankclip(color=$0000f0,pixel_type="yuy2")
ConvertToRGB24

I made two mpeg1 clips with TMPGEnc: bc_def.mpg without the option "output YUV as Basic YCbCr and not CCIR601" checked (which is the default). Importing (as YUY2) and analyzing in AviSynth gives:

DirectShowSource("e:\temp\test\bc_def.mpg",fps=25)
coloryuv(analyze=true) # YUV = 40, 233, 111

conclusion: clip is untouched. The second clip is with the option "output YUV as Basic YCbCr and not CCIR601" checked. Importing (as YUY2) and analyzing in AviSynth gives:

DirectShowSource("e:\temp\test\bc_ycbcr.mpg",fps=2 5)
coloryuv(analyze=true) # YUV = 27, 248, 108

conclusion: the values are changed. Some math:

The inversion of y = x/255*( 235-8 )+8 gave the incorrect values! So I used:

y = x/255*(235-16) + 16 [(0,255)->(16,235)]

The inverse is given by

x = 255/(235-16)*y - 16*255/(235-16) [(16,235)->(0,255)]

y = 39 (luma of blankclip) results indeed in y = 26.8 = 27.

conclusion: the scaling (16,235)->(0,255) is performed when the option "output YUV as Basic YCbCr and not CCIR601" is checked.

btw, I see that I misread Jorel:
I'm very sorry. I will perform some tests, to see whether this is true.

Great, you find a way to do the check ! I search for it yesterday but never found how to do that :-(

That's a great info. I'm glad to never have the option checked :!:

In fact, that's me that told this.

I'll do also (now that I have a way to perform it ;-))

Hi all !
Great results Willbert !
I suspected that "output YUV as Basic YCbCr and not CCIR601" option checked is performing scale conversion but didn't find way to prove that .
After this one we have to find what is wrong (in some movies ) with colors when black turns to be dark blue or green . This problem is mentioned many times in KVCD forum but NOONE could solve this problem .
Even if we check "output YUV as Basic YCbCr and not CCIR601" option colors become more natural but still there is some visual difference .
I suppose that they are using some kind of filter for color scale conversion that doesn't affect DVD MPEG2 stream but after encoding with TMPG color lose right values .
That will be great If we could find how exectly prevent this unwanted effect .
bman

@Dialhot,

I did some more tests:

# source:
# blankclip(color=$000010, pixel_type="yuy2") # YUV = 18, 135, 127
# ConvertToRGB24

I opened this script in TMPGEnc and checked "output YUV as Basic YCbCr and not CCIR601", resulting in bc2_ycbcr.mpg. It has YUV values: 2, 136, 127 (I did it this way, because I don't know how to make this in AviSynth):

# DirectShowSource("e:\temp\test\bc2_ycbcr.mpg",fps= 25)
# coloryuv(analyze=true) # YUV = 2, 136, 127
# ConvertToRGB24

For some strange reason TMPGEnc crashes with the script above, so I loaded bc2_ycbcr.mpg directly in TMPGEnc. Now I unchecked "output YUV as Basic YCbCr and not CCIR601" and encoded to bc2_ccir601.mpg. I made the following script:

DirectShowSource("e:\temp\test\bc2_ccir601.mpg",fp s=25)
coloryuv(analyze=true) # YUV = 16, 128, 128

My conclusion is that all YUV values with Y<16 is clamped to (Y,U,V)=(16,128,128) when leaving "output YUV as Basic YCbCr and not CCIR601" unchecked.

I guess all values with Y>235 are clamped to (Y,U,V)=(235,128,128), but I didn't check this.

Conclusion: Jorel is correct!

Could you give some links, and also upload a short vob where this problem occurs?

That is not Jorel that told you that, that's me :-)

So as I told a long time ago, bye bye limiter in the scripts, is useless :!:

Thank you Wilbert for having done all these tests.

I see, sorry :)

Of course we are only talking about TMPGEnc here ...

Of course. I don't do any encodign with other tool.

But if were going to try another encoder like CCE then we should keep Limiter() in to help with the black background blocks, Right?

Don't know, I never used CCE. Accordingly to the CCE-faq at doom, it has a luminance level option. Maybe someone can do the same two tests (as I did above) to see what this option does?

Yes, CCE has this luminance level 16 to 235 or 0 to 255. I think by default it is at 0 to 255. Now I need to read again on what the two differences do :)