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: 3,865
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,212
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
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



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: 3,865
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,212
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)
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



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,393
@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, 12:15   #6  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
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?
jq963152 is offline   Reply With Quote
Old 11th May 2013, 13:46   #7  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,212
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.
__________________
There was of course no way of knowing whether you were being watched at any given moment.
How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.



Last edited by LoRd_MuldeR; 11th May 2013 at 13:56.
LoRd_MuldeR is offline   Reply With Quote
Old 11th May 2013, 14:51   #8  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Well, read this (especially the highlighted (blue) part + initial commit message):

Quote:
Originally Posted by mewiki.project357.com

http://mewiki.project357.com/wiki/X264_Settings#crf-max

crf-max

Default: Not set

A similar setting to --qpmax except instead of specifying a maximum quantizer you're specifying a maximum ratefactor. This option only works when you are using CRF and have VBV enabled. It prevents x264 from reducing the ratefactor (aka "quality") below the given value even when doing so would violate VBV constraints. This setting is mostly applicable to custom streaming servers. More information can be found in the initial commit message.
jq963152 is offline   Reply With Quote
Old 11th May 2013, 16:23   #9  |  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   #10  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
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 11th May 2013, 22:48   #11  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
@ akupenguin:

Thank you very much for your reply.

Looks like you are the only one who understands what i mean .

But i don't think my initial question has been answered, yet:


Quote:
Originally Posted by jq963152 View Post
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?


?

Ideally i would like to see if x264 increased the CRF, when and how often it increased the CRF and most importantly by how much it increased the CRF. Any chance?

Last edited by jq963152; 11th May 2013 at 22:52.
jq963152 is offline   Reply With Quote
Old 12th May 2013, 21:27   #12  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
That's what I pasted a patch for.
akupenguin is offline   Reply With Quote
Old 13th May 2013, 06:41   #13  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Well, thanks...

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

Or do you mean that this patch will land in the next x264 revision or something like that?
jq963152 is offline   Reply With Quote
Old 13th May 2013, 08:06   #14  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
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, 16:11   #15  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Quote:
Originally Posted by Groucho2004 View Post
So, would you have to copy the code box from akupenguin into a text editor, then save that as "patch.diff" and then do this:

Quote:
Originally Posted by Linyx
To apply a patch, paste the .diff in the x264 trunk (the downloaded git repository), then in MSYS, use

Code:
patch -p1 < "Patch name goes here.diff"
?

Anyway, why that hassle? Why can't it just be implemented into the next main x264 revision ?
jq963152 is offline   Reply With Quote
Old 13th May 2013, 17:34   #16  |  Link
the_weirdo
Yes, I'm weird.
 
the_weirdo's Avatar
 
Join Date: May 2010
Location: Southeast Asia
Posts: 273
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, 18:30   #17  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Quote:
Originally Posted by akupenguin View Post
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:
Just wondering:

Let's say you have a very complex source and encode it with the following settings (just very extreme example):

--crf 1 --vbv-bufsize 1 --vbv-maxrate 1

Obviously, because of those harsh VBV constraints, x264 probably will never reach a constant rate factor of 1 and instead probably will have to increase the rate factor over the entire encode to comply with the VBV constraints.

Question:

Is that the same as CBR encoding:

--bitrate 1 --vbv-bufsize 1 --vbv-maxrate 1

?

Or is there still a difference?

PS:

Just wondering as well:

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?

Will that cause x264 to violate the VBV constraints because it can't increase the constant rate factor further (because 51 is the maximum value, i.e. there is no value of 52, 53, 54, 55 and so on...)?
jq963152 is offline   Reply With Quote
Old 1st June 2013, 20:31   #18  |  Link
akupenguin
x264 developer
 
akupenguin's Avatar
 
Join Date: Sep 2004
Posts: 2,393
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:49   #19  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Thanks for your reply.

But:

Quote:
Originally Posted by akupenguin View Post
Then x264 will enable noise reduction at successively higher strengths. Thus, as far as VBV is concerned, there are virtual QPs above 51.
I don't think so...

Because i just encoded one minute of grainy and detailed high definition source using x264 r2334 with:

--tune grain --crf 1 --vbv-bufsize 1 --vbv-maxrate 1

While encoding the log said:


Quote:
x264 [warning]: VBV underflow (frame 0)
x264 [warning]: VBV underflow (frame 1)
x264 [warning]: VBV underflow (frame 2)
x264 [warning]: VBV underflow (frame 3)
x264 [warning]: VBV underflow (frame 4)
x264 [warning]: VBV underflow (frame 5)

and so on...

The warning showed up for every single frame, 1800 times (one minute @ 30 fps) .

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 .

So it looks like x264 did not comply to the VBV constraints.

Is that a bug?

PS:

The encoded video is unwatchable though...

It has artifacts all over the place and the most noticeable artifact is a lot of teared frames (looking very similar to the tearing of videogames when V-Sync is disabled, but much worse) .
jq963152 is offline   Reply With Quote
Old 1st June 2013, 21:58   #20  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,054
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
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 19:36.


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