Raw Video Frame Buffer Format (RGB)

Video frames can be stored on the Autodesk Media Storage as raw uncompressed RGB data with no file header, and are stored under frame IDs. Frame format information is stored separately. This section describes this raw RGB video format.

Wiretap allows you to access format information through the WireTapClipFormat object associated with a video clip node.

Note: In the sections below, raw RGB refers specifically to the raw RGB file format stored on the Autodesk Media Storage.

Key Attributes of the Raw RGB Format

This section describes key attributes of the raw RGB video format.

Image Orientation – Indicates the orientation of the image data for display. Raw RGB frames are oriented as follows:

• Line direction = Left to right
• Frame direction = Top to bottom

Number of Components or Channels – Defines the number of color components per pixel. Raw RGB pixels have three color components.

Bit Size – Defines the number of bits used for each color component (or channel) in a pixel. All components have the same bit size. Raw RGB frames can have the following bit sizes:

• 8-bit integer
• 10-bit integer
• 12-bit integer (can be packed or unpacked/filled. See the next section)
• 16-bit float
• 32-bit float

Bit size is also known as frame depth.

Component Data Packing Method – Indicates whether the components of a pixel are packed or filled/unpacked into 32-bit words. Packed means pixel components are stored contiguously, regardless of whether they form complete 32-bit words. With this method, every bit contains image data. Filled means the last few bits for a pixel component are skipped or set to 0 so that the pixel component corresponds to a certain number of words. Filling makes each pixel component (and therefore each pixel) start at a word boundary. Filling is only necessary if the data does not fit evenly into words. The number of bits used as filler depends on the bit size. The last few bits can usually be ignored when reading the pixel from memory. Raw RGB frames might be packed or unpacked/filled depending on the bit size. For details, see the table in Memory Required Per Pixel. The Component Packing Diagrams show how component data is laid out for various bit sizes.

End-of-line Padding – Specifies the number of bits required to make each scan line of a frame end on a 32-bit boundary. Padding makes each scan line correspond to a round number of 32-bit words. The raw RGB format uses end-of-line padding. The number of bits of padding required depends on the frame width and the number of bits per pixel.

Encoding – Defines whether the element is run-length encoded. No encoding is applied to raw RGB data.

Memory Required Per Pixel

The memory required for each pixel of a raw RGB frame depends on three factors:

• Number of color components or channels per pixel (for raw RGB this is 3)
• Bit size (in bits per component or bits per channel)
• Data packing method

The following table indicates the memory required for raw RGB frames of various bit sizes.

Number of Components	Bits per Component	Data Type	Bits per Pixel	Memory Required per Pixel
3	8	integer	24	3 bytes per pixel. No filling necessary
3	10	integer	32	4 bytes per pixel in both cases. The last byte is filled. Its last 2 bits can be ignored.
3	12 (packed)	integer	36	4.5 bytes per pixel. This is a non-standard, Visual Effects and Finishing application-specific format. No filler bits are used. For more information on this format and how to unpack it, see 12-bit Packed RGB Format.
3	12 (filled/unpacked)	integer	48	6 bytes per pixel. The last byte is filled. Its last 4 bits can be ignored.
3	16	float	48	6 bytes per pixel. No filling necessary
3	32	float	96	12 bytes per pixel. No filling necessary

Memory Required per Frame

Pixels are arranged in scan lines. The memory required for one scan line is the width of the frame multiplied by the number of bytes per pixel. Each line is padded to a double word length by adding the necessary number of bits set to 0.

Memory required per frame can be calculated as follows:

bitsPerFrame = ( (bitsPerPixel * frameWidth) + endOfLinePadding ) * frameHeight

Component Packing Diagrams

The diagrams in this section show how component data is packed and filled for different bit sizes. Diagrams are not provided for all bitsize/packing combinations. A few representative diagrams are provided to illustrate the principle. For formats that use filling, the diagrams demonstrate the fact that pixel component boundaries do not coincide with byte boundaries.

How to Read the Diagrams

The following table explains how to interpret the diagrams.

Row Label	Comment
Byte	The pipe character (|) represents a byte boundary.
Comp	The values indicate the pixel component. For example, P1/C2 refers to Pixel 1/Component 2. The pipe character (|) represents a component boundary. The word fill indicates that part of the section is filled (does not contain component data).
Bit	Values are indices for the bits within a particular byte.
Data	The values indicate the type of data that is contained in a particular bit, namely: R (red) G (green) B (blue) 0 (filler bit) Set to 0 when writing. It can be ignored when reading.

8-bit Integer Diagram

(packed, no filling necessary)

Byte |      Byte0      |      Byte1      |      Byte2      |      Byte3      |
Comp.|      P1/C0      |      P0/C2      |      P0/C1      |      P0/C0      |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | R R R R R R R R | B B B B B B B B | G G G G G G G G | R R R R R R R R |

10-bit Integer Diagram

(filled to 32-bit word boundaries)

Byte |      Byte0      |      Byte1      |      Byte2      |      Byte3      |
Comp.|fill|        P0/C2        |        P0/C1        |        P0/C0         |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | 0 0 B B B B B B | B B B B G G G G | G G G G G G R R | R R R R R R R R |

12-bit Integer Packed Diagram

Byte |      Byte0      |      Byte1      |      Byte2      |      Byte3      |
Comp.|      P0/C2      |          P0/C1           |           P0/C0          |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | B B B B B B B B | G G G G G G G G | G G G G R R R R | R R R R R R R R |
Byte |      Byte4      |      Byte5      |      Byte6      |      Byte7      |
Comp.| P1/C2|           P1/C1          |          P1/C0           |  P0/C2 |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | B B B B G G G G | G G G G G G G G | R R R R R R R R | R R R R B B B B |
Byte |      Byte8      |      Byte9      |      Byte10     |      Byte11     |
Comp.|          P2/C1           |          P2/C0           |  P1/C2 |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | G G G G G G G G | G G G G R R R R | R R R R R R R R | B B B B B B B B |

12-bit Integer Unpacked Diagram

(filled/unpacked to 16-bit word boundaries)

Byte |      Byte0      |      Byte1      |      Byte2      |      Byte3      |
Comp.|  fill  |           P0/C1          |  fill  |           P0/C0          |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | 0 0 0 0 G G G G | G G G G G G G G | 0 0 0 0 R R R R | R R R R R R R R |
Byte |      Byte4      |      Byte5      |      Byte6      |      Byte7      |
Comp.|  fill  |           P1/C0          |  fill  |           P0/C2          |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | 0 0 0 0 R R R R | R R R R R R R R | 0 0 0 0 B B B B | B B B B B B B B |
Byte |      Byte8      |      Byte9      |      Byte10     |      Byte11     |
Comp.|  fill  |           P1/C2          |  fill  |          P0/C1           |
Bit  | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0 |
Data | 0 0 0 0 B B B B | B B B B B B B B | 0 0 0 0 G G G G | G G G G G G G G |