[Mplayer-advusers] Bug? Anomalous CPU usage when playing HDTV clips.
D Richard Felker III
dalias at aerifal.cx
Sun Apr 11 23:34:27 CEST 2004
On Fri, Apr 09, 2004 at 05:37:46PM -0700, John Stebbins wrote:
> Some additional info for anyone following this thread.
> I got tired of groping in the dark on this, so I horked the
> X sources, added some uSec timing measurements and profiled
> whats going on for one of the drivers. I did this on my desktop
> machine which is a P4 2.6Ghz with intel i830 integrated graphics.
> The color conversion and scaling is indeed being done completely
> in hardware as I thought it should be. The problem turns out
> to be in a busy wait loop in the driver. It appears to be waiting
> for a vsync (as someone suggested earlier). What I see is that
> sometimes, the timing between mplayer & the X driver are just right
> so the busy wait finishes within usecs. Then other times the timing
> will get completely wrong and the busy wait will spin for as long
> as 14 msec. This is fairly modal behavior as well. When the timing
> gets short it tends to stay short for a while, and when it gets long
> it tends to stay long. The propensity for the code to get into the
> long wait mode seems to increase when mplayer is "working harder".
> So high resolutions or high frame rates exaggerates the problem.
> This busy wait is disastrous for 720p HD because this format runs
> at 60fps which is 16 ms per frame. When X chews up 14 ms per frame,
> that leaves just 2 ms for decoding. Ouch!
> I don't know yet if the radeon driver has exactly the same problem.
> I'll be diving into that one next.
> I'm not sure what to do about the busy wait. I don't see an obvious
> way to synchronize closely to vsync without waiting. Any ideas anyone?
Proper hardware should never require a busy loop; it just has a
"switch buffers at next vblank" command you send to the card. Are you
sure you're using the real backend scaler and not a stupid
blitter-based xv port?
More information about the MPlayer-advusers