On Fri, May 25, 2001 at 03:22:44PM +0200, Nemosoft Unv. wrote:
> On 25-May-01 Erik Mouw wrote:
> > On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
> > The format conversion shouldn't be there in the first place. Format
> > conversion is policy, so it doesn't belong in kernel. Note for example
> > that none of the sound drivers does sample rate conversion although
> > some sound chips are locked at 48kHz only.
>
> True, but a number of audio tools will break, because they donīt support that
> samplerate (mpg123 0.59r, one of the more popular MP3 players, segfaults
> when it has to do conversion of 44.1 KHz to 48 KHz). Recording from such a
> source is usually less of a problem, although some post-processing is
> then necessary (not all tools support samplerate conversion natively).
I consider that a bug in mpg123. Examples for rate conversion have been
available for years, so fix mpg123.
> The situation for video devices is worse. 80% of the video tools will break
> if you limit the number of available palettes per driver. Plus, you will get
> severe fragmentation of which program works with which driver. Which is
> unacceptable, in my opinion (and certainly NOT the idea behind a common API!)
I consider this a bug in the tools. I've been working with real-time
video on sgi IRIX machines, and they do a couple of things right:
- The hardware supports a limited set of video formats. Most high end
stuff (Onyx+Sirius, Octane+DV, Onyx2+DIVO) only supports a couple of
YUV or YUVA formats (in studios YUV422 or YUV422+A is the most used).
Low end workstations (Indy, O2) supports some "consumer" formats like
RGB or Y as well.
- There are a couple of libraries (vl, cl, dmedia, audio, audiofile)
that allows you to do all kinds of manipulations in userland.
Fortunately sgi also recognises this, and they're porting their
libraries to Linux (see oss.sgi.com).
> You can blame the authors of those video tools, but thatīs not really fair.
> The original Video4Linux API was based upon TV grabber cards. Most of them
> do YUV/RGB conversion in hardware, so most tools expected that all or most
> palettes would always be available, since supporting a palette would not
> require any extra CPU cycles [1]. Some tools like RGB, and others YUV, so
> the authors happily selected the palette of their choice and never even
> considered building in functions for doing conversion. And then I am not even
> talking about the RGB/BGR mess.
The original V4L API was *implemented* first on TV grabber cards, but
was certainy written with other video equipment in mind. I remember I
looked at the API with the sgi stuff in mind, and considered it quite
sane.
Erik
-- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: J.A.K.Mouw@its.tudelft.nl WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:24 EST