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

[Nick Kurshev]

Hello, Arpi!

On Sun, 17 Mar 2002 12:47:16 +0100 you wrote:

> Hi,
> 
> > I can run gcc simultaneously with mplayerxp and have realtime playback).
> > PLEASE THINK IT AGAIN - IMHO now it's time to change of vision about decodin
> > g.
> > My core works fine for me and it's enough stable already now.
> > I say - single threading decoding is bottleneck and mplayer SHOULD have new 
> > core!
> 
> We disagree here.
> Let's make MPlayerXP, and show people that your idea works and is better
> than mine. Do the same as egcs guys did with gcc...
I don't want ideology wars :)

> I'm still against threads in mplayer cvs - it's far from mplayer philosophy.
> There are threaded players, xien and avifile. They really differs only in
> threading and gui from mplayer, teh codecs are the same. Aviflie has that 10
> buffer decoding ahed you like so much. And ask users, why do they sue
> mplayer? Because it is faster, and much more stable.
Mplayer is faster because it uses the patches which were made by me and Michael
during the 2001. (Do you remember - fastmemcpy, MMX optimization and many other
commits?).
What about xine - I still can't drop the file on it - it simply crashes :(
What about aviplay - it requires qt! I have qt but another version and it don't want
to be compiled for me.
What about mplayer - I compile it even without X11 headers (simply with fbdev and vesa
outputs).
I don't need to ask users why they use mplayer - I'm mplayer's users!!!
I choosed it simply because it could play for me everything!
(Simply because it works against of xmps, aviplay and other).
> 
> no, thanks, no threads here.
> 
As you like say: Michael was AS USUALLY RIGHT!!!
Please remeber that!
> > Only thing which I don't like is their CVS.
> 
> of course you can use mplayerhq cvs, just use another module name than
> 'main'. let's import as mplayerxp:
> cd mplayerxp
> cvs -d:...:/cvsroot/mplayer import mplayerxp vendor start
> 
If I'll use that - could I be sure that you will not reverse and unroll any changes there
now and in the future if you will want to participate with this branch?

> I'm not against your project - i like it. But I don't accept threads in
> 'old' mplayer.
But what should be a scratch in this case?
> 
> > >Will you be incorporating any of the native MPlayer codecs?
> > I'll save every codec from current mplayer but in form of shared object.
> another thing we don't like - the 'plugin everything even libprintf.so'
> viewpoint...
But modularity improves stability, imho!

> > >Anyway if Nick wants to make something very different (dropping away a-v
> > >code, demuxers, codecs and others etc) then it shouldn't be called MPlayer*
> > >at all. It may have positive marketing value now, but it will change to
> > >negative in the future...
> > MplayerXP is not marketing trick. And I don't want drop away these parts.
> > If someone would look attentively at my patch then he could find out
> > that it doesn't touch a-v sync code (simply slightly modified it).
> it's your first patch on this. much more will come untyil yo uget it working
> stable, and the whoel core will be messed up again. i spent last night
> cleaning it up... and not talking about your plans with shared objects...
> 
Shared objects affects libmpcodec abd configure only !!!

> > If someone found out that version X.YY is stable for his needs then why he
> > should upgrade player upto A.BB if he wants upgrade codec only?
> 
> if soemone wants to play movies, why should he download 10+ various libs and
> install them and hope their version match?
Did you hear something about full-package and player-only package,
full-install and install,...?
When everyone compiles the Linux-kernel he types always two command:
make all modules
make install modules_install.
The modules can provide writting commercail plugins for mplayer!
They improve stability of whole project since it's splitted on
independed parts and allows for user update only needed parts of project!
> 
> prs vs contas
> both has good and bad sides.
> we just disagree here.
> 
> > Best regards! Nick
> 
> you should change nickname to libNick.so :)
> 
:)))
> > P.S.: Arpi, please think it again - we can build ULTRA PLAYER if you will ag
> > ree
> > to accept my MT core.
> > (It could be something like Babylon tower :)
> but i don't agree (yet).
> 
> evolution is simple.
> make mplayerxp. if it will be really better, both users and other developers
> will move to mplayerxp and probably i'll also follow them.
> but currently we don't believe in threaded player.
To belive in something - you should test it first.
But it seems that nobody really used mplayerxp.
(I suspect - FUD!?).
> i said - just see avifile or xine. they are threaded.
> one of key ideas of mplayer is dropping threads. don't change this.
> 
And without any reasons! Threads are good things! They provide better CPU
utilization! We can decode in non realtime mode - simply when cpu is free.
but realtime process - page flipping doesn't require a lot of cpu resources.
> 
> 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/3dc00236/attachment.pgp>