Re[4]: [XviD-devel] image pre-processing

[Milan Cutka]

>> maybe we could make a lib with the whole stuff, and
>> ffdshow/ffvfw/xvid will use it ? i dunno is you can use COM in
>> linux :-/

I'm constantly trying to have image filters in ffdshow separated from
other code and it shouldn't be too difficult to create shared library.

CL> Not really, but that's not a big problem, we can always make a shared lib
CL> out of everything once there is some kind of API. Btw. COM is really
CL> fast enough for pre-processing etc.? Didn't know that...

AFAIK COM interfaces are just arrays of function pointers. There
shouldn't be any big overhead by using them.

>> gruel, if you know how to make something portable, can you explain ?

CL> I don't know anything about Windows programming, so I guess I don't know
CL> anything at this point. I guess the most important thing would be to have
CL> separate source files and a fixed API for all functions. The rest can be
CL> done in individual parts. I guess for all UN*Xes, a shared lib would be
CL> the simplest thing. 

I agree, the most important thing would be the API. Then I could add
functions interfacing image processing routines in ffdshow through
this API.

Many image processing routines in ffdshow are written using inline
assembly in C++ source files with MSVC syntax. To have them portable
it would be required to separate them to asm files and use NASM to
compile. BTW I'm not very good in MMX optimizing and anyone with
greater experiences could optimize my filters much more.

Few filters have C++ or C equivalents, but they are mostly outdated.
For this C versions portability to other platforms would be important
too. Then I often assume 32 bit integers and Intel bytes ordering. For
example mplayer image filters are much more portable.