CRF with normal video and animated films quality differs

[Chengbin]

I finally have switched to CRF encoding for my Archos 5, saves time and I set a quality, far simpler.

I'm using CRF 24 for my encodes, as I find that to be the best CRF for quality vs size. Although a lower quanitizer does help in overall visual quality (noticeable when watching, not a little), but bitrate almost doubles, so I choose to sacrifice some visual quality for size.

Anyway, I encoded some animated films, particularly Kung Fu Panda and Ratatouille. I can see significant quality loss with CRF 24. A lower CRF like 18 improves dramatically.

The main difference is detail. On Kung Fu Panda it is the fur on Po and the sand on the ground that is evident. On Ratatouille, it is mostly Remi (the Rat)'s fur and background.

This is viewed on a 4.8'' 800x480 screen BTW. I'm asking because I shouldn't be seeing this much difference on such a small screen.

Is CRF quality measure not as accurate for animated film? Or is low bitrate encoding deficiencies easier to spot with animated films?

BTW the encoding settings are

Normal video

cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=1.0:0.4 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=4 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=crf / crf=24.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Animated film

cabac=1 / ref=10 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=0.5:0.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=1000 / keyint_min=25 / scenecut=40 / rc=crf / crf=18.0 / qcomp=1.00 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

BTW, what does chroma_qp_offset do?

[Dark Shikari]

A perfectly clean source is going to be far easier to spot artifacts in as compared to your ordinary grainy film.

[10L23r]

chroma_qp_offset info: http://mewiki.project357.com/wiki/X264_Settings#chroma-qp-offset
iirc, it can boost quality a little... i think that it is more useful at lower bitrates than higher ones. idk whether a negative value favors luma or chroma, but its generally safer to stay near 0

[J_Darnley]

As it is a an offset for the chroma quantisers it means that the chroma quantisers are $chroma_qp_offset different from the luma quantisers. And I doubt he is specifying --chroma-qp-offset when calling x264 because using psy-rd with the values shown will produce those offsets. Why does psy-rd do this? Because it only affects luma.

[GrandDK]

try without weightb i remember when i encoded that it gave a quality boost

[LoRd_MuldeR]

As it is a an offset for the chroma quantisers it means that the chroma quantisers are $chroma_qp_offset different from the luma quantisers. And I doubt he is specifying --chroma-qp-offset when calling x264 because using psy-rd with the values shown will produce those offsets. Why does psy-rd do this? Because it only affects luma.

This is the code in question, I think:

/* 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 */
/* This can be triggered repeatedly on multiple calls to parameter_validate, but since encoding
* uses the pps chroma qp offset not the param chroma qp offset, this is not a problem. */
if( h->mb.i_psy_rd )
h->param.analyse.i_chroma_qp_offset -= h->param.analyse.f_psy_rd < 0.25 ? 1 : 2;
h->mb.i_psy_trellis = FIX8( h->param.analyse.f_psy_trellis / 4 );
/* Psy trellis has a similar effect. */
if( h->mb.i_psy_trellis )
h->param.analyse.i_chroma_qp_offset -= h->param.analyse.f_psy_trellis < 0.25 ? 1 : 2;

[J_Darnley]

This is the code in question, I think
Yeah, that is what I was referring to. For anyone who wants an English translation:

If psy-rd is on (not set to zero), do the following:
If the psy-rd value is less than 0.25 then subtract 1 from chroma_qp_offset, otherwise subtract 2.

If psy-trellis is on (not set to zero), do the following:
If the psy-trellis value is less than 0.25 then subtract 1 from chroma_qp_offset, otherwise subtract 2.

[Chengbin]

A perfectly clean source is going to be far easier to spot artifacts in as compared to your ordinary grainy film.

I used MVDegrain 3 for all videos to remove grain. Wouldn't that make it easier to spot?

[Sagekilla]

In a sense yes, but MVDegrain3 is an averaging type degrainer: Each output frame will look similar to it's neighbors, noise wise. Each frame becomes more stable and easier to encode, so the potential for encoding artifacts actually decreases. As an example, if you were to run MVDegrain3 on 300 with high SAD thresholds (so it properly catches noise), your frames won't have so much obvious dancing grain which -kills- encoders. Static-ish grain patterns are not difficult to encode (They're practically the same as detail in this case) but the more it moves around, the harder it is to accurately predict.

[Chengbin]

How come Family Guy doesn't suffer from this? I can use CRF 26 and I can't see much of a difference from the original VOB. But truthfully Family Guy doesn't have anywhere near the amount of detail animated films do.

[LoRd_MuldeR]

You give the answer yourself. Family Guy is cartoon with very few textures and absolutely now grain/noise (if encoded from a "clean" source).

This kind of footage is very compressible. Hence this it will still look good, even at high quantizers...

[pcordes]

How come Family Guy doesn't suffer from this? I can use CRF 26 and I can't see much of a difference from the original VOB. But truthfully Family Guy doesn't have anywhere near the amount of detail animated films do.

Family Guy is the most compressible video I've ever seen. Use --ipratio 1.8 (instead of the default 1.4), because the backgrounds tend to remain static for a long time after a scenecut. Often there's not even any panning. You can get down to 2pass 300kb/s for 576x432 and notice artifacts if you look really closely for them. My notes say I tried CRF30, and got 226kb/s, but it didn't look as good. This was a couple years ago, BTW, before AQ, so I wonder how low one could go these days.

Your settings look good, except qcomp=1.0. Are you sure that's a good idea? And I assume your player doesn't support 8x8dct :(, otherwise you'd use that. You could try --partitions all, in case p4x4 is worth the speed cost. Maybe at higher bitrates.

BTW, all those skip blocks in the static background can make the encode quite fast sometimes.

[Chengbin]

No, my player doesn't support high profile, so no 8x8dct.

I use qcomp 1 because if I use high quanitizer, and there is motion, it looks terrible. (Even though Family Guy is very "simple", sometimes it has huge motion scenes that require huge bitrates to look good)

I'm using 640x480 (the DVD's resolution), and it is around 200Kbps @ CRF 26. I see some artifacts if I look at it very closely.

Are you sure using ipratio of 1.8 is a good idea?

[Chengbin]

Is it just me or is x264's I frame decision is bad?

While doing some tests with CRF 28 with ipratio of 1.8 and keyint 1000, x264 doesn't seem to notice a scene change. This is a problem because you see artifacts from the previous scene in the changed scene because it is referencing from that I frame, which it shouldn't.

Here is a comparison to show what I mean

VOB source (Left, I frame. Right, scene change)

http://i43.tinypic.com/2meekrc.png http://i42.tinypic.com/1zdxmhh.png

CRF 28 ((Left, I frame. Right, scene change)

http://i41.tinypic.com/33z5r84.png http://i41.tinypic.com/19nki.png

I tried with lower quanitizers as well, same thing.

[Guest]

There are existing threads discussing this extensively.

[Chengbin]

There are existing threads discussing this extensively.

Can you point me to a thread? Thanks. I don't really know what to type as keyword in the search box.

[LoRd_MuldeR]

While doing some tests with CRF 28 with ipratio of 1.8 and keyint 1000, x264 doesn't seem to notice a scene change.

With that extremely high keyint it's not a big surprise that x264 will miss a scene change when there are two scene changes very close to each other...

[Guest]

Can you point me to a thread? Thanks. I don't really know what to type as keyword in the search box. http://forum.doom9.org/showthread.php?t=144207

http://forum.doom9.org/showthread.php?t=145017

http://forum.doom9.org/showthread.php?t=143996

I found these in two minutes. Your searching skills need work.

[Dark Shikari]

Is it just me or is x264's I frame decision is bad?

While doing some tests with CRF 28 with ipratio of 1.8 and keyint 1000, x264 doesn't seem to notice a scene change. This is a problem because you see artifacts from the previous scene in the changed scene because it is referencing from that I frame, which it shouldn't.x264's scene change decision is not there for the purpose of placing I-frames at every scene change. It's not guaranteed to, and it's not supposed to, and it isn't designed to.

If you're trying to max ipratio in order to trick x264 into doing something it isn't designed for, you won't get what you expect.

[Chengbin]

x264's scene change decision is not there for the purpose of placing I-frames at every scene change. It's not guaranteed to, and it's not supposed to, and it isn't designed to.

If you're trying to max ipratio in order to trick x264 into doing something it isn't designed for, you won't get what you expect.

I'm not sure if designing scene change algorithm like that is helpful for quality.

[LoRd_MuldeR]

I'm not sure if designing scene change algorithm like that is helpful for quality.

Well, if you think you know it better, then you can enforce more scenecuts by:
* lowering the max-keyint
* raising the scenecut threshold

[Chengbin]

I tried lowering keyint to 250, and it does the same thing. I don't want to lower it anymore because it will hurt compression (a lot because Family Guy has lots of static scenes)

How do I raise the scenecut threshold?

[Sagekilla]

@Chengbin: Designing a scene change algorithm that can detect when one happens is very difficult. The simplest kind of SC, where you cut from one scene to another within 1 frame, is easy to handle. But then how do you deal with more complex fades? IIRC, SC is implemented so that, while I-frame placement isn't perfect, the overall quality will be better.

Check x264 --longhelp next time: --scenecut is the param you're looking for.

[kemuri-_9]

there's always the option of forcing IDR-frames/keyframes using the qpfile option.

with a large keyint parameter this would be the surefire way of having the frames you want as IDR frames for those consecutive scene changes.

[JohannesL]

With that extremely high keyint it's not a big surprise that x264 will miss a scene change when there are two scene changes very close to each other...
Really? I thought keyint's purpose was to force a keyframe after a set number of frames to avoid decreasing seekability in very long scenes, and didn't affect scenecut decision.

[kemuri-_9]

Really? I thought keyint's purpose was to force a keyframe after a set number of frames to avoid decreasing seekability in very long scenes, and didn't affect scenecut decision.

iirc, the scenecut algorithm uses a weighted system based on the keyint value:
as the distance since the last IDR approaches the value of the keyint parameter, there are higher chances of a IDR frame being placed.