[MPlayer-dev-eng] MplayerXP vs Mplayer. Hall of truth.

[Daniel Egger]

Am Son, 2002-03-17 um 20.01 schrieb Nick Kurshev:

> Indeed, the place where the diagram shows more of 100% cpu usage
> doesn't exists, and mplayer drops next frame. (We really can't
> get more than 100% ;)
> But there are places with 0% of cpu usage - they are pauses
> between frame decoding. Main goal of this technology is fill
> them by frame decoding to have predecoded frames before PTS
> (presentation time-stamp).
> Indeed, the digits 30% and 150% are disputable but I had them.
> And it's doesn't matter what causes them: decoding of B-frames
> or delays during media reading - they really existed.
 
> Conslusion: I've tested movie playback with simultaneous working
> of gcc - mplayerxp doesn't drop frames and keeps realtime playback
> even on Cel1-266 but mplayer drops every 3rd frame.

I don't buy the argument. When I started using mplayer it was not fast
enough to display common DVDs on a G4. After a bit of hacking and
letting others hack mplayer became fast enough to play DVDs on this
machine and while I definitely can see deficiencies in buffering
I doubt the problem is big enough to actually make threads pay off.

Especially for your Celeron-266 the right idea would be to make sure
that there's enough data predecoded before running into a series of
frames where the CPU really needs power to decode them so the goal
should be to equalize the load over a bigger period of time (like maybe
50-100ms) to ensure that slower CPUs have enough time to compensate
instead of dropping frames. This is exactly what you're trying with your
threads approach and it seems to work for this particular case but it's
not improving the situation in general.

-- 
Servus,
       Daniel