[Ffmpeg-devel] I'm giving up

Michael Niedermayer michaelni
Thu Jan 11 21:26:19 CET 2007


Hi

On Thu, Jan 11, 2007 at 11:22:37AM +0100, Panagiotis Issaris wrote:
> 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

yes


> 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.

simple quantization is:
abs(O[x])= (abs(I[x]) + bias) / quantization_scale

which should explain what bias does, threshold is just used to optimize
the most common case ...


> 
> >  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?

whatever you prefer, as long as trellis & bias stuff is possible


> 
> > 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)? 

_IIRC_ what i meant was that you store the dc coeffs seperate of the ac
coeffs while storing both together as they are after dct and before idct
seems more natural (=DC AC AC ... AC DC AC AC ...


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

attach it if you want me to review it, these external urls have the tendency
to be dead in a few years when someone looks at the mailinglist archives

then noone knows what code we where talking about

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070111/04e17e75/attachment.pgp>



More information about the ffmpeg-devel mailing list