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 :)