[Ffmpeg-devel] I'm giving up
Michael Niedermayer
michaelni
Tue Dec 5 18:47:48 CET 2006
Hi
On Tue, Dec 05, 2006 at 05:17:54PM +0100, Panagiotis Issaris wrote:
> Hi Michael,
>
> On Tue, 2006-12-05 at 15:56 +0100, Michael Niedermayer wrote:
> > > The diffstat shows that the modifications in the patch in existing files
> > > is minimal:
> > > Changelog | 1
> > > doc/ffmpeg-doc.texi | 2
> > > libavcodec/Makefile | 1
> > > libavcodec/allcodecs.c | 2
> > > libavcodec/avcodec.h | 1
> > > libavcodec/dsputil.c | 8
> > > libavcodec/dsputil.h | 16
> > >
> > >
> > > These are the only exceptions, and they were made in response to
> > > suggestions on the mailinglist:
> > > libavcodec/h264.c | 146 --
> > > libavcodec/h264data.h | 27
> > >
> > >
> > > I could remove the regression tests modifications to make the patch even
> > > less intrusive, but I'd think that wouldn't be a good thing to do.
> > > tests/Makefile | 2
> > > tests/ffmpeg.regression.ref | 4
> > > tests/regression.sh | 13
> > > tests/rotozoom.regression.ref | 4
> > >
> > >
> > could you send a patch with just the needed changes to existing files?
> >
> > [...]
> Sure. This is just the normal patch, stripped to contain only the
> changes to existing files. I'm not sure this is what you intended
> though... If it isn't, I'm ready to modify and send a new one.
>
> Patch against revision 7225 (current) attached.
> Changelog | 1
> doc/ffmpeg-doc.texi | 2
> libavcodec/Makefile | 1
> libavcodec/allcodecs.c | 2
> libavcodec/avcodec.h | 1
> libavcodec/dsputil.c | 8 ++
> libavcodec/dsputil.h | 16 ++++
> libavcodec/h264.c | 146
> ++++++------------------------------------
> libavcodec/h264data.h | 27 +++++--
> tests/Makefile | 2
> tests/ffmpeg.regression.ref | 4 +
> tests/regression.sh | 13 +++
> tests/rotozoom.regression.ref | 4 +
> 13 files changed, 90 insertions(+), 137 deletions(-)
[...]
> 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
[...]
> @@ -378,10 +385,19 @@ typedef struct DSPContext {
> #define BASIS_SHIFT 16
> #define RECON_SHIFT 6
>
> + /* h264 functions */
> void (*h264_idct_add)(uint8_t *dst, DCTELEM *block, int stride);
ok commit this anytime
> 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?
> + 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 ...
[...]
> @@ -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
> +
> +
> /**
> * fill a rectangle.
> * @param h height of the rectangle, should be a constant
> * @param w width of the rectangle, should be a constant
> * @param size the size of val (1 or 4), should be a constant
> */
> -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
[...]
> //FIXME need to check that this doesnt overflow signed 32 bit for low qp, i am not sure, it's very close
> //FIXME check that gcc inlines this (and optimizes intra & seperate_dc stuff away)
> static inline int quantize_c(DCTELEM *block, uint8_t *scantable, int qscale, int intra, int seperate_dc){
> @@ -2357,7 +2253,7 @@ static void pred4x4_horizontal_down_c(ui
> src[1+3*stride]=(l1 + 2*l2 + l3 + 2)>>2;
> }
>
> -static void pred16x16_vertical_c(uint8_t *src, int stride){
> +void pred16x16_vertical_c(uint8_t *src, int stride){
ok to commit anytime if you add a ff_ prefix
[...]
> diff --git a/libavcodec/h264data.h b/libavcodec/h264data.h
> index 2dea358..74e7204 100644
> --- a/libavcodec/h264data.h
> +++ b/libavcodec/h264data.h
> @@ -53,6 +53,24 @@
>
> #define EXTENDED_SAR 255
>
> +/* NAL unit types */
> +enum {
> +NAL_SLICE=1,
> +NAL_DPA,
> +NAL_DPB,
> +NAL_DPC,
> +NAL_IDR_SLICE,
> +NAL_SEI,
> +NAL_SPS,
> +NAL_PPS,
> +NAL_AUD,
> +NAL_END_SEQUENCE,
> +NAL_END_STREAM,
> +NAL_FILLER_DATA,
> +NAL_SPS_EXT,
> +NAL_AUXILIARY_SLICE=19
> +};
this can be commited anytime too
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
More information about the ffmpeg-devel
mailing list