strange filesizes with crf mode

[pelle412]

Months ago I tested all kinds of x264 options to evaluate the effect they had on filesize in crf mode. I decided to test a few of them again and was surprised by what I found.

The version of x264 I'm using is:
x264 core:61 r951M 445d87e

My test was on Magnum Force DVD. Here are the settings of my base case:

--crf 21 --level 3.1 --qcomp 0.5 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

Filesize was 960,207 KB

Now if I use --subme 7 instead the filesize was 985,420 KB. The size increased, when in my earlier test it always decreased.

Enabling --trellis 1 or 2 (with subme 6) gave me a filesize of 1,529,734. A 60% increase?

I read through the whole psy-rdo thread to see if it was related to that but didn't come away with any explanation.

Any ideas?

[Avenger007]

The Psy-RDO thread isn't the main thread related to x264 code updates. You should read the change logs.

Maybe this (http://forum.doom9.org/showthread.php?t=140687) thread might help wrt subme 7 and trellis.

[pelle412]

Thanks, but I don't think that thread explains the huge increase in filesize.

[cogman]

Thanks, but I don't think that thread explains the huge increase in filesize.

Psy-rd doesn't work in favor of quality metrics which crf uses to determine the bitrate to through at the film. So if you are using Psy-Rd then you file sizes will get somewhat bigger because the film isn't spending the bits on making the film a bit perfect copy, rather they are spent make the film look better to humans (Which means the image doesn't always match what the original looks like).

This kind of increase is normal. Especially with noisy film (Like my mash footage) I went from something like 180 - 240 MB using the same settings only having psy-rd enabled. loosen your CRF value if that filesize is too big for you.

[pelle412]

But in my case psy-rd is enabled in all cases. Should I expect a 60% increase in filesize by enabling trellis on relatively clean DVD source? And subme 7 I'd expect more compression squeezed out of it, not higher file size.

[akupenguin]

Psy-rd doesn't work in favor of quality metrics which crf uses to determine the bitrate to through at the film.
crf doesn't use quality metrics, it uses complexity metrics. And it uses almost the same complexity metric as psy-rd.
This kind of increase is normal.
This kind of increase (if it's consistent) is a bug, or at least a failure in tuning. Otoh, if only some videos increase in bitrate and others decrease by a similar amount, that's normal. But I wouldn't expect 60% either way.

[pelle412]

Here's some x264 output info for each tested case:


--crf 21 --level 3.1 --qcomp 0.5 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --sar 96:79

avis [info]: 720x352 @ 23.98 fps (176272 frames)
x264 [info]: using SAR=96/79
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:1513 Avg QP:19.12 size: 24307ta 0:00:00
x264 [info]: slice P:87674 Avg QP:21.15 size: 8427
x264 [info]: slice B:87085 Avg QP:23.39 size: 2356
x264 [info]: consecutive B-frames: 16.6% 44.5% 21.9% 13.3% 3.6% 0.1%
x264 [info]: mb I I16..4: 3.8% 87.1% 9.1%
x264 [info]: mb P I16..4: 0.4% 11.7% 0.5% P16..4: 49.2% 16.6% 13.7% 0.0% 0
.0% skip: 7.8%
x264 [info]: mb B I16..4: 0.1% 1.1% 0.1% B16..8: 51.0% 1.1% 2.1% direct:
3.2% skip:41.4% L0:38.8% L1:54.0% BI: 7.2%
x264 [info]: 8x8 transform intra:91.8% inter:73.8%
x264 [info]: direct mvs spatial:98.9% temporal:1.1%
x264 [info]: ref P L0 61.8% 16.6% 10.8% 5.5% 5.3%
x264 [info]: ref B L0 72.1% 16.0% 8.4% 3.5%
x264 [info]: ref B L1 93.6% 6.4%
x264 [info]: kb/s:1067.2

encoded 176272 frames, 45.42 fps, 1067.22 kb/s

--crf 21 --level 3.1 --qcomp 0.5 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --sar 96:79

avis [info]: 720x352 @ 23.98 fps (176272 frames)
x264 [info]: using SAR=96/79
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:1513 Avg QP:19.12 size: 25167ta 0:00:00
x264 [info]: slice P:87674 Avg QP:21.16 size: 8729
x264 [info]: slice B:87085 Avg QP:23.37 size: 2333
x264 [info]: consecutive B-frames: 16.6% 44.5% 21.9% 13.3% 3.6% 0.1%
x264 [info]: mb I I16..4: 5.7% 86.2% 8.1%
x264 [info]: mb P I16..4: 0.5% 10.7% 0.5% P16..4: 49.6% 17.4% 13.5% 0.0% 0
.0% skip: 7.8%
x264 [info]: mb B I16..4: 0.1% 1.1% 0.0% B16..8: 50.6% 1.1% 2.1% direct:
3.1% skip:41.8% L0:38.8% L1:53.4% BI: 7.8%
x264 [info]: 8x8 transform intra:90.8% inter:74.4%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: ref P L0 60.3% 17.1% 11.1% 5.9% 5.7%
x264 [info]: ref B L0 71.6% 16.3% 8.4% 3.7%
x264 [info]: ref B L1 93.9% 6.1%
x264 [info]: kb/s:1095.2

encoded 176272 frames, 40.16 fps, 1095.31 kb/s


--crf 21 --level 3.1 --qcomp 0.5 --ref 5 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --trellis 2 --threads auto --thread-input --progress --no-psnr --no-ssim --sar 96:79

avis [info]: 720x352 @ 23.98 fps (176272 frames)
x264 [info]: using SAR=96/79
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: slice I:1513 Avg QP:19.12 size: 22976ta 0:00:00
x264 [info]: slice P:87674 Avg QP:21.28 size: 13419
x264 [info]: slice B:87085 Avg QP:23.87 size: 4049
x264 [info]: consecutive B-frames: 16.6% 44.5% 21.9% 13.3% 3.6% 0.1%
x264 [info]: mb I I16..4: 3.9% 86.1% 9.9%
x264 [info]: mb P I16..4: 0.7% 13.0% 0.5% P16..4: 45.7% 18.6% 17.3% 0.0% 0
.0% skip: 4.1%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.0% B16..8: 40.0% 1.2% 2.0% direct:
3.8% skip:51.5% L0:40.9% L1:36.9% BI:22.3%
x264 [info]: 8x8 transform intra:90.8% inter:78.8%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: ref P L0 51.9% 20.3% 11.8% 8.1% 8.0%
x264 [info]: ref B L0 59.3% 23.8% 10.5% 6.4%
x264 [info]: ref B L1 95.0% 5.0%
x264 [info]: kb/s:1701.7

encoded 176272 frames, 42.04 fps, 1701.79 kb/s


I-frames in the trellis case are smaller, but P/B frames went up alot, which is why the file got so large. I don't know why the P/B frames got so much larger however.

[CruNcher]

Hmm if --aq-strength is above 0.6 that's the case here (default 1.0) isn't qcomp forced to 1.0 to compensate AQ so --qcomp 0.5 has no effect @ all right ? i mean will forceing --qcomp overide
this ?
Tough i guess it has nothing todo with this problem hmm almost 700 kbps that is extreme didn't experience this extreme bitrate increase yet is --subme 6 with --trellis 1 showing the same kind of increase for you ?

[Avenger007]

x264 [info]: mb P I16..4: 0.4% 11.7% 0.5% P16..4: 49.2% 16.6% 13.7% 0.0% 0.0% skip: 7.8%
x264 [info]: mb B I16..4: 0.1% 1.1% 0.1% B16..8: 51.0% 1.1% 2.1%
direct: 3.2% skip:41.4% L0:38.8% L1:54.0% BI: 7.2%

x264 [info]: mb P I16..4: 0.5% 10.7% 0.5% P16..4: 49.6% 17.4% 13.5% 0.0% 0.0% skip: 7.8%
x264 [info]: mb B I16..4: 0.1% 1.1% 0.0% B16..8: 50.6% 1.1% 2.1%
direct: 3.1% skip:41.8% L0:38.8% L1:53.4% BI: 7.8%

x264 [info]: mb P I16..4: 0.7% 13.0% 0.5% P16..4: 45.7% 18.6% 17.3% 0.0% 0.0% skip: 4.1%
x264 [info]: mb B I16..4: 0.1% 1.4% 0.0% B16..8: 40.0% 1.2% 2.0%
direct: 3.8% skip:51.5% L0:40.9% L1:36.9% BI:22.3%
The difference is that trellis is activated in p8x8 qpel RD; this includes 8x16 and 16x8.

commit 3c3dc3cde75e72b7c212a9a9ddd623ef8a617e41 r950
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Aug 26 14:51:29 2008 -0400

Activate trellis in p8x8 qpel RD
Also clean up macroblock.c with some refactoring
Note that this change significantly reduces subme7+trellis2 performance, but improves quality.
Issue originally reported by Alex_W.

[pelle412]

The difference is that trellis is activated in p8x8 qpel RD; this includes 8x16 and 16x8.
commit 3c3dc3cde75e72b7c212a9a9ddd623ef8a617e41 r950
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Aug 26 14:51:29 2008 -0400

Activate trellis in p8x8 qpel RD
Also clean up macroblock.c with some refactoring
Note that this change significantly reduces subme7+trellis2 performance, but improves quality.
Issue originally reported by Alex_W.


In both my trellis examples above I used --subme 6. And a 60% increase in P/B frame sizes?

The filesize also increased from subme 6 to 7 without using trellis.

[cogman]

crf doesn't use quality metrics, it uses complexity metrics. And it uses almost the same complexity metric as psy-rd.

This kind of increase (if it's consistent) is a bug, or at least a failure in tuning. Otoh, if only some videos increase in bitrate and others decrease by a similar amount, that's normal. But I wouldn't expect 60% either way.

hmm, Well like I said, I saw an increase by about 60% with my MASH videos. I had the same git version for x264 and no noise filters turned on. the only difference was psy-rd. So if that is a bug, then a bug it is. I thought it was normal though :D.

That being said, it was 0.5 of psy-rd without psy-trellis. so that might be some of the reason for the drastic changes (You would definitively know better as I obviously have no encoder programming experience)

[Avenger007]

In both my trellis examples above I used --subme 6. And a 60% increase in P/B frame sizes?
I guess that's trellis in action for that particular source.

The filesize also increased from subme 6 to 7 without using trellis.
2.6% isn't much of an increase. Compare that with >26% between psy-rd off -> on.
What sort of decrease were you expecting?

[pelle412]

I guess that's trellis in action for that particular source.


2.6% isn't much of an increase. Compare that with >26% between psy-rd off -> on.
What sort of decrease were you expecting?

With subme 7 I was guessing a 1 - 3 % reduction in file size.