[MPlayer-users] Excessive * audio codec cpu usage

Brian J. Murrell dab65f6f3b6d3c4e7b3c1a7ae26a9c31 at interlinx.bc.ca
Wed Feb 13 11:21:02 CET 2002


On Wed, Feb 13, 2002 at 11:00:06AM +0100, Arpi wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi,

Hi,

> it includes some I/O time not only audio decoding...

Ahhh.  I wondered, but still...

> maybe your hdd too slow or dunno

But it can't be a factor of hdd speed because I have the same amount
of I/O going on in both samples.  With both samples, a file is being
written (capture and encode to mpeg1) and one is being read.  The only
difference between:

A:  17.8 V:  17.8 A-V:  0.020 ct:  0.018  528/528  58%  0% 28.0% 20 0 0%

and
A:  14.7 V:  14.8 A-V: -0.080 ct:  0.004  436/436  65%  0%  2.4% 0 0 0%

is that the first one is reading the stream being written, the second
one is reading a different stream while the other one continue to
write.

> try with -cache

That seems to help.  Playing a stream while writing it with -cache
1024:

A:  26.5 V:  26.5 A-V:  0.001 ct:  0.007  789/789  66%  0%  1.6% 0 0 39%

and playing a stream other the the one writing with -cache 1024:

A:  15.3 V:  15.3 A-V:  0.001 ct:  0.003  453/453  63%  0%  1.7% 0 0 41%


and playing a the same other stream while the one is writing without -cache 1024:

A:   6.8 V:   6.7 A-V:  0.024 ct: -0.002  198/198  62%  0%  1.8% 0 0 0%

So there is a few %CPU used to cache from slower media.  I also now
know what that last %ge value on the status line is that was always 0%
before.  :-)

b.

-- 
Brian J. Murrell




More information about the MPlayer-users mailing list