[xine-devel] Re: [Xmps-devel] Re: [livid-dev] Re: Linux-video-dev Mailinglist

[Andres S. <sa...@rp...>]

i think a project (not a ml, but an actual project or spec) of this 
nature is an excellent idea.  however, there are certain problems that
go along with this, depending upon how it is designed.  mostly, they
are legal in nature.

just how _would_ this be handled?  you could take the windows approach:
define an API, and have that API pass off video/audio streams to their
proper codecs.  for example, if i want to decode a divx file, supply
lib<whatever>'s API with the filename ("foo.avi"), and it will load
an avi decoding library.  windows does this by loading dlls, and having
them handle the decoding.  the nice thing about this approach is, you're
just defining the interface; implementations are in their own standard
libraries, you don't have to worry about their licenses.  there could
also be a nice callback system set up in this fashion; codecs register
themselves, so while your default OS/distro includes libfoo_decode.so
you can install libfoo_decode_faster.so, which registers itself w/
the standard video api for all .foo decode and encode requests.

this approach would suffer from "dll hell"; libraries would have to
be distributed, you'd have a multitude of codec implementations all
fighting with each other.

the other approach is to try to implement everything yourselves; if
i want to decode a .mpg (mpeg-1) file, lib<whatever> calls it's 
internal mpeg decoder.  this will supply a nice standardized
video library, and is the preferred method.  however, the legal issues
here are going to be huge.  assume one wants to decode/encode divx movies;
you could take the approach avifile takes, which is to use pieces of
wine, and load the win32 dll to handle it.  if the goal is to handle
multiple formats, there will probably be a lot of code borrowed from
projects with incompatibile licenses, not to mention non-free (speech)
dlls.  this would mean exclusion by folks like debian and the fsf;
without them, something would surely not be considered "standard",
at least not under linux.

anyways, forgive that rather long bit of rambling.  my question is,
how much would this library/API hope to accomplish?  is the goal
to simply provide an interface, or some kind of implementation as
well?


On Wed, Dec 06, 2000 at 04:47:27PM +0200, Pasi K?rkk?inen wrote:
> On Tue, 5 Dec 2000, Dirk Farin wrote:
> 
> >
> > Hello,
> >
> > > As you all know, there are many separate video-player
> > > projects for Linux currently going on.
> >
> > And nobody wants to cancel his project, because everyone
> > thinks, his is the only one that's worth working on
> > (me too ;-) Every player so far has its pros and cons.
> > Mine for example lacks a GUI, others have nice looking
> > skin capable GUIs but don't work at all. So working
> > together could help us a lot.
> >
> 
> That's correct.
> 
> 
> > > I'm asking you, the developers, should we create
> > > something like 'linux-video-dev-mailinglist' ?
> >
> > I'd like to have a forum where the developers could
> > exchange experience and MMX/SSE optimized code, which
> > is tedious to write.
> >
> 
> 
> I think we can arrange that.
> 
> 
> > > The list could be used to discuss about common API's and things
> > > that are related to developing video-players and plugins for them for
> > > Linux (and maybe for other Unices as well..).
> >
> > This list could be too late for decoder development, but
> > I'm also very interested in encoder development. As there is
> > not much usable encoder code written, we could perhaps all
> > come together and congregate our efforts in this piece of
> > software. Writing good encoders is far more difficult than
> > writing decoders, as it requires more than doing some DCT
> > and some searching for motion vectors.
> >
> > I've initiated an MPEG-1/2/4 encoder project on sourceforge
> > (www.sourceforge.net/projects/mpegvideo) and hope that
> > the sourceforge team will finally achieve to give me CVS
> > access. There's nearly no code written yet, but I'll put
> > the old sources of my SAMPEG encoder there, which can then
> > be plundered.
> >
> 
> I just registered a project called "Open Media Interface" to the
> sourceforge. Let's see if they'll accept it.
> 
> That project is dedicated to creating a good api/plugin/codec-system for
> Linux (and other unices). Something like we have in windows..
> 
> By creating such a system, people could continue developing their
> own players (or editors or whatever) and have easy access to all supported
> fileformats. Both reading and writing to those formats.
> 
> Comments?
> 
> 
> - Pasi Kärkkäinen, pa...@ik...
> 
> 
> _______________________________________________
> Xmps-devel mailing list
> Xmp...@li...
> http://lists.sourceforge.net/mailman/listinfo/xmps-devel

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
        -- found in the .sig of Rob Riggs, rr...@te...