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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4