how come pixiedust makes the file size larger

[supernater]

I'm testing some denoising filters on some anime I'm encoding and I noticed that the filters I use affect the file size. To compress, I'm using the "x264: Unrestricted 1pass Const. Quality Anime_Toons" profile except that I've turned psy-rd off. Below is my command line...

program --profile high --crf 22.0 --ref 8 --bframes 16 --b-pyramid --no-weightb --deblock 1:1 --trellis 2 --psy-rd 0.0:0 --partitions all --ipratio 1.0 --pbratio 1.0 --me umh --thread-input --aq-mode 0 --output "output" "input"

The file I'm compressing is 640x480 and is 23 min 34 sec in length. I get the following sizes using the following denoise filters at their default settings...


85.4 MB No denoise
80.1 MB fft3dfilter
82.9 MB VagueDenoiser
88.9 MB pixiedust

My question is regarding pixiedust. I was under the impression that denoise filters increased compressibility, particularly pixiedust. So how come using pixiedust increased the file size by roughly 4 MB?

[MadRat]

I can't imagine why a denoiser would do that. Could you post your script? :script:

[scharfis_brain]

pixiedust creates blocks in the video...

[Didée]

Sure, PixieDust can produce blocking because it doesn't use block overlapping ... (MVTools/MDegrain produces blocking, too, when used with overlap=0) ... but it's unlikely that this is the cause of the increased filesize.

Possibilities ...

a) the script-internal clip fed into PixieDust was bigger than 1024*something - PixieDust can't handle big resolutions & produces artifacts that are hard to compress

b) the resolution was not mod16. When res is not mod16, you'll get artifacts at the right border

c) Everything in fact was OK, and PixieDust's denoising made the flat areas (gradients) "very" flat, which might force x264 to spend more bits in those areas, to prevent banding. (depends on x264's settings, I'm not quite up-to-date with those).


Check if the result of PixieDust is free of artifacts, and/or if you used some kind of "supersampling" (upsizing with later downsizing) in the script.

BTW, with all the adaptive-ness, psy-options and whatnotelse in current x264 (which is good!), the term "compressibility" is not as clearly outlined anymore as it was some years before.

When it's about figuring/compairing the "theoretical" compressibility, in the sense of spatio-temporal complexity, I like to run XviD encodes at quant2, without B-frames, usually with a custom 8..16 matrix. It's not a good indicator for how well x264 will compress later on, but it's a good indicator for the mere change-of-complexity achieved by a filter.

[supernater]

I can't imagine why a denoiser would do that. Could you post your script? :script:

Here is my script

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\LoadPluginEx.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DustV5.dll")

DGDecode_mpeg2source("E:\101.d2v", cpu=4, info=3)
ColorMatrix(hints=true,interlaced=true, threads=0)
interp = separatefields().eedi2(field=-2)
TDeint(mode=2, order=1, edeint=interp)
crop( 4, 4, -4, 0)

LanczosResize(640,464) # Lanczos (Sharp)
convertfps(23.976)

converttoyuy2()
pixiedust()
converttoyv12()

[scharfis_brain]

I guess, that pixiedust is being fooled big time by your attempt to do a blend-based framerate conversion with convertfps.

[elguaxo]

PixieDust's denoising made the flat areas (gradients) "very" flat, which might force x264 to spend more bits in those areas, to prevent banding. (depends on x264's settings, I'm not quite up-to-date with those).


According to the command line Psy-RD, PsyTrellis and VAQ are disabled so it can't be that.

[Didée]

You should've posted the script from the start ... scharfis_brain is spot-on. Field/Frame-blending and motion compensation don't fit together.

[supernater]

You should've posted the script from the start ... scharfis_brain is spot-on. Field/Frame-blending and motion compensation don't fit together.

Ah, I see. So I should get rid of convertfps() or use changefps() instead? I'll try it and report back.

[scharfis_brain]

why do you want to change the framerate?
usually changing the framerate isn't a good idea, cause it introduces motion judder. Also a blend conversion makes a video more difficult to compress well.

[supernater]

I used the following script with the command line I posted above...

no denoise:
DGDecode_mpeg2source("E:\101.d2v", cpu=4, info=3)
ColorMatrix(hints=true,interlaced=true, threads=0)
interp = separatefields().eedi2(field=-2)
TDeint(mode=2, order=1, edeint=interp)
crop( 4, 4, -4, 0)

LanczosResize(640,464) # Lanczos (Sharp)


pixiedust:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\LoadPluginEx.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DustV5.dll")

DGDecode_mpeg2source("E:\101.d2v", cpu=4, info=3)
ColorMatrix(hints=true,interlaced=true, threads=0)
interp = separatefields().eedi2(field=-2)
TDeint(mode=2, order=1, edeint=interp)
crop( 4, 4, -4, 0)

LanczosResize(640,464) # Lanczos (Sharp)
converttoyuy2()
pixiedust()
converttoyv12()

78.1 MB no denoise
85.2 MB pixiedust

Could it have something to do with the way I'm deinterlacing?

why do you want to change the framerate?
usually changing the framerate isn't a good idea, cause it introduces motion judder. Also a blend conversion makes a video more difficult to compress well.

I play my movies on XBMC on my old xbox. I find that the processor handles x264 better when I do 24 fps than keeping it at 30 fps. I guess I could disable CABAC, but I'd rather keep it and lower the framerate. I guess I'm just being picky...;)