On Sat, Nov 17, 2001 at 05:52:07PM +0200, Arpi wrote:
> Hi,
>
> 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)
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.
There could be installed all codecs - again I'll repeat here - standard
libraries can't be used as some codecs may not be distributable legaly
in most of the distribution in binary form.
-- so I'd like to expect some comments here --
PS:
It's good idea to use group replay when the original author of the
thread ask for that.
And I've not started libmmxnow just to enjoy myself - so far no comments
from you about what would you like to see there or what should be modified or
handled differently...
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- Resistance is futile. You all will be packaged
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
