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

Michael Militzer xvid-devel@xvid.org
Thu, 8 Aug 2002 01:26:18 +0200


Hi,

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

yes, something like that might be a bad idea...

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

I had a talk about something similar with Skal earlier already. He suggested
that it might be possible to do the dequantization quicker within the quant
function exploiting some mathematical tricks. Not saving the result isn't
too hard, we could just do all calculations using registers. -> voilá, your
hyperfast routine would be ready...

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

I like secrets ;-) Let me guess: has it something to do with adaptive
quantisation? some iterative approach?

bye
Michael