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

[Michael Niedermayer]

Hi

On Friday 01 March 2002 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.
the swscaler can convert from yuy2 -> bgr* but its not as fast as a non 
scaling converter ... allthough all important yuv based codecs support yv12 
so it doesnt matter imho

>
> 	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.
its faster on some cpus (x86, ...) and much slower on cpu which need aligned 
data (alpha, ...) they indeed read unaligned data via some alignment traps 
which are handled in the kernel

[...]

Michael