[FFmpeg-devel] [PATCH 3/3] avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats

[Michael Niedermayer]

On Fri, Feb 06, 2015 at 09:49:17PM +0100, wm4 wrote:
> On Fri,  6 Feb 2015 20:57:50 +0100
> Michael Niedermayer <michaelni at gmx.at> wrote:
> 
> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > ---
> >  libavutil/pixfmt.h |    8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index cbcccb2..cee5f2c 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -141,10 +141,10 @@ enum AVPixelFormat {
> >  #endif
> >      AV_PIX_FMT_DXVA2_VLD,    ///< HW decoding through DXVA2, Picture.data[3] contains a LPDIRECT3DSURFACE9 pointer
> >  
> > -    AV_PIX_FMT_RGB444LE,  ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb), little-endian, most significant bits to 0
> > -    AV_PIX_FMT_RGB444BE,  ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb), big-endian, most significant bits to 0
> > -    AV_PIX_FMT_BGR444LE,  ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb), little-endian, most significant bits to 1
> > -    AV_PIX_FMT_BGR444BE,  ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb), big-endian, most significant bits to 1
> > +    AV_PIX_FMT_RGB444LE,  ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G 4B(lsb), little-endian, most significant bits to 0
> > +    AV_PIX_FMT_RGB444BE,  ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G 4B(lsb), big-endian, most significant bits to 0
> > +    AV_PIX_FMT_BGR444LE,  ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G 4R(lsb), little-endian, most significant bits to 1
> > +    AV_PIX_FMT_BGR444BE,  ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G 4R(lsb), big-endian, most significant bits to 1
> >      AV_PIX_FMT_YA8,       ///< 8bit gray, 8bit alpha
> >  
> >      AV_PIX_FMT_Y400A = AV_PIX_FMT_YA8, ///< alias for AV_PIX_FMT_YA8
> 
> Doesn't explain what "u" means. Also,

fixed


> what does it mean by "most
> significant bits to 1"?

i think this ended up there by copy and paste, removed

applied

thanks

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150207/8c7c1535/attachment.asc>