[MPlayer-dev-eng] XviD support is done

[Christoph Lampert]

On Fri, 18 Jan 2002, Arpi wrote:

> Hi,
> 
> > > > the resulting file was 120mb long. for 1 minute...
> > 
> > Fixed... typo in the opendivx-compatibility stuff
> 
> thx
> 
> > > single pass encoding works. so maybe xvid reporst bad numbers at vbr status
> > > stuff...
> > > anyway, quality is still worse than divx4 with the same options :(
> > 
> > Is it? I never had the impression. What have you been encoding? 
> > We had problems lately with dark material at higher quantizers. 
> > Normaly we get smaller quantizers at same bitrate than DivX4.
> 
> Ok, i'll do more testing (it was just an impression that it's worse, i
> didn't actually compared to divx4, but i coded the same content with divx4
> earlier and it had no such ugly artifacts as with xvid)
> I'll upload samples.

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. 

> Btw, what about optimization I can't see any opt flags in Makefile or
> Makefile.linux. There are a few things commented in .linux makefile, but are
> they safe to enable? as most of teh code is in plain C, they should help...
> Is it safe to enable max stuff (omit fp, -O4, -mcpu=i686 etc) or are there
> still problems with them?

Oh, right, I forgot to tell. I did not encounter any problem with
optmizition. Things were just disabled because Michael who wrote the
Makefile doesn't use Linux himself. I have a different Makefile at home... 
It also compiles nicely with Intel icc, giving a few % speed increse the
last time I checked. 

What's your result about best Flags? We could include them in Makefile... 

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