[FFmpeg-devel] [PATCH] lavfi/hue: use lookup tables

[Michael Niedermayer]

On Tue, Aug 20, 2013 at 09:43:17AM +0000, Paul B Mahol wrote:
> On 8/20/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Aug 19, 2013 at 08:50:44PM +0000, Paul B Mahol wrote:
> >> On 8/19/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Mon, Aug 19, 2013 at 08:28:14PM +0000, Paul B Mahol wrote:
> >> >> On 8/19/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >> > On Mon, Aug 19, 2013 at 07:12:04PM +0000, Paul B Mahol wrote:
> >> >> >> Signed-off-by: Paul B Mahol <onemda at gmail.com>
> >> >> >> ---
> >> >> >>  libavfilter/vf_hue.c | 76
> >> >> >> +++++++++++++++++++++++++++++++---------------------
> >> >> >>  1 file changed, 45 insertions(+), 31 deletions(-)
> >> >> >
> >> >> > breaks -vf hue=90
> >> >> >
> >> >> > also i dont see how this could work, rotation is not newu=f(oldu)
> >> >>
> >> >> obviously, i need bigger luts, but do you consider lut approach worth
> >> >> it?
> >> >
> >> > if its faster sure, but iam not sure SIMD without LUT wont beat it
> >>
> >> shouldn't lut with SIMD be fastest?
> >
> > if theres a CPU and a architecture that has a fast multiple lookup
> > instruction
> 
> The way how you said it, it appears there is none.

i dont know if theres one (not counting FPGAs here)


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

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20130820/95e1d3dc/attachment.asc>