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

Ronald S. Bultje git at videolan.org
Sun Dec 4 22:12:57 EET 2016


ffmpeg | branch: release/3.0 | Ronald S. Bultje <rsbultje at gmail.com> | Fri Oct 14 13:01:27 2016 -0400| [642cd5de4de6c94877601078fad5474a45d36630] | committer: Michael Niedermayer

vp9: change order of operations in adapt_prob().

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).

(cherry picked from commit be885da3427c5d9a6fa68229d16318afffe67193)
Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=642cd5de4de6c94877601078fad5474a45d36630
---

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

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 5d8ad12..c9d7690 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -3703,11 +3703,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);



More information about the ffmpeg-cvslog mailing list