[FFmpeg-devel] [PATCH] Chinese AVS encoder

[Michael Niedermayer]

Hi

On Sat, Jul 21, 2007 at 11:06:42AM +0200, Stefan Gehrer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> as announced before here is my encoder for Chinese AVS.
> Features that it does support:
> - - Intra macroblocks
> - - P_SKIP macroblocks
> - - P_16x16 macroblocks
> - - one or two reference frames
> - - constant quantizer encoding
> - - motion estimation using hexagon search and qpel refinement
> Features that it does not support:
> - - P_16x8, P_8x16 and P_8x8 macroblocks
> - - B macroblocks/frames
> - - rate control
> - - anything else you might think of
> 
> To test it, here is a sample command line
> ./ffmpeg -i in.avi -vcodec cavs -strict -2 -cqp 30 -refs 2 -psnr out.avi
> 
> - -strict -2 is required for the encoder's experimental nature, I have
>  not thought much about its standard conformance, just that it decodes
>  with my decoder.
> - -cqp n with n in the range 0 to 63 is required as only fixed quantizer
>  encoding is supported
> - -refs 2 is optional, one reference frame would be the default
> - -psnr is optional
> 
> Michael, regarding your question on cvslog (sorry for crossposting,
> I wasn't subscribed to cvslog at the time):
> 
> >> Author: stefang
> >> Date: Sat Jul  7 09:14:58 2007
> >> New Revision: 9518
> >>
> >> Log:
> >> move dequantization into it's own inline function
> >
> >why inline? same question for the other inline functions
> >is there some speed gain from duplicating them in the object files
> >between encoder and decoder?
> 
> To be honest I did not think much about object size, it just seemed
> to be a convenient way to share functions this way instead of having
> to create ff_cavs_foobar names and without creating function call
> overhead that was not there before.  If you think object size would be a
> problem I can of course move some functions back from cavs.h to cavs.c.

yes please do unless theres a real speed loss from doing so


[...]
> +/**
> + * eliminate residual blocks that only have insignificant coefficients,
> + * inspired from x264 and JVT-B118
> + */
> +static inline int decimate_block(uint8_t *run, DCTELEM *level, int count) {
> +    static const uint8_t run_score[30] = {
> +        0,3,3,3,3,2,2,2,2,2,2,2,2,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 };
> +    int i;
> +    int score = 0;
> +
> +    if(count>4)
> +        return 9;
> +    for(i=0;i<count;i++) {
> +        int abslevel = FFABS(level[i]);
> +        if(abslevel > 1)
> +            return 9;
> +        score += run_score[FFMIN(run[i],29)];
> +    }
> +    return score;
> +}

how much psnr/bitrate is gained by this? if none then please drop it

[...]

> +    av_reduce(&frame_rate.den, &frame_rate.num,
> +              s->avctx->time_base.num, s->avctx->time_base.den, 60000);

if the exact one isnt support then the code should failm its the user
apps job to choose a supported one


> +    for(i=0;i<15;i++)
> +        if((ff_frame_rate_tab[i].den == frame_rate.den) &&
> +           (ff_frame_rate_tab[i].num == frame_rate.num))
> +            frame_rate_code = i;
> +    if(frame_rate_code < 0) {
> +        av_log(h->s.avctx, AV_LOG_ERROR, "unsupported framerate %d/%d\n",
> +               frame_rate.num, frame_rate.den);
> +        return -1;
> +    }


[...]
> +        put_bits(&s->pb,16,0);
> +        put_bits(&s->pb,16,CAVS_START_CODE);

add a put_bits_long() to bitstrea.c, document the issue with 32bits and
fix vorbis_enc.c :)


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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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/20070721/98e2fad6/attachment.pgp>