| Message ID | 20200713003314.2279-1-jamrial@gmail.com |
|---|---|
| State | Accepted |
| Commit | ba3e771a42c29ee02c34e7769cfc1b2dbc5c760a |
| Headers | show |
| Series | [FFmpeg-devel] x86/yuv2rgb: fix crashes when storing data on unaligned buffers | expand |
| Context | Check | Description |
|---|---|---|
| andriy/default | pending | |
| andriy/make | success | Make finished |
| andriy/make_fate | success | Make fate finished |
> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>: > > Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled > CPUs. FFmpeg does not require aligned output buffers on x86_64? > Fixes ticket #8747 Another issue is described in this ticket that implies an overwrite: Can you reproduce? Thank you, Carl Eugen
On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote: > > >> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>: >> >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled >> CPUs. > > FFmpeg does not require aligned output buffers on x86_64? There's no alignment requirement mentioned anywhere in swscale.h, which explains why every other asm function also uses unaligned mov instructions when handling src and dst buffers. > >> Fixes ticket #8747 > > Another issue is described in this ticket that implies an overwrite: Can you reproduce? No, I haven't tried that one under valgrind. > > Thank you, Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Mon, Jul 13, 2020 at 3:10 AM Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > > > > Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>: > > > > Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 > enabled > > CPUs. > > FFmpeg does not require aligned output buffers on x86_64? Not in swscale/avfilter, only in avcodec. Ronald
On Mon, Jul 13, 2020 at 10:19:07AM -0300, James Almer wrote: > On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote: > > > > > >> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>: > >> > >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled > >> CPUs. > > > > FFmpeg does not require aligned output buffers on x86_64? > > There's no alignment requirement mentioned anywhere in swscale.h, which > explains why every other asm function also uses unaligned mov > instructions when handling src and dst buffers. swscale will print a warning though if its provided with unaligned buffers or strides So i would assume that most library users attempt to supply it with aligned buffers. Thats something new optimized code could take advantage of thx [...]
Am Mo., 13. Juli 2020 um 15:19 Uhr schrieb James Almer <jamrial@gmail.com>: > > On 7/13/2020 4:02 AM, Carl Eugen Hoyos wrote: > > > > > >> Am 13.07.2020 um 02:33 schrieb James Almer <jamrial@gmail.com>: > >> > >> Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled > >> CPUs. > > > > FFmpeg does not require aligned output buffers on x86_64? > > There's no alignment requirement mentioned anywhere in swscale.h, which > explains why every other asm function also uses unaligned mov > instructions when handling src and dst buffers. Thank you both for the explanation, I misremembered. > >> Fixes ticket #8747 > > > > Another issue is described in this ticket that implies an overwrite: Can you reproduce? > > No, I haven't tried that one under valgrind. Given that I was unable to produce unaligned buffers for above issue, this part of the report looked more important to me. Carl Eugen
diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm index 575a84d921..003dff1f25 100644 --- a/libswscale/x86/yuv_2_rgb.asm +++ b/libswscale/x86/yuv_2_rgb.asm @@ -268,9 +268,9 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters por m2, m7 por m1, m6 ; g5 b5 r6 g6 b6 r7 g7 b7 r8 g8 b8 r9 g9 b9 r10 g10 por m2, m3 ; b10 r11 g11 b11 r12 g12 b12 r13 g13 b13 r14 g14 b14 r15 g15 b15 - mova [imageq], m0 - mova [imageq + 16], m1 - mova [imageq + 32], m2 + movu [imageq], m0 + movu [imageq + 16], m1 + movu [imageq + 32], m2 %endif ; mmsize = 16 %else ; PACK RGB15/16/32 packuswb m0, m1 @@ -300,10 +300,10 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters punpckhwd m_green, m_red punpcklwd m5, m6 punpckhwd m_alpha, m6 - mova [imageq + 0], m_blue - mova [imageq + 8 * time_num], m_green - mova [imageq + 16 * time_num], m5 - mova [imageq + 24 * time_num], m_alpha + movu [imageq + 0], m_blue + movu [imageq + 8 * time_num], m_green + movu [imageq + 16 * time_num], m5 + movu [imageq + 24 * time_num], m_alpha %else ; PACK RGB15/16 %define depth 2 %if cpuflag(ssse3) @@ -342,8 +342,8 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters mova m2, m0 punpcklbw m0, m1 punpckhbw m2, m1 - mova [imageq], m0 - mova [imageq + 8 * time_num], m2 + movu [imageq], m0 + movu [imageq + 8 * time_num], m2 %endif ; PACK RGB15/16 %endif ; PACK RGB15/16/32
Regression since fc6a5883d6af8cae0e96af84dda0ad74b360a084 on SSSE3 enabled CPUs. Fixes ticket #8747 Signed-off-by: James Almer <jamrial@gmail.com> --- libswscale/x86/yuv_2_rgb.asm | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)