OggUVS: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
mNo edit summary
Line 3: Line 3:
'''OggUVS''' is an uncompressed video codec for Ogg.  It's a simple way to store and transfer uncompressed video within an Ogg container. It is similar to [[OggYUV]] and [[OggRGB]], but is intended to support both formats.
'''OggUVS''' is an uncompressed video codec for Ogg.  It's a simple way to store and transfer uncompressed video within an Ogg container. It is similar to [[OggYUV]] and [[OggRGB]], but is intended to support both formats.


This is a work in progress and not a final proposal.
'''This is a work in progress and not a final proposal.'''


== Packet Layout ==
== Packet Layout ==
Line 9: Line 9:
Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.  
Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.  


This stream format is field based, rather than frame based. It supports only two fields per frame, and one field per data packet. Fields are stored in temporal order, so granulepos maintains its temporal significance. Fields are always encoded in alternating order, starting with the field containing the topmost line.
This stream format is field based, rather than frame based. It supports only two fields per frame, and one field per data packet. Fields are stored in temporal order, so granulepos maintains its temporal significance.  


=== Main Header Packet ===
=== Main Header Packet ===
Line 27: Line 27:
  31  [uint]  Reserved
  31  [uint]  Reserved
   1  [flg]  Interlaced
   1  [flg]  Interlaced
  32  [enum]  FourCC (set to zero if unknown or N/A)
  32  [enum]  Layout ID


'''Discussion:'''
'''Discussion:'''
* The FourCC field is used to specify a series of predefined packets describing the data layout. Applications should include the predefined packets in the stream as well, preferably by asking a helper library to fill them in. Applications should only use fourcc codes for formats that have corresponding layout packets defined.
* The Layout ID field is used to describe the layout of the image buffer in memory. This provides an easy means of selecting amongst common formats. If this field is set to zero, a Data Layout Packet MUST be included in the stream, and the contents of that packet should be parsed to determine the image buffer layout. The valid values for this field are:
  Value      Short Name          Description
0x31313259  OGGUVS_FMT_YV12    8-bpp Y plane, followed by 8-bpp 2×2 V and U planes.
fill in more later.
 
* The Colorspace field is used to identify all colorspaces supported by this format and is defined as follows:
* The Colorspace field is used to identify all colorspaces supported by this format and is defined as follows:
Colorspace  Description
  Value      Short Name                Description
  0x00000001  R'G'B'
  0x00000001  OGGUVS_CSP_UNSPEC_RGB    Unspecified R'G'B'
  0x00000002  Y'CbCr Rec 601
  0x00000002  OGGUVS_CSP_UNSPEC_YCBCR  Unspecified Y'CbCr


=== Comment Packet ===
=== Comment Packet ===

Revision as of 10:30, 15 November 2005

What is it

OggUVS is an uncompressed video codec for Ogg. It's a simple way to store and transfer uncompressed video within an Ogg container. It is similar to OggYUV and OggRGB, but is intended to support both formats.

This is a work in progress and not a final proposal.

Packet Layout

Note that unless otherwise noted, all multi-byte fields use the network byte order (big endian). The first packed in a stream MUST be the main header packet. The second packet MUST be the comment packet. Some extra header packets MAY be included after the comment header, provided this is identified in the main header. The packets that follow MUST all be data packets.

This stream format is field based, rather than frame based. It supports only two fields per frame, and one field per data packet. Fields are stored in temporal order, so granulepos maintains its temporal significance.

Main Header Packet

32  "UVS\0" Codec Identifier Word 0
32     0x0  Codec Identifier Word 1
16  [uint]  Version Major (breaks backwards compatability to increment)
16  [uint]  Version Minor (backwards compatable, ie, more supported format id's)
16  [uint]  Display Width
16  [uint]  Display Height
16  [uint]  Pixel Aspect Ratio Numerator
16  [uint]  Pixel Aspect Ratio Denominator
16  [uint]  Field Rate Numerator
16  [uint]  Field Rate Denominator
32  [uint]  Maximum Size Per Frame
32  [uint]  Number of extra headers
32  [enum]  Colorspace
31  [uint]  Reserved
 1  [flg]   Interlaced
32  [enum]  Layout ID

Discussion:

  • The Layout ID field is used to describe the layout of the image buffer in memory. This provides an easy means of selecting amongst common formats. If this field is set to zero, a Data Layout Packet MUST be included in the stream, and the contents of that packet should be parsed to determine the image buffer layout. The valid values for this field are:
  Value      Short Name          Description
0x31313259   OGGUVS_FMT_YV12     8-bpp Y plane, followed by 8-bpp 2×2 V and U planes.
fill in more later.
  • The Colorspace field is used to identify all colorspaces supported by this format and is defined as follows:
  Value      Short Name                Description
0x00000001   OGGUVS_CSP_UNSPEC_RGB     Unspecified R'G'B'
0x00000002   OGGUVS_CSP_UNSPEC_YCBCR   Unspecified Y'CbCr

Comment Packet

Undefined at this time, probably will be whatever Theora uses.

Data Layout Packet

32     0x1  Data Layout Header Packet ID
16  [uint]  Version Major (breaks backwards compatability to increment)
16  [uint]  Version Minor (backwards compatable, ie, more supported format id's)
16  [uint]  Luma Height
16  [uint]  Luma Width
16  [uint]  Chroma Height
16  [uint]  Chroma Width
-- Repeat all fields below this point for interlaced storage.
32  [uint]  Alpha channel offset
32  [uint]  Y/R channel offset
32  [uint]  U/G channel offset
32  [uint]  V/B channel offset
32  [sint]  Alpha Y Stride
32  [sint]  Y/R Y Stride
32  [sint]  U/G Y Stride
32  [sint]  V/B Y Stride
32  [sint]  Y/R X Stride
32  [sint]  U/G X Stride
32  [sint]  V/B X Stride

Discussion:

  • This layout packet is for 8 bit per channel formats only.
  • The width and height fields reflect the storage size of the field.
  • The offset fields specify the offset, in bytes, from the start of the data packet to the top leftmost sample for the specified channel.
  • The Y stride field indicates the number of bytes to add to the current position to get the corresponding sample one row down. For the alpha channel, this value should be set to zero if the channel is not present.
  • The X stride field indicates the number of bytes to add to the current position to get the corresponding sample one pixel to the right. For the alpha channel, this value should be set to zero if the channel is not present.

Data Packets

..  [data]     Data for whole field

Supported Formats

The following packets are defined as the standard layout packets for the various defined formats. For those formats that declare a fourcc, it is illegal to modify the values of the layout packet. The following abbreviations are used in the formulae below:

  • disp_h: Display Height, from main header packet
  • disp_w: Display Width, from main header packet
  • l_h: Luma height, from data layout packet
  • l_w: Luma width, from data layout packet
  • c_h: Chroma height, from data layout packet
  • c_w: Chroma width, from data layout packet

YV12

  • FourCC: 0x32315659
  • Interlaced: Not supported.
l_h         = (disp_h + 1) & ~1
l_w         = (disp_w + 1) & ~1
c_h         = l_h / 2
c_w         = l_w / 2
a_offset    = 0
yr_offset   = 0
ug_offset   = l_h * l_w + c_h * c_w
vb_offset   = l_h * l_w
a_y_stride  = 0
yr_y_stride = l_w
ug_y_stride = c_w
vb_y_stride = c_w
a_x_stride  = 0
yr_x_stride = 1
ug_x_stride = 1
vb_x_stride = 1

YUY2

  • FourCC: 0x32595559
  • Interlaced: Not supported.
l_h         = disp_h
l_w         = (disp_w + 1) & ~1
c_h         = l_h
c_w         = l_w / 2
a_offset    = 0
yr_offset   = 0
ug_offset   = 1
vb_offset   = 3
a_y_stride  = 0
yr_y_stride = l_w * 2
ug_y_stride = l_w * 2
vb_y_stride = l_w * 2
a_x_stride  = 0
yr_x_stride = 2
ug_x_stride = 4
vb_x_stride = 4

RGB24 DIB (bottom up, rows aligned to 32 bits)

  • FourCC: 0x0000
  • Interlaced: Not supported.
l_h         = disp_h
l_w         = disp_w
c_h         = disp_h
c_w         = disp_w
a_offset    = 0
yr_offset   = 2 + (disp_h-1) * -yr_y_stride 
ug_offset   = 1 + (disp_h-1) * -yr_y_stride 
vb_offset   = 0 + (disp_h-1) * -yr_y_stride 
a_y_stride  = 0
yr_y_stride = -1 * (((disp_w*3)+3) & ~1)
ug_y_stride = -1 * (((disp_w*3)+3) & ~1)
vb_y_stride = -1 * (((disp_w*3)+3) & ~1)
a_x_stride  = 0
yr_x_stride = 3
ug_x_stride = 3
vb_x_stride = 3