Inconsistent when decoding an H.264 bitstream with bi-prediction weighted prediction enabled on ARM and x86 devices

[Bin Peng]

Summary of the bug:

When decoding a bitstream with weighted-bipred enabled, the output of FFmpeg on ARM and x86 platforms may differ.

How to reproduce:

using ffmpeg git-master built on aarch64 and test on aarch64 devices
% ffmpeg -i inter_weighted_bipred2.264 -f framemd5 -y md5_arm

using ffmpeg git-master built on x86 and test on x86 devices
% ffmpeg -i inter_weighted_bipred2.264 -f framemd5 -y md5_x86

md5_arm and md5_x86 would be different, but we expect the same decode result 
on different CPUs with the same input bit-stream.

[Bin Peng]

h264 bitstream with weighted-bipred enabled

[Bin Peng]

The reason for the inconsistency is that the value of STRIDE_ALIGN differs between platforms. On x86 platforms, it is greater than 16 (typically 32 or 64), while on ARM platforms, it is 16.
​https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/internal.h#L39

The STRIDE_ALIGN is set to the buffer stride of temporary buffers for U and V components in mc_part_weighted.

uint8_t *tmp_cb = sl->bipred_scratchpad;
uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift);

​https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_mb.c#L410

But the offset of temporary buffers for U and V components is hardcoded to 16.

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.

[Michael Niedermayer <michael@niedermayer.cc>]

In 74fd2c3d/ffmpeg:

avcodec/h264_mb: Fix tmp_cr for arm

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 did overwrite part of the U component's pixels,
leading to incorrect predicted pixels.

The bug can be reproduced by the following bitstream.

​https://trac.ffmpeg.org/attachment/ticket/11357/inter_weighted_bipred2.264

Fixes: ticket 11357
Commit-msg-mostly-by: Bin Peng <​pengbin@visionular.com>
Reviewed-by: Bin Peng <​pengbin@visionular.com>
Signed-off-by: Michael Niedermayer <​michael@niedermayer.cc>