[x264-devel] commit: Fix potential crash in the case that the input statsfile is too short ( Jason Garrett-Glaser )

[BugMaster]

On Mon, 10 Nov 2008 02:41:09 +0100 (CET), git version control wrote:
> x264 | branch: master | Jason Garrett-Glaser
> <darkshikari at gmail.com> | Wed Nov  5 19:51:59 2008 -0800|
> [418cace8646a6f546a9026da47f79fad7285f577] | committer: Jason Garrett-Glaser

> Fix potential crash in the case that the input statsfile is too short
> Also resolve various other potential weirdness (such as multiple
> copies of the same error message in threaded mode).

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

>  encoder/ratecontrol.c |   25 ++++++++++++++-----------
>  1 files changed, 14 insertions(+), 11 deletions(-)

> diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
> index 876551f..75d7532 100644
> --- a/encoder/ratecontrol.c
> +++ b/encoder/ratecontrol.c
> @@ -441,9 +441,6 @@ int x264_ratecontrol_new( x264_t *h )
>              return -1;
>          }
>  
> -        /* FIXME: ugly padding because VfW drops delayed B-frames */
-        rc->>num_entries += h->param.i_bframe;
> -
>          rc->entry = (ratecontrol_entry_t*)
> x264_malloc(rc->num_entries * sizeof(ratecontrol_entry_t));
>          memset(rc->entry, 0, rc->num_entries * sizeof(ratecontrol_entry_t));
>  
> @@ -981,6 +978,7 @@ int x264_ratecontrol_slice_type( x264_t *h, int frame_num )
>              /* We could try to initialize everything required for ABR and
>               * adaptive B-frames, but that would be complicated.
>               * So just calculate the average QP used so far. */
> +            int i;
>  
>              h->param.rc.i_qp_constant =
> (h->stat.i_slice_count[SLICE_TYPE_P] == 0) ? 24
>                                        : 1 +
> h->stat.f_slice_qp[SLICE_TYPE_P] /
> h->stat.i_slice_count[SLICE_TYPE_P];
> @@ -993,14 +991,19 @@ int x264_ratecontrol_slice_type( x264_t *h, int frame_num )
>              if( h->param.i_bframe_adaptive )
>                  x264_log(h, X264_LOG_ERROR, "disabling adaptive B-frames\n");
>  
-            rc->>b_abr = 0;
-            rc->>b_2pass = 0;
-            h->>param.rc.i_rc_method = X264_RC_CQP;
-            h->>param.rc.b_stat_read = 0;
-            h->>param.i_bframe_adaptive = 0;
-            if( h->>param.i_bframe > 1 )
-                h->>param.i_bframe = 1;
> -            return X264_TYPE_P;
> +            for( i = 0; i < h->param.i_threads; i++ )
> +            {
+                h->>thread[i]->rc->b_abr = 0;
+                h->>thread[i]->rc->b_2pass = 0;
+                h->>thread[i]->param.rc.i_rc_method = X264_RC_CQP;
+                h->>thread[i]->param.rc.b_stat_read = 0;
+                h->>thread[i]->param.i_bframe_adaptive = 0;
+                h->>thread[i]->param.b_pre_scenecut = 0;
+                h->>thread[i]->param.i_scenecut_threshold = -1;
> +                if( h->thread[i]->param.i_bframe > 1 )
> +                    h->thread[i]->param.i_bframe = 1;
> +            }
> +            return X264_TYPE_AUTO;
>          }
>          switch( rc->entry[frame_num].pict_type )
>          {

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

Does it thread-safe to do such thing?