Hi Zdenek, I'm also CC'ing xine-devel, this is an interesting subject for everybody...
Zdenek Kabelac wrote: > On Sat, Nov 17, 2001 at 05:52:07PM +0200, Arpi wrote: >>What about creating $SUBJ ? >>Ie. making a library containing code for loading and running acm/vfw/dshow >>/quicktime codecs with a common C interface? >> >>Maybe someone of mplayer team could do that, but it has no sense unless you >>begin to use it and help maintaining it. >> > > > Well I've told you quite a few times - mplayer team basicaly seems to maintain > it's own version of this library and only copies some different stuff win32.c > (which I've tried to sync a little bit more with your tree as you might > have noticed) - I'm not receiving any patches from you (yes I can check them > in your tree - but as I said also many times - > you are supposed to send your patches to me and I'll happily apply - if > they are an improvement or are moving this code into the right direction) > > I'm not that happy when I have to track your updates and moreover > check some extra code you are placing in it to include headers from other > parts of mplayer and morever your code seems to be dependent on some > exported variables which I've hopefully replaced with something more > thread safe. > > So now after I've said this which is just a pure comment of the current > situation (btw I've commited some more updates to win32.c so few > more codecs works (not sure about the names but bt20 & peagasus mjpeg I think > - I'll put some newer win32 dll set with 'decorations :)' later this week.. > and registry.c has a cleaner fix for Mszh & ZLib - not yet good but better > then the previous one) > > I'm quite open to the idea of using libwin32 - but I've one simple > condition - CODE HAS TO BE USABLE WITHOUT A SINGLE CODE LINE MODIFICATION - > I do not like the idea that avifile, xine, mplayer will have it's own > trees where some bugs are being silently fixed (so we could tell our users > - see our player doesn't crash) > (e.g. avifile tree always contains unmodified sources of other CVS trees) Unfortunately we are doing the same at xine, and i don't like it either. Our w32 code was pretty outdated until about 3 weeks ago. I updated the loader and included the DirectShow stuff (converting it to C, if you want details there was some discussion on xine-devel about C++ last week). I also found some bits of dependency on avifile like the vector template. I think avifile should be the official maintaineer of this code. You did most of the work and track most of the bugs. If we could agree on a common code base (without a sigle line modification, as you said) I would happily send you any bugfix we do at xine. We are at feature freeze stage in xine (preparing for 1.0) and i don't want any radical change to w32 plugin now. I see that you will also avoid modification of architecture until 0.6 release. > But I'm not sure if we really want just loader dir shared! > I've lately spend quite a lot of time to fix also compression part for > dll's - I think what we really want is - pluggin for encoder/decoder - > > situation now: > - mplayer - library usage only > - avifile, xine - already modularized & using plugin. > > Problem with libraries is - you need them at loadtime to be able to use them > > What I'd like to see is - I guess we have all agreed on /usr/lib/win32 > - so how about /usr/lib/media > > with simply defined codec style - together with config file in /etc/media > > I guess interface in divx4 encore/decore style is all we want. As my personal opinion, a shared library for all win32 codecs would be fine. I would like to hear comments from other xine developers though. Please also note that, at least from xine side, this is material for the next year. Regards, Miguel Freitas _______________________________________________ Avifile mailing list [EMAIL PROTECTED] http://prak.org/mailman/listinfo/avifile
