Re: Conversion library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 01-Jun-01 Ben Bridgwater wrote:
> "Nemosoft Unv." wrote:
> 
>> On 31-May-01 Ben Bridgwater wrote:
> Not really - just add flags to indicate what processor attributes (MMX
> etc) each converter needs, order the accelerated converters before the
> others, then scan the list for the first matching one suported by the
> actual processor attributes.
> 
> I'm open to suggestion.

I would simply replace the function pointer with the most optimized
function during initialization; that way the logic in GetConvertor can be
kept really simple (otherwise, you´d end up with a different GetConvertor on
each platform!).

Some pseudo code might clarify:

library_init()
{
   /* All C functions */
   register_convertor(YUV420, RGB,    yuv420_rgb_C);
   register_convertor(RGB,    YUV420, rgb_yuv420_C);
   register_convertor(YUYV,   RGB,    yuyv_rgb_C);

   /* some assembly functions */
   register_convertor(YUV420, RGB,    yuv420_rgb_x86);
   register_convertor(RGB,    YUV420, rbg_yuv420_x86);
   
   /* MMX optimized */
   register_convertor(YUV420, RGB,    yuv420_rgb_x86_mmx);
}

get_convertor(int from, int to)
{
   .. search list for the combination ...
   while (conv)
      if (conv->from == from && conv->to == to)
        return conv->function;
}

register_convertor would replace the function in it´s list, and no additional
logic would need to be present in get_convertor at all. Adding a convertor
would simply be a matter of implementing it, and adding it to the end of
library_init. Simple.


> I guess I *could* delete the "static" ;-)
> 
> If you're thinking of converter chains, then better just to guarantee
> converters to/from a couple of intermendiate formats such as RGB24 or
> I420.

I´m rather thinking about a program that´s being confronted with a
combination that´s not available, and wants to select a good alternative.
But we´ll see if this really will be a problem.

> For these formats "to" is useful for X display, and "from" is useful for
> V4L and AVI. You're right that's the way it's implemented - as a bunch
> of individual converters that cover the common XImage formats, but the
> point is that the app can just do a dumb "descriptor.format = PackedRGB,
> descriptor.r/g/b masks = XImage.r/g/b masks", then ask for a converter
> to/from that format.

So you have a ´general purpose´ convertor that can convert to almost
anything (at the price of being slow, presumably)?

 - Nemosoft

-----------------------------------------------------------------------------
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: never        IRC: nemosoft      IscaBBS (bbs.isca.uiowa.edu): Nemosoft
                        >> Never mind the daylight << 





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux