[FFmpeg-devel] [PATCH] Support > 8 bit input in yuv2rgb.

[Ronald S. Bultje]

Hi,

On Thu, Nov 7, 2013 at 10:45 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:

> "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >On Wed, Nov 6, 2013 at 4:15 PM, Reimar Döffinger
> ><Reimar.Doeffinger at gmx.de>wrote:
> >
> >> Fairly ugly but about 3x faster than the default path (tested on
> >ARM).
> >>
> >> Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> >> ---
> >>  libswscale/swscale_unscaled.c |   3 +
> >>  libswscale/yuv2rgb.c          | 540
> >> ++++++------------------------------------
> >>  libswscale/yuv2rgb_template.c | 458
> >+++++++++++++++++++++++++++++++++++
> >>  3 files changed, 532 insertions(+), 469 deletions(-)
> >>  create mode 100644 libswscale/yuv2rgb_template.c
> >>
> >> diff --git a/libswscale/swscale_unscaled.c
> >b/libswscale/swscale_unscaled.c
> >> index 83086f7..4864f46 100644
> >> --- a/libswscale/swscale_unscaled.c
> >> +++ b/libswscale/swscale_unscaled.c
> >> @@ -1217,6 +1217,9 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >>      }
> >>      /* yuv2bgr */
> >>      if ((srcFormat == AV_PIX_FMT_YUV420P || srcFormat ==
> >> AV_PIX_FMT_YUV422P ||
> >> +         srcFormat == AV_PIX_FMT_YUV420P9LE || srcFormat ==
> >> AV_PIX_FMT_YUV422P9LE ||
> >> +         srcFormat == AV_PIX_FMT_YUV420P10LE || srcFormat ==
> >> AV_PIX_FMT_YUV422P10LE ||
> >> +         srcFormat == AV_PIX_FMT_YUV420P16LE || srcFormat ==
> >> AV_PIX_FMT_YUV422P16LE ||
> >>           srcFormat == AV_PIX_FMT_YUVA420P) && isAnyRGB(dstFormat) &&
> >>          !(flags & SWS_ACCURATE_RND) && (c->dither ==
> >SWS_DITHER_BAYER ||
> >> c->dither == SWS_DITHER_AUTO) && !(dstH & 1)) {
> >>          c->swscale = ff_yuv2rgb_get_func_ptr(c);
> >> diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
> >> index 77c56a9..946ed79 100644
> >> --- a/libswscale/yuv2rgb.c
> >> +++ b/libswscale/yuv2rgb.c
> >> @@ -54,66 +54,66 @@ const int *sws_getCoefficients(int colorspace)
> >>  }
> >>
> >>  #define LOADCHROMA(i)                               \
> >> -    U = pu[i];                                      \
> >> -    V = pv[i];                                      \
> >> +    U = pu[i] >> shift;                             \
> >> +    V = pv[i] >> shift;                             \
> >>      r = (void *)c->table_rV[V+YUVRGB_TABLE_HEADROOM];
> >> \
> >>      g = (void *)(c->table_gU[U+YUVRGB_TABLE_HEADROOM] +
> >> c->table_gV[V+YUVRGB_TABLE_HEADROOM]);  \
> >>      b = (void *)c->table_bU[U+YUVRGB_TABLE_HEADROOM];
> >
> >
> >
> >So ... I'm going to have to ask this, I'm sure you understand. Why on
> >earth
> >are you using 10bits video in whatever it is you're doing if you end up
> >clipping it back to 8bits again? Isn't it much, much faster to just
> >serve
> >8bits?
>
> Huh? I kind of would have expected you to be aware that a lot of 8-bit
> content (in particular anime I believe) is encoded as 10 bit H.264 because
> the codec is actually more efficient that way (if I remember right hevc
> kind of fixes this by always using higher precision DCT?).
> Or in other words your question is based on two or 3 wrong assumptions:
> 1) that the precision used by the encoder is actually related to the
> precision of the original content
> 2) that I actually have any kind of control over how the content I'd like
> to play is encoded
> 3) that I actually have a particular use-case for this. ;-) Because in
> fact I just noticed this as some obvious low-hanging fruit while trying
> some sample videos and testing what the fastest way to play them is.
>
> Clearer now?
> I believe there is still value in this, but if you all shout at me it's
> nonsense I'll drop it.


Well (3) is the most important one. Typically when people use ffmpeg on a
cellphone, it's for a custom application that has a custom video input that
the application maker has full end-to-end control over. As such, they can
(2).

So that leaves (1). Quality loss b/c of intermediate rounding is indeed
lower, so overall quality is higher. The question is whether you can see
this on a crappy cell phone screen, and whether that improvement in quality
is worth it re: the higher CPU use that you will have regardless of whether
you use these slightly more optimal C functions in colorspace conversion or
not.

Ronald