[FFmpeg-devel] Patch review request: 10bit DNxHD decoding support

Joseph Artsimovich joseph
Fri Mar 11 10:34:41 CET 2011


> >      p8idct(block, temp, NULL,         0, 1, 8, 0);
> >      p8idct(NULL , temp, dest, line_size, 8, 1, 3);  }
> > +
> > +void ff_faanidct10_put(uint16_t *dest, int line_size, DCTELEM block[64]){
> > +    FLOAT temp[64];
> > +    FLOAT* p_tmp = temp;
> > +    int i, j;
> > +
> > +    emms_c();
> 
> this should be moved out of the inner loop of the codec
Do you mean emms_c() should be moved out of this function?  You are not talking about the local variables I presume.  Well, I just copied that bit from ff_faandct().  Should that one be removed as well?

> > +
> > +    for(i=0; i<64; i++)
> > +        temp[i] = block[i] * prescale[i];
> > +
> > +    p8idct(NULL, temp, NULL,         0, 1, 8, 0);
> > +    p8idct(NULL, temp, NULL,         0, 8, 1, 0);
> > +
> > +    for (i = 0; i < 8; ++i) {
> > +        for (j = 0; j < 8; ++j) {
> > +            int val = (int)lrintf((float)p_tmp[j] * (65536.0f /
> > + 1023.0f) + 0.5f);
> 
> the scaling can be merged with prescale and +0.5 looks wrong
I have to say lrintf type of functions scare me and I normally never use them.  The "current rounding direction" sounds like undefined behaviour to me.  Is the default rounding direction always "towards zero" or does it keep changing?  And yes, +0.5 would be wrong for "towards zero".  It would be correct for "towards negative infinity".  I must have been thinking about putting floor() rather than lrintf() there.


Joseph Artsimovich
Software Developer
MirriAd Ltd






More information about the ffmpeg-devel mailing list