From: Dennis H. <dh...@on...> - 2003-02-24 00:10:14
|
Dear Thomas Vander Stichele First I didn't want to answer. But your indifference in looking at things makes me angry. You are a developer of a product that is offered to others and should be interested in what they think instead of joking at them with sentences like : "Let's reverse the question: what philosophical problem do you have with installing a library ?" It is not only a stupid question, since there never was any philosophical intend in my statement, but it is either not an appropriate position to your users. I can't force you to overthink things if you don't like to and will not try to but it actually makes sense that I contact the developers who chain me to non-understood dependencies and talk to them before I just go searching for the next tool with other non-understood dependencies. As somebody being dependent on others when it comes to multimedia tools I can only argue, resign or leave. Maybe you should re-think about what your position as the developer implies. It would be better for 0.01% of your users, at least. To answer the other two core points in your statement: Core libraries are those libraries you can't get rid of since they are too important for your system. With system I mean a system of interdependent software and not single software or my very own system concept. If I want to install Linux I may be able to drop some tools or libs like termcap. I could use ncurses instead. But I will not be able to skip glibc. So it is with GNOME and esound or with multimedia stuff (video, audio, gaming and such) and SDL. Try staying away from SDL, this isn't easy nowadays, really! But there is no problem in skipping Hermes on a modern GNOME/linux system, except you want to have video support in the single product gst-player. I understand that Hermes is needed, I already wrote this, but talking about this decision should be legitim. It is also legitim to install from source. The 0.01% have the same rights like others. And, it was not of matter. I just said that I decide on my own what I install and do not leave this decision to distributors. I have very good reasons since I used distros of nearly all well known distributors and always came into trouble or just disliked the bloating of my harddisk, the crazy configuration dialogs and the like. I use linux commercially and need to be able to find better ways for my case. So, I have good reasons (only to answer your comment). This is not related to gst-player, wasn't intendet to be understood this way and, from my point of view, was never expressed this way. It was only an answer to: "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." becuase this missed the point (as your statement did). I do not want to be relieved from installing by hand, I just wanted to discuss about a main dependency (playing video is one of the _core_ functions of gst-player, isn't it?) that I only need for exact one product of thousands. You can decide if this is of interest to you but, again, it is legitim to discuss about Hermes being a main dependency, atleast if you are interested in your users. I really don't want philosophical, political or personal discussions. Please, leave me with your indifferent position. I just made use of my right as a user to explain a situation that is worth thinking about if the programmer was interested in thinking about that. Bye Dennis P.s.: If business service people would argue your way their companies would go bankrupt. |
From: Erik W. <om...@te...> - 2003-02-24 02:40:12
|
A common theme throughout your email seems to be the assumption that we are here to serve you. This is simply not true. The programmers involved in this project are doing this almost entirely on their own time, for their own reasons. Nowhere have we signed up to provide support for this project other than what we willingly provide. On Mon, 24 Feb 2003, Dennis Heuer wrote: > But there is no problem in skipping Hermes on a modern GNOME/linux > system, except you want to have video support in the single product > gst-player. This is how things work: Libraries that provide a certain service (in this case colorspace conversion) exist to be used by other libraries and applications so that they do not have to implement the same operation themselves. This is called "code re-use". When library or applications programmers decide that they want to "reduce dependencies" by implementing such operations themselves, they end up with their own codebase which is inevitably full of their own bugs, which have to be tracked separately from the same or other bugs in functionally identical pieces of code mainained by someone else. Because these chunks of code are not the primary reason the author is writing whichever program, they are left to rot, and the bugs remain. On the other hand, you have programmers who understand the pitfalls of creating a zillion copies of a routine with their own bugs and flaws. They search for libraries that already do what they want, and make use of them. Those writing new functionality write it in the form of a library, so it can be used by more than just their own project. Imagine if no one had ever bothered to write libc. Because of the evolution of open-source projects, you often have libraries that are either fundamentally flawed, or are never adopted by enough users in order to attain a fully "maintained" status. Hermes is in both categories, yet when the original decision was made to use it, it was a) still under development, and b) used by more projects. Hermes has not been removed from the core colorspace element because there has been no viable alternative so far. We have not gone the route of merging Hermes into the colorspace element because doing so would not be worth the hassle in the long run. It has also not been that big of an issue, until now. > I understand that Hermes is needed, I already wrote this, but talking > about this decision should be legitim. No one has made the claim that it is not legitimate to discuss the requirement of Hermes for core video support. What we are not exactly thrilled with is your approach to bringing up the issue. Instead of politely asking why we are using Hermes for colorspace conversion and whether there were any plans (or God forbid, whether you could even *help*!) to remove it in favor of some other solution, you start out by complaining that you have to install something (which BTW is *very* small and trivial to compile) that you didn't want to, and so you can't get all these neat features. And <GASP>, look at that HUGE dependencies list! It is precisely that attitude that provokes us into *not* rushing out and removing Hermes from the dependencies list YESTERDAY. > It is also legitim to install from source. The 0.01% have the same > rights like others. Yes, you have the exact same list of rights, and the exact same list of things you do *not* have a right to. Quite high on that list of things you *don't* have a right to do is expect developers who work on a project for fun to cater to your every requirement. If you want to force us to do X, Y, and Z, you have to pay us (resume's to be handed out at the door). > You can decide if this is of interest to you but, again, it is legitim > to discuss about Hermes being a main dependency, atleast if you are > interested in your users. We are *always* interested in what our users need, because we are users ourselves. Odd are that if someone runs into a problem or a new feature they need, one of the developers needs or soon will need that same problem fixed or that same new feature. Otherwise, we tend to leave well enough alone, as is the case with Hermes so far. > Maybe you should re-think about what your position as the developer > implies. Maybe you should re-think what your position as a *user* of *free* software implies. > P.s.: If business service people would argue your way their companies > would go bankrupt. If you actually paid us for a service, we would be obligated to respond appropriately. Since this project was written for fun, we are *not* obligated to "support" it in the same way that a business should support their products. Now, because it is indeed relevant, I will explain our plans for replacing Hermes: We are working on a number of projects under the codecs.org umbrella project (see http://codecs.org/) focussing on high-performance routines and infrastructure for codecs and related systems. One of these is called 'libcolorspace' and will contain both highly-optimized routines for various processors (SSE, Altivec, etc.), and general conversion routines that support any-to-any conversions. libcolorspace will itself depend on Specialib, which is the main infrastructure piece necessary to actually select the highest-performing versions of the routines available. This puts *two* libraries on the system as a requirement for the default 'colorspace' element. I suspect this will make you twice as likely not to use gst-player, but for reasons outlined above, I care enough to assist where I can, but I do *not* care enough to design my code in a less-than-optimal manner. The reason we are building Specialib, libcolorspace, and all the other libraries on codecs.org, is so that people will use them. I am personally *sick* of everyone and their dog writing their own iDCT, their own colorspace routines, their own this and that. Every single one of them has one or more significant flaws, the most common being that it simply is *not* the fastest available routine of its kind. Specialib and libcolorspace are an attempt to gather the fastest and best routines into one place, so that other authors will *not* have to continually re-invent this wheel. If no one else *ever* uses these libraries, that will not change the fact that they are still the best way to implement a colorspace conversion element for GStreamer. Erik Walthinsen <om...@te...> - System Administrator __ / \ GStreamer - The only way to stream! | | M E G A ***** http://gstreamer.net/ ***** _\ /_ |
From: Ronald B. <rb...@ro...> - 2003-02-24 07:33:19
|
Hey Erik, [silently removing some user from CC list] On Mon, 2003-02-24 at 03:39, Erik Walthinsen wrote: [-specialib/libcolorspace-] > This puts *two* libraries on the system as a requirement for the default > 'colorspace' element. I suspect this will make you twice as likely not to > use gst-player, but for reasons outlined above, I care enough to assist > where I can, but I do *not* care enough to design my code in a > less-than-optimal manner. After having seen how we handled ffmpeg (which I'm quite happy with), I'm interested in seeing the same library use of _some_ other dependencies such as libatomic (assuming we will use that), specialib, and libcolorspace. Admitted, (lcs)colorspace has nothing to do with the gstreamer core, neither is it a core element (it is an obligatory dependency of one of our applications, which goes for lots of elements/applications). Still, I think it would make sense to use (tagged?) CVS versions of projects like libcolorspace, libatomic etc. just like we do with ffmpeg. The only problem here is static linking (installing a newer libcolorspace doesn't update the (lcs)colorspace element), but since A) we release quite often and B) harddisks are quite huge nowadays, I don't think this is too big a problem. Reason is that most, if not any, distribution will include mad, vorbis/ogg, etc. However, little distributions currently include libcolorspace - it doesn't have a stable API and a 1.0.x release - which makes building quite annoying (you could assume distributions to include it in the future because they have to to get gst-player to work, but since it's not a 1.0.x release, do we want to depend on that?). Basically the same problem as with ffmpeg, where we decided to include it in our releases. What do others think of this? For some specific plugins, I think it'd be appropriate to include CVS versions of their code... Ronald -- Ronald Bultje <rb...@ro...> |
From: Tuukka T. <tu...@ee...> - 2003-02-24 09:04:04
|
On Mon, 24 Feb 2003, Dennis Heuer wrote: >and should be interested in what they think instead of joking at them with >sentences like : > >"Let's reverse the question: what philosophical problem do you have with >installing a library ?" Maybe you misunderstood the intention. I don't feel that it was a joke, instead the point was, what's wrong in requiring you to install the Hermes library? The truth is, that it should be very easy to do, if it is included in your distribution (for Debian it is, at least). >It is not only a stupid question, since there never was any philosophical >intend in my statement, but it is either not an appropriate position to Right, then forget the single word and tell us what problem you have installing Hermes, anyway? It should not cause great problem for majority of users, if it does (and you can show it) then maybe the developers would consider again whether replacing Hermes with something else. >Core libraries are those libraries you can't get rid of since they are too >important for your system. With system I mean a system of interdependent Well, then it is subjective, since some users won't need Xlibs, while other require not only X but also Gnome and KDE. So there really aren't anything such as core libraries (even glibc is not used in some embedded systems...) >gst-player. I understand that Hermes is needed, I already wrote this, but >talking about this decision should be legitim. So what is your alternative? Should the dependancy to Hermes be replaced with dependancy to some other library, or should Hermes be included within Gstreamer source (in which case it won't take advantage of further developments in Hermes), or should Gstreamer developers write similar code from scratch? Unless you can come up with something better than dependency to Hermes, don't waste your time complaining about it. >I really don't want philosophical, political or personal discussions. Hmm, you hate philisophers? ;) Your reaction feels like that... [Some words of myself since this is my first post to the list: I'm qc-usb camera driver developer but the problem is that the camera doesn't deliver any format that is supported by V4L(2), and as you can see from my signature, it isn't exactly recommended to do format conversions in the kernel... so my plan is to abandon V4L(2) api partially in the longer run and support Gstreamer API instead. Didn't get gstreamer video yet to work, though, but I just started investigating it anyway. Nevertheless, if Gstreamer API is as good as I hope, I'm confident it will be one of the most important things that have happened to Linux recently] -- | Tuukka Toivonen <tu...@ee...> [OpenPGP public key | Homepage: http://www.ee.oulu.fi/~tuukkat/ available] | M.Sc. Researcher, Dept of El & Inf Eng, University of Oulu | "You will be shot if you try to do | format conversion in kernel" -Pavel Machek, 2001 +----------------------------------------------------------- |
From: Ronald B. <rb...@ro...> - 2003-02-24 10:14:53
|
Hi Tuukka, I've seen earlier of your postings on the v4l mailinglist, welcome to this list! On Mon, 2003-02-24 at 10:03, Tuukka Toivonen wrote: > [Some words of myself since this is my first post to the list: I'm qc-usb > camera driver developer but the problem is that the camera doesn't > deliver any format that is supported by V4L(2), and as you can see from my > signature, it isn't exactly recommended to do format conversions in the > kernel... so my plan is to abandon V4L(2) api partially in the longer run > and support Gstreamer API instead. Didn't get gstreamer video yet to work, > though, but I just started investigating it anyway. Nevertheless, if > Gstreamer API is as good as I hope, I'm confident it will be one of the > most important things that have happened to Linux recently] Being one of the persons really in *favour* of v4l2, I'd strongly advice against this. I'm developer of the zoran v4l/v4l2 driver. In v4l1, we used extensions for basic things like timestamps, hardware-encoded frames, etc. In v4l2, I've made sure that all this is possible in the standard API, so that we wouldn't need any extensions. This has succeeded, causing our v4l2 driver to be fully integrated in the v4l2 API, no extensions needed. I personally feel that v4l2 is extendible enough to not need to dive away from it for hardware that isn't 'standard-like'. I'm assuming the qc-usb cam delivers JPEG-like frames (quite some cams do this, *ugh*! But yes, it gives nice images at low datarates, which is good ;-) ). I'd suggest to try to use standard V4L in your driver, and only offer the fourcc 'JPEG' (V4L2_PIX_FMT_JPEG), which means 'JFIF-like JPEG', as opposed to Motion-JPEG (YUY2), which is 'MJPG' (V4L2_PIX_FMT_MJPEG). The current GStreamer v4l2 plugin will attach a mimetype of 'video/jpeg' to this, so you only need to place a JPEG header in front of it (this is something the driver is supposed to do), and jpegdec (libjpeg decoder) will happily decode the JPEG frames. ffmpeg's optimized JPEG decoder (ffmpegdec) and mjpegtools' MMX/SSE JPEG decoder (jpegmmxdec) will also work here. This would all integrate perfectly in GStreamer, and you'd still be v4l2 compliant. Isn't that a good thing? This is basically the goal of GStreamer's v4l2 plugin: support as many weird color formats in v4l2 as possible, while still being 100% v4l2 compliant. I'm against doing format/colorspace conversions in kernelspace, and GStreamer gives perfect solutions for problems that this might cause in userspace (by automatic colorspace conversion or format decoding, all integrated in compatible pipelines). If anything doesn't work, feel free to hop on in #gstreamer @ irc.freenode.net, I'll be mostly online during the days (I'm at work though, so I might not respond) - I'll be happy to help in helping out to make both the driver and the v4l2 plugin work with your cam. That's how I tested the v4l2 parts of the zoran driver too. ;-). Ronald -- Ronald Bultje <rb...@ro...> Linux Video/Multimedia developer |
From: Tuukka T. <tu...@ee...> - 2003-02-24 13:26:52
|
On Mon, 24 Feb 2003, Ronald Bultje wrote: >> kernel... so my plan is to abandon V4L(2) api partially in the longer = run >> and support Gstreamer API instead. Didn't get gstreamer video yet to w= ork, >Being one of the persons really in *favour* of v4l2, I'd strongly advice >against this. I'm developer of the zoran v4l/v4l2 driver. In v4l1, we >good ;-) ). I'd suggest to try to use standard V4L in your driver, and Basically the qc-usb supports Bayer CFA-encoded frames, for which there i= s not support in V4L(2). A format definition could be added, but it wouldn'= t help, if no application would support it (and really it would need to be supported by _every_ application). So, what's the point using V4L(2) API = if only special applications can use it anyway... unless there's a plugin fo= r Gstreamer which would understand the Bayer format. To summarize: yes, I'm planning to use V4L(2) API but add a compilation time option to remove format conversions, which sets the driver to output Bayer format which wi= ll be supported only via gstreamer plugins, thus rendering the driver V4L API practically useless for general applications. [But to users reading this: don't be afraid, I'll keep format conversions as long as there are significant applications around which don't support gstreamer.=A0This is a _very_long_ run plan] >only offer the fourcc 'JPEG' (V4L2_PIX_FMT_JPEG), which means 'JFIF-like >JPEG', as opposed to Motion-JPEG (YUY2), which is 'MJPG' With some rare cameras, qc-usb actually supports compressed MJPEG-alike format (decompressing in the kernel space, ugh). But I'm not quite sure about this format, I just copied the code from other people. Looks like it's 4:2:0 YUV sampled, isn't it more MJPEG than JPEG/JFIF style? [A link to MJPEG/JPEG format specs would be great... but I think they are available only for $$$ so it's difficult to know if the camera is sending conforming bistream] >good thing? This is basically the goal of GStreamer's v4l2 plugin: >support as many weird color formats in v4l2 as possible, while still >being 100% v4l2 compliant. I'm against doing format/colorspace Uh.. the application programmer's API, when using Gstreamer's V4L(2) plugin, is not V4L(2), correct? That was my original point: I'm planning = to deprecate the direct use of the driver V4L(2) API, but recommend to use i= t via Gstreamer API. As soon as I get the Bayer->RGB conversion plugin written. >conversions in kernelspace, and GStreamer gives perfect solutions for >problems that this might cause in userspace (by automatic colorspace >conversion or format decoding, all integrated in compatible pipelines). Really great! |
From: Ronald B. <rb...@ro...> - 2003-02-24 13:48:34
|
Hi Tuukka, On Mon, 2003-02-24 at 14:26, Tuukka Toivonen wrote: > Basically the qc-usb supports Bayer CFA-encoded frames, for which there is > not support in V4L(2). A format definition could be added, but it wouldn't > help, if no application would support it (and really it would need to be > supported by _every_ application). So, what's the point using V4L(2) API if > only special applications can use it anyway... unless there's a plugin for > Gstreamer which would understand the Bayer format. To summarize: yes, I'm > planning to use V4L(2) API but add a compilation time option to remove > format conversions, which sets the driver to output Bayer format which will > be supported only via gstreamer plugins, thus rendering the driver > V4L API practically useless for general applications. OK, that's what I was hoping for. This is exactly what I meant. > >only offer the fourcc 'JPEG' (V4L2_PIX_FMT_JPEG), which means 'JFIF-like > >JPEG', as opposed to Motion-JPEG (YUY2), which is 'MJPG' > > With some rare cameras, qc-usb actually supports compressed MJPEG-alike > format (decompressing in the kernel space, ugh). But I'm not quite sure > about this format, I just copied the code from other people. Looks like > it's 4:2:0 YUV sampled, isn't it more MJPEG than JPEG/JFIF style? "Official" MJPEG video is 4:2:2 packed-pixel Y'Cb'Cr (YUY2). Yours sounds like IYUV/I420 (4:2:0 planar Y'Cb'Cr). I don't think JFIF/JPEG defines anything specifically about colorspace, it's just a generic compression scheme. > [A link to MJPEG/JPEG format specs would be great... but I think they > are available only for $$$ so it's difficult to know if the camera is > sending conforming bistream] There's quite some documentation on http://www.ijg.org/. Since JPEG is an official ISO standard, I'd expect the ISO specs to be there too, or on http://www.jpeg.org/. Can't find it at first sight, though. There are some (MS Word) JPEG docs in /usr/share/doc/libjpeg-devel-6b/ too (part of the libjpeg-devel package). > Uh.. the application programmer's API, when using Gstreamer's V4L(2) > plugin, is not V4L(2), correct? That was my original point: I'm planning to > deprecate the direct use of the driver V4L(2) API, but recommend to use it > via Gstreamer API. As soon as I get the Bayer->RGB conversion plugin > written. Sounds great! I'm all in for it. Ronald -- Ronald Bultje <rb...@ro...> Linux Video/Multimedia developer |
From: Tuukka T. <tu...@ee...> - 2003-02-24 14:01:21
|
On Mon, 24 Feb 2003, Ronald Bultje wrote: >There's quite some documentation on http://www.ijg.org/. Since JPEG is >an official ISO standard, I'd expect the ISO specs to be there too, or ? Since JPEG is an ISO standard, I'd expect it NOT to be there, after all, all ISO standards I know of are very expensive to obtain. At best one can find some old draft versions from the net, whose legal status is unclear at best. But, thanks for the links, anyway. |