On Mon, Nov 19, 2001 at 04:12:31PM +0200, Arpi wrote:
> Hi,
>
> > 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).
ok - there might be some problem I've not noticed yet in avifile usage
so if you will find some let me know (patches are always welcomed)
> > 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.
I think I'll have to add vfw stuff as well in out code and again
reinterface VideoCodec.cpp :(
> 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...)
yes having private modification in local tree is a bad idea especialy
when you have write access to ffmpeg :)
> > 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)
>
>
> > (e.g. avifile tree always contains unmodified sources of other CVS trees)
> what is it good for?
Well sometimes users get angry when they download a package and will
figure out they are missing some important other packages
(really noone reads manuals :) you know that :)
>
> > 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.
waiting for that...
> 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.
well M$ has something like .inf files for codecs - I don't know
why we could not get agreed on them
> > 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'...
Well for those who don't like this word - plugin is 'shared library'
linked to program at runtime when it's needed - is it better know :)
> btw you mean including other codecs, like libavcodec natiev stuff divx4linux
> etc in this lib? then we'll go nowhere :(
No I just mean plugin for libwin32 now - you simply call initialization
and you will get encoded/decoded images - I'm not sure how many
different interfaces you could 'invent' here....
I guess the decore/encore (which is basicaly similar to win32.dll)
is the thing everyone can use
> 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.
I don't see the point here - you have to call these functions:
init
setbpp
decode
I can't see anyproblem with using decore style here -
of course there will have to be many parameter that decore doesn't have
(like setting prefered list of decoderes for given codec - something you
could extract for your config and sent to decore interface -
or you could explicitly ask for given codec and try them in the
specified order yourself)
>
> i think you want to step too big.
maybe - but we could at least talk about perspectives here.
if the mplayer would be organized differently with respect to full thread
safety there wouldn't be probably even the reason for two slightly projects ;)
> we don't want more, than loader and related interfaces being in a common
> library (static/dynamic one, preferred way is optional).
You are loading DivX library - so why not libwin32 for decoding all
win.dll codecs ?
The reason for runtime loaded is - as I said simple - you do not
need to have library installed on the system while you are
building or distributing binary of player (I'll leave comments from
some texts in DOCS dir from `unnamed' author for myself here :))
> 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
Well you have created interface for DivX4 - so why not do the same
for win32 - it will have aproximately same effect on avifile code....
> > 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 :)
that's why mutt has been created :)
>
> > 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).
not that I didn't wanted - it's been just to early for this stuff
(and still probably is as I didn't have much time to look at his part)
> do you still want to keep it as a shared library?
I'm not quite sure what you have against shared libraries ?
If the code is properly written - you could use all registers in the
subroutine if you would use stack and push/pop bx
there will be nearly zero speed gain if you would have linked
it staticaly
Could you enlightenm me what would be the advantage of building
this library staticaly ?
--
.''`. 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
