[MPlayer-dev-eng] [PATCH] DXR3 Docs update

David Holm david at realityrift.com
Wed Sep 4 05:26:04 CEST 2002


On Tue, 2002-09-03 at 10:06, gabucino at mplayerhq.hu wrote:
> > > 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.

True, but when playing divx it's a whole different story. And that's
what I've used the card for all the time since I started writing the
mplayer device ;).

//David




More information about the MPlayer-dev-eng mailing list