[Ffmpeg-devel] I'm giving up

Michael Niedermayer michaelni
Thu Dec 7 19:16:40 CET 2006


Hi

On Thu, Dec 07, 2006 at 06:00:15PM +0100, Panagiotis Issaris wrote:
> Hi Michael,
> 
> On Thu, 2006-12-07 at 17:14 +0100, Panagiotis Issaris wrote:
> > Hi Michael,
> > 
> > On Wed, 2006-12-06 at 15:25 +0100, Michael Niedermayer wrote:
> > >[...] 
> > > ok, can be commited
> > Done.
> The updated patch containing only the changes to existing files.
> 
> With friendly regards,
> Takis
> -- 
> vCard: http://www.issaris.org/pi.vcf
> Public key: http://www.issaris.org/pi.key

> diff --git a/Changelog b/Changelog
> index c50cf6a..1384120 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -66,6 +66,7 @@ version <next>
>  - TIFF picture decoder
>  - GIF picture decoder
>  - Intel Music decoder
> +- Native H.264 encoder
>  
>  version 0.4.9-pre1:
>  
> diff --git a/doc/ffmpeg-doc.texi b/doc/ffmpeg-doc.texi
> index 6f42f33..19e65ed 100644
> --- a/doc/ffmpeg-doc.texi
> +++ b/doc/ffmpeg-doc.texi
> @@ -931,7 +931,7 @@ following image formats are supported:
>  @item VC1                    @tab     @tab  X
>  @item H.261                  @tab  X  @tab  X
>  @item H.263(+)               @tab  X  @tab  X @tab also known as RealVideo 1.0
> - at item H.264                  @tab     @tab  X
> + at item H.264                  @tab  X  @tab  X
>  @item RealVideo 1.0          @tab  X  @tab  X
>  @item RealVideo 2.0          @tab  X  @tab  X
>  @item MJPEG                  @tab  X  @tab  X

these are of course fine as soon as they are true ...



[...]
> 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) and second for more complex quantization like trellis
this all somehow doesnt belong in DSPContext
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?


>  
>      /* snow wavelet */
>      void (*vertical_compose97i)(DWTELEM *b0, DWTELEM *b1, DWTELEM *b2, DWTELEM *b3, DWTELEM *b4, DWTELEM *b5, int width);
> diff --git a/tests/ffmpeg.regression.ref b/tests/ffmpeg.regression.ref
> index 9db847a..e142584 100644
> --- a/tests/ffmpeg.regression.ref
> +++ b/tests/ffmpeg.regression.ref
> @@ -59,6 +59,10 @@ e9e884a7c6b77d1aeeb4cb56ac150f92 *./data
>  2389564 ./data/a-h263p.avi
>  0bb16a352798c997cb36e167f4fa8f3c *./data/out.yuv
>  stddev:  2.07 PSNR:41.77 bytes:7602176
> +edf347e9edb3c1ba89ade82070f8ba30 *./data/a-ffh264.mp4
> +3015289 ./data/a-ffh264.mp4
> +d0942b33f272c0ade4fab2f84c418631 *./data/out.yuv
> +stddev:  0.68 PSNR:51.38 bytes:7602176
>  3ee2dd25f141d520f61e5c01d08bdef1 *./data/a-odivx.mp4
>  550787 ./data/a-odivx.mp4
>  a1c691f3be526ecbf3be3152d5bab88c *./data/out.yuv

that and the related stuff too is fine as soon as it can be added without 
breaking the regression tests (=after we have a working h.264 encoder in svn)


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