Encode 4:2:0 and 4:4:4

[jpsdr]

I've made 4:4:4 encode and compare test.
Original source was 1080p 4:2:0.
I've created 2 files :
- One 720p 4:2:0, simply downscaled.
- One 720p 4:4:4, created by downscaling Y from 1920x1080->1280x720, and upscalling U/V from 960x540 to 1280x720.

Both files were encoded in one pass crf mode, with both the exact same parameters, except of course profile, was high10 for 4:2:0 and high444 for 4:4:4 (i'm using a 10bit version of x264).
Source is an anime.
Result was 23MB for 4:2:0, and 19MB for 4:4:4.
As there is more informations (or more details) on the 4:4:4 video, i was expecting it to be bigger than the 4:2:0, not the opposite.

Is it normal ?
As parameters of encodes are exactly the same, and videos are also "the same", i thought the rule "similar quality with same crf" would be true, and in that case, expect a bigger 4:4:4 file, as there is more informations, so bigger file to have same quality than 4:2:0.
Or, just having a high444 profile instead of high10 break the rule, and finaly the quality may absolutely not be the same.

Can someone tell me were i'm wrong ?

:thanks:

[sneaker_ger]

You "broke the rule" by using different chroma subsampling. (That said, 4:4:4 done right is more efficient anyways.)

[Asmodian]

I believe the default chroma qp offset is higher for 4:4:4 than it is for 4:2:0. Try with it set to the same value for both encodes.

edit: Yes it is, +6 for chroma-qp-offset in 4:4:4, according to Dark Shikari (http://forum.doom9.org/showthread.php?p=1620092#post1620092). I believe it defaults to +0 in 4:2:0.

[Desbreko]

Like Asmodian posted, using 4:4:4 output adds +6 to the offset, so setting --chroma-qp-offset -6 will get you the same offset as a 4:2:0 encode, and you'll see the expected increase in bitrate. You probably won't actually need to set it that low to get the same quality as the 4:2:0 encode, though, since compression artifacts won't be as visible in the higher resolution chroma.

[jpsdr]

Thanks for all these informations.
Everything is now clear.

I've just take a look at the code, out of curiosity, and find out :

h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -32, 32);
/* In 4:4:4 mode, chroma gets twice as much resolution, so we can halve its quality. */
if( b_open && i_csp >= X264_CSP_I444 && i_csp < X264_CSP_BGR && h->param.analyse.b_psy )
h->param.analyse.i_chroma_qp_offset += 6;
/* Psy RDO increases overall quantizers to improve the quality of luma--this indirectly hurts chroma quality */
/* so we lower the chroma QP offset to compensate */
if( b_open && h->mb.i_psy_rd && !h->param.i_avcintra_class )
h->param.analyse.i_chroma_qp_offset -= h->param.analyse.f_psy_rd < 0.25 ? 1 : 2;
/* Psy trellis has a similar effect. */
if( b_open && h->mb.i_psy_trellis && !h->param.i_avcintra_class )
h->param.analyse.i_chroma_qp_offset -= h->param.analyse.f_psy_trellis < 0.25 ? 1 : 2;
h->param.analyse.i_chroma_qp_offset = x264_clip3(h->param.analyse.i_chroma_qp_offset, -12, 12);
/* MB-tree requires AQ to be on, even if the strength is zero. */

It obviously says that chroma quality is halved, so, yes, "rule is broken".
The little thing i found curious, is why there is first a limit of -32/+32, and after a limit of +12/-12.

[bxyhxyh]

When I encode using megui it was +4.
Maybe megui is changing it to +4?

[Desbreko]

The chroma_qp_offset value you see in the encoding settings SEI is the final offset that gets used for the encode. Besides the +6 applied when using 4:4:4, psy-rd and psy-trellis can also apply negative offsets depending on their strength, and the --chroma-qp-offset setting can be used to apply another offset of your choosing. All of these offsets are added together to determine the final offset.

So for your case of a +4 offset, it's likely that a -2 offset from psy-rd and/or psy-trellis is being added to the +6 offset from using 4:4:4.