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

List:       kde-multimedia
Subject:    Re: artsplug near final
From:       Martin Vogt <mvogt () rhrk ! uni-kl ! de>
Date:       2000-06-25 13:55:57
[Download RAW message or body]

> 
> 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 will look at it.
 
> > * 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.
>
no. forget this. too much gtk/gdk in the codec and its threaded as well.
Better start with the mp3 codec in mpeglib and remove the threads.
I think you cannot make multiple instances with this codec.

(the codecs in mpeglib are both not threaded, mpeglib is only a thread
starter) 
It starts for every codec a decode thread so that the users "main" programm
run as expected and can control the decode thread.


 
> 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.
>

yes, there should be not much libc system out there.

On most user desktops you will have glibc.
 
> 
> 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.
>
I like the idea of a new module "kdesupport-multimedia".

Advantages:
-----------
* I can start converting mpeglib into the KDE CVS build system without
  breaking the GUI frontends in kdemultimedia.
* If it really turns out, that its too buggy, not useable, 
  does not fit into the KDE 2.0 time frame,whatever
  we can drop the whole package and still break no GUI
  application.
* libc based distributions can drop the package and still
  have kscd and kmix etc.. included

Disavantage:
-----------
* cvs users need to add a new module

conclusion:

 I think we should have a new kdesupport-multimedia module.

But only after I have brushed up mpeglib to compile on the
typical distributions and tested it a bit more.


> 
> (1) they don't cause compile problems and run everywhere where they
>     (maybe conditionally) compile
then mpeg2dec and ac3dec are out.


> (2) there are applications in kde-multimedia which know how to use them
> (3) they are reasonable stable and bugfree
> 
ok, then I would say:

* ogg/vorbis (maybe we should use the 1.0 version if its out,a month ot so)
* wav
* mp3/mpeg I video.



> 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.
>
before we put it in CVSi, but after its nearly converted to the KDE CVS
system (admin dir etc) we should make an announcement, let them
test it, and if the respone is positive make a kdesupport-multimedia
module.
 
> 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.
> 
we should have it in beta3.
when is the release date for beta3?

regards,

Martin

_______________________________________________
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]