TransQuant/MBCoding (was: Re: Re[2]: [XviD-devel] [BUG] BFrame encoder doesn't force intra for 1st frame)

Christoph Lampert xvid-devel@xvid.org
Thu, 8 Aug 2002 10:15:41 +0200 (CEST)


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

I just noticed that I overlooked some small detail: I need the quantized
values... okay, maybe this detail is not so small after all. :-(

So I need a hyperfast routine, where:
* given coefficients are quantized and dequantized
* the SAD between quant and dequant calculated
* the original coefficients _not_ overwritten, because they have to be
  reused for other quantizers, 
* it must be possible to call a routine with access to all 64
  coefficients of every block, or even for 6*64 coeff. of an MB. 
* after that, the dequant coeff can be thrown away. 

Sounds less "hyperfast"... but maybe faster than calling MBTransQuant all
the time.


* OR, if that is faster: The routine to be called is of course a
  "bitcounter", measuring how many bits are needed to encode this block. 
  As far as I know this is based on a lookup table using the quantizer
  values, and a run-level-method to encode 0s. 

So maybe it could work like with a combined method: 
* Quantized and dequantized is in registers
* If the quantized value is zero, increase a run-counter. If it's not
  zero, count bits needed to encode the counter's value and the lookup
  table of the nozero quantized value. 
* original coeff. are in memory and not touched, quantized values are not 
  saved, only their VLC-length. 

So it's a combinantion of QuantInter/Intra and MBCoding, completely 
working in registers. Might even be ASMerized without too much trouble. 
Sounds good to me.

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


Well challenged... now riddle me this: "There are three men in a boat
with four cigarettes but no matches. How do they manage to smoke?" 

gruel

P.S. Yes, it's for adapative quantization. I can't stand "psychovisual"
heuristics anymore. My area is mathematics, so that's what's going to
happen on my side. 

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