[FFmpeg-devel] [PATCH] Indeo5 decoder

[Michael Niedermayer]

On Fri, Apr 17, 2009 at 01:44:30PM +0200, Maxim wrote:
> Michael Niedermayer schrieb:
> > On Tue, Apr 07, 2009 at 05:08:34PM +0200, Maxim wrote:
> >   
> >> Michael Niedermayer schrieb:
> >>     
> >>> On Tue, Apr 07, 2009 at 10:52:34AM +0200, Maxim wrote:
> >>>   
> >>>       
> >>>> Michael Niedermayer schrieb:
> >>>>     
> >>>>         
> >>>>> On Mon, Apr 06, 2009 at 08:41:57PM +0200, Maxim wrote:
> >>>>>       
> >>>>>           
> >>> [...]
> >>>   
> >>>       
> >>>>>> +
> >>>>>> +
> >>>>>> +/**
> >>>>>> + *  Build static indeo5 dequantization tables.
> >>>>>> + */
> >>>>>> +static av_cold void build_dequant_tables(void)
> >>>>>> +{
> >>>>>> +    int         mat, i, lev;
> >>>>>> +    uint32_t    q1, q2, sf1, sf2;
> >>>>>> +
> >>>>>> +    for (mat = 0; mat < 5; mat++) {
> >>>>>> +        /* build 8x8 intra/inter tables for all 24 quant levels */
> >>>>>> +        for (lev = 0; lev < 24; lev++) {
> >>>>>> +            sf1 = ivi5_scale_quant_8x8_intra[mat][lev];
> >>>>>> +            sf2 = ivi5_scale_quant_8x8_inter[mat][lev];
> >>>>>> +
> >>>>>> +            for (i = 0; i < 64; i++) {
> >>>>>> +                q1 = (ivi5_base_quant_8x8_intra[mat][i] * sf1) >> 8;
> >>>>>> +                q2 = (ivi5_base_quant_8x8_inter[mat][i] * sf2) >> 8;
> >>>>>> +                deq8x8_intra[mat][lev][i] = av_clip(q1, 1, 255);
> >>>>>> +                deq8x8_inter[mat][lev][i] = av_clip(q2, 1, 255);
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> 1..255 but they arent uint8_t 
> >>>>> av_clip() seems useless  and the whole table precalc maybe as well
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> They were made uint16_t in order to achieve a compatibility with Indeo4
> >>>> that uses 9bits dequant tables...
> >>>> The table precalculation should help avoiding huge static tables...
> >>>>     
> >>>>         
> >>> let me clarify my question, what is gained by merging a multiply and shift
> >>> into the table?
> >>> is it faster? if so then by how much?
> >>>       
> 
> I did some research on that! Here are answers on your questions:
> 
> Question: Is it faster? if so then how much?
> 
> Yes, it's faster. I measured calc "time" using START/STOP_TIMER macs. I
> did two tests on two different videos: one containing mostly light
> colors (DPS190indeo.avi) and another containing mostly dark colors
> (haegemonia.avi). The reason for this choice was that the light colors
> require higher scalefactors to be used and therefore a multiply by a
> higher number.
> First test measured dezicycles consumed by the inverse quantization
> using TABLE lookup/MUL. It was done in my x86 Laptop equipped with the
> Indel Core Duo processor at 2 GHz. Here are the raw numbers:

could you show me the used code?
Iam interrested to see how you did the MUL

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090417/01d847fe/attachment.pgp>