[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