-----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-----