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

[Nick Kurshev]

Hello, GАbor!

On Sun, 17 Mar 2002 17:20:37 +0100 you wrote:

> On Sun, Mar 17, 2002 at 05:22:35PM +0100, Arpi wrote:
> > > I've speedup it on 200-300%! Why don't want such solid speedup and still int
> > > erested
> > > in invisible performance grow?
> > 
> > it's not more than your dreams or false suspects...
> > 
> > avg benchmark won't change, so it won't be faster a single bit!
> > it will be smoother on systems fast enough for avg decoding but not fast
> > enough for decoding very complex frames in time.
> 
> 
> BTW, I don't understand why threading makes things faster (of course on
> single CPU system, on SMP it's true of course). Maintaining multiple contexts
> by scheduler makes a bit SLOWER not faster. The fastest possible way to
> implement an algorithm on UP systems is using only ONE thread (of course
> it can be true that it makes it smoother a bit but also it will be slower).
Because decoding is realtime process.
With thread we can decode non realtimely (simply when processor is free).
If you look at diagram of cpu usage (which Arpi don't like).
You can find out that player sleeps between light-frame decoding but when
stream contain hard frame it can't decode it realtimely and drops next frame.
My idea is have them predecoded in pauses (when main process sleeps).
So there is a big speedup. - Monotonous cpu loading against of peaked loading.
> I'm not against threading (I likes them unlike Arpi ;-) but for tasks where
> it's simplier to implement something with threads and it's not so performance
> bottleneck like when I would have liked to implement GUI as a thread.
> 
> Just inmagine: an algorithm (whatever complex) is faster to run it in once
> not dividing into several concurent pieces of control flow (threads now),
> since the performance of an UP system will NOT be greater if you run
> several processes at once instead of one, of course. For losing speed you
> must also keep track some sync code between threads, also kernel should
> keep track more contextes (threads). So it's pointless.
disagree - simply try xp and watch yourself.
Btw, many don't understand this place - I've understand that and tried to implement
xp and I'm right.
> 
> > the only thing which can realize 200-300% speedup is method-2 direct
> 
> method-2? What is it?
> 
MMX optimization
> > rendering using single buffer in video ram, so for example divxvfw+dga.
> > Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with
> > no framedrops. Also windows media player can, using the same trick.
> > 
> > > I planed to use libvo and libao as static libraries ;)
> > hehe
> 
> - GАbor
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> 


Best regards! Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020317/b6885966/attachment.pgp>