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

[Nick Kurshev]

Hello, Arpi!

On Sun, 17 Mar 2002 18:05:40 +0100 you wrote:

> Hi,
> 
> > 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
> 
> it doesn't drop frames unless you force it (-framedrop)
> and quoting your README from mplayerxp (just downloaded):
> 
> "This feature is useful only if average benchmark shows you less of 100%
> of cpu usage."
> 
> you said the truth here.
> 
> so even if you think (say) it's 5000% faster, it won't allow playback on
300% please didn't distort digits
> cpus where old mplayer (==avg benchmark) can't play without drop.
> 
> your patch does no more than smoother playback on fast enough (avg<100%) but
> not too fast (max>100%) systems.
> 
Yes! you are right!

> also note, taht your max bench code reporetd ~480% cpu usage whan playing
> I-frames only vcd-sized mpeg1 on p4-1.8ghz with mga_vid...
> 
That's ok for 0.0.0 version - I should clean that, sorry!
Any independed cpu meter shows that xp loads cpu much less of mplayer.
> don't tell me that i need p4-8ghz to be abel to playback vcd :)
> the whole decoding+libvo process was under 12% total...
> 
> > My idea is have them predecoded in pauses (when main process sleeps).
> > So there is a big speedup. - Monotonous cpu loading against of peaked loadin
> > g.
> ideas are nice things. but if you check mplayer code, there are no pauses
> when decoding frame tooks longer than 1/fps seconds, it will delay next
> frame a bit. it is called 'drifted delay' by kabi...
> yes, it isn't so smooth as your but works and not slower.
But what about 250% per B-frame and 50% per other frames?
It doesn't matter what causes these 250% - media reading delays or other
(concurent tasks)
> 
> > > method-2? What is it?
> > > 
> > MMX optimization
> heh?
> 
> rtfm docs/tech/dr-methods.txt
> 
DR is already works and there is nothing to do except writting of new drivers :(

> or my oldmail heer about DR (the file contains it a bit extended by
> implementation details used in libmpcodecs)
> 
> Nick:
> "* Cleaning program to be GPL'ed.
>   (You can redistribute it in binary form if you want)"
> - you should remove libmp1e, it is not used at all, just left in main cvs
o'k
> - you should at least ask us, at least my code is not GPL yet.
Arpi, it seems that you already several years violate GPL, isn't?
Did you remeber that noise which was around MS licence on etu
where MS called GPL'ed licence like a virus.
Please look at this licence 2.b:
    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.
This means that any program which contain GPL'ed code MUST BE whole GPL!
FYI: It's viral nature of GPL.
(Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy)!!!)
>   i'll allow you to distribute my code as gpl (i don't want to do so, but unless i do
>   it, you will say 'you just want to sabotage my xp project' so i do),
>   but you should at least ask me and the others...
You are right!!!
In this connection please everyone who has doubts about GPL code in mplayer tells me
and I'll remove this stuff as soon as possible.
> - g72x is not GPL
> - nor xa/*
> - mp3lib is LGPL
LGPL allows me redistribute the library as separate work without affecting
of licence of base program - it's cause why I want to move all codecs out from mplayerxp.
> - you can delete c++ version of directshow interface, not used at all
> - why do you 'mirror sf.net' (libavcodec)
because I still don't implement dynalinking model.
But I don't want make distributive without significand stuff like you.
> 
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
> _______________________________________________
> 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/550dfdb5/attachment.pgp>