[FFmpeg-devel] [PATCH] Define endian variant for PIX_FMT_RGB/BGR_5X5

[Stefano Sabatini]

On date Sunday 2009-03-15 19:24:03 +0100, Michael Niedermayer encoded:
> On Sun, Mar 15, 2009 at 03:54:00PM +0100, Stefano Sabatini wrote:
[...]
> > @@ -109,6 +103,17 @@
> >      PIX_FMT_VAAPI_MOCO, ///< HW acceleration through VA API at motion compensation entry-point, Picture.data[3] contains a vaapi_render_state struct which contains macroblocks as well as various fields extracted from headers
> >      PIX_FMT_VAAPI_IDCT, ///< HW acceleration through VA API at IDCT entry-point, Picture.data[3] contains a vaapi_render_state struct which contains fields extracted from headers
> >      PIX_FMT_VAAPI_VLD,  ///< HW decoding through VA API, Picture.data[3] contains a vaapi_render_state struct which contains the bitstream of the slices as well as various fields extracted from headers
> > +
> > +    PIX_FMT_RGB565BE,  ///< packed RGB 5:6:5, 16bpp, (msb)   5R 6G 5B(lsb), big-endian
> > +    PIX_FMT_RGB565LE,  ///< packed RGB 5:6:5, 16bpp, (msb)   5R 6G 5B(lsb), little-endian
> > +    PIX_FMT_RGB555BE,  ///< packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), big-endian, most significant bit to 0
> > +    PIX_FMT_RGB555LE,  ///< packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), little-endian, most significant bit to 0
> > +
> > +    PIX_FMT_BGR565BE,  ///< packed BGR 5:6:5, 16bpp, (msb)   5B 6G 5R(lsb), big-endian
> > +    PIX_FMT_BGR565LE,  ///< packed BGR 5:6:5, 16bpp, (msb)   5B 6G 5R(lsb), little-endian
> > +    PIX_FMT_BGR555BE,  ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), big-endian, most significant bit to 1
> > +    PIX_FMT_BGR555LE,  ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), little-endian, most significant bit to 1
> > +
> >      PIX_FMT_NB,        ///< number of pixel formats, DO NOT USE THIS if you want to link with shared libav* because the number of formats might differ between versions
> 
> i suspect you violate the "note" above with that ordering

Indeed (also I'm not perfectly convinced that's a good idea, maybe
this is a requirement we could avoid using the PIX_FMT_BE in
pixdesc?). 

Fixed locally.

> [...]
> 
> > Index: ffmpeg/tests/libav.regression.ref
> > ===================================================================
> > --- ffmpeg.orig/tests/libav.regression.ref	2009-03-15 15:28:06.000000000 +0100
> > +++ ffmpeg/tests/libav.regression.ref	2009-03-15 15:28:13.000000000 +0100
> > @@ -124,10 +124,10 @@
> >  304128 ./tests/data/b-libav-bgr24.yuv
> >  7c1108633b0fef1aff5637fe70e74d0c *./tests/data/b-libav-rgb32.yuv
> >  304128 ./tests/data/b-libav-rgb32.yuv
> > -d86c3fa21db8b4eaf3efb66b7b245e46 *./tests/data/b-libav-rgb565.yuv
> > -304128 ./tests/data/b-libav-rgb565.yuv
> > -64d733888d3f17513383453fae238fdc *./tests/data/b-libav-rgb555.yuv
> > -304128 ./tests/data/b-libav-rgb555.yuv
> > +d86c3fa21db8b4eaf3efb66b7b245e46 *./tests/data/b-libav-rgb565le.yuv
> > +304128 ./tests/data/b-libav-rgb565le.yuv
> > +64d733888d3f17513383453fae238fdc *./tests/data/b-libav-rgb555le.yuv
> > +304128 ./tests/data/b-libav-rgb555le.yuv
> >  838958bb95a41057a18bbb647c39ba87 *./tests/data/b-libav-gray.yuv
> >  304128 ./tests/data/b-libav-gray.yuv
> >  c7c9d2b2926e1677c27bd7df89f53073 *./tests/data/b-libav-monow.yuv
> > Index: ffmpeg/tests/regression.sh
> > ===================================================================
> > --- ffmpeg.orig/tests/regression.sh	2009-03-15 14:56:06.000000000 +0100
> > +++ ffmpeg/tests/regression.sh	2009-03-15 14:56:13.000000000 +0100
> > @@ -639,7 +639,7 @@
> >  
> >  if [ -n "$do_pixfmt" ] ; then
> >  conversions="yuv420p yuv422p yuv444p yuyv422 yuv410p yuv411p yuvj420p \
> > -             yuvj422p yuvj444p rgb24 bgr24 rgb32 rgb565 rgb555 gray monow \
> > +             yuvj422p yuvj444p rgb24 bgr24 rgb32 rgb565le rgb555le gray monow \
> >               monob yuv440p yuvj440p"
> >  for pix_fmt in $conversions ; do
> >      file=${outfile}libav-${pix_fmt}.yuv
> 
> that wont work on BE-archs

Maybe we could make av_get_pix_fmt("rgb565") select the correct
variant according to the endianess of the system (for example:
avcodec_get_pix_fmt() looks for "rgb565", it's missing, so it tryies
again with "rgb565le"/"rgb565be").

Would be this acceptable?

Regards.
-- 
FFmpeg = Fundamental and Fierce Mega Pacific Elaborated Guru