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:
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
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] [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam"