[FFmpeg-devel] [PATCH] Support > 8 bit input in yuv2rgb.
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Thu Nov 7 16:45:38 CET 2013
"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.
More information about the ffmpeg-devel
mailing list