[Ffmpeg-devel] I'm giving up

Panagiotis Issaris takis.issaris
Wed Dec 6 14:47:32 CET 2006


Hi Michael,

On Tue, 2006-12-05 at 18:47 +0100, Michael Niedermayer wrote:
> [...]
> 
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 96ea77a..5bc2f00 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -144,6 +144,7 @@ enum CodecID {
> >      CODEC_ID_VP5,
> >      CODEC_ID_VP6,
> >      CODEC_ID_VP6F,
> > +    CODEC_ID_FFH264,
> >      CODEC_ID_TARGA,
> 
> breaks ABI
Yes, you are right. It is intentionally in my personal tree as I got
conflicts on every new codec entering FFmpeg before ours.

I fixed it now though.


> >      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_dct)(DCTELEM inblock[4][4], DCTELEM outblock[4][4]);
> 
> is there any advantage in inblock != outblock?
Not really. Fixed.


> > +    void (*h264_idct_notranspose_add)(uint8_t *dst, DCTELEM *block, int stride);
> > +    void (*h264_hadamard_mult4x4)(DCTELEM Y[4][4]);
> > +    void (*h264_hadamard_quant_2x2)(int16_t Y[2][2], int QP);
> > +    void (*h264_hadamard_quant_4x4)(DCTELEM Y[4][4], int QP);
> > +    void (*h264_hadamard_invquant_4x4)(DCTELEM Y[4][4], int QP);
> > +    void (*h264_transform_dct_quant)(int16_t block[4][4], int QP, int dontscaleDC);
> > +    void (*h264_transform_inverse_quant_dct_add)(int16_t block[4][4], int QP, int dontscaleDC, uint8_t *dst, int stride);
> 
> there is some inconsistance in int16_t vs.DCTELEM ...
Fixed.

> [...]
> > @@ -422,13 +408,22 @@ static always_inline uint32_t pack16to32
> >  #endif
> >  }
> >  
> > +const uint8_t rem6[52]={
> > +0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3,
> > +};
> > +
> > +const uint8_t div6[52]={
> > +0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 8, 8, 8, 8,
> > +};
> 
> need ff_ prefix
Fixed.

> > -static always_inline void fill_rectangle(void *vp, int w, int h, int stride, uint32_t val, int size){
> > +always_inline void fill_rectangle(void *vp, int w, int h, int stride, uint32_t val, int size){
> >      uint8_t *p= (uint8_t*)vp;
> >      assert(size==1 || size==4);
> >      assert(w<=4);
> > @@ -1808,70 +1803,7 @@ static uint8_t *decode_nal(H264Context *
> >      return dst;
> >  }
> >  
> > -#if 0
> 
> removing the #if 0 code or moving them to a fresh new h264-whatever file is
> ok feel free to commit this part anytime
Does that mean I can add a h264enc.c file containing a new NAL encoding
implementation (which is based on yours and ours combined as suggested
in an earlier review) and H264 DCT in a h264dsp.c file while removing
the #if 0'ed out version h264_diff_dct_c()?


I've also attached an updated version of the modifications only patch.

Thanks for reviewing!

With friendly regards,
Takis
-- 
vCard: http://www.issaris.org/pi.vcf
Public key: http://www.issaris.org/pi.key
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edm-20061206T141750-ffmpeg-nal_encoding.diff
Type: text/x-patch
Size: 3100 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061206/6d01460c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edm-20061206T143723-ffmpeg-h264dct.c
Type: text/x-patch
Size: 6028 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061206/6d01460c/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edm-20061206T143958-ffmpeg-h264_only_modifications.diff
Type: text/x-patch
Size: 10833 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061206/6d01460c/attachment-0002.bin>



More information about the ffmpeg-devel mailing list