FFmpeg

110153 Commits

37 Branches

400 Tags

484 MiB

Tag: Branch: Tree: 0adb375377

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
Wenbin Chen	76b33704b6	avcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb() For 422 frames we should not use hard coded 8 to calculate mb size for uv plane. Chroma shift should be taken into consideration to be compatiple with different sampling format. The error is reported by fate test when av_cpu_max_align() return 64 on the platform supporting AVX512. This is a hidden error and it is exposed after commit `17a59a634c`. mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of squared error) on current mb, reconstructed mb will be wrote to the previous mb space, so that the memory can be saved. However if the align is 64, the frame is shared in somewhere else, so the frame cannot be reused and a new frame to store reconstrued data is created. Because the height of mb is wrong when compute sse on 422 frame, starting from the second line of macro block, changed data is read when frame is reused (we need to read row 16 rather than row 8 if frame is 422), and unchanged data is read when frame is not reused (a new frame is created so the original frame will not be changed). That is why commit `17a59a634c` exposes this issue, because it add av_cpu_max_align() and this function return 64 on platform supporting AVX512 which lead to creating a frame in mpeg2enc, and this lead to the different outputs. Signed-off-by: Wenbin Chen <wenbin.chen@intel.com> Signed-off-by: Marton Balint <cus@passwd.hu>	3 years ago
Michael Niedermayer	ed49b142bb	tests: Rename vsynth2 to vsynth_lena This avoids confusion with a growing number of vsynth tests Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago

Wenbin Chen

76b33704b6

avcodec/mpegvideo_enc: Fix a chroma mb size error in sse_mb()

For 422 frames we should not use hard coded 8 to calculate mb size for
uv plane. Chroma shift should be taken into consideration to be
compatiple with different sampling format.

The error is reported by fate test when av_cpu_max_align() return 64
on the platform supporting AVX512. This is a hidden error and it is
exposed after commit 17a59a634c.

mpeg2enc has a mechanism to reuse frames. When it computes SSE (sum of
squared error) on current mb, reconstructed mb will be wrote to the
previous mb space, so that the memory can be saved. However if the align
is 64, the frame is shared in somewhere else, so the frame cannot be
reused and a new frame to store reconstrued data is created. Because the
height of mb is wrong when compute sse on 422 frame, starting from the
second line of macro block, changed data is read when frame is reused
(we need to read row 16 rather than row 8 if frame is 422), and unchanged
data is read when frame is not reused (a new frame is created so the
original frame will not be changed).

That is why commit 17a59a634c exposes this
issue, because it add av_cpu_max_align() and this function return 64 on
platform supporting AVX512 which lead to creating a frame in mpeg2enc,
and this lead to the different outputs.

Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

3 years ago

Michael Niedermayer

ed49b142bb

tests: Rename vsynth2 to vsynth_lena

This avoids confusion with a growing number of vsynth tests

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

10 years ago

2 Commits (0adb375377f369b69b24d86bbfe674b7693ccf3c)