[MPlayer-dev-eng] Re: Compile options

[Andrew Savchenko]

On 20 Sep 2006 21:46, Loren Merritt wrote:
> On Wed, 20 Sep 2006, Andrew Savchenko wrote:
> > I've made some tests for 3 movie types: H264 HD
> > (http://images.apple.com/movies/wb/the_fountain/the_fountain-tsr_h4
> >80p.mov), x264 and mpeg4; and for 4 sets of compile options: general
> > -O4 option, general -O4 and -fno-inline-functions for dsputil_mmx.o
> > only, general -O4 and -O2 for dsputil_mmx.o only, general -O2.
<skip>
> > So, I think all optimization parameters must remain unchanged (i.e.
> > -O4 by default with no exception). Do you agree with me?
>
> The obvious next thing to try is: add attribute(noinline) just to the
> h264 dsp functions.

Should I change only h264dsp_mmx.c or dsputil_h264_template_mmx.c as 
well? As I understood I also shouldn't change dsputil_mmx.c, because it 
is used not only for h264 processing. Am I right?

> > Results for MPEG4:
> > ==> General -O4 build:
> >
> > vc: (8.835 \pm 0.019)s
> > vo: (176.051 \pm 0.070)s
> > user: 1m(45.945 \pm 0.152)s
>
> What vo are you using, that manages to take 20 times as much cpu-time
> as the codec?

It is x11. I know, it is extremely slow, but there is a reason to use 
it. I need a high quality scaling. Both xv and vidix use hardware 
scaling and on my ancient nVidia Riva TNT 2 it is ugly: I can clearly 
see small squares when hardware upscaling small resolution video to a 
full screen.

Usually I'm using -sws 10, natural bicubic spline provides perfect 
qulity by the cost of CPU usage, but mine one is fast enough to allow 
this. Also I usually use -vf pp=ac,hue,screenshot (hue is needed to 
allow saturation adjustment), this also eats some CPU time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060921/1c1849ab/attachment.pgp>