Re[2]: [XviD-devel] [BUG] BFrame encoder doesn't force intra for 1st frame

Christoph Lampert xvid-devel@xvid.org
Wed, 7 Aug 2002 14:52:14 +0200 (CEST)


On Wed, 7 Aug 2002, Radoslaw Czyz wrote:

> > Especially since B-frame ME is (and will stay, even after
> > optimization) much slower than P-frame ME.
> 
> Which reminds me - why are we re-creating bframes while encoding? I
> mean everything after quantization - dequantization, idct,
> transfer_16to8add.

Because we were too clever to write every routine twice, so we re-used
pre-written stuff, which does too much work. Part of optimization
will be to remove all this unnecessary work.

> In other words: do we plan to use MBTransQuantInter function for
> bframes, or create MBTransQuantB (or something) ?

My suggestion would be to split MBTransQuantIntra/Inter into 4 or 5 parts:

MBTrans() /* the same for Intra/Inter blocks */
MBQuantInter() /* for B-frames, de-quant part can be skipped */ 
MBQuantIntra() 
MBTransBack() /* not called in B-frames */

maybe MBQuantInter() should rather be split into 
MBQuantInter()
MBDeQuantInter()  /* not called for B-frames */

That's no problem to do, I did for testing some new feature. 
Since the whole stuff is only called once or twice, in encoder.c,
things would not get messy, and it's easier to skip parts that are not
needed. 

Btw. there is another question from me in similar direction: 

Is it possible to write a hyperfast Quant+Dequant Routine where the
quantized values are not really saved? I just need to know the sum of
absolute differences between unquantized and quantized coefficients and it
has to be called several times for the same block with different
quantizers. 

The reason is still a secret. ;-) But unfortunately, until now it's a very
slow secret. 

gruel


-- 
Christoph H. Lampert chl@math,uni-bonn,de | Diese Signature wurde maschi-     
Beringstr. 6, Raum 14 Tel. (0228) 73-2948 | nell erstellt und bedarf
Sprechstunden: keine, aber meistens da    | keiner Unterschrift. AZ 27B-6