[XviD-devel] some bframes ideas

[Christoph Lampert]

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. 

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

gruel