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

[Arpi]

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'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.

no, thanks, no threads here.

> 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

I'm not against your project - i like it. But I don't accept threads in
'old' mplayer.

> >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...

> >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...

> 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?

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.
i said - just see avifile or xine. they are threaded.
one of key ideas of mplayer is dropping threads. don't change this.


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu