[RFC] FourCCs for rawvideo rgb4_byte / bgr4_byte
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? Regards.
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 and iam not sure abut the fourccs here, this format is simply inefficient to store 4bit rgb, is it used in the wild? 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
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.
On Wed, May 26, 2010 at 12:49:54AM +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.
i probably added it to sws for playing with 4bit dithering
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.
nut4cc.txt | 2 ++ 1 file changed, 2 insertions(+) 6e19f1c1d96011a3c5ac6716f91f1040703604bb add-bgr4-rgb4-byte-codec-tags.patch
ya ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
On date Wednesday 2010-05-26 03:34:49 +0200, Michael Niedermayer wrote:
On Wed, May 26, 2010 at 12:49:54AM +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.
i probably added it to sws for playing with 4bit dithering
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.
nut4cc.txt | 2 ++ 1 file changed, 2 insertions(+) 6e19f1c1d96011a3c5ac6716f91f1040703604bb add-bgr4-rgb4-byte-codec-tags.patch
ya ok
Applied.
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.
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.
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"
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] "G" is always implicit, as its position is always assumed to be between "R" and "B". As for rgb_byte and bgr_byte we may use ad-hoc FourCCs: 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) Regards.
On date Monday 2010-05-31 18:17:00 +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]
"G" is always implicit, as its position is always assumed to be between "R" and "B".
As for rgb_byte and bgr_byte we may use ad-hoc FourCCs: 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)
Ping?
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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides
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.
On Wed, Jun 02, 2010 at 04:21:27PM +0200, Stefano Sabatini wrote:
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]
the value should be 12, its in line with rgb15 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
On date Thursday 2010-06-03 23:07:46 +0200, Michael Niedermayer wrote:
On Wed, Jun 02, 2010 at 04:21:27PM +0200, Stefano Sabatini wrote:
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]
the value should be 12, its in line with rgb15
Fixed, regards.
On Thu, Jun 03, 2010 at 11:58:44PM +0200, Stefano Sabatini wrote:
On date Thursday 2010-06-03 23:07:46 +0200, Michael Niedermayer wrote:
On Wed, Jun 02, 2010 at 04:21:27PM +0200, Stefano Sabatini wrote:
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]
the value should be 12, its in line with rgb15
Fixed, regards.
nut4cc.txt | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) c79d553780cdeec09c8e776854fffbcf11fb32fd define-rgba-fourcc-scheme.patch Index: docs/nut4cc.txt =================================================================== --- docs/nut4cc.txt (revision 669) +++ docs/nut4cc.txt (working copy) [...] +RGB[12] Packed RGB 4:4:4, 16bpp, (msb)4U 4R 4G 4B(lsb), little-endian, most significant bits of the most significant byte unused +[12]BGR Packed RGB 4:4:4, 16bpp, (msb)4U 4R 4G 4B(lsb), big-endian , most significant bits of the most significant byte unused +BGR[12] Packed BGR 4:4:4, 16bpp, (msb)4U 4B 4G 4R(lsb), little-endian, most significant bits of the most significant byte unused +[12]RGB Packed BGR 4:4:4, 16bpp, (msb)4U 4B 4G 4R(lsb), big-endian , most significant bits of the most significant byte unused
added this into the list where it belongs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
participants (2)
-
Michael Niedermayer -
Stefano Sabatini