[FFmpeg-devel] [PATCH] Define endian variant for PIX_FMT_RGB/BGR_5X5
Michael Niedermayer
michaelni
Sun Mar 15 20:29:18 CET 2009
On Sun, Mar 15, 2009 at 07:57:05PM +0100, Stefano Sabatini wrote:
> 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?).
ive also thought about using the 2nd lest sig bit for rgb vs bgr,
maybe as we are already breaking ABI that could be done too.
>
> 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?
yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- 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/8950a5cf/attachment.pgp>
More information about the ffmpeg-devel
mailing list