[x264-devel] commit: Correct misprediction of bitrate in threaded mode ( Gabriel Bouvigne )

[BugMaster]

On Tue, 16 Sep 2008 10:54:36 +0200 (CEST), git version control wrote:
> x264 | branch: master | Gabriel Bouvigne <bouvigne at mp3-tech.org> |
> Tue Sep 16 01:54:37 2008 -0700|
> [2042a196655aae035d1ef8164c4d4f46ce83dbee] | committer:
> Jason Garrett-Glaser 

> Correct misprediction of bitrate in threaded mode
> Improves bitrate accuracy in cases with large numbers of threads.
> Loosely based on a patch by BugMaster.

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

>  encoder/ratecontrol.c |   15 +++++++++++++++
>  1 files changed, 15 insertions(+), 0 deletions(-)

> diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
> index 1559c72..103e73b 100644
> --- a/encoder/ratecontrol.c
> +++ b/encoder/ratecontrol.c
> @@ -1348,6 +1348,21 @@ static float rate_estimate_qscale( x264_t *h )
>                            + h->stat.i_slice_size[SLICE_TYPE_P]
>                            + h->stat.i_slice_size[SLICE_TYPE_B]);
>  
+    if( h->>param.i_threads > 1 )
> +    {
+        int j = h->>rc - h->thread[0]->rc;
> +        int i;
> +        for( i=1; i<h->param.i_threads; i++ )
> +        {
> +            x264_t *t = h->thread[ (j+i)%h->param.i_threads ];
> +            double bits = t->rc->frame_size_planned;
> +            if( !t->b_thread_active )
> +                continue;
> +            bits  = X264_MAX(bits,
> x264_ratecontrol_get_estimated_size(t));
> +            total_bits += (int64_t)bits;
> +        }
> +    }
> +
>      if( rcc->b_2pass )
>      {
>          rce = *rcc->rce;

> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel

This patch do diametrically opposed to what my patch do. It only makes
worse. If VBV is not used "t->rc->frame_size_planned" and
"x264_ratecontrol_get_estimated_size(t)" are always zero, so it do
nothing. But when VBV is active it increase "total_bits" more which is
not correct because than we calculate "total_bits / rcc->expected_bits_sum"
where "total_bits" is the size of already encoded frames (without
frames which encoded by active threads), "rcc->expected_bits_sum" also
show the expected size of frames which ended encode (because it
calculated in "x264_ratecontrol_end"). So I think the correct way to
fix was my patch. Which fix the problem that "rcc->expected_bits_sum"
can be zero if we have more than 30 threads (because in such situation
we did not end to encode at least one frame when first enter this
if-brunch) an so the overflow of "total_bits / rcc->expected_bits_sum".
Also it fix the difference between "total_bits" and "rce.expected_bits"
where "rce.expected_bits" shows the expected size of all (also with
those frames which are encoding now by other threads) frames before
current.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: x264_multithreading_Nth_pass_ratecontrol.r977.diff
Url: http://mailman.videolan.org/pipermail/x264-devel/attachments/20080917/39ed3d40/attachment-0001.txt