Samsung Electronics

6105 Tennyson Pkwy, Ste 300 Plano TX 75024 United States of America yklwhite@gmail.com

Samsung Electronics

34, Seongchon-gil, Seocho-gu Seoul 3573 Republic of Korea m.w.park@samsung.com

Samsung Electronics

6105 Tennyson Pkwy, Ste 300 Plano TX 75024 United States of America m.budagavi@samsung.com

Samsung Electronics

11488 Tree Hollow Ln San Diego CA 92128 United States of America rajan_joshi@ieee.org

Samsung Electronics

34 Seongchon-gil Seocho-gu Seoul 3573 Republic of Korea kwangpyo.choi@gmail.com

mezzanine codec visually lossless compression APV This document describes the bitstream format of Advanced Professional Video (APV) and its decoding process. APV is a professional video codec providing visually lossless compression mainly for recording and post production.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• .  Introduction
• .  Terms
  • .  Terms and Definitions
  • .  Abbreviated Terms
• .  Conventions Used in This Document
  • .  General
  • .  Operators
    • .  Arithmetic Operators
    • .  Bitwise Operators
  • .  Range Notation
    • .  Order of Operations Precedence
  • .  Variables, Syntax Elements, and Tables
  • .  Processes
• .  Formats and Processes Used in This Document
  • .  Bitstream Formats
  • .  Source, Decoded, and Output Frame Formats
  • .  Partitioning of a Frame
    • .  Partitioning of a Frame into Tiles
    • .  Spatial or Component-Wise Partitioning
  • .  Scanning Processes
    • .  Zig-Zag Scan
    • .  Inverse Scan
• .  Syntax and Semantics
  • .  Method of Specifying Syntax
  • .  Syntax Functions and Descriptors
    • .  byte_aligned()
    • .  more_data_in_tile()
    • .  next_bits(n)
    • .  read_bits(n)
    • .  Syntax Element Processing Functions
  • .  List of Syntax and Semantics
    • .  Access Unit
    • .  Primitive Bitstream Unit
    • .  Primitive Bitstream Unit Header
    • .  Frame
    • .  Frame Header
    • .  Frame Information
    • .  Quantization Matrix
    • .  Tile Info
    • .  Access Unit Information
    • . Metadata
    • . Filler
    • . Tile
    • . Tile Header
    • . Tile Data
    • . Macroblock Layer
    • . AC Coefficient Coding
    • . Byte Alignment
• .  Decoding Process
  • .  MB Decoding Process
  • .  Block Reconstruction Process
  • .  Scaling and Transformation Process
    • .  Scaling Process for Transform Coefficients
    • .  Process for Scaled Transform Coefficients
• .  Parsing Process
  • .  Process for Syntax Element Type h(v)
    • .  Process for abs_dc_coeff_diff
    • .  Process for coeff_zero_run
    • .  Process for abs_ac_coeff_minus1
    • .  Process for Variable-Length Codes
  • .  Codeword Generation Process for h(v) (Informative)
    • .  Process for abs_dc_coeff_diff
    • .  Process for coeff_zero_run
    • .  Process for abs_ac_coeff_minus1
    • .  Process for Variable-Length Codes
• .  Metadata Information
  • .  Metadata Payload
  • .  List of Metadata Syntax and Semantics
    • .  Filler Metadata
    • .  Recommendation ITU-T T.35 Metadata
    • .  Mastering Display Color Volume Metadata
    • .  Content Light-Level Information Metadata
    • .  User-Defined Metadata
    • .  Undefined Metadata
• .  Profiles, Levels, and Bands
  • .  Overview of Profiles, Levels, and Bands
  • .  Requirements on Video Decoder Capability
  • .  Profiles
    • .  General
    • .  422-10 Profile
    • .  422-12 Profile
    • .  444-10 Profile
    • .  444-12 Profile
    • .  4444-10 Profile
    • .  4444-12 Profile
    • .  400-10 Profile
  • .  Levels and Bands
    • .  General
    • .  Limits of Levels and Bands
• . Security Considerations
• . IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• .  Raw Bitstream Format
• .  APV Implementations
  • .  OpenAPV Open Source Project
  • .  Android Open Source Project
  • .  FFmpeg Open Source Project
• Authors' Addresses

Introduction This document defines the bitstream format and decoding process for the Advanced Professional Video (APV) codec. The APV codec is a professional video codec that was developed in response to the need for professional-level, high-quality video recording and post production. The primary purpose of the APV codec is for use in professional video recording and editing workflows for various types of content. This specification is neither the product of the IETF nor a consensus view of the community. The APV codec supports the following features:

• Perceptually lossless video quality that is close to the original, uncompressed quality;
• Low complexity and high throughput intra frame only coding without inter frame coding;
• Intra frame coding without prediction between pixel values but with prediction between transformed values for low delay encoding;
• High bit rates of up to a few Gbps for 2K, 4K, and 8K resolution content, enabled by a lightweight entropy coding scheme;
• Frame tiling for immersive content and for enabling parallel encoding and decoding;
• Various chroma sampling formats from 4:0:0 to 4:4:4:4, and bit depths from 10 to 16 (Note: Only the profiles supporting 10 bits and 12 bits are currently defined);
• The ability to decode and re-encode multiple times without severe visual quality degradation; and
• Various metadata including HDR10/10+ and user-defined formats.

Terms

Terms and Definitions

access unit (AU):

a collection of primitive bitstream units (PBU) including various types of frames, metadata, filler, and access unit information, associated with a specific time

band:

a defined set of constraints on the value of the maximum coded data rate of each level

block:

MxN (M-column by N-row) array of samples, or an MxN array of transform coefficients

byte-aligned:

a position in a bitstream that is an integer multiple of 8 bits from the position of the first bit in the bitstream

chroma:

a sample array or single sample representing one of the two color difference signals related to the primary colors, represented by the symbols Cb and Cr in 4:2:2 or 4:4:4 color format

coded frame:

a coded representation of a frame containing all macroblocks of the frame

coded representation:

a data element as represented in its coded form

component:

an array or a single sample from one of the three arrays (luma and two chroma) that compose a frame in 4:2:2, or 4:4:4 color format, or an array or a single sample from an array that compose a frame in 4:0:0 color format, or an array or a single sample from one of the four arrays that compose a frame in 4:4:4:4 color format.

decoded frame:

a frame derived by decoding a coded frame

decoder:

an embodiment of a decoding process

decoding process:

a process specified that reads a bitstream and derives decoded frames from it

encoder:

an embodiment of an encoding process

encoding process:

a process that produces a bitstream conforming to this document

flag:

a variable or single-bit syntax element that can take one of the two possible values: 0 and 1

frame:

an array of luma samples and two corresponding arrays of chroma samples in 4:2:2 and 4:4:4 color format, or an array of samples in 4:0:0 color format, or four arrays of samples in 4:4:4:4 color format

level:

a defined set of constraints on the values that are taken by the syntax elements and variables of this document, or the value of a transform coefficient prior to scaling

luma:

a sample array or single sample representing the monochrome signal related to the primary colors, represented by the symbol or subscript Y or L

macroblock (MB):

a square block of luma samples and two corresponding blocks of chroma samples of a frame in 4:2:2 or 4:4:4 color format, or a square block of samples of a frame in 4:0:0 color format, or four square blocks of samples of a frame in 4:4:4:4 color format

metadata:

data describing various characteristics related to a bitstream without directly affecting the decoding process of it.

partitioning:

a division of a set into subsets such that each element of the set is in exactly one of the subsets

prediction:

an embodiment of the prediction process

prediction process:

use of a predictor to provide an estimate of the data element currently being decoded

predictor:

a combination of specified values or previously decoded data elements used in the decoding process of subsequent data elements

primitive bitstream unit (PBU):

a data structure to construct an access unit with frame and metadata

profile:

a specified subset of the syntax of this document

quantization parameter (QP):

a variable used by the decoding process for the scaling value of transform coefficients

raster scan:

a mapping of a rectangular two-dimensional pattern to a one-dimensional pattern such that the first entries in the one-dimensional pattern are from the top row of the two-dimensional pattern scanned from left to right, followed by the second, third, etc., rows of the pattern each scanned from left to right

raw bitstream:

an encapsulation of a sequence of access units where a field indicating the size of an access unit precedes each access unit as defined in

source:

a term used to describe the video material or some of its attributes before the encoding process

syntax element:

an element of data represented in the bitstream

syntax structure:

zero or more syntax elements present together in a bitstream in a specified order

tile:

a rectangular region of MBs within a particular tile column and a particular tile row in a frame

tile column:

a rectangular region of MBs having a height equal to the height of the frame and width specified by syntax elements in the frame header

tile row:

a rectangular region of MBs having a height specified by syntax elements in the frame header and a width equal to the width of the frame

tile scan:

a specific sequential ordering of MBs partitioning a frame in which the MBs are ordered consecutively in MB raster scan in a tile and the tiles in a frame are ordered consecutively in a raster scan of the tiles of the frame

transform coefficient:

a scalar quantity, considered to be in a frequency domain, that is associated with a particular one-dimensional or two-dimensional index

Abbreviated Terms

LSB:

least significant bit

MSB:

most significant bit

RGB:

Red, Green and Blue

Conventions Used in This Document

General The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Operators The operators and the order of precedence are the same as used in the C programming language . However, there are some exceptions for the operators described in the and , which follows widely used industry practices for video codecs.

Arithmetic Operators

//

an integer division with rounding of the result toward zero. For example, 7//4 and -7//-4 are rounded to 1 and -7//4 and 7//-4 are rounded to -1

/ or div(x,y)

a division in mathematical equations where no truncation or rounding is intended

min(x,y)

the minimum value of the values x and y

max(x,y)

the maximum value of the values x and y

ceil(x)

the smallest integer value that is larger than or equal to x

clip(x,y,z)

clip(x,y,z)=max(x,min(z,y))

sum (i=x, y, f(i))

a summation of f(i) with i taking all integer values from x up to and including y

log2(x)

the base-2 logarithm of x

Bitwise Operators

& (bitwise "and")

When operating on integer arguments, operates on a two's complement representation of the integer value. When operating on arguments with unequal bit depths, the bit depths are equalized by adding zeros in significant positions to the argument with lower bit depth.

| (bitwise "or")

When operating on integer arguments, operates on a two's complement representation of the integer value. When operating on arguments with unequal bit depths, the bit depths are equalized by adding zeros in significant positions to the argument with lower bit depth.

x >> y

arithmetic right shift of a two's complement integer representation of x by y binary digits. This function is defined only for non-negative integer values of y. Bits shifted into the most significant bits (MSBs) as a result of the right shift have a value equal to the MSB of x prior to the shift operation.

x << y

arithmetic left shift of a two's complement integer representation of x by y binary digits. This function is defined only for non-negative integer values of y. Bits shifted into the least significant bits (LSBs) as a result of the left shift have a value equal to 0.

Range Notation

x = y..z

x takes on integer values starting from y to z, inclusive, with x, y, and z being integer numbers and z being greater than y.

Order of Operations Precedence When order of precedence is not indicated explicitly by use of parentheses, operations are evaluated in the following order.

• Operations of a higher precedence are evaluated before any operation of a lower precedence. specifies the precedence of operations from highest to lowest; operations closer to the top of the table indicate a higher precedence.
• Operations of the same precedence are evaluated sequentially from left to right.

Operation precedence from highest (top of the table) to lowest (bottom of the table)

operations (with operands x, y, and z)
"x++", "x--"
"!x", "-x" (as a unary prefix operator)
x^y (power)
"x * y", "x / y", "x // y", "x % y"
"x + y", "x - y", "sum (i=x, y, f(i))"
"x << y", "x >> y"
"x < y", "x <= y", "x > y", "x >= y"
"x == y", "x != y"
"x & y"
"x | y"
"x && y"
"x || y"
"x ? y : z"
"x..y"
"x = y", "x += y", "x -= y"

Variables, Syntax Elements, and Tables Each syntax element is described by its name in all lowercase letters and its type is provided next to the syntax code in each row. Each syntax element and multi-byte integers are written in big endian format. The decoding process behaves according to the value of the syntax element and to the values of previously decoded syntax elements. In some cases, the syntax tables may use the values of other variables derived from syntax elements values. Such variables appear in the syntax tables or text, named by a mixture of lower case and uppercase letters and without any underscore characters. Variables with names starting with an uppercase letter are derived for the decoding of the current syntax structure and all dependent syntax structures. Variables with names starting with an uppercase letter may be used in the decoding process for later syntax structures without mentioning the originating syntax structure of the variable. Variables with names starting with a lowercase letter are only used within the section in which they are derived. Functions that specify properties of the current position in the bitstream are referred to as syntax functions. These functions are specified in and assume the existence of a bitstream pointer with an indication of the position of the next bit to be read by the decoding process from the bitstream. A one-dimensional array is referred to as a list. A two-dimensional array is referred to as a matrix. Arrays can either be syntax elements or variables. Square brackets are used for the indexing of arrays. In reference to a visual depiction of a matrix, the first square bracket is used as a column (horizontal) index and the second square bracket is used as a row (vertical) index. A specification of values of the entries in rows and columns of an array may be denoted by {{...}{...}}, where each inner pair of brackets specifies the values of the elements within a row in increasing column order and the rows are ordered in increasing row order. Thus, setting a matrix s equal to {{1 6}{4 9}} specifies that s[0][0] is set equal to 1, s[1][0] is set equal to 6, s[0][1] is set equal to 4, and s[1][1] is set equal to 9. Binary notation is indicated by enclosing the string of bit values in single quote marks. For example, '0b01000001' represents an eight-bit string having only its second and its last bits (counted from the most to the least significant bit) equal to 1. Hexadecimal notation, indicated by prefixing the hexadecimal number by "0x", may be used instead of binary notation when the number of bits is an integer multiple of 4. For example, 0x41 represents an eight-bit string having only its second and its last bits (counted from the most to the least significant bit) equal to 1. A value equal to 0 represents a FALSE condition in a test statement. The value TRUE is represented by any value different from zero.

Processes Processes are used to describe the decoding of syntax elements. A process has a separate specification and invoking. When invoking a process, the assignment of variables is specified as follows:

• If the variables at the invoking and the process specification do not have the same name, the variables are explicitly assigned to lower case input or output variables of the process specification.
• Otherwise (the variables at the invoking and the process specification have the same name), the assignment is implied.

In the specification of a process, a specific coding block is referred to by the variable name having a value equal to the address of the specific coding block.

Formats and Processes Used in This Document

Bitstream Formats This section specifies the bitstream format of the Advanced Professional Video (APV) codec. A raw bitstream format consists of a sequence of AUs where the field indicating the size of access units precedes each of them. The raw bitstream format is specified in .

Source, Decoded, and Output Frame Formats This section specifies the relationship between the source and decoded frames. The video source that is represented by the bitstream is a sequence of frames. Source and decoded frames are each comprised of one or more sample arrays:

• Monochrome (for example, Luma only)
• Luma and two chroma (for example, YCbCr or YCgCo as specified in ).
• Green, blue, and red (GBR, also known as RGB).
• Arrays representing other unspecified tri-stimulus color samplings (for example, YZX, also known as XYZ as specified in ).
• Arrays representing other unspecified four color samplings

For the convenience of notation and terminology in this document, the variables and terms associated with these arrays can be referred to as luma and chroma regardless of the actual color representation method in use. The values of the variables SubWidthC, SubHeightC, and NumComps depend on the chroma format sampling structure as specified in . The chroma format sampling structure is signaled through chroma_format_idc. Other values of chroma_format_idc, SubWidthC, SubHeightC, and NumComps may be specified in future versions of this document. SubWidthC, SubHeightC, and NumComps values derived from chroma_format_idc

chroma_format_idc	Chroma format	SubWidthC	SubHeightC	NumComps
0	4:0:0	1	1	1
1	reserved	reserved	reserved	reserved
2	4:2:2	2	1	3
3	4:4:4	1	1	3
4	4:4:4:4	1	1	4
5..7	reserved	reserved	reserved	reserved

In 4:0:0 sampling, there is only one sample array that can be considered as the luma array. In 4:2:2 sampling, each of the two chroma arrays has the same height and half the width of the luma array. In 4:4:4 sampling and 4:4:4:4 sampling, all the sample arrays have the same height and width as the luma array. The number of bits necessary for the representation of each of the samples in the luma and chroma arrays in a video sequence is in the range of 10 to 16, inclusive. When the value of chroma_format_idc is equal to 2, the chroma samples are co-sited with the corresponding luma samples; the nominal locations in a frame are as shown in .

Nominal vertical and horizontal locations of 4:2:2 luma and chroma samples in a frame & * & * & * & * & * ... & * & * & * & * & * ... & * & * & * & * & * ... & * & * & * & * & * ... ... & - location where both luma and chroma sample exist * - location where only luma sample exist

For each frame, when the value of chroma_format_idc is equal to 3 or 4, all of the array samples are co-sited; the nominal locations in a frame are as shown in .

Nominal vertical and horizontal locations of 4:4:4 and 4:4:4:4 luma and chroma samples in a frame & & & & & & & & & & ... & & & & & & & & & & ... & & & & & & & & & & ... & & & & & & & & & & ... ... & - location where both luma and chroma sample exist

Samples are processed in units of MBs. The variables MbWidth and MbHeight, which specify the width and height of the luma arrays for each MB, are defined as follows:

• MbWidth = 16
• MbHeight = 16

The variables MbWidthC and MbHeightC, which specify the width and height of the chroma arrays for each MB, are derived as follows:

• MbWidthC = MbWidth // SubWidthC
• MbHeightC = MbHeight // SubHeightC

Partitioning of a Frame

Partitioning of a Frame into Tiles This section specifies how a frame is partitioned into tiles. A frame is divided into tiles. A tile is a group of MBs that cover a rectangular region of a frame and is processed independently of other tiles. Every tile has the same width and height, except possibly tiles at the right or bottom frame boundary when the frame width or height is not a multiple of the tile width or height, respectively. The tiles in a frame are scanned in raster order. Within a tile, the MBs are scanned in raster order. Each MB is comprised of one (MbWidth) x (MbHeight) luma array and zero, two, or three corresponding chroma sample arrays. For example, a frame is divided into 6 tiles (3 tile columns and 2 tile rows) as shown in . In this example, the tile size is defined as 4 column MBs and 4 row MBs. In case of the third and sixth tiles (in raster order), the tile size is 2 column MBs and 4 row MBs since the frame width is not a multiple of the tile width.

Frame with 10 by 8 MBs that is partitioned into 6 tiles +===================+===================+=========+ # | | | # MB | MB | MB | MB # MB | MB # +-------------------+-------------------+---------+ # | | | # MB | MB | MB | MB # MB | MB # +----- tile -----+-------------------+---------+ # | | | # MB | MB | MB | MB # MB | MB # +-------------------+-------------------+---------+ # | | | # MB | MB | MB | MB # MB | MB # +===================+===================+=========+ # MB | MB | MB | MB # MB | MB | MB | MB # MB | MB # +-------------------+-------------------+---------+ # MB | MB | MB | MB # MB | MB | MB | MB # MB | MB # +-------------------+-------------------+---------+ # MB | MB | MB | MB # MB | MB | MB | MB # MB | MB # +-------------------+-------------------+---------+ # MB | MB | MB | MB # MB | MB | MB | MB # MB | MB # +===================+===================+=========+ #,= tile boundary |,- MB boundary

Spatial or Component-Wise Partitioning The following divisions of processing elements form spatial or component-wise partitioning:

• the division of each frame into components;
• the division of each frame into tile columns;
• the division of each frame into tile rows;
• the division of each tile column into tiles;
• the division of each tile row into tiles;
• the division of each tile into color components;
• the division of each tile into MBs;
• the division of each MB into blocks.

Scanning Processes

Zig-Zag Scan This process converts a two dimensional array into an one-dimensional array. The process starts at the top-left position in the block and then moves diagonally, changing direction at the edges of the block until it reaches the bottom-right position. shows an example of scanning order for 4x4 size block.

Example of zig-zag scanning order for 4x4 block +===================+ # 00 | 01 | 05 | 06 # +-------------------+ # 02 | 04 | 07 | 12 # +-------------------+ # 03 | 08 | 11 | 13 # +-------------------+ # 09 | 10 | 14 | 15 # +===================+

Inputs to this process are:

• a variable blkWidth specifying the width of a block, and
• a variable blkHeight specifying the height of a block.

Output of this process is the array zigZagScan[sPos]. The array index sPos specifies the scan position ranging from 0 to (blkWidth * blkHeight)-1. Depending on the value of blkWidth and blkHeight, the array zigZagScan is derived as follows:

Pseudocode for zig-zag scan pos = 0 zigZagScan[pos] = 0 pos++ for(line = 1; line < (blkWidth + blkHeight - 1); line++){ if(line % 2){ x = min(line, blkWidth - 1) y = max(0, line - (blkWidth - 1)) while(x >=0 && y < blkHeight){ zigZagScan[pos] = y * blkWidth + x pos++ x-- y++ } } else{ y = min(line, blkHeight - 1) x = max(0, line - (blkHeight - 1)) while(y >= 0 && x < blkWidth){ zigZagScan[pos] = y * blkWidth + x pos++ x++ y-- } } }

Inverse Scan Inputs to this process are:

• a variable blkWidth specifying the width of a block, and
• a variable blkHeight specifying the height of a block.

Output of this process is the array inverseScan[rPos]. The array index rPos specifies the raster scan position ranging from 0 to (blkWidth * blkHeight)-1. Depending on the value of blkWidth and blkHeight, the array inverseScan is derived as follows:

• The variable forwardScan is derived by invoking the zig-zag scan order initialization process as specified in with input parameters blkWidth and blkHeight.
• The output variable inverseScan is derived as follows:

Pseudocode for inverse zig-zag scan for(pos = 0; pos < blkWidth * blkHeight; pos++){ inverseScan[forwardScan[pos]] = pos }

Syntax and Semantics

Method of Specifying Syntax The syntax tables specify a superset of the syntax of all allowed bitstreams. Note that a decoder MUST implement some means for identifying entry points into the bitstream and some means to identify and handle non-conforming bitstreams. The methods for identifying and handling errors and other such situations are not specified in this document. The APV bitstream is described using syntax code based on the C programming language -- including use of if/else, while, and for -- as well as functions defined within this document. The syntax table in syntax code is presented in a two-column format such as shown in . In this form, the type column provides a type referenced in that same line of syntax code by using the syntax elements processing functions defined in .

A depiction of type-labeled syntax code for syntax description in this document syntax code | type --------------------------------------------------------------|----- ExampleSyntaxCode(){ | operations | syntax_element | u(n) } |

Syntax Functions and Descriptors The functions presented in this document are used in the syntactical description. These functions are expressed in terms of the value of a bitstream pointer that indicates the position of the next bit to be read by the decoding process from the bitstream.

byte_aligned()

• If the current position in the bitstream is on the last bit of a byte, i.e., the next bit in the bitstream is the first bit in a byte, the return value of byte_aligned() is equal to TRUE.
• Otherwise, the return value of byte_aligned() is equal to FALSE.

more_data_in_tile()

• If the current position in the i-th tile() syntax structure is less than TileSize[i] in bytes from the beginning of the tile_header() syntax structure of the i-th tile, the return value of more_data_in_tile() is equal to TRUE.
• Otherwise, the return value of more_data_in_tile() is equal to FALSE.

next_bits(n) This function provides the next n bits in the bitstream for comparison purposes, without advancing the bitstream pointer.

read_bits(n) This function indicates that the next n bits from the bitstream are to be read and it advances the bitstream pointer by n bit positions. When n is equal to 0, read_bits(n) is specified to return a value equal to 0 and to not advance the bitstream pointer.

Syntax Element Processing Functions

b(8):

byte having any pattern of bit string (8 bits). The parsing process for this descriptor is specified by the return value of the function read_bits(8).

f(n):

fixed-pattern bit string using n bits written (from left to right) with the left bit first, i.e., big endian format. The parsing process for this descriptor is specified by the return value of the function read_bits(n).

u(n):

unsigned integer using n bits. The parsing process for this descriptor is specified by the return value of the function read_bits(n) interpreted as a binary representation of an unsigned integer with the most significant bit written first.

h(v):

variable-length entropy coded syntax element with the left bit first, i.e., big endian format. The parsing process for this descriptor is specified in .

List of Syntax and Semantics

Access Unit

access unit syntax code syntax code | type --------------------------------------------------------------|----- access_unit(au_size){ | signature | f(32) currReadSize = 4 | do(){ | pbu_size | u(32) currReadSize += 4 | pbu() | currReadSize += pbu_size | } while (au_size > currReadSize) | } |

signature

A four-character code that identifies the bitstream as an APV AU. The value MUST be 'aPv1' (0x61507631).

pbu_size

the size of a primitive bitstream unit in bytes. A value of 0 is prohibited and the value of 0xFFFFFFFF for pbu_size is reserved for future use.

Note: An AU consists of one primary frame, zero or more non-primary frames such as a frame for additional view, zero or more alpha frames, zero or more depth frames, zero or more preview frames such as a frame with smaller resolution, zero or more metadata, and zero or more fillers.

Primitive Bitstream Unit

primitive bitstream unit syntax code syntax code | type --------------------------------------------------------------|----- pbu(){ | pbu_header() | if((1 <= pbu_type && pbu_type <=2) || | (25 <= pbu_type && pbu_type <= 27)) | frame() | else if(pbu_type == 65) | au_info() | else if(pbu_type == 66) | metadata() | else if (pbu_type == 67) | filler() | } |

Primitive Bitstream Unit Header

primitive bitstream unit header syntax code syntax code | type --------------------------------------------------------------|----- pbu_header(){ | pbu_type | u(8) group_id | u(16) reserved_zero_8bits | u(8) } |

pbu_type

indicates the type of data in a PBU listed in . Other values of pbu_type are reserved for future use. List of PBU types

pbu_type	meaning	notes
0	reserved
1	primary frame
2	non-primary frame
3...24	reserved
25	preview frame
26	depth frame
27	alpha frame
28...64	reserved
65	access unit information
66	metadata
67	filler
68...255	reserved

Note: A PBU with pbu_type equal to 65 (access unit information) may happen in an AU. If it exists, it MUST be the first PBU in an AU, and it can be ignored by a decoder.

group_id

indicates the identifier to associate a coded frame with metadata. More than two frames can have the same group_id in a single AU. A primary frame and a non-primary frame MUST have different group_id values, and two non-primary frames MUST have different group_id values. When the value of group_id is equal to 0, the value of pbu_type MUST be greater than 64. The value of 0xFFFF for group_id is reserved for future use.

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

Frame

frame() syntax code syntax code | type --------------------------------------------------------------|----- frame(){ | frame_header() | for(i = 0; i < NumTiles; i++){ | tile_size[i] | u(32) tile(i) | } | filler() | } |

tile_size[i]

indicates the size in bytes of i-th tile data (i.e., tile(i)) in raster order in a frame. The value of 0 for tile_size[i] is reserved for future use. The variable TileSize[i] is set equal to tile_size[i].

Frame Header

frame_header() syntax code syntax code | type --------------------------------------------------------------|----- frame_header(){ | frame_info() | reserved_zero_8bits | u(8) color_description_present_flag | u(1) if(color_description_present_flag){ | color_primaries | u(8) transfer_characteristics | u(8) matrix_coefficients | u(8) full_range_flag | u(1) } | use_q_matrix | u(1) if(use_q_matrix){ | quantization_matrix() | } | tile_info() | reserved_zero_8bits | u(8) byte_alignment() | } |

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

color_description_present_flag equal to 1

specifies that color_primaries, transfer_characteristics, and matrix_coefficients are present. color_description_present_flag equal to 0 specifies that color_primaries, transfer_characteristics, and matrix_coefficients are not present.

color_primaries

MUST have the semantics of ColourPrimaries as specified in . When the color_primaries syntax element is not present, the value of color_primaries is inferred to be equal to 2.

transfer_characteristics

MUST have the semantics of TransferCharacteristics as specified in . When the transfer_characteristics syntax element is not present, the value of transfer_characteristics is inferred to be equal to 2.

matrix_coefficients

MUST have the semantics of MatrixCoefficients as specified in . When the matrix_coefficients syntax element is not present, the value of matrix_coefficients is inferred to be equal to 2.

full_range_flag

MUST have the semantics of VideoFullRangeFlag as specified in . When the full_range_flag syntax element is not present, the value of full_range_flag is inferred to be equal to 0.

use_q_matrix

with a value of 1 specifies that the quantization matrices are present. A value of 0 specifies that the quantization matrices are not present.

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

Frame Information

frame_info() syntax code syntax code | type --------------------------------------------------------------|----- frame_info(){ | profile_idc | u(8) level_idc | u(8) band_idc | u(3) reserved_zero_5bits | u(5) frame_width | u(24) frame_height | u(24) chroma_format_idc | u(4) bit_depth_minus8 | u(4) capture_time_distance | u(8) reserved_zero_8bits | u(8) } |

profile_idc

indicates a profile to which the coded frame conforms as specified in . Bitstreams SHALL NOT contain values of profiles_idc other than those specified in . Other values of profile_idc are reserved for future use.

level_idc

indicates a level to which the coded frame conforms as specified in . Bitstreams SHALL NOT contain values of level_idc other than those specified in . Other values of level_idc are reserved for future use.

band_idc

specifies a maximum coded data rate of level_idc as specified in . Bitstreams SHALL NOT contain values of band_idc other than those specified in . The value of band_idc MUST be in the range of 0 to 3. Other values of band_idc are reserved for future use.

reserved_zero_5bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

frame_width

specifies the width of the frame in units of luma samples. frame_width MUST be a multiple of 2 when chroma_format_idc has a value of 2. The value 0 is reserved for future use.

frame_height

specifies the height of the frame in units of luma samples. The value 0 is reserved for future use.

The variables FrameWidthInMbsY, FrameHeightInMbsY, FrameWidthInSamplesY, FrameHeightInSamplesY, FrameWidthInSamplesC, FrameHeightInSamplesC, FrameSizeInMbsY, and FrameSizeInSamplesY are derived as follows:

• FrameWidthInSamplesY = frame_width
• FrameHeightInSamplesY = frame_height
• FrameWidthInMbsY = ceil(FrameWidthInSamplesY / MbWidth)
• FrameHeightInMbsY = ceil(FrameHeightInSamplesY / MbHeight)
• FrameWidthInSamplesC = FrameWidthInSamplesY // SubWidthC
• FrameHeightInSamplesC = FrameHeightInSamplesY // SubHeightC
• FrameSizeInMbsY = FrameWidthInMbsY * FrameHeightInMbsY
• FrameSizeInSamplesY = FrameWidthInSamplesY * FrameHeightInSamplesY

chroma_format_idc

specifies the chroma sampling relative to the luma sampling as specified in . The value of chroma_format_idc MUST be 0, 2, 3, or 4. Other values are reserved for future use.

bit_depth_minus8

specifies the bit depth of the samples. The variables BitDepth and QpBdOffset are derived as follows:

• BitDepth = bit_depth_minus8 + 8
• QpBdOffset = bit_depth_minus8 * 6

bit_depth_minus8 MUST be in the range of 2 to 8, inclusive. Other values are reserved for future use.

capture_time_distance

indicates the time difference between the capture time of the frames in the previous access unit and frames in the current access unit in milliseconds if there has been any access unit preceding the access unit this frame belongs to.

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

Quantization Matrix

quantization_matrix() syntax code syntax code | type --------------------------------------------------------------|----- quantization_matrix(){ | for(i = 0; i < NumComps; i++){ | for(y = 0; y < 8; y++){ | for(x = 0; x < 8; x++){ | q_matrix[i][x][y] | u(8) } | } | } | } |

q_matrix[i][x][y]

specifies a scaling value in the quantization matrices. When q_matrix[i][x][y] is not present, it is inferred to be equal to 16. The array index i specifies an indicator for the color component; when chroma_format_idc is equal to 2 or 3, the value of the index i is equal to 0 for Y component, 1 for Cb, and 2 for Cr. The value of 0 for q_matrix[i][x][y] is reserved for future use. The quantization matrix, QMatrix[i][x][y], is derived as follows:

• QMatrix[i][x][y] = q_matrix[i][x][y]

Tile Info

tile_info() syntax code syntax code | type --------------------------------------------------------------|----- tile_info(){ | tile_width_in_mbs | u(20) tile_height_in_mbs | u(20) startMb = 0 | for(i = 0; startMb < FrameWidthInMbsY; i++){ | ColStarts[i] = startMb * MbWidth | startMb += tile_width_in_mbs | } | ColStarts[i] = FrameWidthInMbsY*MbWidth | TileCols = i | startMb = 0 | for(i = 0; startMb < FrameHeightInMbsY; i++){ | RowStarts[i] = startMb * MbHeight | startMb += tile_height_in_mbs | } | RowStarts[i] = FrameHeightInMbsY*MbHeight | TileRows = i | NumTiles = TileCols * TileRows | tile_size_present_in_fh_flag | u(1) if(tile_size_present_in_fh_flag){ | for(i = 0; i < NumTiles; i++){ | tile_size_in_fh[i] | u(32) } | } | } |

tile_width_in_mbs

specifies the width of a tile in units of MBs.

tile_height_in_mbs

specifies the height of a tile in units of MBs.

tile_size_present_in_fh_flag

equal to 1 specifies that tile_size_in_fh[i] is present in the frame header. tile_size_present_in_fh_flag equal to 0 specifies that tile_size_in_fh[i] is not present in the frame header.

tile_size_in_fh[i]

indicates the size in bytes of i-th tile data in raster order in a frame. The value of tile_size_in_fh[i] MUST have the same value with tile_size[i]. When it is not present, the value of tile_size_in_fh[i] is inferred to be equal to tile_size[i]. The value of 0 for tile_size_in_fh[i] is reserved for future use.

Access Unit Information

au_info() syntax code syntax code | type --------------------------------------------------------------|----- au_info(){ | num_frames | u(16) for(i = 0; i < num_frames; i++){ | pbu_type | u(8) group_id | u(16) reserved_zero_8bits | u(8) frame_info() | } | reserved_zero_8bits | u(8) byte_alignment() | filler() | } |

num_frames

indicates the number of frames contained in the current AU.

pbu_type

has the same semantics as pbu_type in the pbu_header() syntax. Note: The value of pbu_type MUST be 1, 2, 25, 26, or 27 in bitstreams conforming to this document.

group_id

has the same semantics as group_id in the pbu_header() syntax.

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

Metadata

metadata() syntax code syntax code | type --------------------------------------------------------------|----- metadata(){ | metadata_size | u(32) currReadSize = 0 | do{ | payloadType = 0 | while(next_bits(8) == 0xFF){ | ff_byte | f(8) payloadType += ff_byte | currReadSize++ | } | metadata_payload_type | u(8) payloadType += metadata_payload_type | currReadSize++ | | payloadSize = 0 | while(next_bits(8) == 0xFF){ | ff_byte | f(8) payloadSize += ff_byte | currReadSize++ | } | metadata_payload_size | u(8) payloadSize += metadata_payload_size | currReadSize++ | | metadata_payload(payloadType, payloadSize) | currReadSize += payloadSize | } while(metadata_size > currReadSize) | filler() | } |

metadata_size

specifies the size of metadata before filler() in the current PBU.

ff_byte

is a byte equal to 0xFF.

metadata_payload_type

specifies the last byte of the payload type of a metadata.

metadata_payload_size

specifies the last byte of the payload size of a metadata.

Syntax and semantics of metadata_payload() are specified in .

Filler

filler() syntax code syntax code | type --------------------------------------------------------------|----- filler(){ | while(next_bits(8) == 0xFF) | ff_byte | f(8) } |

ff_byte

is a byte equal to 0xFF.

Tile

tile() syntax code syntax code | type --------------------------------------------------------------|----- tile(tileIdx){ | tile_header(tileIdx) | for(i = 0; i < NumComps; i++){ | tile_data(tileIdx, i) | } | while(more_data_in_tile()){ | tile_dummy_byte | b(8) } | } |

tile_dummy_byte

has any pattern of 8-bit string.

Tile Header

tile_header() syntax code syntax code | type --------------------------------------------------------------|----- tile_header(tileIdx){ | tile_header_size | u(16) tile_index | u(16) for(i = 0; i < NumComps; i++){ | tile_data_size[i] | u(32) } | for(i = 0; i < NumComps; i++){ | tile_qp[i] | u(8) } | reserved_zero_8bits | u(8) byte_alignment() | } |

tile_header_size

indicates the size of the tile header in bytes.

tile_index

specifies the tile index in raster order in a frame. tile_index MUST have the same value as tileIdx.

tile_data_size[i]

indicates the size of the i-th color component data in a tile in bytes. The array index i specifies an indicator for the color component; when chroma_format_idc is equal to 2 or 3, the value of the index i is equal to 0 for Y component, 1 for Cb, and 2 for Cr. The value of 0 for tile_data_size[i] is reserved for future use.

tile_qp[i]

specifies the quantization parameter value for i-th color component. The array index i specifies an indicator for the color component; when chroma_format_idc is equal to 2 or 3, the value of the index i is equal to 0 for Y component, 1 for Cb, and 2 for Cr. The Qp[i] to be used for the MBs in the tile are derived as follows:

• Qp[i] = tile_qp[i] - QpBdOffset
• Qp[i] MUST be in the range of -QpBdOffset to 51, inclusive.

reserved_zero_8bits

MUST be equal to 0 in bitstreams conforming to the profiles specified in . Values of reserved_zero_8bits greater than 0 are reserved for future use. Decoders conforming to the profiles specified in MUST ignore PBU with values of reserved_zero_8bits greater than 0.

Tile Data

tile_data() syntax code syntax code | type --------------------------------------------------------------|----- tile_data(tileIdx, cIdx){ | x0 = ColStarts[tileIdx % TileCols] | y0 = RowStarts[tileIdx // TileCols] | numMbColsInTile = (ColStarts[tileIdx % TileCols + 1] - | ColStarts[tileIdx % TileCols]) // MbWidth | numMbRowsInTile = (RowStarts[tileIdx // TileCols + 1] - | RowStarts[tileIdx // TileCols]) // MbHeight | numMbsInTile = numMbColsInTile * numMbRowsInTile | PrevDC = 0 | PrevDcDiff = 20 | Prev1stAcLevel = 0 | for(i = 0; i < numMbsInTile; i++){ | xMb = x0 + ((i % numMbColsInTile) * MbWidth) | yMb = y0 + ((i // numMbColsInTile) * MbHeight) | macroblock_layer(xMb, yMb, cIdx) | } | byte_alignment() | } |

The tile_data() syntax calculates the location of the macroblocks belonging to each tile and collects them.

Macroblock Layer

macroblock_layer() syntax code syntax code | type --------------------------------------------------------------|----- macroblock_layer(xMb, yMb, cIdx){ | subW = (cIdx == 0)? 1 : SubWidthC | subH = (cIdx == 0)? 1 : SubHeightC | blkWidth = (cIdx == 0)? MbWidth : MbWidthC | blkHeight = (cIdx == 0)? MbHeight : MbHeightC | TrSize = 8 | for(y = 0; y < blkHeight; y += TrSize){ | for(x = 0; x < blkWidth; x += TrSize){ | abs_dc_coeff_diff | h(v) if(abs_dc_coeff_diff) | sign_dc_coeff_diff | u(1) TransCoeff[cIdx][xMb // subW + x][yMb // subH + y] = | PrevDC + abs_dc_coeff_diff * | (1 - 2*sign_dc_coeff_diff) | PrevDC = | TransCoeff[cIdx][xMb // subW + x][yMb // subH + y] | PrevDcDiff = abs_dc_coeff_diff | ac_coeff_coding(xMb // subW + x, yMb // subH + y, | log2(TrSize), log2(TrSize), cIdx) | } | } | } |

abs_dc_coeff_diff

specifies the absolute value of the difference between the current DC transform coefficient level and PrevDC.

sign_dc_coeff_diff

specifies the sign of the difference between the current DC transform coefficient level and PrevDC. sign_dc_coeff_diff equal to 0 specifies that the difference has a positive value. sign_dc_coeff_diff equal to 1 specifies that the difference has a negative value.

The transform coefficients are represented by the arrays TransCoeff[cIdx][x0][y0]. The array indices x0, y0 specify the location (x0, y0) relative to the top-left sample for each component of the frame. The array index cIdx specifies an indicator for the color component; when chroma_format_idc is equal to 2 or 3, the value of the index i is equal to 0 for Y component, 1 for Cb, and 2 for Cr. The value of TransCoeff[cIdx][x0][y0] MUST be in the range of -32768 to 32767, inclusive.

AC Coefficient Coding

ac_coeff_coding() syntax code syntax code | type --------------------------------------------------------------|----- ac_coeff_coding(x0, y0, log2BlkWidth, log2BlkHeight, cIdx){ | scanPos = 1 | firstAC = 1 | PrevLevel = Prev1stAcLevel | PrevRun = 0 | do{ | coeff_zero_run | h(v) for(i = 0; i < coeff_zero_run; i++){ | blkPos = ScanOrder[scanPos] | xC = blkPos & ((1 << log2BlkWidth) - 1) | yC = blkPos >> log2BlkWidth | TransCoeff[cIdx][x0+xC][y0 + yC] = 0 | scanPos++ | } | PrevRun = coeff_zero_run | if(scanPos < (1 << (log2BlkWidth + log2BlkHeight))){ | abs_ac_coeff_minus1 | h(v) sign_ac_coeff | u(1) level = (abs_ac_coeff_minus1 + 1) * | (1 - 2 * sign_ac_coeff) | blkPos = ScanOrder[scanPos] | xC = blkPos & ((1 << log2BlkWidth) - 1) | yC = blkPos >> log2BlkWidth | TransCoeff[cIdx][x0 + xC][y0 + yC] = level | scanPos++ | PrevLevel = abs_ac_coeff_minus1 + 1 | if(firstAC == 1){ | firstAC = 0 | Prev1stAcLevel = PrevLevel | } | } | } while(scanPos < (1 << (log2BlkWidth + log2BlkHeight))) | } |

coeff_zero_run

specifies the number of zero-valued transform coefficient levels that are located before the position of the next non-zero transform coefficient level in a scan of transform coefficient levels.

abs_ac_coeff_minus1

plus 1 specifies the absolute value of an AC transform coefficient level at the given scanning position.

sign_ac_coeff

specifies the sign of an AC transform coefficient level for the given scanning position. sign_ac_coeff equal to 0 specifies that the corresponding AC transform coefficient level has a positive value. sign_ac_coeff equal to 1 specifies that the corresponding AC transform coefficient level has a negative value.

The array ScanOrder[sPos] specifies the mapping of the zig-zag scan position sPos, ranging from 0 to (1 << log2BlkWidth) * (1 << log2BlkHeight) - 1, inclusive, to a raster scan position rPos. ScanOrder is derived by invoking with input parameters blkWidth equal to (1 << log2BlkWidth) and blkHeight equal to (1 << log2BlkHeight).

Byte Alignment

byte_alignment() syntax code syntax code | type --------------------------------------------------------------|----- byte_alignment(){ | while(!byte_aligned()) | alignment_bit_equal_to_zero | f(1) } |

alignment_bit_equal_to_zero

MUST be equal to 0.

Decoding Process This process is invoked to obtain a decoded frame from a bitstream. Input to this process is a bitstream of a coded frame. Output of this process is a decoded frame. The decoding process operates as follows for the current frame:

• The syntax structure for a coded frame is parsed to obtain the parsed syntax structures.
• The processes in Sections , , and specify the decoding processes using syntax elements in all syntax structures. For bitstreams conforming to this document, the coded tiles of the frame MUST contain tile data for every MB of the frame, such that the division of the frame into tiles and the division of the tiles into MBs form a partitioning of the frame.
• After all the tiles in the current frame have been decoded, the decoded frame is cropped using the cropping rectangle if FrameWidthInSamplesY is not equal to FrameWidthInMbsY * MbWidth or FrameHeightInSamplesY is not equal to FrameHeightInMbsY * MbHeight.
• The cropping rectangle, which specifies the samples of a frame that are output, is derived as follows:
  • The cropping rectangle contains the luma samples with horizontal frame coordinates from 0 to FrameWidthInSampleY - 1 and vertical frame coordinates from 0 to FrameHeightInSamplesY - 1, inclusive.
  • The cropping rectangle contains the two chroma arrays having frame coordinates (x//SubWidthC, y//SubHeightC), where (x,y) are the frame coordinates of the specified luma samples.

MB Decoding Process This process is invoked for each MB. Input to this process is a luma location (xMb, yMb) specifying the top-left sample of the current luma MB relative to the top-left luma sample of the current frame. Outputs of this process are the reconstructed samples of all color components. The total number of color components is indicated by the value of NumComps for the current MB. For example, when chroma_format_idc is equal to 2 or 3, the value of NumComps is equal to 3 and three components, Y component, Cb component, and Cr component, are reconstructed The following steps apply:

• Let recSamples[0] be a (MbWidth)x(MbHeight) array of the reconstructed samples of the first color component (when chroma_format_idc is equal to 2 or 3, Y).
• The block reconstruction process as specified in is invoked with the luma location (xMb, yMb), the variable nBlkW set equal to MbWidth, the variable nBlkH set equal to MbHeight, the variable cIdx set equal to 0, and the (MbWidth)x(MbHeight) array recSamples[0] as inputs. The output is a modified version of the (MbWidth)x(MbHeight) array recSamples[0], which is the reconstructed samples of the first color component for the current MB.
• When chroma_format_idc is not equal to 0, let recSamples[1] be a (MbWidthC)x(MbHeightC) array of the reconstructed samples of the second color component. For example, when chroma_format_idc is equal to 2 or 3, recSamples[1] is the Cb color component.
• When chroma_format_idc is not equal to 0, the block reconstruction process as specified in is invoked with the luma location (xMb, yMb), the variable nBlkW set equal to MbWidthC, the variable nBlkH set equal to MbHeightC, the variable cIdx set equal to 1, and the (MbWidthC)x(MbHeightC) array recSamples[1] as inputs. The output is a modified version of the (MbWidthC)x(MbHeightC) array recSamples[1], which is the reconstructed samples of the second color component for the current MB.
• When chroma_format_idc is not equal to 0, let recSamples[2] be a (MbWidthC)x(MbHeightC) array of the reconstructed samples of the third color component. For example, when chroma_format_idc is equal to 2 or 3, recSamples[2] is the Cr color component.
• When chroma_format_idc is not equal to 0, the block reconstruction process as specified in is invoked with the luma location (xMb, yMb), the variable nBlkW set equal to MbWidthC, the variable nBlkH set equal to MbHeightC, the variable cIdx set equal to 2, and the (MbWidthC)x(MbHeightC) array recSamples[2] as inputs. The output is a modified version of the (MbWidthC)x(MbHeightC) array recSamples[2], which is the reconstructed samples of the third color component for the current MB.
• When chroma_format_idc is equal to 4, let recSamples[3] be a (MbWidthC)x(MbHeightC) array of the reconstructed samples of the fourth color component.
• When chroma_format_idc is equal to 4, the block reconstruction process as specified in is invoked with the luma location (xMb, yMb), the variable nBlkW set equal to MbWidthC, the variable nBlkH set equal to MbHeightC, the variable cIdx set equal to 3, and the (MbWidthC)x(MbHeightC) array recSamples[3] as inputs. The output is a modified version of the (MbWidthC)x(MbHeightC) array recSamples[3], which is the reconstructed samples of the fourth color component for the current MB.

Block Reconstruction Process Inputs to this process are:

• a luma location (xMb, yMb) specifying the top-left sample of the current MB relative to the top-left luma sample of the current frame,
• two variables nBlkW and nBlkH specifying the width and the height of the current block,
• a variable cIdx specifying the color component of the current block, and
• an (nBlkW)x(nBlkH) array of recSamples of a reconstructed block.

Output of this process is a modified version of the (nBlkW)x(nBlkH) array recSamples of reconstructed samples. The following applies:

• The variables numBlkX and numBlkY are derived as follows:
  • numBlkX = nBlkW // TrSize
  • numBlkY = nBlkH // TrSize
• For yIdx = 0..numBlkY - 1, the following applies:
  • For xIdx = 0..numBlkX - 1, the following applies:
    • The variables xBlk and yBlk are derived as follows:
      • xBlk = xMb // (cIdx==0? 1: SubWidthC) + xIdx*TrSize
      • yBlk = yMb // (cIdx==0? 1: SubHeightC) + yIdx*TrSize
    • The scaling and transformation process as specified in is invoked with the location (xBlk, yBlk), the variable cIdx set equal to cIdx, the transform width nBlkW set equal to TrSize, and the transform height nBlkH set equal to TrSize as inputs. The output is a (TrSize)x(TrSize) array r of a reconstructed block.
    • The (TrSize)x(TrSize) array recSamples is modified as follows:
      • recSamples[(xIdx * TrSize) + i, (yIdx * TrSize) + j] = r[i,j], with i=0..TrSize-1, j=0..TrSize-1

Scaling and Transformation Process Inputs to this process are:

• a location (xBlkY, yBlkY) of the current color component specifying the top-left sample of the current block relative to the top-left sample of the current frame,
• a variable cIdx specifying the color component of the current block,
• a variable nBlkW specifying the width of the current block, and
• a variable nBlkH specifying the height of the current block.

Output of this process is the (nBlkW)x(nBlkH) array of reconstructed samples r with elements r[x][y]. The quantization parameter qP is derived as follows:

• qP = Qp[cIdx] + QpBdOffset

The (nBlKW)x(nBlkH) array of reconstructed samples r is derived as follows:

• The scaling process for transform coefficients as specified in is invoked with the block location (xBlkY, yBlkY), the block width nBlkW and the block height nBlkH, the color component variable cIdx, and the quantization parameter qP as inputs. The output is an (nBlkW)x(nBlkH) array of scaled transform coefficients d.
• The transformation process for scaled transform coefficients as specified in is invoked with the block location (xBlkY, yBlkY), the block width nBlkW and the block height nBlkH, the color component variable cIdx, and the (nBlkW)x(nBlkH) array of scaled transform coefficients d as inputs. The output is an (nBlkW)x(nBlkH) array of reconstructed samples r.
• The variable bdShift is derived as follows:
  • bdShift = 20 - BitDepth
• The reconstructed sample values r[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1 are modified as follows:
  • r[x][y] = clip(0, (1 << BitDepth)-1, ((r[x][y]+(1 << (bdShift-1)))>>bdShift) + (1 << (BitDepth-1)))

Scaling Process for Transform Coefficients Inputs to this process are:

• a location (xBlkY, yBlkY) of the current color component specifying the top-left sample of the current block relative to the top-left sample of the current frame,
• a variable nBlkW specifying the width of the current block,
• a variable nBlkH specifying the height of the current block,
• a variable cIdx specifying the color component of the current block, and
• a variable qP specifying the quantization parameter.

Output of this process is the (nBlkW)x(nBlkH) array d of scaled transform coefficients with elements d[x][y]. The variable bdShift is derived as follows:

• bdShift = BitDepth + ((log2(nBlkW) + log2(nBlkH)) // 2) - 5

The list levelScale[] is specified as follows:

• levelScale[k] = {40, 45, 51, 57, 64, 71} with k = 0..5.

For the derivation of the scaled transform coefficients d[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1, the following applies:

• The scaled transform coefficient d[x][y] is derived as follows:
  • d[x][y] = clip(-32768, 32767, ((TransCoeff[cIdx][xBlkY][yBlkY] * QMatrix[cIdx][x][y] * levelScale[qP % 6] << (qP//6)) + (1 << (bdShift-1)) >> bdShift))

Process for Scaled Transform Coefficients

General Inputs to this process are:

• a location (xBlkY, yBlkY) of the current color component specifying the top-left sample of the current block relative to the top-left sample of the current frame,
• a variable nBlkW specifying the width of the current block,
• a variable nBlkH specifying the height of the current block, and
• an (nBlkW)x(nBlkH) array d of scaled transform coefficients with elements d[x][y].

Output of this process is the (nBlkW)x(nBlkH) array r of reconstructed samples with elements r[x][y]. The (nBlkW)x(nBlkH) array r of reconstructed samples is derived as follows:

• Each (vertical) column of scaled transform coefficients d[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1 is transformed to e[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1 by invoking the one-dimensional transformation process as specified in for each column x = 0..nBlkW - 1 with the size of the transform block nBlkH, and the list d[x][y] with y = 0..nBlkH - 1 as inputs. The output is the list e[x][y] with y = 0..nBlkH - 1.
• The following applies:
  • g[x][y] = (e[x][y] + 64) >> 7
• Each (horizontal) row of the resulting array g[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1 is transformed to r[x][y] with x = 0..nBlkW - 1, y = 0..nBlkH - 1 by invoking the one-dimensional transformation process as specified in for each row y = 0..nBlkH - 1 with the size of the transform block nBlkW, and the list g[x][y] with x = 0..nBlkW - 1 as inputs. The output is the list r[x][y] with x = 0..nBlkW - 1.

Transformation Process Inputs to this process are:

• a variable nTbS specifying the sample size of scaled transform coefficients, and
• a list of scaled transform coefficients x with elements x[j], with j = 0..(nTbS - 1).

Output of this process is the list of transformed samples y with elements y[i], with i = 0..(nTbS - 1). The transformation matrix derivation process as specified in is invoked with the transform size nTbS as input, and the transformation matrix transMatrix as output. The list of transformed samples y[i] with i = 0..(nTbS - 1) is derived as follows:

• y[i] = sum(j = 0, nTbS - 1, transMatrix[i][j] * x[j])

Transformation Matrix Derivation Process Input to this process is a variable nTbS specifying the horizontal sample size of scaled transform coefficients. Output of this process is the transformation matrix transMatrix. The transformation matrix transMatrix is derived based on nTbs as follows:

• If nTbS is equal to 8, the following applies:

  Transform matrix for nTbS == 8 transMatrix[m][n] = { { 64, 64, 64, 64, 64, 64, 64, 64 } { 89, 75, 50, 18, -18, -50, -75, -89 } { 84, 35, -35, -84, -84, -35, 35, 84 } { 75, -18, -89, -50, 50, 89, 18, -75 } { 64, -64, -64, 64, 64, -64, -64, 64 } { 50, -89, 18, 75, -75, -18, 89, -50 } { 35, -84, 84, -35, -35, 84, -84, 35 } { 18, -50, 75, -89, 89, -75, 50, -18 } }

Parsing Process

Process for Syntax Element Type h(v) This process is invoked for the parsing of syntax elements with descriptor h(v) in and .

Process for abs_dc_coeff_diff Inputs to this process are bits for the abs_dc_coeff_diff syntax element. Output of this process is a value of the abs_dc_coeff_diff syntax element. The variable kParam is derived as follows: kParam = clip(0, 5, PrevDcDiff >> 1) The value of syntax element abs_dc_coeff_diff is obtained by invoking the parsing process for variable-length codes as specified in with kParam.

Process for coeff_zero_run Inputs to this process are bits for the coeff_zero_run syntax element. Output of this process is a value of the coeff_zero_run syntax element. The variable kParam is derived as follows: kParam = clip(0, 2, PrevRun >> 2) The value of syntax element coeff_zero_run is obtained by invoking the parsing process for variable-length codes as specified in with kParam.

Process for abs_ac_coeff_minus1 Inputs to this process are bits for the abs_ac_coeff_minus1 syntax element. Output of this process is a value of the abs_ac_coeff_minus1 syntax element. The variable kParam is derived as follows: kParam = clip(0, 4, PrevLevel >> 2) The value of syntax element abs_ac_coeff_minus1 is obtained by invoking the parsing process for variable-length codes as specified in with kParam.

Process for Variable-Length Codes Input to this process is kParam. Output of this process is a value, symbolValue, of a syntax element. The symbolValue is derived as follows:

Parsing process of symbolValue symbolValue = 0 parseExpGolomb = 1 k = kParam stopLoop = 0 if(read_bits(1) == 1){ parseExpGolomb = 0 } else{ if(read_bits (1) == 0){ symbolValue += (1 << k) parseExpGolomb = 0 } else{ symbolValue += (2 << k) parseExpGolomb = 1 } } if(parseExpGolomb){ do{ if(read_bits(1) == 1){ stopLoop = 1 } else{ symbolValue += (1 << k) k++ } } while(!stopLoop) } if(k > 0) symbolValue += read_bits(k)

where the value returned from read_bits(n) is interpreted as a binary representation of an n-bit unsigned integer with the most significant bit written first.

Codeword Generation Process for h(v) (Informative) This process specifies the code generation process for syntax elements with descriptor h(v).

Process for abs_dc_coeff_diff Input to this process is a symbol value of the abs_dc_coeff_diff syntax element. Output of this process is a codeword of the abs_dc_coeff_diff syntax element. The variable kParam is derived as follows: kParam = clip(0, 5, PrevDcDiff >> 1) The codeword of syntax element abs_dc_coeff_diff is obtained by invoking the generation process for variable-length codes as specified in with the symbol value symbolValue and kParam.

Process for coeff_zero_run Input to this process is a symbol value of the coeff_zero_run syntax element. Output of this process is a codeword of the coeff_zero_run syntax element. The variable kParam is derived as follows: kParam = clip(0, 2, PrevRun >> 2) The codeword of syntax element coeff_zero_run is obtained by invoking the generation process for variable-length codes as specified in with the symbol value symbolValue and kParam.

Process for abs_ac_coeff_minus1 Input to this process is a symbol value of the abs_ac_coeff_minus1 syntax element. Output of this process is a codeword of the abs_ac_coeff_minus1 syntax element. The variable kParam is derived as follows: kParam = clip(0, 4, PrevLevel >> 2) The codeword of syntax element abs_ac_coeff_minus1 is obtained by invoking the generation for variable-length codes as specified in with the symbol value symbolValue and kParam.

Process for Variable-Length Codes Inputs to this process are symbolVal and kParam Output of this process is a codeword of a syntax element. The codeword is derived as follows:

Generating bits from symbolValue PrefixVLCTable[3][2] = {{1, 0}, {0, 0}, {0, 1}} symbolValue = symbolVal valPrefixVLC = clip(0, 2, symbolVal >> kParam) bitCount = 0 k = kParam while(symbolValue >= (1 << k)){ symbolValue -= (1 << k) if(bitCount < 2) put_bits(PrefixVLCTable[valPrefixVLC][bitCount], 1) else put_bits(0, 1) if(bitCount >= 2) k++ bitCount++ } if(bitCount < 2) put_bits(PrefixVLCTable[valPrefixVLC][bitCount], 1) else put_bits(1, 1) if(k > 0) put_bits(symbolValue, k)

where a codeword generated from put_bits(v, n) is interpreted as a binary representation of an n-bit unsigned integer value v with the most significant bit written first.

Metadata Information

Metadata Payload

metadata_payload() syntax code syntax code | type --------------------------------------------------------------|----- metadata_payload(payloadType, payloadSize){ | if(payloadType == 4){ | metadata_itu_t_t35(payloadSize) | } | else if(payloadType == 5){ | metadata_mdcv(payloadSize) | } | else if(payloadType == 6){ | metadata_cll(payloadSize) | } | else if(payloadType == 10){ | metadata_filler(payloadSize) | } | else if(payloadType == 170){ | metadata_user_defined(payloadSize) | } | else{ | metadata_undefined(payloadSize) | } | byte_alignment() | } |

The syntax and semantics of each type of metadata are defined in .

List of Metadata Syntax and Semantics

Filler Metadata syntax code | type --------------------------------------------------------------|----- metadata_filler(payloadSize){ | for(i = 0; i < payloadSize; i++){ | ff_byte | f(8) } | } |

ff_byte

is a byte equal to 0xFF.

Recommendation ITU-T T.35 Metadata This metadata contains information registered as specified in .

metadata_itu_t_t35() syntax code syntax code | type --------------------------------------------------------------|----- metadata_itu_t_t35(payloadSize){ | itu_t_t35_country_code | b(8) readSize = payloadSize - 1 | | if(itu_t_t35_country_code == 0xFF){ | itu_t_t35_country_code_extension | b(8) readSize-- | } | | for(i = 0; i < readSize; i++){ | itu_t_t35_payload[i] | b(8) } | } |

itu_t_t35_country_code

MUST be a byte having the semantics of country code as specified in Annex A of .

itu_t_t35_country_code_extension

MUST be a byte having the semantics of country code as specified in Annex B of .

itu_t_t35_payload[i]

MUST be a byte having the semantics of data registered as specified in .

The terminal provider code and terminal provider oriented code as specified in MUST be contained in the first one or more bytes of the itu_t_t35_payload. Any remaining bytes in itu_t_t35_payload data MUST be data having syntax and semantics as specified by the entity identified by the country code and terminal provider code. Note that any metadata to be carried with this type of payload is expected to have been registered through either national administrator, the Alliance for Telecommunications Industry Solutions (ATIS) or the ITUT-T Telecommunication Standardization Bureau (TSB) as specified in .

Mastering Display Color Volume Metadata

metadata_mdcv() syntax code syntax code | type --------------------------------------------------------------|----- metadata_mdcv(payloadSize){ | for(i = 0; i < 3; i++){ | primary_chromaticity_x[i] | u(16) primary_chromaticity_y[i] | u(16) } | white_point_chromaticity_x | u(16) white_point_chromaticity_y | u(16) max_mastering_luminance | u(32) min_mastering_luminance | u(32) } |

primary_chromaticity_x[i]

specifies a 0.16 fixed-point format of X chromaticity coordinate of mastering display in terms of CIE 1931 as specified in , where i = 0, 1, 2 specifies Red, Green, Blue, respectively.

primary_chromaticity_y[i]

specifies a 0.16 fixed-point format of Y chromaticity coordinate of mastering display in terms of CIE 1931 as specified in , where i = 0, 1, 2 specifies Red, Green, Blue, respectively.

white_point_chromaticity_x

specifies a 0.16 fixed-point format of white point X chromaticity coordinate of mastering display in terms of CIE 1931 as specified in .

white_point_chromaticity_y

specifies a 0.16 fixed-point format of white point Y chromaticity coordinate as mastering display in terms of CIE 1931 as specified in .

max_mastering_luminance

is a 24.8 fixed-point format of maximum display mastering luminance, represented in candelas per square meter.

min_mastering_luminance

is an 18.14 fixed-point format of minimum display mastering luminance, represented in candelas per square meter.

Content Light-Level Information Metadata

metadata_cll() syntax code syntax code | type --------------------------------------------------------------|----- metadata_cll(payloadSize){ | max_cll | u(16) max_fall | u(16) } |

max_cll

specifies the maximum content light level information as specified in , Appendix A.

max_fall

specifies the maximum frame-average light level information as specified in , Appendix A.

User-Defined Metadata This metadata has user data identified by a universal unique identifier as specified in , the contents of which are not specified in this document.

metadata_user_defined() syntax code syntax code | type ------------------------------------------------------------|----- metadata_user_defined(payloadSize){ | uuid | u(128) for(i = 0; i < (payloadSize - 16); i++) | user_defined_data_payload[i] | b(8) } |

uuid

MUST be a 128-bit value specified as a generated Universally Unique Identifier (UUID) according to the procedures specified in .

user_defined_data_payload[i]

MUST be a byte having user-defined syntax and semantics as specified by the UUID generator.

Undefined Metadata

metadata_undefined() syntax code syntax code | type --------------------------------------------------------------|----- metadata_undefined(payloadSize){ | for(i = 0; i < payloadSize; i++){ | undefined_metadata_payload_byte[i] | b(8) } | } |

undefined_metadata_payload_byte[i]

is a byte reserved for future use.

Profiles, Levels, and Bands

Overview of Profiles, Levels, and Bands Profiles, levels, and bands specify restrictions on a coded frame and hence limits on the capabilities needed to decode the coded frame. Profiles, levels, and bands are also used to indicate interoperability points between individual decoder implementations. Each profile specifies a subset of algorithmic features and limits that MUST be supported by all decoders conforming to that profile. NOTE: This document does not include individually selectable "options" at the decoder, as this would increase interoperability difficulties. NOTE: Encoders are not required to make use of any particular subset of features supported in a profile. Each level with a band specifies a set of limits on the values that may be taken by the syntax elements of this document. For any given profile, a level with a band generally corresponds to a particular decoder processing load and memory capability. The constraints set by levels and bands are orthogonal to the constraints defined by profiles so that the same set of level and band definitions is used with all profiles. For example, a certain level L and a certain band B can be combined with either profile X or profile Y to specifically define two different sets of constraints. NOTE: Individual implementations may support a different level for each supported profile.

Requirements on Video Decoder Capability Capabilities of video decoders conforming to this document are specified in terms of the ability to decode video streams conforming to the constraints of profiles, levels, and bands specified in this section. When expressing the capabilities of a decoder for a specified profile, the level and the band supported for that profile MUST also be expressed. Specific values are specified for the syntax elements profile_idc, level_idc, and band_idc. All other values of profile_idc, level_idc, and band_idc are reserved for future use. NOTE: Decoders SHALL NOT infer that a reserved value of profile_idc between the values specified in this document indicates intermediate capabilities between the specified profiles, as there are no restrictions on the method to be chosen for the use of such future reserved values. However, decoders MUST infer that a reserved value of level_idc and a reserved value of band_idc between the values specified in this document indicates intermediate capabilities between the specified levels.

Profiles

General All constraints for a coded frame that are specified are constraints for the coded frame that are activated when the bitstream of the access unit is decoded.

422-10 Profile Conformance of a coded frame to the 422-10 profile is indicated by profile_idc equal to 33. Coded frames conforming to the 422-10 profile MUST obey the following constraints:

• chroma_format_idc MUST be equal to 2.
• bit_depth_minus8 MUST be equal to 2.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 422-10 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 422-10 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

422-12 Profile Conformance of a coded frame to the 422-12 profile is indicated by profile_idc equal to 44. Coded frames conforming to the 422-12 profile MUST obey the following constraints:

• chroma_format_idc MUST be equal to 2.
• bit_depth_minus8 MUST be in the range of 2 to 4.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 422-12 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 422-12 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 422-12 profile or the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

444-10 Profile Conformance of a coded frame to the 444-10 profile is indicated by profile_idc equal to 55. Coded frames conforming to the 444-10 profile MUST obey the following constraints:

• chroma_format_idc MUST be in the range of 2 to 3.
• bit_depth_minus8 MUST be equal to 2.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 444-10 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 444-10 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 444-10 profile or the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

444-12 Profile Conformance of a coded frame to the 444-12 profile is indicated by profile_idc equal to 66. Coded frames conforming to the 444-12 profile MUST obey the following constraints:

• chroma_format_idc MUST be in the range of 2 to 3.
• bit_depth_minus8 MUST be in the range of 2 to 4.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 444-12 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 444-12 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 444-12 profile, the 444-10 profile, the 422-12 profile, or the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

4444-10 Profile Conformance of a coded frame to the 4444-10 profile is indicated by profile_idc equal to 77. Coded frames conforming to the 4444-10 profile MUST obey the following constraints:

• chroma_format_idc MUST be in the range of 2 to 4.
• bit_depth_minus8 MUST be equal to 2.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 4444-10 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 4444-10 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 4444-10 profile, the 444-10 profile, or the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

4444-12 Profile Conformance of a coded frame to the 4444-12 profile is indicated by profile_idc equal to 88. Coded frames conforming to the 4444-12 profile MUST obey the following constraints:

• chroma_format_idc MUST be in the range of 2 to 4.
• bit_depth_minus8 MUST be in the range of 2 to 4.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 4444-12 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 4444-12 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 4444-12 profile, the 4444-10 profile, the 444-12 profile, the 444-10 profile, the 422-12 profile, or the 422-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

400-10 Profile Conformance of a coded frame to the 400-10 profile is indicated by profile_idc equal to 99. Coded frames conforming to the 400-10 profile MUST obey the following constraints:

• chroma_format_idc MUST be equal to 0.
• bit_depth_minus8 MUST be equal to 2.
• pbu_type MUST be equal to 1.

Coded frames conforming to the 400-10 profile MUST also conform to any levels and bands constraints specified in . Decoders conforming to the 400-10 profile at a specific level (identified by a specific value of L) and a specific band (identified by a specific value of B) MUST be capable of decoding all coded frames for which all of the following conditions apply:

• The coded frame is indicated to conform to the 400-10 profile.
• The coded frame is indicated to conform to a level (by a specific value of level_idc) that is lower than or equal to level L.
• The coded frame is indicated to conform to a band (by a specific value of band_idc) that is lower than or equal to band B.

Levels and Bands

General For purposes of comparison of level capabilities, a particular level of each band is considered to be a lower level than some other level when the value of the level_idc of the particular level of each band is less than that of the other level.

• The luma sample rate (luma samples per second) MUST be less than or equal to the "Max luma sample rate".
• The coded data rate (bits per second) MUST be less than or equal to the "Max coded data rate".
• The value of tile_width_in_mbs MUST be greater than or equal to 16.
• The value of tile_height_in_mbs MUST be greater than or equal to 8.
• The value of TileCols MUST be less than or equal to 20.
• The value of TileRows MUST be less than or equal to 20.

Limits of Levels and Bands specifies the limits for each level of each band. A level to which a coded frame conforms is indicated by the syntax elements level_idc and band_idc as follows:

• level_idc MUST be set equal to a value of 30 times the level number specified in .

General level limits

level	Max luma sample rate (samples/s)	Max coded data rate (Mbit/s)
		band_idc==
		0	1	2	3
1	3,041,280	8	11	15	23
1.1	6,082,560	16	21	30	45
2	15,667,200	39	54	76	114
2.1	31,334,400	78	108	152	227
3	66,846,720	114	159	222	333
3.1	133,693,440	227	317	444	666
4	265,420,800	455	637	892	1,338
4.1	530,841,600	910	1,274	1,784	2,675
5	1,061,683,200	1,820	2,548	3,567	5,350
5.1	2,123,366,400	3,639	5,095	7,133	10,699
6	4,777,574,400	7,278	10,189	14,265	21,397
6.1	8,493,465,600	14,556	20,378	28,529	42,793
7	16,986,931,200	29,111	40,756	57,058	85,586
7.1	33,973,862,400	58,222	81,511	114,115	171,172

shows widely used typical configurations of resolution and frame rates of video and corresponding levels for them. Example of typical video configurations and corresponding levels (informative)

use case	resolution	frame per second	luma sample per second	level
720p	1280 x 720	30	27,648,000	2.1
FHD	1920 x 1080	30	62,208,000	3
UHD 4K	3840 x 2160	60	497,664,000	4.1
UHD 4K	3840 x 2160	120	995,328,000	5
UHD 8K	7680 x 4320	60	1,990,656,000	5.1
UHD 8K	7680 x 4320	120	3,981,312,000	6

Security Considerations Like any other audio or video codec, APV should not be used with insecure ciphers or cipher modes that are vulnerable to known plaintext attacks. Some of the header bits as well as the padding are easily predictable. A decoder MUST be robust against any non-compliant or malicious payloads. Malicious payloads MUST NOT cause the decoder to overrun its allocated memory or to take an excessive amount of resources to decode. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems in encoders are typically rare. Malicious video streams MUST NOT cause the encoder to misbehave because this would allow an attacker to attack transcoding gateways. A frequent security problem in image and video codecs is failure to check for integer overflows. An example is allocating "frame_width * frame_height" in pixel count computations without considering that the multiplication result may have overflowed the range of the arithmetic type. The implementation MUST ensure that any data outside of allocated and initialized memory cannot be read. A decoder MUST NOT try to process the metadata whose type is not recognized by the implementation. Failure to process any metadata exactly according to the syntax structure specified MAY put a decoder in an unknown status. None of the content carried in APV is intended to be executable.

IANA Considerations This document has no actions for IANA.

References Normative References CIE CTA CTA-861.3-A ITU-T ISO ISO/IEC ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Informative References commit 1a7845a

Raw Bitstream Format

raw_bitstream_access_unit() syntax code syntax code | type --------------------------------------------------------------|----- raw_bitstream_access_unit(){ | au_size | u(32) access_unit(au_size) | } |

au_size

indicates the size of access unit in bytes. 0 is prohibited and 0xFFFFFFFF is reserved.

APV Implementations

OpenAPV Open Source Project The Academy Software Foundation (ASWF) , jointly founded by the Academy of Motion Picture Arts and Science (AMPAS) and the Linux Foundation, has created an open source software development project conformant to this document . The project also provides various test vectors for verification of the implementations at .

Android Open Source Project The Android open source project (AOSP) has implemented Advanced Professional Video (APV) conformant to this document .

FFmpeg Open Source Project The FFmpeg project is developing an APV decoder and an APV encoder conformant to this document.

Authors' Addresses Samsung Electronics

6105 Tennyson Pkwy, Ste 300 Plano TX 75024 United States of America yklwhite@gmail.com

Samsung Electronics

34, Seongchon-gil, Seocho-gu Seoul 3573 Republic of Korea m.w.park@samsung.com

Samsung Electronics

6105 Tennyson Pkwy, Ste 300 Plano TX 75024 United States of America m.budagavi@samsung.com

Samsung Electronics

11488 Tree Hollow Ln San Diego CA 92128 United States of America rajan_joshi@ieee.org

Samsung Electronics

34 Seongchon-gil Seocho-gu Seoul 3573 Republic of Korea kwangpyo.choi@gmail.com