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

[Stefano Sabatini]

On date Thursday 2010-05-27 00:59:21 +0200, Stefano Sabatini wrote:
> On date Wednesday 2010-05-26 00:49:54 +0200, Stefano Sabatini wrote:
> > On date Sunday 2010-05-23 04:30:44 +0200, Michael Niedermayer wrote:
> > > On Fri, May 21, 2010 at 12:19:10AM +0200, Stefano Sabatini wrote:
> > > > Hi all, this follows a thread from ffmpeg-devel:
> > > > http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/109054/focus=109394
> > > > 
> > > > I proposed these names:
> > > > B4BY (bgr4_byte) Packed BGR 1:2:1,  8bpp, (msb)1B 2G 1R(lsb)
> > > > R4BY (rgb4_byte) Packed RGB 1:2:1,  8bpp, (msb)1R 2G 1B(lsb)
> > > > 
> > > > Other idea:
> > > > bgr4_byte => B[1][2][1]
> > > > rgb4_byte => R[1][2][1]
> > > > 
> > > 
> > > > Note that I'm very satisfied with these names, maybe someone can find
> > > > a better scheme.
> > > > 
> > > > What do you think?
> > > 
> > > i think you are missin a "not" in your sentance
> > 
> > Yes indeed.
> >  
> > > and iam not sure abut the fourccs here, this format is simply inefficient
> > > to store 4bit rgb, is it used in the wild?
> > 
> > I have not the faintest idea, and I couldn't even manage to understand
> > who introduced it, since it exists since the night of time of FFmpeg.
> > 
> > > if not (its just for ffmpegs test lavfi test system we can just pick any
> > > random fourcc and treat it like some ffmpeg internal thing)
> > > either of your choices would do for that
> > 
> > My problem is that I need to *write* such a format in NUT, so I need a
> > codec for that. Also to add such a tag shouldn't hurt anyway. If you
> > have an idea for avoiding to define a tag for it and still be able to
> > store such a format in NUT please tell (well an idea would be to make
> > possible to define the codec tag), as for me I prefer to add these two
> > rather than add exceptions/special cases to the FFmpeg code.
> > 
> > Patch updated, regards.
> 
> > Index: docs/nut4cc.txt
> > ===================================================================
> > --- docs/nut4cc.txt	(revision 669)
> > +++ docs/nut4cc.txt	(working copy)
> > @@ -96,6 +96,8 @@
> >  B0W1    black/white bitstream, 1bpp, 1 is white, 0 is black, in each byte pixels are ordered from the msb to the lsb [NOT in AVI]
> >  BGR[4]  Packed BGR 1:2:1 bitstream,  4bpp, (msb)1B 2G 1R(lsb), a byte contains two pixels, the first pixel in the byte is the one composed by the 4 msb bits [NOT in AVI]
> >  RGB[4]  Packed RGB 1:2:1 bitstream,  4bpp, (msb)1R 2G 1B(lsb), a byte contains two pixels, the first pixel in the byte is the one composed by the 4 msb bits [NOT in AVI]
> > +B4BY    Packed BGR 1:2:1,  8bpp, (msb)4X 1B 2G 1R(lsb), one pixel per byte, the 4 most significant bits are ignored
> > +R4BY    Packed RGB 1:2:1,  8bpp, (msb)4X 1R 2G 1B(lsb), one pixel per byte, the 4 most significant bits are ignored
> >  BGR[8]  Packed RGB 3:3:2,  8bpp, (msb)2B 3G 3R(lsb) [NOT in AVI]
> >  RGB[8]  Packed RGB 3:3:2,  8bpp, (msb)2R 3G 3B(lsb) [NOT in AVI]
> >  RGB[48] Packed RGB 16:16:16, 48bpp, 16R, 16G, 16B, the 2-byte value for each R/G/B component is stored as little-endian [NOT in AVI]
> 
> 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
> 
> Second byte: the number of bytes of a pixel
> Third byte: a decimal composed by two digits, the first is the number
> of bits of the first component, the second is the number of bits of
> the second component
> Fourth byte: a decimal composed by two digits, the first is the number
> of bits of the third component, the second is the number of bits of
> the fourth component
> 
> If the order of pixels is inverted then the bytes have to be read
> as big-endian.
> 
> If the format has only three components, then the first component is
> supposed to be composed of the non-used pixels.
> 
> According to this scheme:
> bgr4_byte -> B1[41][21]
> rgb4_byte -> R1[41][21]
> rgb444be  -> [44][44]2R
> rgb444le  -> R2[44][44]
> bgr444be  -> [44][44]2B
> bgr444le  -> B2[44][44]

Ehm... s/R/r/, s/B/b/:
bgr4_byte -> b1[41][21]
rgb4_byte -> r1[41][21]
rgb444be  -> [44][44]2r
rgb444le  -> r2[44][44]
bgr444be  -> [44][44]2b
bgr444le  -> b2[44][44]

Regards.