[FFmpeg-trac] #9751(swscale:new): Incorrect YUV->RGB24 conversion results on IBM Power9

FFmpeg trac at avcodec.org
Wed Apr 27 15:02:23 EEST 2022


#9751: Incorrect YUV->RGB24 conversion results on IBM Power9
-------------------------------------+-----------------------------------
             Reporter:  gciaparrone  |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:  swscale
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-----------------------------------
Description changed by gciaparrone:

Old description:

> Converting a YUV frame into an RGB24 image seems to produce incorrect
> results on an IBM Power9 processor. Compiling ffmpeg with --disable-
> altivec solves the issue. The problem might be related to this old issue
> pointed out by Hong Bo Peng here:
> https://trac.ffmpeg.org/ticket/7124#comment:7
>
> This can be more easily seen by converting a completely black image from
> RGB to YUV and then back to RGB on an IBM Power9 (or possibly on any
> Little Endian processor with ALTIVEC support?). The output image has all
> pixels set to [16, 16, 16] instead of [0, 0, 0]. The issue spans multiple
> versions of ffmpeg, including the current git master version. Using
> --disable-altivec or running the command on a non-ALTIVEC processor
> outputs the correct image with all [0, 0, 0] pixels.
>
> Input image:
>
> Output image (IBM Power9):
>
> Output image (AMD Ryzen 5 1600X processor):
>
> Output image (IBM Power9, --disable-altivec):
>

>
> How to reproduce:
> {{{
> # convert RGB image to YUV420p
> $ ffmpeg -i black.png -pix_fmt yuv420p black.yuv
> # convert it back to RGB
> $ ffmpeg -s:v 64x64 -pix_fmt yuv420p -i black.yuv -frames:v 1 -pix_fmt
> rgb24 reblack.png
> }}}

New description:

 Converting a YUV frame into an RGB24 image seems to produce incorrect
 results on an IBM Power9 processor. Compiling ffmpeg with --disable-
 altivec solves the issue. The problem might be related to this old issue
 pointed out by Hong Bo Peng here:
 https://trac.ffmpeg.org/ticket/7124#comment:7

 This can be more easily seen by converting a completely black image from
 RGB to YUV and then back to RGB on an IBM Power9 (or possibly on any
 Little Endian processor with ALTIVEC support?). The output image has all
 pixels set to [16, 16, 16] instead of [0, 0, 0]. The issue spans multiple
 versions of ffmpeg, including the current git master version. Using
 --disable-altivec or running the command on a non-ALTIVEC processor
 outputs the correct image with all [0, 0, 0] pixels.

 Input image:
 [[Image(black.png)]]

 Output image (IBM Power9):
 [[Image(reblack_bad.png)]]

 Output image (AMD Ryzen 5 1600X processor):
 [[Image(reblack_amd.png)]]

 Output image (IBM Power9, --disable-altivec):
 [[Image(reblack.png)]]



 How to reproduce:
 {{{
 # convert RGB image to YUV420p
 $ ffmpeg -i black.png -pix_fmt yuv420p black.yuv
 # convert it back to RGB
 $ ffmpeg -s:v 64x64 -pix_fmt yuv420p -i black.yuv -frames:v 1 -pix_fmt
 rgb24 reblack.png
 }}}

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9751#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list