[XviD-devel] CheckCandidate

[Christoph Lampert]

Hi,

nobody seems responsible, but I was just asking because am no friend of
methods which are implemented only because they seem to work in practice. 
Often, one just thinks they do but in fact they don't. 

My tests showed that current INTER/INTER4V method choses many more
INTER4V blocks than the previous pure lagrangian. This is good at low 
quantizers of 2 to 4, there the current method often reaches an error of 
2-3% and sometimes less (I mean bitrate is only 2% larger than with
optimal decision. In fact, 20-30% percent of block are classified wrong,
but for the vast majority of them the effect is very small). An error of
2% is very good, btw. 

But for medium quantizers, the method is much worse, usually the error
peaks at a quantizer 8 to 12 with a bitrate often more than 10% higher
than necessary! That's because still INTER4V is choosen too often... 

The bitrate error then drops again until it's somewhat stable below 5% 
for very high quants (almost all blocks are INTER then, but still more 
INTER4V than optimal). 

You can see this very well from the plot I attached: Possible saves in
bitrate versus quantizer for several (rather static) QCIF sequences. 
Especially the "miss america" sequence is _horrible_ with more than 20%
too high bitrate, just due to mode decision... 


Without the   sad += ...  line there are much fewer INTER4V blocks,
and the error rate of about constant 4-5% for most quantizers. 
Still, this cannot simply be compared, since of course ME uses
different tracks and other blocks are encoded ... 

Is there any voluteer around to check what's wrong with medium quants at
the moment? I guess from the practical point it would be better to have
high errors at very high quantizers, and as good as possible decision in
the area of quant 3 to 8 where most of the encoding takes place. 
 
gruel 



On Mon, 17 Feb 2003, Christoph Lampert wrote:
> in CheckCandidate16/16no4v/8 the current SAD is _multiplicated_ with
> the number of motion bits in the way 
> 
> sad += (data->lambda16 * t * sad)>>10; 
> 
> Where does this come from? Syskin, was that you? I don't remember it from
> my earlier versions, in particular since it leaves the usual lagrangian
> method. Is there any special reason why it was chosen in this way?  
> 
> gruel
> 
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saved-bitrate.png
Type: image/png
Size: 9019 bytes
Desc: 
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030218/1a61b6f3/saved-bitrate.png