Hi, On Sun, Feb 19, 2012 at 7:42 AM, Ronald S. Bultje <[email protected]> wrote: > Hi, > > On Sun, Feb 19, 2012 at 7:11 AM, Kostya Shishkov > <[email protected]> wrote: >> On Sun, Feb 19, 2012 at 07:05:04AM -0800, Ronald S. Bultje wrote: >>> Hi, >>> >>> On Sun, Feb 19, 2012 at 7:02 AM, Kostya Shishkov >>> <[email protected]> wrote: >>> > On Sun, Feb 19, 2012 at 06:41:55AM -0800, Ronald S. Bultje wrote: >>> >> Hi, >>> >> >>> >> On Sun, Feb 19, 2012 at 2:02 AM, Luca Barbato <[email protected]> wrote: >>> >> > On 19/02/12 09:08, Kostya Shishkov wrote: >>> >> >> This also makes encoder take DCT permutation into account as well. >>> >> >> --- >>> >> >> libavcodec/proresdec.c | 10 +++++----- >>> >> >> libavcodec/proresdsp.c | 11 +++++++++++ >>> >> >> libavcodec/proresdsp.h | 1 + >>> >> >> libavcodec/proresenc.c | 14 +++++++------- >>> >> >> 4 files changed, 24 insertions(+), 12 deletions(-) >>> >> > >>> >> > Ok. >>> >> >>> >> Wait, what happened to make dspcontext smaller? >>> > >>> > nothing, look at the file list again >>> >>> Oh I see. So why is this in dsp then? We can't x86-SIMD this since it >>> uses an indexed table (out[]), where the index is non-linear (scan[]). >> >> It's not scantable, it's permutation table. So if there's no permutation you >> can simply multiply input matrix by quant without reordering. > > Right, but that only happens for C, and the annoying thing is that for > C, there's no way to speed up that multiplication. See the catch-22 > here?
Let me be a little constructive. I'm all for putting this multiplication in a more generic place, e.g. prores.c, so encoder/decoder can share it. But I don't think it belongs in a dsp file, since it cannot be DSPized. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
