Any way to find out what the CRF of an encode WOULD have been?

[benwaggoner]

So, encoding with CRF is essentially same as encoding 2-pass ABR at the same bitrate as the CRF would have produced. So, emulating a CRF encoding as ABR is straightforward.

But how about the reverse scenario: taking an ABR encode and figuring out what CRF would have produced a file the same frame size?

Given that CRF is used in internal rate control, I imagine that there is some sort of CRF value calculated for each frame. True? If so, is there any way to log those values? That would be a good start (and useful for other scenarios; per-frame CRF would be a better quick quality heuristic than per-frame PSNR or SSIM!).

Is there some sort of target CRF generated by the first pass that could also be captured?

[LoRd_MuldeR]

I think, in ABR mode, the "rate factor" is not constant, as x264 will constantly re-adjust the rate factor as needed, in order to hit the desired average bitrate.

So there is no CRF value in ABR mode, but x264 does print out the final rate factor:
ffms [info]: 640x480p 0:1 @ 25/1 fps (vfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
x264 [info]: profile High 10, level 3.0, 4:2:0 10-bit
x264 [info]: frame I:9 Avg QP:41.44 size: 40974
x264 [info]: frame P:2219 Avg QP:44.30 size: 3104
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 1.9% 0.0% 0.0% P16..4: 20.0% 0.0% 0.0% 0.0% 0.0% skip:78.0%
x264 [info]: final ratefactor: 33.57
x264 [info]: coded y,uvDC,uvAC intra: 60.2% 40.0% 19.6% inter: 13.2% 4.2% 1.5%
x264 [info]: i16 v,h,dc,p: 43% 28% 23% 6%
x264 [info]: i8c dc,h,v,p: 52% 22% 20% 6%
x264 [info]: kb/s:651.36

[benwaggoner]

I think, in ABR mode the "rate factor" is not constant, as x264 will constantly re-adjust the rate factor as needed, to hit the desired average bitrate.

So there is no CRF value in ABR mode, but x264 does print out the final rate factor:
Ah, that's exactly what I was looking for. Internal acronym mapping failure :). CRF is a mode, RF is the parameter.

How about figuring out rate factor for each frame? Does that get calculated internally? Anyone try outputting it to .stats or elsewhere?

[LoRd_MuldeR]

I don't think a frame "has" a rate factor. Put simply, and to my understanding, a relative number of bits is allocated to each frame based on its "complexity", using some magic formula. The rate factor simply is a scaling factor that is applied on top of that, in order to hit the desired total size (average bitrate) - at least in ABR and 2-Pass modes. In CRF mode, it's simply a user-defined constant. In ABR and 2-Pass mode, the rate factor gets readjusted continuously, as the "perfect" value cannot be known beforehand. You could log its current value after each frame. But how much does that tell you about the current frame? I'm not so sure... (I guess there will be more fluctuation at the beginning and less towards the end of the encode)

[akupenguin]

@LoRd_MuldeR
Hmm, sorta. Which variable is more fundamental depends on how you look at it.
CRF definitely treats RF as more fundamental: it sets RF to a constant, and doesn't ever compute anything related to bits unless you also enabled VBV.
You could consider 2pass to be using the CRF formula as just a relative allocation of bits and then multiply it by whatever scaling factor is needed. But you could also consider it to be using the CRF formula as a relative allocation of QP and then add whatever scaling factor is needed. Which is in turn equivalent to treating the RF parameter as the independent variable and bits as the dependent variable, and setting RF to whatever it needs to be. (Actually, the 2nd and 3rd views are slightly more accurate than the 1st view, since x264's "predict bits from QP" formula is not exactly an exponential. Adding QP is exactly what 2pass does, while multiplying bits is only an approximation of the effect.)
And whichever interpretation of 2pass you use, there's an analogous interpretation of ABR that's reevaluated at each frame based on the information available so far.

Btw, "final rate factor" is the final estimate of what RF would have produced the target bitrate if passed to a CRF encode. Not the actual RF used for the last frame, which is that plus a correction factor to compensate for the fact that ABR probably used the wrong RF earlier in the movie when it didn't know the complexity of the end. (Unless you set --ratetol=infinity, which disables that correction factor. In that case, the RF used for any given frame is just the best estimate so far of what RF would have produced the target bitrate if passed to a CRF encode, even if that means the current encode won't hit the target due to earlier mispredictions.)
... I can see how that would be confusing. Should we rename it?

[LoRd_MuldeR]

Hello,

a similar question:

When using --crf together with --vbv-bufsize --vbv-maxrate, then x264 will increase the CRF value while encoding, if the user specified CRF value would otherwise exceed the specified VBV restrictions (which can be circumvented via --crf-max), correct?

So, question:

Is there any way to find out if x264 increased the CRF value while encoding and how often it did increase the CRF value while encoding?

Are you sure VBV works by messing with the CRF value?

Without having checked that in detail, I assume that, put simply, first the rate-control algorithm, e.g. CRF, assigns the "intended" number of bits to the frame and then, afterwards, VBV kicks in order to avoid a buffer underflow - which might or might not make it necessary to "take away" some bits from the frame's budget. Which means that VBV is more or less independent from the CRF value.

[paradoxical]

Okay, except your question was about what would happen with --crf not --crf-max. --crf-max is not set by default so it has little relevance. But, yes, your CRF value would exceed the VBV restrictions the ratefactor will be adjusted.

[akupenguin]

Are you sure VBV works by messing with the CRF value?
Any given frame or macroblock or whatever scale object you're interested in, has a QP, and a ratefactor, and a bitsize. Those 3 variables are all deterministically and monotonically related to each other, and have only 1 degree of freedom between them. Therefore, regardless of which one is mentioned in the sourcecode of a given algorithm, you can always interpret the effect of that algorithm has having messed with ratefactor.

jq963152 was also entirely correct to infer the above from the existence of the option --crf-max.

As for reporting which frames increased ratefactor to comply with VBV, here you go:

--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -2548,6 +2548,9 @@ static float rate_estimate_qscale( x264_t *h )

//FIXME use get_diff_limited_q() ?
q = clip_qscale( h, pict_type, q );
+
+ if( h->param.rc.i_rc_method == X264_RC_CRF && rcc->b_vbv )
+ printf( "%d %.4f\n", h->fenc->i_frame, qscale2qp( q ) - rcc->qp_novbv );
}

rcc->last_qscale_for[pict_type] =

[akupenguin]

That's what I pasted a patch (http://forum.doom9.org/showthread.php?p=1627919#post1627919) for.

[Groucho2004]

Well, thanks... :p

But how does that paste of a patch help me as a x264 user / x264 non-developer ;)?

You don't need programming skills to build x264. (http://doom10.org/index.php?topic=26.0)

[the_weirdo]

Anyway, why that hassle? Why can't it just be implemented into the next main x264 revision ;)?

Because just a few people actually need it.

[akupenguin]

Is that the same as CBR encoding:
--bitrate 1 --vbv-bufsize 1 --vbv-maxrate 1

Logically equivalent but not bit-identical. In order to guarantee no vbv overflows, x264 has to be slightly conservative about vbv constraints, and the precise nature of that conservativeness depends on conditions prior to applying the constraints.

What happens when x264 automatically increased the CRF to 51 because of harsh VBV constraints but needs to increase it even further to comply with the VBV constraints?
Then x264 will enable noise reduction at successively higher strengths. Thus, as far as VBV is concerned, there are virtual QPs above 51.

[Groucho2004]

And the filesize came out at roughly 60 MB (around 8000 Kbps according to MediaInfo), which is much too high for those VBV constraints i guess ;).
What were the reported QP values? I bet 51. Which is as high as it can get with x264.

[akupenguin]

QPs 52 to 69 are the virtual ones. They show up as "51" on the summary.

When I run `x264 --crf 1 --vbv-maxrate 1 --vbv-bufsize 1 --tune grain`, I get:
yuv [info]: 1280x528p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 3.1
x264 [warning]: VBV underflow (frame 0, -1800 bits)
x264 [warning]: VBV underflow (frame 1, -208 bits)
x264 [warning]: VBV underflow (frame 2, -200 bits)
x264 [warning]: VBV underflow (frame 3, -232 bits)
x264 [warning]: VBV underflow (frame 4, -208 bits)
... (warning for every frame)
x264 [info]: frame I:21 Avg QP:51.00 size: 262
x264 [info]: frame P:516 Avg QP:51.00 size: 36
x264 [info]: frame B:487 Avg QP:51.00 size: 31
x264 [info]: consecutive B-frames: 13.5% 61.7% 22.9% 2.0%
x264 [info]: mb I I16..4: 0.0% 100.0% 0.0%
x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 0.0% 0.0% 0.0% 0.0% 0.0% skip:100.0%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 0.0% 0.0% 0.0% direct: 0.0% skip:100.0%
x264 [info]: 8x8 transform intra:100.0%
x264 [info]: coded y,uvDC,uvAC intra: 0.0% 0.0% 0.0% inter: 0.0% 0.0% 0.0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 0% 0% 100% 0% 0% 0% 0% 0% 0%
x264 [info]: i8c dc,h,v,p: 100% 0% 0% 0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: kb/s:7.60

And the output video is not merely unwatchably low quality but rather contains no information at all: x264 quantized all of the coefficients to 0, leaving a blank grey rectangle. This still wasn't low enough bitrate, because there is no such thing as a 1kb/s 25fps h264 video. Frame headers alone are bigger than that, before you even get to the skipped MBs which cost a fraction of a bit each.

[sneaker_ger]

ultrafast and superfast don't use mbtree - maybe that's where the difference comes from?

[MasterNobody]

That is due --rc-lookahead 0 in --preset ultrafast i.e. lookahead for VBV is disabled.

[paradoxical]

No, he said that lookahead for VBV was disabled not that VBV was disabled.

[Dark Shikari]

Most likely for some reason or another the VBV algorithm tripped up given those absurd parameters (crf 1, VBV 1) and neutered analysis settings.

Obviously it still had some effect; if not, the QP would have been about 40 steps lower.