[FFmpeg-trac] #11182(swscale:closed): yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference

FFmpeg trac at avcodec.org
Tue Sep 10 04:55:25 EEST 2024


#11182: yuvtestsrc and yuv444p->rgba->yuv444p conversion result in huge difference
-------------------------------------+-------------------------------------
             Reporter:  Andrew-R     |                    Owner:  (none)
                 Type:  defect       |                   Status:  closed
             Priority:  normal       |                Component:  swscale
              Version:  unspecified  |               Resolution:  invalid
             Keywords:  colorspace   |               Blocked By:
  color_primaries                    |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Balling):

 >Mathematically makes no sense: At the same bit-depth, where comes such
 difference?

 In the case with full range RGB to full range YCbCr... There are some
 values in YCbCr that will be negative R', G', B'. (For example in limited
 range YCbCr BT.709 values 139, 151, 24 will be limited (!) RGB -21, 182,
 181 and full RGB -43, 194, 192.)
 https://stackoverflow.com/questions/32321631/is-converting-ycbcr-to-rgb-
 reversible


 The bit depth does not play any role. Even 12 bit YCbCr is still 6 times
 bigger than RGB. What makes the change is if you use BT.2020 linear RGB
 now, that would be bigger than YCbCr and that is how:


 >While most (if not all?) displays expect RGB from hardware aspect..?

 My LG C9 supports direct rendering of YCbCr data (and so do Intel and
 Nvidia), there is no RGB in it, it is WRGB. Moreover the way this works is
 that the color engagement works through XYZ, not RGB.


 Here
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11182#comment:11>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list