rfc9584xml2.original.xml   rfc9584.xml 
<?xml version="1.0" encoding="ascii"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.40 (Ruby 2.
6.10) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-avtcore-rtp-evc-07" category="std" co <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
nsensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs=" -ietf-avtcore-rtp-evc-07" number="9584" category="std" consensus="true" submissi
true"> onType="IETF" obsoletes="" updates="" tocInclude="true" sortRefs="true" symRefs=
<front> "true" version="3" xml:lang="en">
<title abbrev="RTP payload format for EVC">RTP Payload Format for Essential
Video Coding (EVC)</title>
<front>
<title abbrev="RTP Payload Format for EVC">RTP Payload Format for Essential
Video Coding (EVC)</title>
<seriesInfo name="RFC" value="9584"/>
<author initials="S." surname="Zhao" fullname="Shuai Zhao"> <author initials="S." surname="Zhao" fullname="Shuai Zhao">
<organization>Intel</organization> <organization>Intel</organization>
<address> <address>
<postal> <postal>
<street>2200 Mission College Blvd</street> <street>2200 Mission College Blvd</street>
<city>Santa Clara</city> <city>Santa Clara</city><region>California</region>
<code>95054</code> <code>95054</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>shuai.zhao@ieee.org</email> <email>shuai.zhao@ieee.org</email>
</address> </address>
</author> </author>
<author initials="S." surname="Wenger" fullname="Stephan Wenger"> <author initials="S." surname="Wenger" fullname="Stephan Wenger">
<organization>Tencent</organization> <organization>Tencent</organization>
<address> <address>
<postal> <postal>
<street>2747 Park Blvd</street> <street>2747 Park Blvd</street>
<city>Palo Alto</city> <city>Palo Alto</city><region>California</region>
<code>94588</code> <code>94588</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>stewe@stewe.org</email> <email>stewe@stewe.org</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Lim" fullname="Youngkwon Lim"> <author initials="Y." surname="Lim" fullname="Youngkwon Lim">
<organization>Samsung Electronics</organization> <organization>Samsung Electronics</organization>
<address> <address>
<postal> <postal>
<street>6625 Excellence Way</street> <street>6625 Excellence Way</street>
<city>Plano</city> <city>Plano</city><region>Texas</region>
<code>75013</code> <code>75013</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>yklwhite@gmail.com</email> <email>yklwhite@gmail.com</email>
</address> </address>
</author> </author>
<date year="2023" month="December" day="19"/> <date year="2024" month="June"/>
<area>ART</area> <area>WIT</area>
<workgroup>avtcore</workgroup> <workgroup>avtcore</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 113?>
<t>This document describes an RTP payload format for the Essential Video Coding <keyword>EVC</keyword>
(EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was dev <keyword>ISO/IEC 23094-1</keyword>
eloped by the Moving Picture Experts Group (MPEG). The RTP payload format allows <keyword>Essential Video Coding</keyword>
for the packetization of one or more Network Abstraction Layer (NAL) units in e
ach RTP packet payload and the fragmentation of a NAL unit into multiple RTP pac
kets. The payload format has broad applicability in videoconferencing, Internet
video streaming, and high-bitrate entertainment-quality video, among other appli
cations.</t>
<abstract>
<t>This document describes an RTP payload format for the Essential Video
Coding (EVC) standard, published as ISO/IEC International Standard
23094-1. EVC was developed by the MPEG. The RTP payload format allows
for the packetization of one or more Network Abstraction Layer (NAL)
units in each RTP packet payload and the fragmentation of a NAL unit
into multiple RTP packets. The payload format has broad applicability in
videoconferencing, Internet video streaming, and high-bitrate
entertainment-quality video, among other applications.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 117?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>The Essential Video Coding <xref target="EVC"/> standard, which is for
mally designated as ISO/IEC International Standard 23094-1 <xref target="EVC"/>,
<t>The Essential Video Coding <xref target="EVC"/> standard, which is formally was published in 2020. One of MPEG's goals is to keep EVC's Baseline profile e
designated as ISO/IEC International Standard 23094-1 <xref target="ISO23094-1"/> ssentially royalty-free by using technologies published more than 20 years ago o
has been published in 2020. One goal of MPEG is to keep <xref target="EVC"/>&# r otherwise known to be available for use without a requirement for paying royal
39;s Baseline profile essentially royalty-free by using technologies published m ties, whereas more advanced profiles follow a reasonable and non-discriminatory
ore than 20 years ago or otherwise known to be available for use without a requi licensing terms policy. Both the Baseline profile and higher profiles of EVC <xr
rement for paying royalties, whereas more advanced profiles follow a reasonable ef target="EVC"/> are reported to provide coding efficiency gains over High Effi
and non-discriminatory licensing terms policy. Both the Baseline profile and hig ciency Video Coding <xref target="HEVC"/> and Advanced Video Coding <xref target
her profiles of <xref target="EVC"/> are reported to provide coding efficiency g ="AVC"/> under certain configurations.</t>
ains over High Efficiency Video Coding <xref target="HEVC"/> and Advanced Video <t>This document describes an RTP payload format for EVC. It shares its ba
Coding <xref target="AVC"/> under certain configurations.</t> sic design with the NAL unit-based RTP payload formats of H.264 Video Coding <xr
ef target="RFC6184"/>, Scalable Video Coding (SVC) <xref target="RFC6190"/>, Hig
<t>This document describes an RTP payload format for EVC. It shares its basic de h Efficiency Video Coding (HEVC) <xref target="RFC7798"/>, and Versatile Video C
sign with the NAL unit-based RTP payload formats of H.264 Video Coding <xref tar oding (VVC) <xref target="RFC9328"/>. With respect to design philosophy, securi
get="RFC6184"/>, Scalable Video Coding (SVC) <xref target="RFC6190"/>, High Effi ty, congestion control, and overall implementation complexity, it has similar pr
ciency Video Coding (HEVC) <xref target="RFC7798"/>, and Versatile Video Coding operties to those earlier payload format specifications. This is a conscious ch
(VVC)<xref target="RFC9328"/>. With respect to design philosophy, security, con oice, as at least the RTP Payload Format for H.264 video as described in <xref t
gestion control, and overall implementation complexity, it has similar propertie arget="RFC6184"/> is widely deployed and generally known in the relevant impleme
s to those earlier payload format specifications. This is a conscious choice, a nter communities. Certain mechanisms described in <xref target="RFC6190"/> were
s at least <xref target="RFC6184"/> is widely deployed and generally known in th incorporated, as EVC supports temporal scalability. EVC currently does not offe
e relevant implementer communities. Certain mechanisms known from <xref target= r higher forms of scalability.</t>
"RFC6190"/> were incorporated as EVC supports temporal scalability. EVC currentl <section anchor="overview-of-the-evc-codec">
y does not offer higher forms of scalability.</t> <name>Overview of the EVC Codec</name>
<t>The codings described in <xref target="EVC"/>, <xref target="AVC"/>,
<section anchor="overview-of-the-evc-codec"><name>Overview of the EVC Codec</nam <xref target="HEVC"/>, and <xref target="VVC"/> share a similar hybrid video cod
e> ec design. In this document, we provide a very brief overview of those features
of EVC that are, in some form, addressed by the payload format specified herein
<t><xref target="EVC"/>, <xref target="AVC"/>, <xref target="HEVC"/> and <xref t . Implementers have to read, understand, and apply the ISO/IEC standard pertain
arget="VVC"/> share a similar hybrid video codec design. In this document, we p ing to EVC <xref target="EVC"/> to arrive at interoperable, well-performing impl
rovide a very brief overview of those features of EVC that are, in some form, ad ementations. The EVC standard has a Baseline profile and a Main profile, the lat
dressed by the payload format specified herein. Implementers have to read, unde ter being a superset of the Baseline profile but including more advanced feature
rstand, and apply the ISO/IEC standard pertaining to EVC to arrive at interopera s. EVC also includes still image variants of both Baseline and Main profiles, i
ble, well-performing implementations. The EVC standard has a Baseline profile an n each of which the bitstream is restricted to a single IDR picture. EVC facilit
d a Main profile, the latter being a superset of the Baseline profile but includ ates certain walled garden implementations under commercial constraints imposed
ing more advanced features. EVC also includes still image variants of both Base by intellectual property rights by including syntax elements that allow encoders
line and Main profiles, in each of which the bitstream is restricted to a single to mark a bitstream as to what of the many independent coding tools are exercis
IDR picture. EVC facilitates certain walled-garden implementations under commer ed in the bitstream, in a spirit similar to the general_constraint_info of <xref
cial constraints imposed by intellectual property rights by including syntax ele target="VVC"/>.</t>
ments that allow encoders to mark a bitstream as to what of the many independent <t>Conceptually, all EVC, AVC, HEVC, and VVC include a Video Coding Laye
coding tools are exercised in the bitstream, in a spirit similar to the general r (VCL), a term that is often used to refer to the coding-tool features, and a N
_constraint_flags of <xref target="VVC"/>.</t> etwork Abstraction Layer (NAL), which usually refers to the systems and transpor
t interface aspects of the codecs.</t>
<t>Conceptually, all EVC, AVC, HEVC and VVC include a Video Coding Layer (VCL); <section anchor="coding-tool-features-informative">
a term that is often used to refer to the coding-tool features, and a Network Ab <name>Coding-Tool Features (Informative)</name>
straction Layer (NAL), which usually refers to the systems and transport interfa
ce aspects of the codecs.</t>
<section anchor="coding-tool-features-informative"><name>Coding-Tool Features (i
nformative)</name>
<t>Coding blocks and transform structure</t>
<t>EVC uses a traditional block-based coding structure, which divides the encode
d image into blocks of up to 64x64 luma samples for the Baseline profile and 128
x128 luma samples for the Main profile that can be recursively divided into smal
ler blocks. The baseline profiles utilize an HEVC-like quad-tree blocks partitio
ning that allows to divide a block horizontally and vertically onto four smaller
square blocks. The Main profile adds two advanced coding structure tools: 1) Bi
nary Ternary Tree (BTT) partitioning that allows non-square coding units; and 2)
Split Unit Coding Order segmentation that changes the processing order of the b
locks from traditional left-to-right and top-to-bottom scanning order processing
to an alternative right-to-left and bottom-to-top scanning order. In the Main p
rofile, the picture can be divided into slices and tiles, which can be independe
ntly encoded and/or decoded in parallel.</t>
<t>EVC also uses a traditional video codecs prediction model assuming two genera
l types of predictions: Intra (spatial) and Inter (temporal) predictions. A resi
due block is calculated by subtracting predicted data from the original (encoded
) one. The Baseline profile allows only discrete cosine transform (DCT-2) and sc
alar quantization to transform and quantize residue data, wherein the Main profi
le additionally has options to use discrete sine transform (DST-7) and another t
ype of discrete cosine transform (DCT-8). In addition, for the Main profile, Imp
roved Quantization and Transform (IQT) uses a different mapping/clipping functio
n for quantization. An inverse zig-zag scanning order is used for coefficient co
ding. Advanced Coefficient Coding (ADCC) in the Main profile can code coefficien
t values more efficiently, for example, indicated by the last non-zero coefficie
nt. The Baseline profile uses a straightforward run-length encoding (RLE) based
approach to encode the quantized coefficients.</t>
<t>Entropy coding</t>
<t>EVC uses a similar binary arithmetic coding mechanism as HEVC CABAC and VVC.
The mechanism includes a binarization step and a probability update defined by a
lookup table. In the Main profile, the derivation process of syntax elements ba
sed on adjacent blocks makes the context modeling and initialization process mor
e efficient.</t>
<t>In-loop filtering</t>
<t>The Baseline profile of EVC uses the deblocking filter defined in H.263 Annex
J. In the Main profile, an Advanced Deblocking Filter (ADDB) can be used as an
alternative, which can further reduce undesirable compression artifacts. The Mai
n profile also defines two additional in-loop filters that can be used to improv
e the quality of decoded pictures before output and/or for inter-prediction. A H
adamard Transform Domain Filter (HTDF) is applied to the luma samples before deb
locking, and a lookup table is used to determine four adjacent samples for filt
ering. An adaptive Loop Filter (ALF) allows to send signals of up to 25 differen
t filters for the luma components, and the best filter can be selected through t
he classification process for each 4x4 block. Similarly to VVC, the filter param
eters of ALF are signaled in the Adaptation Parameter Set (APS).</t>
<t>Inter-prediction</t>
<t>The basis of EVC&#39;s inter-prediction is motion compensation using interpol
ation filters with a quarter sample resolution. In the Baseline profile, a motio
n vector is transmitted using one of three spatially neighboring motion vectors
and a temporally collocated motion vector as a predictor. A motion vector differ
ence may be signaled relative to the selected predictor, but there is a case whe
re no motion vector difference is signaled, and there is no remaining data in th
e block. This mode is called a skip mode. The Main profile includes six addition
al tools to provide improved inter-prediction. With Advanced Motion Vectors Pred
iction (ADMVP), adjacent blocks can be conceptually merged to indicate that they
use the same motion, but more advanced schemes can also be used to create predi
ctions from the basic model list of candidate predictors. The Merge with Motion
Vector Difference (MMVD) tool uses a process similar to the concept of merging n
eighboring blocks but also allows the use of expressions that include a starting
point, motion amplitude, and direction of motion to send a motion vector signal
. Using Advanced Motion Vector Prediction (AMVP), candidate motion vector predic
tions for the block can be derived from its neighboring blocks in the same pictu
re and collocated blocks in the reference picture. The Adaptive Motion Vector Re
solution (AMVR) tool provides a way to reduce the accuracy of a motion vector fr
om a quarter sample to half sample, full sample, double sample, or quad sample,
which provides an efficiency advantage, such as when sending large motion vector
differences. The Main profile also includes the Decoder-side Motion Vector Refi
nement (DMVR), which uses a bilateral template matching process to refine the mo
tion vectors without additional signaling.</t>
<t>Intra prediction and intra-coding</t>
<t>Intra prediction in EVC is performed on adjacent samples of coding units in a
partitioned structure. For the Baseline profile, when all coding units are squa
re, there are five different prediction modes: DC (mean value of the neighborhoo
d), horizontal, vertical, and two different diagonal directions. In the Main pro
file, intra prediction can be applied to any rectangular coding unit, and 28 add
itional direction modes are available in the so-called Enhanced Intra Prediction
Directions (EIPD). In the Main profile, an encoder can also use Intra Block Cop
y (IBC), where previously decoded sample blocks of the same picture are used as
a predictor. A displacement vector in integer sample precision is signaled to in
dicate where the prediction block in the current picture is used for this mode.<
/t>
<t>Reference frames management</t>
<t>In EVC, decoded pictures can be stored in a decoded picture buffer (DPB) for
predicting pictures that follow them in the decoding order. In the Baseline prof
ile, the management of the DPB (i.e., the process of adding and deleting referen
ce pictures) is controlled by a straightforward AVC-like sliding window approach
with very few parameters from the SPS. For the Main profile, DPB management can
be handled much more flexibly using explicitly signaled reference Picture Lists
(RPL) in the SPS or slice level.</t>
</section>
<section anchor="systems-and-transport-interfaces"><name>Systems and Transport I
nterfaces</name>
<t>EVC inherits the basic systems and transport interface designs from AVC and H
EVC. These include the NAL-unit-based syntax, hierarchical syntax and data unit
structure, and Supplemental Enhancement Information (SEI) message mechanism. The
hierarchical syntax and data unit structure consists of a sequence-level parame
ter set (SPS), two picture-level parameter sets (PPS and APS, each of which can
apply to one or more pictures), slice-level header parameters, and lower-level p
arameters.</t>
<t>A number of key components that influenced the Network Abstraction Layer desi
gn of EVC as well as this document, are described below:</t>
<t>Sequence parameter set</t>
<ul empty="true"><li> <dl newline="true">
<t>The Sequence Parameter Set (SPS) contains syntax elements pertaining to a C <dt>Coding blocks and transform structure</dt>
oded Video Sequence (CVS), which is a group of pictures, starting with a random <dd><t>EVC uses a traditional block-based coding structure, which
access point picture and followed by zero or more pictures that may depend on ea divides the encoded image into blocks of up to 64x64 luma samples
ch other and the random access point picture. In MPEG-2, the equivalent of a CVS for the Baseline profile and 128x128 luma samples for the Main
is a Group of Pictures (GOP), which generally started with an I frame and is fo profile that can be recursively divided into smaller blocks. The
llowed by P and B frames. While more complex in its options of random access poi Baseline profiles utilize HEVC-like quad-tree-blocks partitioning
nts, EVC retains this basic concept. In many TV-like applications, a CVS contain that allows a block to be divided horizontally and vertically into
s a few hundred milliseconds to a few seconds of video. In video conferencing (w four smaller square blocks. The Main profile adds two advanced
ithout switching MCUs involved), a CVS can be as long in duration as the whole s coding structure tools: 1) Binary Ternary Tree (BTT) partitioning
ession.</t> that allows non-square coding units and 2) Split Unit Coding Order
</li></ul> segmentation that changes the processing order of the blocks from
traditional left-to-right and top-to-bottom scanning order
processing to an alternative right-to-left and bottom-to-top
scanning order. In the Main profile, the picture can be divided into
slices and tiles, which can be independently encoded and/or decoded
in parallel.</t>
<t>EVC also uses a traditional video codecs prediction model assuming
two general types of predictions: Intra (spatial) and Inter (temporal) predictio
ns. A residue block is calculated by subtracting predicted data from the origina
l (encoded) one. The Baseline profile allows only discrete cosine transform (DCT
-2) and scalar quantization to transform and quantize residue data, wherein the
Main profile additionally has options to use discrete sine transform (DST-7) and
another type of discrete cosine transform (DCT-8). In addition, for the Main pr
ofile, Improved Quantization and Transform (IQT) uses a different mapping or cli
pping function for quantization. An inverse zig-zag scanning order is used for c
oefficient coding. Advanced Coefficient Coding (ADCC) in the Main profile can co
de coefficient values more efficiently, for example, indicated by the last non-z
ero coefficient. The Baseline profile uses a straightforward RLE-based approach
to encode the quantized coefficients.</t></dd>
<dt>Entropy coding</dt>
<dd><t>EVC uses a similar binary arithmetic coding mechanism as HEVC C
ABAC (context adaptive binary arithmetic coding) and VVC. The mechanism includes
a binarization step and a probability update defined by a lookup table. In the
Main profile, the derivation process of syntax elements based on adjacent blocks
makes the context modeling and initialization process more efficient.</t>
</dd>
<t>Picture and adaptation parameter set</t> <dt>In-loop filtering</dt>
<dd><t>The Baseline profile of EVC uses the deblocking filter defined
in H.263 Annex J <xref target="VIDEO-CODING" format="default"/>. In the Main pro
file, an Advanced Deblocking Filter (ADDB) can be used as an alternative, which
can further reduce undesirable compression artifacts. The Main profile also defi
nes two additional in-loop filters that can be used to improve the quality of de
coded pictures before output and/or for Inter prediction. A Hadamard Transform D
omain Filter (HTDF) is applied to the luma samples before deblocking, and a look
up table is used to determine four adjacent samples for filtering. An adaptive
Loop Filter (ALF) allows signals of up to 25 different filters to be sent for th
e luma components; the best filter can be selected through the classification pr
ocess for each 4x4 block. Similarly to VVC, the filter parameters of ALF are sig
naled in the Adaptation Parameter Set (APS).</t></dd>
<ul empty="true"><li> <dt>Inter prediction</dt>
<t>The Picture Parameter Set and the Adaptation Parameter Set (PPS and APS, re <dd><t>The basis of EVC's Inter prediction is motion compensation usin
spectively) carry information pertaining to a single picture. The PPS contains i g interpolation filters with a quarter sample resolution. In the Baseline profil
nformation that is likely to stay constant from picture to picture, at least for e, a motion vector is transmitted using one of three spatially neighboring motio
pictures of a certain type whereas the APS contains information, such as adapti n vectors and a temporally collocated motion vector as a predictor. A motion vec
ve loop filter coefficients, that are likely to change from picture to picture.< tor difference may be signaled relative to the selected predictor, but there is
/t> a case where no motion vector difference is signaled, and there is no remaining
</li></ul> data in the block. This mode is called a "skip" mode. The Main profile includes
six additional tools to provide improved Inter prediction. With Advanced Motion
Vectors Prediction (ADMVP), adjacent blocks can be conceptually merged to indica
te that they use the same motion, but more advanced schemes can also be used to
create predictions from the basic model list of candidate predictors. The Merge
with Motion Vector Difference (MMVD) tool uses a process similar to the concept
of merging neighboring blocks but also allows the use of expressions that includ
e a starting point, motion amplitude, and direction of motion to send a motion v
ector signal. Using Advanced Motion Vector Prediction (AMVP), candidate motion v
ector predictions for the block can be derived from its neighboring blocks in th
e same picture and collocated blocks in the reference picture. The Adaptive Moti
on Vector Resolution (AMVR) tool provides a way to reduce the accuracy of a moti
on vector from a quarter sample to half sample, full sample, double sample, or q
uad sample, which provides an efficiency advantage, such as when sending large m
otion vector differences. The Main profile also includes the Decoder-side Motion
Vector Refinement (DMVR), which uses a bilateral template matching process to r
efine the motion vectors without additional signaling.</t></dd>
<t>Profile, level, and toolsets</t> <dt>Intra prediction and intra coding</dt>
<dd><t>Intra prediction in EVC is performed on adjacent samples of cod
ing units in a partitioned structure. For the Baseline profile, when all coding
units are square, there are five different prediction modes: DC (mean value of t
he neighborhood), horizontal, vertical, and two different diagonal directions. I
n the Main profile, intra prediction can be applied to any rectangular coding un
it, and 28 additional direction modes are available in the Enhanced Intra Predic
tion Directions (EIPDs). In the Main profile, an encoder can also use Intra Bloc
k Copy (IBC), where previously decoded sample blocks of the same picture are use
d as a predictor. A displacement vector in integer sample precision is signaled
to indicate where the prediction block in the current picture is used for this m
ode.</t></dd>
<ul empty="true"><li> <dt>Reference frames management</dt>
<t>Profiles and levels follow the same design considerations known from AVC, H <dd><t>In EVC, decoded pictures can be stored in a decoded picture buf
EVC, and video codecs as old as MPEG-1 Video. The profile defines a set of tools fer (DPB) for predicting pictures that follow them in the decoding order. In the
(not to confuse with the &quot;toolset&quot; discussed below) that a decoder co Baseline profile, the management of the DPB (i.e., the process of adding and de
mpliant with this profile has to support. In EVC, profiles are defined in Annex leting reference pictures) is controlled by a straightforward AVC-like sliding w
A. Formally, they are defined as a set of constraints that a bitstream needs to indow approach with very few parameters from the sequence parameter set (SPS). F
conform to. In EVC, the Baseline profile is much more severely constraint than or the Main profile, DPB management can be handled much more flexibly using expl
the Main profile, reducing implementation complexity. Levels relate to bitstream icitly signaled Reference Picture Lists (RPLs) in the SPS or slice level.</t></d
complexity in dimensions such as maximum sample decoding rate, maximum picture d>
size, and similar parameters directly related to computational complexity and/or </dl>
memory demands.</t> </section>
</li></ul> <section anchor="systems-and-transport-interfaces">
<name>Systems and Transport Interfaces</name>
<t>EVC inherits the basic systems and transport interface designs from
AVC and HEVC. These include the NAL-unit-based syntax, hierarchical syntax and
data unit structure, and Supplemental Enhancement Information (SEI) message mech
anism. The hierarchical syntax and data unit structure consists of a sequence-le
vel parameter set (i.e., SPS), two picture-level parameter sets (i.e., PPS and A
PS, each of which can apply to one or more pictures), slice-level header paramet
ers, and lower-level parameters.</t>
<t>A number of key components that influenced the NAL design of EVC as
well as this document are described below:</t>
<dl newline="true">
<dt>Sequence parameter set</dt>
<dd><t>The Sequence Parameter Set (SPS) contains syntax elements p
ertaining to a Coded Video Sequence (CVS), which is a group of pictures, startin
g with a random access point picture and followed by zero or more pictures that
may depend on each other and the random access point picture. In MPEG-2, the equ
ivalent of a CVS is a Group of Pictures (GOP), which generally starts with an I
frame and is followed by P and B frames. While more complex in its options of ra
ndom access points, EVC retains this basic concept. In many TV-like applications
, a CVS contains a few hundred milliseconds to a few seconds of video. In video
conferencing (without switching Multipoint Control Units (MCUs) involved), a CVS
can be as long in duration as the whole session.</t></dd>
<dt>Picture and adaptation parameter set</dt>
<dd><t>The Picture Parameter Set (PPS) and the Adaptation Paramete
r Set (APS) carry information pertaining to a single picture. The PPS contains i
nformation that is likely to stay constant from picture to picture, at least for
pictures of a certain type; whereas the APS contains information, such as adapt
ive loop filter coefficients, that are likely to change from picture to picture.
</t></dd>
<dt>Profile, level, and toolsets</dt>
<dd><t>Profiles and levels follow the same design considerations k
nown from AVC, HEVC, and video codecs as old as MPEG-1 Video. The profile define
s a set of tools (not to be confused with the "toolset" discussed below) that a
decoder compliant with this profile has to support. In EVC, profiles are defined
in Annex A of <xref target="EVC"/>. Formally, they are defined as a set of con
straints that a bitstream needs to conform to. In EVC, the Baseline profile is m
uch more severely constrained than the Main profile, reducing implementation com
plexity. Levels relate to bitstream complexity in dimensions such as maximum sam
ple decoding rate, maximum picture size, and similar parameters directly related
to computational complexity and/or memory demands.</t>
<t>Profiles and levels are signaled in the highest parameter set available, the SPS.</t> <t>Profiles and levels are signaled in the highest parameter set available, the SPS.</t>
<t>EVC contains another mechanism related to the use of coding tools, known as the toolset syntax elements. These syntax elements, toolset_idc_h and toolset_i dc_l (located in the SPS), are bitmasks that allow encoders to indicate which co ding tools they are using within the menu of profiles offered by the profile tha t is also signaled. No decoder conformance point is associated with the toolset, but a bitstream that was using a coding tool that is indicated as not being use d in the toolset syntax element would be non-compliant. While MPEG specifically rules out the use of the toolset syntax element as a conformance point, walled g arden implementations could do so without incurring the interoperability problem s MPEG fears and create bitstreams and decoders that do not support one or more given tools. That, in turn, may be useful to mitigate certain intellectual prope rty-related risks.</t> </dd>
<ul empty="true"><li> <dt>Bitstream and elementary stream</dt>
<t>EVC contains another mechanism related to the use of coding tools, known as <dd><t>Above the Coded Video Sequence (CVS), EVC defines a video bitst
the toolset syntax element. This syntax element, toolset_idc_h and toolset_idc_ ream that can be used as an elementary stream in the MPEG systems context. For t
l located in the SPS, is a bitmask that allows encoders to indicate which coding his document, the video bitstream syntax level is not relevant.</t></dd>
tools they are using within the menu of profiles offered by the profile that is <dt>Random access support</dt>
also signaled. No decoder conformance point is associated with the toolset, but <dd><t>EVC supports random access mechanisms based on IDR and clean ra
a bitstream that was using a coding tool that is indicated as not being used in ndom access (CRA) access units.</t></dd>
the toolset syntax element would be non-compliant. While MPEG specifically rule <dt>Temporal scalability support</dt>
s out the use of the toolset syntax element as a conformance point, walled garde <dd><t>EVC supports temporal scalability through the generalized refer
n implementations could do so without incurring the interoperability problems MP ence picture selection approach known since AVC/SVC. Up to six temporal layers a
EG fears and create bitstreams and decoders that do not support one or more give re supported. The temporal layer is signaled in the NAL unit header (which co-se
n tools. That, in turn, may be useful to mitigate certain intellectual property- rves as the payload header in this document), in the nuh_temporal_id field.</t><
related risks.</t> /dd>
</li></ul>
<t>Bitstream and elementary stream</t>
<ul empty="true"><li>
<t>Above the Coded Video Sequence (CVS), EVC defines a video bitstream that ca
n be used as an elementary stream in the MPEG systems context. For this document
, the video bitstream syntax level is not relevant.</t>
</li></ul>
<t>Random access support</t>
<ul empty="true"><li>
<t>EVC supports random access mechanisms based on IDR and CRA access units.</t
>
</li></ul>
<t>Temporal scalability support</t>
<ul empty="true"><li>
<t>EVC supports temporal scalability through the generalized reference picture
selection approach known since AVC/SVC. Up to six temporal layers are supported
. The temporal layer is signaled in the NAL unit header (which co-serves as the
payload header in this document), in the nuh_temporal_id field.</t>
</li></ul>
<t>Reference picture management</t>
<ul empty="true"><li>
<t>EVC&#39;s reference picture management is POC-based (Picture Order Count),
similar to HEVC. In the Main profile, substantially all reference picture list m
anipulations available in HEVC are available, including explicit transmissions/u
pdates of reference picture lists, although for reference pictures management pu
rposes, EVC uses a modern VVC-like RPL approach, which is conceptually simpler t
han the HEVC one. In the Baseline profile, reference picture management is more
restricted, allowing for a comparatively simple group of picture structures only
.</t>
</li></ul>
<t>SEI Message</t>
<ul empty="true"><li>
<t>EVC inherits many of HEVC&#39;s SEI Messages, occasionally with syntax and/
or semantics changes, making them applicable to EVC. In addition, some of the co
dec-agnostic SEI Messages of the VSEI specification are also mapped.</t>
</li></ul>
</section>
<section anchor="parallel-processing-support-informative"><name>Parallel Process
ing Support (informative)</name>
<ul empty="true"><li>
<t>EVC&#39;s Baseline profile includes no tools specifically addressing parall
el processing support. The Main profile includes independently decodable slices
for parallel processing. The slices are defined as any rectangular region within
a picture and can be encoded to have no coding dependencies with other slices i
n the same picture but with other slices from the previous picture. No specific
support for parallel processing is specified in this RTP payload format.</t>
</li></ul>
</section> <dt>Reference picture management</dt>
<section anchor="NALUnitHeader"><name>NAL Unit Header</name> <dd><t>EVC's reference picture management is POC-based, similar to HEV
C. In the Main profile, substantially all reference picture list manipulations a
vailable in HEVC are specified, including explicit transmissions or updates of r
eference picture lists. Although for reference pictures management purposes, EVC
uses a modern VVC-like RPL approach, which is conceptually simpler than the HEV
C one. In the Baseline profile, reference picture management is more restricted,
allowing for a comparatively simple group of picture structures only.</t></dd>
<dt>SEI Message</dt>
<dd><t>EVC inherits many of HEVC's SEI messages, occasionally with syn
tax and/or semantics changes, making them applicable to EVC.
In addition, some of the codec-agnostic SEI messages of the VSEI specification <
xref target="VSEI"/> are also mapped.</t></dd>
</dl>
</section>
<section anchor="parallel-processing-support-informative">
<name>Parallel Processing Support (Informative)</name>
<t>EVC maintains the NAL unit concept of <xref target="VVC"/> with different par <t>EVC's Baseline profile includes no tools specifically addressing
ameter options. EVC also uses a two-byte NAL unit header, as shown in <xref targ parallel-processing support. The Main profile includes independently
et="evc-nuh"/>. The payload of a NAL unit refers to the NAL unit excluding the decodable slices for parallel processing. The slices are defined as
NAL unit header.</t> any rectangular region within a picture. They can be encoded to have
coding dependencies with other slices from the previous picture but
not with other slices in the same picture. No specific support for
parallel processing is specified in this RTP payload format.</t>
<figure anchor="evc-nuh"><artwork><![CDATA[ </section>
<section anchor="NALUnitHeader">
<name>NAL Unit Header</name>
<t>EVC maintains the NAL unit concept of <xref target="VVC"/> with dif
ferent parameter options. EVC also uses a two-byte NAL unit header, as shown in
<xref target="evc-nuh"/>. The payload of a NAL unit refers to the NAL unit excl
uding the NAL unit header.</t>
<figure anchor="evc-nuh">
<name>The Structure of the EVC NAL Unit Header</name>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Type | TID | Reserve |E| |F| Type | TID | Reserve |E|
+-------------+-----------------+ +-------------+-----------------+]]></artwork>
</figure>
The Structure of the EVC NAL Unit Header <t>The semantics of the fields in the NAL unit header are as specified
]]></artwork></figure> in EVC and described briefly below for convenience. In addition to the name and
size of each field, the corresponding syntax element name in EVC is also provid
<t>The semantics of the fields in the NAL unit header are as specified in EVC an ed.</t>
d described briefly below for convenience. In addition to the name and size of e
ach field, the corresponding syntax element name in EVC is also provided.</t>
<t>F: 1 bit</t>
<ul empty="true"><li>
<t>forbidden_zero_bit. Required to be zero in EVC. Note that the inclusion of
this bit in the NAL unit header was included to enable transport of EVC video o
ver MPEG-2 transport systems (avoidance of start code emulations) <xref target="
MPEG2S"/>. In this document, the value 1 may be used to indicate a syntax violat
ion, e.g., for a NAL unit resulting from aggregating a number of fragmented unit
s of a NAL unit but missing the last fragment, as described in <xref target="fun
its"/>.</t>
</li></ul>
<t>Type: 6 bits</t>
<ul empty="true"><li>
<t>nal_unit_type_plus1. This field allows the NAL Unit Type to be computed. Th
e NAL Unit Type (NalUnitType) is equal to the value found in this field, minus 1
; in other words:</t>
</li></ul>
<ul empty="true"><li>
<ul empty="true"><li>
<t>NalUnitType = nal_unit_type_plus1 - 1.</t>
</li></ul>
</li></ul>
<ul empty="true"><li>
<t>The NAL unit type is detailed in Table 4 of <xref target="EVC"/>. If the va
lue of NalUnitType is less than or equal to 23, the NAL unit is a VCL NAL unit.
Otherwise, the NAL unit is a non-VCL NAL unit. For a reference of all currentl
y defined NAL unit types and their semantics, please refer to Section 7.4.2.2 in
<xref target="EVC"/>. Note that nal_unit_type_plus1 MUST NOT be zero.</t>
</li></ul>
<t>TID: 3 bits</t>
<ul empty="true"><li>
<t>nuh_temporal_id. This field specifies the temporal identifier of the NAL u
nit. The value of TemporalId is equal to TID. TemporalId shall be equal to 0 if
it is an IDR NAL unit type (NAL unit type 1).</t>
</li></ul>
<t>Reserve: 5 bits</t>
<ul empty="true"><li>
<t>nuh_reserved_zero_5bits. This field shall be equal to the version of the EV
C standard. Values of nuh_reserved_zero_5bits greater than 0 are reserved for fu
ture use by ISO/IEC. Decoders conforming to a profile specified in <xref target=
"EVC"/>&#39;s Annex A shall ignore (i.e., remove from the bitstream and discard)
all NAL units with values of nuh_reserved_zero_5bits greater than 0.</t>
</li></ul>
<t>E: 1 bit</t>
<ul empty="true"><li>
<t>nuh_extension_flag. This field shall be equal to the version of the EVC sta
ndard. The value of nuh_extension_flag equal to 1 is reserved for future use by
ISO/IEC. Decoders conforming to a profile specified in <xref target="EVC"/>&#39;
s Annex A shall ignore (i.e., remove from the bitstream and discard) all NAL uni
ts with values of nuh_extension_flag equal to 1.</t>
</li></ul>
</section>
</section>
<section anchor="overview-of-the-payload-format"><name>Overview of the Payload F
ormat</name>
<t>This payload format defines the following processes required for transport of
EVC-coded data over RTP <xref target="RFC3550"/>:</t>
<t><list style="symbols">
<t>usage of RTP header with this payload format</t>
<t>packetization of EVC-coded NAL units into RTP packets using
three types of payload structures: a single NAL unit,
aggregation, and fragment unit</t>
<t>transmission of EVC NAL units of the same bitstream within a
single RTP stream.</t>
<t>media type parameters to be used with the Session Description
Protocol (SDP) <xref target="RFC8866"/></t>
<t>usage of RTCP feedback messages</t>
</list></t>
</section>
</section>
<section anchor="conventions"><name>Conventions</name>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &
quot;SHALL&quot;, &quot;SHALL
NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,
&quot;NOT RECOMMENDED&quot;,
&quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted
as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown above.</t>
</section> <dl>
<section anchor="definitionsandabbr"><name>Definitions and Abbreviations</name> <dt>F:</dt>
<dd><t>1 bit</t>
<dl>
<dt>forbidden_zero_bit:</dt>
<dd>Required to be zero in EVC. Note that the
inclusion of this bit in the NAL unit header was included to
enable transport of EVC video over MPEG-2 transport systems
(avoidance of start code emulations) <xref target="MPEG2S"/>. In
this document, the value 1 may be used to indicate a syntax
violation, e.g., for a NAL unit resulting from aggregating a
number of fragmented units of a NAL unit but missing the last
fragment, as described in <xref target="funits"/>.</dd></dl>
</dd>
<dt>Type:</dt>
<dd>
<t>6 bits</t>
<dl>
<dt>nal_unit_type_plus1:</dt>
<dd><t>This field allows the NAL Unit Type to
be computed. The NAL Unit Type (NalUnitType) is equal to the
value found in this field, minus 1; in other words:</t>
<t>NalUnitType = nal_unit_type_plus1 - 1.</t>
<t>The NAL unit type is detailed in Table 4 of <xref
target="EVC"/>. If the value of NalUnitType is less than or
equal to 23, the NAL unit is a VCL NAL unit. Otherwise, the NAL
unit is a non-VCL NAL unit. For a reference of all currently
defined NAL unit types and their semantics, please refer to
Section 7.4.2.2 of <xref target="EVC"/>. Note that
nal_unit_type_plus1 <bcp14>MUST NOT</bcp14> be zero.</t></dd></dl>
</dd>
<dt>TID:</dt>
<dd><t>3 bits</t>
<dl>
<dt>nuh_temporal_id:</dt>
<dd>This field specifies the temporal identifier
of the NAL unit. The value of TemporalId is equal to
TID. TemporalId shall be equal to 0 if it is an IDR NAL unit type
(NAL unit type 1).</dd></dl>
</dd>
<dt>Reserve:</dt>
<dd><t>5 bits</t>
<dl>
<dt>nuh_reserved_zero_5bits:</dt>
<dd>This field shall be equal to the version of the EVC
standard. Values of nuh_reserved_zero_5bits greater than 0 are
reserved for future use by ISO/IEC. Decoders conforming to a
profile specified in Annex A of <xref target="EVC"/> shall ignore
(i.e., remove from the bitstream and discard) all NAL units with
values of nuh_reserved_zero_5bits greater than 0.</dd></dl>
</dd>
<dt>E:</dt>
<dd><t>1 bit</t>
<dl>
<dt>nuh_extension_flag:</dt>
<dd>This field shall be equal to the version of
the EVC standard. The value of nuh_extension_flag equal to 1 is
reserved for future use by ISO/IEC. Decoders conforming to a
profile specified in Annex A of <xref target="EVC"/> shall ignore
(i.e., remove from the bitstream and discard) all NAL units with
values of nuh_extension_flag equal to 1.</dd></dl>
</dd>
</dl>
</section>
</section>
<section anchor="overview-of-the-payload-format">
<name>Overview of the Payload Format</name>
<t>This payload format defines the following processes required for tran
sport of EVC-coded data over RTP <xref target="RFC3550"/>:</t>
<ul spacing="normal">
<li>usage of RTP header with this payload format</li>
<li>packetization of EVC-coded NAL units into RTP packets using
three types of payload structures: a single NAL unit, aggregation,
and fragment unit</li>
<li>transmission of EVC NAL units of the same bitstream within a
single RTP stream</li>
<li>usage of media type parameters to be used with the Session
Description Protocol (SDP) <xref target="RFC8866"/></li>
<li>usage of RTCP feedback messages</li>
</ul>
</section>
</section>
<section anchor="conventions">
<name>Conventions</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<section anchor="definitions"><name>Definitions</name> </section>
<t>This document uses the terms and definitions of EVC. <xref target="definitio <section anchor="definitionsandabbr">
nforevc"/> <name>Definitions and Abbreviations</name>
<section anchor="definitions">
<name>Definitions</name>
<t>This document uses the terms and definitions of EVC. <xref target="d
efinitionforevc"/>
lists relevant definitions from <xref target="EVC"/> for convenience. <xref tar get="def"/> lists relevant definitions from <xref target="EVC"/> for convenience. <xref tar get="def"/>
provides definitions specific to this document.</t> provides definitions specific to this document.</t>
<section anchor="definitionforevc">
<name>Definitions from the EVC Standard</name>
<dl spacing="normal" newline="true">
<dt>Access Unit (AU):</dt>
<dd>A set of NAL units that are associated with each other
according to a specified classification rule, are consecutive in
decoding order, and contain exactly one coded picture.</dd>
<dt>Adaptation Parameter Set (APS):</dt>
<dd>A syntax structure containing syntax elements that apply to
zero or more slices as determined by zero or more syntax elements
found in slice headers.</dd>
<dt>Bitstream:</dt>
<dd>A sequence of bits, in the form of a NAL unit stream or a byte
stream, that forms the representation of coded pictures and
associated data forming one or more CVSs.</dd>
<dt>Coded Picture:</dt>
<dd>A coded representation of a picture containing all CTUs of the
picture.</dd>
<dt>Coded Video Sequence (CVS):</dt>
<dd>A sequence of access units that consists, in decoding order,
of an IDR access unit, followed by zero or more access units that
are not IDR access units, including all subsequent access units up
to but not including any subsequent access unit that is an IDR
access unit.</dd>
<dt>Coding Tree Block (CTB):</dt>
<dd>An NxN block of samples for some value of N such that the
division of a component into CTBs is a partitioning.</dd>
<dt>Coding Tree Unit (CTU):</dt>
<section anchor="definitionforevc"><name>Definitions from the EVC Standard</name <dd>A CTB of luma samples, two corresponding CTBs of chroma
> samples of a picture that has three sample arrays, or a CTB of
samples of a monochrome picture or a picture that is coded using
<t>Access Unit: A set of NAL units that are associated with each other according three separate color planes and syntax structures used to code
to a specified classification rule, are consecutive in decoding order, and cont the samples.</dd>
ain exactly one coded picture.</t> <dt>Decoded Picture:</dt>
<dd>A decoded picture is derived by decoding a coded picture.</dd>
<t>Adaptation parameter set (APS): A syntax structure containing syntax <dt>Decoded Picture Buffer (DPB):</dt>
elements that apply to zero or more slices as determined by zero or <dd>A buffer holding decoded pictures for reference, output
more syntax elements found in slice headers.</t> reordering, or output delay specified for the hypothetical
reference decoder in Annex C of the <xref target="EVC"/>
<t>Bitstream: A sequence of bits, in the form of a NAL unit stream or a byte str standard.</dd>
eam, that forms the representation <dt>Dynamic Range Adjustment (DRA):</dt>
of coded pictures and associated data forming one or more coded video sequences <dd>A mapping process that is applied to the decoded picture prior to
(CVSs).</t> cropping and output as part of the decoding process; it is
controlled by parameters conveyed in an Adaptation Parameter Set
<t>Coded Picture: A coded representation of a picture containing all CTUs of the (APS).</dd>
picture.</t> <dt>Hypothetical Reference Decoder (HRD):</dt>
<dd>A hypothetical decoder model that specifies constraints on the
<t>Coded Video Sequence (CVS): A sequence of access units that consists, in deco variability of conforming NAL unit streams or conforming byte
ding order, of an IDR access unit, followed by zero or more access units that ar streams that an encoding process may produce.</dd>
e not IDR access units, including all subsequent access units up to but not incl <dt>IDR Access Unit:</dt>
uding any subsequent access unit that is an IDR access unit.</t> <dd>An access unit in which the coded picture is an IDR picture.</dd>
<dt>IDR Picture:</dt>
<t>Coding Tree Block (CTB): An NxN block of samples for some value of N such tha <dd>The coded picture for which each VCL NAL unit has NalUnitType equ
t the division of a component into CTBs is a partitioning.</t> al to IDR_NUT.</dd>
<dt>Level:</dt>
<t>Coding Tree Unit (CTU): A CTB of luma samples, two corresponding CTBs of chro <dd>A defined set of constraints on the values that may be taken
ma samples of a picture that has three sample arrays, or a CTB of samples of a m by the syntax elements and variables of this document, or the
onochrome picture or a picture that is coded using three separate colour planes value of a transform coefficient prior to scaling.</dd>
and syntax structures used to code the samples.</t> <dt>Network Abstraction Layer (NAL) Unit:</dt>
<dd>A syntax structure containing an indication of the type of
<t>Decoded Picture: A decoded picture is derived by decoding a coded picture.</t data to follow and bytes containing that data in the form of an
> RBSP interspersed as necessary.</dd>
<dt>Network Abstraction Layer (NAL) Unit Stream:</dt>
<t>Decoded Picture Buffer (DPB): A buffer holding decoded pictures for reference <dd>A sequence of NAL units.</dd>
, output reordering, or output <dt>Non-IDR Picture:</dt>
delay specified for the hypothetical reference decoder in Annex C of <xref targe <dd>A coded picture that is not an IDR picture.</dd>
t="EVC"/> standard.</t> <dt>Non-VCL NAL Unit:</dt>
<dd>A NAL unit that is not a VCL NAL unit.</dd>
<t>Dynamic Range Adjustment (DRA): A mapping process that is applied to decoded <dt>Picture Parameter Set (PPS):</dt>
picture prior to cropping and output as part of the decoding process and is con <dd>A syntax structure containing syntax elements that apply to
trolled by parameters conveyed in an Adaptation Parameter Set (APS).</t> zero or more entire coded pictures as determined by a syntax
element found in each slice header.</dd>
<t>Hypothetical Reference Decoder (HRD): A hypothetical decoder model that speci <dt>Picture Order Count (POC):</dt>
fies constraints on the variability of conforming NAL unit streams or conforming <dd>A variable that is associated with each picture, uniquely
byte streams that an encoding process may produce.</t> identifies the associated picture among all pictures in the CVS,
and (when the associated picture is to be output from the DPB) indica
<t>IDR access unit: access unit in which the coded picture is an IDR picture.</t tes the position of the associated picture
> in output order relative to the output order positions of the
other pictures in the same CVS that are to be output from the
<t>IDR picture: coded picture for which each VCL NAL unit has NalUnitType equal DPB.</dd>
to IDR_NUT.</t> <dt>Raw Byte Sequence Payload (RBSP):</dt>
<dd>A syntax structure containing an integer number of bytes that
<t>Level: A defined set of constraints on the values that may be taken by the sy is encapsulated in a NAL unit and that is either empty or has the
ntax elements and variables of this document, or the value of a transform coeffi form of a string of data bits containing syntax elements followed
cient prior to scaling.</t> by an RBSP stop bit and zero or more subsequent bits equal to
0.</dd>
<t>Network Abstraction Layer (NAL) unit: A syntax structure containing an indica <dt>Sequence Parameter Set (SPS):</dt>
tion of the type of data to follow <dd>A syntax structure containing syntax elements that apply to
and bytes containing that data in the form of an RBSP interspersed as necessary. zero or more entire CVSs as determined by the content of a syntax
</t> element found in the PPS referred to by a syntax element found in
each slice header.</dd>
<t>Network Abstraction Layer (NAL) Unit Stream: A sequence of NAL units.</t> <dt>Slice:</dt>
<dd>An integer number of tiles of a picture in the tile scan of
<t>Non-IDR Picture: A coded picture that is not an IDR picture.</t> the picture, exclusively contained in a single NAL unit.</dd>
<dt>Tile:</dt>
<t>Non-VCL NAL Unit: A NAL unit that is not a VCL NAL unit.</t> <dd>A rectangular region of CTUs within a particular tile column and
a particular tile row in a picture.</dd>
<t>Picture Parameter Set (PPS): A syntax structure containing syntax elements th <dt>Tile Column:</dt>
at apply to zero or more entire coded pictures as determined by a syntax element <dd>A rectangular region of CTUs having a height equal to the height
found in each slice header.</t> of the picture and width specified by syntax elements in the
PPS.</dd>
<t>Picture Order Count (POC): A variable that is associated with each picture, u <dt>Tile Row:</dt>
niquely identifies the associated picture among all pictures in the CVS, and, wh <dd>A rectangular region of CTUs having a height specified by
en the associated picture is to be output from the decoded picture buffer, indic syntax elements in the PPS and a width equal to the width of the
ates the position of the associated picture in output order relative to the outp picture.</dd>
ut order positions of the other pictures in the same CVS that are to be output f <dt>Tile Scan:</dt>
rom the decoded picture buffer.</t> <dd>A specific sequential ordering of CTUs partitioning a picture
in which the CTUs are ordered consecutively in CTU raster scan in
<t>Raw Byte Sequence Payload (RBSP): A syntax structure containing an integer nu a tile, whereas tiles in a picture are ordered consecutively in a
mber of bytes that is encapsulated in a NAL unit and that is either empty or has raster scan of the tiles of the picture.</dd>
the form of a string of data bits containing syntax elements followed by an RBS <dt>Video Coding Layer (VCL) NAL Unit:</dt>
P stop bit and zero or more subsequent bits equal to 0.</t> <dd>A collective term for coded slice NAL units and the subset of
NAL units that have reserved values of NalUnitType that are
<t>Sequence Parameter Set (SPS): A syntax structure containing syntax elements t classified as VCL NAL units in this document.</dd>
hat apply to zero or more entire CVSs as determined by the content of a syntax e </dl>
lement found in the PPS referred to by a syntax element found in each slice head </section>
er.</t> <section anchor="def">
<name>Definitions Specific to This Document</name>
<t>Slice: integer number of tiles of a picture in the tile scan of the picture a <dl newline="true" spacing="normal">
nd that are exclusively contained in a single NAL unit.</t> <dt>Media-Aware Network Element (MANE):</dt><dd><t>A network
element, such as a middlebox, selective forwarding unit, or
<t>Tile: rectangular region of CTUs within a particular tile column and a partic application-layer gateway, that is capable of parsing certain
ular tile row in a picture.</t> aspects of the RTP payload headers or the RTP payload and reacting
to their contents.</t>
<t>Tile column: rectangular region of CTUs having a height equal to the height o <aside><t>Informative note: The concept of a MANE goes beyond normal
f the picture and width specified by syntax elements in the PPS.</t> routers or gateways in that a MANE has to be aware of the
signaling (e.g., to learn about the payload type mappings of the
<t>Tile row: A rectangular region of CTUs having a height specified by syntax el media streams), and in that it has to be trusted when working with
ements in the PPS and a width equal to the width of the picture.</t> Secure RTP (SRTP). The advantage of using MANEs is that they
allow packets to be dropped according to the needs of the media
<t>Tile scan: A specific sequential ordering of CTUs partitioning a picture in w coding. For example, if a MANE has to drop packets due to
hich the CTUs are ordered consecutively in CTU raster scan in a tile whereas til congestion on a certain link, it can identify and remove those
es in a picture are ordered consecutively in a raster scan of the tiles of the p packets whose elimination produces the least adverse effect on the
icture.</t> user experience. After dropping packets, MANEs must rewrite RTCP
packets to match the changes to the RTP stream, as specified in
<t>Video coding layer (VCL) NAL unit: A collective term for coded slice NAL unit <xref target="RFC3550" section="7" sectionFormat="of"/>.</t></aside>
s and the subset of NAL units that have reserved values of NalUnitType that are </dd>
classified as VCL NAL units in this document.</t> <dt>NAL unit decoding order:</dt><dd>A NAL unit order that conforms
to the constraints on NAL unit order given in Section 7.4.2.3 of
</section> <xref target="EVC"/> and follows the order of NAL units in the
<section anchor="def"><name>Definitions Specific to This Document</name> bitstream.</dd>
<dt>NALU-time:</dt><dd>The value that the RTP timestamp would have
<t>Media-Aware Network Element (MANE): A network element, such as a if the NAL unit would be transported in its own RTP packet.</dd>
middlebox, selective forwarding unit, or application-layer gateway <dt>NAL unit output order:</dt><dd>A NAL unit order in which NAL
that is capable of parsing certain aspects of the RTP payload headers units of different access units are in the output order of the
or the RTP payload and reacting to their contents.</t> decoded pictures corresponding to the access units, as specified in
<xref target="EVC"/>, and in which NAL units within an access unit
<ul empty="true"><li> are in their decoding order.</dd>
<t>Informative note: The concept of a MANE goes beyond normal routers or gatew <dt>RTP stream:</dt><dd>See <xref target="RFC7656"/>. Within the
ays in that a MANE has to be aware of the signaling (e.g., to learn about the pa scope of this document, one RTP stream is utilized to transport an
yload type mappings of the media streams), and in that it has to be trusted when EVC bitstream, which may contain one or more temporal
working with Secure RTP (SRTP). The advantage of using MANEs is that they allo sub-layers.</dd>
w packets to be dropped according to the needs of the media coding. For example <dt>Transmission order:</dt><dd>The order of packets in ascending
, if a MANE has to drop packets due to congestion on a certain link, it can iden RTP sequence number order (in modulo arithmetic). Within an
tify and remove those packets whose elimination produces the least adverse effec Aggregation Packet (AP), the NAL unit transmission order is the same a
t on the user experience. After dropping packets, MANEs must rewrite RTCP packe s
ts to match the changes to the RTP stream, as specified in Section 7 of <xref ta the order of appearance of NAL units in the packet.</dd>
rget="RFC3550"/>.</t> </dl>
</li></ul> </section>
</section>
<t>NAL unit decoding order: A NAL unit order that conforms to the constraints on <section anchor="abbreviations">
NAL unit order given in Section 7.4.2.3 in <xref target="EVC"/>, follow the ord <name>Abbreviations</name>
er of NAL units in the bitstream.</t> <dl newline="false" spacing="normal" indent="9">
<dt>AU</dt>
<t>NALU-time: The value that the RTP timestamp would have if the NAL unit would <dd>Access Unit</dd>
be transported in its own RTP packet.</t> <dt>AP</dt>
<dd>Aggregation Packet</dd>
<t>NAL unit output order: A NAL unit order in which NAL units of different acces <dt>APS</dt>
s units are in the output order of the decoded pictures corresponding to the acc <dd>Adaptation Parameter Set</dd>
ess units, as specified in <xref target="EVC"/>, and in which NAL units within a <dt>ATS</dt>
n access unit are in their decoding order.</t> <dd>Adaptive Transform Selection</dd>
<dt>B</dt>
<t>RTP stream: See <xref target="RFC7656"/>. Within the scope of this document, <dd>Bi-predictive</dd>
one RTP stream is utilized to transport a EVC bitstream, which may contain one <dt>CBR</dt>
or more temporal sub-layers.</t> <dd>Constant Bit Rate</dd>
<dt>CPB</dt>
<t>Transmission order: The order of packets in ascending RTP sequence number ord <dd>Coded Picture Buffer</dd>
er (in modulo arithmetic). Within an aggregation packet, the NAL unit transmiss <dt>CTB</dt>
ion order is the same as the order of appearance of NAL units in the packet.</t> <dd>Coding Tree Block</dd>
<dt>CTU</dt>
</section> <dd>Coding Tree Unit</dd>
</section> <dt>CVS</dt>
<section anchor="abbreviations"><name>Abbreviations</name> <dd>Coded Video Sequence</dd>
<dt>DPB</dt>
<t>AU &#160;&#160;&#160;&#160;&#160;&#160;&#160; Access Unit</t> <dd>Decoded Picture Buffer</dd>
<dt>HRD</dt>
<t>AP &#160;&#160;&#160;&#160;&#160;&#160;&#160; Aggregation Packet</t> <dd>Hypothetical Reference Decoder</dd>
<dt>HSS</dt>
<t>APS &#160;&#160;&#160;&#160;&#160;&#160; Adaptation Parameter Set</t> <dd>Hypothetical Stream Scheduler</dd>
<dt>I</dt>
<t>ATS &#160;&#160;&#160;&#160;&#160;&#160; Adaptive Transform Selection</t> <dd>Intra</dd>
<dt>IDR</dt>
<t>B &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; Bi-predictive</t> <dd>Instantaneous Decoding Refresh</dd>
<dt>LSB</dt>
<t>CBR &#160;&#160;&#160;&#160;&#160;&#160; Constant Bit Rate</t> <dd>Least Significant Bit</dd>
<dt>LTRP</dt>
<t>CPB &#160;&#160;&#160;&#160;&#160;&#160; Coded Picture Buffer</t> <dd>Long-Term Reference Picture</dd>
<dt>MMVD</dt>
<t>CTB &#160;&#160;&#160;&#160;&#160;&#160; Coding Tree Block</t> <dd>Merge with Motion Vector Difference</dd>
<dt>MSB</dt>
<t>CTU &#160;&#160;&#160;&#160;&#160;&#160; Coding Tree Unit</t> <dd>Most Significant Bit</dd>
<dt>NAL</dt>
<t>CVS &#160;&#160;&#160;&#160;&#160;&#160; Coded Video Sequence</t> <dd>Network Abstraction Layer</dd>
<dt>P</dt>
<t>DPB &#160;&#160;&#160;&#160;&#160;&#160; Decoded Picture Buffer</t> <dd>Predictive</dd>
<dt>POC</dt>
<t>HRD &#160;&#160;&#160;&#160;&#160;&#160; Hypothetical Reference Decoder</t> <dd>Picture Order Count</dd>
<dt>PPS</dt>
<t>HSS &#160;&#160;&#160;&#160;&#160;&#160; Hypothetical Stream Scheduler</t> <dd>Picture Parameter Set</dd>
<dt>QP</dt>
<t>I &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; Intra</t> <dd>Quantization Parameter</dd>
<dt>RBSP</dt>
<t>IDR &#160;&#160;&#160;&#160;&#160;&#160; Instantaneous Decoding Refresh</t> <dd>Raw Byte Sequence Payload</dd>
<dt>RGB</dt>
<t>LSB &#160;&#160;&#160;&#160;&#160;&#160; Least Significant Bit</t> <dd>Red, Green, and Blue</dd>
<dt>SAR</dt>
<t>LTRP &#160;&#160;&#160;&#160;&#160; Long-Term Reference Picture</t> <dd>Sample Aspect Ratio</dd>
<dt>SEI</dt>
<t>MMVD &#160;&#160;&#160;&#160;&#160; Merge with Motion Vector Difference</t> <dd>Supplemental Enhancement Information</dd>
<dt>SODB</dt>
<t>MSB &#160;&#160;&#160;&#160;&#160;&#160; Most Significant Bit</t> <dd>String Of Data Bits</dd>
<dt>SPS</dt>
<t>NAL &#160;&#160;&#160;&#160;&#160;&#160; Network Abstraction Layer</t> <dd>Sequence Parameter Set</dd>
<dt>STRP</dt>
<t>P &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160; Predictive</t> <dd>Short-Term Reference Picture</dd>
<dt>VBR</dt>
<t>POC &#160;&#160;&#160;&#160;&#160;&#160; Picture Order Count</t> <dd>Variable Bit Rate</dd>
<dt>VCL</dt>
<t>PPS &#160;&#160;&#160;&#160;&#160;&#160; Picture Parameter Set</t> <dd>Video Coding Layer</dd>
</dl>
<t>QP &#160;&#160;&#160;&#160;&#160;&#160;&#160; Quantization Parameter</t> </section>
</section>
<t>RBSP &#160;&#160;&#160;&#160;&#160; Raw Byte Sequence Payload</t> <section anchor="RTPPayloadFormat">
<name>RTP Payload Format</name>
<t>RGB &#160;&#160;&#160;&#160;&#160;&#160; Same as GBR</t> <section anchor="RTPHeaderUsage">
<name>RTP Header Usage</name>
<t>SAR &#160;&#160;&#160;&#160;&#160;&#160; Sample Aspect Ratio</t> <t>The format of the RTP header is specified in <xref target="RFC3550"/>
(included as
<t>SEI &#160;&#160;&#160;&#160;&#160;&#160; Supplemental Enhancement Information
</t>
<t>SODB &#160;&#160;&#160;&#160;&#160; String Of Data Bits</t>
<t>SPS &#160;&#160;&#160;&#160;&#160;&#160; Sequence Parameter Set</t>
<t>STRP &#160;&#160;&#160;&#160;&#160; Short-Term Reference Picture</t>
<t>VBR &#160;&#160;&#160;&#160;&#160;&#160; Variable Bit Rate</t>
<t>VCL &#160;&#160;&#160;&#160;&#160;&#160; Video Coding Layer</t>
</section>
</section>
<section anchor="RTPPayloadFormat"><name>RTP Payload Format</name>
<section anchor="RTPHeaderUsage"><name>RTP Header Usage</name>
<t>The format of the RTP header is specified in <xref target="RFC3550"/> (reprin
ted as
<xref target="rtp-header"/> for convenience). This payload format uses the fiel ds of <xref target="rtp-header"/> for convenience). This payload format uses the fiel ds of
the header in a manner consistent with that specification.</t> the header in a manner consistent with that specification.</t>
<t>The RTP payload (and the settings for some RTP header bits) for
APs and Fragmentation Units (FUs) are specified in Sections
<xref target="aps" format="counter"/> and <xref target="funits" format="counter"
/>, respectively.</t>
<t>The RTP payload (and the settings for some RTP header bits) for <figure anchor="rtp-header">
aggregation packets and fragmentation units are specified in <name>RTP Header According to RFC 3550</name>
<xref target="aps"/> and <xref target="funits"/>, respectively.</t> <artwork><![CDATA[
<figure anchor="rtp-header"><sourcecode type="~"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number | |V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers | | contributing source (CSRC) identifiers |
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork
>
RTP Header According to [RFC3550] </figure>
]]></sourcecode></figure>
<t>The RTP header information to be set according to this RTP payload format is
set as follows:</t>
<t>Marker bit (M): 1 bit</t>
<ul empty="true"><li>
<t>Set for the last packet of the access unit, carried in the current
RTP stream. This is in line with the normal use of the M bit in
video formats to allow an efficient playout buffer handling.</t>
</li></ul>
<t>Payload Type (PT): 7 bits</t>
<ul empty="true"><li>
<t>The assignment of an RTP payload type for this new payload format
is outside the scope of this document and will not be specified
here. The assignment of a payload type has to be performed either
through the profile used or in a dynamic way.</t>
</li></ul>
<t>Sequence Number (SN): 16 bits</t>
<ul empty="true"><li>
<t>Set and used in accordance with <xref target="RFC3550"/>.</t>
</li></ul>
<t>Timestamp: 32 bits</t>
<ul empty="true"><li>
<t>The RTP timestamp is set to the sampling timestamp of the content. A 90 kHz
clock rate MUST be used. If the NAL unit has no timing properties of its own (
e.g., parameter sets or certain SEI NAL units), the RTP timestamp MUST be set to
the RTP timestamp of the coded picture of the access unit in which the NAL unit
is included. For SEI messages, this information is specified in Annex D of <xr
ef target="EVC"/>. Receivers MUST use the RTP timestamp for the display process,
even when the bitstream contains picture timing SEI messages or decoding unit i
nformation SEI messages as specified in <xref target="EVC"/>.</t>
</li></ul>
<t>Synchronization source (SSRC): 32 bits</t>
<ul empty="true"><li>
<t>Used to identify the source of the RTP packets. According to this document
, a single SSRC is used for all parts of a single bitstream.</t>
</li></ul>
</section>
<section anchor="PayloadHeaderUsage"><name>Payload Header Usage</name>
<t>The first two bytes of the payload of an RTP packet are referred to as the pa
yload header. The payload header consists of the same fields (F, TID, Reserve a
nd E) as the NAL unit header as shown in <xref target="NALUnitHeader"/>, irrespe
ctive of the type of the payload structure.</t>
<t>The TID value indicates (among other things) the relative importance of an RT
P packet, for example, because NAL units with larger TID value are not used for
the decoding of the ones with smaller TID value. A lower value of TID indicates
a higher importance. More-important NAL units MAY be better protected against tr
ansmission losses than less-important NAL units.</t>
</section>
<section anchor="PayloadStructures"><name>Payload Structures</name>
<t>Three different types of RTP packet payload structures are specified. A recei
ver can identify the type of an RTP packet payload through the Type field in the
payload header.</t>
<t>The three different payload structures are as follows:</t>
<t><list style="symbols">
<t>Single NAL unit packet: Contains a single NAL unit in the payload, and the
NAL unit header of the NAL unit also serves as the payload header. This payload
structure is specified in <xref target="SingleNALUnit"/>.</t>
<t>Aggregation Packet (AP): Contains more than one NAL unit within one access
unit. This payload structure is specified in <xref target="aps"/>.</t>
<t>Fragmentation Unit (FU): Contains a subset of a single NAL unit. This paylo
ad structure is specified in <xref target="funits"/>.</t>
</list></t>
<section anchor="SingleNALUnit"><name>Single NAL Unit Packets</name> <t>The RTP header information to be set according to this RTP payload fo
rmat is set as follows:</t>
<dl newline="false" spacing="normal">
<dt>Marker bit (M):</dt>
<dd><t>1 bit</t>
<t>Set for the last packet of the access unit and carried in the
current RTP stream. This is in line with the normal use of the M
bit in video formats to allow an efficient playout buffer
handling.</t>
</dd>
<dt>Payload Type (PT):</dt>
<dd><t>7 bits</t>
<t>The assignment of an RTP payload type for this new payload format
is outside the scope of this document and will not be specified
here. The assignment of a payload type has to be performed either
through the profile used or in a dynamic way.</t>
</dd>
<dt>Sequence Number (SN):</dt>
<dd><t>16 bits</t>
<t>Set and used in accordance with <xref target="RFC3550"/>.</t>
</dd>
<dt>Timestamp:</dt>
<dd><t>32 bits</t>
<t>The RTP timestamp is set to the sampling timestamp of the
content. A 90 kHz clock rate <bcp14>MUST</bcp14> be used. If the
NAL unit has no timing properties of its own (e.g., parameter sets
or certain SEI NAL units), the RTP timestamp <bcp14>MUST</bcp14> be
set to the RTP timestamp of the coded picture of the access unit in
which the NAL unit is included. For SEI messages, this information
is specified in Annex D of <xref target="EVC"/>. Receivers
<bcp14>MUST</bcp14> use the RTP timestamp for the display process,
even when the bitstream contains picture timing SEI messages or
decoding unit information SEI messages as specified in <xref
target="EVC"/>.</t>
</dd>
<dt>Synchronization source (SSRC):</dt>
<dd><t>32 bits</t>
<t>Used to identify the source of the RTP packets. According to
this document, a single SSRC is used for all parts of a single
bitstream.</t>
</dd>
</dl>
<t>A single NAL unit packet contains exactly one NAL unit, and consists of a pay </section>
load header as defined in Table 4 of <xref target="EVC"/> (denoted as PayloadHdr <section anchor="PayloadHeaderUsage">
), followed by a conditional 16-bit DONL field (in network byte order), and the <name>Payload Header Usage</name>
NAL unit payload data (the NAL unit excluding its NAL unit header) of the contai <t>The first two bytes of the payload of an RTP packet are referred to
ned NAL unit, as shown in <xref target="single-nhr"/>.</t> as the payload header. The payload header consists of the same fields
(F, TID, Reserve, and E) as the NAL unit header, as shown in <xref
target="NALUnitHeader"/>, irrespective of the type of the payload
structure.</t>
<t>The TID value indicates (among other things) the relative
importance of an RTP packet, for example, because NAL units with
larger TID values are not used to decode the ones with
smaller TID values. A lower value of TID indicates a higher
importance. More important NAL units <bcp14>MAY</bcp14> be better
protected against transmission losses than less important NAL
units.</t>
</section>
<section anchor="PayloadStructures">
<name>Payload Structures</name>
<t>Three different types of RTP packet payload structures are specified.
A receiver can identify the type of an RTP packet payload through the Type fiel
d in the payload header.</t>
<t>The three different payload structures are as follows:</t>
<ul>
<li>Single NAL unit packet: Contains a single NAL unit in
the payload, and the NAL unit header of the NAL unit also serves as
the payload header. This payload structure is specified in <xref
target="SingleNALUnit"/>.</li>
<li>Aggregation Packet (AP): Contains more than one NAL unit
within one access unit. This payload structure is specified in
<xref target="aps"/>.</li>
<li>Fragmentation Unit (FU): Contains a subset of a single
NAL unit. This payload structure is specified in <xref
target="funits"/>.</li>
</ul>
<section anchor="SingleNALUnit">
<name>Single NAL Unit Packets</name>
<t>A single NAL unit packet contains exactly one NAL unit and
consists of a payload header as defined in Table 4 of <xref
target="EVC"/> (denoted as PayloadHdr), followed by a conditional
16-bit DONL field (in network byte order), and the NAL unit payload
data (the NAL unit excluding its NAL unit header) of the contained
NAL unit, as shown in <xref target="single-nhr"/>.</t>
<figure anchor="single-nhr"><artwork><![CDATA[ <figure anchor="single-nhr">
<name>The Structure of a Single NAL Unit Packet</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr | DONL (conditional) | | PayloadHdr | DONL (conditional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| NAL unit payload data | | NAL unit payload data |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The Structure of a Single NAL Unit Packet
]]></artwork></figure>
<t>The DONL field, when present, specifies the value of the 16 least significant
bits of the decoding order number of the contained NAL unit. If sprop-max-don-
diff (defined in <xref target="optionalParameters"/> is greater than 0, the DONL
field MUST be present, and the variable DON for the contained NAL unit is deriv
ed as equal to the value of the DONL field. Otherwise (sprop-max-don-diff is eq
ual to 0), the DONL field MUST NOT be present.</t>
</section>
<section anchor="aps"><name>Aggregation Packets (APs)</name>
<t>Aggregation Packets (APs) enable the reduction of packetization overhead for
small NAL units, such as most of the non-VCL NAL units, which are often only a f
ew octets in size.</t>
<t>An AP aggregates NAL units of one access unit, and it MUST NOT contain NAL un
its from more than one AU. Each NAL unit to be carried in an AP is encapsulated
in an aggregation unit. NAL units aggregated in one AP are included in NAL-unit-
decoding order.</t>
<t>An AP consists of a payload header, as defined in Table 4 of <xref target="EV <t>The DONL field, when present, specifies the value of the 16 least s
C"/> (denoted here as PayloadHdr with Type=56) followed by two or more aggregati ignificant bits of the decoding order number of the contained NAL unit. If spro
on units, as shown in <xref target="au-hdr"/>.</t> p-max-don-diff (defined in <xref target="optionalParameters"/>) is greater than
0, the DONL field <bcp14>MUST</bcp14> be present, and the variable DON for the c
ontained NAL unit is derived as equal to the value of the DONL field. Otherwise
(where sprop-max-don-diff is equal to 0), the DONL field <bcp14>MUST NOT</bcp14
> be present.</t>
</section>
<section anchor="aps">
<name>Aggregation Packets (APs)</name>
<t>Aggregation Packets (APs) enable the reduction of packetization ove
rhead for small NAL units, such as most of the non-VCL NAL units, which are ofte
n only a few octets in size.</t>
<t>An AP aggregates NAL units of one access unit, and it <bcp14>MUST N
OT</bcp14> contain NAL units from more than one AU. Each NAL unit to be carried
in an AP is encapsulated in an aggregation unit. NAL units aggregated in one AP
are included in NAL-unit-decoding order.</t>
<t>An AP consists of a payload header, as defined in Table 4 of <xref
target="EVC"/> (denoted here as PayloadHdr with Type=56), followed by two or mor
e aggregation units, as shown in <xref target="au-hdr"/>.</t>
<figure anchor="au-hdr"><artwork><![CDATA[ <figure anchor="au-hdr">
<name>The Structure of an Aggregation Packet</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=56) | | | PayloadHdr (Type=56) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| two or more aggregation units | | two or more aggregation units |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The Structure of an Aggregation Packet
]]></artwork></figure>
<t>The fields in the payload header of an AP are set as follows. The F bit MUST
be equal to 0 if the F bit of each aggregated NAL unit is equal to zero; otherwi
se, it MUST be equal to 1. The Type field MUST be equal to 56.</t>
<t>The value of TID MUST be the smallest value of TID of all the aggregated NAL <t>The fields in the payload header of an AP are set as follows. The F
units. The value of Reserve and E MUST be equal to 0 for this specification.</t> bit <bcp14>MUST</bcp14> be equal to 0 if the F bit of each aggregated NAL unit
is equal to zero; otherwise, it <bcp14>MUST</bcp14> be equal to 1. The Type fiel
d <bcp14>MUST</bcp14> be equal to 56.</t>
<t>The value of TID <bcp14>MUST</bcp14> be the smallest value of TID o
f all the aggregated NAL units. The value of Reserve and E <bcp14>MUST</bcp14> b
e equal to 0 for this specification.</t>
<ul empty="true"><li> <aside><t>Informative note: All VCL NAL units in an AP have the
<t>Informative note: All VCL NAL units in an AP have the same TID value since same TID value since they belong to the same access unit. However,
they belong to the same access unit. However, an AP may contain non-VCL NAL unit an AP may contain non-VCL NAL units for which the TID value in the
s for which the TID value in the NAL unit header may be different from the TID v NAL unit header may be different from the TID value of the VCL NAL
alue of the VCL NAL units in the same AP.</t> units in the same AP.</t></aside>
</li></ul>
<t>An AP MUST carry at least two aggregation units and can carry as many aggrega <t>An AP <bcp14>MUST</bcp14> carry at least two aggregation units
tion units as necessary; however, the total amount of data in an AP obviously MU and can carry as many aggregation units as necessary; however, the
ST fit into an IP packet, and the size SHOULD be chosen so that the resulting IP total amount of data in an AP obviously <bcp14>MUST</bcp14> fit into
packet is smaller than the path MTU size so to avoid IP layer fragmentation. An an IP packet, and the size <bcp14>SHOULD</bcp14> be chosen so that
AP MUST NOT contain FUs specified in <xref target="funits"/>. APs MUST NOT be n the resulting IP packet is smaller than the path MTU size so to
ested; i.e., an AP can not contain another AP.</t> avoid IP layer fragmentation. An AP <bcp14>MUST NOT</bcp14> contain
FUs specified in <xref target="funits"/>. APs <bcp14>MUST
NOT</bcp14> be nested; i.e., an AP cannot contain another AP.</t>
<ul empty="true"><li> <aside><t>Informative note: If a receiver encounters nested
<t>Informative note: If a receiver encounters nested Aggregation Packets, whic APs, which is against the aforementioned
h is against the aforementioned requirement, it has several options, listed in o requirement, it has several options, listed in order of ease of
rder of ease of implementation: 1) Ignore the nested AP; 2) Ignore the nested AP implementation: 1) ignore the nested AP; 2) ignore the nested AP and
and report a &quot;packet loss&quot; to the decoder, if such functionality exis report a "packet loss" to the decoder, if such functionality exists
ts in the API, 3) Implement support for nested APs and extract the Network Abstr in the API; and 3) implement support for nested APs and extract the
action Layer (NAL) units from these nested APs.</t> NAL units from these nested APs.</t></aside>
</li></ul>
<t>The first aggregation unit in an AP consists of a conditional 16-bit DONL fie ld (in network byte order) followed by a 16-bit unsigned size information (in ne twork byte order) that indicates the size of the <t>The first aggregation unit in an AP consists of a conditional 16-bi t DONL field (in network byte order) followed by a 16-bit unsigned size informat ion (in network byte order) that indicates the size of the
NAL unit in bytes (excluding these two octets but including the NAL unit header) , followed by the NAL unit itself, including its NAL unit header, as shown in <x ref target="au-first-nhdr"/>.</t> NAL unit in bytes (excluding these two octets but including the NAL unit header) , followed by the NAL unit itself, including its NAL unit header, as shown in <x ref target="au-first-nhdr"/>.</t>
<figure anchor="au-first-nhdr"><artwork><![CDATA[ <figure anchor="au-first-nhdr">
<name>The Structure of the First Aggregation Unit in an AP</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : DONL (conditional) | NALU size | | : DONL (conditional) | NALU size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU size | | | NALU size | |
+-+-+-+-+-+-+-+-+ NAL unit | +-+-+-+-+-+-+-+-+ NAL unit |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The Structure of the First Aggregation Unit in an AP
]]></artwork></figure>
<ul empty="true"><li>
<t>Informative note: The first octet of <xref target="au-first-nhdr"/> (indica
ted by the first colon) belongs to a previous aggregation unit. It is depicted t
o emphasize that aggregation units are octet aligned only. Similarly, the NAL un
it carried in the aggregation unit can terminate at the octet boundary.</t>
</li></ul>
<t>The DONL field, when present, specifies the value of the 16 least significant
bits of the decoding order number of the aggregated NAL unit.</t>
<t>If sprop-max-don-diff is greater than 0, the DONL field MUST be present in an <aside><t>Informative note: The first octet of <xref
aggregation unit that is the first aggregation unit in an AP. The variable DON target="au-first-nhdr"/> (indicated by the first colon) belongs to a
for the aggregated NAL unit is derived as equal to the value of the DONL field, previous aggregation unit. It is depicted to emphasize that
and the variable DON for an aggregation unit that is not the first aggregation u aggregation units are octet aligned only. Similarly, the NAL unit
nit in an AP-aggregated NAL unit is derived as equal to the DON of the preceding carried in the aggregation unit can terminate at the octet
aggregated NAL unit in the same AP plus 1 modulo 65536. Otherwise (sprop-max-do boundary.</t></aside>
n-diff is equal to 0), the DONL field MUST NOT be present in an aggregation unit
that is the first aggregation unit in an AP</t>
<t>An aggregation unit that is not the first aggregation unit in an AP will be f <t>The DONL field, when present, specifies the value of the 16 least s
ollowed immediately by a 16-bit unsigned size information (in network byte order ignificant bits of the decoding order number of the aggregated NAL unit.</t>
) that indicates the size of the NAL unit in bytes (excluding these two octets b <t>If sprop-max-don-diff is greater than 0, the DONL field <bcp14>MUST
ut including the NAL unit header), followed by the NAL unit itself, including it </bcp14> be present in an aggregation unit that is the first aggregation unit in
s NAL unit header, as shown in <xref target="au-not-first-nhdr"/>.</t> an AP. The variable DON for the aggregated NAL unit is derived as equal to the
value of the DONL field, and the variable Decoding Order Number (DON) for an agg
regation unit that is not the first aggregation unit in an AP-aggregated NAL uni
t is derived as equal to the DON of the preceding aggregated NAL unit in the sam
e AP plus 1 modulo 65536. Otherwise (where sprop-max-don-diff is equal to 0), th
e DONL field <bcp14>MUST NOT</bcp14> be present in an aggregation unit that is t
he first aggregation unit in an AP.</t>
<t>An aggregation unit that is not the first aggregation unit in an AP
will be followed immediately by a 16-bit unsigned size information (in network
byte order) that indicates the size of the NAL unit in bytes (excluding these tw
o octets but including the NAL unit header), followed by the NAL unit itself, in
cluding its NAL unit header, as shown in <xref target="au-not-first-nhdr"/>.</t>
<figure anchor="au-not-first-nhdr"><artwork><![CDATA[ <figure anchor="au-not-first-nhdr">
<name> The Structure of an Aggregation Unit That Is Not the First Agg
regation Unit in an AP</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : NALU size | NAL unit | | : NALU size | NAL unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The Structure of an Aggregation Unit That Is Not the First
Aggregation Unit in an AP
]]></artwork></figure>
<ul empty="true"><li> <aside><t>Informative note: The first octet of <xref
<t>Informative note: The first octet of <xref target="au-not-first-nhdr"/> (in target="au-not-first-nhdr"/> (indicated by the first colon) belongs
dicated by the first colon) belongs to a previous aggregation unit. It is depict to a previous aggregation unit. It is depicted to emphasize that
ed to emphasize that aggregation units are octet aligned only. Similarly, the NA aggregation units are octet aligned only. Similarly, the NAL unit
L unit carried in the aggregation unit can terminate at the octet boundary.</t> carried in the aggregation unit can terminate at the octet
</li></ul> boundary.</t></aside>
<t><xref target="au-wout-donl"/> presents an example of an AP that contains two <t><xref target="au-wout-donl"/> presents an example of an AP that
aggregation contains two aggregation units, labeled "NALU 1" and "NALU 2",
units, labeled as NALU 1 and NALU 2 in the figure, without the DONL field without the DONL field being present.</t>
being present.</t>
<figure anchor="au-wout-donl"><artwork><![CDATA[ <figure anchor="au-wout-donl">
<name>An Example of an AP Packet Containing Two Aggregation Units wit
hout the DONL Field</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=56) | NALU 1 Size | | PayloadHdr (Type=56) | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | | | NALU 1 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 1 Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 1 Data |
| . . . | | . . . |
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | NALU 2 Size | NALU 2 HDR | | . . . | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | | | NALU 2 HDR | |
+-+-+-+-+-+-+-+-+ NALU 2 Data | +-+-+-+-+-+-+-+-+ NALU 2 Data |
| . . . | | . . . |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
An Example of an AP Packet Containing
Two Aggregation Units without the DONL Field
]]></artwork></figure>
<t><xref target="au-with-donl"/> presents an example of an AP that contains two <t><xref target="au-with-donl"/> presents an example of an AP that con
aggregation tains two aggregation
units, labeled as NALU 1 and NALU 2 in the figure, with the DONL field being p units, labeled "NALU 1" and "NALU 2", with the DONL field being present.</t>
resent.</t>
<figure anchor="au-with-donl"><artwork><![CDATA[ <figure anchor="au-with-donl">
<name>An Example of an AP Containing Two Aggregation Units with the D
ONL Field</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header | | RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=56) | NALU 1 DONL | | PayloadHdr (Type=56) | NALU 1 DONL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR | | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| NALU 1 Data . . . | | NALU 1 Data . . . |
| | | |
+ . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : NALU 2 Size | | : NALU 2 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 HDR | | | NALU 2 HDR | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 2 Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NALU 2 Data |
| | | |
| . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
An Example of an AP Containing
Two Aggregation Units with the DONL Field
]]></artwork></figure>
</section>
<section anchor="funits"><name>Fragmentation Units</name>
<t>Fragmentation Units (FUs) are introduced to enable fragmenting a single NAL u
nit into multiple RTP packets, possibly without cooperation or knowledge of the
EVC encoder. A fragment of a NAL unit consists of an integer number of consecut
ive octets of that NAL unit. Fragments of the same NAL unit MUST be sent in con
secutive order with ascending RTP sequence numbers (with no other RTP packets wi
thin the same RTP stream being sent between the first and last fragment).</t>
<t>When a NAL unit is fragmented and conveyed within FUs, it is referred to as a
fragmented NAL unit. APs MUST NOT be fragmented. FUs MUST NOT be nested; i.e.
, an FU must not contain a subset of another FU.</t>
<t>The RTP timestamp of an RTP packet carrying an FU is set to the NALU-time of
the fragmented NAL unit.</t>
<t>An FU consists of a payload header as defined in Table 4 of <xref target="EVC </section>
"/> (denoted as PayloadHdr with type=57), an FU header of one octet, a condition <section anchor="funits">
al 16-bit DONL field (in network byte order), and an FU payload, as shown in <xr <name>Fragmentation Units (FUs)</name>
ef target="fu-payload"/>.</t> <t>FUs are introduced to enable fragmenting a single NAL unit into mul
tiple RTP packets, possibly without cooperation or knowledge of the EVC encoder.
A fragment of a NAL unit consists of an integer number of consecutive octets o
f that NAL unit. Fragments of the same NAL unit <bcp14>MUST</bcp14> be sent in
consecutive order with ascending RTP sequence numbers (with no other RTP packets
within the same RTP stream being sent between the first and last fragment).</t>
<t>When a NAL unit is fragmented and conveyed within FUs, it is referr
ed to as a fragmented NAL unit. APs <bcp14>MUST NOT</bcp14> be fragmented. FUs
<bcp14>MUST NOT</bcp14> be nested; i.e., an FU must not contain a subset of ano
ther FU.</t>
<t>The RTP timestamp of an RTP packet carrying an FU is set to the NAL
U-time of the fragmented NAL unit.</t>
<t>An FU consists of a payload header as defined in Table 4 of <xref t
arget="EVC"/> (denoted as PayloadHdr with Type=57), an FU header of one octet, a
conditional 16-bit DONL field (in network byte order), and an FU payload, as sh
own in <xref target="fu-payload"/>.</t>
<figure anchor="fu-payload"><artwork><![CDATA[ <figure anchor="fu-payload">
<name>The Structure of an FU</name>
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PayloadHdr (Type=57) | FU header | DONL (cond) | | PayloadHdr (Type=57) | FU header | DONL (cond) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| DONL (cond) | | | DONL (cond) | |
|-+-+-+-+-+-+-+-+ | |-+-+-+-+-+-+-+-+ |
| FU payload | | FU payload |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding | | :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
The Structure of an FU
]]></artwork></figure>
<t>The fields in the payload header are set as follows. The Type field MUST be
equal to 57. The fields F, TID, Reserve and E MUST be equal to the fields F, TI
D, Reserve and E, respectively, of the fragmented NAL unit.</t>
<t>The FU header consists of an S bit, an E bit, and a 6-bit FuType field, as sh <t>The fields in the payload header are set as follows. The Type fiel
own in <xref target="fu-header"/>.</t> d <bcp14>MUST</bcp14> be equal to 57. The fields F, TID, Reserve, and E <bcp14>
MUST</bcp14> be equal to the fields F, TID, Reserve, and E, respectively, of the
fragmented NAL unit.</t>
<t>The FU header consists of an S bit, an E bit, and a 6-bit FuType fi
eld, as shown in <xref target="fu-header"/>.</t>
<figure anchor="fu-header"><artwork><![CDATA[ <figure anchor="fu-header">
<name>The Structure of FU Header</name>
<artwork><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|E| FuType | |S|E| FuType |
+---------------+ +---------------+]]></artwork>
</figure>
The Structure of FU Header
]]></artwork></figure>
<t>The semantics of the FU header fields are as follows:</t>
<t>S: 1 bit</t>
<ul empty="true"><li>
<t>When set to 1, the S bit indicates the start of a fragmented NAL unit, i.e.
, the first byte of the FU payload is also the first byte of the payload of the
fragmented NAL unit. When the FU payload is not the start of the fragmented NAL
unit payload, the S bit MUST be set to 0.</t>
</li></ul>
<t>E: 1 bit</t>
<ul empty="true"><li>
<t>When set to 1, the E bit indicates the end of a fragmented NAL unit, i.e.,
the last byte of the payload is also the last byte of the fragmented NAL unit.
When the FU payload is not the last fragment of a fragmented NAL unit, the E bit
MUST be set to 0.</t>
</li></ul>
<t>FuType: 6 bits</t>
<ul empty="true"><li>
<t>The field FuType MUST be equal to the field Type of the fragmented NAL unit
.</t>
</li></ul>
<t>The DONL field, when present, specifies the value of the 16 least significant
bits of the decoding order number of the fragmented NAL unit.</t>
<t>If sprop-max-don-diff is greater than 0, and the S bit is equal to 1, the DON <t>The semantics of the FU header fields are as follows:</t>
L field MUST be present in the FU, and the variable DON for the fragmented NAL u <dl>
nit is derived as equal to the value of the DONL field. Otherwise (sprop-max-do <dt>S:</dt>
n-diff is equal to 0, or the S bit is equal to 0), the DONL field MUST NOT be pr <dd>
esent in the FU.</t> <t>1 bit</t>
<t>A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the Start <t>When set to 1, the S bit indicates the start of a fragmented NAL unit, i.e.,
bit and End bit MUST NOT both be set to 1 in the same FU header.</t> the first byte of the FU payload is also the first byte of the payload of the fr
agmented NAL unit. When the FU payload is not the start of the fragmented NAL u
nit payload, the S bit <bcp14>MUST</bcp14> be set to 0.</t>
</dd>
<t>The FU payload consists of fragments of the payload of the fragmented NAL uni <dt>E:</dt>
t so that if the FU payloads of consecutive FUs, starting with an FU with the S <dd>
bit equal to 1 and ending with an FU with the E bit equal to 1, are sequentially <t>1 bit</t>
concatenated, the payload of the fragmented NAL unit can be reconstructed. The
NAL unit header of the fragmented NAL unit is not included as such in the FU pa
yload, but rather the information of the NAL unit header of the fragmented NAL u
nit is conveyed in F, TID, Reserve and E fields of the FU payload headers of the
FUs and the FuType field of the FU header of the FUs. An FU payload MUST NOT be
empty.</t>
<t>If an FU is lost, the receiver SHOULD discard all following fragmentation uni <t>When set to 1, the E bit indicates the end of a fragmented NAL unit, i.e., th
ts in transmission order corresponding to the same fragmented NAL unit unless th e last byte of the payload is also the last byte of the fragmented NAL unit. Wh
e decoder in the receiver is known to gracefully handle incomplete NAL units.</t en the FU payload is not the last fragment of a fragmented NAL unit, the E bit <
> bcp14>MUST</bcp14> be set to 0.</t>
</dd>
<t>A receiver in an endpoint or a MANE MAY aggregate the first n-1 fragments of <dt>FuType:</dt>
a NAL unit to an (incomplete) NAL unit, even if fragment n of that NAL unit is n <dd>
ot received. In this case, the forbidden_zero_bit of the NAL unit MUST be set to <t>6 bits</t>
1 to indicate a syntax violation.</t>
</section> <t>The field FuType <bcp14>MUST</bcp14> be equal to the field Type
</section> of the fragmented NAL unit.</t>
<section anchor="DON"><name>Decoding Order Number</name> </dd>
</dl>
<t>For each NAL unit, the variable AbsDon is derived, representing the <t>The DONL field, when present, specifies the value of the 16 least s
ignificant bits of the decoding order number of the fragmented NAL unit.</t>
<t>If sprop-max-don-diff is greater than 0 and the S bit is equal to 1
, the DONL field <bcp14>MUST</bcp14> be present in the FU, and the variable DON
for the fragmented NAL unit is derived as equal to the value of the DONL field.
Otherwise (where sprop-max-don-diff is equal to 0, or where the S bit is equal
to 0), the DONL field <bcp14>MUST NOT</bcp14> be present in the FU.</t>
<t>A non-fragmented NAL unit <bcp14>MUST NOT</bcp14> be transmitted in
one FU; i.e., the S-bit and E-bit <bcp14>MUST NOT</bcp14> both be set to 1 in t
he same FU header.</t>
<t>The FU payload consists of fragments of the payload of the fragment
ed NAL unit so that if the FU payloads of consecutive FUs, starting with an FU w
ith the S bit equal to 1 and ending with an FU with the E bit equal to 1, are se
quentially concatenated, the payload of the fragmented NAL unit can be reconstru
cted. The NAL unit header of the fragmented NAL unit is not included as such in
the FU payload. Instead, the information of the NAL unit header of the fragment
ed NAL unit is conveyed in F, TID, Reserve, and E fields of the FU payload heade
rs of the FUs and the FuType field of the FU header of the FUs. An FU payload <b
cp14>MUST NOT</bcp14> be empty.</t>
<t>If an FU is lost, the receiver <bcp14>SHOULD</bcp14> discard all fo
llowing fragmentation units in transmission order corresponding to the same frag
mented NAL unit unless the decoder in the receiver is known to gracefully handle
incomplete NAL units.</t>
<t>A receiver in an endpoint or a MANE <bcp14>MAY</bcp14> aggregate th
e first n-1 fragments of a NAL unit to an (incomplete) NAL unit, even if fragmen
t n of that NAL unit is not received. In this case, the forbidden_zero_bit of th
e NAL unit <bcp14>MUST</bcp14> be set to 1 to indicate a syntax violation.</t>
</section>
</section>
<section anchor="DON">
<name>Decoding Order Number</name>
<t>For each NAL unit, the variable AbsDon is derived; it represents the
decoding order number that is indicative of the NAL unit decoding decoding order number that is indicative of the NAL unit decoding
order.</t> order.</t>
<t>Let NAL unit n be the n-th NAL unit in transmission order within an
<t>Let NAL unit n be the n-th NAL unit in transmission order within an
RTP stream.</t> RTP stream.</t>
<t>If sprop-max-don-diff is equal to 0, then AbsDon[n] (the value of Abs
<t>If sprop-max-don-diff is equal to 0, AbsDon[n], the value of AbsDon for NAL u Don for NAL unit n) is derived as equal to n.</t>
nit n, is derived as equal to n.</t> <t>Otherwise (where sprop-max-don-diff is greater than 0), AbsDon[n] is
derived as follows, where DON[n] is the value
<t>Otherwise (sprop-max-don-diff is greater than 0), AbsDon[n] is derived as fol
lows, where DON[n] is the value
of the variable DON for NAL unit n:</t> of the variable DON for NAL unit n:</t>
<ul spacing="normal">
<li>If n is equal to 0 (i.e., NAL unit n is the very first NAL unit
in transmission order), AbsDon[0] is set equal to DON[0].</li>
<li><t>Otherwise (where n is greater than 0), the following applies
for derivation of AbsDon[n]:</t>
<t><list style="symbols"> <artwork><![CDATA[
<t>If n is equal to 0 (i.e., NAL unit n is the very first NAL unit If DON[n] == DON[n-1],
in transmission order), AbsDon[0] is set equal to DON[0].</t> AbsDon[n] = AbsDon[n-1]
<t>Otherwise (n is greater than 0), the following applies for
derivation of AbsDon[n]:</t>
</list></t>
<figure><artwork><![CDATA[
If DON[n] == DON[n-1],
AbsDon[n] = AbsDon[n-1]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768),
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 - DON[n])
If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
]]></artwork></figure>
<t>For any two NAL units m and n, the following applies:</t>
<t><list style="symbols">
<t>AbsDon[n] greater than AbsDon[m] indicates that NAL unit n follows NAL unit
m in NAL unit decoding order.</t>
<t>When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding order of the tw
o NAL units can be in either order.</t>
<t>AbsDon[n] less than AbsDon[m] indicates that NAL unit n precedes NAL unit m
in decoding order. <vspace blankLines='1'/>
<ul empty="true"><li>
<ul empty="true"><li>
<t>Informative note: When two consecutive NAL units in the NAL
unit decoding order has different values of AbsDon, the
the absolute difference between the two AbsDon values may be
greater than or equal to 1.</t>
</li></ul>
</li></ul>
<vspace blankLines='1'/>
<ul empty="true"><li>
<ul empty="true"><li>
<t>Informative note: There are multiple reasons to allow for the absolut
e difference of the values of AbsDon for two consecutive NAL units in the NAL un
it decoding order to be greater than one. An increment by one is not required, a
s at the time of associating values of AbsDon to NAL units, it may not be known
whether all NAL units are to be delivered to the receiver. For example, a gatewa
y might not forward VCL NAL units of higher sub-layers or some SEI NAL units whe
n there is congestion in the network. In another example, the first intra-coded
picture of a pre-encoded clip is transmitted in advance to ensure that it is rea
dily available in the receiver. When transmitting the first intra-coded picture,
the originator still determines how many NAL units will be encoded before the f
irst intra-coded picture of the pre-encoded clip follows in decoding order. Thus
, the values of AbsDon for the NAL units of the first intra-coded picture of the
pre-encoded clip have to be estimated when they are transmitted, and gaps in th
e values of AbsDon may occur.</t>
</li></ul>
</li></ul>
</t>
</list></t>
</section>
</section>
<section anchor="PacketizationRules"><name>Packetization Rules</name>
<t>The following packetization rules apply:</t>
<t><list style="symbols">
<t>If sprop-max-don-diff is greater than 0, the transmission order of NAL unit
s carried in the RTP stream MAY be different from the NAL unit decoding order. O
therwise (sprop-max-don-diff equals 0), the transmission order of NAL units carr
ied in the RTP stream MUST be the same as the NAL unit decoding order.</t>
<t>A NAL unit of small size SHOULD be encapsulated in an aggregation packet to
gether with one or more other NAL units to avoid the unnecessary packetization o
verhead for small NAL units. For example, non-VCL NAL units, such as access unit
delimiters, parameter sets, or SEI NAL units, are typically small and can often
be aggregated with VCL NAL units without violating MTU size constraints.</t>
<t>Each non-VCL NAL unit SHOULD, when possible from an MTU size match viewpoin
t, be encapsulated in an aggregation packet with its associated VCL NAL unit, as
typically, a non-VCL NAL unit would be meaningless without the associated VCL N
AL unit being available.</t>
<t>For carrying precisely one NAL unit in an RTP packet, a single NAL unit pac
ket MUST be used.</t>
</list></t>
</section>
<section anchor="DepacketizationProcess"><name>De-packetization Process</name>
<t>The general concept behind de-packetization is to get the NAL units out of th
e RTP packets in an RTP stream and pass them to the decoder in the NAL unit deco
ding order.</t>
<t>The de-packetization process is implementation dependent. Therefore, the foll
owing description should be seen as an example of a suitable implementation. Oth
er schemes may also be used as long as the output for the same input is the same
as the process described below. The output is the same when the set of output N
AL units and their order are both identical. Optimizations relative to the descr
ibed algorithms are possible.</t>
<t>All normal RTP mechanisms related to buffer management apply. In particular,
duplicated or outdated RTP packets (as indicated by the RTP sequence number and
the RTP timestamp) are removed. To determine the exact time for decoding, factor
s such as a possible intentional delay to allow for proper inter-stream synchron
ization, MUST be factored in.</t>
<t>NAL units with NAL unit type values in the range of 0 to 55, inclusive, may b
e passed to the decoder. NAL-unit-like structures with NAL unit type values in t
he range of 56 to 62, inclusive, MUST NOT be passed to the decoder.</t>
<t>The receiver includes a receiver buffer, which is used to compensate for tran
smission delay jitter within individual RTP streams and to reorder NAL units fro
m transmission order to the NAL unit decoding order. In this section, the receiv
er operation is described under the assumption that there is no transmission del
ay jitter within an RTP stream. To clarify the distinction from a practical rece
iver buffer, which is also used to compensate for transmission delay jitter, the
buffer in this section will henceforth be referred to as the de-packetization b
uffer. Receivers should also prepare for transmission delay jitter; that is, eit
her reserve separate buffers for transmission delay jitter buffering and de-pack
etization buffering or use a receiver buffer for both transmission delay jitter
and de-packetization. Moreover, receivers should take transmission delay jitter
into account in the buffering operation, e.g., by additional initial buffering b
efore starting of decoding and playback.</t>
<t>The de-packetization process extracts the NAL units from the RTP packets in a
n RTP stream as follows. When an RTP packet carries a single NAL unit packet, th
e payload of the RTP packet is extracted as a single NAL unit, excluding the DON
L field, i.e., third and fourth bytes, when sprop-max-don-diff is greater than 0
. When an RTP packet carries an aggregation packet, several NAL units are extrac
ted from the payload of the RTP packet. In this case, each NAL unit corresponds
to the part of the payload of each aggregation unit that follows the NALU size f
ield, as described in <xref target="aps"/>. When an RTP packet carries a Fragmen
tation Unit (FU), all RTP packets from the first FU (with the S field equal to 1
) of the fragmented NAL unit up to the last FU (with the E field equal to 1) of
the fragmented NAL unit are collected. The NAL unit is extracted from these RTP
packets by concatenating all FU payloads in the same order as the corresponding
RTP packets and appending the NAL unit header with the fields F and TID set to e
qual the values of the fields F and TID in the payload header of the FUs, respec
tively, and with the NAL unit type set equal to the value of the field FuType in
the FU header of the FUs, as described in <xref target="funits"/>.</t>
<t>When sprop-max-don-diff is equal to 0, the de-packetization buffer size is ze
ro bytes, and the NAL units carried in the single RTP stream are directly passed
to the decoder in their transmission order, which is identical to their decodin
g order.</t>
<t>When sprop-max-don-diff is greater than 0, the process described in the remai
nder of this section applies.</t>
<t>The receiver has two buffering states: initial buffering and buffering while
playing. Initial buffering starts when the reception is initialized. After initi
al buffering, decoding and playback are started, and the buffering-while-playing
mode is used.</t>
<t>Regardless of the buffering state, the receiver stores incoming NAL units in
reception order into the de-packetization buffer. NAL units carried in RTP packe
ts are stored in the de-packetization buffer individually, and the value of AbsD
on is calculated and stored for each NAL unit.</t>
<t>Initial buffering lasts until the difference between the greatest and smalles
t AbsDon values of the NAL units in the de-packetization buffer is greater than
or equal to the value of sprop-max-don-diff.</t>
<t>After initial buffering, whenever the difference between the greatest and sma
llest AbsDon values of the NAL units in the de-packetization buffer is greater t
han or equal to the value of sprop-max-don-diff, the following operation is repe
atedly applied until this difference is smaller than sprop-max-don-diff:</t>
<t><list style="symbols">
<t>The NAL unit in the de-packetization buffer with the smallest value of AbsD
on is removed from the de-packetization buffer and passed to the decoder.</t>
</list></t>
<t>When no more NAL units are flowing into the de-packetization buffer, all NAL
units remaining in the de-packetization buffer are removed from the buffer and p
assed to the decoder in the order of increasing AbsDon values.</t>
<!-- Section 7 -->
</section>
<section anchor="PayloadFormatParameters"><name>Payload Format Parameters</name>
<t>This section specifies the optional parameters. A mapping of the parameters w
ith Session Description Protocol (SDP) <xref target="RFC8866"/> is also provided
for applications that use SDP.</t>
<t>Parameters starting with the string &quot;sprop&quot; for stream properties c
an be used by a sender to provide a receiver with the properties of the stream t
hat is or will be sent. The media sender (and not the receiver) selects whether,
and with what values, &quot;sprop&quot; parameters are being sent. This uncommo
n characteristic of the &quot;sprop&quot; parameters may not be intuitive in the
context of some signaling protocol concepts, especially with offer/answer. Ple
ase see <xref target="sdpoa"/> for guidance specific to the use of sprop paramet
ers in the Offer/Answer case.</t>
<!-- Section 7.1 -->
<section anchor="oparams"><name>Media Type Registration</name>
<t>The receiver MUST ignore any parameter unspecified in this document.</t>
<t>Type name:&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&
#160;video</t>
<t>Subtype name:&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;evc</t>
<t>Required parameters: N/A</t>
<t>Optional parameters: profile-id, level-id, toolset-id, max-recv-level-id, spr
op-sps, sprop-pps, sprop-sei, sprop-max-don-diff, sprop-depack-buf-bytes, depack
-buf-cap (refer to <xref target="optionalParameters"/> for definitions)</t>
<t>Encoding considerations:</t>
<ul empty="true"><li>
<t>This type is only defined for transfer via RTP (RFC 3550).</t>
</li></ul>
<t>Security considerations:</t>
<ul empty="true"><li>
<t>See <xref target="Security"/> of RFC XXXX.</t>
</li></ul>
<t>Interoperability considerations: N/A</t>
<t>Published specification:</t>
<ul empty="true"><li>
<t>Please refer to RFC XXXX and EVC standard <xref target="EVC"/>.</t>
</li></ul>
<t>Applications that use this media type:</t>
<ul empty="true"><li>
<t>Any application that relies on EVC-based video services over RTP</t>
</li></ul>
<t>Fragment identifier considerations: N/A</t>
<t>Additional information: N/A</t>
<t>Person &amp; email address to contact for further information:</t>
<ul empty="true"><li>
<t>Stephan Wenger (stewe@stewe.org)</t>
</li></ul>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: N/A</t>
<t>Author: See Authors&#39; Addresses section of RFC XXXX.</t>
<t>Change controller:</t>
<ul empty="true"><li>
<t>IETF &lt;avtcore@ietf.org&gt;</t>
</li></ul>
<!-- Section 7.2 -->
</section>
<section anchor="optionalParameters"><name>Optional Parameters Definition</name>
<t>profile-id, level-id, toolset-id:</t>
<ul empty="true"><li>
<t>These parameters indicate the profile, the level, and constraints of the bi
tstream carried by the RTP stream, or a specific set of the profile, the level,
and constraints the receiver supports.</t>
</li></ul>
<ul empty="true"><li>
<t>More specifications of these parameters, including how they relate to synta
x elements specified in <xref target="EVC"/> are provided below.</t>
</li></ul>
<t>profile-id:</t>
<ul empty="true"><li>
<t>When profile-id is not present, a value of 0 (i.e., the Baseline profile) M
UST be inferred.</t>
</li></ul>
<ul empty="true"><li>
<t>When used to indicate properties of a bitstream, profile-id MUST be derived
from the profile_idc in the SPS.</t>
</li></ul>
<ul empty="true"><li>
<t>EVC bitstreams transported over RTP using the technologies of this document
SHOULD refer only to SPSs that have the same value in profile_idc, unless the s
ender has a priori knowledge that a receiver can correctly decode the EVC bitstr
eam with different profile_idc values (for example in walled garden scenarios).
As exceptions to this rule, if the receiver is known to support Baseline profil
e, a bitstream could safely end with CVS referring to an SPS wherein profile_idc
indicates the Baseline Still Picture profile. A similar exception can be made
for Main profile and Main Still picture profile.</t>
</li></ul>
<t>level-id:</t>
<ul empty="true"><li>
<t>When level-id is not present, a value of 90 (corresponding to level 3, whic
h allows for approximately SD TV resolution and frame rates; for details please
see Annex A of EVC) MUST be inferred.</t>
</li></ul>
<ul empty="true"><li>
<t>When used to indicate properties of a bitstream, level-id MUST be derived f
rom the level_idc in the SPS.</t>
</li></ul>
<ul empty="true"><li>
<t>If the level-id parameter is used for capability exchange, the following ap
plies. If max-recv-level-id is not present, the default level defined by level-i
d indicates the highest level the codec wishes to support. Otherwise, max-recv-l
evel-id indicates the highest level the codec supports for receiving. For either
receiving or sending, all levels that are lower than the highest level supporte
d MUST also be supported.</t>
</li></ul>
<t>toolset-id:</t>
<ul empty="true"><li>
<t>This parameter is a base64 encoding (Section 4 of <xref target="RFC4648"></
xref>) representation of a 64 bit unsigned integer bit mask derived from the con
catenation, in network byte order, of the syntax elements toolset_idc_h and tool
set_idc_l. When used to indicate properties of a bitstream, its value MUST be d
erived from toolset_idh_h and toolset_idc_l in the sequence parameter set.</t>
</li></ul>
<t>max-recv-level-id:</t>
<ul empty="true"><li>
<t>This parameter MAY be used to indicate the highest level a receiver support
s.</t>
</li></ul>
<t>The value of max-recv-level-id MUST be in the range of 0 to 255, inclusive.P.
</t>
<t>When max-recv-level-id is not present, the value is inferred to be equal to l
evel-id.</t>
<t>max-recv-level-id MUST NOT be present when the highest level the receiver sup
ports is not higher than the default level.</t>
<t>sprop-sps:</t>
<ul empty="true"><li>
<t>This parameter MAY be used to convey sequence parameter set NAL units of th
e bitstream for out-of-band transmission of sequence parameter sets. The value
of the parameter is a comma-separated (&#39;,&#39;) list of base64 encoding (Sec
tion 4 of <xref target="RFC4648"/>) representations of the sequence parameter se
t NAL units as specified in Section 7.3.2.1 of <xref target="EVC"/>.</t>
</li></ul>
<t>sprop-pps:</t>
<ul empty="true"><li>
<t>This parameter MAY be used to convey picture parameter set NAL units of the
bitstream for out-of-band transmission of picture parameter sets. The value of
the parameter is a comma-separated (&#39;,&#39;) list of base64 encoding (Secti
on 4 of <xref target="RFC4648"/>) representations of the picture parameter set N
AL units as specified in Section 7.3.2.2 of <xref target="EVC"/>.</t>
</li></ul>
<t>sprop-sei:</t>
<ul empty="true"><li>
<t>This parameter MAY be used to convey one or more SEI messages that describe
bitstream characteristics. When present, a decoder can rely on the bitstream c
haracteristics that are described in the SEI messages for the entire duration of
the session, independently from the persistence scopes of the SEI messages as s
pecified in <xref target="VSEI"/>.</t>
</li></ul>
<ul empty="true"><li>
<t>The value of the parameter is a comma-separated (&#39;,&#39;) list of base6
4 encoding (Section 4 of <xref target="RFC4648"/>) representations of SEI NAL un
its as specified in <xref target="VSEI"/>.</t>
</li></ul>
<ul empty="true"><li>
<ul empty="true"><li>
<t>Informative note: Intentionally, no list of applicable or inapplicable SE
I messages is specified here. Conveying certain SEI messages in sprop-sei may b
e sensible in some application scenarios and meaningless in others. However, a
few examples are described below:</t>
</li></ul>
</li></ul>
<ul empty="true"><li>
<ul empty="true"><li>
<t>1) In an environment where the bitstream was created from film-based sour
ce material, and no splicing is going to occur during the lifetime of the sessio
n, the film grain characteristics SEI message is likely meaningful, and sending
it in sprop-sei rather than in the bitstream at each entry point may help with s
aving bits and allows one to configure the renderer only once, avoiding unwanted
artifacts.</t>
</li></ul>
</li></ul>
<ul empty="true"><li>
<ul empty="true"><li>
<t>2) Examples for SEI messages that would be meaningless to be conveyed in
sprop-sei include the decoded picture hash SEI message (it is close to impossibl
e that all decoded pictures have the same hashtag) or the filler payload SEI mes
sage (as there is no point in just having more bits in SDP).</t>
</li></ul>
</li></ul>
<t>sprop-max-don-diff:</t>
<ul empty="true"><li>
<t>If there is no NAL unit naluA that is followed in transmission order by any
NAL unit preceding naluA in decoding order (i.e., the transmission order of the
NAL units is the same as the decoding order), the value of this parameter MUST
be equal to 0.</t>
</li></ul>
<ul empty="true"><li>
<t>Otherwise, this parameter specifies the maximum absolute difference between
the decoding order number (i.e., AbsDon) values of any two NAL units naluA and
naluB, where naluA follows naluB in decoding order and precedes naluB in transmi
ssion order.</t>
</li></ul>
<ul empty="true"><li>
<t>The value of sprop-max-don-diff MUST be an integer in the range of 0 to 327
67, inclusive.</t>
</li></ul>
<ul empty="true"><li>
<t>When not present, the value of sprop-max-don-diff is inferred to be equal t
o 0.</t>
</li></ul>
<t>sprop-depack-buf-bytes:</t>
<ul empty="true"><li>
<t>This parameter signals the required size of the de-packetization buffer in
units of bytes. The value of the parameter MUST be greater than or equal to the
maximum buffer occupancy (in units of bytes) of the de-packetization buffer as
specified in Section 6.</t>
</li></ul>
<ul empty="true"><li>
<t>The value of sprop-depack-buf-bytes MUST be an integer in the range of 0 to
4294967295, inclusive.</t>
</li></ul>
<ul empty="true"><li>
<t>When sprop-max-don-diff is present and greater than 0, this parameter MUST
be present and the value MUST be greater than 0. When not present, the value of
sprop-depack-buf-bytes is inferred to be equal to 0.</t>
</li></ul>
<ul empty="true"><li> If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
<ul empty="true"><li> AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
<t>Informative note: The value of sprop-depack-buf-bytes indicates the requi
red size of the de-packetization buffer only. When network jitter can occur, an
appropriately sized jitter buffer has to be available as well.</t>
</li></ul>
</li></ul>
<t>depack-buf-cap:</t> If (DON[n] < DON[n-1] and DON[n-1] - DON[n] >= 32768),
AbsDon[n] = AbsDon[n-1] + 65536 - DON[n-1] + DON[n]
<ul empty="true"><li> If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
<t>This parameter signals the capabilities of a receiver implementation and in AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 - DON[n])
dicates the amount of de-packetization buffer space in units of bytes that the r
eceiver has available for reconstructing the NAL unit decoding order from NAL un
its carried in the RTP stream. A receiver is able to handle any RTP stream for
which the value of the sprop-depack-buf-bytes parameter is smaller than or equal
to this parameter.</t>
</li></ul>
<ul empty="true"><li> If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
<t>When not present, the value of depack-buf-cap is inferred to be equal to 42 AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
94967295. The value of depack-buf-cap MUST be an integer in the range of 1 to 4 ]]></artwork></li>
294967295, inclusive.</t> </ul>
</li></ul> <t>For any two NAL units (m and n), the following applies:</t>
<ul spacing="normal">
<li>When AbsDon[n] is greater than AbsDon[m], the NAL unit n
follows NAL unit m in NAL unit decoding order.</li>
<li>When AbsDon[n] is equal to AbsDon[m], the NAL unit decoding
order of the two NAL units can be in either order.</li>
<li>When AbsDon[n] is less than AbsDon[m], the NAL unit n precedes
NAL unit m in decoding order.</li>
</ul>
<ul empty="true"><li> <aside><t>Informative note: When two consecutive NAL units in
<ul empty="true"><li> the NAL unit decoding order has different values of AbsDon, the
<t>Informative note: depack-buf-cap indicates the maximum possible size of t absolute difference between the two AbsDon values may be greater than
he de-packetization buffer of the receiver only, without allowing for network ji or equal to 1.</t></aside>
tter.</t>
</li></ul>
</li></ul>
<!-- Section 7.3 --> <aside><t>Informative note: There are multiple reasons to allow
the absolute difference of the values of AbsDon for two
consecutive NAL units in the NAL unit decoding order to be greater
than one. An increment by one is not required as at the time of
associating values of AbsDon to NAL units, it may not be known whether
all NAL units are to be delivered to the receiver. For example, a
gateway might not forward VCL NAL units of higher sub-layers or some
SEI NAL units when there is congestion in the network. In another
example, the first intra-coded picture of a pre-encoded clip is
transmitted in advance to ensure that it is readily available in the
receiver. When transmitting the first intra-coded picture, the
originator still determines how many NAL units will be encoded before
the first intra-coded picture of the pre-encoded clip follows in
decoding order. Thus, the values of AbsDon for the NAL units of the
first intra-coded picture of the pre-encoded clip have to be estimated
when they are transmitted and gaps in the values of AbsDon may
occur.</t></aside>
</section>
</section>
<section anchor="PacketizationRules">
<name>Packetization Rules</name>
<t>The following packetization rules apply:</t>
<ul spacing="normal">
<li>If sprop-max-don-diff is greater than 0, the transmission order of
NAL units carried in the RTP stream <bcp14>MAY</bcp14> be different
from the NAL unit decoding order. Otherwise (where sprop-max-don-diff
equals 0), the transmission order of NAL units carried in the RTP
stream <bcp14>MUST</bcp14> be the same as the NAL unit decoding
order.</li>
<li>A NAL unit of small size <bcp14>SHOULD</bcp14> be encapsulated in
an AP together with one or more other NAL units to avoid the
unnecessary packetization overhead for small NAL units. For example,
non-VCL NAL units, such as access unit delimiters, parameter sets, or
SEI NAL units, are typically small and can often be aggregated with
VCL NAL units without violating MTU size constraints.</li>
<li>Each non-VCL NAL unit <bcp14>SHOULD</bcp14>, when possible from an
MTU size match viewpoint, be encapsulated in an AP with its associated
VCL NAL unit as, typically, a non-VCL NAL unit would be meaningless
without the associated VCL NAL unit being available.</li>
<li>A single NAL unit packet <bcp14>MUST</bcp14> be used for carrying
precisely one NAL unit in an RTP packet.</li>
</ul>
</section>
<section anchor="DepacketizationProcess">
<name>De-packetization Process</name>
<t>The general concept behind de-packetization is to get the NAL units out
of the RTP packets in an RTP stream and pass them to the decoder in the NAL uni
t decoding order.</t>
<t>The de-packetization process is implementation dependent. Therefore, th
e following description should be seen as an example of a suitable implementatio
n. Other schemes may also be used as long as the output for the same input is th
e same as the process described below. The output is the same when the set of ou
tput NAL units and their order are both identical. Optimizations relative to the
described algorithms are possible.</t>
<t>All normal RTP mechanisms related to buffer management apply. In partic
ular, duplicated or outdated RTP packets (as indicated by the RTP sequence numbe
r and the RTP timestamp) are removed. To determine the exact time for decoding,
factors such as a possible intentional delay to allow for proper inter-stream sy
nchronization must be considered.</t>
<t>NAL units with NAL unit type values in the range of 0 to 55, inclusive,
may be passed to the decoder. NAL-unit-like structures with NAL unit type value
s in the range of 56 to 62, inclusive, <bcp14>MUST NOT</bcp14> be passed to the
decoder.</t>
<t>The receiver includes a receiver buffer, which is used to compensate fo
r transmission delay jitter within individual RTP streams and to reorder NAL uni
ts from transmission order to the NAL unit decoding order. In this section, the
receiver operation is described under the assumption that there is no transmissi
on delay jitter within an RTP stream. To clarify the distinction from a practica
l receiver buffer, which is also used to compensate for transmission delay jitte
r, the buffer in this section will henceforth be referred to as the "de-packetiz
ation" buffer. Receivers should also prepare for transmission delay jitter; that
is, either reserve separate buffers for transmission delay jitter buffering and
de-packetization buffering, or use a receiver buffer for both transmission dela
y jitter and de-packetization. Moreover, receivers should take transmission dela
y jitter into account in the buffering operation, e.g., by additional initial bu
ffering before starting decoding and playback.</t>
<t>The de-packetization process extracts the NAL units from the RTP packet
s in an RTP stream as follows. When an RTP packet carries a single NAL unit pack
et, the payload of the RTP packet is extracted as a single NAL unit, excluding t
he DONL field, i.e., third and fourth bytes, when sprop-max-don-diff is greater
than 0. When an RTP packet carries an AP, several NAL units are extracted from t
he payload of the RTP packet. In this case, each NAL unit corresponds to the par
t of the payload of each aggregation unit that follows the NALU size field, as d
escribed in <xref target="aps"/>. When an RTP packet carries a Fragmentation Uni
t (FU), all RTP packets from the first FU (with the S field equal to 1) of the f
ragmented NAL unit up to the last FU (with the E field equal to 1) of the fragme
nted NAL unit are collected. The NAL unit is extracted from these RTP packets by
concatenating all FU payloads in the same order as the corresponding RTP packet
s and appending the NAL unit header with the fields F and TID set to equal the v
alues of the fields F and TID in the payload header of the FUs, respectively, an
d with the NAL unit type set equal to the value of the field FuType in the FU he
ader of the FUs, as described in <xref target="funits"/>.</t>
<t>When sprop-max-don-diff is equal to 0, the de-packetization buffer size
is zero bytes, and the NAL units carried in the single RTP stream are directly
passed to the decoder in their transmission order, which is identical to their d
ecoding order.</t>
<t>When sprop-max-don-diff is greater than 0, the process described in the
remainder of this section applies.</t>
<t>The receiver has two buffering states: initial buffering and buffering
while playing. Initial buffering starts when the reception is initialized. After
initial buffering, decoding and playback are started, and the buffering-while-p
laying mode is used.</t>
<t>Regardless of the buffering state, the receiver stores incoming NAL uni
ts in reception order into the de-packetization buffer. NAL units carried in RTP
packets are stored in the de-packetization buffer individually, and the value o
f AbsDon is calculated and stored for each NAL unit.</t>
<t>Initial buffering lasts until the difference between the greatest and s
mallest AbsDon values of the NAL units in the de-packetization buffer is greater
than or equal to the value of sprop-max-don-diff.</t>
<t>After initial buffering, whenever the difference between the greatest a
nd smallest AbsDon values of the NAL units in the de-packetization buffer is gre
ater than or equal to the value of sprop-max-don-diff, the following operation i
s repeatedly applied until this difference is smaller than sprop-max-don-diff:</
t>
<t indent="3">The NAL unit in the de-packetization buffer with the smallest valu
e of AbsDon is removed from the de-packetization buffer and passed to the decode
r.</t>
<t>When no more NAL units are flowing into the de-packetization buffer, al
l NAL units remaining in the de-packetization buffer are removed from the buffer
and passed to the decoder in the order of increasing AbsDon values.</t>
</section> </section>
<section anchor="sdp-parameters"><name>SDP Parameters</name> <section anchor="PayloadFormatParameters">
<name>Payload Format Parameters</name>
<t>The receiver MUST ignore any parameter unspecified in this document.</t> <t>This section specifies the optional parameters. A mapping of the parame
ters with the Session Description Protocol (SDP) <xref target="RFC8866"/> is als
<!-- Section 7.3.1 --> o provided for applications that use SDP.</t>
<t>Parameters starting with the string "sprop" for stream properties can b
<section anchor="mapping-of-payload-type-parameters-to-sdp"><name>Mapping of Pay e used by a sender to provide a receiver with the properties of the stream that
load Type Parameters to SDP</name> is or will be sent. The media sender (and not the receiver) selects whether, and
with what values, "sprop" parameters are being sent. This uncommon characterist
<t>The media type video/evc string is mapped to fields in the Session Descriptio ic of the "sprop" parameters may not be intuitive in the context of some signali
n Protocol (SDP) <xref target="RFC8866"/> as follows:</t> ng protocol concepts, especially with Offer/Answer. Please see <xref target="sd
poa"/> for guidance specific to the use of sprop parameters in the Offer/Answer
<t><list style="symbols"> case.</t>
<t>The media name in the &quot;m=&quot; line of SDP MUST be video.</t>
<t>The encoding name in the &quot;a=rtpmap&quot; line of SDP MUST be evc (the
media subtype).</t>
<t>The clock rate in the &quot;a=rtpmap&quot; line MUST be 90000.</t>
<t>The OPTIONAL parameters profile-id, level-id, toolset-id, max-recv-level-id
, sprop-max-don-diff, sprop-depack-buf-bytes, and depack-buf-cap, when present,
MUST be included in the &quot;a=fmtp&quot; line of SDP. The fmtp line is express
ed as a media type string, in the form of a semicolon-separated list of paramete
r=value pairs.</t>
<t>The OPTIONAL parameters sprop-sps, sprop-pps, and sprop-sei, when present,
MUST be included in the &quot;a=fmtp&quot; line of SDP or conveyed using the &qu
ot;fmtp&quot; source attribute as specified in Section 6.3 of <xref target="RFC5
576"/>. For a particular media format (i.e., RTP payload type), sprop-sps, sprop
-pps, or sprop-sei MUST NOT be both included in the &quot;a=fmtp&quot; line of S
DP and conveyed using the &quot;fmtp&quot; source attribute. When included in th
e &quot;a=fmtp&quot; line of SDP, those parameters are expressed as a media type
string, in the form of a semicolon-separated list of parameter=value pairs. Whe
n conveyed in the &quot;a=fmtp&quot; line of SDP for a particular payload type,
the parameters sprop-sps, sprop-pps, and sprop-sei MUST be applied to each SSRC
with the payload type. When conveyed using the &quot;fmtp&quot; source attribute
, these parameters are only associated with the given source and payload type as
parts of the &quot;fmtp&quot; source attribute.</t>
</list></t>
<ul empty="true"><li>
<t>Informative note: Conveyance of sprop-sps and sprop-pps using the &quot;fmt
p&quot; source attribute allows for out-of-band transport of parameter sets in t
opologies like Topo-Video-switch-MCU, as specified in <xref target="RFC7667"/>.<
/t>
</li></ul>
<t>A general usage of media representation in SDP is as follows:</t>
<figure><artwork><![CDATA[
m=video 49170 RTP/AVP 98
a=rtpmap:98 evc/90000
a=fmtp:98 profile-id=1;
sprop-sps=<sequence parameter set data>;
sprop-pps=<picture parameter set data>;
]]></artwork></figure>
<t>A SIP offer/answer exchange wherein both parties are expected to both send an <section anchor="oparams">
d receive could look like the following. Only the media codec-specific parts of <name>Media Type Registration</name>
the SDP are shown.</t> <t>The receiver <bcp14>MUST</bcp14> ignore any parameter unspecified
in this document.</t>
<dl spacing="normal" newline="false">
<dt>Type name:</dt><dd>video</dd>
<dt>Subtype name:</dt><dd>evc</dd>
<dt>Required parameters:</dt><dd>N/A</dd>
<dt>Optional parameters:</dt><dd>profile-id, level-id, toolset-id,
max-recv-level-id, sprop-sps, sprop-pps, sprop-sei,
sprop-max-don-diff, sprop-depack-buf-bytes, depack-buf-cap (refer to
<xref target="optionalParameters"/> for definitions)</dd>
<dt>Encoding considerations:</dt> <dd>This type is only defined for
transfer via RTP <xref target="RFC3550" format="default"/>.</dd>
<dt>Security considerations:</dt> <dd>See <xref target="Security"/>
of RFC 9584.</dd>
<dt>Interoperability considerations:</dt><dd>N/A</dd>
<dt>Published specification:</dt> <dd>Please refer to RFC 9584 and
EVC standard <xref target="EVC"/>.</dd>
<dt>Applications that use this media type:</dt> <dd>Any application
that relies on EVC-based video services over RTP</dd>
<dt>Fragment identifier considerations:</dt><dd>N/A</dd>
<dt>Additional information:</dt><dd>N/A</dd>
<dt>Person &amp; email address to contact for further
information:</dt> <dd><br/>Stephan Wenger (stewe@stewe.org)</dd>
<dt>Intended usage:</dt><dd>COMMON</dd>
<dt>Restrictions on usage:</dt><dd>N/A</dd>
<dt>Author:</dt><dd>See Authors' Addresses section of RFC 9584.</dd>
<dt>Change controller:</dt> <dd>IETF &lt;avtcore@ietf.org&gt;</dd>
</dl>
</section>
<section anchor="optionalParameters">
<name>Optional Parameters Definition</name>
<dl newline="true">
<dt>profile-id, level-id, toolset-id:</dt>
<dd><t>These parameters indicate the profile, the level, and
constraints of the bitstream carried by the RTP stream or a
specific set of the profile, the level, and constraints the receiver
supports.</t>
<t>More specifications of these parameters, including how they
relate to syntax elements specified in <xref target="EVC"/> are
provided below.</t>
</dd>
<figure><artwork><![CDATA[ <dt>profile-id:</dt>
Offerer->Answerer: <dd><t>When profile-id is not present, a value of 0 (i.e., the
m=video 49170 RTP/AVP 98 Baseline profile) <bcp14>MUST</bcp14> be inferred.</t>
a=rtpmap:98 evc/90000 <t>When used to indicate properties of a bitstream, profile-id
a=fmtp:98 profile-id=1; level_id=90; <bcp14>MUST</bcp14> be derived from the profile_idc in the SPS.</t>
<t>EVC bitstreams transported over RTP using the technologies of
this document <bcp14>SHOULD</bcp14> refer only to SPSs that have
the same value in profile_idc, unless the sender has a priori
knowledge that a receiver can correctly decode the EVC bitstream
with different profile_idc values (for example, in walled garden
scenarios). As exceptions to this rule, if the receiver is known
to support a Baseline profile, a bitstream could safely end with CVS
referring to an SPS wherein profile_idc indicates the Baseline
Still picture profile. A similar exception can be made for Main
profile and Main Still picture profile.</t>
</dd>
]]></artwork></figure> <dt>level-id:</dt>
<dd><t>When level-id is not present, a value of 90 (corresponding
to level 3, which allows for approximately standard-definition
television (SD TV) resolution and frame rates; see Annex A of <xref
target="EVC"/>) <bcp14>MUST</bcp14> be inferred.</t>
<t>When used to indicate properties of a bitstream, level-id
<bcp14>MUST</bcp14> be derived from the level_idc in the SPS.</t>
<t>If the level-id parameter is used for capability exchange, the
following applies. If max-recv-level-id is not present, the default
level defined by level-id indicates the highest level the codec
wishes to support. Otherwise, max-recv-level-id indicates the
highest level the codec supports for receiving. For either
receiving or sending, all levels that are lower than the highest
level supported <bcp14>MUST</bcp14> also be supported.</t>
</dd>
<ul empty="true"><li> <dt>toolset-id:</dt>
<t>The above represents an offer for symmetric video communication using <xref <dd>This parameter is a base64-encoding representation (<xref
target="EVC"/> and its payload specification at the main profile and level 3.0. target="RFC4648" section="4" sectionFormat="of"/>) of a 64-bit
Informally speaking, this offer tells the receiver of the offer that the sende unsigned integer bit mask derived from the concatenation, in network
r is willing to receive up to xKpxx resolution at the maximum bitrates specified byte order, of the syntax elements toolset_idc_h and toolset_idc_l.
in <xref target="EVC"/>. At the same time, if this offer were accepted &quot;as When used to indicate properties of a bitstream, its value
is&quot;, the offer can expect that the answerer would be able to receive and p <bcp14>MUST</bcp14> be derived from toolset_idh_h and toolset_idc_l in
roperly decode EVC media up to and including level 3.0.</t> the sequence parameter set.</dd>
</li></ul>
<figure><artwork><![CDATA[ <dt>max-recv-level-id:</dt>
Answerer->Offerer: <dd><t>This parameter <bcp14>MAY</bcp14> be used to indicate the
m=video 49170 RTP/AVP 98 highest level a receiver supports.</t>
a=rtpmap:98 evc/90000 <t>The value of max-recv-level-id <bcp14>MUST</bcp14> be in the range
a=fmtp:98 profile-id=1; level_id=60 of 0 to 255, inclusive.</t>
]]></artwork></figure> <t>When max-recv-level-id is not present, the value is inferred to be
equal to level-id.</t>
<t>max-recv-level-id <bcp14>MUST NOT</bcp14> be present when the
highest level the receiver supports is not higher than the default
level.</t></dd>
<ul empty="true"><li> <dt>sprop-sps:</dt>
<ul empty="true"><li> <dd><t>This parameter <bcp14>MAY</bcp14> be used to convey sequence
<t>Informative note: level_id shall be set equal to a value of 30 times the parameter set NAL units of the bitstream for out-of-band transmission
level number specified in Table A.1 of EVC.</t> of sequence parameter sets. The value of the parameter is a
</li></ul> comma-separated (',') list of base64-encoding representations (<xref
</li></ul> target="RFC4648" section="4" sectionFormat="of"/>) of the sequence
parameter set NAL units as specified in Section 7.3.2.1 of <xref
target="EVC"/>.</t>
</dd>
<t>With this answer to the offer above, the system receiving the offer advises t <dt>sprop-pps:</dt>
he offerer that it is incapable of handing evc at level 3.0 but is capable of de <dd><t>This parameter <bcp14>MAY</bcp14> be used to convey picture
coding level 2. As EVC video codecs must support decoding at all levels below th parameter set NAL units of the bitstream for out-of-band transmission
e maximum level they implement, the resulting user experience would likely be th of picture parameter sets. The value of the parameter is a
at both systems send video at level 2. However, nothing prevents an encoder from comma-separated (',') list of base64-encoding representations (<xref
further downgrading its sending to, for example, level 1 if it were short of cy target="RFC4648" section="4" sectionFormat="of"/>) of the picture
cles or bandwidth or for other reasons.</t> parameter set NAL units as specified in Section 7.3.2.2 of <xref
target="EVC"/>.</t></dd>
<!-- Section 7.3.2 --> <dt>sprop-sei:</dt>
<dd><t>This parameter <bcp14>MAY</bcp14> be used to convey one or more
SEI messages that describe bitstream characteristics. When present, a
decoder can rely on the bitstream characteristics that are described
in the SEI messages for the entire duration of the session,
independently from the persistence scopes of the SEI messages as
specified in <xref target="VSEI"/>.</t>
<t>The value of the parameter is a comma-separated (',') list of
base64-encoding representations (<xref target="RFC4648" section="4"
sectionFormat="of"/>) of SEI NAL units as specified in
<xref target="VSEI"/>.</t>
<aside><t>Informative note: Intentionally, no list of
applicable or inapplicable SEI messages is specified here.
Conveying certain SEI messages in sprop-sei may be sensible in
some application scenarios and meaningless in others. However,
a couple of examples are described below.</t>
<ol type="1">
<li>In an environment where the bitstream was created from
film-based source material, and no splicing is going to occur
during the lifetime of the session, the film grain
characteristics SEI message is likely meaningful; and sending
it in sprop-sei rather than in the bitstream at each entry
point may help with saving bits and allow one to configure
the renderer only once, avoiding unwanted artifacts.</li>
<li>Examples for SEI messages that would be meaningless to be
conveyed in sprop-sei include the decoded picture hash SEI
message (it is close to impossible that all decoded pictures
have the same hashtag) or the filler payload SEI message (as
there is no point in just having more bits in SDP).</li>
</ol></aside>
</dd>
</section> <dt>sprop-max-don-diff:</dt>
<section anchor="sdpoa"><name>Usage with SDP Offer/Answer Model</name>
<t>This section describes the negotiation of unicast messages using the offer/an swer model described in <xref target="RFC3264"/> and its updates.</t> <dd><t>If there is no NAL unit naluA that is followed in transmission order by any NAL unit preceding naluA in decoding order (i.e., the transmission order of the NAL units is the same as the decoding order), the value of this pa rameter <bcp14>MUST</bcp14> be equal to 0.</t>
<t>This section applies to all profiles defined in <xref target="EVC"/>, specifi cally to Baseline, Main, and the associated still image profiles.</t> <t>Otherwise, this parameter specifies the maximum absolute differen ce between the decoding order number (i.e., AbsDon) values of any two NAL units naluA and naluB, where naluA follows naluB in decoding order and precedes naluB in transmission order.</t>
<t>The following limitations and rules pertaining to the media configuration app ly:</t> <t>The value of sprop-max-don-diff <bcp14>MUST</bcp14> be an integer in the range of 0 to 32767, inclusive.</t>
<t>The parameters identifying a media format configuration for EVC are profile-i <t>When not present, the value of sprop-max-don-diff is inferred to
d and level-id. Profile_id MUST be used symmetrically.</t> be equal to 0.</t>
</dd>
<t>The answerer MUST structure its answer according to one of the following thre <dt>sprop-depack-buf-bytes:</dt>
e options:</t> <dd>
<ul empty="true"><li> <t>This parameter signals the required size of the de-packetization
<t><list style="symbols"> buffer in units of bytes. The value of the parameter <bcp14>MUST</bcp14> be gre
<t>maintain all configuration parameters with the values remaining the same ater than or equal to the maximum buffer occupancy (in units of bytes) of the de
as in the offer for the media format (payload type), with the exception that the -packetization buffer as specified in <xref target="DepacketizationProcess" form
value of level-id is changeable as long as the highest level indicated by the a at="default"/>.</t>
nswer is not higher than that indicated by the offer; or</t>
</list></t>
</li></ul>
<ul empty="true"><li> <t>The value of sprop-depack-buf-bytes <bcp14>MUST</bcp14> be an int
<t><list style="symbols"> eger in the range of 0 to 4294967295, inclusive.</t>
<t>remove the media format (payload type) completely (when one or more of th
e parameter values are not supported).</t>
</list></t>
</li></ul>
<t>Informative note: The above requirement for symmetric use does not apply for level-id and does not apply for the other bitstream or RTP stream properties and capability parameters, as described in <xref target="formatconfig"/> (Payload f ormat config) below.</t> <t>When sprop-max-don-diff is present and greater than 0, this param eter <bcp14>MUST</bcp14> be present and the value <bcp14>MUST</bcp14> be greater than 0. When not present, the value of sprop-depack-buf-bytes is inferred to b e equal to 0.</t>
<t>To simplify handling and matching of these configurations, the same RTP paylo <aside><t>Informative note: The value of
ad type number used in the offer SHOULD also be used in the answer, as specified sprop-depack-buf-bytes indicates the required size of the
in <xref target="RFC3264"></xref>.</t> de-packetization buffer only. When network jitter can occur, an
appropriately sized jitter buffer has to be available as
well.</t></aside>
</dd>
<t>The answer MUST NOT contain a payload type number used in the offer for the m <dt>depack-buf-cap:</dt>
edia subtype unless the configuration is the same as in the offer or the configu <dd>
ration in the answer only differs from that in the offer with a different value <t>This parameter signals the capabilities of a receiver
of level-id.</t> implementation and indicates the amount of de-packetization buffer
space in units of bytes that the receiver has available for
reconstructing the NAL unit decoding order from NAL units carried in
the RTP stream. A receiver is able to handle any RTP stream for
which the value of the sprop-depack-buf-bytes parameter is smaller
than or equal to this parameter.</t>
<t>When not present, the value of depack-buf-cap is inferred to be
equal to 4294967295. The value of depack-buf-cap
<bcp14>MUST</bcp14> be an integer in the range of 1 to 4294967295,
inclusive.</t>
<!-- Section 7.3.2.x --> <aside><t>Informative note: The value of depack-buf-cap indicates
the maximum possible size of the de-packetization buffer of the
receiver only, without allowing for network jitter. When network
jitter occurs, an appropriately sized jitter buffer has to be
available as well. </t></aside>
</dd>
</dl>
<section anchor="formatconfig"><name>Payload Format Configuration</name> </section>
<t>The following limitations and rules pertain to the configuration of the paylo <section anchor="sdp-parameters">
ad format buffer management.</t> <name>SDP Parameters</name>
<t>The receiver <bcp14>MUST</bcp14> ignore any parameter unspecified in
this document.</t>
<t>The parameters sprop-max-don-diff and sprop-depack-buf-bytes describe the pro <section anchor="mapping-of-payload-type-parameters-to-sdp">
perties of an RTP stream that the offerer or the answerer is sending for the med <name>Mapping of Payload Type Parameters to SDP</name>
ia format configuration. This differs from the normal usage of the offer/answer <t>The media type video/evc string is mapped to fields in the Session
parameters; normally, such parameters declare the properties of the bitstream or Description Protocol (SDP) <xref target="RFC8866"/> as follows:</t>
RTP stream that the offerer or the answerer is able to receive. When dealing wi <ul spacing="normal">
th EVC, the offerer assumes that the answerer will be able to receive media enco <li>The media name in the "m=" line of SDP <bcp14>MUST</bcp14>
ded using the configuration being offered.</t> be video.</li>
<li>The encoding name in the "a=rtpmap" line of SDP
<bcp14>MUST</bcp14> be evc (the media subtype).</li>
<li>The clock rate in the "a=rtpmap" line <bcp14>MUST</bcp14> be
90000.</li>
<t>Informative note: The above parameters apply for any RTP stream, when present <li>The <bcp14>OPTIONAL</bcp14> parameters profile-id, level-id,
, sent by a declaring entity with the same configuration. In other words, the ap toolset-id, max-recv-level-id, sprop-max-don-diff,
plicability of the above parameters to RTP streams depends on the source endpoin sprop-depack-buf-bytes, and depack-buf-cap, when present,
t. Rather than being bound to the payload type, the values may have to be applie <bcp14>MUST</bcp14> be included in the "a=fmtp" line of SDP. The
d to another payload type when being sent, as they apply for the configuration.< "a=fmtp" line is expressed as a media type string, in the form of a
/t> semicolon-separated list of parameter=value pairs.</li>
<li>The <bcp14>OPTIONAL</bcp14> parameters sprop-sps, sprop-pps,
and sprop-sei, when present, <bcp14>MUST</bcp14> be included in
the "a=fmtp" line of SDP or conveyed using the "fmtp" source
attribute as specified in <xref target="RFC5576"
sectionFormat="of" section="6.3"/>. For a particular media format
(i.e., RTP payload type), sprop-sps, sprop-pps, or sprop-sei
<bcp14>MUST NOT</bcp14> be both included in the "a=fmtp" line of
SDP and conveyed using the "fmtp" source attribute. When included
in the "a=fmtp" line of SDP, those parameters are expressed as a
media type string, in the form of a semicolon-separated list
of parameter=value pairs. When conveyed in the "a=fmtp" line of
SDP for a particular payload type, the parameters sprop-sps,
sprop-pps, and sprop-sei <bcp14>MUST</bcp14> be applied to each
SSRC with the payload type. When conveyed using the "fmtp" source
attribute, these parameters are only associated with the given
source and payload type as parts of the "fmtp" source
attribute.</li>
</ul>
<aside><t>Informative note: Conveyance of sprop-sps and sprop-pps
using the "fmtp" source attribute allows for out-of-band transport
of parameter sets in topologies like Topo-Video-switch-MCU, as
specified in <xref target="RFC7667"/>.</t></aside>
<t>When an offerer offers an interleaved stream, indicated by the presence of sp rop-max-don-diff with a value larger than zero, the offerer MUST include the siz e of the de-packetization buffer sprop-depack-buf-bytes.</t> <t>A general usage of media representation in SDP is as follows:</t>
<t>To enable the offerer and answerer to inform each other about their capabilit <artwork><![CDATA[
ies for de-packetization buffering in receiving RTP streams, both parties are RE m=video 49170 RTP/AVP 98
COMMENDED to include depack-buf-cap.</t> a=rtpmap:98 evc/90000
a=fmtp:98 profile-id=1;
sprop-sps=<sequence parameter set data>;
sprop-pps=<picture parameter set data>;
]]></artwork>
<t>The parameters sprop-sps, or sprop-pps, when present (included in the &quot;a <t>A SIP Offer/Answer exchange wherein both parties are expected to
=fmtp&quot; line of SDP or conveyed using the &quot;fmtp&quot; source attribute, both send and receive could look like the following. Only the media
as specified in Section 6.3 of <xref target="RFC5576"></xref>), are used for ou codec-specific parts of the SDP are shown.</t>
t-of-band transport of the parameter sets (SPS or PPS, respectively).
The answerer MAY use either out-of-band or in-band transport of parameter sets f
or the bitstream it is sending, regardless of whether out-of-band parameter sets
transport has been used in the offerer-to-answerer direction. Parameter sets in
cluded in an answer are independent of those parameter sets included in the offe
r, as they are used for decoding two different bitstreams; one from the answerer
to the offerer and the other in the opposite direction. In case some RTP packet
s are sent before the SDP offer/answer settles down, in-band parameter sets MUST
be used for those RTP stream parts sent before the SDP offer/answer.</t>
<t>The following rules apply to transport of parameter sets in the offerer-to-an <artwork><![CDATA[
swerer direction.</t> Offerer->Answerer:
m=video 49170 RTP/AVP 98
a=rtpmap:98 evc/90000
a=fmtp:98 profile-id=1; level_id=90;
]]></artwork>
<t>An offer MAY include sprop-sps, and/or sprop-pps. If none of these parameters <t>The above represents an offer for symmetric video communication
are present in the offer, then only in-band transport of parameter sets is used using <xref target="EVC"/> and its payload specification at the main
.</t> profile and level 3. Informally speaking, this offer tells the
receiver of the offer that the sender is willing to receive up to
xKpxx resolution at the maximum bitrates specified in <xref
target="EVC"/>. At the same time, if this offer were accepted "as
is", the offer can expect that the Answerer would be able to receive
and properly decode EVC media up to and including level 3.</t>
<t>If the level to use in the offerer-to-answerer direction is equal to the defa <artwork><![CDATA[
ult level in the offer, the answerer MUST be prepared to use the parameter sets Answerer->Offerer:
included in sprop-sps, and sprop-pps (either included in the &quot;a=fmtp&quot; m=video 49170 RTP/AVP 98
line of SDP or conveyed using the &quot;fmtp&quot; source attribute) for decodin a=rtpmap:98 evc/90000
g the incoming bitstream, e.g., by passing these parameter set NAL units to the a=fmtp:98 profile-id=1; level_id=60
video decoder before passing any NAL units carried in the RTP streams. Otherwise ]]></artwork>
, the answerer MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included
in the &quot;a=fmtp&quot; line of SDP or conveyed using the &quot;fmtp&quot; sou
rce attribute) and the offerer MUST transmit parameter sets in-band.</t>
<t>The following rules apply to transport of parameter sets in the answerer-to-o <aside><t>Informative note: level_id shall be set equal to a
fferer direction.</t> value of 30 times the level number specified in Table A.1 of
<xref target="EVC"/>.</t></aside>
<t>An answer MAY include sprop-sps, and/or sprop-pps. If none of these parameter <t>With this answer to the offer above, the system receiving the
s are present in the answer, then only in-band transport of parameter sets is us offer advises the Offerer that it is incapable of handling evc at
ed.</t> level 3 but is capable of decoding level 2. As EVC video codecs
must support decoding at all levels below the maximum level they
implement, the resulting user experience would likely be that both
systems send video at level 2. However, nothing prevents an encoder
from further downgrading its sending to, for example, level 1 if it
were short of cycles or bandwidth or for other reasons.</t>
</section>
<section anchor="sdpoa">
<name>Usage with SDP Offer/Answer Model</name>
<t>This section describes the negotiation of unicast messages using th
e Offer/Answer model described in <xref target="RFC3264"/> and its updates.</t>
<t>This section applies to all profiles defined in <xref target="EVC"/
>, specifically to Baseline, Main, and the associated still image profiles.</t>
<t>The following limitations and rules pertaining to the media configu
ration apply:</t>
<t>The parameters identifying a media format configuration for EVC are
profile-id and level-id. Profile_id <bcp14>MUST</bcp14> be used symmetrically.<
/t>
<t>The offerer MUST be prepared to use the parameter sets included in sprop-sps <t>The Answerer <bcp14>MUST</bcp14> structure its answer according to
and sprop-pps (either included in the &quot;a=fmtp&quot; line of SDP or conveyed one of the following two options:</t>
using the &quot;fmtp&quot; source attribute) for decoding the incoming bitstrea <ul spacing="normal">
m, e.g., by passing these parameter set NAL units to the video decoder before pa <li>maintain all configuration parameters with the values
ssing any NAL units carried in the RTP streams.</t> remaining the same as in the offer for the media format (payload
type), with the exception that the value of level-id is changeable
as long as the highest level indicated by the answer is not higher
than that indicated by the offer; or</li>
<li>remove the media format (payload type) completely (when one or
more of the parameter values are not supported).</li>
</ul>
<t>When sprop-sps and/or sprop-pps are conveyed using the &quot;fmtp&quot; sourc <aside><t>Informative note: The above requirement for symmetric use do
e attribute, as specified in Section 6.3 of <xref target="RFC5576"></xref>, the es not apply for level-id and does not apply for the other bitstream or RTP stre
receiver of the parameters MUST store the parameter sets included in sprop-sps a am properties and capability parameters, as described in <xref target="formatcon
nd/or sprop-pps and associate them with the source given as part of the &quot;fm fig"/> ("<xref target="formatconfig" format="title"/>").</t></aside>
tp&quot; source attribute. Parameter sets associated with one source (given as p <t>To simplify handling and matching of these configurations, the same
art of the &quot;fmtp&quot; source attribute) MUST only be used to decode NAL un RTP payload type number used in the offer <bcp14>SHOULD</bcp14> also be used in
its conveyed in RTP packets from the same source (given as part of the &quot;fmt the answer, as specified in <xref target="RFC3264"/>.</t>
p&quot; source attribute). When this mechanism is in use, SSRC collision detecti <t>The answer <bcp14>MUST NOT</bcp14> contain a payload type number us
on and resolution MUST be performed as specified in <xref target="RFC5576"></xre ed in the offer for the media subtype unless the configuration is the same as in
f>.</t> the offer or the configuration in the answer only differs from that in the offe
r with a different value of level-id.</t>
<t><xref target="params-interpretation"/> lists the interpretation of all the pa <section anchor="formatconfig">
rameters that MAY be used for the various combinations of offer, answer, and dir <name>Payload Format Configuration</name>
ection attributes.</t> <t>The following limitations and rules pertain to the configuration
of the payload format buffer management.</t>
<ul spacing="normal">
<li><t>The parameters sprop-max-don-diff and sprop-depack-buf-byte
s describe the properties of an RTP stream that the Offerer or the Answerer is s
ending for the media format configuration. This differs from the normal usage of
the Offer/Answer parameters; normally, such parameters declare the properties o
f the bitstream or RTP stream that the Offerer or the Answerer is able to receiv
e. When dealing with EVC, the Offerer assumes that the Answerer will be able to
receive media encoded using the configuration being offered.</t></li>
</ul>
<aside><t>Informative note: The above parameters apply for any RTP s
tream, when present, sent by a declaring entity with the same configuration. In
other words, the applicability of the above parameters to RTP streams depends on
the source endpoint. Rather than being bound to the payload type, the values ma
y have to be applied to another payload type when being sent, as they apply for
the configuration.</t></aside>
<ul spacing="normal">
<li><t>When an Offerer offers an interleaved stream, indicated
by the presence of sprop-max-don-diff with a value larger than
zero, the Offerer <bcp14>MUST</bcp14> include the size of the
de-packetization buffer sprop-depack-buf-bytes.</t></li>
<li><t>To enable the Offerer and Answerer to inform each other
about their capabilities for de-packetization buffering in
receiving RTP streams, both parties are
<bcp14>RECOMMENDED</bcp14> to include depack-buf-cap.</t></li>
<li><t>The parameters sprop-sps or sprop-pps, when present
(included in the "a=fmtp" line of SDP or conveyed using the
"fmtp" source attribute, as specified in <xref target="RFC5576"
sectionFormat="of" section="6.3"/>), are used for out-of-band
transport of the parameter sets (SPS or PPS, respectively). The
Answerer <bcp14>MAY</bcp14> use either out-of-band or in-band
transport of parameter sets for the bitstream it is sending,
regardless of whether out-of-band parameter sets transport has
been used in the Offerer-to-Answerer direction. Parameter sets
included in an answer are independent of those parameter sets
included in the offer, as they are used for decoding two
different bitstreams: one from the Answerer to the Offerer, and
the other in the opposite direction. In case some RTP packets
are sent before the SDP Offer/Answer settles down, in-band
parameter sets <bcp14>MUST</bcp14> be used for those RTP stream
parts sent before the SDP Offer/Answer.</t></li>
<li><t>The following rules apply to transport of parameter sets
in the Offerer-to-Answerer direction.</t>
<ul spacing="normal">
<li><t>An offer <bcp14>MAY</bcp14> include sprop-sps and/or
sprop-pps. If none of these parameters are present in the
offer, then only in-band transport of parameter sets is
used.</t></li>
<li><t>If the level to use in the Offerer-to-Answerer
direction is equal to the default level in the offer, the
Answerer <bcp14>MUST</bcp14> be prepared to use the parameter
sets included in sprop-sps and sprop-pps (either included in
the "a=fmtp" line of SDP or conveyed using the "fmtp" source
attribute) for decoding the incoming bitstream, e.g., by
passing these parameter set NAL units to the video decoder
before passing any NAL units carried in the RTP
streams. Otherwise, the Answerer <bcp14>MUST</bcp14> ignore
sprop-vps, sprop-sps, and sprop-pps (either included in the
"a=fmtp" line of SDP or conveyed using the "fmtp" source
attribute), and the Offerer <bcp14>MUST</bcp14> transmit
parameter sets in-band.</t></li>
</ul></li>
<li><t>The following rules apply to transport of parameter sets in
the Answerer-to-Offerer direction.</t>
<ul spacing="normal">
<li><t>An answer <bcp14>MAY</bcp14> include sprop-sps and/or
sprop-pps. If none of these parameters are present in the
answer, then only in-band transport of parameter sets is
used.</t></li>
<li><t>The Offerer <bcp14>MUST</bcp14> be prepared to use the
parameter sets included in sprop-sps and sprop-pps (either
included in the "a=fmtp" line of SDP or conveyed using the
"fmtp" source attribute) for decoding the incoming bitstream,
e.g., by passing these parameter set NAL units to the video
decoder before passing any NAL units carried in the RTP
streams.</t></li>
</ul></li>
<li><t>When sprop-sps and/or sprop-pps are conveyed using the
"fmtp" source attribute, as specified in <xref target="RFC5576"
sectionFormat="of" section="6.3"/>, the receiver of the parameters
<bcp14>MUST</bcp14> store the parameter sets included in sprop-sps
and/or sprop-pps and associate them with the source given as part
of the "fmtp" source attribute. Parameter sets associated with one
source (given as part of the "fmtp" source attribute)
<bcp14>MUST</bcp14> only be used to decode NAL units conveyed in
RTP packets from the same source (given as part of the "fmtp"
source attribute). When this mechanism is in use, SSRC collision
detection and resolution <bcp14>MUST</bcp14> be performed as
specified in <xref target="RFC5576"/>.</t></li>
</ul>
<t><xref target="params-interpretation"/> lists the interpretation o
f all the parameters that <bcp14>MAY</bcp14> be used for the various combination
s of offer, answer, and direction attributes.</t>
<figure anchor="params-interpretation"><artwork><![CDATA[ <figure anchor="params-interpretation">
<name>Interpretation of Parameters for Various Combinations of
Offers, Answers, and Direction Attributes</name>
<artwork><![CDATA[
sendonly --+ sendonly --+
recvonly --+ | recvonly --+ |
sendrecv --+ | | sendrecv --+ | |
| | | | | |
profile-id C C P profile-id C C P
level-id D D P level-id D D P
toolset-id C C P toolset-id C C P
max-recv-level-id R R - max-recv-level-id R R -
sprop-max-don-diff P - P sprop-max-don-diff P - P
sprop-depack-buf-bytes P - P sprop-depack-buf-bytes P - P
depack-buf-cap R R - depack-buf-cap R R -
sprop-sei P - P sprop-sei P - P
sprop-sps P - P sprop-sps P - P
sprop-pps P - P sprop-pps P - P
Legend: Legend:
C: configuration for sending and receiving bitstreams C: configuration for sending and receiving bitstreams
D: changeable configuration, same as C, except possible to D: changeable configuration; same as C, except possible to
answer with a different but consistent value (see the semantics answer with a different but consistent value (see the semantics
of the level-id parameter on these parameters being of the level-id parameter on these parameters being
consistent-basically, level down-grading is allowed) consistent -- basically, level down-grading is allowed)
P: properties of the bitstream to be sent P: properties of the bitstream to be sent
R: receiver capabilities R: receiver capabilities
-: not usable, when present MUST be ignored -: not usable; when present MUST be ignored]]></artwork>
</figure>
Interpretation of Parameters for Various Combinations of
Offers, Answers, and Direction Attributes.
]]></artwork></figure>
<t>Parameters used for declaring receiver capabilities are, in general, downgrad
able, i.e., they express the upper limit for a sender&#39;s possible behavior. T
hus, a sender MAY select to set its encoder using only lower/lesser or equal val
ues of these parameters.</t>
<t>When a sender&#39;s capabilities are declared with the configuration paramete
rs, these parameters express a configuration that is acceptable for the sender t
o receive bitstreams. In order to achieve high interoperability levels, it is of
ten advisable to offer multiple alternative configurations. It is impossible to
offer multiple configurations in a single payload type. Thus, when multiple conf
iguration offers are made, each offer requires its own RTP payload type associat
ed with the offer.</t>
<t>An implementation SHOULD be able to understand all media type parameters (inc
luding all optional media type parameters), even if it doesn&#39;t support the f
unctionality related to the parameter. This, in conjunction with proper applicat
ion logic in the implementation, allows the implementation, after having receive
d an offer, to create an answer by potentially downgrading one or more of the op
tional parameters to the point where the implementation can cope, leading to hig
her chances of interoperability beyond the most basic interop points (for which,
as described above, no optional parameters are necessary).</t>
<t>Informative note: In implementations of various H.26x video coding payload Fo
rmats including those for <xref target="AVC"/> and <xref target="HEVC"/>, it was
occasionally observed that implementations were incapable of parsing most (or a
ll) of the optional parameters and hence rejected offers other than the most bas
ic offers. As a result, the offer/answer exchange resulted in a baseline perform
ance (using the default values for the optional parameters) with the resulting s
uboptimal user experience. However, there are valid reasons to forego the implem
entation complexity of implementing the parsing of some or all of the optional p
arameters, for example, when there is predetermined knowledge, not negotiated by
an SDP-based offer/answer process, of the capabilities of the involved systems
(walled gardens, baseline requirements defined in application standards higher u
p in the stack, and similar).</t>
<t>An answerer MAY extend the offer with additional media format configurations.
However, to enable their usage, in most cases, a second offer is required from
the offerer to provide the bitstream property parameters that the media sender w
ill use. This also has the effect that the offerer has to be able to receive thi
s media format configuration, not only to send it.</t>
</section>
</section>
<section anchor="multicast"><name>Multicast</name>
<t>For bitstreams being delivered over multicast, the following rules apply:</t>
<t>The media format configuration is identified by profile-id and level-id. Thes
e media format configuration parameters, including level-id, MUST be used symmet
rically; that is, the answerer MUST either maintain all configuration parameters
or remove the media format (payload type) completely. Note that this implies th
at the level-id for offer/answer in multicast is not changeable.</t>
<t>To simplify the handling and matching of these configurations, the same RTP p
ayload type number used in the offer SHOULD also be used in the answer, as speci
fied in <xref target="RFC3264"></xref>. An answer MUST NOT contain a payload typ
e number used in the offer unless the configuration is the same as in the offer.
</t>
<t>Parameter sets received MUST be associated with the originating source and MU
ST only be used in decoding the incoming bitstream from the same source.</t>
<t>The rules for other parameters are the same as above for unicast as long as t
he three above rules are obeyed.</t>
</section>
<section anchor="declativeSessiondesc"><name>Usage in Declarative Session Descri
ptions</name>
<t>When EVC over RTP is offered with SDP in a declarative style, as in Real Time
Streaming Protocol (RTSP) <xref target="RFC7826"></xref> or Session Announcemen
t Protocol (SAP) <xref target="RFC2974"></xref>, the following considerations ap
ply.</t>
<t>All parameters capable of indicating both bitstream properties and receiver c
apabilities are used to indicate only bitstream properties. For example, in this
case, the parameters profile-id and level-id declare the values used by the bit
stream, not the capabilities for receiving bitstreams. As a result, the followin
g interpretation of the parameters MUST be used:</t>
<t>Declaring actual configuration or bitstream properties:</t>
<t>profile-id
level-id
sprop-sps
sprop-pps
sprop-max-don-diff
sprop-depack-buf-bytes
sprop-sei</t>
<t>Not usable (when present, they MUST be ignored):</t>
<t>depack-buf-cap
recv-sublayer-id</t>
<t>A receiver of the SDP is required to support all parameters and values of the
parameters provided; otherwise, the receiver MUST reject (RTSP) or not particip
ate in (SAP) the session. It falls on the creator of the session to use values t
hat are expected to be supported by the receiving application.</t>
</section>
<section anchor="consider4pps"><name>Considerations for Parameter Sets</name>
<t>When out-of-band transport of parameter sets is used, parameter sets MAY stil
l be additionally transported in-band unless explicitly disallowed by an applica
tion, and some of these additional parameter sets may update some of the out-of-
band transported parameter sets. An update of a parameter set refers to the send
ing of a parameter set of the same type using the same parameter set ID but with
different values for at least one other parameter of the parameter set.</t>
<!-- Section 8 -->
</section>
</section>
</section>
<section anchor="FeedbackMessage"><name>Use with Feedback Messages</name>
<t>The following subsections define the use of the Picture Loss Indication (PLI)
and Full Intra Request (FIR) feedback messages with <xref target="EVC"/>. The P
LI is defined in <xref target="RFC4585"/>, and the FIR message is defined in <xr
ef target="RFC5104"/>.</t>
<t>In accordance with this document, a sender MUST NOT send Slice Loss Indicatio
n (SLI) or Reference Picture Selection Indication (RPSI), and a receiver MUST ig
nore RPSI and MUST treat a received SLI as a received PLI, ignoring the &quot;Fi
rst&quot;, &quot;Number&quot;, and &quot;PictureID&quot; fields of the PLI.</t>
<!-- Section 8.1 -->
<section anchor="PLI"><name>Picture Loss Indication (PLI)</name>
<t>As specified in Section 6.3.1 of <xref target="RFC4585"/>, the reception of a
PLI by a media sender indicates &quot;the loss of an undefined amount of coded
video data belonging to one or more pictures&quot;. Without having any specific
knowledge of the setup of the bitstream (such as use and location of in-band par
ameter sets, IDR picture locations, picture structures, and so forth), a reactio
n to the reception of a PLI by a EVC sender SHOULD be to send an IDR picture and
relevant parameter sets, potentially with sufficient redundancy so to ensure co
rrect reception. However, sometimes information about the bitstream structure is
known. For example, such information can be parameter sets that have been conve
yed out of band through mechanisms not defined in this document and that are kno
wn to stay static for the duration of the session. In that case, it is obviously
unnecessary to send them in-band as a result of the reception of a PLI. Other e
xamples could be devised based on a priori knowledge of different aspects of the
bitstream structure. In all cases, the timing and congestion control mechanisms
of <xref target="RFC4585"/> MUST be observed.</t>
<!-- Section 8.2 -->
</section>
<section anchor="FIR"><name>Full Intra Request (FIR)</name>
<t>The purpose of the FIR message is to force an encoder to send an independent
decoder refresh point as soon as possible while observing applicable congestion-
control-related constraints, such as those set out in <xref target="RFC8082"/>.<
/t>
<t>Upon reception of a FIR, a sender MUST send an IDR picture. Parameter sets MU
ST also be sent, except when there is a priori knowledge that the parameter sets
have been correctly established. A typical example for that is an understanding
between the sender and receiver, established by means outside this document, th
at parameter sets are exclusively sent out of band.</t>
</section>
</section>
<section anchor="Security"><name>Security Considerations</name>
<t>The scope of this section is limited to the payload format itself and to one
feature of <xref target="EVC"/> that may pose a particularly serious security ri
sk if implemented naively. The payload format, in isolation, does not form a com
plete system. Implementers are advised to read and understand relevant security-
related documents, especially those pertaining to RTP (see the Security Consider
ations section in <xref target="RFC3550"/>) and the security of the call-control
stack chosen (that may make use of the media type registration of this document
). Implementers should also consider known security vulnerabilities of video cod
ing and decoding implementations in general and avoid those.</t>
<t>Within this RTP payload format, and with the exception of the user data SEI m
essage as described below, no security threats other than those common to RTP pa
yload formats are known. In other words, neither the various media-plane-based m
echanisms nor the signaling part of this document seem to pose a security risk b
eyond those common to all RTP-based systems.</t>
<t>RTP packets using the payload format defined in this specification are subjec
t to the security considerations discussed in the RTP specification <xref target
="RFC3550"/>, and in any applicable RTP profile such as RTP/AVP <xref target="RF
C3551"/>, RTP/AVPF <xref target="RFC4585"/>, RTP/SAVP <xref target="RFC3711"/>,
or RTP/SAVPF <xref target="RFC5124"/>. However, as &quot;Securing the RTP Frame
work: Why RTP Does Not Mandate a Single Media Security Solution&quot; <xref targ
et="RFC7202"/> discusses, it is not an RTP payload format&#39;s responsibility t
o discuss or mandate what solutions are used to meet the basic security goals li
ke confidentiality, integrity and source authenticity for RTP in general. This
responsibility lays on anyone using RTP in an application. They can find guidan
ce on available security mechanisms and important considerations in &quot;Option
s for Securing RTP Sessions&quot; <xref target="RFC7201"/>. Applications SHOULD
use one or more appropriate strong security mechanisms. The rest of this sectio
n discusses the security impacting properties of the payload format itself.</t>
<t>Because the data compression used with this payload format is applied end-to-
end, any encryption needs to be performed after compression. A potential denial-
of-service threat exists for data encodings using compression techniques that ha
ve non-uniform receiver-end computational load. The attacker can inject patholo
gical datagrams into the bitstream that are complex to decode and that cause the
receiver to be overloaded.</t>
<t>EVC is particularly vulnerable to such attacks, as it is extremely simple to
generate datagrams containing NAL units that affect the decoding process of many
future NAL units. Therefore, the usage of data origin authentication and data i
ntegrity protection of at least the RTP packet is RECOMMENDED based on the thoug
hts of <xref target="RFC7202"/>.</t>
<t>Like HEVC <xref target="RFC7798"/> and <xref target="VVC"/>, <xref target="EV
C"/> includes a user data Supplemental Enhancement Information (SEI) message. Th
is SEI message allows inclusion of an arbitrary bitstring into the video bitstre
am. Such a bitstring could include JavaScript, machine code, and other active co
ntent.</t>
<t><xref target="EVC"></xref> leaves the handling of this SEI message to the rec
eiving system. In order to avoid harmful side effects of the user data SEI messa
ge, decoder implementations cannot naively trust its content. For example, forwa
rding all received JavaScript code detected by a decoder implementation to a web
-browser unchecked would be a bad and insecure implementation practice. The safe
st way to deal with user data SEI messages is to simply discard them, but that c
an have negative side effects on the quality of experience by the user.</t>
<t>End-to-end security with authentication, integrity, or confidentiality protec
tion will prevent a MANE from performing media-aware operations other than disca
rding complete packets. In the case of confidentiality protection, it will even
be prevented from discarding packets in a media-aware way. To be allowed to pe
rform such operations, a MANE is required to be a trusted entity that is include
d in the security context establishment.</t>
</section>
<section anchor="CC"><name>Congestion Control</name>
<t>Congestion control for RTP SHALL be used in accordance with RTP <xref target=
"RFC3550"/> and with any applicable RTP profile, e.g., AVP <xref target="RFC3551
"/> or AVPF <xref target="RFC4585"/>. If best-effort service is being used, an a
dditional requirement is that users of this payload format MUST monitor packet l
oss to ensure that the packet loss rate is within an acceptable range. Packet lo
ss is considered acceptable if a TCP flow across the same network path and exper
iencing the same network conditions would achieve an average throughput, measure
d on a reasonable timescale, that is not less than all RTP streams combined are
achieved. This condition can be satisfied by implementing congestion-control mec
hanisms to adapt the transmission rate, by implementing the number of layers sub
scribed for a layered multicast session, or by arranging for a receiver to leave
the session if the loss rate is unacceptably high.</t>
<t>The bitrate adaptation necessary for obeying the congestion control principle
is easily achievable when real-time encoding is used, for example, by adequatel
y tuning the quantization parameter. However, when pre-encoded content is being
transmitted, bandwidth adaptation requires the pre-coded bitstream to be tailore
d for such adaptivity.</t>
<t>The key mechanism available in <xref target="EVC"></xref> is temporal scalabi
lity. A media sender can remove NAL units belonging to higher temporal sub-layer
s (i.e., those NAL units with a large value of TID) until the sending bitrate dr
ops to an acceptable range.</t>
<t>The mechanisms mentioned above generally work within a defined profile and le <t>Parameters used for declaring receiver capabilities are, in gener
vel; therefore no renegotiation of the channel is required. Only when non-downgr al, downgradable, i.e., they express the upper limit for a sender's possible beh
adable parameters (such as profile) are required to be changed does it become ne avior. Thus, a sender <bcp14>MAY</bcp14> select to set its encoder using only lo
cessary to terminate and restart the RTP stream(s). This may be accomplished by wer/lesser or equal values of these parameters.</t>
using different RTP payload types.</t> <t>When a sender's capabilities are declared with the configuration
parameters, these parameters express a configuration that is acceptable for the
sender to receive bitstreams. In order to achieve high interoperability levels,
it is often advisable to offer multiple alternative configurations. It is imposs
ible to offer multiple configurations in a single payload type. Thus, when multi
ple configuration offers are made, each offer requires its own RTP payload type
associated with the offer.</t>
<t>An implementation <bcp14>SHOULD</bcp14> be able to understand all
media type parameters (including all optional media type parameters), even if i
t doesn't support the functionality related to the parameter. This, in conjuncti
on with proper application logic in the implementation, allows the implementatio
n, after having received an offer, to create an answer by potentially downgradin
g one or more of the optional parameters to the point where the implementation c
an cope. This leads to higher chances of interoperability beyond the most basic
interop points (for which, as described above, no optional parameters are necess
ary).</t>
<aside><t>Informative note: In implementations of various H.26x vide
o coding payload formats including those for <xref target="AVC"/> and <xref targ
et="HEVC"/>, it was occasionally observed that implementations were incapable of
parsing most (or all) of the optional parameters and hence rejected offers othe
r than the most basic offers. As a result, the Offer/Answer exchange resulted in
a baseline performance (using the default values for the optional parameters) w
ith the resulting suboptimal user experience. However, there are valid reasons t
o forego the implementation complexity of implementing the parsing of some or al
l of the optional parameters, for example, when there is predetermined knowledge
, not negotiated by an SDP-based Offer/Answer process, of the capabilities of th
e involved systems (walled gardens, baseline requirements defined in application
standards higher up in the stack, and similar).</t></aside>
<t>An Answerer <bcp14>MAY</bcp14> extend the offer with additional m
edia format configurations. However, to enable their usage, in most cases, a sec
ond offer is required from the Offerer to provide the bitstream property paramet
ers that the media sender will use. This also has the effect that the Offerer ha
s to be able to receive this media format configuration, and not only to send it
.</t>
</section>
</section>
<section anchor="multicast">
<name>Multicast</name>
<t>For bitstreams being delivered over multicast, the following rules
apply:</t>
<ul spacing="normal">
<li><t>The media format configuration is identified by profile-id
and level-id. These media format configuration parameters,
including level-id, <bcp14>MUST</bcp14> be used symmetrically;
that is, the Answerer <bcp14>MUST</bcp14> either maintain all
configuration parameters or remove the media format (payload type)
completely. Note that this implies that the level-id for
Offer/Answer in multicast is not changeable.</t></li>
<li><t>To simplify the handling and matching of these
configurations, the same RTP payload type number used in the offer
<bcp14>SHOULD</bcp14> also be used in the answer, as specified in
<xref target="RFC3264"/>. An answer <bcp14>MUST NOT</bcp14>
contain a payload type number used in the offer unless the
configuration is the same as in the offer.</t></li>
<li><t>Parameter sets received <bcp14>MUST</bcp14> be associated
with the originating source and <bcp14>MUST</bcp14> only be used
in decoding the incoming bitstream from the same source.</t></li>
<li><t>The rules for other parameters are the same as above for
unicast as long as the three above rules are obeyed.</t></li>
</ul>
</section>
<section anchor="declativeSessiondesc">
<name>Usage in Declarative Session Descriptions</name>
<t>When EVC over RTP is offered with SDP in a declarative style, as in
the Real-Time Streaming Protocol (RTSP) <xref target="RFC7826"/> or Session Ann
ouncement Protocol (SAP) <xref target="RFC2974"/>, the following considerations
apply.</t>
<ul spacing="normal">
<li><t>All parameters capable of indicating both bitstream propertie
s and receiver capabilities are used to indicate only bitstream properties. For
example, in this case, the parameters profile-id and level-id declare the values
used by the bitstream, not the capabilities for receiving bitstreams. As a resu
lt, the following interpretation of the parameters <bcp14>MUST</bcp14> be used:<
/t>
<t>MANEs MAY remove certain unusable packets from the RTP stream when that RTP s <ul><li>
tream was damaged due to previous packet losses. This can help reduce the networ <t>Declaring actual configuration or bitstream properties:</t>
k load in certain special cases. For example, MANEs can remove those FUs where t <ul spacing="compact"><li><t>profile-id</t></li>
he leading FUs belonging to the same NAL unit have been lost, because the traili <li><t>level-id</t></li>
ng FUs are meaningless to most decoders. MANE can also remove higher temporal sc <li><t>sprop-sps</t></li>
alable layers if the outbound transmission (from the MANE&#39;s viewpoint) exper <li><t>sprop-pps</t></li>
iences congestion.</t> <li><t>sprop-max-don-diff</t></li>
<li><t>sprop-depack-buf-bytes</t></li>
<li><t>sprop-sei</t></li></ul></li>
<li>
<t>Not usable (when present, they <bcp14>MUST</bcp14> be ignored):</t>
<ul spacing="compact"><li>
<t>depack-buf-cap</t></li>
<li><t>recv-sublayer-id</t></li>
</ul>
</li>
<li> <t>A receiver of the SDP is required to support all parameters and
values of the parameters provided; otherwise, the receiver <bcp14>MUST</bcp14>
reject (RTSP) or not participate in (SAP) the session. It falls on the creator o
f the session to use values that are expected to be supported by the receiving a
pplication.</t></li>
</ul>
</li>
</ul>
</section>
<section anchor="consider4pps">
<name>Considerations for Parameter Sets</name>
<t>When out-of-band transport of parameter sets is used, parameter set
s <bcp14>MAY</bcp14> still be additionally transported in-band unless explicitly
disallowed by an application, and some of these additional parameter sets may u
pdate some of the out-of-band transported parameter sets. An update of a paramet
er set refers to the sending of a parameter set of the same type using the same
parameter set ID but with different values for at least one other parameter of t
he parameter set.</t>
</section> </section>
<section anchor="iana-considerations"><name>IANA Considerations</name> </section>
</section>
<t>A new media type, as specified in <xref target="oparams"/> of this document, <section anchor="FeedbackMessage">
has been registered with IANA.</t> <name>Use with Feedback Messages</name>
</section> <t>The following subsections define the use of the Picture Loss Indication
<section anchor="acknowledgements"><name>Acknowledgements</name> (PLI) <xref target="RFC4585" format="default"/> and Full Intra Request (FIR) <x
ref target="RFC5104" format="default"/> feedback messages with <xref target="EVC
"/>.</t>
<t>In accordance with this document, a sender <bcp14>MUST NOT</bcp14> send
Slice Loss Indication (SLI) or Reference Picture Selection Indication (RPSI); a
nd a receiver <bcp14>MUST</bcp14> ignore RPSI and <bcp14>MUST</bcp14> treat a re
ceived SLI as a received PLI, ignoring the "First", "Number", and "PictureID" fi
elds of the PLI.</t>
<t>Large parts of this specification share text with the RTP payload format for <section anchor="PLI">
VVC <xref target="RFC9328"/>. Roman Chernyak is thanksed for his valueable revie <name>Picture Loss Indication (PLI)</name>
w comments. We thank the authors of that specification for their excellent work. <t>As specified in <xref target="RFC4585" sectionFormat="of" section="6.
</t> 3.1"/>, the reception of a PLI by a media sender indicates "the loss of an undef
ined amount of coded video data belonging to one or more pictures". Without havi
ng any specific knowledge of the setup of the bitstream (such as use and locatio
n of in-band parameter sets, IDR picture locations, picture structures, and so f
orth), a reaction to the reception of a PLI by an EVC sender <bcp14>SHOULD</bcp1
4> be to send an IDR picture and relevant parameter sets, potentially with suffi
cient redundancy so as to ensure correct reception. However, sometimes informati
on about the bitstream structure is known. For example, such information can be
parameter sets that have been conveyed out of band through mechanisms not define
d in this document and that are known to stay static for the duration of the ses
sion. In that case, it is obviously unnecessary to send them in-band as a result
of the reception of a PLI. Other examples could be devised based on a priori kn
owledge of different aspects of the bitstream structure. In all cases, the timin
g and congestion-control mechanisms of <xref target="RFC4585"/> <bcp14>MUST</bcp
14> be observed.</t>
</section> </section>
<section anchor="FIR">
<name>Full Intra Request (FIR)</name>
<t>The purpose of the FIR message is to force an encoder to send an inde
pendent decoder refresh point as soon as possible while observing applicable con
gestion-control-related constraints, such as those set out in <xref target="RFC8
082"/>.</t>
<t>Upon reception of a FIR, a sender <bcp14>MUST</bcp14> send an IDR pic
ture. Parameter sets <bcp14>MUST</bcp14> also be sent, except when there is a pr
iori knowledge that the parameter sets have been correctly established. A typica
l example for that is an understanding between the sender and receiver, establis
hed by means outside this document, that parameter sets are exclusively sent out
of band.</t>
</section>
</section>
<section anchor="Security">
<name>Security Considerations</name>
<t>The scope of this section is limited to the payload format itself and t
o one feature of <xref target="EVC"/> that may pose a particularly serious secur
ity risk if implemented naively. The payload format, in isolation, does not form
a complete system. Implementers are advised to read and understand relevant sec
urity-related documents, especially those pertaining to RTP (see the Security Co
nsiderations in <xref target="RFC3550" sectionFormat="of" section="14"/>) and th
e security of the call-control stack chosen (that may make use of the media type
registration of this document). Implementers should also consider known securit
y vulnerabilities of video coding and decoding implementations in general and av
oid those.</t>
<t>Within this RTP payload format, and with the exception of the user data
SEI message as described below, no security threats other than those common to
RTP payload formats are known. In other words, neither the various media-plane-b
ased mechanisms nor the signaling part of this document seem to pose a security
risk beyond those common to all RTP-based systems.</t>
<t>RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP specification <xref
target="RFC3550"/> and in any applicable RTP profile such as RTP/AVP <xref targe
t="RFC3551"/>, RTP/AVPF <xref target="RFC4585"/>, RTP/SAVP <xref target="RFC3711
"/>, or RTP/SAVPF <xref target="RFC5124"/>. However, as "<xref target="RFC7202"
format="title"/>" <xref target="RFC7202" format="default"/> discusses, it is no
t an RTP payload format's responsibility to discuss or mandate what solutions ar
e used to meet the basic security goals like confidentiality, integrity, and sou
rce authenticity for RTP in general. This responsibility lies on anyone using R
TP in an application. They can find guidance on available security mechanisms a
nd important considerations in "<xref target="RFC7201" format="title"/>" <xref t
arget="RFC7201" format="default"/>. Applications <bcp14>SHOULD</bcp14> use one o
r more appropriate strong security mechanisms. The rest of this section discuss
es the security impacting properties of the payload format itself.</t>
<t>Because the data compression used with this payload format is applied e
nd to end, any encryption needs to be performed after compression. A potential d
enial-of-service threat exists for data encodings using compression techniques t
hat have non-uniform receiver-end computational load. The attacker can inject p
athological datagrams into the bitstream that are complex to decode and that cau
se the receiver to be overloaded.</t>
<t>EVC is particularly vulnerable to such attacks, as it is extremely simp
le to generate datagrams containing NAL units that affect the decoding process o
f many future NAL units. Therefore, the usage of data origin authentication and
data integrity protection of at least the RTP packet is <bcp14>RECOMMENDED</bcp1
4> based on <xref target="RFC7202"/>.</t>
<t>Like HEVC <xref target="RFC7798"/> and VVC <xref target="VVC"/>, EVC <x
ref target="EVC"/> includes a user data Supplemental Enhancement Information (SE
I) message. This SEI message allows inclusion of an arbitrary bitstring into the
video bitstream. Such a bitstring could include JavaScript, machine code, and o
ther active content.</t>
<t>EVC <xref target="EVC"/> leaves the handling of this SEI message to the
receiving system. In order to avoid harmful side effects of the user data SEI m
essage, decoder implementations cannot naively trust its content. For example, f
orwarding all received JavaScript code detected by a decoder implementation to a
web browser unchecked would be a bad and insecure implementation practice. The
safest way to deal with user data SEI messages is to simply discard them, but th
at can have negative side effects on the quality of experience by the user.</t>
<t>End-to-end security with authentication, integrity, or confidentiality
protection will prevent a MANE from performing media-aware operations other than
discarding complete packets. In the case of confidentiality protection, it wil
l even be prevented from discarding packets in a media-aware way. To be allowed
to perform such operations, a MANE is required to be a trusted entity that is i
ncluded in the security context establishment.</t>
</section>
<section anchor="CC">
<name>Congestion Control</name>
<t>Congestion control for RTP <bcp14>SHALL</bcp14> be used in accordance w
ith RTP <xref target="RFC3550"/> and with any applicable RTP profile, e.g., AVP
<xref target="RFC3551"/> or AVPF <xref target="RFC4585"/>. If best-effort servic
e is being used, an additional requirement is that users of this payload format
<bcp14>MUST</bcp14> monitor packet loss to ensure that the packet loss rate is w
ithin an acceptable range. Packet loss is considered acceptable if a TCP flow ac
ross the same network path and experiencing the same network conditions would ac
hieve an average throughput, measured on a reasonable timescale, that is not les
s than all RTP streams combined. This condition can be satisfied by implementing
congestion-control mechanisms to adapt the transmission rate by implementing th
e number of layers subscribed for a layered multicast session or by arranging fo
r a receiver to leave the session if the loss rate is unacceptably high.</t>
<t>The bitrate adaptation necessary for obeying the congestion control pri
nciple is easily achievable when real-time encoding is used, for example, by ade
quately tuning the quantization parameter. However, when pre-encoded content is
being transmitted, bandwidth adaptation requires the pre-coded bitstream to be t
ailored for such adaptivity.</t>
<t>The key mechanism available in <xref target="EVC"/> is temporal scalabi
lity. A media sender can remove NAL units belonging to higher temporal sub-layer
s (i.e., those NAL units with a large value of TID) until the sending bitrate dr
ops to an acceptable range.</t>
<t>The mechanisms mentioned above generally work within a defined profile
and level; therefore, no renegotiation of the channel is required. Only when non
-downgradable parameters (such as the profile) are required to be changed does i
t become necessary to terminate and restart the RTP streams. This may be accompl
ished by using different RTP payload types.</t>
<t>MANEs <bcp14>MAY</bcp14> remove certain unusable packets from the RTP s
tream when that RTP stream was damaged due to previous packet losses. This can h
elp reduce the network load in certain special cases. For example, MANEs can rem
ove those FUs where the leading FUs belonging to the same NAL unit have been los
t, because the trailing FUs are meaningless to most decoders. MANE can also remo
ve higher temporal scalable layers if the outbound transmission (from the MANE's
viewpoint) experiences congestion.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>The media type specified in <xref target="oparams"/> has been registere
d with IANA.</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<references title='Normative References'> <reference anchor="EVC" target="https://www.iso.org/standard/57797.html"
>
<reference anchor="ISO23094-1" target="https://www.iso.org/standard/57797.html"> <front>
<front> <title>Information technology -- General video coding -- Part 1: Ess
<title>ISO/IEC DIS Information technology --- General video coding --- Part ential video
1 Essential video coding</title> coding</title>
<author > <author>
<organization></organization> <organization/>
</author> </author>
<date year="n.d."/> <date month="October" year="2020"/>
</front> </front>
</reference> <seriesInfo name="ISO/IEC" value="23094-1:2020"/>
<reference anchor="EVC" target="https://www.iso.org/standard/57797.html"> </reference>
<front>
<title>ISO/IEC 23094-1 Essential Video Coding</title>
<author >
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="RFC9328">
<front>
<title>RTP Payload Format for Versatile Video Coding (VVC)</title>
<author fullname="S. Zhao" initials="S." surname="Zhao"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="Y. Sanchez" initials="Y." surname="Sanchez"/>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="M. M Hannuksela" initials="M. M" surname="Hannuksela"/>
<date month="December" year="2022"/>
<abstract>
<t>This memo describes an RTP payload format for the Versatile Video Codin
g (VVC) specification, which was published as both ITU-T Recommendation H.266 an
d ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video E
xperts Team (JVET). The RTP payload format allows for packetization of one or mo
re Network Abstraction Layer (NAL) units in each RTP packet payload, as well as
fragmentation of a NAL unit into multiple RTP packets. The payload format has wi
de applicability in videoconferencing, Internet video streaming, and high-bitrat
e entertainment-quality video, among other applications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9328"/>
<seriesInfo name="DOI" value="10.17487/RFC9328"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the
requirements in the specification. These words are often capitalized. This docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument specifies an Internet Best Current Practices for the Internet Community,
and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<author fullname="R. Frederick" initials="R." surname="Frederick"/>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
<date month="July" year="2003"/>
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol. RTP pr
ovides end-to-end network transport functions suitable for applications transmit
ting real-time data, such as audio, video or simulation data, over multicast or
unicast network services. RTP does not address resource reservation and does not
guarantee quality-of- service for real-time services. The data transport is aug
mented by a control protocol (RTCP) to allow monitoring of the data delivery in
a manner scalable to large multicast networks, and to provide minimal control an
d identification functionality. RTP and RTCP are designed to be independent of t
he underlying transport and network layers. The protocol supports the use of RTP
-level translators and mixers. Most of the text in this memorandum is identical
to RFC 1889 which it obsoletes. There are no changes in the packet formats on th
e wire, only changes to the rules and algorithms governing how the protocol is u
sed. The biggest change is an enhancement to the scalable timer algorithm for ca
lculating when to send RTCP packets in order to minimize transmission in excess
of the intended rate when many participants join a session simultaneously. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Control</tit
le>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<date month="July" year="2003"/>
<abstract>
<t>This document describes a profile called "RTP/AVP" for the use of the r
eal-time transport protocol (RTP), version 2, and the associated control protoco
l, RTCP, within audio and video multiparticipant conferences with minimal contro
l. It provides interpretations of generic fields within the RTP specification su
itable for audio and video conferences. In particular, this document defines a s
et of default mappings from payload type numbers to encodings. This document als
o describes how audio and video data may be carried within RTP. It defines a set
of standard encodings and their names when used within RTP. The descriptions pr
ovide pointers to reference implementations and the detailed standards. This doc
ument is meant as an aid for implementors of audio, video and other real-time mu
ltimedia applications. This memorandum obsoletes RFC 1890. It is mostly backward
s-compatible except for functions removed because two interoperable implementati
ons were not found. The additions to RFC 1890 codify existing practice in the us
e of payload formats under this profile and include new payload formats defined
since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="65"/>
<seriesInfo name="RFC" value="3551"/>
<seriesInfo name="DOI" value="10.17487/RFC3551"/>
</reference>
<reference anchor="RFC3711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author fullname="M. Baugher" initials="M." surname="Baugher"/>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="M. Naslund" initials="M." surname="Naslund"/>
<author fullname="E. Carrara" initials="E." surname="Carrara"/>
<author fullname="K. Norrman" initials="K." surname="Norrman"/>
<date month="March" year="2004"/>
<abstract>
<t>This document describes the Secure Real-time Transport Protocol (SRTP),
a profile of the Real-time Transport Protocol (RTP), which can provide confiden
tiality, message authentication, and replay protection to the RTP traffic and to
the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3711"/>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
</reference>
<reference anchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-
Based Feedback (RTP/AVPF)</title>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="N. Sato" initials="N." surname="Sato"/>
<author fullname="C. Burmeister" initials="C." surname="Burmeister"/>
<author fullname="J. Rey" initials="J." surname="Rey"/>
<date month="July" year="2006"/>
<abstract>
<t>Real-time media streams that use RTP are, to some degree, resilient aga
inst packet losses. Receivers may use the base mechanisms of the Real-time Trans
port Control Protocol (RTCP) to report packet reception statistics and thus allo
w a sender to adapt its transmission behavior in the mid-term. This is the sole
means for feedback and feedback-based error repair (besides a few codec-specific
mechanisms). This document defines an extension to the Audio-visual Profile (AV
P) that enables receivers to provide, statistically, more immediate feedback to
the senders and thus allows for short-term adaptation and efficient feedback-bas
ed repair mechanisms to be implemented. This early feedback profile (AVPF) maint
ains the AVP bandwidth constraints for RTCP and preserves scalability to large g
roups. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4585"/>
<seriesInfo name="DOI" value="10.17487/RFC4585"/>
</reference>
<reference anchor="RFC5124">
<front>
<title>Extended Secure RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/SAVPF)</title>
<author fullname="J. Ott" initials="J." surname="Ott"/>
<author fullname="E. Carrara" initials="E." surname="Carrara"/>
<date month="February" year="2008"/>
<abstract>
<t>An RTP profile (SAVP) for secure real-time communications and another p
rofile (AVPF) to provide timely feedback from the receivers to a sender are defi
ned in RFC 3711 and RFC 4585, respectively. This memo specifies the combination
of both profiles to enable secure RTP communications with feedback. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5124"/>
<seriesInfo name="DOI" value="10.17487/RFC5124"/>
</reference>
<reference anchor="RFC8174"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 328.xml"/>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="B. Leiba" initials="B." surname="Leiba"/> 119.xml"/>
<date month="May" year="2017"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<abstract> 550.xml"/>
<t>RFC 2119 specifies common key words that may be used in protocol specif <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ications. This document aims to reduce the ambiguity by clarifying that only UPP 551.xml"/>
ERCASE usage of the key words have the defined special meanings.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</abstract> 711.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="BCP" value="14"/> 585.xml"/>
<seriesInfo name="RFC" value="8174"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="DOI" value="10.17487/RFC8174"/> 124.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
866.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
576.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
104.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
826.xml"/>
<reference anchor="RFC3264"> <reference anchor="VSEI" target="https://www.itu.int/rec/T-REC-H.274">
<front> <front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)</title> <title>Versatile supplemental enhancement information messages for c
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> oded video bitstreams</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <author>
<date month="June" year="2002"/> <organization>ITU-T</organization>
<abstract> </author>
<t>This document defines a mechanism by which two entities can make use of <date month="March" year="2024"/>
the Session Description Protocol (SDP) to arrive at a common view of a multimed </front>
ia session between them. In the model, one participant offers the other a descri <seriesInfo name="ITU-T Recommendation" value="H.274"/>
ption of the desired session from their perspective, and the other participant a </reference>
nswers with the desired session from their perspective. This offer/answer model
is most useful in unicast sessions where information from both participants is n
eeded for the complete view of the session. The offer/answer model is used by pr
otocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264"/>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
</reference>
<reference anchor="RFC8866"> </references>
<front> <references>
<title>SDP: Session Description Protocol</title> <name>Informative References</name>
<author fullname="A. Begen" initials="A." surname="Begen"/>
<author fullname="P. Kyzivat" initials="P." surname="Kyzivat"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<date month="January" year="2021"/>
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP is intend
ed for describing multimedia sessions for the purposes of session announcement,
session invitation, and other forms of multimedia session initiation. This docum
ent obsoletes RFC 4566.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8866"/>
<seriesInfo name="DOI" value="10.17487/RFC8866"/>
</reference>
<reference anchor="RFC4648"> <reference anchor="MPEG2S">
<front> <front>
<title>The Base16, Base32, and Base64 Data Encodings</title> <title>Information technology - Generic coding of moving pictures an
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/> d associated audio information - Part 1: Systems</title>
<date month="October" year="2006"/> <author>
<abstract> <organization>IS0/IEC</organization>
<t>This document describes the commonly used base 64, base 32, and base 16 </author>
encoding schemes. It also discusses the use of line-feeds in encoded data, use <date month="June" year="2013"/>
of padding in encoded data, use of non-alphabet characters in encoded data, use </front>
of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> <seriesInfo name="ISO/IEC" value="13818-1:2013"/>
</abstract> </reference>
</front>
<seriesInfo name="RFC" value="4648"/>
<seriesInfo name="DOI" value="10.17487/RFC4648"/>
</reference>
<reference anchor="RFC5576"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 184.xml"/>
<title>Source-Specific Media Attributes in the Session Description Protocol <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
(SDP)</title> 190.xml"/>
<author fullname="J. Lennox" initials="J." surname="Lennox"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="J. Ott" initials="J." surname="Ott"/> 656.xml"/>
<author fullname="T. Schierl" initials="T." surname="Schierl"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="June" year="2009"/> 667.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>The Session Description Protocol (SDP) provides mechanisms to describe 201.xml"/>
attributes of multimedia sessions and of individual media streams (e.g., Real-ti <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
me Transport Protocol (RTP) sessions) within a multimedia session, but does not 202.xml"/>
provide any mechanism to describe individual media sources within a media stream <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
. This document defines a mechanism to describe RTP media sources, which are ide 798.xml"/>
ntified by their synchronization source (SSRC) identifiers, in SDP, to associate <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
attributes with these sources, and to express relationships among sources. It a 974.xml"/>
lso defines several source-level attributes that can be used to describe propert
ies of media sources. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5576"/>
<seriesInfo name="DOI" value="10.17487/RFC5576"/>
</reference>
<reference anchor="RFC5104"> <reference anchor="HEVC" target="https://www.itu.int/rec/T-REC-H.265">
<front> <front>
<title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback <title>High efficiency video coding</title>
(AVPF)</title> <author>
<author fullname="S. Wenger" initials="S." surname="Wenger"/> <organization>ITU-T</organization>
<author fullname="U. Chandra" initials="U." surname="Chandra"/> </author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <date month="November" year="2019"/>
<author fullname="B. Burman" initials="B." surname="Burman"/> </front>
<date month="February" year="2008"/> <seriesInfo name="ITU-T Recommendation" value="H.265"/>
<abstract> </reference>
<t>This document specifies a few extensions to the messages defined in the
Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conver
sational multimedia scenarios where centralized multipoint functionalities are i
n use. However, some are also usable in smaller multicast environments and point
-to-point calls.</t>
<t>The extensions discussed are messages related to the ITU-T Rec. H.271 V
ideo Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate,
and Temporal-Spatial Trade-off. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5104"/>
<seriesInfo name="DOI" value="10.17487/RFC5104"/>
</reference>
<reference anchor="RFC8082"> <reference anchor="VIDEO-CODING" target="https://www.itu.int/rec/T-REC-H.
<front> 263">
<title>Using Codec Control Messages in the RTP Audio-Visual Profile with Fee <front>
dback with Layered Codecs</title> <title>Video coding for low bit rate communication</title>
<author fullname="S. Wenger" initials="S." surname="Wenger"/> <author>
<author fullname="J. Lennox" initials="J." surname="Lennox"/> <organization>ITU-T</organization>
<author fullname="B. Burman" initials="B." surname="Burman"/> </author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/> <date month="January" year="2005"/>
<date month="March" year="2017"/> </front>
<abstract> <seriesInfo name="ITU-T Recommendation" value="H.263"/>
<t>This document updates RFC 5104 by fixing a shortcoming in the specifica </reference>
tion language of the Codec Control Message Full Intra Request (FIR) description
when using it with layered codecs. In particular, a decoder refresh point needs
to be sent by a media sender when a FIR is received on any layer of the layered
bitstream, regardless of whether those layers are being sent in a single or in m
ultiple RTP flows. The other payload-specific feedback messages defined in RFC 5
104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no
corresponding shortcomings have been found.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8082"/>
<seriesInfo name="DOI" value="10.17487/RFC8082"/>
</reference>
<reference anchor="RFC7826"> <reference anchor="AVC" target="https://www.iso.org/standard/66069.html"
<front> >
<title>Real-Time Streaming Protocol Version 2.0</title> <front>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/> <title>Part 10: Advanced video coding</title>
<author fullname="A. Rao" initials="A." surname="Rao"/> <author>
<author fullname="R. Lanphier" initials="R." surname="Lanphier"/> <organization>ITU-T</organization>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/> </author>
<author fullname="M. Stiemerling" initials="M." role="editor" surname="Stiem <date month="October" year="2014"/>
erling"/> </front>
<date month="December" year="2016"/> <seriesInfo name="ITU-T Recommendation" value="H.264"/>
<abstract> </reference>
<t>This memorandum defines the Real-Time Streaming Protocol (RTSP) version
2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.</t>
<t>RTSP is an application-layer protocol for the setup and control of the
delivery of data with real-time properties. RTSP provides an extensible framewor
k to enable controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored clips. This p
rotocol is intended to control multiple data delivery sessions; provide a means
for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide
a means for choosing delivery mechanisms based upon RTP (RFC 3550).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7826"/>
<seriesInfo name="DOI" value="10.17487/RFC7826"/>
</reference>
<reference anchor="VSEI" target="https://www.itu.int/rec/T-REC-H.274"> <reference anchor="VVC" target="http://www.itu.int/rec/T-REC-H.266">
<front> <front>
<title>Versatile supplemental enhancement information messages for coded vid <title>Versatile video coding</title>
eo bitstreams</title> <author>
<author > <organization>ITU-T</organization>
<organization></organization> </author>
</author> <date month="August" year="2020"/>
<date year="2020"/> </front>
</front> <seriesInfo name="ITU-T Recommendation" value="H.266"/>
</reference> </reference>
</references>
</references> </references>
<references title='Informative References'> <section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<reference anchor="MPEG2S" > <t>Large parts of this specification share text with the RTP payload
<front> format for VVC <xref target="RFC9328"/>. <contact fullname="Roman
<title>Information technology - Generic coding ofmoving pictures and associa Chernyak"/> is thanked for his valuable review comments. We thank the
ted audio information - Part 1:Systems, ISO International Standard 13818-1</titl authors of that specification for their excellent work.</t>
e> </section>
<author initials="" surname="IS0/IEC" fullname="IS0/IEC">
<organization></organization>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="RFC6184">
<front>
<title>RTP Payload Format for H.264 Video</title>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="R. Even" initials="R." surname="Even"/>
<author fullname="T. Kristensen" initials="T." surname="Kristensen"/>
<author fullname="R. Jesup" initials="R." surname="Jesup"/>
<date month="May" year="2011"/>
<abstract>
<t>This memo describes an RTP Payload format for the ITU-T Recommendation
H.264 video codec and the technically identical ISO/IEC International Standard 1
4496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the
Multiview Video Coding extension, for which the RTP payload formats are defined
elsewhere. The RTP payload format allows for packetization of one or more Netwo
rk Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each
RTP payload. The payload format has wide applicability, as it supports applicati
ons from simple low bitrate conversational usage, to Internet video streaming wi
th interleaved transmission, to high bitrate video-on-demand.</t>
<t>This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in S
ection 14. Issues on backward compatibility to RFC 3984 are discussed in Section
15. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6184"/>
<seriesInfo name="DOI" value="10.17487/RFC6184"/>
</reference>
<reference anchor="RFC6190">
<front>
<title>RTP Payload Format for Scalable Video Coding</title>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="T. Schierl" initials="T." surname="Schierl"/>
<author fullname="A. Eleftheriadis" initials="A." surname="Eleftheriadis"/>
<date month="May" year="2011"/>
<abstract>
<t>This memo describes an RTP payload format for Scalable Video Coding (SV
C) as defined in Annex G of ITU-T Recommendation H.264, which is technically ide
ntical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payloa
d format allows for packetization of one or more Network Abstraction Layer (NAL)
units in each RTP packet payload, as well as fragmentation of a NAL unit in mul
tiple RTP packets. Furthermore, it supports transmission of an SVC stream over a
single as well as multiple RTP sessions. The payload format defines a new media
subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the
base layer, when encapsulated in its own RTP stream, must use the H.264 media s
ubtype name ("H264") and the packetization method specified in RFC 6184. The pay
load format has wide applicability in videoconferencing, Internet video streamin
g, and high-bitrate entertainment-quality video, among others. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6190"/>
<seriesInfo name="DOI" value="10.17487/RFC6190"/>
</reference>
<reference anchor="RFC7656">
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protoc
ol (RTP) Sources</title>
<author fullname="J. Lennox" initials="J." surname="Lennox"/>
<author fullname="K. Gross" initials="K." surname="Gross"/>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="B. Burman" initials="B." role="editor" surname="Burman"/>
<date month="November" year="2015"/>
<abstract>
<t>The terminology about, and associations among, Real-time Transport Prot
ocol (RTP) sources can be complex and somewhat opaque. This document describes a
number of existing and proposed properties and relationships among RTP sources
and defines common terminology for discussing protocol entities and their relati
onships.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7656"/>
<seriesInfo name="DOI" value="10.17487/RFC7656"/>
</reference>
<reference anchor="RFC7667">
<front>
<title>RTP Topologies</title>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<date month="November" year="2015"/>
<abstract>
<t>This document discusses point-to-point and multi-endpoint topologies us
ed in environments based on the Real-time Transport Protocol (RTP). In particula
r, centralized topologies commonly employed in the video conferencing industry a
re mapped to the RTP terminology.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7667"/>
<seriesInfo name="DOI" value="10.17487/RFC7667"/>
</reference>
<reference anchor="RFC7201">
<front>
<title>Options for Securing RTP Sessions</title>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="April" year="2014"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is used in a large number of dif
ferent application domains and environments. This heterogeneity implies that dif
ferent security mechanisms are needed to provide services such as confidentialit
y, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) p
ackets suitable for the various environments. The range of solutions makes it di
fficult for RTP-based application developers to pick the most suitable mechanism
. This document provides an overview of a number of security solutions for RTP a
nd gives guidance for developers on how to choose the appropriate security mecha
nism.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7201"/>
<seriesInfo name="DOI" value="10.17487/RFC7201"/>
</reference>
<reference anchor="RFC7202">
<front>
<title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media S
ecurity Solution</title>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
<date month="April" year="2014"/>
<abstract>
<t>This memo discusses the problem of securing real-time multimedia sessio
ns. It also explains why the Real-time Transport Protocol (RTP) and the associat
ed RTP Control Protocol (RTCP) do not mandate a single media security mechanism.
This is relevant for designers and reviewers of future RTP extensions to ensure
that appropriate security mechanisms are mandated and that any such mechanisms
are specified in a manner that conforms with the RTP architecture.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7202"/>
<seriesInfo name="DOI" value="10.17487/RFC7202"/>
</reference>
<reference anchor="RFC7798">
<front>
<title>RTP Payload Format for High Efficiency Video Coding (HEVC)</title>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>
<author fullname="Y. Sanchez" initials="Y." surname="Sanchez"/>
<author fullname="T. Schierl" initials="T." surname="Schierl"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<author fullname="M. M. Hannuksela" initials="M. M." surname="Hannuksela"/>
<date month="March" year="2016"/>
<abstract>
<t>This memo describes an RTP payload format for the video coding standard
ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both als
o known as High Efficiency Video Coding (HEVC) and developed by the Joint Collab
orative Team on Video Coding (JCT-VC). The RTP payload format allows for packeti
zation of one or more Network Abstraction Layer (NAL) units in each RTP packet p
ayload as well as fragmentation of a NAL unit into multiple RTP packets. Further
more, it supports transmission of an HEVC bitstream over a single stream as well
as multiple RTP streams. When multiple RTP streams are used, a single transport
or multiple transports may be utilized. The payload format has wide applicabili
ty in videoconferencing, Internet video streaming, and high-bitrate entertainmen
t-quality video, among others.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7798"/>
<seriesInfo name="DOI" value="10.17487/RFC7798"/>
</reference>
<reference anchor="RFC2974">
<front>
<title>Session Announcement Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<author fullname="E. Whelan" initials="E." surname="Whelan"/>
<date month="October" year="2000"/>
<abstract>
<t>This document describes version 2 of the multicast session directory an
nouncement protocol, Session Announcement Protocol (SAP), and the related issues
affecting security and scalability that should be taken into account by impleme
ntors. This memo defines an Experimental Protocol for the Internet community.</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="2974"/>
<seriesInfo name="DOI" value="10.17487/RFC2974"/>
</reference>
<reference anchor="HEVC" target="https://www.itu.int/rec/T-REC-H.265">
<front>
<title>High efficiency video coding, ITU-T Recommendation H.265</title>
<author >
<organization></organization>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="AVC" target="https://www.iso.org/standard/66069.html">
<front>
<title>ITU-T Recommendation H.264 - Advanced video coding for generic audiov
isual services</title>
<author >
<organization></organization>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="VVC" target="http://www.itu.int/rec/T-REC-H.266">
<front>
<title>Versatile Video Coding, ITU-T Recommendation H.266</title>
<author >
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
</references>
</back> </back>
<!-- ##markdown-source:
H4sIAOeOgmUAA+2963IbR7Yu+B9PUSNFnCamAVqkJEqi246mSKrFM7pwE5T6
9PR2OApAgawWUIVdVSBFy97RP+f3xPw85zXmAeZR+klmXTNXZhVIyJb7MnPY
bpsEqvK6cl2/tXI4HPaavJln+8nZ+Wlymt7My3SavCirRdoks7JKjus6K5o8
nSfv82lWJoflNC8ukq3j94f9XjoeV9kVv7uUd2fm3feHvWk5KdIFtD+t0lkz
zLNmNkyvmklZZcOqWQ6zq8nwwZPeNG3gmd0Huw+HO7vDnWe9Xt2kxfT7dF4W
8EVTrTL8qMrSxX5ycnz+Iun18mVF39TN7oMHzx7s9lL4ej85ODvvXV/sJ9JL
78M1vFE0WVVkzfAIR9GbpM1+UjfTXm9C04GH60me95b5fvLnppwMkrqsoLNZ
Db/dLPCX73q9dNVcltV+L6Gfofw3SfKi3k9G28n/fpmW7kOe9OhylebhF2V1
weOZu49wXhmMaBfmkbzO6zovC1jo+Ty7yJLn86upe3KSNzfQalo0aXI4T6vU
f1NOob9njx88fmQ+WxVNBS+8Gx24D7NFms9h9jiy7R9gZL/PsyzbhmGtndgf
s+Iiq+KpNdnyMi3iL2l651kxAappT/DJoydAZNWHrlmdwl4nB/OmjOf06PHT
p5vNqcmus9/Tv9fP50/byat8EU3mT9DqxYdrWHb7Hc1llC5q+DI5nmeTpiqL
fFK35rW3t/s4Of44yWDLYObJH9ObeHLztIgn9uTxg52HG03s5sP8+jJvst9f
4N/bk3LR6xV0zvKrDAnyZPR29+GDZ4+GO0yecqbh469Ojg+To5MRkByfTKSt
JptcFuW8vLhJ/vbX/yv5Q1ZkFZzwKzrhfCToC9iqJtkxPMA+QR3VWZVndQ5t
7yfcc1pd4JJcNs2y3v/qq+vr6+28LnE/vqIjnVbTrx4/efLsyfZls5j34CVg
E52jlhmtYUE/qzd8x7GaB9j52YvDZw93n+7zr7s7O8/k14ePHz/wv+7or092
9Fcgy8fy6+Od3Ufy65O9x3vy69OdJ/rpw909/fXp0z194NHeI+348eMne66F
vSeu3QfutQdPd/WBp7v4LPzxfnR8EizdvfdZVcMez7OkXi2X82wBKwcLlxVw
VCf0V5IbQlhkdZ1eZDWxa6TKqWzxOG+Y29b31i90s9rOi+arKpt8dT48Oz4c
vtyGE95aZNch0yr88/r0+A+7o3DTu8lzyMSZT5Qsy9mivMJflvmkWVUwdNhl
YN91OcmhT/h1Nc3LYJJDoeP90Q3whgXwdKAwEQn0BCzQSIgl2Xn4dOfpcIeG
FjJ84R8nowdInREDsZ/q3Olww37t7TzVXdzbeaZE9QQe8L+6vX3yzNHiMyQf
+P1lfEBe5heXSTab5ZMc2M1NcCphcufvhufJWQZcAvZ7ymsAO7P3+PN2Up53
s3mGYzmIz+q6zh7Bsh9Mr5DqpiFjQVK7kE2lzbrK6xVsAbCSq3yS1Zsf7L29
B3vP2gd75xFT2ftorOZwWEZyy4rttYn/1hXba9H+cDhM0jEcpXTS9Hrnl3md
gEa0ooM4zepJlY+JhNepUM1ldqsKluhiDJLlajzP60s8ArXjoWuoXFjrNvLe
5Bqen2ZX2bxcwsvjG+r0NZ+yUz5lINyWWdXUyR+qcrVMtvAA97eTc3iwY+Dp
fF5e1278y3TyIWvyH3hdy1kCKh3I1mQB2lnyJmuuS1AIDmSR8JFX6U1WJVtv
Dl71k1UBnAhOXpKlk0vpDJtzfeLxx15mVXpB3E57SRNogN6H15syWazmTQ4s
0TRS8xSi4V/CeowrahtYaD5Jx/kchDgOggh5UhazrIKTx8QjqqUQOXNN+gZH
dglHdQjMtAKaAC4MjzZpXuA4h/8BRI/N0nvw9KJE9gZTqbRfnEm9zUS0yKfT
OejA97HDqpyueKnuKxv6dD83n/+EtLaWcj59gm3/6SdDOwmoF7C8ec1rMJ/f
IHXmFwWz1E3pCVr2mgh0QCuZZYWhTVhEPBnbSfIWqOCihFZgr5CesHfYpg9Z
ttQR/qZOnqd1Ns/h0WVVzvDoZjonGGNV3qTz5mY4AzUMCXdV4/Sc+ADNxPRM
5Nagyrr7ILnJ0grO3UWJhEiLfp3XWfKhKK8LHMU4A/sBdK10DF0iIa/g2+sc
5MEK6Dupsv9Y5RXLU/wWKAh75vFAtwNYUCARmD71miojlEngMuMZoZbSGtYS
u0F6KcpiOM2RLwANpU1Z3SRACVkhE6sWMKMSPrnZTp7DsInyW0ukhAeU5DqE
RdZtBzMJul2ChQMjgrnCM0iDyp+NYLkAWoVXr6AhkjnH/quIoF5K09Cz4/rR
Iwf0xKqYQmsTPgcJHqX8YlU5Uv98DgkdbycnDRg0KWoDyC3GaQ2yhQmYNo2W
SbnBEL6G0bWbo0Vi2RUNXYT4Tz8NktEkZaIIefEIebE8+OwBPnjrgm29PHYv
oMjHF3DtuiVUsgWirE8Po676009wev6I04IJL8EqwU2U2S4v83lZl8vLG7Bc
s8mqAg4zwGUGJY8YBvwKbGLO3eHOwkFK8oWqivIM/v2RXs2ZH9ZAj2BvIq2g
IMCTBZ3CcYBjAUdpnmdVvDk4tHzm2FiS0N7CPykOAuztclUnk8sSyHuALAZe
mcNhaOx64+PXsBLEj5bz8iZjhn/BFgt8zCcWSAm3uMrmGRBf4yeEtAZSHfcd
xgyDOBTKWwCTSIu8hgPFTcyqcmF3MLmGAwwNT8oKjoryQZSXqFmXKAxBmcSv
QHUhoiApwSIVFh4ERIPDLmGpirIB2gKhoccSl4jIzb4JzP1+8vYK1aDsGr8k
4Q+tARVkk+T+/V5PjvBAj9MgPHqfPr1nxo5nAdZZd+3yZlzlRg3L9HTAgpzg
0plDB6wrcywhTWA4NyAN82xG1OKHhjs/y1LWweETHChw1wbZywA3pC4XxDoX
sLvTaYV822kX3aQC3yPXzGlYfgdroMCrDOkNmCUIK2IhJLuYilFacrMqpVSw
JUvebWKeJQ+xhAFWYIogveXYPBI0nmic+Hw+hL9wVPhKeCxEWSAK0PbxaKTd
DDhNXiOdyUcDGt88bZAixxm2niIhwUSyRve61c54hWOczFfEBUJRomu/TQY0
6Fx1Kc/CfsBZp2MNtl1ylVY5nAnapDHKDNcNDtMOsh44RQueZZUAx+WMQTyO
0GUDqrvIDqSx4gKGenJ0piYZH4FZOkGyhoNTO3Z/DUc2mw4vYOlAKYiWV0UD
KuHVBJUWZBOgOeU4eHi4FALCXZujNwatBmFIoAvAyULef2NWrL6Bxj8mGXdT
C32S5AWeXCIZ4SQW6JFKzTRT+vgan5atWaQFNgxMCAwEFE0iLJuynNckUbOP
OOqaVZxg1WhVYaGWOXBjdyaJfWbKyb73c/1+Nk8vRGDTcd5Gc+awhF1f4pTn
wJWRacMiD9AeG5CByOID/is0AB0GIkR06veHr/pfw3eoSvBy5NhVA9uxqnlL
qwwZlQyPpznEaTqKk1N3l+o+EApa1StW1rDdWhuu2RZn9b1KixpZKh9IoBwY
Pkm2WtefmFZNLPK+TGl4joN6oSxoy7gZ+sAsgVvK1MfzcvLB9ISPoZ6+Imrt
9XD1YPJ4kuH7aS7KLb0myoLstntJ5zbNkU3WNESmqKmcOjI5pGeYAxhN8Pfe
o4+gXMxXC6CGFKnfG0mdPGRn9+lH+H/3G/bk8lZOQEsaoxQE8VPDMqD4oQFO
eTg1avbIf2hYzM7GUb9wDIF35D/gAIiwhvP8Q5aAsTIdNqRm85yWKWgBuFJ0
Ci691Ye6SC7Cg55NLssq/6FEPxQMCKd1hRrEhP4scVyzclW5wdXQVZUFYwxm
CrIEOrkuPSeMN4cP5X6y00+egxIN8uscbRb8L05g6/n5eX/9+FEDlzFIw2SC
fk0j3+0nIzDNmuQdmpVCX28r5Ft1ZsxP3g5QMC6EOGD0E5CA5MGix4WuZTVJ
+bDEN89mDZy6IXE1Jt1yiR8AB2/gWdAbisK3ZppHpgzsZi52Ggg6agPfxUap
LW4EP4JWo7a2WSPIOsSX8Hels5C20EyRQ8aihE+IPGtYJ+y6HhV4+iugZjja
fHIK3BYkg/k2H0uSah1n02gyQIpVNs2Z/Szgkzl6A1ckwJFMhMEmzc2SFRX/
eE2BmCpNtupliiZln8ZPNm6ypdpd376xnRygBMynK9k75J9AypPVnFREED/1
aszsEJ2U/CZ8MU2bVLb5Er0f+UWOE9mSpeijU4Spvc0JmDDLgs4zWERZg7RZ
4zOeoW0dHZ4Pd3kGpFVWeGgL53dBvusexofk28zNB4cohmveJgE8eLL8MA5U
fMoly+2GtsgPrTWw0fnwCQ8sLdjBgZuBe3HHdJ72iRq150En7xugrgj6Kizy
v9kJY3/nvr2Tf4NTL6Q0zWfkwWlAri+XsFFfTeY5/ZLMVgWTEnZlFxB2Hu2M
K9TYkh/yi+EP6UV8DIEWSIqyN10NaVUWtr1pfGi+VBvv4OgQTMKulcczhFQS
tHmVzleZ+Bfcp6gbYOfZRxIWqHlM0QLzmvccLSzkcT+A5msbXEN8smKkmwAb
gcavUfGtVgWwk+IC1EmiYJrB2avjfsICE5a1KlGRBOJgEqfeleamtmc4VHDa
0Sxd3mhsyQpl1ZjGzMxBnW0uF1njYwLOlkPFjZShw4PnB04l4pn5h5yWnHKT
SjCgkCxFtYHBj9Xtt1qiQxeY1AzWhdYxTeZl+QFFOtoNtzBMoIn8ihsXDk02
X6SV8oohxU7/kmLcVKXCIv0g4gOt9uxjw/yNjIcC2WWOTEuHrz2EFAGM9AS2
qgQ+D+MCxkar27nVYsTRqvPoaRx0KuhVtwY5u8cfwpEoso/Jf12zBEC2juKP
fGMvuDEg+KPnfRUQdG7SOpJdVorMVhXxDmCpK1AQ0Vqoc7LcyGGBBiYde5Dr
oEE2nboDihOehOoQTqTkwSrVgUalqnHOjEZJmcgDuZjILxeSGmcz3IRy1SxX
jUo5PJek3w69PEFx8jKdpgs8U55ZHZULHLYu1Mvzoxd98pygX5iHQmfZqoXS
p980VdOFVplYHYsilxFaAUgBpIA56rOKpqMZYn8w0iWpFK9wpdw+voLRee2v
zlACoe94blTf3ceG6+oaKzunieAmghCEEzFwTv0xGJtKfLIXQLQZW5+XVbm6
YAt1Amytds4mdxSIFSIXevTxER+q7WTE3AQ9BiVyBz6p0geqH4uMxgYjh4mR
aceT8ZbdAS4D93SqLyQjsOO3Dk5HfTpx4TbzgUO3pLpKflO3aAG3ZlE6B1xW
1NwFO7Xp6WU55890Acm5mSItVjgG3jkU6OV8xfQlBzM+7LDE2tkVLGdJsouk
7yJvcHW5V4rUoKaKirMoSbByRQayYFxW7JUwrUg01nnG5sjQgTJYBIUdkutE
pl9WeBLC75VcJmh939DW6z5U2ZxVWzUmlSZccwPynSC/yMTlmKIDn/4uyvU9
5bXrxVEhN1GgZbwQZxJpc2rnM12RdxP5s2iEOE44nR/yJX3awY28tyb/aDkR
+xSMYz5X/abNPsgN7Jjsa57We9mLU09bwGxfvz/tD1oyRk7VxLgXQFRWF8Lw
RH1gbgizvSFVj9Yc6F7WkRc7dE/Vk0sQb9w+sV3DRkHlwzaNWu01Y/bdsx4/
z2tywEAb03xqXoHJyXriSPkUBHNPjvyWbr1+/f6oT6uqGoXyh8gXI4uAXeIS
4EZbSpcVw7nSjJTlXdLM8K3so4ohkR/eGVM3KJjQJChzdLIKBeKBzRt4hKlt
moPxrgFMeURZanxgmU63k3d0UrtpICQBpgC/mmF7wXYIY2YTR+091GZQu8W9
wjhLx+LImSDiUHMRJ2a4QPgkeYVon5z38FxZLJ7wcDpnjrPRdM5kW+Wg4NZe
pzfsxCIlAXtIJ5MV2GM3HBMO50xTafFPeP8ync/kT9CoV/O5+2NarlCO6p9s
JUzd36yv+AEVNp5Gp6NJL+C5egWPAQsEllTQ/uIizhFosJY5rdVoHCPB6R6R
MlINa+Qc8eqh5kORta0jXD3vohNtGI1YMpaBf8+JRNJmcsmWLB8ZdhCSrXaZ
xczfBUg9M2MqRQWCxGKVWnOdtVj4cKhqf+sRmCsqpcBTxTEfqcqqrCCbMO4a
drk6Jw8yJHUPbSO8dY1QpN1A52rQFukA5BIaiDzAT2ZInl6nibwQ9X5ydJhs
LTKgADLV1OOjh+ayLKewAd45NnB+MZE816VpfpqnF7SgjkXUa7TuPF5COb5G
eURnNraSFhcr5H9mttz37lO7h54r0cxo9j46rke+HIrUO2aw2VScK4YFHbmx
J1vHJ6dH/fWGg/jnvfxAFssNPiemdIjW4tbJ88O++CxwylcYVKRgIWvkcqC9
H7bNnCpje4TqyDSv4RAIak61pIKE8IVnFvDKJK9Ff3MaipWdPDr2ArqlEOcR
z17ChW5Q1o/QqF4BB+jMMcsZqp1oIRbATXCAeHQ4JNCyRlRxhvGzDpvGz4BM
o+jk1tEpWGQzIwws0I4kmgAXYNQLHT011vYftk+XBFJkxLod0GeylW9n2wPr
KSVuPZ2qrQvqQEajacmLmiwjCWvP1UCP/RUH6siu5zk1eg3bgwAM9VOQDkHB
zll2be0Ap5mMTkeedYT0ilMwE5MFh1MwxQEtkNWTdjTDqPp4rkAVUBfmIBrQ
I2pUW52fQq9egRYE5+Xs9JXzDsFQUPCQzzWZI3QLXSgYGklGJq5y7uIqJxpX
qTkyQiy1ALrMm9qoXXcFZThoLGtyIEGnl8fiYqmdSqt4i6HBW7DXAxheDhKm
AqEyQenArhDaYVSpCa1loiz4xcgCWY8NkNVCRrdGxyd9hbN6Xw9LzM/okmKO
tOCkLdTZf6xwM4a0yJ4sEozabsE2APNBPi202PUYbN0pbBchY05Hgyi8SuyN
49dlgItz1D3gbZamL7N0GtipvEZwJEHkR71jaLjXO0iK1WLMEYcP2Y0xs1VF
nc1pjmxxrw/qCcJEvESoumTzOYVKQ/hASl4IBu7AacxgbPu93khWMlycXu9b
2iH3bWRP4wrT2SYgUuw4C6P7KeEkFHbkWtw6fD9yig6ZgheEYcRIgKzxwGvn
YlAD7U9RM5wQKyKVPVBnmQsysyFHarxtvLZot3LcA3UW3nkG+Il/45Z+iI8i
Lm64y4wRIWegSQjnhNm+H/F8/qDzOdXOt/7w9tTN2WNlaJYwaJ5kkZywGGE1
rA4mdUofPhc5A3bmJWqbNEVBB5EobHwUAPrvmA2sLVJLlfEOEqkwrxFji6ZJ
0fXz98yhLfhxIPN0JJASe75cFVOUZWC9gY0I4qeY1kwC+K1+ACOiOBF1oREj
D91MtlRdreEX1nJfH75D1fGqnIOh03e9iwJVwzkjV0wyFcgakz+K+BJtArb9
QFCfGlpJvbcopn0kfX00pHwlkPWupoCpCBCMYr7oUq2qmwACH58UAW0EJhc2
6NbZvqwwAdwdZlRASDeMzkCwFUkDPR2NY4YDj+gijUKJk4hXESEUCFKsJE14
zSi8xeSckMZdG4QTBg6HZIbMwdh1Y8UtU2FOXFRUcPTEAAuHrTrV8DixW3yk
NroQ65TCIUmEAJcWWIuBlzm0BjcfRDExoDYnNZQO/Q7zMQEoi7Wnrus0UdQQ
uYq2EF/WMHUrTpVGdU8mcI8CbStGYCFD7ssSiSJY8aFGmJC+jAaX9HrJcBiB
vdFpoik4xABzfBca4KDAAUifFwImHrDryD6XmllYnI+My2Nxiizjw42zQ+d4
U/ohdCInUF92KlcNW1Vl8xvTCYOA21oc+QzauC8Dh9xOXvHOkwOSCMgP1D9G
HCJfIGoXCUAJd5F+zBerhRoOTm1GcOHAfavEWec/iALksJdeKWWLjEA1HHem
9VksV41Cs81oJP6wyBYIJ55mwG2ntaf4gKS73N2EWaybSPtxBuDAacdwTAj8
6Ji1RHt96M0M17jNLJZqIOdF2IEQcCT6xdsafjjQh7/Pp5PvL+0Bpk/miXqg
vBY9YAkKm7hI6w8BDsQCxIwpR0qbxX45ymadHo+PtA+DWjHgwGGwUfh4EKTF
7uA40MzVxd9O3pTmdDIjJP2JlAR83Oc8uQMv82WHrD1F1AcmevAoUzsHNwAf
LE4Zs8pAxZUBtXXvR3JdrubIWiiy7HiJqg2E7ndwYMKCrWg92EWvZHBL+6mg
hsNVGAigMFkDKJzQqKawqKVzTYGFAsY2g34yCwDlYC8GfudoAtGYZ5wlgP5L
dln7tDixSpVGcAWhI1w04ZOBNn8B8qrgySHtpg1hAuGcFwMNbsAizFZzgiPm
TX6BvamQ7AQ8DvUsVXn9AY/zcw9fhKHJymHAnD+Fw3kw1uDlbZoyHmEvaKJ0
wHZYlGO2re4ckIH2XuxKCWOrGR2YDfhw3JlQAds1OdOkYrzRHRLom7LuwoQc
SDtUSg3s24XdEbqKS3Z4dqCPkd8P0xE6EN7rOupCgwdBSlHECf7QcmNIDIt0
SvVJMCeEAwuPgerw1QgN7XcUTsWQketwjvaZ8G4eDfIPVBzCRwIPleyPy5ES
y3JLWdwQ8/GyWhmxIrblsTxCjfcH2mCxuvxeuwW+CwpaNp8GviudsXVefStB
0fa6GL8K9Hf69lD8CVuqODP87hDTp9FY9iEddkx0Ohjr1Zh0Vw5nosO33TFF
n6D3fLmaC0MJnJ6MurWu0IGBHqtvR4OqHBX6isEkbC119ogmzxxZFRANqs1t
f5ddkeWqQli0WFnixkdnYVVgbJsNqrPTV46mjCEchPxq4p2VV41odoRJW+vO
u2uviPN5uPiAJaumgHLAP61StlpkBC3j3LtmGAEHlDQ6Pkles6dHCMf7ssiS
xDQeJifzKKxROZmktSLYSGZ6ZxBqSDWqRk0+qRW6icz5g8iKhcsG5AiREpcH
p1HCg8UrD9OLoqwRqGTHoY9g8naYJMPUhFoAwtKyqcCdTwUTmZx6lOdIhEwH
6lmPUlsv1jBRUYruEshkSdIgl6/2aHClTv1fH8cOQZ4kHGm1BBvKiXKtlrlF
xY9GJkIUqKiyC1wnUbLSMMTIQkmxpRTEu6Jov+g6OrgJZi/R9rN6Kl13hS5R
jWo/6VzCGnHwhjQobbqoThFYM2/ixi7xRRlqOy1NqAAZNaGOXzIHxs8+3YdP
8UP+7Cd27CJIQd0thsGb6LbmCdHUTAjLKfji1NlOWiDc63I4vmlacoMyuOpL
ycX69AnLuoAkoFS1cyM+wrzcMCXAfZx9VC7aIaFgOf7zP//Tpd8HPw+SnWQ3
eZg8Sh4ne8mT1t+db/12eMf/Ot/68cWP8O9zdF/gX8n5yRH8+ywjqZn8ePzj
mr7sT/gXfdLreI0cpM5BbfLCIpKgdfm0n9zXxWfYkedq8ipJ5HqdAkA8KKJM
zS8xbl3MCJvfsDdB8K4F6LgY584Cvqi7W6inEQ1bAkugikNjGQjLrNCNVRYd
qTv8to8FE0lKkB3Z5It92GnQG5H7wWDG+RTO+ffomf0ePgUaPOOE3ank9pLP
lpvDM2sALszNaoFgsL+SMsg7FwstKmF/U4a6snhwsRPxlrNiS4m07NI1j6hy
vJVelfmUrBsEiaKvllG/2UIVEMwY5doZeLDamXukQ1OweceYFWE0MtWlBc41
F9datn2xPRCpbA5njRnzKK4JJXFxAdw3bdh89DEFzbtHzBhFy8MjTsigXFIT
FH+s7xDX8ERFnGNGrWDWUw9P1z4cXDQIcGdBcH+P336PXsPvl7BNO+IJIDKy
gBx3NOiE8qazg0RV4/CJrTfpHP/CPyigmCG+U2mX13QGKqZn1EK5i7wA/r+T
DOBzFhLXZTWt92G83yam0eSbruEnf/s//s9kB4N337pB0bKRXxT3Fh3noq6f
E209MqncQAMzM0D4wvaILluCbKBOh0hIndLuw0FIzeQEeX/4yn2C6fmNJMV3
PYtmfvT8C6IerxMiGSCQwmfCilgP5lirpzs36tcgWaLfOPOpaCMxjZ5sP9re
3d5lSpEl8Me3a4FfvxudJ2/enuupx7UGXr0PUsGRVWixaKYy05TyQXFHqT2V
o5KDn7tMHr8U53ZD1II8mQZUBUPYtt/Vl7hY48w/8SDJZ4msN9uoIXFshX/u
9HFmIn/2Qd7Z2VX88ZQ54mP8Kjg47d6JqEA2Oz4YJr5uJ+85/QC+W9MBaPLo
MhGT4oFUHeDHGFq8InmGzp/xjabubit+qVZ3j4tZqLoZSCZfKEK8zjIXsHLR
+hBcQZUt0PPhQYaBqwR94zAnwjC7RRYN8eozp4l5S14W4TvZx4YdwZTX+UuX
PaCtdvO+pR3J1f2XXu+1k+vOlY/KF6IxRKsdZZu7BADUhUq1SUUxz2ot7iHw
m0iUD9m6IOgAyXNU2KlsABYM++knYPy/hTVGFAK8gF+qquDjKsFw8PlWhRzf
kV8fSrMztWvYlQv6IqOzfX6bNO8N530f8dPmBvCek+ioAlBUW8QyPYHjsr4L
VWX8gCycyu+w2mbQgfSJY+Yvt7HRRTbNU2ZaJqLReISw82aPJKXjiDQEMkkS
jFo05aScJ1ujo1MpoYE11X76KVr5w9NklmXTMayWq3OG9XMOSVFlh859REjg
mUJkBAnu5B5KjHsD/i9KDvz97Pjf3p2cHR/h76OXB69euV968sTo5dt3r478
b/7Nw7evXx+/OeKXURIFH/XuvT740z1e/3tvT89P3sIC32v514h98hpxJgBm
zaGJ3AvUp+cw6Z1HvChYyw5sPF6gnSdYTQPhjVL5A5MJ+U8MYPTQ35CSW4+E
drrMmxSDMc6qS9F3jMcOdmNGmUfkEMMANBUBzVNd0U/3p/4J5Fvw/U90Xu2b
cDjDWi8u7Yir3LC54Z9n6gPZ/OmT/xgzXq4msPPkOfPlP+yLUteDi2S0DBVu
DlpwiF37rjPliTWb0YpNHszIcTs8Ja4yEpvprSH3egfsaUZtbR/ZKIdC/ely
Mew4zmNhJBMwmqY+qu84dZQPg+EWBuZgFDSbrCh+jlHKALo3EKg2eQ8wh5BC
jBjHCNCCMPmDNZgGzoCh+bCREQCrFIIg3/WiugwKgwoANeoXqn26UoC66fFT
ETLIqeoMkWMWHARJeM0l8oGVMfKmdj5sijOHdoxwN1JyyQGitR0EFYk0y3h2
TAHQGFSPo5sWjRmVK+S8YJG7NmRkqzHqQGuK0dSYYsQRHPGB42T4+bB7noNL
2/Y7gIf88Pyd4+F+Z9dHhuIVs6ESCQsJdm7QRVr4hsRa/IuD9UiqdvMp5e40
cRu1dbvjxNC5T+NswkY4EQ0NUmzFvFPcrHnHh2ZbI9925SWoqABjkrcOz5/j
OhXJm49vBOJbzoKEOnISe3ONwQHO+YAp9bXbOAfVY9kPjUv9JFu8IBoImbQw
jne0X/AKNmUTBRmwGDpbqGUk1UvgYanF1HvqoTESFISTwRjEkFZVelMP+FxI
b8Hri7IoqVnvVKVng2YpGjF1WWfSQ0bRAaTbOeYnLudpIecnZi4+p9FlGssg
YHWOBOtszkoMfyZDm5NbxjeectMW34vaSp4b3DQ2LDjqy3IuHufo8AcRnYEm
iFYZnRHK2cRydPQpCPZ5emN4uubkXN4skftTpoCxtxUr4AA4h7bmm7MgYA43
RboAmXZGgKiD6V9WdSM5IWcHNAtJivc5H3oKfAZBvILwbF5WnNxV8tukZkgG
LNcLUW7jFlg7EABiCOI2yiGJ7BsBrxd351++tEvkA49i6iRbL8+OaKLBUuoC
cu4Zzdkb/xaiVBbic6lyDfMyiEnZeCQ06qSs7NdGfChnK3wWvUvjTgmNgGlM
mDoTcp/9gEthZSVXrKlF2cK7PBGbv/ajx5HGuCnSMqyLh86+dS85awza+/7N
u3NomdBRfMDY19MB8HKrR4aeg8mCYtukH7JCwTGxRCe8HK34XENogetTDofj
rKmpJWHLJjg6xSg9s89NSpDepdKkhXpYjenuqlygjKc6NyjrelSB5aZhqnKw
TEKQmLRSp4MUydnz0Smr/TUVDGN8ToYEkFY3G8yAhMKoU+9xCic2UxZDJI6W
VhEza5SfLbJ6Y3yCqtV6H5V9M3Q1erRsG+G6qSq5iSaJNl+VtdSxWLFM49CD
0yXpSFiF0gzdgBBg4G8PaeBKr56BdqnyDi4LqwH7AiN3zkVWKc1bLt5JxWJR
2XETEbIBTY3UeMllW/N+rga3MGhnu3QnBvk6IgIGKevcEnpXD4W2zaVR4pTt
4Ettz+mjbN7EcyNPAwKynTr4OZMgwNB18hy5r8k3YGfJFp6xO6kt9dlfPgDC
R1m3GFpNl7VUA6IYtTsD7OmWx3KaYbZYovSoRLGylgfCJqjeOXMF8jXeQvhW
j1aWUWN1p7H0HFpVXt2lhr3XedukanQkY3z584gGTfsUsiSDtdZsh3WHshHk
OilCGuD73FM8wj/3O/a2yVt6sAIhyTWKmIPQhPK7zEUBKZh4JQBkXCUli8gh
h+GuHKuUd8AdoAcy1jzsAfX/CT1C4wANebUotHZN9GVVXicWLCE9yUu3dniZ
XrEefJlRHbLATy2fdUz/Op8itsZprlgUK6ILv3M6HBjmPhXX2ng0G3Ygy8KD
CmbAH7VM4HPdWiJ2h+bg84J1KVVbdyMLiskFpOL1MnowJfNnSihg44qZE2Qc
nkiqtCZXyoRYDWoxOBiXIEHkGCJfbmsxDdpTrSR3GpSd9Xtbo3/uq0U6CmV1
gHCoxMexgqS/NoJPlHdfaQILcZou1xaBc1yAwvv9rYrpzpH6s1j1sepD3XKV
im/OuuZGxo9HXscjeZaceOyf+6nXe42e6eHBdWrq0h8L/9h6ffDmmNhfId84
2LlLTOlxkfZx+XGgcM4rYumYguoTrMugwPuQ1xoBv9fpTc/Zw+mSVAdy6Fdk
FiscOCqNaRFD4ujqiTZsv8INASLinF4+AHmlPBa1v+Rbn1FJuCm8xeD8MiiL
kSa4DMlFSQWHbkqqWI45HnB8V1w2x01FdobSOegtySPBTCpaYo0faIWAZItx
CPDMPEsr8jkLQlwnQRq1mKduATigIAZVfyBVBUTUNqZbuisKdS/UjHAPXcbf
CEtm8nptjeDffYEtuYINVMiIdgGnQm4YXxKFK8pqWIb7mqIZjORqXbSEg6F8
lmDoWh6OYui+dNssWjhs0vWCBfs4KUYreyN+0NEIrOcHKt5NjIT1yRuhgQWj
wLGAs7Z2zYW851x1XkoooenJWglnccFiUPE7MKaw6LgYcqsa9Ri8HkJd6gcz
qhWmfgDpYyArt4A9gEFcV3mTcZTGLByVm2Dhr8UzS0fJ6nGN0UkOHMAODxeK
Q5tEda/QGxmYJqyCqgNTPLmuIIy1W6NXGNRvB0DohIcmTqr+TVZqtfBnxLtM
9IyH/G7Y5As5fGzQOgchrgN+WTdAJZJ2QZw0D1EIPiPDBTB5sShwd12YQKJd
JquVdyySE2hBENADCAN3a+qVpUDZt06goExB4JKUHQj9vPHOu1WWIx8PThWm
InCX+IHlVVy8AGwER2n7sLGZ1Ojfe7znyu6rNTIpl1mXJ6Kw5Eq1HLii7tTV
4KR4ckqBIlMlmke/SJ2qGMQDfHrBaswygxIUgggtb9u5pTU9XCQ3JlJnhoan
Wr5qu/TGVk5FPlbz0tRZ7PuJ41L6sLG0HiGEmtaYmF2KASeWjhshhx7T2B+h
tOOIFER1FGq83+sdvEv+SzGul19v8u/ExNzg1dPPetXM+pSGhC2MNmpircMS
mjj/nCZQLvsqgSOXMdLrPf+MuUiLz3NXSewq6/UOn59tNpJDzft9Dnt9BrIe
3j19nmz6ctt9Du+fbzb+pBVywXc3I4EkjpLAq+83XPyuoFivh1U/Nnq9O2rQ
6708O9qsgdv92dDQaMOJBA2xQzAZTS4zOPDYzsnnUxGV5GGf8obPE/GkRYa4
+SPlvjApYP6Xvd6r0YaL+op0khEojxTnZnqE98/P7jrXyasSq8ej/XIWV1sB
I+D1+7t2ZaOyc9DSplN5XXbNBDnhRq+v9f72ep/D4qS1U8MTTt8ebjaEDjco
vA3s8fNej5jjv30Whw6KP7uWQKCjK+yOd9c6BuH1P2y4iyMRbn94ftbrjQ42
PA8jjqMe8EU+Zzh6znDa7O0NauNAc2+P7poDMgM8h29nyRG6G58TenS0qYDr
dhlCAxucxtElaENrj+P7TcXSe3W2e7GEfoLN3m3dlNFDpFPHlcgI5oGP5VP+
kMFN+LCk5rwjENp9eZY/pM8kI0NwiMZ+16zKln7rjJlkC6EdeSGor0+f8PJk
fq2Na+orhjlCPjqMlaSAlLMee/I0pzPFBLqCM84RypH5ghDxjU7bPBfrYthy
Tp+sachCd4gHM0nUeKnIWK+tSdYBDlHq3/oafHZtYAnSZe0uPtK0gbAWCicL
cbbQg458nJ2Oz3Y7PnsoLYTpRE+TZ5/zWW+TZKNNkpF+fP/N7o+nP/63H5Pk
8BD/fv0jjfL0XHKTZNSxiu9yl77cSLqSnOTHm6nrf36dkdQ3BUJOClfYvVxV
iGIajc6wwr6H7rdG8s0v/F9rTQjSkI9X5HXTcRxG46jba3LbwibJNvzc+sCX
WtjuNDvD6g6se+vPwq2+c5lohkl5duHYjSkxVHJp7yb2l3VmRBKfzAhWwu4V
TLd5nVYfmLskW6/7Jh8MY1eu0HhKdUzoAlGNXVo0GlZOctmYri6j8QmYa+zY
y2aq7Ygn1FSzeC25Yz2G8ek1g43UDrbVYRvEN92gv1MxRFg9kAEKKoM4U+n0
HGb3xOV3nHP8FbRHLaoY3ZVIPlNXSbKg6oYBAD2nShxUL3a9X0MCO/O5FAbx
zLiHwQn1l4YDCcfgHbG+lCvHQXu2TIK5eWKalCKWpgJauk5vbITyDTO2rdEb
3HGXKaYVtLRyCRMVuRhot0In4bkyqv3k4W6wrqG3TahOa45T6WakU/eAy/0m
nzqWEH32IPnw8odkQkhAArMRqlyQ7njNXeS2u0w5PTtfCBZIb1ssZ851J27y
qMpg6W/VRPXR+VH6gw7HoY7CzCd8wKSx+zh6+8SEIS6bI6ZZkeLVxiEtXCI+
UZY9/7Hiwwi2oyDV7SybZDl6oHn0Woc8HLcedK7deqNoqkGSoa/WQSJs1SbJ
lXYYF156O+CkNH5CmbYfe/DkGg8l0uxtQslS3jvN2FSvPVEbPx2EfOQG45AH
x8UYNc6M3QR1ZQk8klau0iU/Zj3RPao9wAe4rdnKNx3abV4Bk0WQKSMjNNJo
MsCt+1kSw3z0vrPgSJRGLiLEFut0/kXRbbdeDDDLbuByspEhHPe1+Vbac5C+
HqbVg1KZV16tjOFddrS+yjQvBqaFswvfI2i27FXP6FW9qPsJY8cFI4OXHcJR
VqC1Xa7ofp9xNknxJERpVFRIvDK9K3balBW2hXsFdVNoYQS9jM01gMyMioya
zEb4zk8q1atN/di3k9dllQ31g8YM8vXBn5D9jDO6DxMOacP3N6R043DkQp6X
NdstsBCY0NrVYkSuI48MtsTqPyZaRU+gD164BKqOS8YN0jgwRPg6MOZLYajN
EkhI704mGplHkp2TAp3bOyB/pqYmGvKa4QV60W+TUYg0kXHsoyNXi2pGYJRo
EP4+lvjURLmvUsLslsJBsWHqQURt25fHLUeReOhvO9zwCPrtm8n4a74xeuLj
YRy/wM8siv8zhkPWJg3iRWCfMuL+xbt+uKIO99CG+mzep0mGJ1CD2Urq9lSs
Zs4yChcMS//G+yok6ISezfFxqYGaBWTqIEd8N61tvcd2XnqyBceglEJyKiim
VT9M96CKbq7I/M7eEJXlo7dvXslJwFiUgi0IM00ho34HNerwCCm3FXzla4kg
34not29VtjTITo8LmvBKDovLinYDDRw0jn6xU+GX+xS+hPlszU2/X8ac5P/Q
5myZXesbc/NLj+Pn/PzY3UY3oXxeG19iHMHPl1iP/e3tbU0aFRnDNfPNOL68
FwBFUVCQJl3DmJwfwJwelmT+mAtQWdLWBlHBheDqDDDwGIlSm1jJ2KQih8F8
i+PsPONsf9VoZQ0X6cfhtCyGKFyRfTnu9ukTF0NK5863XfPF9GHmP5tZhn2p
jeVmpmzLwcLhYaeLtUdns5LSzoIkMjHfpy3bgZeatiZmS1A86HcPWYplyLBV
8rQFb42St6aiYwli6FA+gsxZ+5zWxiFFd7py1xxFye+gSSFzZtfxIigR4KF2
i7J2Dpy4Fom7epYxZni1NWU7c3HwEvRMBhdgHSJMZQVr89SBGrI6xLZE+oIg
TRq/UgrV8G8RDD3UQg7ebSfHqYGmaEUa725KaRhdAPIQccF0a3CWOnB6mDo7
FYSLlCXiwfFVDC20C8/+NmE/+Axpz3fjWJHP5gSqt9883usH4h8tRJfsGc2w
jsVvuhpeTln0SvmvXyp5f7Hg/QLyjti7Wawtt1DCvu9g/z9uMIq7m/gCwi5s
4tad/buNov2z6Y7c8rOBwP3y8rZD4BadgCQVt3Ja1B9jy71Fmry0xSwj9Klz
sZkX5MJWWRZWJ2rc91rOzXAjK8bca5gA8jV7Pri0VFfbO9yzsYlbjzzeE4s4
8EboY+QKIg9G3YRPSFEq8mK2h1pH9XUCz1HXGjivehwZ/baNpD6AflvAdV57
AnA6/5V32nDlX4IYY509j4pkHJ01Y18CV73iCg7YogURtuSjyfJsIhdVp5Ev
6Znm+lZNtPKviizuQObLaA9OnbShheQ7KtwNEXQZb4tVaFlPeVjKu3Y8Z9Ih
v04udS3IB1MiNCJdUGaeJlO5lS/HemMYDWqWS6o9Jjd6j5sLa2PlQinvgtIb
QdPoyPXwXF8zz71OVr2401x13WWK0KHzd9wktgB9Yvk/fI8TAoIgON2+q0tn
1Y4X79b7DOCFOlDpigzh718nXKSJVwCXFx2D2qDW7Kf9+jbpSAk4mVGdN3F6
Yd7yilJTpXkFWZ7S9S+s+9nrd9TDh0cQi6EsuBYP1a6gukvsuJZYCF3fgCk3
S7kPBiu9iK6jAFIqFYfxkaD8+36y009OuCwV4+55dKdfJ7vdXwg8XsC5f/vr
f5cNRP/j3/76P/TwSZ44AfRJH9Ur4/k+6OwjaVJC+wenJ4PkYR+vqJdEElsV
1nXNpJ59JPwWH8INkpJ9zZnaTKPetn74+LB42g+Vvp/lioncOfLeqkD7LJNK
nzZUsq4ZuYjKpphqlVD43cPT80JiCltBiViMBKHKwar9eGWLe3QwtMgNFUau
mjqbz2xFkQ63UYdySosN9u00cA/9f0ZHtRqQ/HedLwifRxck7+AX0ojard6h
p8U/XaNwX7rtvauJfxEddYMV9zpmS7ckrY54h1Ux31neYRVNQ/lrBIZnRnRC
2XKMzgyyBr18RM4kv4LFX4q+6D+1ViaUstttw/hE3CbLfCL3zGSLJQgSpBrO
RWsrDzhtGhgwcOJbVGfeXxQfpTdEGJEWg0WJyqnMVG6X2Tl3MMYkZC7Z8A9y
gnVovVgRpNML9tkurjXuikRzGpu7pZJq4B0esjW2xWe6yG5xw902dLph6+7h
Dz9zkNi1RpBRpeKyQ11tBKp0grVtscYzZ+rsPX78cG/7i7v+vsB2ksr/SxeV
YUfjzEvtfEGJkw2mOf+amkfyL6B5wCJ2aR//BMrHrxIRUvXDKgP2RxQFJ89/
VgQkbvNfKSK0yXxV+t/lVyKhj9dVJSc11tn2ukE3MBR+NtIZIppFvWFztSEm
+P/fqQ60CtflqkHmPocFEH7NF3ExMsg79jSxWW4ECf0sPXG2z1NYJZZPfLJ2
SEzy77uuJFV+QYWK9C61UIT0+LY4Hzf6J2FDX4AL3XLoDBZ6/c+Xs4FuCRaY
UcoWjkL2+OVGEXbz8ujM9nLLOmw6iriHozBcv8aM2qb/bfbzZYy5WFD8vOUM
xv2jnrlRW7YF38uqf6lNjVr9GWuxdhPpR9o/Wgu8+Pts6ucReOfP3z8EBDr0
cczWBfx26EtvmVfOgcvHgrhus+0XxLaNXPZCpadiBt75R4qZ2Ez5nzJm3c/f
WcYoZ8at+VVGEfYTcsNgrTqk0Bcfxc/66WRHoUS7i7t9YTG1prsvsBb7/tdO
+fXr0MXur6l7dIusL+wF/hV35B+CVOgSVd0yCn/Wy6nbhJQTSQJNa8OxawdK
k2Bor9f10NaLd3VfwFIN17uyt7hpBJaL+rUh8livCqO9y3mQkTPAcqZ1PpY7
RlHiTkq6Y5oBbhXd6wti8CK4zE/uG8d8Hn8RS3gHQRCx6ypFam93EJ8U9ZD6
TAnMx5LWw7QZ14vPDWMXYNBo5a6yubWaEKwtPVSUkuZi760xV6RTz6ZYEot3
6nmcNddZVlgHIV5Tb6+Pw1Lff0S/eRo4W82NdIJk5+Lh0i9s+kAu1orSjlL7
qlmwOI7un8LVfHdHkP3FO655FkTZbX6ARNxfvDMp9UEmXpg/QmAIqUYLbYdZ
ia56mO5t14zIKwuv/hoYfzm9pDY86esCeLQRlbRC0hz8Mvw/t+sTVAK36Gw1
lG/+mfyhX0oAtvWzJxYw6Jcb//Zh2v6XYfokvaJW7xBF8Q82sV7sbtzE2i89
YfzsJr7AKPjnX1aSy0+Xi/jFOyePzUnbAG3YBTK8G+v3RB6SpjvzOtuvNXe8
ERYKGdzOLwkJ+a4r7RSWY4ThV+J0x/obFhxmfvZi5efWwaa0gstttxrzT8RW
bnm0g8TW/vw4+vEY6E9GKXUj1ra7wWXFnTQDSxddUeynvuaSYr/asomtxMaR
qfFAWoCIwR12uo+k9kIQ2mvkFpJOST8Qme01DpY6bkBKzXoBcfeDJtF5HUEl
POB2sxoRdQNd04IXfH6qUU5/dBVl1xIddyxRVkw3WiBSxLqmbRen9dDPWoxA
57tlcH5KHUvBFG5vE3YsRal/PQth/nTbHP5hgI5ufrUxoEPBEHJaDEZgZxO0
B2/aHalNXfT7a+c2uQth2hPbHPzAs0N1mUDUXfOwb0rSemNycV68+9qcmRGd
ar2Q4RivgQmaADvAUO1OAPpw/NBLIz0qVhzNYtvubm7kAMx5zOjq2KYk04l4
k6uczXq4v7KTpmRuoSVcK9uJXc8fR88PREfQWvt8bwKyJwyJCr/bYE4YSR0j
HptLOK8mbKydd8Dbb2lFmJBLpULxjYjfPGZXA8J+gIXPJR1C7EmMJdmoX3vl
VbfG42q4xaxTisD7b3w1fquNtCWtf4Hw5qZJS+Z0ZwnzGGeBzstaGLADhgtO
Xi77pbQLf9luV4U3XNR25eDOqtBc56Nj4VaF3Hge3IcWjAtGi/4Xqjl1UaWT
bLZCKqNyS5Q1V6L3qjElNYgB+PcLvq5rukSAO19mR1XasaaFg24Z3aAY7oTH
0ngrONVgy/faN/KMStbk/kwnRcuboxQqowMSP5HbECap3twOhDjOp2Cs863V
kq4TUGQkL3eo/IyoBf4qlau8nGuCC12wIGKJi35KKSYqRACsFV1uWKjEZj0O
QhlxMK6PuPaPiIKBv75SAFS9btmnADK9cuuqDdjSF3ua6fgqM8tWaJpQMWxM
VmY3Cboq4rYO2C0y1kohnuO//7n49+909iLdZPYoJP2wBusEI675neIvFO79
oPeoYVGjB3y1CMpC95QbZU/WtCXU/XhBDe/9FjNCinDiehG4WXBtOatu5GC4
L8GM6Fx5M4MHPDYkUNcLDRq+oJocZnGKzrXgo6AMiK8ypFQo6J0WxjFrs2r7
1iyDaUKXfy6+S775hn8b7nw38DYQv0ffu9/hiZ5/fUve/9a9TpxZPh36T3+X
PNx9sve0f3fryW/br3f0+LuOHvGPob797Tef0yUhTu2AdRQ/Z7Kf0/VQmu0Y
xnf9nzPvz1hp27fvk1I9XhB8mHOaff4bX3dfrKE9qs1jT2hAsvrFAgnfWGhp
wMXkGPuPFonJRW9fbvBbtrUivuBOlOl00M1OwzscwumKzoV3bPHtZr5X26FI
6I3nyMDoLJ5ka26wgd923mHD5iVdeutV2VaWInwALXRNFvPQfPKjv6mIh08L
BW8SoG9cl/NV43MlJ1kQx8BBCN+XZji3El4PNh8Fp8+GXT+zc064h/+7QBTe
E4WXI7gakw4+3zE2x+DDKfE7GyxY53JxaYNwPkVGGiXoOZzfh0BNtI+c+kKZ
f+wgE9ijBjH0bkHsoDXQxtAfBXVwPaVAJWt5IN+IFoNCEubuwGk2R7VOLucw
iuJ2eBtPqtcaJQu6fAw7kZudoqxXGJ2UQvM3dSRaBzkozejqEXLtJ3OXjyyx
RD9Iq9MwkRuR1zAxepkOW7UaCe065LgiXgmfUwnLyEqlG44mGYc9a3/Jp8TH
0mmOpTOu0nxOKkCkTW/L4dI2Ffe+dlw87LLKLxDjiqvSILjfXf5XY/Yup/ma
ZRL8v05lnM00efPWBSBbMV4CZZltFgLHaVUPbjkRl1m4zT9vAJztTcSHu71I
3ZVUDV0mVQWeBPatXKRLd+5aY0OaLyeTFcaOqW75aVBR5WyF971xFTzzOX3s
CpKrbAqLsVT0Kl3fuC+K3uZ5Qh2adDkLxEUAhjZRYKkO2JFwvk6y3eEaImZa
OzXwF4zMVhgwl9ncJnHtLUozKWkTZZLfUfNFAr9NecG8jLwn9m4g5gx+Ai6b
HMe2Klxu/GfU2onYX0eRHXftnSkHO6UrxDAbPK5PSw65gPuxq6e5WeJlJMBk
eACa8s+Fe8ZB2hfNO2S2irAQ2xTvZ9OsenN5F+0DFeCJ5yGboO5aBm5kTHAw
CtcYX0x2lWfXZPYPNt81GjQXKXCX5NoRkMxzq4CCpjVGd5fXIksLgqHUIZpz
TdMCp3Dcm4sXYqFghRCgbgWHJqoAKJOxRUfb+BeZXlDPmLjPUTYMyexUbjQn
z0AWfCdfCRu6yApK9tcLB8cZ2N1TIKqoQb69+CJrYpa8Ci5VsFdfFfYUI40t
U/YTLaK0/ju0G/G+toakt7ajUyIoQ4AJJVkxpXrQpK6h6IotAtBuJ1W+5LrA
l7rbNaqNaQtuCwcvb1gYBz0JE0zqCcxKVEuKxMjuYFNUREQv4JJbk0WyETvL
C/yo47YunR+PdExCGAbP6ZrSkn3NVVoWkIs8YjQw9kjmevEY8gJygHMFVTgM
MJ8lFmP+Qa77im+Q9kNJ5xclXVbGip2eYvTbUb1yKsuO+7/I8FrBvF5Ia6z1
ScF1UDrSC9ZOSeKR1uUv0x0k0xVf2sllyWFGU/rdktpW6pxSPhup67Y1dcgG
WJ++1ELGCxqnsLSl14s4NveRqkOgYjwzJakHySzF24dqz5I9J8upFjlDbIA7
pzehZcAVxumpaijHI7o+YeDOOHdDzM5cGiiAPe/TRA+zKCmqLuJdjkgGDyig
/1iyHPFi5IGWl8ED6bVwOY3bvnTZPP+Q2UK3m3f6eA9b3dsNeg1CPp1d80k3
fl8KAtS2+Ineju6qm6ykHXTngjqN7lM6X1bh4F34S06lj8W3iDRzlU9XQqdy
lylTSQn98RkxFXxIIWqrMR4F1q0mqXe45ovjIpe9Bynm9qSviqlENWCdVgtm
U1ryphIj7u45BjyYqHsCx0prJU9z0IW5jopIX6BNrHuCN5WtX3BicJ+76jxt
OfZ5uCRsbFziWYU2OCDXUZ28JQDkjnlTpV4YOY0Q5OwSz/atw/pa/doDdaDI
9cgwNlSmGh1zfQdR8VMMEewQn/5raAWLh7comtonbry+k66mueJ3ScWXqngh
mvRDdkt7XHdpQtWE9AibkSppwtrQ7QeY9j114EG66Rn+618QG9EFK7H0kx4G
kv/Q9RjGfpdAl5o8oZrvC+/coWgYnBMDVVtIzjzrqr9t79WMop3m/dwNj6V7
q51BEmSrB/gEDUvnFcNkZ+WKyB2z3EUd3sTWu31i3beFalGn0B/jp+IWd+3U
4zhXEGYyMUN3k+/S4GlMq0HRurA+gfoJZN/FDvA4Ls8fTXXw23d5Td3wATmn
LCG5BWDvwot3AqfmCDtHb72D0FWx7oyILnUJCEYTNHX8eU3RRex8ATypJ1bQ
BKRoqlLZWY1tLJ/OIUzbog0s3kG0Ql7/MAhs2ySo3XIpCIOuMLubrYIB6R2s
XCfRTpl94FnpfH5tBUUJmseIQr4xp4nuRiFNJYhjBWFB17PG6j3WoKPDNh2a
ivF/XH+GbYjyFnEmdTRqqtuorCGuvt7ylwgTsnywQgEPEgFrzXdqW4m7kLmt
1Rhx74wDf4N9yz67Zdpdbqq2ZeN8nIs0L9yKGxVBAjixhkj3G12XRgiB9IEl
2+8QT7iI/i+YHywYiiS6B/6k9TiJMe8vpj6XqqlJ63jD9LZcvt7qcNAt/Rht
g41npjKOe2tIAxvKwLDcTKZaLt6UDUyzmpIzQmgymnmkXtZoPNQMscBngoiC
n5FeNe4IZI2m1Ul/AW+guYnBciuZe/Vbz21wJj1QAShvIg4ffEpan8VAB0QH
tPYQ+S+6yZp8LhpvZ4yIaVTSXVwV0zBqFIEd6jvnV6+PLwUzbR8bNKLXkRSS
I4ryf6HpxJ6XwOQBJR1bnWLEg4741G1XXtsJxiU92/2QuzyUkLfPyQmKduFa
T37iGvD6wbrW1MPVZdUSfwSDjTzHoQo2k1W56/ANonAas0p+8/Zxef+Gn8Rd
Y9ZGnaeewogpipmQkGByv/tfhsNkJHz6STIcfssBkeASV1/IPzGXA/GXpsg/
snfD9UMIr14K4N3cCJpLFkA45kYl/yVv8ChjuXZkHH6nVdmUoFclW6Oj0z7f
Tff06d4eXzIg5mOJNwjKxV1LdkORU4xUVbTh4F26KdD1F8I0ibL4it97RK33
2OnP8tncMydBfDKpqbRWnRXiWZBRWHPRtR3eVCe9YdMK1cKSwxLGq9UZmlAV
L+2Bbo9VzLf20IdvUeGsNZBr1KprbJp3fuBmZVacXIouoVBu3Vmh9FnAsk8u
U1JXK3Q8THTUHc2YkDKci1XON3TJBZF41d9HDuxgeBch3Olcru7jXRVnNhr1
REEU6+AIDpL9V6DtXFPa5+mcCtnWWYbXzUyXZSoX+16scr67UKtM6/mQmyZp
yHbEMri31P4BtU92Uut8bO/ICbmfvKatII0T5HqOkRN6hvB8JTWubnq3++RD
y7mSLkZsfcRnVQRFiYNL6VBtwm4KeHb/c68nX/dvumCz1xutxs0vbDu7mqBq
w4AEs6r7yZuvDnq9t+1zv69XVg5zUKLmIBHn9FtTlnNQ9Ol3lA2wbldD/zUL
jXpZ669L/2ud5YNO6cWfTSmKMgTGORSl3HwySZd4WfSMD+2a60vYfzwjoQ58
pN/rHReiHxKcfCpiEVFK3/LJoYXFk4yXaWhqqHNEYXdXQEGogG0BB0vwes0+
3dU5WVVYGLmj3RHRuj4Bw8Ki6/Duf4Of7V4CShQMl0T0OJ93tMFbcroaz/P6
Esv+2TLs1IMcKrcc2jpjqN8fIpvEulpTf1Nj0jvo5LBExMyxGkolwfYPihvL
kPnpKiNsIfwJTQ7HKfJSvgEW3Xn5BL+74qRon5hu7yXumiYMy/q7HLxcFwH2
FTr8LwmK4jn6xirCWZWcczzhQM8MfTxZcPcub0STLVGR+WNWYEb5Vt1k19nv
6d/bZXXRl70oUAat8K7H/eTw7evXb9/gUUG5MuHFQg8Kfy1DXjWXZbVPG82/
179JDnhsmRetwbb3Di/Jc09XJ6O7oaIhnhyfv0j+/XfpVTMBfvP7PGtmOLR/
/7bF1HYdU3OH1cjFI0f1yttax6PXu+tAy6lAD0fAdwUyLRIRm5BsKWzDX6wm
YWlnNvnbSMWSsZEj+mbAQHMnAWp/gfEmHYV2GFcgr7eJgl+X/kJDpXluOZic
LUyJEJ0GsSocREMiE4h4xvHI7ktQOTinqgzHD+1S77s0Nf+ZIsT8JUpeL3Yo
Y5zdczhldB2zvNt3USugdfLeb7vmNV7g9ivUXlK/IQM7FG1QYdTeTcnPfJ9P
Jyp7R6cj6g9ZjGtNwFe4+BhDFBYAw1HfVZNNLotyXl44PcrewCx4EeZlxIVh
DtCR8KjwFgl3o4MZ3MDmR4jWdcnhwiovq9wUpuCCh+HdluSFIxcOK+bsQ7QT
ZL3G3E9pFkZsvS1zfSkO7xqtHQQ4gXIPOvYkK1IYS93HsgvoUxSvQO3utkVM
0kBzlTqzOrTCfkwSA7uzMBsMStTpDNEPmeqUh+9HEu6RdBPM7z0dMUw+XM0o
cdL1NiJE26mgwOQFKutRc1lIPyvVthfplGNDr1PfBx1i+oBbXEYt9no9ZU3+
5Ognt52bZw8wdT9Kq6EXk4fu7ix2fou9UZUfCacGKzU6Ss7fo6MTwaTkDMPY
AXIJut+6/lpUiwakUJ0svU7LVzof4ACAZr7U8XTzXXs46YmuoylXb7sWvPZq
r0kGbUqVD9g2kkxr8Nzb2GJLz2ttBBu2s3Q1b2TRVZcCpu/fCmiL8KS1Ps+G
B5xBIFlQe2pD8wYI16FzbtiqygeaP58wcksSIEwDk/IpAVvZ+85OAWpMOBLy
e7402F18EvYpPWWyfYpWcR/DPoUyVy5ONRsF1AAUtveIwaE4oi3VBKhayZ9B
sXi09+jpd32fXOQyPdIEXgwKR2tNnTFhiesPbXoyIQyMRnbWKHHVBGKxKLNB
cvz+UsL7/pO55kJ/zglA/wsf7e4j4Nq/7OrR+ewVnxKg9rAyVa/XoiNvE/in
BbPZGnl709MOTSS6zKlNuZ5bMN8PACW7AaJk+//5v8XJtdlhFElZO06k4Fx1
Kerb2x1L0Zk67Nz07RPWmroOSSDj7qAELAJ6dtbiBovPuaNr9rQNYfYycca4
pmEJdiWRShCLma1pUYt4BDGs6JCi0yUdKo5hmmz9ZvCbPl3mgy/cfoTJI4Zn
+Kef4kPsvU13zTWNdFJvLjzc3t3eMYWN3GIvP2exnXT+Umvd2eA/w1LfNdPb
V3q3a6XrLN98pS3wGQHFC8Q2X2jikIbxrKYXePpqZbJGNVJHM6pjFaNhY8Ms
bMPLt1bYMBiSgivRsseHV5WTPUy1tN3IvBxMFHr3hgUYXnjfFTn/JuXSe1eD
XuIV//TpPXxP6/vtP5RcwmyX24bZld104qGLGJYrSjcq8bggvrFEZ4b5O1iY
4EJ11OBh7w+JisjRBRKV1OvglcK74BSaCJNSMCW7ea3Hx5ksJFwtQhtrQKC2
hBTn7+ejW2jFAKojEiKbeJ+WAy8vk0zzq7wqi4UIFsl7MSYXLOuEomEi8cE4
WIjTqS5X1YTA60C4qfgFYB1rHD6Fa+rkohQLgFJIkETVGp3ns8yWknPUyhiF
+QLz5/PYk17b9aTaAPkHPFKyMrOVDEO0xoRDY37NXRGF1KVB+cnCoaNAKywG
ZjNQBj5u0mU2X7IBV6eklo4VYyyGDDINZiFcXViEMZrAakyjn37AeRPYwqq4
TrmGIOhdiHytmU53+1rhko93mwV1wvXlwl9T1cFPWaClJubls4jAPr8MVnRL
6kPMy5qmlC8c1peZEqVTBY3UkW8A22zSi77WSIG9xFCmAluC3hiB41CevOQw
+r9gScNLXmxixWMJ3GIQC23TzpioWl2uPZ/nCSzqwEWL/E0vnRn5GJgyGWLm
7hxuppXbZT1F3dk/UQC6jYAPG+xH2fxNJLlad4Wys81YZ9EbYXQRli1frBZ3
JpR2l0eQyXJstG+i7O0UZV4vYgvw23OtB8AfKwSOvupYVIrYanaue6i9vm05
1AHP0SUzhU07lX1M135i1X3nN1ij2Xd3d4u+/8CTbxxo6dJSOOanPlaJG9lL
hNajTrxuSK3frtzpAt0KfVDCkS6Qpy/TYnJDxTTD3vp3jW+dIre3bj/j1dp4
Tx/tPnv0bO/J7rPHnRvbvX1qbVF+ZAvY1Xkc7SueQDoX9oGqiXdRVWvSd1BW
p6qzyWKGzpvPojS+lUbmI94KgV1Trh1KfipgSL6+ZSVXa2HT0xBUziA3mpVP
CoaPrrM5Wqm9MA5513FxzjXn2PAO3TCLCncsXABzpe868CJ8mrVPWWJu6zXI
PT8dcXtp4agWsDTigqR0bZA8Si5g67CmzmAtpfQQMmeDmQwvaQ54whoCCRT7
AJ8Ucgm7HZtwzyi2fAt9+3Mcs7KojQ0Yw86tjKHrEMXjDMhFGaNTljY6N1GU
Ac+Rv/4oddWs6Cpfe6zwKERRyYcuKgkaUgBBuv+lYBVxjx7ecT957YFJioYi
FIYZCEaTYGj3dUA+1s3R66+yq4mCiDAUjrhrIoGw5utnYpyCmp6/NbCgghMS
GZaz+OZeQtEVtCqPTh0B0cC29UVnpgbvpt9UzRJG290CTmqr8WAkRpD0XZug
aE8+UGxjXYPa0rMH8OPecxV7TYD4F+BENoOBcFKOPQZxIUrvSJWadn5Ss0UT
rhGDtPBj/pRA/kuK3Uu+iSERJoyBtoeHU9JVs0VOV7EZJ4Ma8m5tvmFOsUzz
qr51CbtRM2RQeuTMz58yskpnpPnA7D1+UOzptIG5jlEtX68iPXT+kcePn+xh
agjVCDIJpbJ4zMVUZ2f8Mp9PosN1OCGMuzgD0jqhOYl2k6kGxfHvnKvktmzS
MsqPMoRGcILP34F2eJTWzl47/1m8IXbhNffqcwjPizVBD2N2CborRqOzQ4OV
NN3E471zGwYtZAbfQogeDFMGwHV2kWMVQW2FILa+d9yIJWUWKPxxzd5339DI
rrRUKgm5BTKLAmu0ySnyweaWR5wi+Xa3yQ1O+1ouFSpBucHn8PfwPcqDYQ3T
n1wOXx++G3R4HeFMPtnbe0KOxwNXdIBwSxR8IrqMgoXs2CCtzcorW7N78Q1j
vB4923nyAA/yVwfvT5NnT90DKjb2nz1FqfMVyQvzLa4OfuelxDc7X5sS226B
v/ndmnDHNG3Sb9uvLPGVbre9vEFFzA6S0clpgEp1IW+HfyDuQkcmc4c60/sy
6Uv06xEFiD4jQIt5WX7gfQqC59vJWwKyOPlLIeihwzkF1ElMC9FKWEIdHSq8
/IRzzarhtwx1RbzYr7snDlPwzbMHX/MoxCBOx+VV5mmHMiBLl1Fb3yxg5SuY
Fo8KXe9gNIgjmc+Jw0qhwdPU7rgGCC2tkbWI4SKC4thG61XOK5VWWWbpB+Kw
pDLyiMDEm0fIMFln+V7NJEEK5VyISbzFurucX/jxf1t+/BigQnSA4o7IG0KH
dOLCtpODxrvb0OMs+B431GsqczZB1Ay8eQ+LLNT3BmasE6qRgZToh50KNXh/
rBpcOnb2X2Fk3WOaEM/ElMgzY8NTkW9+fZX4lOaG3woZ/v2Ib++BkF4Xb9an
4LCkCrs3OYcGDvTwAVeg8GgY9SMGm8U3wBxwqBRWCTNJWMggU2R2IU4o3hM6
CwOBQdRNtjCoEfPU9CqvNaeCVzAxFcjygnwEXPoEDWV8G1X2tPGbwRdv14l5
1Nno/NDuNqLJcG/15MEDNd/Lo3AxnyDXWCQLxWQCYnbR/BvvpdBUtxrr8GH0
oCbuCaSVE59mGpRQyFhc9cwvaW1q5ps8Ojc3GLYLHGH5NynZc+VuYeQ7oyTu
I9jeKTDHiyp1V4hroKUpB4kB34kFgmXGZ7jYdMaAs7K4ndxMMMCBZQBg0a/z
KeYrMBcrBQFEdQa7DF0PwL2fvCOpyrkvwL2DlITXMPY53dT16T7nO0QZNxoY
Y+oosouyyV38lBgnbJ+LvXg9IxBhC+olypIFFeDh7t4jw2dXS6zmUnMl/3au
p1RN0aMY3I0kbGzgefScsZkKCRwQjM8nFho9jcvf5QtcJW17Oy7KRjW1JKpK
kpXKsi05fGnKYqsE5RhX6saPxdvOQ21WwOZ8j1RoiYTv447juUk98hBhL07Y
IC4GzXtBRQb1oLzAwxWRaTm2TE+6gi5cIou3DKtAVApMLAufF+1WpLmsMs3B
Iqf8/0qykO/Wms+jOcRZWM67ZTPXbLxHE86c5Parq+ZaZKS5dj220wkix2kt
DIn1KnWf2rpMIWioVU1I1qgTNpQ27edpEl/D4aVV4uS7u+aTaDlyoOMtMqaD
anNxZELWEkkEx+Tge33Kg+3ydaueRD5sCm2H+hHmW0zLjOdIJEwPuAUkP0f7
e5ovsScfMi4r61U1QDquNOfQnRbq3pFWT5NgssK7z9SHFpyZvgO1n5cI9gXO
MZPK8pp4TXXkfIJgnYWkKuUn3bV4gbEmUplOVkChAgwPin3JA0wtbSvoz8IB
vwtOpXck+IvqNhtCeEjEiWbh5uGJjOKrQVPSUvSCnY6kIOVSC4fRMmkTNsO3
TcSFe+0xRF7fll3bH530aiWOHgZjus+iKyCNz2LdyrfDqUZVSoTCWkXKtls8
vSNM5i3xVrTAAaWosxBfGhSxcXxM1TMtKKyMPPc6RievDKYnaZjR5mVapc1Z
4S057if6tTyMvniqeGbWAJS4eVp1TQo/WccVNpliZDyI42aacbonURvIyUHQ
DNXLshEnb5NILmxskvDCab1Yr9KEJMJZrdzL9A4max1FjlGGsabWZUVSoTmV
5SSdG9SF5sYkE+PRjXb2RABPoO1WU2FlCs1iJiv70BoZZuaZumcMhqsVhicO
I71zYzs5MxghXotxuSpc3njbj2eqbZvyu8ZNp9WVA25Hq+IziAcioW8iiROu
gl5JWnhiYlKXWFc1z9Ir0vwEvx0LbN4G61MLjrTwNeZmsDkXuhBYoyUkPw4k
GXDRJjGvbnbBMk0uxg1InLw9QtUE/CbvLbk9eUlhs7lMaV6FAV9OFFlbnEyK
grDBaKhj0HZCnR1jNuLxm6PjIx4DTzmMhKxjmHXgTievrj0OdDvLF44btOVx
FDj4s8QNvutzlVyXjrLWPxpqZOQj3cLEJXjn9HQUliYCvSzUxA/+RBqXlu03
fRC88m53rB4Fz2DZfHepIVVQK0aLstueohZ9bxicH2eaFWFlfFYNm3LopsEV
hogTncbeYr+DiHIQM4MufnbAW17FIG7Rftv1bZiB3R/nRECYldc9fArg16RK
O7Fnj058rLw2qx2DXl3nTWZnelJQaj/jUlvVb/giZVctnQjVClWYX0PWbHlN
KOTOrQhMOt7psg7qO7GX9q7eWnatKS9O87/D33/nttO9xqz9IUkrGzDHHGb3
lT3qlLNVeBOzHViJroOTvW/YJoJxb3I6fMkkm3OGU8ZTt8nUgppdzL1tBllr
cJGVzdAnrEA51V47+IWl83DNTDRnS5jEl2eK/egAXcptXArnFXnpyj9irRh5
MD6zYSl0UgDIsaY4fyFSbSG8bWAtgKfeDvGb8SoLZIPX6soUc/j7rqJjHVYL
0BsF2ntO5PsFjqauBRKwdh0dTTUyf6Wzqbbuzz2c5/Gi/YJj8z9PjT81QUk+
WZtgp6Wy5JfXnuL6xq2iTOKDVIm16c5Go0cVWF262M7CmEk8do7CS7T9rmB7
rL3EYX08EvLS1uc0LDnXdDJMWpUEvsxWGvBEZ1VSsv1+1gj0vhgupSLF2DnO
g+MZMFICi4zmUiG4UT88RZRdfNGdz6xCe4MxJS0PFxEB0N+nT1zAaEgGGJxp
dsn89BOBSWo5NfYrcoPM5zG9kCFv09JU8cU78soVrt1inBc+A0p1RXXDod/S
CXW3LhRGueP+bwnog65KGzi89Vpv/EEYmT56+8Xe1Co+Lo/e8bT5+dE/bYID
634O6Z9TfNp5ctf/HNE/9LRHyG3SdjtJt/VzRv8M8ekOEzv+OYVHpe01zrQ1
T0eI1K6f1kgQR7T2pzUSZEibP73c5Gm8KvMCCGK/10sO9zvCQers8yCPQNjU
veRo38Y3ghYGzul7OJBgicfkAjciwhNFoeXCxTiv3HbsPbpbWF2C2JK7Q54a
KdfWd2C3UqhPsJuHXvQ9YBqd3ssitRrAUBq66GrN0KVsilcPnu7f6nFklxPq
K73kbN9WVvEukV4y3KeQxqrGlYscEQ7HSHrmtNfj+lgBzzJwXtyq98KWDiO2
1KNALChdHIoV/fTIcaYDy5mQMX3aT+5389BeUHXQGsLiOeycKYp8wvsJ/Grg
wtY8cZeudaOwQVrO1RJvqyCnusD3GJzym9oT0TjDtLTS3eflCgwi3+ZqglQx
AwuoA+/XGDqrHcQwqWbFV+isYFcwW15BsdKAeJzPz48mnqs6pg0yb12MsgPh
p0sQB3c1XY6hMS55gQ+Dlm1U17I/oOyp1Qsj0sllDrRNoUSWgrbiGqMgBuLP
4VuZCLOhnmu2t939g+kcGijYFR2GtqDXRu7HMec9ej18hfw1Wk86hE3y3tL5
6H7ZuV0rrq8jReK5P4k81kQBWDaoFWzrwlKWXHiYbJkoP8Xf5aXrQrdmUHU5
UiQM2tVs7JaHFuFDrqho59N9fyU0ZqGUWV38xsNXcICzFd+gkdLWmStuAjWG
QzB0+mDF/iLv8DTlPhib4IwYS1c8J5z2QKGbnV9R2WBJEdULqp1ffEDpuJRx
ZVxyaKCUjbv63UJZOiLQHTVY3WQpT9XnS0fbxeWslgSCSRVpILF0lFwTPuit
0zDObkoxrxdl3SQkH/Qx7lRKXFHqThRJFkRUUXaOnMLnelNbd+j8JKY7GqXq
ni+3d/c+eoATgYWC+KVaNGxfoQ8PR/rp04FDHH769FKwLIgIgsGXk0laSwp+
Uo7pOpKp8J1oJAQgCvBaMLma84NhqbZKuoSzf9vm4RDo6hWgl78wrFROcdkE
1VHM4vMDhO9KBYBloiAtICs/Ia5gKm/AJcLYjiAs85a3QNXNJrzfYQzaY+97
NuFRYPVqjI9yYDMAhBlgV+MucYVe8qm9wRXt7Yuyk4AJoPFRYmruSx23rnwp
dWl57W9Z+ggaFl5MCsLHXUQ19UXiCJPmYFkcwEoJJy3lB8L4LdfZd6WR4tw/
tsGuyjkFxwQUtxWUh8PQj26YwY4EYKygNIPU9qz1aK+Wysfgq8kH8cpxVba+
9VGJtpB9xJqXnppEI/V1ONfHuWu7wzZyllcc5Cb+S3SM/nvRUybIXUotcu5y
PJ3l7RCSvhpzqGWKBnrTMlqby6jcMkWggSolIE/gkUuBIGXQjYXSarcm+TOK
W5viqF2rwaSiNQsJ6khV8ikzDQ8LQfkYT7HQv3/ie7VN+URW0v2VvVRC0T0f
12ULby89vxWW4C+XmEn9zbVgt3PSzm5pqrtopk/oWg+RMzdAtd3L4kLcDOdG
KayfCfXaTt6UTaa7LjcZ5ha+4GwpCkXa050Xfh8Um+ZNwAgRhU39k6OiEuOu
/rmYqJ+DfrI13Nn75zQnl1zUpZnKhcokdHyuT9vfZ4s4dPuKO918etXJSque
KFoi0F7spBjigY8qUDeCOTKEU4CAK62FU47R80gXiTr0cI65pGg9sSrUkV9a
C+sgIwsfkmdQ9fpJjDMEsbqSq5pZoGtIuT2FA7xwR3VzM2dnMzpCM2D351gN
Z0TLhGvms1rPzkenfSKfJ093976ju25lmAdFUYKKzShHkwd7IC/sPnvy6LuY
dYUFoOU+Sr7O0qy5UbUERcJQGLzGK5YIinhca423S/cx4XQ0FN0NrJnIfBVX
5DFdw0YDoJZoV3rnQCDRBu5KgBZ2pMv31KEH+lVtu3i7wgFyVEBkHDkfRjpp
VmnMbq1sMquzb2sauxKtvoCfry7XUSNnTd0RXyet13vj/EOCzbVZ+zexl6i/
Hxdl6JFvFFRTupoeh9Y7aMVIJNnNaSCmrG46b+ns4T0u4e5TteevmWH4yGmY
7M7avh4jzKYvG0nMzJeSec0nhl0bdLLInzBLMYlJcGJkTpZuDvKchu5kkK5y
W5C5ZoqOKgl68jI6pegsh+H5RGr0bHuEbJsZkp7jR7Dbyog2TnHkExFfpM1u
rEbxg04XRdXKVJfW0KcIIZgslvyi4s15LV5LUdjN9EQjLhcm6GrU3WgkCKfj
vAn7SvcEsxhWQiJW3qZc3zAWSUWYnTmvLueOB3WzKXeMQMfOeqPPwqdPjsiJ
HNWpNuYd5d6guCJ/QyjlOnFWcd2Fp3rpzLtaEl9eZNmULtt6rakqSBr6qXzY
Qg7DAZUcFLVv2ANau3XWEtOvStjgExEAMIKt01cnDAN4sQIqOSlgExK80QKz
CrZenJz1k5kOyWXP0EhdQh4OBVrhe2BNoguW+3v89DE6CBRmAO3Zam/x4493
HjzCFtGdIYkdZGRfu9wxLWBhPbWqcpGlMALq7JjlCGeJON5MK2PpgozIyYsP
2efPTkcnfR53GvEfQW7gE15vQr5uaqDDOGBB0tp+Aks04JeV5P721//+Au9s
/Ntf/8cA/3hDyiH9hQ3DJzLIkyP4UCtn6Ia+OmlRk7mi5fb9Jn4DvwEhHawP
j2ulU7ORyuuWvioybj3hfwOL0RdUuUfGQFkrWhx9nbztvioPI5gFQZA2KeVG
FBc2q0e8eVql7t528kcprSJeQ4QYuFRgX5ze8fcGDPpWoGVLb8Gmq21R5ygn
TuB3Q9wGwBfOXMk9fR4+1o/8vdPKIRO6HRjpCR02vL7CrNYtJl03wkvp3cVq
DsMq2jGwqgbKQ1rEmJ1B4CLlooerGaxQjqwMhDXsBpX8gkGS56FeVZkW7/eD
M/4JZN6cAmruBfG4XbO2Jl1LCu5HuiCtvW1FKtzH6E53YQEhOx3iAHukqqPE
XKpydXFpL21HtcAwmPB6BH5HhLu/DKABIYW3EQIFqftuTRlWuVQ2bUSTlZDH
+Aq9q7DUq8K5Z922EdpDiSr1qqc23aYFAZH5EqATTU+eZpgKO03EeVZ03cuA
qa1ObKUE6e2INbptoimRo4B9TGR45Qu1u2HdgfeLQ5FuW7GrHTIKp1iqF7iV
+vnU3LyyVvIQm4LfRN4tV9Wy9CItEibsAiVj1sXpzIGx4F0FKYHeADtwKQEA
NPDLkuEpGnTiyzZ5Fka7k0i1rMdQ1mOoQRRzm4pQOdmxZc2J1Ui4KvKePni6
S8Ul3i3LIqYAmGEs6DrOfwsDFNbHJ2kpwfPQVbvuKo8OdJM9fnqxB0w+lcuU
8DY70KfoslW9r4MPkMQcCxPiIiPM1KWU6VmDc2AbR4aI1VFrXLia3ZiBKkC9
RANmpV2KgGFVAwJte46BunnirpuKVHQkO3fRFNMeVVRmyjMJv1SxdpEHgbMg
EwtOWTafSSl9RnODorDisJSWb6Dxo35M1G2rzNDAOWBT61irvP5AYT3142dY
j5NmybpYOAQyufO6nIvO7jIhKfUidS49caMDE3DtiqeGs+6n7MFN2TQ3AUsn
eXSE7hjoDoXX2QlsPkhIpovAFJqxblfcomtS9uPHD7CWtCqXboVc0GA+16PJ
Pvxkgn0XWMJLVnyB98wbNdnEUit7s51uvE6pH62TXFtPh07tOJErblhXq3mh
0UGJYwTxN67HJX/EATOPfmClFCsP81JKbQUVcdbnqRQQXC7tk45lzhRtIq3L
FvMNgpGUqkrBSDcbdMlhlDAItpXkjaUrE2VXw6HUXt62M8AKcVpbiBztB94p
XGQSJwokvMAX/EWKDlZohT0QFkFq5HiFJ8lFacOxyy3rWhubQ0x4j7HBOHrj
MTr1sdoR1WNBHXE1/otgSwLSjXx5YH5PVrVxFhNUNmjNHIWBFCAhVdhIKhqz
FH5RaaQVRvT1HXxdPnwR6vz46cg/+2SHnuWkSPrihVpvu2S9mfrloP3zaZZ1
wpG8QD6N5Q/3kz9ecmbhEfIkdFW9xhgcBvmTEeM4+KZJxxFGAum8J5WZdh+A
8HSr5JAnlOhddNDfb+qEbzIC6c5BesS08utkYkj/dFuo4kdDj+ciy0TRpYiy
27mLEguVUtEi8vxNWeuGrwbkS7ygp9geYJ/7ClpBCBp+PpMcU3/MqShm3hrv
PL0hFxZsMUoTJkF5M3TPcFXNG1KqgRyn/mpQfN0VMHUTMAeLyGiBnhjk6xFN
Qkf33i69L8ttMI5CHNm136AdqtljL0kUe4a4rrHsTDlZ1ElLSqRsjU1qhVZZ
3bSksaOD8EzBTFKuzNqG3HWKazjmz7NJqhB+Yo0oJivxERIpeJ9E3EbtckVB
scEMB/jPgM4kqKXVDfPeIsumGh81uGSCwZi+ULFyFhzwlQL+g/4yuRtSuDDw
dIImE5YOR6u1LZVH2dHTvXH5fzj3Jql2BWixqyInnUCVMBw3vbliIQQDwHnK
DqQNStSMyynlBXGzZQpslCBAOFgYyAWCABN3Q7QBOKrtJdgEgy13ppnfAeeA
4fXCyAyOBPXOpNdDU5nL1HqtSWUtB56Z6dGAuWADs4nsY4OgACpeTCorPMqn
r8nM8CWUh+tokh5oAhr6NsXVBbqABLbAPZ+tSN1zb5KOVlF2xEDEr2Sx085x
cM4zB1/RmL72nATvDPY3YjpPpHJZllE4S5vv6qxFDqqhydx4243ZKVD/K+Ri
CO6Rz588e+owP+8Z8qO6q6Q9oDFh9IjVUrWXeXJcEEaKJPGJMfa3QNvoq7oh
wIJAAWG0mFTylWmi9KT6YJVGmyRWY3NQHJltw0hw582jbEBrRtF/BT44osAg
VlPFsDLfa8aSVFKSJ4pPbOhm6F7vzzD17xJKza7D+LRyJDsP4+jhCIFTtC2u
kvS5y7RazFagrKKRw7iK+lYtbeCvPY/0RTiVBLhhwyABG79mCKubR+CKgW25
TiuHLXROS79AtC6SYyHRgDWdc8mw62w8HFewgxTcnlxmQI9TU14NaHEq+gpx
6hZqaYn3hOSTjI0avHuxRpgZi2wMsBIH7lyWWvwBdKwpiDHBW3vR/zIgl77w
l0KYX3YhQdxg3fmUIJxXjApTokvCPtj7Nl6HrHzeSx1G/wTH2CgCA0ncsnqC
PdIEuJHqXbBWrw/eHHOsXWQFIeVIN06vKRS+dPLZKOQycZUAZOaJ8ko1/8RM
YvNn/WgY4IcjIkgpZ7pdseVJgzL9qG5MAXI7Qtg5lBwMCJKQEurkPB9m0X4W
A510FFckyiFiJvHasCWSavm3IF/OKtV08brzKUhJFArNqU/rUAxFtP0PD8Hq
P2z7u1RLG708ePXKwiTiWAU+ZBRzb4Ct18w17S5SypFOYpWckh3HMLYh0CrG
A1UbyBX1xLFA5JY+HmcLKOX+qurKXx4bKTLkRgJzKMcwqcgT8uN7R7FxF/mv
ufw1R4lEK/WQcyrZjh4r/3xeOxUTVSD/bI4+sPPD02SGVfXSSVXWBgyjRdRR
6aAFdsczCOnpY4iWywV8yra6QNlxfKBQEKtmLzIoPAP0OOEUxbfKOEvWJ9D5
DQpONnCUh5xW4DtpoaajK1DCaV44NSpMSb1OReC5Uanvuwb6rxVWFkA12/5G
q7Ijz52mS96N4FYV3I5BqzV8TMBIWOUIo/s1hRHF4ueECfocjW4H13L3OpV8
s06FG6rVfNJAUyMBGQTX5SLegEpWhdvxG4JeCnxIqoDyrFLRmdWjTqiiMd/M
JZCp+KyCJQGUQBcHg6YHthrWPKbFT9mxm6G7FbRpurXKFYN3gfQA4ooznWJm
B1U5a1auCBx8VLhyJAY070xgBV0MtUyPyF9/VjXbusFefQFFM2+XgEAnDdri
luJ0IbxFt6xk71jlxTZA6WhuuFRhlnzIjDFlrEDEs5FWg5whQ9MPOAZSuYDZ
0Q4J4nt8+x2BBr1SHETttNqca201HgqduQuW0OfiX5cULqpT4ytwnZ8c9eGB
Jp8H0X2ljynYdEz+HXxGkZzumCz4kjjF16uxjbExZBLKspwHp1Uv92t2n1Ny
c4EO0ajSJFEj9FZgpQUvu6R08TVfnlEMbQJTkOOh/hl3MzkyjUgCMlZSitrl
WEZjUi5MPgCpnITA5oQJSoZt0spbB0w3W3hzNrEhubsOxRjCLtXrzsajjyHF
eEp0iKGUZpyJkIPelLcqBHjUSgk2xUAkIJE2wYfoe0yxzCXMcZUxgDmjyJoV
NFmtTBQVObzUDeOZE2Y5yvZprJi8IqMSPzTHuCIlmKdiKJsJ9MW72iSHaA4I
fhrQu5M47u4XHzSB4YJIGRunAoaH5toOpR2F978R2Fv0axgn6UITEi51qcNr
nTA6r/NM2XnuIDZS8cqKhS23Hdj2b2qwnbJrCoT1jaJbG9ZKQMvk5ODNQSte
gqiwIrs27vOuWuolJwWiUhO5aAe+cA+73T3aEvsjXe1g4sJUDOSHXl8RqzB1
v1vO1vqSgIOo/jkPeNsvyPmPau8+e7j7FLWssxIs+OQQ1ri4ST+I0lR80KxF
7Iy4FDOcDBeQPMg4uu3kjxk/Tl2iIVCqqoW+xWCQEmvO+bb3+ZyubwTqhXkP
h8MEwTe9/xdbgc2ffnkBAA==
</rfc> </rfc>
 End of changes. 148 change blocks. 
3143 lines changed or deleted 1884 lines changed or added

This html diff was produced by rfcdiff 1.48.