[MPlayer-dev-eng] [PATCH] DXR3 Docs update
gabucino at mplayerhq.hu
gabucino at mplayerhq.hu
Tue Sep 3 10:06:37 CEST 2002
> > Because if it's enabled (default), MPlayer
> > - hangs on the 2. second of an MPEG1 file
> It should not do this...
It did some time ago but you are right, now it works "right" (100%).
> > - plays DVDs with 100% CPU (!) usage
> Yes, when it prebuffers it tries to fill the dxr3's video buffer all the
> time (it does not copy one frame/"played frame"). The DXR3 has a rather
> large video buffer, so on most systems it will encode video frames
> constantly, therefore using 100% cpu. The good thing is that this makes
> the playback much less sensitive to other apps spiking the cpu since it
> will have lots of frames in the buffer to play before it starts lagging
> behind. If you run with noprebuf and the cpu spikes it will most likely
> not have time to encode the entire frame before it hits the frames
> timestamp, therefore causing framedropping.
Eh. And the CPU burns while the user thinks it's at 0% ...
Feel free to correct me, but IMHO:
- let's assume MPEG2 playing takes approx. 5% CPU (it seems to be much less)
- in this case, we need 20 (!) other processes that each require 100% CPU (!),
to make DXR3 playback sloppy!
- this case is highly unlikely on a desktop computer...
Because I couldn't ever make MPEG2 playing lag..
It's nice to _have_ this feature, but IMHO it's not so nice to have it
enabled by default.
--
Gabucino
/ Worshipping Niedermayer 4ever /
"Do you always look at it encoded?" (C) D. R. F.
"minden lehet. ez nem." (c) A'rpi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020903/d47bb8dd/attachment.pgp>
More information about the MPlayer-dev-eng
mailing list