[x264-devel] commit: 2-pass VBV fixes (Jason Garrett-Glaser )

git version control git at videolan.org
Tue Aug 25 05:54:54 CEST 2009


x264 | branch: master | Jason Garrett-Glaser <darkshikari at gmail.com> | Mon Aug 24 03:28:11 2009 -0700| [533b473f71f2ccd1f73e3d25cd57fca06ef553b5] | committer: Jason Garrett-Glaser 

2-pass VBV fixes
Properly run slicetype frame cost with 2pass + MB-tree.
Slash the VBV rate tolerance in 2-pass mode; increasing it made sense for the highly reactive 1-pass VBV algorithm, but not for 2-pass.
2-pass's planned frame sizes are guaranteed to be reasonable, since they are based on a real first pass, while 1-pass's, based on lookahead SATD, cannot always be trusted.

> http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=533b473f71f2ccd1f73e3d25cd57fca06ef553b5
---

 encoder/ratecontrol.c |    7 +++++--
 encoder/slicetype.c   |   15 ++++++---------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
index 96ad190..cf3dc9a 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -1060,8 +1060,11 @@ void x264_ratecontrol_mb( x264_t *h, int bits )
             int i_qp_max = X264_MIN( prev_row_qp + h->param.rc.i_qp_step, h->param.rc.i_qp_max );
             int i_qp_min = X264_MAX( prev_row_qp - h->param.rc.i_qp_step, h->param.rc.i_qp_min );
             float buffer_left_planned = rc->buffer_fill - rc->frame_size_planned;
-            /* More threads means we have to be more cautious in letting ratecontrol use up extra bits. */
-            float rc_tol = (buffer_left_planned / h->param.i_threads);
+            /* More threads means we have to be more cautious in letting ratecontrol use up extra bits.
+             * In 2-pass mode we can be more trusting of the planned frame sizes, since they were decided
+             * by actual encoding instead of SATD prediction. */
+            float rc_tol = h->param.rc.b_stat_read ? (buffer_left_planned / rc->buffer_size) * rc->frame_size_planned
+                                                   : (buffer_left_planned / h->param.i_threads);
 
             /* Don't modify the row QPs until a sufficent amount of the bits of the frame have been processed, in case a flat */
             /* area at the top of the frame was measured inaccurately. */
diff --git a/encoder/slicetype.c b/encoder/slicetype.c
index 221b54c..b9a7bb0 100644
--- a/encoder/slicetype.c
+++ b/encoder/slicetype.c
@@ -976,16 +976,13 @@ int x264_rc_analyse_slice( x264_t *h )
     frames[p0] = h->fref0[0];
     frames[b] = h->fenc;
 
-    if( h->param.rc.b_mb_tree )
-        cost = x264_slicetype_frame_cost_recalculate( h, frames, p0, p1, b );
-    else
-    {
-        cost = x264_slicetype_frame_cost( h, &a, frames, p0, p1, b, 0 );
+    cost = x264_slicetype_frame_cost( h, &a, frames, p0, p1, b, 0 );
 
-        /* In AQ, use the weighted score instead. */
-        if( h->param.rc.i_aq_mode )
-            cost = frames[b]->i_cost_est_aq[b-p0][p1-b];
-    }
+    if( h->param.rc.b_mb_tree && !h->param.rc.b_stat_read )
+        cost = x264_slicetype_frame_cost_recalculate( h, frames, p0, p1, b );
+    /* In AQ, use the weighted score instead. */
+    else if( h->param.rc.i_aq_mode )
+        cost = frames[b]->i_cost_est_aq[b-p0][p1-b];
 
     h->fenc->i_row_satd = h->fenc->i_row_satds[b-p0][p1-b];
     h->fdec->i_row_satd = h->fdec->i_row_satds[b-p0][p1-b];



More information about the x264-devel mailing list