- NUT-devel - lists.mplayerhq.hu

[nut] [propchange]: r669 - svn:log
by stefano 27 May '10

27 May '10

Author: stefano Revision: 669 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1,4 +1,4 @@ Describe a scheme for defining FourCCs for generic rawvideo YUVA formats, and use it for creating a bunch of them: Y1[00][16], [16][00]1Y, Y3[11][16], [16][11]3Y, Y3[10][16], -[16][10]3Y, Y3[00][16], [16][00]3Y, Y4[11][ 8], YA[00][ 8]. +[16][10]3Y, Y3[00][16], [16][00]3Y, Y4[11][ 8], Y2[00][ 8].

1 0

Re: [NUT-devel] [PATCH] Additional planar YUVA? format fourccs
by stefasab 26 May '10

26 May '10

On date Friday 2010-05-21 18:22:13 +0200, Stefano Sabatini wrote: > On date Friday 2010-05-21 04:54:11 +0200, Michael Niedermayer nutted: > > On Fri, May 21, 2010 at 12:18:32AM +0200, Stefano Sabatini wrote: > > > Hi, > > > > > > this follows from a discussion on ffmpeg-devel: > > > http://thread.gmane.org/20100514214352.GE2585@MichaelsNB > > > > > > We need this in order to support to contain in NUT all the formats > > > currently supported by FFmpeg, which in turn is required by the lavfi > > > test system. > > > > > > Regards. > > > > > nut4cc.txt | 32 ++++++++++++++++++++++++++++++++ > > > 1 file changed, 32 insertions(+) > > > 8bcd168001001097502f105d2283671d83d5effd define-yuva-fourcc.patch > > > Index: docs/nut4cc.txt > > > =================================================================== > > > --- docs/nut4cc.txt (revision 668) > > > +++ docs/nut4cc.txt (working copy) > > > @@ -101,6 +101,38 @@ > > > 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] > > > [48]RGB Packed RGB 16:16:16, 48bpp, 16R, 16G, 16B, the 2-byte value for each R/G/B component is stored as big-endian [NOT in AVI] > > > > > > +Since many exotic planar YUVA pixel formats are not contemplated by > > > +AVI/QuickTime FourCC list, the following scheme is adopted for > > > +representing them. > > > + > > > +The first two bytes can contains the values: > > > +Y1 = only Y > > > +Y3 = YUV > > > +Y4 = YUVA > > > > > +YA = Y+A > > > > Y2 > > Updated. Ping.

3 5

[nut]: r669 - docs/nut4cc.txt
by stefano 26 May '10

26 May '10

Author: stefano Date: Wed May 26 00:35:45 2010 New Revision: 669 Log: Describe a scheme for defining FourCCs for generic rawvideo YUVA formats, and use it for creating a bunch of them: Y1[00][16], [16][00]1Y, Y3[11][16], [16][11]3Y, Y3[10][16], [16][10]3Y, Y3[00][16], [16][00]3Y, Y4[11][ 8], YA[00][ 8]. Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt Sun May 16 18:41:15 2010 (r668) +++ docs/nut4cc.txt Wed May 26 00:35:45 2010 (r669) @@ -101,6 +101,39 @@ RGB[8] Packed RGB 3:3:2, 8bpp, (msb)2R 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] [48]RGB Packed RGB 16:16:16, 48bpp, 16R, 16G, 16B, the 2-byte value for each R/G/B component is stored as big-endian [NOT in AVI] +Since many exotic planar YUVA pixel formats are not contemplated by +the AVI/QuickTime FourCC lists, the following scheme is adopted for +representing them. + +The first two bytes can contain the values: +Y1 = only Y +Y2 = Y+A +Y3 = YUV +Y4 = YUVA + +The third byte represents the width and height chroma subsampling +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, ...). + +If the order of bytes is inverted, that means that each component has +to be read big-endian. + +Follows the list of the supported YUVA planar format FourCCs created +using this scheme: + +Y1[00][16] Planar gray, 16bpp, little-endian [NOT in AVI] +[16][00]1Y Planar gray, 16bpp, big-endian [NOT in AVI] +Y3[11][16] Planar YUV 4:2:0, 24bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian [NOT in AVI] +[16][11]3Y Planar YUV 4:2:0, 24bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian [NOT in AVI] +Y3[10][16] Planar YUV 4:2:2, 32bpp, (1 Cr & Cb sample per 2x1 Y samples), little-endian [NOT in AVI] +[16][10]3Y Planar YUV 4:2:2, 32bpp, (1 Cr & Cb sample per 2x1 Y samples), big-endian [NOT in AVI] +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] +Y2[00][ 8] 8bit gray, 8bit alpha [NOT in AVI] + Raw audio: [x] is an byte with value x, [NOT in AVI] ALAW A-LAW ULAW MU-LAW

1 0

Re: [NUT-devel] [RFC] FourCCs for rawvideo rgb4_byte / bgr4_byte
by stefasab 23 May '10

23 May '10

On date Friday 2010-05-21 00:14:17 +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? Ping.

4 3

[PATCH] Additional planar YUVA? format fourccs
by Stefano Sabatini 21 May '10

21 May '10

Hi, this follows from a discussion on ffmpeg-devel: http://thread.gmane.org/20100514214352.GE2585@MichaelsNB We need this in order to support to contain in NUT all the formats currently supported by FFmpeg, which in turn is required by the lavfi test system. Regards.

2 1

[nut]: r668 - docs/nut4cc.txt
by stefano 16 May '10

16 May '10

Author: stefano Date: Sun May 16 18:41:15 2010 New Revision: 668 Log: Add NUT codec tags: 440P Planar 4:4:0 YUV [NOT in AVI] B1W0 black/white bitstream, 1bpp, 0 is white, 1 is black, in each byte pixels are ordered from the msb to the lsb [NOT in AVI] 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] 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] These tags allow to store rawvideo with pixel formats which are not currently contemplated by AVI/QT codec tags. This has been discussed on the FFmpeg-devel ML, see the thread: Subject: [FFmpeg-devel] [PATCH 10/13] Add rawvideo pixel formats to codec tags mapping for the newly added nut rawvideo pixel formats codec tags. Date: 2010-05-09 13:30:00 GMT Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt Sun May 16 18:34:08 2010 (r667) +++ docs/nut4cc.txt Sun May 16 18:41:15 2010 (r668) @@ -74,6 +74,7 @@ YUV9 Planar 4:1:0 YUV Y800 8bit Gray 411P Planar 4:1:1 YUV 422P Planar 4:2:2 YUV +440P Planar 4:4:0 YUV [NOT in AVI] 444P Planar 4:4:4 YUV UYVY Packed 4:2:2 YUV (UYVY) YUY2 Packed 4:2:2 YUV (YUYV) @@ -91,6 +92,14 @@ ABGR Packed RGBA 8:8:8:8, 32bpp, ABGR ARGB Packed RGBA 8:8:8:8, 32bpp, ARGB [NOT in AVI] RGB[24] Packed RGB 8:8:8, 24bpp RGB [NOT in AVI] BGR[24] Packed RGB 8:8:8, 24bpp BGR [NOT in AVI] +B1W0 black/white bitstream, 1bpp, 0 is white, 1 is black, in each byte pixels are ordered from the msb to the lsb [NOT in AVI] +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] +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] +[48]RGB Packed RGB 16:16:16, 48bpp, 16R, 16G, 16B, the 2-byte value for each R/G/B component is stored as big-endian [NOT in AVI] Raw audio: [x] is an byte with value x, [NOT in AVI] ALAW A-LAW

1 0

[nut]: r667 - homepage/index.html
by stefano 16 May '10

16 May '10

Author: stefano Date: Sun May 16 18:34:08 2010 New Revision: 667 Log: Make the link to the specs directly point to Michael specifications file, as the SVN web front end is still broken. Modified: homepage/index.html Modified: homepage/index.html ============================================================================== --- homepage/index.html Sat Feb 20 02:30:28 2010 (r666) +++ homepage/index.html Sun May 16 18:34:08 2010 (r667) @@ -16,7 +16,7 @@ <center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center> @@ -48,7 +48,7 @@ and dynamic index generation during play </p> <center> - [<a href="http://svn.mplayerhq.hu/nut/docs/nut.txt?view=co">Specification</a>] + [<a href="http://www1.mplayerhq.hu/~michael/nut.txt">Specification</a>] [<a href="http://lists.mplayerhq.hu/mailman/listinfo/nut-devel">Mailing List</a>] </center>

1 0

[nut]: r666 - docs/nut.txt
by michael 20 Feb '10

20 Feb '10

Author: michael Date: Sat Feb 20 02:30:28 2010 New Revision: 666 Log: Clarify what to do with silly specs doing silly things with dts. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt Sat Feb 20 02:04:20 2010 (r665) +++ docs/nut.txt Sat Feb 20 02:30:28 2010 (r666) @@ -771,6 +771,14 @@ dts dts of all frames MUST be bigger or equal to dts of all previous frames in the same stream. + If a codec spec defines dts in a way incompatible to this then the decoder + dts shall be considered to be entirely outside the nut spec. In this case + a decoder compatible with a nut demuxer will output/display decoded frames + purely based on the pts values stored in a nut file. + Such nut files MUST NOT contain non standard fields conveying these codec + dts as this would break remuxing, spliting, merging and time scaling by + (de)muxers unaware of these non standard fields. + width (v) / height (v) Width and height of the video in pixels. MUST be set to the coded width/height, MUST NOT be 0.

1 0

[nut]: r665 - docs/nut.txt
by michael 20 Feb '10

20 Feb '10

Author: michael Date: Sat Feb 20 02:04:20 2010 New Revision: 665 Log: Add "TargetAudience" metadata/info key Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt Fri Sep 18 14:27:33 2009 (r664) +++ docs/nut.txt Sat Feb 20 02:04:20 2010 (r665) @@ -948,6 +948,8 @@ info packet types Note: Names of fields SHOULD be in English if a word with the same meaning exists in English. Note: MUST be less than 64 bytes long. + "TargetAudience" + "default", "visually impaired", "hearing impaired" "Replaces" v (stream id) This stream is a superior alternative (higher resolution or otherwise)

1 0

[nut]: r664 - docs/nut.txt
by michael 18 Sep '09

18 Sep '09

Author: michael Date: Fri Sep 18 14:27:33 2009 New Revision: 664 Log: Explicitly spell out limit for time_base_num previously, the limit on denom as well as the fact that timebases in reality are <=1 alraedy ensured that this is true unless one wanted to violate it intentionally. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt Fri Sep 18 01:56:56 2009 (r663) +++ docs/nut.txt Fri Sep 18 14:27:33 2009 (r664) @@ -538,6 +538,7 @@ time_base_num (v) / time_base_denom (v) if FLAG_FIXED_FPS is set time_base_num and time_base_denom MUST NOT be 0 time_base_num and time_base_denom MUST be relatively prime + time_base_num MUST be < 2^31 time_base_denom MUST be < 2^31 examples: fps time_base_num time_base_denom

1 0