Results may be 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.