I tested the script line by line and found the cause of my wet-paint effect was the ConvertToYUY2.
I followed the suggestion of Boulder's here to change to xvidvfw.dll and huffyuv.dll for YV12 and YUY but the result was the same.

I am using CCE 2.67 SP, which according to some reply here, accepts only YUY2 colorspace.

DIKO generates and requires YV12 at the beginning. Converting to YUY2 leads to wet-paint. Does it mean that I am stuck :x

I am curious why nobody else encounter this problem when changing from YV12->YUY2 :?:

Yes it is but as you installed Xvid you can REMOVE the line convertToYUY2 and let Xvid do the job. Boulder says it's better with avisynth but perhaps you will proof the opposite.

Personally I (try to...) NEVER use any convertTo... in my scripts :!:

Okay I did a LOT more testing (my god it can never end!). Yes, I found Deen as a replacement for ATC in V2 script to be a big improvement. The graininess in v2 is very widespread, and while I think it's great for unnatural surfaces it disturbs foreground images like people's faces. Deen helped to smooth that out. So then I went *back* to V4 and added the 2nd blockbuster line as you suggested, and now I take back what I said and think v4 *is* better, not only on details but also in compression :). Moreover, I replaced the Convolution3D line with Deen in V4, and I think that helped even more with compression and the appearance of natural surfaces. And finally I added Limiter() to the end of my script. I don't think I could tell a large difference with it or not in my encodes, but it did reduce file size again.

So currently, here is my "modified" V4 script. Dialhot if you got any more suggestions please let me know!:

I agree with Dialhot here, Uruk-Hai. I just let the codec do it as stated earlier and there's no need for it in my scripts. Haven't tried disabling it though and see if Avisynth does it better though...

:lol:
Remove the "limiter" and you have the script I personally use for all my jobs since I discovered the new Deen (5 month ago perhaps ?).

Okay, I never spoke about that, sorry :-p .
(note : I never had problem with the "official" V4 so a modification wasn't so urgent).

HAhaha okay, that's a coincidence. Could you please tell me why you don't use Limiter but others do? What are the pros/cons? Thanx.

edit: oh wait, never mind, found it! :D
http://www.kvcd.net/forum/viewtopic.php?t=9994

I did find though that compression was better with limiter() at the end... so with that being said, perhaps it does have some merit? :?:

Because I don't like to do something that is useless. But things changed a little (for others, not for me).

At first, the goal of limiter was to restraint the luma in the range [16-235] because the TV set are supposed to be hurted by extrem values (even if that is not true since years but habits are habits...).

THIS is useless : CCE, Tmpgenc, Mainconcept... all the encoder we use already clip the luma in this range by default ! So no need to have a filter to do that.

After a long time, people started to agree with that and limiter was removed form the optimal script for instance.

NOW the limiter filter is saw as an way to reduce the file size, as many other filter we use in fact, AND it was reintroduced in the script for this purpose. Just like you do.

But I'm not sure it's so harmless on the result (the "dark green blacks" phenomena is probably due to this limiter...)

excellent answer my friend. I'm giving the modified V4 script with Deen() a try now. Please keep us posted on any suggestions/update you come up with! They are no doubt invaluable to us all.

reply
 

well, well, :D
thead very interesting....
I will use yours script if I can.....
And I would to know when to use the second blokbuster in the script.

thank you very much..


byby

You mean dark grey, right? The borders that are added in the Avisynth script are actually dark grey as their luma value is probably 16 :!:

@zagor
Hum... it's hard to say exactly when. The problem is that you need to doa test for that.
In fact, personally, as I always use CQMatic to calculate the CQ, I look at the sample that it left on the disk at the end of its work. Then I look into the dark areas to see if there is "dancing" block in the flat areas (these are the so called "DCT blocks"). If there is, I do again the process with the second line.

@boulder
For some people they appear dark green, and I never understood why. Probably a matter of wrong gain on the Green component in their TV.
(you can also change the gain indivually for each color on your PC monitor, you see what I mean ?).

For the borders, that's true that when we tried to see if tmgpenc does clip or scale of the luma into the range [16-235] we discovered that all internal commands of avisynth ouptut in that range ! Impossible to generate a true dark (luma=0) even with the command "blackclip" :!:

Yes, it's probably related to some wrong settings. I've never had such behaviour. Black is black is dark grey :lol:

That's true, I also found that out a long time ago, trying to get pure black out of Avisynth.

reply
 

please, can you tell me if your dll is this?

deen.dll 245.760 byte

In the readme file is call:

(Deen 1.0 beta 1)


thanks


by

This is the correct one.