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

[Michael Niedermayer]

On Sat, Nov 09, 2013 at 01:05:53PM +0100, Reimar Döffinger wrote:
> On 09.11.2013, at 12:37, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Fri, Nov 08, 2013 at 10:47:20PM +0100, Reimar Döffinger wrote:
> >> Significantly faster than the default path (which defaults to
> >> bicubic scaling even if no real scaling happens), though
> >> the templating is kind of ugly and increases code size a bit.
> >> 
> >> Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> >> ---
> >> libswscale/swscale_unscaled.c |   3 +
> >> libswscale/yuv2rgb.c          | 550 ++++++------------------------------------
> >> libswscale/yuv2rgb_template.c | 458 +++++++++++++++++++++++++++++++++++
> >> 3 files changed, 537 insertions(+), 474 deletions(-)
> >> create mode 100644 libswscale/yuv2rgb_template.c
> >> 
> >> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> >> index 83086f7..8842f35 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_YUV420P9 || srcFormat == AV_PIX_FMT_YUV422P9 ||
> >> +         srcFormat == AV_PIX_FMT_YUV420P10 || srcFormat == AV_PIX_FMT_YUV422P10 ||
> >> +         srcFormat == AV_PIX_FMT_YUV420P16 || srcFormat == AV_PIX_FMT_YUV422P16 ||
> >>          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..28de37e 100644
> >> --- a/libswscale/yuv2rgb.c
> >> +++ b/libswscale/yuv2rgb.c
> >> @@ -54,72 +54,72 @@ 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];
> > 
> > are the shifts faster than bigger tables ?
> > (it would be slightly more accurate with bigger tables)
> 
> I haven't tested. But note that I also added 16-bit support, we are talking about 256 times larger table.
> If keeping the shift for Y that would still be around 48 MB if I calculated right?

this sounds a bit bigger than what i would have expected for 16bit
without a shift


> There could be a "compromise" by making the tables for y, u and v 9 bit and only shifting for > 9 bit, to get better precision. That would only increase their size 4x I believe.

2x


> I guess even making the tables 10 bit might still be reasonable...

> However in both cases I think that will mean further changes since it would also need to increase the HEADROOM stuff.

yes


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131109/956bad27/attachment.asc>