[FFmpeg-devel] [PATCH] vp9: change order of operations in adapt_prob().

[James Zern]

Ronald,

On Fri, Oct 14, 2016 at 10:01 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> This is intended to workaround bug "665 Integer Divide Instruction May
> Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
> div-by-zero in this codepath, such as reported in Mozilla bug #1293996.
>
> Note that this isn't guaranteed to fix the bug, since a compiler is free
> to reorder instructions that don't depend on each other. However, it
> appears to fix the bug in Firefox, and a similar patch was applied to
> libvpx also (see Chrome bug #599899).
>

I recently made a few additional changes as this regressed in chrome
[1][2], but just like this change there's no guarantee it won't occur
again.

[1] https://chromium.googlesource.com/webm/libvpx/+/8b4210940ce4183d4cfded42c323612c0c6d1688
[2] https://chromium.googlesource.com/webm/libvpx/+/82ea74223771793628dbd812c2fd50afcfb8183a

> ---
>  libavcodec/vp9.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>

lgtm

> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index cb2a4a2..3b72149 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -3705,11 +3705,10 @@ static av_always_inline void adapt_prob(uint8_t *p, unsigned ct0, unsigned ct1,
>      if (!ct)
>          return;
>
> +    update_factor = FASTDIV(update_factor * FFMIN(ct, max_count), max_count);
>      p1 = *p;
> -    p2 = ((ct0 << 8) + (ct >> 1)) / ct;
> +    p2 = ((((int64_t) ct0) << 8) + (ct >> 1)) / ct;
>      p2 = av_clip(p2, 1, 255);
> -    ct = FFMIN(ct, max_count);
> -    update_factor = FASTDIV(update_factor * ct, max_count);
>
>      // (p1 * (256 - update_factor) + p2 * update_factor + 128) >> 8
>      *p = p1 + (((p2 - p1) * update_factor + 128) >> 8);
> --
> 2.8.1
>