[Mplayer-users] Clicking/pausing/generally bad sound

Emma Tonkin etonkin at tirin.openworld.co.uk
Wed Apr 25 17:25:48 CEST 2001


> On Mittwoch, 25. April 2001 03:02 you wrote:
> > Oh, and if I use gl, that second percentage becomes 70% or so. With x11
> > it's about 29,30% as with fbdev... but the first percentage is immense
> > with x11, like 100% or something... whereas it's small (30%) with gl.
> >
>
> No wonder sound skips, the resolution of the DivX is immense, no proper divx

Yup, true; bad example. However, it happens with the vast majority of divx
that I've ever tried, which encompasses a broad range of other
sizes/resolutions/etc from 640x300 or so, to 320*200 or so, and whilst I
discovered late last night that I get reasonable playback on
TV-screen-resolution @24fps (9%, though according to top it's still using
50% of cpu)...

Okay, so I try again with a 720 x 480 image...

To clarify: mplayer renders video perfectly as far as I can see, say with
this Divx I'm watching now, 'top' says it's on 52% of cpu usage using sdl,
the graphics are fine, it's a 720x480 video... and the sound's going
tick-tick-tick... and if I had the soundtrack as a separate mp3 I could be
playing it concurrently and getting perfect performance... indeed, I am
running 'mpg123 AlicesRestaurant.mp3' right now... Which probably proves
nothing... I have no idea how mp3 decoding from avis works, if it's
comparable.

With any of these divx's, apart from the very largest one, which as you
correctly mentioned uses stupid amounts of CPU, I get perfect vision,
buggered up sound to some extent, and generally ten times enough spare cpu
to be able to mpg123 Anything.mp3 at the same time and get flawless mp3
playback. Granted that with mpg123, X and mplayer running together there
isn't much spare cpu left for, say, compiling kernels... ;-)

> are made at full DVD resolution cause they simply eat too much decoding
> power, even 640x480 would be too slow, that's one reason black bars above and
> below the movie are cutted so you get 640x272 or whatever (besides it
> improves image quality). As you can see you system is loaded at about 95% so
> I don't wonder sound skips. Usual divx on my PC (PIII 930) play at about
> 10-20% load for decoding, and about 30-60% with PostProcessing (-pp) set to
> 4. Sound needs additional 1.5-3% depending on quality and format and 2% are
> spend for libvo driver when using yuv acceleration and about 6% for rgb/bgr
> modes (sdl driver and xv/x11).

...so since /this/ divx is taking 50% of cpu according to top, there
should be enough left for that additional 1.5 to 3% ;-)

> Btw. I would suggest using at least 24bpp for
> best image quality or best thing is to use a video out that handles yuv
> format, if you don't have xv acceleration try sdl out, it displays yuv to
> x11, xv or dga (aalib in upcoming release), you have to export
> SDL_VIDEODRIVER=dga to use dga, if you got support for that on your system.
> (in sdl driver yuv is about twice as fast as rgb/bgr tested with unreleased
> sdl out with rgb support (yea, in release, too).

You're right about sdl, it appears to give a good image... still *#&@%!
sound though.

export SDL_VIDEODRIVER=dga
mplayer -vo dga  /mnt/lose/AVI/foo.avi

gives me:

vo_dga: Supporting mode: depth=16, bpp=16, r=00f800, g=0007e0, b=00001f
(-bpp 16)
Loading DLL: /usr/lib/win32/divx_c32.ax  OK
DivX setting result = 0
VO: [dga] 352x288 => 352x288  BGR16
Xlib:  extension "XFree86-DGA" missing on display ":0.0".
vo_dga: DGA 2.0 available :-) Can switch resolution AND depth!
vo_dga: Selected video mode 100000 x 100000 @ 100000 Hz @ depth 16, bitspp
16, video 352 x 288.
Segmentation fault

There is a module Xfree86-dga which is usually excluded when I load X, I
don't know what it is (but it buggers up my system if it isn't excluded).
I tried including it and got just the same error followed by the same
segfault, which I expect means that I've got it all wrong somewhere.

> Btw. you can benchmark mplayer performance with perl -e 'system "mplayer -fps
> 10000 -nosound some.avi" and printf "bench took %i sec\n", time - $^T'
>
umm...
I guess with -vo something, because without any -vo option mplayer spits
it out complaining Sorry, Xv not supported by this X11 version/driver


Em


_______________________________________________
Mplayer-users mailing list
Mplayer-users at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-users



More information about the MPlayer-users mailing list