[XviD-devel] some bframes ideas

[suxen_drol]

On Fri, 21 Mar 2003 11:45:28 +0100 (CET) Christoph Lampert <chl at math.uni-bonn.de> wrote:

> On Fri, 21 Mar 2003, Radek Czyz wrote:
> 
> > Hi,
> > 
> > I was thinking on how to make bframes better - in terms of quality,
> > decision, dark blocks etc. I performed a few tests, too.
> > 
> > My main idea is to decrease bframe's size in a different way than
> > increasing quantizer. I already tested coefficients thresholding, as
> > it used to be done in pframes. As you might remember, TOOSMALL_LIMIT
> > of 3 gave the best PSNR, but was blurry.
> > I tried it in bframes and it seems to give very good results - for
> > example, when bframes have the same quantizer as pframes, the filesize
> > is smaller (5 - 10%) while there is completely no visible artifacts.
> 
> Hm, not a bad idea. 
>  
> > A different idea - which I haven't tried yet - is to substract a
> > fraction of a quantization error form coefficients (up to half of
> > maximum error). @ MfA: thanks for this, sounds very reasonble.
> 
> Could you test this? I'm not so sure about this one... 
> 
> > A simple question is: do you know other, simple and fast ways to
> > decrease bits needed? Trellis quantization sounds great, but seems
> > slow... and I would prefer ways which could be integrated into BITS
> > stuff. There is no BITS for bframes but who knows, maybe there will be
> 
> Trellis quantization _is_ great  ;-)  and it _is_ slow ;-)
> BITS stuff for bframes would be great, btw., because there are much more
> possible encoding mode here. 

iam sure this has been discussed before, and is not specific to bframes.
why not sum up the coefficents values lost by a range of quantizers, and
select one which results in the least error?

> > > Ah and another question - would you like me to commit my newest code?
> > It includes a series of cleanups and doesn't produce dark blocks, but
> > is not tested too well (as opposed to current code, which is tested
> > and proven to be ugly...)
> 
> If I remember correctly, Pete asked to not commit too many big changes in
> structure at the moment, because merge with API-4 will become painful.
> I guess encoder.c is a good candidate for not changing too much if not
> necessary.

yes commit changes. however, please refrain from changing xvid.h and
encoder.c (unless absolutely neccessary). the cvs head is meant for
testing, bug-fixing and cleanups.

dev-api-4 should be ready for public testing soon.

-- pete; life is like a box of ammo