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

[Reimar Döffinger]

"Ronald S. Bultje" <rsbultje at gmail.com> wrote:
>Hi,
>
>
>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.