MplayerXP vs Mplayer. Hall of truth.
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 :)
On Sun, 17 Mar 2002 11:51:08 +0300 Nick Kurshev <nickols_k@mail.ru> wrote:
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.
Because they arent comercial. It's one of the biggest technical universities in europe. Have a look at www.ethz.ch. I'm at the moment i'm trying to get some webspace from them for a mplayer mirror (looks like as i got it).
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?
ACK Attila Kinali -- I am a moslem, i am a terrorist.
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
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 16.34 schrieb Nick Kurshev:
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.
Threads are useful if you can find blocking tasks which are parallelisable and thus prevent maximum cpu utilisation. Threads have several drawbacks, one of them are locking issues another one would be overhead for the thread management, another one would be harder debugability, another one would be the against-nature of threads versus processes on Unixsystems. IBM uses threads with Java extensivly for no good reason and all they get is piss-poor performance for which they're blaming linux. Please use threads only iff there's some real value in that. -- Servus, Daniel
Hello, Daniel! On 17 Mar 2002 17:46:52 +0100 you wrote:
Am Son, 2002-03-17 um 16.34 schrieb Nick Kurshev:
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.
Threads are useful if you can find blocking tasks which are parallelisable and thus prevent maximum cpu utilisation. Threads have I know such task - usleep() Thread can sleep too ;) several drawbacks, one of them are locking issues another one would be overhead for the thread management, another one would be harder debugability, another one would be the against-nature of threads versus processes on Unixsystems.
IBM uses threads with Java extensivly for no good reason and all they get is piss-poor performance for which they're blaming linux.
Please use threads only iff there's some real value in that.
I know that inaccurate thread usage causes slowdowning of system. But they the best solution in my case!
-- Servus, Daniel
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 17.53 schrieb Nick Kurshev:
Threads are useful if you can find blocking tasks which are parallelisable and thus prevent maximum cpu utilisation. Threads have I know such task - usleep() Thread can sleep too ;)
Sleeping is a not a bad thing cpu-wise and it certainly is not what I meant by "parallelisable".
I know that inaccurate thread usage causes slowdowning of system. But they the best solution in my case!
Yet you fail to explain why. I'm not against threads at all but they hit me often enough to warn others from thinking they could heal the world(tm). Threads are often used in wrong places which is a sign of not well-though design. If you're able to reasonable explain why you think threads are benefitial and the explanation is waterproof then you'll have my fullest support. -- Servus, Daniel
Hello, Daniel! On 17 Mar 2002 18:54:39 +0100 you wrote:
Am Son, 2002-03-17 um 17.53 schrieb Nick Kurshev:
Threads are useful if you can find blocking tasks which are parallelisable and thus prevent maximum cpu utilisation. Threads have I know such task - usleep() Thread can sleep too ;)
Sleeping is a not a bad thing cpu-wise and it certainly is not what I meant by "parallelisable".
I know that inaccurate thread usage causes slowdowning of system. But they the best solution in my case!
Yet you fail to explain why. I'm not against threads at all but they hit me often enough to warn others from thinking they could heal the world(tm).
Threads are often used in wrong places which is a sign of not well-though design. If you're able to reasonable explain why you think threads are benefitial and the explanation is waterproof then you'll have my fullest support.
Please dload mplayerxp and read README.
-- Servus, Daniel
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 19.10 schrieb Nick Kurshev:
Please dload mplayerxp and read README.
I don't have time for games. Either its a valuable document so you can post a relevant excerpt here or it is not and that'd be wasting my time anyway. So far your only argument for threads is that it's faster however you don't even explain how you measured that. If you don't care to explain I don't care to support you. -- Servus, Daniel
Hello, Daniel! On 17 Mar 2002 19:52:27 +0100 you wrote:
Am Son, 2002-03-17 um 19.10 schrieb Nick Kurshev:
Please dload mplayerxp and read README.
I don't have time for games. Either its a valuable document so you can post a relevant excerpt here or it is not and that'd be wasting my time anyway. O'k read that:
Please look at diagram of cpu decoding: ^ CPU loading /\ | | | |----------------------|--|------------------------- 100% | /\ | | | | | | | /---------This frame was dropped | /\ | | | || /\ | | | Pause | |Pause | ||| |Pause -----------------------------------------------------> t Indeed, the place where the diagram shows more of 100% cpu usage doesn't exists, and mplayer drops next frame. (We really can't get more than 100% ;) But there are places with 0% of cpu usage - they are pauses between frame decoding. Main goal of this technology is fill them by frame decoding to have predecoded frames before PTS (presentation time-stamp). Indeed, the digits 30% and 150% are disputable but I had them. And it's doesn't matter what causes them: decoding of B-frames or delays during media reading - they really existed. Conslusion: I've tested movie playback with simultaneous working of gcc - mplayerxp doesn't drop frames and keeps realtime playback even on Cel1-266 but mplayer drops every 3rd frame.
So far your only argument for threads is that it's faster however you don't even explain how you measured that. If you don't care to explain I don't care to support you.
It hardly to mesure - only by number of dropped frame (mplayerxp drops less frames against of mplayer on slow machines).
-- Servus, Daniel
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 20.01 schrieb Nick Kurshev:
Indeed, the place where the diagram shows more of 100% cpu usage doesn't exists, and mplayer drops next frame. (We really can't get more than 100% ;) But there are places with 0% of cpu usage - they are pauses between frame decoding. Main goal of this technology is fill them by frame decoding to have predecoded frames before PTS (presentation time-stamp). Indeed, the digits 30% and 150% are disputable but I had them. And it's doesn't matter what causes them: decoding of B-frames or delays during media reading - they really existed.
Conslusion: I've tested movie playback with simultaneous working of gcc - mplayerxp doesn't drop frames and keeps realtime playback even on Cel1-266 but mplayer drops every 3rd frame.
I don't buy the argument. When I started using mplayer it was not fast enough to display common DVDs on a G4. After a bit of hacking and letting others hack mplayer became fast enough to play DVDs on this machine and while I definitely can see deficiencies in buffering I doubt the problem is big enough to actually make threads pay off. Especially for your Celeron-266 the right idea would be to make sure that there's enough data predecoded before running into a series of frames where the CPU really needs power to decode them so the goal should be to equalize the load over a bigger period of time (like maybe 50-100ms) to ensure that slower CPUs have enough time to compensate instead of dropping frames. This is exactly what you're trying with your threads approach and it seems to work for this particular case but it's not improving the situation in general. -- Servus, Daniel
Daniel Egger wrote:
Especially for your Celeron-266 the right idea would be to make sure that there's enough data predecoded before running into a series of frames where the CPU really needs power to decode them so the goal should be to equalize the load over a bigger period of time (like maybe 50-100ms) to ensure that slower CPUs have enough time to compensate instead of dropping frames. This is exactly what you're trying with your threads approach and it seems to work for this particular case but it's not improving the situation in general.
What would improve the situation in general then?
Am Mon, 2002-03-18 um 01.22 schrieb daniel carter:
Especially for your Celeron-266 the right idea would be to make sure that there's enough data predecoded before running into a series of frames where the CPU really needs power to decode them so the goal should be to equalize the load over a bigger period of time (like maybe 50-100ms) to ensure that slower CPUs have enough time to compensate instead of dropping frames. This is exactly what you're trying with your threads approach and it seems to work for this particular case but it's not improving the situation in general.
What would improve the situation in general then?
As I tried to point out the optimal solution would be to decode frames in advance to flatten the cpu utilisation. This can be also implemented without threads but if my reasoning is flawed I wouldn't mind being corrected. -- Servus, Daniel
Daniel Egger wrote:
Am Mon, 2002-03-18 um 01.22 schrieb daniel carter:
Especially for your Celeron-266 the right idea would be to make sure that there's enough data predecoded before running into a series of frames where the CPU really needs power to decode them so the goal should be to equalize the load over a bigger period of time (like maybe 50-100ms) to ensure that slower CPUs have enough time to compensate instead of dropping frames. This is exactly what you're trying with your threads approach and it seems to work for this particular case but it's not improving the situation in general.
What would improve the situation in general then?
As I tried to point out the optimal solution would be to decode frames in advance to flatten the cpu utilisation.
A good idea indeed. Nick has thought of this and implemented it already. In fact this thread where you make the suggestion is in reply to discussion of the implementation.
On Tue, Mar 19, 2002 at 11:21:23AM +1200, daniel carter wrote:
Daniel Egger wrote:
Am Mon, 2002-03-18 um 01.22 schrieb daniel carter:
Especially for your Celeron-266 the right idea would be to make sure that there's enough data predecoded before running into a series of frames where the CPU really needs power to decode them so the goal should be to equalize the load over a bigger period of time (like maybe 50-100ms) to ensure that slower CPUs have enough time to compensate instead of dropping frames. This is exactly what you're trying with your threads approach and it seems to work for this particular case but it's not improving the situation in general.
What would improve the situation in general then?
As I tried to point out the optimal solution would be to decode frames in advance to flatten the cpu utilisation.
A good idea indeed. Nick has thought of this and implemented it already. In fact this thread where you make the suggestion is in reply to discussion of the implementation.
There's nothing wrong with Nick's idea as a starting point. Where he's wrong is in implying that threads are necessary or even desirable for doing this. The same thing can be done in a much cleaner fashion without threads, and that way you'd also avoid the cache coherency and context switching penalties of threads, so it'd be faster too. Unfortunately this way would also be more complicated to code, and since (as myself and others have pointed out many times before) the benefits of decoding ahead are quite limited, it doesn't seem worthwhile to implement. Rich
Daniel Egger wrote:
IBM uses threads with Java extensivly for no good reason and all they get is piss-poor performance for which they're blaming linux.
For no good reason? Thread == Thread is a good reason to me.
Am Son, 2002-03-17 um 09.51 schrieb Nick Kurshev:
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.
Please go on and elaborate why you think that multithreading will help. Considering that it might be clever to have a few decoded video and audio frames in spare there shouldn't be much advantage to be had to parallelise the jobs. I suspect that using mmap and madvise instead of open and read on inputfiles would lead to bigger improvements than minimizing outtimes I still fail to see. That having said it might be interesting to have threads to get mplayer demuxing several streams at once and mixing them together somehow, yet I fail to see what this might be useful for. :) Using pthreads still involves some debugging and profiling problems which are hardly solveable and thus should lead to such a step being well thought before doing it. -- Servus, Daniel
Hello, Daniel! On 17 Mar 2002 14:55:42 +0100 you wrote:
Am Son, 2002-03-17 um 09.51 schrieb Nick Kurshev:
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.
Please go on and elaborate why you think that multithreading will help. Because I saw it in practice :))) Considering that it might be clever to have a few decoded video and audio frames in spare there shouldn't be much advantage to be had to parallelise the jobs. I suspect that using mmap and madvise instead of open and read on inputfiles would lead to bigger improvements than minimizing outtimes I still fail to see. mmap will not help - it's not a bottleneck. And much more - probably you can't mmap inet's socket.
That having said it might be interesting to have threads to get mplayer demuxing several streams at once and mixing them together somehow, yet I fail to see what this might be useful for. :)
xp branch uses one demuxer!
Using pthreads still involves some debugging and profiling problems which are hardly solveable and thus should lead to such a step being well thought before doing it.
-xp is only key and you are free not use that.
-- Servus, Daniel
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 17.10 schrieb Nick Kurshev:
Please go on and elaborate why you think that multithreading will help. Because I saw it in practice :)))
That's not exactly a fundamental reasoning. If that's all you can tell then please also mention how you measured that.
mmap will not help - it's not a bottleneck.
If you have highbandwitdh streams then it definitely could be one.
And much more - probably you can't mmap inet's socket.
You don't have to. Please don't tell me that you'd communicate through inet sockets between the components of mplayer.
xp branch uses one demuxer!
Okay, now I fail to see where you're aiming. :) -- Servus, Daniel
Hi, Nick! I think you should only make patches that enables threading in mplayer and distribute them. And you should spend more time on 3DNow optimizing! MPlayer will support also shared libs of libvo,libao,.. drivers..in the "near" future. - alex
Nick! I think you should only make patches that enables threading in mplayer and distribute them. Most likely it should go to the Patches section on the Download page until
Alex Beregszaszi didn't RTFM : proper testing, users seeing it. Then we'd see. I think this is reasonable. -- Gabucino
Hello, Gabucino! On Sun, 17 Mar 2002 15:55:11 +0100 you wrote:
Nick! I think you should only make patches that enables threading in mplayer and distribute them. Most likely it should go to the Patches section on the Download page until
Alex Beregszaszi didn't RTFM : proper testing, users seeing it. Then we'd see. I think this is reasonable.
Nope! Arpi performs to much cosmetic changes in CVS to make this patch not applicable.
-- Gabucino
Best regards! Nick
Hi,
Nope! Arpi performs to much cosmetic changes in CVS to make this patch not a pplicable.
rotfl no, it does nothing with your patch it wa sjust too many bugreporst about nonworking uninitialization of libvo, and crashes caused by not exiting if some init fails. rtfml. i spent last night to cleanup too messy mplayer.c a bit, and remove unused stuff, and fix order of init/uninit sequence. anyway, don't your patch only affects dec_ahead.c or so? anyway 2: i thought you already forkes, so you aren't intereste din changed made in old brach, your patch si already applied in mpxp cvs... this is why i removed your very silly and useless max_benchmark code A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Arpi! On Sun, 17 Mar 2002 17:14:39 +0100 you wrote:
Hi,
Nope! Arpi performs to much cosmetic changes in CVS to make this patch not a pplicable.
rotfl no, it does nothing with your patch it wa sjust too many bugreporst about nonworking uninitialization of libvo, and crashes caused by not exiting if some init fails. rtfml. i spent last night to cleanup too messy mplayer.c a bit, and remove unused stuff, and fix order of init/uninit sequence.
anyway, don't your patch only affects dec_ahead.c or so? anyway 2: i thought you already forkes, so you aren't intereste din changed made in old brach, your patch si already applied in mpxp cvs... this is why i removed your very silly and useless max_benchmark code
It seems that you have messed something: max benchmark is useless for mplayerxp same as ave benchmark is useless for mplayer. So we should swap these stuffs :))) Joke!
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Hi,
Nick! I think you should only make patches that enables threading in mplay er and distribute them. Most likely it should go to the Patches section on the Download page until
Alex Beregszaszi didn't RTFM : proper testing, users seeing it. Then we'd see. I think this is reasonable.
No. I agree with nick, his plans go far, more than some patches. He wants to change the basic design of mplayer core (maybe full rewrite). I think keeping libmpdemux libvo etc as compatible as possible is more than enough. But if he plans to change codecs to dlopen'ed plugins, then it's really much more than a new core. I still vote for fork, and we'll see, maybe we'll drop old branch and switch to Nick's branch later. Let him show what he can do. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Alex! On Sun, 17 Mar 2002 15:43:54 +0100 you wrote:
Hi,
Nick! I think you should only make patches that enables threading in mplayer and distribute them. Is it joke? When I first time send my patch then only thing which was done by Arpi is removing #ifdef LIBVO2 (but from mplayer.c only). In this case I will make my patches every day and every hour :) Such patch was already suggested by me - it was #ifdef'ed code which didn't affect stability and even in such form it was refused by Arpi. It's unreal idea. And you should spend more time on 3DNow optimizing!
Do you want to speedup mplayer on 10-30%? I've speedup it on 200-300%! Why don't want such solid speedup and still interested in invisible performance grow?
MPlayer will support also shared libs of libvo,libao,.. drivers..in the "near" future.
I planed to use libvo and libao as static libraries ;)
- alex _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Hi,
And you should spend more time on 3DNow optimizing! agree!
Do you want to speedup mplayer on 10-30%? I've speedup it on 200-300%! Why don't want such solid speedup and still int erested in invisible performance grow?
it's not more than your dreams or false suspects... avg benchmark won't change, so it won't be faster a single bit! it will be smoother on systems fast enough for avg decoding but not fast enough for decoding very complex frames in time. the only thing which can realize 200-300% speedup is method-2 direct rendering using single buffer in video ram, so for example divxvfw+dga. Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with no framedrops. Also windows media player can, using the same trick.
I planed to use libvo and libao as static libraries ;) hehe
they have to be changed to dynamic to solve binary packaging, and anyway the vo drivers don't have cpu-sensitive code. the codecs actually has. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Arpi! On Sun, 17 Mar 2002 17:22:35 +0100 you wrote:
Hi,
And you should spend more time on 3DNow optimizing! agree!
Do you want to speedup mplayer on 10-30%? I've speedup it on 200-300%! Why don't want such solid speedup and still int erested in invisible performance grow?
it's not more than your dreams or false suspects...
Please be realist!!!
avg benchmark won't change, so it won't be faster a single bit! it will be smoother on systems fast enough for avg decoding but not fast enough for decoding very complex frames in time.
the only thing which can realize 200-300% speedup is method-2 direct rendering using single buffer in video ram, so for example divxvfw+dga. Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with no framedrops. Also windows media player can, using the same trick.
I already painted diagram within of mplayerxp package. I hope that there everything is clear.
I planed to use libvo and libao as static libraries ;) hehe
they have to be changed to dynamic to solve binary packaging, and anyway the vo drivers don't have cpu-sensitive code. the codecs actually has.
Do you mean: decode(...) vs (*decode)(...) ? In this case you can catch only half of cpu clock. But my idea doesn't require catching of such "speedup"
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Nick Kurshev didn't RTFM :
in invisible performance grow? it's not more than your dreams or false suspects... Please be realist!!! Heh ;) Today I was explaining Arpi a bug for 1 hours, he always said it is "missing feature" ;) Now he can reprod it at last :)
-- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama
On Sun, Mar 17, 2002 at 05:22:35PM +0100, Arpi wrote:
I've speedup it on 200-300%! Why don't want such solid speedup and still int erested in invisible performance grow?
it's not more than your dreams or false suspects...
avg benchmark won't change, so it won't be faster a single bit! it will be smoother on systems fast enough for avg decoding but not fast enough for decoding very complex frames in time.
BTW, I don't understand why threading makes things faster (of course on single CPU system, on SMP it's true of course). Maintaining multiple contexts by scheduler makes a bit SLOWER not faster. The fastest possible way to implement an algorithm on UP systems is using only ONE thread (of course it can be true that it makes it smoother a bit but also it will be slower). I'm not against threading (I likes them unlike Arpi ;-) but for tasks where it's simplier to implement something with threads and it's not so performance bottleneck like when I would have liked to implement GUI as a thread. Just inmagine: an algorithm (whatever complex) is faster to run it in once not dividing into several concurent pieces of control flow (threads now), since the performance of an UP system will NOT be greater if you run several processes at once instead of one, of course. For losing speed you must also keep track some sync code between threads, also kernel should keep track more contextes (threads). So it's pointless.
the only thing which can realize 200-300% speedup is method-2 direct
method-2? What is it?
rendering using single buffer in video ram, so for example divxvfw+dga. Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with no framedrops. Also windows media player can, using the same trick.
I planed to use libvo and libao as static libraries ;) hehe
- Gábor
Hello, GАbor! On Sun, 17 Mar 2002 17:20:37 +0100 you wrote:
On Sun, Mar 17, 2002 at 05:22:35PM +0100, Arpi wrote:
I've speedup it on 200-300%! Why don't want such solid speedup and still int erested in invisible performance grow?
it's not more than your dreams or false suspects...
avg benchmark won't change, so it won't be faster a single bit! it will be smoother on systems fast enough for avg decoding but not fast enough for decoding very complex frames in time.
BTW, I don't understand why threading makes things faster (of course on single CPU system, on SMP it's true of course). Maintaining multiple contexts by scheduler makes a bit SLOWER not faster. The fastest possible way to implement an algorithm on UP systems is using only ONE thread (of course it can be true that it makes it smoother a bit but also it will be slower). 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. My idea is have them predecoded in pauses (when main process sleeps). So there is a big speedup. - Monotonous cpu loading against of peaked loading. I'm not against threading (I likes them unlike Arpi ;-) but for tasks where it's simplier to implement something with threads and it's not so performance bottleneck like when I would have liked to implement GUI as a thread.
Just inmagine: an algorithm (whatever complex) is faster to run it in once not dividing into several concurent pieces of control flow (threads now), since the performance of an UP system will NOT be greater if you run several processes at once instead of one, of course. For losing speed you must also keep track some sync code between threads, also kernel should keep track more contextes (threads). So it's pointless. disagree - simply try xp and watch yourself. Btw, many don't understand this place - I've understand that and tried to implement xp and I'm right.
the only thing which can realize 200-300% speedup is method-2 direct
method-2? What is it?
MMX optimization
rendering using single buffer in video ram, so for example divxvfw+dga. Acki (vo_dga author) could play middle size divx on p1 200 mmx + dga with no framedrops. Also windows media player can, using the same trick.
I planed to use libvo and libao as static libraries ;) hehe
- GАbor _______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
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
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
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 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. 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... don't tell me that i need p4-8ghz to be abel to playback vcd :) the whole decoding+libvo process was under 12% total... frame a bit. it is called 'drifted delay' by kabi... yes, it isn't so smooth as your but works and not slower.
method-2? What is it?
MMX optimization heh?
rtfm docs/tech/dr-methods.txt 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 - you should at least ask us, at least my code is not GPL yet. 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... - g72x is not GPL - nor xa/* - mp3lib is LGPL - you can delete c++ version of directshow interface, not used at all - why do you 'mirror sf.net' (libavcodec) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
so even if you think (say) it's 5000% faster, it won't allow playback on 300% please didn't distort digits
Hi, these numbers doesn't matter here - they measure things but not performance
cpus where old mplayer (==avg benchmark) can't play without drop.
your patch does no more than smoother playback on fast enough (avg<100%) b ut not too fast (max>100%) systems.
Yes! you are right! sure ;)
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!
it was in mplayer cvs (near to 0.70 or even 1.0) for a month
Any independed cpu meter shows that xp loads cpu much less of mplayer.
they are all confused by threads and usleep test my '3pm' mp3 player. it is reported as using 0% cpu by top, ps etc...
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 lo adin 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) if yo uhave 250% b frames, the movie is unplayable... 92% of frames are P or B frames (you lie whan say B eats more than P - both ues MC, only I frames are fast) so it means you have ~200% avg bench...
rtfm docs/tech/dr-methods.txt
DR is already works and there is nothing to do except writting of new driver s :(
DR wiht single buffer really helps on slow systems where video bandwith is the bottleneck, so on p1 and slow celerons. m2dr+dga really achieves dixiv playback on tehse without framedrops! your decoding ahead won't work wiht single buffer so you lose the biggest advantage of direct rendering - updating avg 30% of framebuffer instead of memcpy the whole
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? no.
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: please look at mplayer license
This means that any program which contain GPL'ed code MUST BE whole GPL! mplayer is not a program! it is a collection of various sources, gpl and non-gpl ones this is why distributing it in compiled form is forbidden...
the good old trick used by ml3labe and some other projects to solve fuckin' gpl restrictions YOU will break gpl by allowing users to distribute it in compiled form :)
FYI: It's viral nature of GPL. (Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy)!!! yes
A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Arpi! On Sun, 17 Mar 2002 18:50:05 +0100 you wrote:
Hi,
[snip]
rtfm docs/tech/dr-methods.txt
DR is already works and there is nothing to do except writting of new driver s :(
DR wiht single buffer really helps on slow systems where video bandwith is the bottleneck, so on p1 and slow celerons. m2dr+dga really achieves dixiv playback on tehse without framedrops! your decoding ahead won't work wiht single buffer so you lose the biggest advantage of direct rendering - updating avg 30% of framebuffer instead of memcpy the whole
It works with temporary buffers in RAM (-vo xv) Anyway you can't implement something better there. And such solution can be as generic thing.
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? no.
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: please look at mplayer license
This means that any program which contain GPL'ed code MUST BE whole GPL! mplayer is not a program! it is a collection of various sources, gpl and non-gpl ones this is why distributing it in compiled form is forbidden...
You have very limited licence. Before I though that it caused by some limitation in tempoary stuff like encoder odivx and so on. But you forbit to have compiled collection of your sources!!! GPL never forbit compile a program. Every commercial program can be compiled with GPL'ed shared object. Every commercial product communicates with GPL'ed kernel. So it seems just as stupid limitation.
the good old trick used by ml3labe and some other projects to solve fuckin' gpl restrictions
The licence doesn't affect products. You can use GPL'ed gcc to compile commercial program. The same as you can links with GPL objects if your program doesn't required. its source. What about header - they don't violate licence (at least I can rewrite them from scratch).
YOU will break gpl by allowing users to distribute it in compiled form :) Licence of which part of COLLECTION forbits do that?
FYI: It's viral nature of GPL. (Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy)!!! yes
I guessed that mplayer is program but it seems that it was my mistake. It's even not a program, wow! Then what is it and why it does work after translating of this collection by gcc?
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Nick Kurshev didn't RTFM :
I guessed that mplayer is program but it seems that it was my mistake. It's even not a program, wow! Then what is it and why it does work after translating of this collection by gcc? Wow it does??? It usually doesn't :)
-- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama
Hi,
DR wiht single buffer really helps on slow systems where video bandwith is the bottleneck, so on p1 and slow celerons. m2dr+dga really achieves dixiv playback on tehse without framedrops! your decoding ahead won't work wiht single buffer so you lose the biggest advantage of direct rendering - updating avg 30% of framebuffer instead of memcpy the whole It works with temporary buffers in RAM (-vo xv)
no xv such slow systems (like p1 or old celerons) usually has no xv-capable cards but dga or vidix or xmga (1 buffers) could work there fine it was tested with dga, and it worked well on p1 - search archive, it was done a year ago (!) by Acki (similar DR hacks like yours - but never comited) again: on p1 mmx with no drops, not on celeron 266 with drops as yours
Anyway you can't implement something better there. ?
And such solution can be as generic thing. threads?
This means that any program which contain GPL'ed code MUST BE whole GPL! mplayer is not a program! it is a collection of various sources, gpl and non-gpl ones this is why distributing it in compiled form is forbidden... You have very limited licence. Before I though that it caused by some limitation in tempoary stuff like encoder odivx and so on. But you forbit to have compiled collection of your sources!!! GPL never forbit compile a program. Every commercial program can be compiled with GPL'ed shared object. LGPLed. not GPLed.
Every commercial product communicates with GPL'ed kernel. So it seems just as stupid limitation. there are no shared objects nor LGPL
ans we'll remove this stupid license as soon as we get rid of things keepeng us away from binary packages. but you'd better RTFMing
the good old trick used by ml3labe and some other projects to solve fuckin ' gpl restrictions
The licence doesn't affect products. You can use GPL'ed gcc to compile commercial program. The same as you can links with GPL objects if your program doesn't required. its source. What about header - they don't violate licence (at least I can rewrite them from scratch).
YOU will break gpl by allowing users to distribute it in compiled form :) Licence of which part of COLLECTION forbits do that?
dunno. many, including all code by me. i'll switch to gpl my code as soon as we get rid of other problems
FYI: It's viral nature of GPL. (Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy )!!! yes
I guessed that mplayer is program but it seems that it was my mistake. yes
It's even not a program, wow! yes
Then what is it and why it does work after translating of this collection by gcc? even dd if=/dev/urandom of=mplayer works sometimes... rare but possible!
A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Arpi! On Sun, 17 Mar 2002 19:37:47 +0100 you wrote:
Hi,
DR wiht single buffer really helps on slow systems where video bandwith is the bottleneck, so on p1 and slow celerons. m2dr+dga really achieves dixiv playback on tehse without framedrops! your decoding ahead won't work wiht single buffer so you lose the biggest advantage of direct rendering - updating avg 30% of framebuffer instead of memcpy the whole It works with temporary buffers in RAM (-vo xv)
no xv such slow systems (like p1 or old celerons) usually has no xv-capable cards ^^^^^^^ but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times. it was tested with dga, and it worked well on p1 - search archive, it was done a year ago (!) by Acki (similar DR hacks like yours - but never comited) again: on p1 mmx with no drops, not on celeron 266 with drops as yours
Anyway you can't implement something better there. ?
And such solution can be as generic thing. threads? For threads!
This means that any program which contain GPL'ed code MUST BE whole GPL! mplayer is not a program! it is a collection of various sources, gpl and non-gpl ones this is why distributing it in compiled form is forbidden... You have very limited licence. Before I though that it caused by some limitation in tempoary stuff like encoder odivx and so on. But you forbit to have compiled collection of your sources!!! GPL never forbit compile a program. Every commercial program can be compiled with GPL'ed shared object. LGPLed. not GPLed. It's disputable question
Every commercial product communicates with GPL'ed kernel. So it seems just as stupid limitation. there are no shared objects nor LGPL
ans we'll remove this stupid license as soon as we get rid of things keepeng us away from binary packages. but you'd better RTFMing
Anyway - I can redistribute your sources under GPL as you said. Second - you should make it as soon as possible simply because mplayer has many parts which are GPL'ed - GPL is applicable to PROGRAM which doesn't exist. (vidix is not a program) It something strange. Anyway you should call something by PROGRAM to which is applied GPL of parts!
the good old trick used by ml3labe and some other projects to solve fuckin ' gpl restrictions
The licence doesn't affect products. You can use GPL'ed gcc to compile commercial program. The same as you can links with GPL objects if your program doesn't required. its source. What about header - they don't violate licence (at least I can rewrite them from scratch).
YOU will break gpl by allowing users to distribute it in compiled form :) Licence of which part of COLLECTION forbits do that?
dunno. many, including all code by me. i'll switch to gpl my code as soon as we get rid of other problems
The biggest program is described above
FYI: It's viral nature of GPL. (Note: mplayer contains GPL'ed code - my code at least (vidix,fastmemcpy )!!! yes
I guessed that mplayer is program but it seems that it was my mistake. yes
It's even not a program, wow! yes
Then what is it and why it does work after translating of this collection by gcc? even dd if=/dev/urandom of=mplayer works sometimes... rare but possible!
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Nick Kurshev didn't RTFM :
such slow systems (like p1 or old celerons) usually has no xv-capable cards but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times. It's not only about card, it's about X driver too!
Every commercial program can be compiled with GPL'ed shared object. LGPLed. not GPLed. It's disputable question It's not disputable, Arpi is right. This is why LGPL was invented.
Anyway - I can redistribute your sources under GPL as you said. Nick, what do you want to achieve with this? What good does it get, bringing this GPL-nonGPL topic forth again - just some days/weeks before full-GPL release? In case you stay with separate mplayerxp project, you should keep our "license" until we make it GPL.
-- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama
Hello, Gabucino! On Sun, 17 Mar 2002 19:50:13 +0100 you wrote:
Nick Kurshev didn't RTFM :
such slow systems (like p1 or old celerons) usually has no xv-capable cards but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times. It's not only about card, it's about X driver too!
I fixed vo_xv upto 10 buffers so version of X11 doesn't matter - you can grow it upto infinity.
Every commercial program can be compiled with GPL'ed shared object. LGPLed. not GPLed. It's disputable question It's not disputable, Arpi is right. This is why LGPL was invented.
Disputable - did you hear about int 0x80? What does mean the question there is .so files or not? If you can watch their names through ldd - it's not a problem. (For example mplayerxp already now loads divx4linux through dlopen so you are not able to find out that it uses this library without depth studing of the sources. But communicating with GPL'ed program (kernel) does present always under Linux. So it's not a question at all.
Anyway - I can redistribute your sources under GPL as you said. Nick, what do you want to achieve with this? What good does it get, bringing this GPL-nonGPL topic forth again - just some days/weeks before full-GPL release? In case you stay with separate mplayerxp project, you should keep our "license" until we make it GPL.
If you want: #MPlayer is basically GPL, but contains some non-GPL code which is not allowed to be distributed in binary form, and also contains #the OpenDivX library which has special license. We are still developing towards GPL. # #Distributing MPlayer in the form of binaries and/or binary packages is currently impossible, speaking about both technical and law #areas. Detailed information can be found in the second part of this file, and it is recommended to read it. I guess that non-GPL'ed code is not mplayer.c? :) It was never declared explicitly!!! #Reasons: Law # #MPlayer describes the sourcecode. It contains several files with incompatible licenses especially on the redistribution clauses. As ^^^^^^^ #source files, they are allowed to coexist in a same project. # #Therefore, NEITHER BINARIES NOR BINARY PACKAGES OF MPlayer ARE ALLOWED TO EXIST SINCE SUCH #OBJECTS BREAK LICENSES. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE DOING ILLEGAL #ACTIVITIES. # #So if you know somebody who maintains a binary package then forward her/him this text and (ask him to) contact us. What (s)he is #doing is illegal and IT IS NO LONGER MPlayer, but his/her mplayer. If it breaks, it is his/her fault. Don't come and cry on the #MPlayer mailing lists, you will most likely be blacklisted. Except the juristic lacks: The word 'several' is countable noun in english. But those sources were never counted! I don't want to play in SUCH games. When I asked Arpi what I should remove also from mplayerxp he wanted say: mplayer.c - it's not GPL'ed code. But sorry! mplayer package never had a normal licence. Only some files in this package have explicitly given licence. Well - I asked developer - what should I remove also? Only Mike Melanson said me that his stuff is GPL'ed. Well, Arpi told before that I can redistribute his stuff under GPL but I've top amazed: #> you should at least ask us, at least my code is not GPL yet. 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... Arpi said that his code is NOT GPL'ed. Then what licence covers that (Sun's Moziila'a, OSF, BSDlike)? Nothing! There is no expicitly given licence which was PUBLISHED. In this connexion, that attack on OS/2 developers looked strange since they got unlicensed stuff - so what you want from them? (Although then it was presented as stealing). But nobody can steal CODE which is in PUBLIC DOMAIN or under BSDlike licence for examlpe or without licence at all). So delaying of licence's question doesn't increase mplayer's profit at all. (I will not amaze if this code was included in some commercial soft).
-- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama
Best regards! Nick
Nick Kurshev didn't RTFM :
It's not only about card, it's about X driver too! I fixed vo_xv upto 10 buffers so version of X11 doesn't matter - you can grow it upto infinity. Ehh. I meant the card doesn't have xv driver AT ALL. Like s3 trio64 which is a great card for these machines.
It's not disputable, Arpi is right. This is why LGPL was invented. Disputable - did you hear about int 0x80? I'm not sure that would stand in the court. After all, LGPL _does_ exists..
I guess that non-GPL'ed code is not mplayer.c? :) It was never declared explicitly!!! Faszom.
Only Mike Melanson said me that his stuff is GPL'ed. .so just said on IRC: GUI and mpng code is _not_ GPL. (under standard "mplayer licence")
So delaying of licence's question doesn't increase mplayer's profit at all. Faszom. Nick, you didn't answer my question: exactly _WHAT_ do you want to achieve with this licensing issue? MPlayer _will_ be GPL in a few days! Do you plan WorldDominationXP(tm) until then??
-- Gabucino "I think the developers placed this bug intentionally, so the GUI won't run on specific systems. They are Debian-lovers, I see this from the docs." -- lama
Hello, Gabucino! On Mon, 18 Mar 2002 20:09:07 +0100 you wrote: [snip]
So delaying of licence's question doesn't increase mplayer's profit at all.
[snip]
Nick, you didn't answer my question: exactly _WHAT_ do you want to achieve with this licensing issue? MPlayer _will_ be GPL in a few days! Do you plan WorldDominationXP(tm) until then??
What do I want? I want have freedom to distribute my branch under GPL except stuff which have other licence. I don't want to start this subtread but Arpi said: #>you should at least ask us, at least my code is not GPL yet and that sounded like - I violate some strange licence without author agreement on that. Since it serious question I wanted to analyse - what I violated? Here is my opinion: 1. Mplayer has no licence at all. Because: mplayer is not a program but collection of sources (even this fact is not declared. I can't find out from mplayer's licence - what is subject of licence). Let mplayer is collection of sources. As declared in "licence agreements" these sources have different licences. Therefore mplayer has no united licence which covers whole package and each source file MUST have explicitly given licence (else it's unlicensed). In addition, given licence doesn't give list of files where should be explicitly counted files or their groups. O'k - I tried deterime which sources have licence and what kind of licence they have. My analysis shows me that mplayer's package contains dominated number of sources which have no licence at all (include core of player and its integral parts). 2. In this connexion, I don't violate any mplayer's licence. 3. I allow binary distrubution after clearing of code from non GPL'ed stuff (except unlicensed) - and I'm right. 4. I shouldn't wait until you make mplayer GPL'ed PROGRAM. When I first time participated with Mplayer in march-april 2001 - there was the same situation - mplayer was unlicensed (finely basicaly GPL'ed) and Arpi promised that his mplayer will be GPL'ed as soon as possible. It was year ago. Now I can watch the same promises. I don't believe in the phrase: "MPlayer _will_ be GPL in a few days!" You have own freedom do that or not do. Same as I have the same freedom. And I realized that. (Well - there is my lack: xp has several subdirs with expicitly non-GLP'ed code and I going to upload next release as soon as I'll remove that. And I will not wait until mplayer will be GPL'ed or will not be GPL'ed!) That's all! Best regards! Nick P.S.: Please keep it in mind: licence is not a toy and until mplayer has the same situation it's equal to - mplayer has no licence. (You should or make it a program and cover by unified licence (of any kind which will more like to Arpi) or put licence's strings in every source file - where they don't present). Else it provides possibility to use mplayer's (unlicensed) sources in any way by everyone.
Nick Kurshev wrote:
mplayer's package contains dominated number of sources which have no licence at all (include core of player and its integral parts).
IANAL, but IMHO: Just because the license is not stated in the source files does not mean "it has no license at all so I can do whatever I want". I'd rather take this to mean you have to negotiate with the writer of the code the terms on which it may be licensed. After all the writer still has the copyright unless he explicitly chooses to make it public domain. -- Tobias PGP: 0x9AC7E0BC
Hello, Tobias! On Tue, 19 Mar 2002 19:33:52 +0100 you wrote:
Nick Kurshev wrote:
mplayer's package contains dominated number of sources which have no licence at all (include core of player and its integral parts).
IANAL, but IMHO:
Just because the license is not stated in the source files does not mean "it has no license at all so I can do whatever I want". I'd rather take this to mean you have to negotiate with the writer of the code the terms on which it may be licensed. After all the writer still has the copyright unless he explicitly chooses to make it public domain.
On Tue, Mar 19, 2002 at 07:33:52PM +0100, Tobias Diedrich wrote:
Nick Kurshev wrote:
mplayer's package contains dominated number of sources which have no licence at all (include core of player and its integral parts).
IANAL, but IMHO:
Just because the license is not stated in the source files does not mean "it has no license at all so I can do whatever I want". I'd rather take this to mean you have to negotiate with the writer of the code the terms on which it may be licensed. After all the writer still has the copyright unless he explicitly chooses to make it public domain.
So true. Idiotic proprietary software companies have people thinking backwards to the point that they can't even comprehend simple terms. A license, in legalese, is a document granting one permission to do something that would otherwise be prohibited -- NOT an agreement or contract, and certainly not a document that magically takes away your rights. In summary, no license = you can't make copies or derivative works at all beyond the limits of fair use. No license is the opposite of public domain, not the same. However, IANAL, but in any sane interpretation of the law and fair use, a license is not required to make the temporary copies in memory necessary to run a program, or to make modification to a program for one's own personal use to adapt it to one's own needs. </copyright rant> Rich
On Mon, Mar 18, 2002 at 09:45:23PM +0300, Nick Kurshev wrote:
Hello, Gabucino!
On Sun, 17 Mar 2002 19:50:13 +0100 you wrote:
Nick Kurshev didn't RTFM :
such slow systems (like p1 or old celerons) usually has no xv-capable cards but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times. It's not only about card, it's about X driver too!
I fixed vo_xv upto 10 buffers so version of X11 doesn't matter - you can grow it upto infinity.
Every commercial program can be compiled with GPL'ed shared object. LGPLed. not GPLed. It's disputable question It's not disputable, Arpi is right. This is why LGPL was invented.
Disputable - did you hear about int 0x80? What does mean the question there is .so files or not? If you can watch their names through ldd - it's not a problem. (For example mplayerxp already now loads divx4linux through dlopen so you are not able to find out that it uses this library without depth studing of the sources. But communicating with GPL'ed program (kernel) does present always under Linux. So it's not a question at all.
It is not disputable, at least as long as you are participating in ANY activity that involves copying, modifying, or distributing the GPL code. You may be able to convince a court to let you work around this is you never touch the GPL code yourself, and only make it easy for end users who obtained the GPL code from somewhere else to link it with your GPL-incompatible program, but you most definitely cannot do what you're saying if you distribute the GPL with your GPL-incompatible code or as a separate addon package for it. Why don't you try actually READING the GPL for once? Linking is linking, and it does not matter whether its static or dynamic. BTW, although the whole issue has not been argued in court before, it *has* convinced fairly large companies to back down and GPL their whole programs, or move the GPL code to a separate program that's independent, multiple time in out-of-court settlements. So don't just take my word for it, do the research and stop babbling about things you know nothing about. Rich
Hi,
such slow systems (like p1 or old celerons) usually has no xv-capable card s ^^^^^^^ but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times.
please rtfm dr-methods.txt you still don't understand... if you have a single (1) buffer, you don't have to update the whole buffer at each frames, just the chanegd macroblocks. at average (<=1000kbit) divx only ~30% of MBs chanegs between 2 frames. so it means 300% speedup of video blitting and it really matters on slow pci bus / video ram old systems have if you have more than 1 buffers (even if they are in video ram) you have to refresh all MBs so you lose this advantage of DRm2, and only get one less memcpy (maybe) nothing more. of course having 1 buffers decreases quality but on p1 mmx who cares... and on faster systems it has no sense nor your stuff so if we see the things: 1 2 3 4 |--------|--------|---------|-----------------------------| cpu speed: slow ~200mhz ~400mhz ~800mhz fast avg bench: >100% >100% <100% <100% max bench: >100 >100 >100 <100 method: framedrop| dr m2 |dec.ahead| old single-process mplayer playback: jerky smooth smoother smoother your threading mess is only usefull at range '3', to make playback smoother ( != make playabck possible - it makes no extra performance - just a bit better quality) it won't help at 1,2 and 4, only at 3
Every commercial product communicates with GPL'ed kernel. So it seems just as stupid limitation. there are no shared objects nor LGPL
ans we'll remove this stupid license as soon as we get rid of things keepe ng us away from binary packages. but you'd better RTFMing
Anyway - I can redistribute your sources under GPL as you said. Second - you should make it as soon as possible simply because mplayer has many parts which are GPL'ed - GPL is applicable to PROGRAM which doesn't exi st. (vidix is not a program) It something strange. Anyway you should call something by PROGRAM to which is applied GPL of parts !
heh? you should actually program instead of thinking about what is program :) A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
Hello, Arpi! On Sun, 17 Mar 2002 20:04:34 +0100 you wrote:
Hi,
such slow systems (like p1 or old celerons) usually has no xv-capable card s ^^^^^^^ but dga or vidix or xmga (1 buffers) could work there fine Middle size divx4 can be fitted into 2MB of video upto 7 times.
please rtfm dr-methods.txt
you still don't understand... if you have a single (1) buffer, you don't have to update the whole buffer at each frames, just the chanegd macroblocks. at average (<=1000kbit) divx only ~30% of MBs chanegs between 2 frames. so it means 300% speedup of video blitting and it really matters on slow pci bus / video ram old systems have
if you have more than 1 buffers (even if they are in video ram) you have to refresh all MBs so you lose this advantage of DRm2, and only get one less memcpy (maybe) nothing more.
of course having 1 buffers decreases quality but on p1 mmx who cares...
and on faster systems it has no sense nor your stuff
so if we see the things:
1 2 3 4 |--------|--------|---------|-----------------------------| cpu speed: slow ~200mhz ~400mhz ~800mhz fast avg bench: >100% >100% <100% <100% max bench: >100 >100 >100 <100 method: framedrop| dr m2 |dec.ahead| old single-process mplayer playback: jerky smooth smoother smoother
your threading mess is only usefull at range '3', to make playback smoother ( != make playabck possible - it makes no extra performance - just a bit better quality)
it won't help at 1,2 and 4, only at 3
When frame cares only part of scene it's easy frame. Hard frames cares a full new scene and this method will not help you.
Every commercial product communicates with GPL'ed kernel. So it seems just as stupid limitation. there are no shared objects nor LGPL
ans we'll remove this stupid license as soon as we get rid of things keepe ng us away from binary packages. but you'd better RTFMing
Anyway - I can redistribute your sources under GPL as you said. Second - you should make it as soon as possible simply because mplayer has many parts which are GPL'ed - GPL is applicable to PROGRAM which doesn't exi st. (vidix is not a program) It something strange. Anyway you should call something by PROGRAM to which is applied GPL of parts !
heh?
you should actually program instead of thinking about what is program :)
I would be glad to program a program.
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@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
Am Son, 2002-03-17 um 17.32 schrieb Nick Kurshev:
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. My idea is have them predecoded in pauses (when main process sleeps). So there is a big speedup. - Monotonous cpu loading against of peaked loading.
Why would that be benefitial instead of say prebuffering frames? Also how do you synchronize between your threads? How many threads are you spawning and what are there functions? Do you have some sort of diagram available? -- Servus, Daniel
Hello, Daniel! On 17 Mar 2002 18:58:34 +0100 you wrote:
Am Son, 2002-03-17 um 17.32 schrieb Nick Kurshev:
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. My idea is have them predecoded in pauses (when main process sleeps). So there is a big speedup. - Monotonous cpu loading against of peaked loading.
Why would that be benefitial instead of say prebuffering frames? Also It said also ;) how do you synchronize between your threads? How many threads are you spawning and what are there functions? Do you have some sort of diagram Currently there are only 2 thread: main (mplayerxp) and video decoding available? in graphics form - no
-- Servus, Daniel
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Best regards! Nick
On Sun, Mar 17, 2002 at 05:20:37PM +0100, Gábor Lénárt wrote:
BTW, I don't understand why threading makes things faster (of course on single CPU system, on SMP it's true of course).
Because threading might take some code out of a(n I/O) "blocked" path and put it into an executable path.
Maintaining multiple contexts by scheduler makes a bit SLOWER not faster. The fastest possible way to implement an algorithm on UP systems is using only ONE thread (of course it can be true that it makes it smoother a bit but also it will be slower).
You are right in all of this, as long as the one thread is free of I/O blocking. If Nick really has found a 200-300% efficiency gain with threading, what he likely has done is found tasks in "old" mplayer core that block other tasks from happening (such as decoding and buffering frames). b. -- Brian J. Murrell
participants (11)
-
Alex Beregszaszi -
Arpi -
Attila Kinali -
Brian J. Murrell -
D Richard Felker III -
daniel carter -
Daniel Egger -
Gabucino -
Gábor Lénárt -
Nick Kurshev -
Tobias Diedrich