Hi, > > Yes, it is. Eugene's comments says "Sh*t. MSVC++ and g++ use different > > methods of storing vtables." and manually implements the directshow api > > in plain C using pointers to functions. Nice work indeed. ;) > > Yes I've already spend a lot of time to make it so easily portable to C > as this was my original goal as well - but as Arpi just wanted > faster solution I've prepared simplier and easier one... it means you will replace C++ code with this C version ? sound good... ;)
> > I manually converted a lot of code, resolving inheritance, vector > > templates and some other stuff that took a lot of work. But technically > > speaking it is not big deal. > > yeah it's not - expect I want to have certain beauty in the code so > I do not want to just replace :: with _ :) I think it's more. I also did ::->_ but didn't worked ;) > As I mentined elsewhere - would be plugins in the encore/decore style > enough for you ? maybe. i think it needs codecs conf file parser stuff inside libwin32* then. i prefer keeping the current interfaces until we design a new one. just moving common code to a lib. it's easy to do and doesn't require much coding on your or our side. > (As I do not see any single point in compiling this 3 times for > avifile, mplayer, xine) but it doesn't require new api. > Anyway maybe we should really consider to create some standard here yes, later. i also have plans, mostly from mplayer's dec_*.c stuff. but it depends too lot on mplayer architecture and less threadsafe so you won't like it. > I've proposed libmmxnow - but mplayer seems to be creating their > own compiler-time depended stuff - I do not have really that much time we don't like runtime stuff (plugins, cpu detect etc), as you know :) A'rpi / Astral & ESP-team -- mailto:[EMAIL PROTECTED] http://esp-team.scene.hu _______________________________________________ Avifile mailing list [EMAIL PROTECTED] http://prak.org/mailman/listinfo/avifile
