[NUT-devel] [RFC] FourCCs for rawvideo rgb4_byte / bgr4_byte

[Stefano Sabatini]

On date Wednesday 2010-06-02 14:34:15 +0200, Michael Niedermayer wrote:
> On Mon, May 31, 2010 at 06:17:00PM +0200, Stefano Sabatini wrote:
> > On date Friday 2010-05-28 03:23:38 +0200, Michael Niedermayer wrote:
> > > On Thu, May 27, 2010 at 12:14:24PM +0200, Stefano Sabatini wrote:
> > > > On date Thursday 2010-05-27 00:59:21 +0200, Stefano Sabatini wrote:
> > [...]
> > > > > I was almost committing, but since there are other formats I want to
> > > > > add support for, maybe someone can find out a scheme for all of them.
> > > > > 
> > > > > These are the format I want to add support for:
> > > > > bgr4_byte ->none
> > > > > rgb4_byte ->none
> > > > > rgb444be ->none
> > > > > rgb444le ->none
> > > > > bgr444be ->none
> > > > > bgr444le ->none
> > > > > 
> > > > > I propose this scheme.
> > > > > 
> > > > > First byte:
> > > > > b = BGR
> > > > > B = BGR+A
> > > > > r = RGB
> > > > > R = RGB+A
> > > > > a = ABGR
> > > > > A = ARGB
> > > 
> > > i dont like this at all, using upper/lower case to distinguish formats
> > > 
> > > following is much closer to the existing system:
> > > RGBA -> RBA[bits]
> > > ARGB -> ARB[bits]
> > > ABGR -> ABR[bits]
> > > BGRA -> BRA[bits]
> > 
> > This only works if all the components have the same amount of bits.
> > 
> > Anyway I don't mind if you want to use this scheme for the missing
> > formats:
> > rgb444be -> [16]BRA
> > rgb444le -> ARB[16]
> > bgr444be -> [16]RBA
> > bgr444le -> ABR[16]
> 
> the bits value should be 64 for 16bit per component, 32 for 8bpc

This would lead to:

rgb444be -> [16]BGR
rgb444le -> RGB[16]
bgr444be -> [16]BGR
bgr444le -> BGR[16]

note that rgb444/bgr444 does not use the A component, which is set to
0 or to 1 (check libavutil/pixfmt.h):

    PIX_FMT_RGB444BE,  ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb), big-endian, most significant bits to 0
    PIX_FMT_RGB444LE,  ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb), little-endian, most significant bits to 0
    PIX_FMT_BGR444BE,  ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb), big-endian, most significant bits to 1
    PIX_FMT_BGR444LE,  ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb), little-endian, most significant bits to 1

but that shouldn't be a problem, since I can't see a reason for which
it shouldn't just be ignored.
 
Of the four listed above two are already used:
RGB[16] Packed RGB 5:6:5, 16bpp, (msb)   5R 6G 5B(lsb), little-endian [NOT in AVI]
BGR[16] Packed BGR 5:6:5, 16bpp, (msb)   5B 6G 5R(lsb), little-endian [NOT in AVI]

That's why I proposed the other scheme, which would allow to define
without ambiguity also formats for which the number of bits per
component is different (but only works if bits_per_component <= 9).

Alternatively we could use lowcased characters:
rgb  -> RGB
bgr  -> BGR
rba  -> RGBA
arb  -> ARGB 
abr  -> ABGR

Check solution in attachment, regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: define-rgba-fourcc-scheme.patch
Type: text/x-diff
Size: 1798 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20100602/6951a9a1/attachment.patch>