[Ffmpeg-devel] I'm giving up

Panagiotis Issaris takis.issaris
Thu Jan 11 11:22:37 CET 2007


Hi Michael,

On Thu, 2006-12-07 at 19:16 +0100, Michael Niedermayer wrote: 
> [...]
> > diff --git a/libavcodec/dsputil.h b/libavcodec/dsputil.h
> > index c728c1b..b87685b 100644
> > --- a/libavcodec/dsputil.h
> > +++ b/libavcodec/dsputil.h
> > @@ -59,6 +59,8 @@ void ff_h264_idct8_dc_add_c(uint8_t *dst
> >  void ff_h264_idct_dc_add_c(uint8_t *dst, DCTELEM *block, int stride);
> >  void ff_h264_lowres_idct_add_c(uint8_t *dst, int stride, DCTELEM *block);
> >  void ff_h264_lowres_idct_put_c(uint8_t *dst, int stride, DCTELEM *block);
> > +void ff_h264_hadamard_inv_quant_2x2(DCTELEM Y[2][2], int QP);
> > +void ff_h264_hadamard_mult_2x2(DCTELEM Y[2][2]);
> >  
> >  void ff_vector_fmul_add_add_c(float *dst, const float *src0, const float *src1,
> >                                const float *src2, int src3, int blocksize, int step);
> > @@ -383,7 +385,14 @@ typedef struct DSPContext {
> >      void (*h264_idct8_add)(uint8_t *dst, DCTELEM *block, int stride);
> >      void (*h264_idct_dc_add)(uint8_t *dst, DCTELEM *block, int stride);
> >      void (*h264_idct8_dc_add)(uint8_t *dst, DCTELEM *block, int stride);
> > +    void (*h264_idct_notranspose_add)(uint8_t *dst, DCTELEM *block, int stride);
> >      void (*h264_dct)(DCTELEM block[4][4]);
> > +    void (*h264_dct_quant)(DCTELEM block[4][4], int QP, int dontscaleDC);
> > +    void (*h264_inv_quant_dct_add)(DCTELEM block[4][4], int QP, int dontscaleDC, uint8_t *dst, int stride);
> > +    void (*h264_hadamard_quant_2x2)(DCTELEM Y[2][2], int QP);
> > +    void (*h264_hadamard_quant_4x4)(DCTELEM Y[4][4], int QP);
> > +    void (*h264_hadamard_inv_quant_4x4)(DCTELEM Y[4][4], int QP);
> > +    void (*h264_hadamard_mult_4x4)(DCTELEM Y[4][4]);
> 
> somehow i dont like the quantizaton functions in here, first they dont
> get enough information (thinking of quantization bias values from
> AVCodecContext)
Are you talking about intra_quant_bias and inter_quant_bias? What do
those parameters actually do? I didn't find an explanation in the
documentation or sourcecode comments. I did find that they are being
used in the dct_quantize_c function to set bias, and that bias is being
used to set both threshold1 and level.

>  and second for more complex quantization like trellis
> this all somehow doesnt belong in DSPContext
I've moved the quantization functions out of the DSPContext back into
h264enc.c or would you prefer a separate file for the quantization
related functions?

> then about [2][2] for the dc coeffs, is it really ideal to store them
> like that and not in a [4][16] or so thingy?
I'm not sure I truly understand this... Do you mean you'd prefer
to see the DC coeffs of both luma and chroma stored in one bigger array
instead of the current three arrays (YD, UD, VD)? 

> [...]

Current patch available here:
http://research.edm.uhasselt.be/h264/patches/edm-20070111T111655-ffmpeg-h264.diff

With friendly regards,
Takis
-- 
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key





More information about the ffmpeg-devel mailing list