[x264-devel] [PATCH] fix bug of weighted bipred according to Rec. ITU-T H.264 (10/2016) 8.4.3
Lingjiang Fang
vacingfang at foxmail.com
Wed Jan 20 03:55:14 UTC 2021
On Wed, 20 Jan 2021 00:51:11 +0300
BugMaster <BugMaster at narod.ru> wrote:
> On Fri, 15 Jan 2021 17:20:22 +0800, Lingjiang Fang wrote:
> > From: Lingjiang Fang <vacingfang at tencent.com>
>
> > ---
> > common/macroblock.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> > diff --git a/common/macroblock.c b/common/macroblock.c
> > index 9a3c7132..638a5c42 100644
> > --- a/common/macroblock.c
> > +++ b/common/macroblock.c
> > @@ -1890,13 +1890,17 @@ void x264_macroblock_bipred_init( x264_t *h
> > ) int poc0 = l0->i_poc +
> > mbfield*l0->i_delta_poc[field^(i_ref0&1)];
> > for( int i_ref1 = 0; i_ref1 <
> > (h->i_ref[1]<<mbfield); i_ref1++ )
> > {
> > + int use_default = 0;
> > int dist_scale_factor;
> > x264_frame_t *l1 = h->fref[1][i_ref1>>mbfield];
> > int cur_poc = h->fdec->i_poc +
> > mbfield*h->fdec->i_delta_poc[field];
> > int poc1 = l1->i_poc +
> > mbfield*l1->i_delta_poc[field^(i_ref1&1)];
> > int td = x264_clip3( poc1 - poc0, -128, 127 );
> > if( td == 0 /* || pic0 is a long-term ref */ )
> > + {
> > dist_scale_factor = 256;
> > + use_default = 1;
> > + }
> > else
> > {
> > int tb = x264_clip3( cur_poc - poc0, -128,
> > 127 ); @@ -1907,7 +1911,7 @@ void x264_macroblock_bipred_init(
> > x264_t *h )
> > h->mb.dist_scale_factor_buf[mbfield][field][i_ref0][i_ref1] =
> > dist_scale_factor;
>
> > dist_scale_factor >>= 2;
> > - if( h->param.analyse.b_weighted_bipred
> > + if( !use_default &&
> > h->param.analyse.b_weighted_bipred
> > && dist_scale_factor >= -64
> > && dist_scale_factor <= 128 )
> > {
> > --
> > 2.29.2
>
> Hi.
>
> I understand which part of H.264 spec you tried to fix. But was you
> able to really trigger this bug (code path) in x264? I in my quick
> test I couldn't because x264 does not use long-term refs and I don't
> know when poc0 and poc1 would be equal for B-frame (which frame-types
> pattern will cause this?).
thank you for your reply ^_^
Yes, we will never trigger this bug under the current logic of x264, we
notice this because we want do some enhancement to the reference
management, so we need to fix it first.
anyway, since the implementation doesn't follow the spec and it's easy
to fix it, why not ^_^
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
Regards,
Lingjiang Fang
More information about the x264-devel
mailing list