When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part_weighted.
If the buffer stride is 32 or 64 (as on x86 platforms),
the U and V pixels can be interleaved row by row without
overlapping, resulting in correct output.
However, on ARM platforms where the stride is 16,
the V component will overwrite part of the U component's pixels,
leading to incorrect predicted pixels.
Fixes: ticket 11357
Signed-off-by: Bin Peng <peng...@visionular.com>
---
libavcodec/h264_mb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..b480cd312b 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -407,8 +407,8 @@ static av_always_inline void mc_part_weighted(const
H264Context *h, H264SliceCon
/* don't optimize for luma-only case, since B-frames usually
* use implicit weights => chroma too. */
uint8_t *tmp_cb = sl->bipred_scratchpad;
- uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift);
- uint8_t *tmp_y = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize;
+ uint8_t *tmp_cr = sl->bipred_scratchpad + (16 * sl->mb_uvlinesize);
+ uint8_t *tmp_y = sl->bipred_scratchpad + (32 * sl->mb_uvlinesize);
int refn0 = sl->ref_cache[0][scan8[n]];
int refn1 = sl->ref_cache[1][scan8[n]];
--
2.25.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
