[XviD-devel] VHQ

[Christoph Lampert]

On Thu, 13 Feb 2003, Radek Czyz wrote:

> Thanks for the results, Christoph.
> 
> First of all, I'm happy it works. The tests you've conducted have the
> same results as mine.
> 
> There are 3 things on my VHQ-related todo list now:
> 
>  - do something about the speed. in particular, when we compute
>    cbp, we can remember it (put it in MACROBLOCK struct <-- this doesn't
>    sound so good). In motion compensation we could use
>    transfer8x8_copy instead if transfer_8to16sub for blocks which
>    will not be coded. We would also skip fdct + quantization for these
>    blocks.

My first idea would be to not always use _BITS for mode decision but only
in "difficult cases". For this we should first a huge data file, maybe of
the data we could use for mode decision:  
1) SAD after ME 
2) variance of current block 

Maybe we could add 
3) length of pmv , 
but I don't know if this helps.

Those are the "training samples". Then we need "teaching data" which won't
be available to the final algorithm. 
4) bits for INTRA
5) bits for INTER

And we should be able to find regions of classification: 
A) Surely to be INTERed (e.g. if SAD is below some threshhold)
B) Surely to be INTRAed (e.g. if variance is above some threshhold?)
C) doubtfull (blocks with this 1)-3) are not clearly INTER or INTRA)

>From this we could implement a general rule and call _BITS mode decision
only if we detect a C) case. I doubt that this is going to be more than
5%. 


Radek, since you know best what is calculated when, could you add a
#ifdef or some  dprintf which  simply print 1)-5) (or at least 1,2,4,5) to 
stderr or a file when running in _BITS mode? Doesn't have to be in CVS,
but just as a quick hack for developers/testers? 


>  - experiment more and discover if we could do something about this
>    PSNR drop. Perhaps we should skip _BITS refinement/search (leave only
>    decision) for macroblocks where _any_ luma dct block is zero? or two?
>    or three? just an idea.

When I have time, I'll try my "minimize TEXTURE bits" idea.

> The problem I would _really_ like to fix is this B-frames flickering I
> hate so much. Stupid bug, it's even difficult to prove it exists. But
> it does exist.

Can it be reproduced on "artificial" images? Are you sure that it's really
a bug and not due to some quantization rounding or something?

gruel