> yesterday I tried to import directshow C sources to mplayer, not working
that would explain lowercased 'this' :)
> yet. you didn't converted ds_videodecoder/ds_audiodecoder, so i got them
I'll do proper port later to match the rest of the code - but I'll
first do some cleaning there and will think a little bit about the interface
on this side.
> Do you plan to convert these, or i should do some cleanup of xine's version?
yes - everything will be converted in such a way that C++ will be just
wrapping class.
> > I'd like to remove it (and do few other cleanups to remove dead code
> > and useless headers)
> I'll ask al3x. afaik he added for VP31, but it should be usefull for others
> too (i think, not sure).
>
> > What is necessary for qtx support ?
> What you #if 0'd. :)
> Mostly the tls_ linked list stuff.
> expTlsAlloc and so on.
Not sure about Tls - but CRICTIAL section is now garbage collectioned
(I'm quite currious if you will find any memory leak ;)
and I don't understand what's behind the NEW_CRIT...
> qtx codecs assumes some relations between tls pointers and something at
> FS: segment space. dunno the details, Eugene fixed it and sent patch.
Speaking about FS: - Xine developer has created somehow more advanced
LDT keeper - which will be probably ported - this will
also require some changes - but I guess it all could be hidden inside
the library...
> btw i must keep the wrappers, as libwin32.h and the lots of stuff included
> there does conflicts with other includes in mplayer. :(
> but it's my prob...
libwin32.h should be eliminated - passed structure will be pointers to
BITMAPINFOHEADER and other standard Win32 structure
(BTW wine/ have no __atribute__ for packing - they have been producing
somewhat incorrect sizeof result :)
> it's coding style so you'll rewrite it :), but in its current state it is
> working well and provides an array of codecs with all info parsed from
> the codecs.conf file. some things can be removed, mainly the native codec
> ids. it's enough to keep acm/vfw and dshow types, and maybe qtx in the
> future.
we will see - but I have some more needs
> like cram and huffyuv (their outfmt depends on input bitmapinfohdr).
> but on the other side, soem codecs provides false info at detection.
thats why there are workaround - when codes does something wrong - it's
fixed so the outside result shuold be always correct.
> i agree in that win32.c should be usually modified for new codecs.
> but codecs.conf is very usefull for _us_, developers, as we don't have to
> recompile program at every codec parameter modification to test.
Well I could probably save about 15 seconds this way :)
(in libs & plugins: make install)
> and easier for users too, they can upgrade codecs.conf, don't have to
> recompile player (unless it needs win32.c mods)
The point is - users are recompling player anyway :)
--
.''`. 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
