[PATCH] docs/nut4cc: Add floating point rawvideo support
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- docs/nut4cc.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/nut4cc.txt b/docs/nut4cc.txt index c2c067a..8235367 100644 --- a/docs/nut4cc.txt +++ b/docs/nut4cc.txt @@ -160,6 +160,7 @@ values for the UV planes, that is the amount to shift the luma width/height right to find the chroma width/height. The fourth byte is the number of bits used (8, 16, ...). +33 implies 32bit IEEE floats (33 is used to leave 32 for integers) If the order of bytes is inverted, that means that each component has to be read big-endian. @@ -176,6 +177,7 @@ Y3[10][16] Planar YUV 4:2:2, 32bpp, (1 Cr & Cb sample per 2x1 Y samples), littl Y3[00][16] Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian [NOT in AVI] [16][00]3Y Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), big-endian [NOT in AVI] Y4[11][ 8] Planar YUV 4:2:0, 20bpp, (1 Cr & Cb sample per 2x2 Y & A samples) [NOT in AVI] +Y3[00][33] Planar YUV 4:4:4, 96bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian floats [NOT in AVI] Y2[00][ 8] 8bit gray, 8bit alpha [NOT in AVI] G3[00][ 8] Planar GBR, 24bpp [NOT in AVI] G3[00][ 9] Planar GBR, 27bpp, 7 unused MSB per 16bit value, little-endian [NOT in AVI] @@ -188,6 +190,7 @@ G3[00][14] Planar GBR, 42bpp, 2 unused MSB per 16bit value, little-endian [NOT [14][00]3G Planar GBR, 42bpp, 2 unused MSB per 16bit value, big-endian [NOT in AVI] G3[00][16] Planar GBR, 48bpp, little-endian [NOT in AVI] [16][00]3G Planar GBR, 48bpp, big-endian [NOT in AVI] +[33][00]3G Planar GBR, 96bpp, big-endian floats [NOT in AVI] Audio: 3389 RFC 3389 comfort noise generator -- 1.7.9.5
On 2/9/16, Michael Niedermayer <michael@niedermayer.cc> wrote:
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- docs/nut4cc.txt | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/docs/nut4cc.txt b/docs/nut4cc.txt index c2c067a..8235367 100644 --- a/docs/nut4cc.txt +++ b/docs/nut4cc.txt @@ -160,6 +160,7 @@ values for the UV planes, that is the amount to shift the luma width/height right to find the chroma width/height.
The fourth byte is the number of bits used (8, 16, ...). +33 implies 32bit IEEE floats (33 is used to leave 32 for integers)
If the order of bytes is inverted, that means that each component has to be read big-endian. @@ -176,6 +177,7 @@ Y3[10][16] Planar YUV 4:2:2, 32bpp, (1 Cr & Cb sample per 2x1 Y samples), littl Y3[00][16] Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian [NOT in AVI] [16][00]3Y Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), big-endian [NOT in AVI] Y4[11][ 8] Planar YUV 4:2:0, 20bpp, (1 Cr & Cb sample per 2x2 Y & A samples) [NOT in AVI] +Y3[00][33] Planar YUV 4:4:4, 96bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian floats [NOT in AVI] Y2[00][ 8] 8bit gray, 8bit alpha [NOT in AVI] G3[00][ 8] Planar GBR, 24bpp [NOT in AVI] G3[00][ 9] Planar GBR, 27bpp, 7 unused MSB per 16bit value, little-endian [NOT in AVI] @@ -188,6 +190,7 @@ G3[00][14] Planar GBR, 42bpp, 2 unused MSB per 16bit value, little-endian [NOT [14][00]3G Planar GBR, 42bpp, 2 unused MSB per 16bit value, big-endian [NOT in AVI] G3[00][16] Planar GBR, 48bpp, little-endian [NOT in AVI] [16][00]3G Planar GBR, 48bpp, big-endian [NOT in AVI] +[33][00]3G Planar GBR, 96bpp, big-endian floats [NOT in AVI]
Why is this one big-endian? Having this supported in swscale would make me happy.
On Tue, Feb 09, 2016 at 07:20:31PM +0100, Paul B Mahol wrote:
On 2/9/16, Michael Niedermayer <michael@niedermayer.cc> wrote:
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- docs/nut4cc.txt | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/docs/nut4cc.txt b/docs/nut4cc.txt index c2c067a..8235367 100644 --- a/docs/nut4cc.txt +++ b/docs/nut4cc.txt @@ -160,6 +160,7 @@ values for the UV planes, that is the amount to shift the luma width/height right to find the chroma width/height.
The fourth byte is the number of bits used (8, 16, ...). +33 implies 32bit IEEE floats (33 is used to leave 32 for integers)
If the order of bytes is inverted, that means that each component has to be read big-endian. @@ -176,6 +177,7 @@ Y3[10][16] Planar YUV 4:2:2, 32bpp, (1 Cr & Cb sample per 2x1 Y samples), littl Y3[00][16] Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian [NOT in AVI] [16][00]3Y Planar YUV 4:4:4, 48bpp, (1 Cr & Cb sample per 1x1 Y samples), big-endian [NOT in AVI] Y4[11][ 8] Planar YUV 4:2:0, 20bpp, (1 Cr & Cb sample per 2x2 Y & A samples) [NOT in AVI] +Y3[00][33] Planar YUV 4:4:4, 96bpp, (1 Cr & Cb sample per 1x1 Y samples), little-endian floats [NOT in AVI] Y2[00][ 8] 8bit gray, 8bit alpha [NOT in AVI] G3[00][ 8] Planar GBR, 24bpp [NOT in AVI] G3[00][ 9] Planar GBR, 27bpp, 7 unused MSB per 16bit value, little-endian [NOT in AVI] @@ -188,6 +190,7 @@ G3[00][14] Planar GBR, 42bpp, 2 unused MSB per 16bit value, little-endian [NOT [14][00]3G Planar GBR, 42bpp, 2 unused MSB per 16bit value, big-endian [NOT in AVI] G3[00][16] Planar GBR, 48bpp, little-endian [NOT in AVI] [16][00]3G Planar GBR, 48bpp, big-endian [NOT in AVI] +[33][00]3G Planar GBR, 96bpp, big-endian floats [NOT in AVI]
Why is this one big-endian?
because thats how the planar rawvideo formats distinguish LE/BE its an example, write the fourcc backward and its the other endianness
Having this supported in swscale would make me happy. _______________________________________________ NUT-devel mailing list NUT-devel@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/nut-devel
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment.
participants (2)
-
Michael Niedermayer -
Paul B Mahol