From: Dennis H. <dh...@on...> - 2003-02-22 19:25:45
|
Dear Christian Thanks for your answer. I understand that you want to base your code on external libraries. This is not what I criticize. You wrote: As distributions start to include GStreamer they will also ship most of these needed 3rd party libraries which will relieve you of the trouble of having to install them togheter with GStreamer. This, _fortunately_, is not true in my case since I love to install my system manually from source. So, I am not only bored from installing many packages (which is true but I can cope with that) but I have discussed with myself many times what to install and what not. This is why I awaited gst-player, for an example. I do not have Xine or such on my newly installed system and couldn't listen to my oggs for weeks now. But, I decided to not install something I don't want if something better for my case is possibly coming up soon. People who depend on distros may install whatever their distroa prefer without asking or even thinking about that. I don't think that this is the way to go. We should discuss dependencies over and over. The point is that there are core dependencies and, besides that, there are a lot of optional dependencies. I just care about the core dependencies - as long as the optional dependencies are really optional. You already seem to solve the problem with that core dependency Hermes. Hermes is not really a core application on linux systems and thus should not be a core dependency for gst-player. On the other hand, if you keep optional dependencies really optional, then have as many dependencies you want. I will not care since I will skip these options at installation time. This is all I fight for ;) Greetings Dennis |
From: Thomas V. S. <th...@ur...> - 2003-02-23 21:30:43
|
> Dear Christian > > Thanks for your answer. > > This, _fortunately_, is not true in my case since I love to install my system manually from source. So, I am not only bored from installing many packages (which is true but I can cope with that) but I have discussed with myself many times what to install and what not. This is why I awaited gst-player, for an example. I do not have Xine or such on my newly installed system and couldn't listen to my oggs for weeks now. But, I decided to not install something I don't want if something better for my case is possibly coming up soon. My personal opinion is that we shouldn't try to cater for the 0.01% that compiles from source (do you have good reason to do so ?). Especially now with something like gentoo, I don't see any point at all in doing everything by hand. > People who depend on distros may install whatever their distroa prefer > without asking or even thinking about that. I don't think that this is > the way to go. We should discuss dependencies over and over. The point is > that there are core dependencies and, besides that, there are a lot of > optional dependencies. I just care about the core dependencies - as long > as the optional dependencies are really optional. You already seem to > solve the problem with that core dependency Hermes. > Hermes is not really > a core application on linux systems and thus should not be a core > dependency for gst-player. That's a weird statement to make. I don't know who decides what are core applications on linux, but I'd imagine things like vorbis, avifile, and so on not being part of them. > On the other hand, if you keep optional > dependencies really optional, then have as many dependencies you want. I > will not care since I will skip these options at installation time. You can decide for yourself whether or not Hermes is optional. If you don't need video playback, then Hermes isn't needed. If you want video playback, it is needed. I don't really see the problem. If you insist on compiling your system by hand, of course you're going to end up spending lots of time compiling and installing dependencies. Do I wish this on you ? No. But that's a choice you made for yourself. The solution is not, as you suggest, to take out dependencies. If that rubs you the wrong way, then maybe GStreamer is not what you want. GStreamer is designed to make use of libraries. Thomas -- The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> god loves his children yeah <-*- thomas (at) apestaart (dot) org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/ |
From: Benjamin O. <in...@pu...> - 2003-02-25 10:54:05
|
On Sun, 23 Feb 2003, Thomas Vander Stichele wrote: > My personal opinion is that we shouldn't try to cater for the 0.01% tha= t > compiles from source (do you have good reason to do so ?). > Especially now with something like gentoo, I don't see any point at all= in > doing everything by hand. I just couldn't leave that statement standing there alone. Let me assure you I'll file anything I consider a bug on my LFS system that doesn't work. As for the reason to do so: I have to care for one layer less (the packet manager) and I'm in direct control of every install. I can even decide myself which configure options to use. That's a great thing. I never have to fear that installing something from CVS breaks my RPM database. I had an official GNOME2 install before the Debian guys even knew that GNOME2 existed. There are a myriad of other reasons, but I'll stop here. Oh, and Gentoo is just another packet manager that happens to distribute an equivalent of SRPMs. It's only another (though thinner) form of that additional layer. > > Hermes is not really > > a core application on linux systems and thus should not be a core > > dependency for gst-player. That's the point where he is wrong. Hermes is a core dependency of the player. It might be possible (but most probably useless) to make it an optional dependecy. But since nobody cares it would be his job to do that if he wants it. Or he could pay me, it shouldn't be too difficult to do (some defines and configure hacking should be enough) :) Another good thing would be to file a feature request on bugzilla. (Thoug= h that wouldn't be as fast). Just out of interest: Xine and Mplayer include their own colorspace stuff= ? Or Do they just hope that the video formats are supported by XVideo? One of 20.000 GStreamer users=B0), Benjamin =B0) 0.01% compile from source, 2 of those use GStreamer, do the math :) |
From: Tuukka T. <tu...@ee...> - 2003-02-25 12:07:03
|
On Tue, 25 Feb 2003, Benjamin Otte wrote: >Just out of interest: Xine and Mplayer include their own colorspace stuff? Yes, it looks like that in MPlayer (dunno about Xine). From MPlayer-0.90pre8/postproc/swscale.c: ---- supported Input formats: YV12, I420/IYUV, YUY2, BGR32, BGR24, BGR16, BGR15, RGB32, RGB24, Y8/Y800, YVU9/IF09 supported output formats: YV12, I420/IYUV, {BGR,RGB}{1,4,8,15,16,24,32}, Y8/Y800, YVU9/IF09 {BGR,RGB}{1,4,8,15,16} support dithering ---- By the way, if you're interested to know how MPlayer works, take a look in DOCS/tech/libmpcodecs.txt and other files in the dir. MPlayer docs are very good, even from the technical point. Considering the huge variety of media that MPlayer supports, I wonder if it would be difficult to convert whole MPlayer into Gstreamer source module/modules? |
From: Bastien N. <ha...@ha...> - 2003-02-25 12:50:37
|
On Tue, 2003-02-25 at 12:06, Tuukka Toivonen wrote: > On Tue, 25 Feb 2003, Benjamin Otte wrote: > > >Just out of interest: Xine and Mplayer include their own colorspace stuff? > > Yes, it looks like that in MPlayer (dunno about Xine). From > MPlayer-0.90pre8/postproc/swscale.c: > > ---- > supported Input formats: YV12, I420/IYUV, YUY2, BGR32, BGR24, BGR16, > BGR15, RGB32, RGB24, Y8/Y800, YVU9/IF09 > supported output formats: YV12, I420/IYUV, {BGR,RGB}{1,4,8,15,16,24,32}, > Y8/Y800, YVU9/IF09 > {BGR,RGB}{1,4,8,15,16} support dithering > ---- > > By the way, if you're interested to know how MPlayer works, take a look in > DOCS/tech/libmpcodecs.txt and other files in the dir. MPlayer docs > are very good, even from the technical point. > > Considering the huge variety of media that MPlayer supports, I wonder > if it would be difficult to convert whole MPlayer into Gstreamer > source module/modules? The mplayer engine isn't threadsafe, and that includes the plugins etc. Best is to work like xine and MPlayer do, adapting code from each other. You end up with code that is similar but adapted. Cheers -- /Bastien Nocera http://hadess.net #2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from /lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity); Segmentation fault |
From: Tuukka T. <tu...@ee...> - 2003-02-25 12:57:59
|
On Tue, 25 Feb 2003, Bastien Nocera wrote: >The mplayer engine isn't threadsafe, and that includes the plugins etc. Couldn't that be implemented by simply adding locks around each call to the MPlayer code as simple initial low-performance version? To support as wide variety of codecs as MPlayer I'm afraid one needs to use binary-only modules which might not be thread safe anyway. >Best is to work like xine and MPlayer do, adapting code from each other. On the longer run, I definitely agree. |
From: Ben T. <hig...@co...> - 2003-02-25 14:57:00
|
Thomas Vander Stichele wrote: >My personal opinion is that we shouldn't try to cater for the 0.01% that >compiles from source (do you have good reason to do so ?). >Especially now with something like gentoo, I don't see any point at all in >doing everything by hand. > I have a good reason. Sun's Gnome-2.0 is kinda broke, and because they chose to put the support code in the /usr file system, the only way I can build is to build a tree that I'm confident in is to remove Sun's Gnome-2.0 and build it from scratch. I spent about two weeks adding code into the current Garnome tree to build all the support code (png, tiff, expat, etc) that is normally just part of a Linux system. I hit a wall building Gstreamer, and part of it is because my current gcc doesn't use gas, so I'm in the process of building gcc again to use gas. >>Hermes is not really >>a core application on linux systems and thus should not be a core >>dependency for gst-player. >> >> > >That's a weird statement to make. I don't know who decides what are core >applications on linux, but I'd imagine things like vorbis, avifile, and so >on not being part of them. > Well, I assume that the configure script will do the right things and either error out if there are hard dependencies on libraries that don't exist, or report that optional libraries aren't available. The thing I really like about Garnome: You can tell it what dependencies you need for a specific application like Gstreamer, and it will go out and build all that stuff before building Gstreamer. On Solaris, Sun decides what is part of a distribution, but like I said before, the current 2.0 stuff was in /usr, which prevented me from isolating their stuff from what I was building. At least in the 2.0-beta3, it was in /opt, so I just need to keep /opt/gnome-2.0/bin out of my path. >>On the other hand, if you keep optional >>dependencies really optional, then have as many dependencies you want. I >>will not care since I will skip these options at installation time. >> >> > >You can decide for yourself whether or not Hermes is optional. If you >don't need video playback, then Hermes isn't needed. If you want video >playback, it is needed. > >I don't really see the problem. If you insist on compiling your system by >hand, of course you're going to end up spending lots of time compiling and >installing dependencies. Do I wish this on you ? No. But that's a >choice you made for yourself. The solution is not, as you suggest, to >take out dependencies. If that rubs you the wrong way, then maybe >GStreamer is not what you want. GStreamer is designed to make use of >libraries. > Agreed. I've done the home grown gnome thing before and it was a lot of work. I don't think I'd ever do it again without using Garnome. I realize I'm in a very small minority that I'm on Solaris and compiling gnome from scratch. However, as long as I can code the dependencies into Garnome, I don't ever have to worry about it again. Ben |