NICE! :D

Guys this is fun... Right Now I'm at the state of getting a very good picture quality with CQ_VBR. Still scenes are nice and sharp, I almost killed mosquito noise completely, and DCT Blocks are reduced a lot.
The one problem left for me is blocky picture in action scenes due to bitrate shortage... There's probably not a lot I can do about that since the Average bitrate is at around 510 kb/sec for this movie, but I'm going to try things to better it... Any ideas on that?
TMPGEnc's Soften Block Noise seems to make things worse... :roll:

The only way is to lowering your min to save a little more bits for action scenes.

Hi Dialhot!

I know I'm getting on your nerves but... I'm totally in love with PixieDust...
This script is working WONDERS for me on that source at that Ultra-Low-Bitrates... Check it out it's pretty basic!
It even beats MA by far... Picture looks brilliantly sharp even at that low resolution, PixieDust() takes care of ALL mosquito noise, and the MergeLuma-blur is helping to avoid blocks in action scenes... I know the speed of PixieDust sucks, but to me it's worth every second... :roll:

Make sure you use ConverttoYUY2() and ConverttoYV12(), otherwise you may get a performance hit. That's one Avisynth strangeness although I don't know if it is fixed by now.

Compare it to this scritp please, and tell me what do you think :
(uncomment the second blockbuster line only if you have too much DCT blocks in dark areas after encoding).

Note1: I do not know what you call "Noisy" source but we were discussing about PixieDust because you were looking for a good denoiser. The Two Towers SEE... noisy ? ;-)

Note2: All your Chroma is completly screwed up by the 2 "ConvertTo..." but its seems that you don't care about it. Try to compare the color of the source and the ones of the encoding video.
The problem isn't in PixieDust. The problem is that as everyone trying to use these "old" filters, you convert twice. You should perhaps try the internal convert function of mpeg2dec3 (do not remember the name, see the documentation).

In his script as he needs to converttoYUY2() cause of pixiedust.... Is it really needed to convert back to YV12 afterwards???
I only see activated as following ..
... does one of these really need YV12 (Im not shure now)??

Of course not, and that is what I wanted to point out.

It doesn't seem that the mpeg2dec3 within the command supports [, string pixel_type]), but I remeber too that I've also read somewhere that by importing a source that could be set. :?:

Only this command is mentioned in the readme....
Could it be that we both mean this?:

There it's supportet as [, string pixel_type])

EDIT: It seems you edited your last Post Dialhot ;-) cause thats why I was typing this

You're right ;-). I changed it after having read the documentation myself :-).

However, for those who want to do the convert, think about making a test with "YV12toYUY2" that is the internal convertion function of mpeg2dec3.dll. Perhaps it's better than the avisynth's one.

Thanks for all your inputs mates! Will do more testing on this! :D

@Dialhot: No LOTR II Towers is one of the best authored and cleanest DVDs around. However, when resizing to such a low resolution, I like to get rid of ALL the noise left, because mosquito noise will be terrible at a 352x288 resolution, if the source is not completely denoised before...

I know the quality of LOTR II. Well, the difference in my case is that I got the 170mins version but I think both do base on the same master-source.

The best & most effective way to avoid mosquitonoise IMHO is when adding a minimal blur to the video (like mergeLuma/Chroma) but this you're already doing as I saw your last script.

But caution! If you perform to much "denoising" on an already clean source anyway the details will suffer ... and thats what you understand by "more denoising = more compression" this in real means: less details = more compression.
And on the other hand the risk of blocks on big fading clean surfaces gets very high! That's why we often use Blockbuster which adds "spray" as you know to exactly avoid the result of blocks on static surfaces.

Ok, here's one thing I already found out... The blockyness in High Action scenes is NOT due to bitrate shortage. It must be how Automatic VBR (CQ_VBR) allocates the bitrate, because with CQ, this effect does not show up. However Picture seems to be blurrier using CQ, so it's a tough choice for me... :roll:

That's one problem with TMPGEnc, not being able to do any manual bitrate allocation :cry:

Regarding YV12toYUY2, see this: http://forum.doom9.org/showthread.ph...ght=yv12toyuy2

Thanks For That Link ! :wink:

Ok, with this Project I'll wait until YMPEG gets stable and try it again... :roll: :?

??? And what do you expect in this codec that would give you a correct result for Two Towers ?
(I didn't follow all the threads on that tool).

I expect it to allocate the bitrate better than TMPGEnc does. From what kwag said, it has a far better motion search algorithm...
The problem is within TMPGEnc. If CQ_VBR would not produce so many blocks in High Action Scenes (even if they are blurred heavily! ) the movie will look fine...