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

[Nick Kurshev]

Hello!

A few more words about this fork. Well, I really didn't want to do that.
I tried to improve current mplayer with this enough stable patch. But
what said Arpi? - /dev/null
Well - /dev/null is folder on my system :)
Even more - if Arpi will agree to apply my core and continue
development of mplayer in multithreaded way - I'm ready to froze
mlpayerxp and spend all my energy to make mplayer as player no.1
in the world. Currently we have situation when my 5KB patch causes
forking and as result we will have misfeatured mplayerxp with top performance
and fulfeatured mplayer with average performance.
I really didn't understand Arpi when he refused every my attempt to speedup
mplayer in multithread edway. This technology opens new horizons and nobody dreamed
to have such performance before.
Arpi, you should understand that nobody will use 80286 overclocked upto 1000Mhz
if there is P3. The single threaded core of mplayer is very limited and you will
catch every half of CPU clock to speedup decoding on 0.01%. My core allows me to
use dynalinked objects without visible performance degradation. (As I wrote -
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 decoding.
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!

>When i first saw that you are forking, the first thing that came into
>my mind was, why not using the alread existing and good working infrastructure
>that mplayer already has? Ie using mplayerhq.hu as main server 
>(maybe with anohter domain) ?
>The reason why i ask is, because i dont like sf. They are a single point
>of failure for a lot of projects and their service quality is due to
>their size not the best (but i apreciate what they are doing for the
>community).
I partly agree with you! But - sf.net is well known server which is part of OSF mainstream
and provides qualitative service for project's search and has many other useful things.
Only thing which I don't like is their CVS.

>If you dont like to be too near to old mplayer, it should be
>possible to organise a server here at the eth (swiss federal
>institute of technology) for you.
Distance doesn't matter for me. Simply sf.net is first what crossed my mind.
But I know nothing about SWIT - what is it? How it stable? Why this commercial
organization will provide hosting? and so on.

>You can't directly move a subdir in the SF CVS. You put in a work
>order and request that the admins do it for you. I've had experience with
>this, and they will eventually get to it (it may take a few days or
>weeks).
Thanks

>Good luck with your fork. And who knows? In the grand scheme of
>open source development, the main project may roll some of your better
>ideas into the main tree (like gcc & egcs). But did you HAVE to call in
>MPlayerXP? I can't imagine that I'm the only person who thinks that refers
>to an MPlayer port to a certain other operating system.
:)
MplayerXP = Mplayer + extra performance

>Will you be incorporating any of the native MPlayer codecs?
I'll save every codec from current mplayer but in form of shared object.

>Agree.
>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).
and important: by suppressing -xp key you get "old" core!
My changes are caused by the fact that I want to build pure player.
(Sorry! I don't want to mirror whole sf.net).
If there is project: libfame then why mplayer should have a copy
of this project? Let everyone uses libfame.so if he wants.
My idea is build player which doesn't require to be recompiled when
you change or add or remove codec.
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?

>What about XPMP ? would follow the long list of X[MPS]{3} strings :)
>(xmms,xmmp,xmps etc)
Nope! MplayerXP will have the same parts as in Mplayer which are directly
related with player (libdemuxer, a-v sync, ao-vo drivers). It will have
even native codecs but in form of shared objects.

>Right. For testing this I've just asked two of my friends (windows users)
>and both of them thought that it's simply something advanced version
>of Windows Media Player for Windows XP.
ROTFL :)))

Best regards! Nick

P.S.: Arpi, please think it again - we can build ULTRA PLAYER if you will agree
to accept my MT core.
(It could be something like Babylon tower :)

-------------- 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/247de596/attachment.pgp>