Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
8th May 2013, 20:12 | #1 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Any way to find out what the CRF of an encode WOULD have been?
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? |
8th May 2013, 20:30 | #2 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,251
|
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: Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 8th May 2013 at 22:00. |
|
8th May 2013, 20:42 | #3 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Quote:
How about figuring out rate factor for each frame? Does that get calculated internally? Anyone try outputting it to .stats or elsewhere? |
|
8th May 2013, 22:16 | #4 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,251
|
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)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 9th May 2013 at 02:37. |
8th May 2013, 23:38 | #5 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
@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? Last edited by akupenguin; 8th May 2013 at 23:44. |
11th May 2013, 13:46 | #6 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,251
|
Quote:
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 11th May 2013 at 13:56. |
|
11th May 2013, 16:23 | #7 | Link |
Guest
Posts: n/a
|
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.
Last edited by paradoxical; 11th May 2013 at 16:25. |
11th May 2013, 20:18 | #8 | Link | |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
Quote:
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: Code:
--- 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] = |
|
13th May 2013, 08:06 | #10 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
|
|
1st June 2013, 20:31 | #12 | Link | ||
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
Quote:
Quote:
|
||
2nd June 2013, 02:02 | #14 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
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: Code:
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 Last edited by akupenguin; 2nd June 2013 at 06:45. |
2nd June 2013, 23:18 | #18 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
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. |
Tags |
.stats, crf, rate controlm logging |
Thread Tools | Search this Thread |
Display Modes | |
|
|