[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: artsplug near final
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-06-23 9:53:14
[Download RAW message or body]

   Hi!

On Wed, Jun 21, 2000 at 12:10:30PM +0200, Martin Vogt wrote:
> > I can only second the CVS issue: if we don't have it there, chances are good
> > that most users will never even notice that there is mp3 support...
> >
> The point is:
> 
> * where we should put it.
> 
> I think we cannot put it in kde-multimedia, because the artsplug
> lib is linked against mpeglib and libtool does not support
> linking against not installed libraies.
> 
> This is the reason why artsplug is seperate from mpeglib because
> you must install mpeglib first.

I don't think this is an issue. For instance, I link libx11globalcomm against
the yet uninstalled libmcop, and treat it as aRts dynamically loaded module
in the CVS (see kdelibs/arts/x11). So this seems to work, which maybe relates
to the fact that KDE is always using a bleeding edge, special tuned libtool.

> * I have no CVS access

Well, if you would like to work on mpeglib in the CVS, getting one should
be no problem.

> * mpeglib will never work on some old Linux systems, libc based systems
>   maybe this is a point to consider.

This is true. The optimal mp3 codec would be a real small source, non
dependant on any further libs, directly integrated into aRts (e.g. can
decompress as float directly, no float->int->float conversions), maybe
non threaded. One could achieve something like this taking the xmms source
and porting the codec to aRts.

So if somebody would write something like this, it would be the optimal
solution. However, if not, I'd rather have something which works nicely
for almost everybody than nothing at all.

> > My only concern currently is how far we'll get in the future (> KDE2.0) when
> > we keep the strict seperation between aRts and standalone mpeglib code.
> > Especially once we start extending aRts in the direction of more modularity
> > regarding decoding and playing, video codecs, threading support, ...
> >
> Then split/remove/delete mpeglib. 
> 
> I think it will take some time until arts supports all this.
> But then you can rip the codecs from mpeglib.
>                      
> Or choose other codecs. 
>            
> mpeglib and the "bridge" artsplug works now. If there is something
> better in the future, simply remove the old things.
> 
> Another way would be to "migrate" mpeglib slowly to new arts interfaces.
> (For example if arts supports video frames, use this interfaces
> instead of mpeglibs)
> 
> If it supports inputStream use them in mpeglib.
> 
> and so on.
> 
> For KDE 2.0 I think to keep it how it works now.   
>  
> > Still, we can try this approach, and if it doesn't work, we'll try something
> > else. So far, I am quite happy with the interoperability that is available
> > now between mpeglib and aRts.
> > 
>          
> It supports the kmedia2 interface, nothing more was planned for KDE 2.0

Yes, this sounds about what I had in mind. Certainly, for KDE2.0 we'll keep
things kmedia2 based, as they are. And as your ideas for the time beyond that
are as flexible as mine, there is probably nothing to worry about ... ;)

> > So after everybody telling: "mpeglib should be in the CVS", would anybody
> > like to put it there, maintain it there, update new versions, fix bugs, make
> > sure that it integrates with the build system and such? Martin? Somebody else?
> >
> Hm.
> Im currently unsure. mpeglib is used by two other developers
> (and maybe more I now nothing about)

Well, there are two basic ways for making external versions: one is to develop
on an external version only, and merge the changes every so often into the CVS.

The other is to keep the "official" version inside the CVS, and to release new
external versions from there. This is pretty much what I do with the aRts
versions.

> Some bugs are "unfixable", like the old libc/thread problem.
> It should run on FreeBSD, but I had no success reports for a
> long time.
> The interlibrary dependencies...
>
> And of course I have no CVS access.
> 
> Before we put it in, we should clear these things. 
> And we should clear which codecs should be in.
> Should the yaf-* part be included, should we move
> ogg/vorbis into the lib, etc...
> 
> For examples vob/ac3 is very experimental,I can already
> hear the user cry, that they cannot play dvd, because we
> cannot include DeCss...

I think we should only include codecs under three conditions:

(1) they don't cause compile problems and run everywhere where they
    (maybe conditionally) compile
(2) there are applications in kde-multimedia which know how to use them
(3) they are reasonable stable and bugfree

I'd rather have fewer codecs which are stable, than lots of stuff which
doesn't work as it should.

> Mpeglib runs on alpha but (not yet) on Sun etc..
> Its a rather big library and KDE 2.0 is already in freeze.
> 
> Maybe we should include it, but before that I would like to
> have more people to test it, if it _really_ works for them.

The easy way to get testers is to put it into the CVS and wait for bug
reports. The not-so-easy way is to make an announcement (probably not here
but on kde-devel or something like this), and hope you'll get enough testers
to do proper verification.

The change gets even more risky the later we do it. The earlier it is in, the
more beta tests it gets. If we include it after the last beta release (a
really bad idea), it's probably guaranteed that it breaks for some people
in the final version.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]