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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th May 2013, 20:12   #1  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th May 2013, 20:30   #2  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,221
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:
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
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 8th May 2013 at 22:00.
LoRd_MuldeR is offline   Reply With Quote
Old 8th May 2013, 20:42   #3  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,106
Quote:
Originally Posted by LoRd_MuldeR View Post
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?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th May 2013, 22:16   #4  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,221
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.
LoRd_MuldeR is offline   Reply With Quote
Old 8th May 2013, 23:38   #5  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
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.
akupenguin is offline   Reply With Quote
Old 11th May 2013, 13:46   #6  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,221
Quote:
Originally Posted by jq963152 View Post
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.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 11th May 2013 at 13:56.
LoRd_MuldeR is offline   Reply With Quote
Old 11th May 2013, 16:23   #7  |  Link
paradoxical
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.
  Reply With Quote
Old 11th May 2013, 20:18   #8  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Quote:
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:
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] =
akupenguin is offline   Reply With Quote
Old 12th May 2013, 21:27   #9  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
That's what I pasted a patch for.
akupenguin is offline   Reply With Quote
Old 13th May 2013, 08:06   #10  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by jq963152 View Post
Well, thanks...

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.
Groucho2004 is offline   Reply With Quote
Old 13th May 2013, 17:34   #11  |  Link
the_weirdo
Yes, I'm weird.
 
the_weirdo's Avatar
 
Join Date: May 2010
Location: Southeast Asia
Posts: 271
Quote:
Originally Posted by jq963152 View Post
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.
__________________
“Never argue with stupid people, they will drag you down to their level and then beat you with experience.” — Mark Twain
the_weirdo is offline   Reply With Quote
Old 1st June 2013, 20:31   #12  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,392
Quote:
Originally Posted by jq963152 View Post
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.

Quote:
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.
akupenguin is offline   Reply With Quote
Old 1st June 2013, 21:58   #13  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by jq963152 View Post
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.
Groucho2004 is offline   Reply With Quote
Old 2nd June 2013, 02:02   #14  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
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
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.

Last edited by akupenguin; 2nd June 2013 at 06:45.
akupenguin is offline   Reply With Quote
Old 2nd June 2013, 11:39   #15  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,564
ultrafast and superfast don't use mbtree - maybe that's where the difference comes from?
sneaker_ger is offline   Reply With Quote
Old 2nd June 2013, 11:53   #16  |  Link
MasterNobody
Registered User
 
Join Date: Jul 2007
Posts: 546
That is due --rc-lookahead 0 in --preset ultrafast i.e. lookahead for VBV is disabled.
MasterNobody is offline   Reply With Quote
Old 2nd June 2013, 19:50   #17  |  Link
paradoxical
Guest
 
Posts: n/a
No, he said that lookahead for VBV was disabled not that VBV was disabled.
  Reply With Quote
Old 2nd June 2013, 23:18   #18  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,667
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.
Dark Shikari is offline   Reply With Quote
Reply

Tags
.stats, crf, rate controlm logging

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 13:05.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.