[MPlayer-dev-eng] XviD support is done

Christoph Lampert chl at math.uni-bonn.de
Sat Jan 19 13:24:05 CET 2002


On Sat, 19 Jan 2002, Arpi wrote:

> Hi,
> 
> > Thanks. When I tried your two-pass example, XviD-file was was a little
> > smaller and had a little higher quantizer than the
> > DivX4-verison. Ratecontrol isn't perfect for either, so maybe one should 
> > compare fixed quant or same size clips. 
> 
> Maybe i'm wrong, but...
> AFAIK the bits of a coded frame consists from 3 components:
> - frame header, more or less constant length, and just a few bits
> - motion compensation vectors - could improve image quality
> - quantized dct components - smaller qscale is better  quality but makes more bits

> so, if you get smaller qsscales at the same bitrate, it means you have more
> bits left from other 2 tasks, so your MC is less successfull?
> (i can imagine it from faster compression)

No, it's the other way round: If we have smaller quantizers, but the same
bitrate, then we had _less_ bits to work on after MC, so MC is
"better". 
With smaller quantizers the error after MC is produced better, so picture
should be better, too. But that's only in theory... 

gruel


> compared divx4 and xvid, Gabu found that divx4 results more pixelized but
> sharper images, xvid make it a bit blured.

There might be a threshholding criterion set not optimal for low
quantizers. Try setting 

#define TOOSMALL_LIMIT 8

to a lower value (or just 0) in   core/src/encoder/mbtransquant.c:

> i should test it myself, i think..

Please do... doom9 is doing a comparisson just now and we'd love to get 
some good tips on image quality.

gruel

-- 
Christoph H. Lampert chl at math.uni-bonn.de | Diese Signature wurde maschi-     
Beringstr. 6, Raum 15 Tel. (0228) 73-4708 | nell erstellt und bedarf
Sprechstunden Di/Do 10-11 und spontan     | keiner Unterschrift. AZ 27B-6 




More information about the MPlayer-dev-eng mailing list