4. Formats and Processes Used in This Document
Questa sezione conserva il testo RFC su APV, includendo bitstream syntax, syntax element processing, decoding and parsing processes, metadata, profiles, levels, bands, raw bitstream format e implementation references.
Testo RFC originale
4. Formats and Processes Used in This Document
4.1. 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 Appendix A.
4.2. 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
[H273]).
* 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 [CIE15]).
* 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
Table 2. 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.
+===================+==========+===========+============+==========+
| chroma_format_idc | Chroma | SubWidthC | SubHeightC | NumComps |
| | format | | | |
+===================+==========+===========+============+==========+
| 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 |
+-------------------+----------+-----------+------------+----------+
Table 2: SubWidthC, SubHeightC, and NumComps values derived from
chroma_format_idc
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 Figure 1.
& * & * & * & * & * ...
& * & * & * & * & * ...
& * & * & * & * & * ...
& * & * & * & * & * ...
...
& - location where both luma and chroma sample exist
* - location where only luma sample exist
Figure 1: Nominal vertical and horizontal locations of 4:2:2 luma
and chroma samples in a frame
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 Figure 2.
& & & & & & & & & & ...
& & & & & & & & & & ...
& & & & & & & & & & ...
& & & & & & & & & & ...
...
& - location where both luma and chroma sample exist
Figure 2: Nominal vertical and horizontal locations of 4:4:4 and
4:4:4:4 luma and chroma samples in a frame
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
4.3. Partitioning of a Frame
4.3.1. 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 Figure 3. 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.
+===================+===================+=========+
# | | | # 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
Figure 3: Frame with 10 by 8 MBs that is partitioned into 6 tiles
4.3.2. 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.
4.4. Scanning Processes
4.4.1. 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. Figure 4 shows an
example of scanning order for 4x4 size block.
+===================+
# 00 | 01 | 05 | 06 #
+-------------------+
# 02 | 04 | 07 | 12 #
+-------------------+
# 03 | 08 | 11 | 13 #
+-------------------+
# 09 | 10 | 14 | 15 #
+===================+
Figure 4: Example of zig-zag scanning order for 4x4 block
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:
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--
}
}
}
Figure 5: Pseudocode for zig-zag scan
4.4.2. 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 Section 4.4.1 with
input parameters blkWidth and blkHeight.
* The output variable inverseScan is derived as follows:
for(pos = 0; pos < blkWidth * blkHeight; pos++){
inverseScan[forwardScan[pos]] = pos
}
Figure 6: Pseudocode for inverse zig-zag scan