[FFmpeg-devel] [PATCH] Chinese AVS encoder

[Stefan Gehrer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Michael Niedermayer wrote:
>> 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
> 

done

> 
> [...]
>> +/**
>> + * 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

I tested on the popular foreman (300 CIF frames). When encoding at
around 800kbps, roughly 0.1dB are gained by this. When encoding at
around 200kbps, this increases to a gain of around 0.15dB.
So I would like to keep 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
> 

removed


> 
>> +    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 :)

I looked a bit into this and I think a better way would be to fix
put_bits() to support up to 32 bits instead of up to 31 bits.
I am not so sure, but after a bit of checking in vorbis_enc.c it
seems there is never any writing with more than 32 bits even
though the local put_bits() function takes a 64bit argument.

Attached a new encoder patch and a proposed fix for put_bits().

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGpuSZYpYOlpT3vNMRAtZHAJwPWbgFJii6LsNPccX00FwvcdgIRwCguewG
GaR3Ox/qNiru79+7Jrq58sc=
=NtuI
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cavsenc2.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070725/eb034f11/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bitstream.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070725/eb034f11/attachment.asc>