[NUT-devel] [RFC] FourCCs for rawvideo rgb4_byte / bgr4_byte
Stefano Sabatini
stefasab at gmail.com
Thu May 27 00:59:21 CEST 2010
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]
Regards.
More information about the NUT-devel
mailing list