Hi Patrick,
You are correct, at the output of yuv2rgb inlines each component is indeed 16-bit wide, but because the currently supported pixel formats are all 8-bit wide, all component values in the conversion pipeline will take up to 8-bit (in a 16-bit wide container). I started working on adding support for 10-bit formats and will be doing this in stages. I just finished adding conversions to/from 10bit YUV format (aka v210), and I am currently fixing a few conversion bugs here and there. If you wish to test it, checkout the SVN branch at
http://pixfc-sse.googlecode.com/svn/branches/add-10bit . The next step is to add support for 10-bit RGB.
And yes, the macro "situation" makes it quite hard to follow what's going on inside pixfc. I m planning to write up a page detailing how to dig into the code, but essentially, you start with a conversion function in conversion_routines_from_xxx.c which is defined using a single macro, then go to the definition of that macro and find out which conversion recipe is used (called xxxx_TO_yyyy_RECIPE). The conversion recipes can be found in yuv_conversion_recipes.h and rgb_conversion_recipes.h. They contain the core of the conversion code and calls the correct inline functions to do the job, usually broken up into the following blocks: unpacking -> up/downsampling -> conversion -> packing. Between each of these blocks, components are all 16-bit wide, but currently only use 8-bit as explained above.
Hope this helps.
Cheers,
Frank