[MPlayer-dev-eng] Packed YUV -> RGB Conversion; Speed Freak

[Gabriel Gerhardsson]

Hi Mike

On Fri, 2002-03-01 at 06:17, Mike Melanson wrote:
> Hi team,
> 	Look out, I've been RTFS'ing again, and now I have more 
> questions. I recently discovered the postprocessing unit. After studying
> it for awhile, it occurred to me that the yuv2rgb module is strictly 
> YV12->RGB. Some modules hack the input to allow I420/IYUV data, but the
> converter only handles planar YUV data. But there aren't any converters
> for packed YUV formats -> RGB, correct? I might take a stab at writing one
> if no one else is interested.
> 
> 	Speed freak question: I've recently come to understand that when
> outputting BGR32 data, it's useful to transfer full 32-bit pixels, rather
> than 4 individual bytes. In rendering BGR24 data, would it be plausible
> to have pre-rendered pixel values as 32-bit integers and then transfer
> them to the output image, but only advance the pixel pointer by 3 bytes
> each time? Like so:
> 
>   unsigned char *out_ptr;
>   unsigned int pixel1, pixel2;
>   (unsigned int *)out_ptr = pixel1;
>   out_ptr += 3;
>   (unsigned int *)out_ptr = pixel2;
> 
> Or would this net a performance hit because of not transferring data on
> neat 32-bit memory boundaries? No big deal, just curious.

I believe that's how it works. The speedup comes from being able to move
the int with one command to the memory. If it's not alligned on 32-bit
boundaries it will have to split up the transfer in several smaller
ones.
This is why BGRA exists.

Take care
/Gabriel