On Wed, 6 Sep 2006 11:52:16 -0400
"Timothy Miller" <[EMAIL PROTECTED]> wrote:
> OGA is designed to deal exclusively with 32-bit ARGB pixels. But we
> would like to support YUV formats as well. It seems to me that the
> best place to put the conversion is in the host interface when the
> data comes into the chip. As you write (or DMA) YUV data into the
> graphics memory, it gets converted automatically to RGB before being
> stored. Thus, when you want to scale it into a window, the GPU is
> working only on RGB data, as is the video output.
Little question here. I guess to be able to convert YUV
on the fly to RGB in the interface, you have to get all
3 bytes at the same time. But the traditional way to optain
YUV data (in video applications) is that you get 3 so called
planes. Ie one memory region (or image) per "colour". So,
the PCI interface would need a lot of cache to store a
complete Y-plane and U-plane until the V-plane arrives.
Also an issue here is the subsampling, ie that the U and V
planes are down scaled by a factor two in the width (4:2:2)
or in widht and height (4:2:0). This scaling has to be
inverted before YUV->RGB conversion.
Though uncommon, it might be a good idea if strange
subsampling formats (like those seen with DV files)
could be supported too (using a 2/3 down scaling and
stuff like that)
Attila Kinali
--
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
-- reeler in +kaosu
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
