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 yes but i haven't yet time to migrate to new interface (registry/drivers.c changes).
> 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) afaik there were no usefull changes since you synced last time. > 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. as you also know, the old loader/* stuff was messy and i had to mess it more to be usable for mplayer. i'll migrate our code and sync to new driver.c/registry.c/afl.c once. > 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) ok i'll look at it. this is why i suggested a common, general lib for this stuff, with a single cvs. same way as we did with libavcodec (earlier we had modified copy of libavcodec in mplayer tree and sync code to and backware with ffmpeg cvs. it was overkill...) it will be a bit more work for users (they had to download libwin32codecs from different place) but it would solve syncing problems. > 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 - of course, this is what we also want. but it requires an interface suitable for all users (avifile,mplayer etc) > 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) yes > (e.g. avifile tree always contains unmodified sources of other CVS trees) what is it good for? > But I'm not sure if we really want just loader dir shared! i said: libwin32codecs. so not only loader, including vfw/acm/dshow and quicktime (as soon we get it working) interfaces with a common if. note, it won't be easy, as some dll needs some hacking and we should introduce some config file where we/users can easily add new dlls or finetune options. i don't like the idea of hardcoded stuff you did. > 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 - i don't like the word 'plugin'... btw you mean including other codecs, like libavcodec natiev stuff divx4linux etc in this lib? then we'll go nowhere :( i don't know much about xine, but afaik most projects just uses the win32-related code of avifile and at least we don't want to use more. > 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 ok > I guess interface in divx4 encore/decore style is all we want. maybe. i think you want to step too big. we don't want more, than loader and related interfaces being in a common library (static/dynamic one, preferred way is optional). i think, at first step it's enough to keep current function names (so different stuff for acm/vfw/dshow) until we design and accept in a new common encoding/decoding api. i think (and know:)) all players using win32 stuff at this level has its own codec plugin interface and they don't want to change or make wrappers to another plugin if. they just want to eliminate loader/ dir and it's maintance and do it in a common CVS so every player using it could benefit, and no syncing / backporting problems. for example, this way you shouldn't keep sync with our cvs and vice versa. > PS: > It's good idea to use group replay when the original author of the > thread ask for that. yes but it requires cc: implementation in mailer3 first :) > 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... at time you started it, we had no much code toa dd (you didn't wanted to add DCT stuff, and we had not colorspace/scaling stuff yet). do you still want to keep it as a shared library? A'rpi / Astral & ESP-team -- mailto:[EMAIL PROTECTED] http://esp-team.scene.hu _______________________________________________ Avifile mailing list [EMAIL PROTECTED] http://prak.org/mailman/listinfo/avifile
