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

[Michael Niedermayer]

On Sun, Mar 15, 2009 at 03:54:00PM +0100, Stefano Sabatini wrote:
> On date Sunday 2009-03-15 02:13:17 +0100, Michael Niedermayer encoded:
> > On Sat, Mar 14, 2009 at 11:54:35PM +0100, Stefano Sabatini wrote:
> > > Hi all, as in subject.
> > > 
> > > BTW, since libavutil API is in flux state due to its major bump, what
> > > about to avoid the ifver < 51 and simply remove the ifdeffed
> > > macros?
> > 
> > agree no ifdef needed
> > also patches ok if you tested them
> 
> Sorry, for some strange reason the previous patches seemed to work, but
> they don't.
> 
> Attached series has been tested, in the sense that it passes
> regressions tests, I'm somehow unsure for what regards the RGB5X5
> stuff since previously we had just the RGB565 case to manage in both
> LE and BE systems, maybe something has to be changed in libswscale.
> 
> Change in imgconvert.c looks necessary, otherwise we can't even select
> rgb5X5[bl]e.
[...]

> @@ -90,10 +86,8 @@
>      PIX_FMT_RGB4_BYTE, ///< packed RGB 1:2:1,  8bpp, (msb)1R 2G 1B(lsb)
>      PIX_FMT_NV12,      ///< planar YUV 4:2:0, 12bpp, 1 plane for Y and 1 for UV
>      PIX_FMT_NV21,      ///< as above, but U and V bytes are swapped
> -
>      PIX_FMT_RGB32_1,   ///< packed RGB 8:8:8, 32bpp, (msb)8R 8G 8B 8A(lsb), in CPU endianness
>      PIX_FMT_BGR32_1,   ///< packed RGB 8:8:8, 32bpp, (msb)8B 8G 8R 8A(lsb), in CPU endianness
> -
>      PIX_FMT_GRAY16BE,  ///<        Y        , 16bpp, big-endian
>      PIX_FMT_GRAY16LE,  ///<        Y        , 16bpp, little-endian
>      PIX_FMT_YUV440P,   ///< planar YUV 4:4:0 (1 Cr & Cb sample per 1x2 Y samples)

cosmetic


> @@ -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


[...]

> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090315/3cf078ab/attachment.pgp>