Diff: rfc9584xml2.original.xml

	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 " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">


	]>	]>


	<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="May"/>


	<area>ART</area>	<area>WIT</area>
	<workgroup>avtcore</workgroup>	<workgroup>avtcore</workgroup>

	<keyword>Internet-Draft</keyword>

	<abstract>


	<?line 113?>	<keyword>EVC</keyword>
		<keyword>ISO/IEC 23094-1</keyword>
	<t>This document describes an RTP payload format for the Essential Video Coding	<keyword>Essential Video Coding</keyword>
	(EVC) standard, published as ISO/IEC International Standard 23094-1. EVC was dev
	eloped by the Moving Picture Experts Group (MPEG). The RTP payload format allows
	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="ISO2309
	<t>The Essential Video Coding <xref target="EVC"/> standard, which is formally	4-1"/>, was published in 2020. One of MPEG's goals is to keep EVC's Baseline pr
	designated as ISO/IEC International Standard 23094-1 <xref target="ISO23094-1"/>	ofile essentially royalty-free by using technologies published more than 20 year
	has been published in 2020. One goal of MPEG is to keep <xref target="EVC"/>&#	s ago or otherwise known to be available for use without a requirement for payin
	39;s Baseline profile essentially royalty-free by using technologies published m	g royalties, whereas more advanced profiles follow a reasonable and non-discrimi
	ore than 20 years ago or otherwise known to be available for use without a requi	natory licensing terms policy. Both the Baseline profile and higher profiles of
	rement for paying royalties, whereas more advanced profiles follow a reasonable	EVC <xref target="EVC"/> are reported to provide coding efficiency gains over Hi
	and non-discriminatory licensing terms policy. Both the Baseline profile and hig	gh Efficiency Video Coding <xref target="HEVC"/> and Advanced Video Coding <xref
	her profiles of <xref target="EVC"/> are reported to provide coding efficiency g	target="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.
	(VVC)<xref target="RFC9328"/>. With respect to design philosophy, security, con
	gestion control, and overall implementation complexity, it has similar propertie
	s to those earlier payload format specifications. This is a conscious choice, a
	s at least <xref target="RFC6184"/> is widely deployed and generally known in th
	e relevant implementer communities. Certain mechanisms known from <xref target=
	"RFC6190"/> were incorporated as EVC supports temporal scalability. EVC currentl
	y does not offer higher forms of scalability.</t>

	<section anchor="overview-of-the-evc-codec"><name>Overview of the EVC Codec</nam
	e>


	<t><xref target="EVC"/>, <xref target="AVC"/>, <xref target="HEVC"/> and <xref t	<!-- [rfced] Since it is the technology defined within the RFC, may we update to
	arget="VVC"/> share a similar hybrid video codec design. In this document, we p	something
	rovide a very brief overview of those features of EVC that are, in some form, ad	like the following for clarity?
	dressed by the payload format specified herein. Implementers have to read, unde
	rstand, and apply the ISO/IEC standard pertaining to EVC to arrive at interopera
	ble, well-performing implementations. The EVC standard has a Baseline profile an
	d a Main profile, the latter being a superset of the Baseline profile but includ
	ing more advanced features. EVC also includes still image variants of both Base
	line and Main profiles, in each of which the bitstream is restricted to a single
	IDR picture. EVC facilitates certain walled-garden implementations under commer
	cial constraints imposed by intellectual property rights by including syntax ele
	ments that allow encoders to mark a bitstream as to what of the many independent
	coding tools are exercised in the bitstream, in a spirit similar to the general
	_constraint_flags of <xref target="VVC"/>.</t>


	<t>Conceptually, all EVC, AVC, HEVC and VVC include a Video Coding Layer (VCL);	Original:
	a term that is often used to refer to the coding-tool features, and a Network Ab	This is a conscious choice, as at least [RFC6184] is widely deployed
	straction Layer (NAL), which usually refers to the systems and transport interfa	and generally known in the relevant implementer communities.
	ce aspects of the codecs.</t>


	<section anchor="coding-tool-features-informative"><name>Coding-Tool Features (i	Perhaps:
	nformative)</name>	This is a conscious choice, as at least the RTP Payload Format
		as described in [RFC6184] is widely deployed and generally known in
		the relevant implementer communities.
		-->


	<t>Coding blocks and transform structure</t>	This is a conscious choice, as at least the RTP Payload Format for H.264 video a
		s described in <xref target="RFC6184"/> is widely deployed and generally known i
		n the relevant implementer communities. Certain mechanisms described in <xref t
		arget="RFC6190"/> were incorporated, as EVC supports temporal scalability. EVC c
		urrently does not offer higher forms of scalability.</t>
		<section anchor="overview-of-the-evc-codec">
		<name>Overview of the EVC Codec</name>


	<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>	<!-- [rfced] Similarly, may we update this text to indicate that the codings/tec hnologies "share a similar hybrid video codec design"?


	<t>EVC also uses a traditional video codecs prediction model assuming two genera	Original:
	l types of predictions: Intra (spatial) and Inter (temporal) predictions. A resi	[EVC], [AVC], [HEVC] and [VVC] share a similar hybrid video codec
	due block is calculated by subtracting predicted data from the original (encoded	design.
	) 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>	Perhaps:
		The codings described in [EVC], [AVC], [HEVC], and [VVC] share a similar
		hybrid video codec design.
		-->


	<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>	<!-- [rfced] We do not see "general_constraint_flags" in [VVC] (http://www.itu.i nt/rec/T-REC-H.266). Does this perhaps refer to "general_constraints_info"? Pl ease clarify.


	<t>In-loop filtering</t>	Original:
		EVC facilitates certain walled-garden implementations under
		commercial constraints imposed by intellectual property rights by
		including syntax elements that allow encoders to mark a bitstream as
		to what of the many independent coding tools are exercised in the
		bitstream, in a spirit similar to the general_constraint_flags of
		[VVC].
		-->
		<!-- Note that we added a citation to [EVC] to clarify that it is the ISO/IEC st
		andard that implementers are required to understand. Please let us know if any
		updates are required.


	<t>The Baseline profile of EVC uses the deblocking filter defined in H.263 Annex	Original:
	J. In the Main profile, an Advanced Deblocking Filter (ADDB) can be used as an	Implementers have to read, understand, and
	alternative, which can further reduce undesirable compression artifacts. The Mai	apply the ISO/IEC standard pertaining to EVC to arrive at
	n profile also defines two additional in-loop filters that can be used to improv	interoperable, well-performing implementations.
	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>	Current:
		Implementers have to read, understand, and
		apply the ISO/IEC standard pertaining to EVC [EVC] to arrive at
		interoperable, well-performing implementations.
		-->


	<t>The basis of EVC's inter-prediction is motion compensation using interpol	<t>The codings described in <xref target="EVC"/>, <xref target="AVC"/>,
	ation filters with a quarter sample resolution. In the Baseline profile, a motio	<xref target="HEVC"/>, and <xref target="VVC"/> share a similar hybrid video cod
	n vector is transmitted using one of three spatially neighboring motion vectors	ec design. In this document, we provide a very brief overview of those features
	and a temporally collocated motion vector as a predictor. A motion vector differ	of EVC that are, in some form, addressed by the payload format specified herein
	ence may be signaled relative to the selected predictor, but there is a case whe	. Implementers have to read, understand, and apply the ISO/IEC standard pertain
	re no motion vector difference is signaled, and there is no remaining data in th	ing to EVC <xref target="EVC"/> to arrive at interoperable, well-performing impl
	e block. This mode is called a skip mode. The Main profile includes six addition	ementations. The EVC standard has a Baseline profile and a Main profile, the lat
	al tools to provide improved inter-prediction. With Advanced Motion Vectors Pred	ter being a superset of the Baseline profile but including more advanced feature
	iction (ADMVP), adjacent blocks can be conceptually merged to indicate that they	s. EVC also includes still image variants of both Baseline and Main profiles, i
	use the same motion, but more advanced schemes can also be used to create predi	n each of which the bitstream is restricted to a single IDR picture. EVC facilit
	ctions from the basic model list of candidate predictors. The Merge with Motion	ates certain walled garden implementations under commercial constraints imposed
	Vector Difference (MMVD) tool uses a process similar to the concept of merging n	by intellectual property rights by including syntax elements that allow encoders
	eighboring blocks but also allows the use of expressions that include a starting	to mark a bitstream as to what of the many independent coding tools are exercis
	point, motion amplitude, and direction of motion to send a motion vector signal	ed in the bitstream, in a spirit similar to the general_constraint_info of <xref
	. Using Advanced Motion Vector Prediction (AMVP), candidate motion vector predic	target="VVC"/>.</t>
	tions for the block can be derived from its neighboring blocks in the same pictu	<t>Conceptually, all EVC, AVC, HEVC, and VVC include a Video Coding Laye
	re and collocated blocks in the reference picture. The Adaptive Motion Vector Re	r (VCL), a term that is often used to refer to the coding-tool features, and a N
	solution (AMVR) tool provides a way to reduce the accuracy of a motion vector fr	etwork Abstraction Layer (NAL), which usually refers to the systems and transpor
	om a quarter sample to half sample, full sample, double sample, or quad sample,	t interface aspects of the codecs.</t>
	which provides an efficiency advantage, such as when sending large motion vector	<section anchor="coding-tool-features-informative">
	differences. The Main profile also includes the Decoder-side Motion Vector Refi	<name>Coding-Tool Features (Informative)</name>
	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>	<dl newline="true">
		<dt>Coding blocks and transform structure</dt>
		<dd><t>EVC uses a traditional block-based coding structure, which divi
		des the encoded image into blocks of up to 64x64 luma samples for the Baseline p
		rofile and 128x128 luma samples for the Main profile that can be recursively div
		ided into smaller blocks.


	<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>	<!-- [rfced] We are having trouble understanding "allows to divide". Please con sider whether the suggested updated correctly conveys the intended meaning.


	<t>Reference frames management</t>	Original:
		The baseline
		profiles utilize an HEVC-like quad-tree blocks partitioning that
		allows to divide a block horizontally and vertically onto four
		smaller square blocks.


	<t>In EVC, decoded pictures can be stored in a decoded picture buffer (DPB) for	Perhaps:
	predicting pictures that follow them in the decoding order. In the Baseline prof	The Baseline
	ile, the management of the DPB (i.e., the process of adding and deleting referen	profiles utilize HEVC-like quad-tree-blocks partitioning that
	ce pictures) is controlled by a straightforward AVC-like sliding window approach	allows a block to be divided horizontally and vertically into four
	with very few parameters from the SPS. For the Main profile, DPB management can	smaller square blocks.
	be handled much more flexibly using explicitly signaled reference Picture Lists	-->
	(RPL) in the SPS or slice level.</t>


	</section>	The Baseline profiles utilize HEVC-like quad-tree-blocks partitioning that
	<section anchor="systems-and-transport-interfaces"><name>Systems and Transport I	allows a block to be divided horizontally and vertically into four
	nterfaces</name>	smaller square blocks. The Main profile adds two advanced coding structure to
		ols: 1) Binary Ternary Tree (BTT) partitioning that allows non-square coding uni
		ts and 2) Split Unit Coding Order segmentation that changes the processing order
		of the blocks from traditional left-to-right and top-to-bottom scanning order p
		rocessing to an alternative right-to-left and bottom-to-top scanning order. In t
		he 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>
		<!-- [rfced] Would you like to define "binarization" in Section 3.1.1 (Definitio
		ns from the EVC Standard), as binarization is defined in [EVC] as:


	<t>EVC inherits the basic systems and transport interface designs from AVC and H	binarization
	EVC. These include the NAL-unit-based syntax, hierarchical syntax and data unit	set of bin strings (3.7) for all possible values of a syntax element (3.86)
	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	Original:
	gn of EVC as well as this document, are described below:</t>	The mechanism includes a binarization step and a
		probability update defined by a lookup table.
		-->


	<t>Sequence parameter set</t>	<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>


	<ul empty="true"><li>	<dt>In-loop filtering</dt>
	<t>The Sequence Parameter Set (SPS) contains syntax elements pertaining to a C
	oded Video Sequence (CVS), which is a group of pictures, starting with a random
	access point picture and followed by zero or more pictures that may depend on ea
	ch other and the random access point picture. In MPEG-2, the equivalent of a CVS
	is a Group of Pictures (GOP), which generally started with an I frame and is fo
	llowed by P and B frames. While more complex in its options of random access poi
	nts, EVC retains this basic concept. In many TV-like applications, a CVS contain
	s a few hundred milliseconds to a few seconds of video. In video conferencing (w
	ithout switching MCUs involved), a CVS can be as long in duration as the whole s
	ession.</t>
	</li></ul>


	<t>Picture and adaptation parameter set</t>	<!-- [rfced] Please confirm that "H.263 Annex J." refers to
		the ITU-T Recommendation found at <https://www.itu.int/rec/T-REC-H.263>.
		If this is correct, will add an informative reference entry.


	<ul empty="true"><li>	Current:
	<t>The Picture Parameter Set and the Adaptation Parameter Set (PPS and APS, re	The Baseline profile of EVC uses the deblocking filter defined in
	spectively) carry information pertaining to a single picture. The PPS contains i	H.263 Annex J.
	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 adapti
	ve loop filter coefficients, that are likely to change from picture to picture.<
	/t>
	</li></ul>


	<t>Profile, level, and toolsets</t>	<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.


	<ul empty="true"><li>	<!-- [rfced] We're having trouble understanding "allows to send". Please consid
	<t>Profiles and levels follow the same design considerations known from AVC, H	er whether the suggested updated conveys the correct meaning.
	EVC, and video codecs as old as MPEG-1 Video. The profile defines a set of tools
	(not to confuse with the "toolset" discussed below) that a decoder co
	mpliant with this profile has to support. In EVC, profiles are defined in Annex
	A. Formally, they are defined as a set of constraints that a bitstream needs to
	conform to. In EVC, the Baseline profile is much more severely constraint than
	the Main profile, reducing implementation complexity. Levels relate to bitstream
	complexity in dimensions such as maximum sample decoding rate, maximum picture
	size, and similar parameters directly related to computational complexity and/or
	memory demands.</t>
	</li></ul>


	<t>Profiles and levels are signaled in the highest parameter set available, the	Original:
	SPS.</t>	An adaptive Loop Filter (ALF)
		allows to send signals of up to 25 different filters for the luma
		components, and the best filter can be selected through the
		classification process for each 4x4 block.


	<ul empty="true"><li>	Perhaps:
	<t>EVC contains another mechanism related to the use of coding tools, known as	An adaptive Loop Filter (ALF)
	the toolset syntax element. This syntax element, toolset_idc_h and toolset_idc_	allows signals of up to 25 different filters to be sent for the luma
	l located in the SPS, is a bitmask that allows encoders to indicate which coding	components; the best filter can be selected through the
	tools they are using within the menu of profiles offered by the profile that is	classification process for each 4x4 block.
	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 used in
	the toolset syntax element would be non-compliant. While MPEG specifically rule
	s out the use of the toolset syntax element as a conformance point, walled garde
	n implementations could do so without incurring the interoperability problems MP
	EG fears and create bitstreams and decoders that do not support one or more give
	n tools. That, in turn, may be useful to mitigate certain intellectual property-
	related risks.</t>
	</li></ul>


	<t>Bitstream and elementary stream</t>	An adaptive Loop Filter (ALF) allows signals of up to 25 different filters to be sent for the luma components; the best filter can be selected through the class ification process for each 4x4 block. Similarly to VVC, the filter parameters of ALF are signaled in the Adaptation Parameter Set (APS).</t></dd>


	<ul empty="true"><li>	<dt>Inter prediction</dt>
	<t>Above the Coded Video Sequence (CVS), EVC defines a video bitstream that ca	<dd><t>The basis of EVC's Inter prediction is motion compensation usin
	n be used as an elementary stream in the MPEG systems context. For this document	g interpolation filters with a quarter sample resolution. In the Baseline profil
	, the video bitstream syntax level is not relevant.</t>	e, a motion vector is transmitted using one of three spatially neighboring motio
	</li></ul>	n vectors and a temporally collocated motion vector as a predictor. A motion vec
		tor difference may be signaled relative to the selected predictor, but there is
		a case where no motion vector difference is signaled, and there is no remaining
		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>Random access support</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>EVC supports random access mechanisms based on IDR and CRA access units.</t	<dd><t>In EVC, decoded pictures can be stored in a decoded picture buf
	>	fer (DPB) for predicting pictures that follow them in the decoding order. In the
	</li></ul>	Baseline profile, the management of the DPB (i.e., the process of adding and de
		leting reference pictures) is controlled by a straightforward AVC-like sliding w
		indow approach with very few parameters from the sequence parameter set (SPS). F
		or the Main profile, DPB management can be handled much more flexibly using expl
		icitly signaled Reference Picture Lists (RPLs) in the SPS or slice level.</t></d
		d>
		</dl>
		</section>
		<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>


	<t>Temporal scalability support</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>
		<!-- [rfced] Should "syntax element" be plural when referring to toolset_idc_h a
		nd toolset_idc_l? We see "elements" (plural) later in the text. Please conside
		r how/if the text should be updated. For example, should "the toolset syntax el
		ement" be "toolset syntax elements", and should "is a bitmask" be "are bitmasks"
		?


	<ul empty="true"><li>	Original (first sentence included because changes may be needed there as well):
	<t>EVC supports temporal scalability through the generalized reference picture	EVC contains another mechanism related to the use of coding tools,
	selection approach known since AVC/SVC. Up to six temporal layers are supported	known as the toolset syntax element. This syntax element,
	. The temporal layer is signaled in the NAL unit header (which co-serves as the	toolset_idc_h and toolset_idc_l located in the SPS, is a bitmask
	payload header in this document), in the nuh_temporal_id field.</t>	that allows encoders to indicate which coding tools they are using
	</li></ul>	within the menu of profiles offered by the profile that is also
		signaled.


	<t>Reference picture management</t>	Original (refers to "syntax elements"):
		This parameter is a base64 encoding (Section 4 of [RFC4648])
		representation of a 64 bit unsigned integer bit mask derived from
		the concatenation, in network byte order, of the syntax elements
		toolset_idc_h and toolset_idc_l.
		-->


	<ul empty="true"><li>	<t>EVC contains another mechanism related to the use of coding tools, known as
	<t>EVC's reference picture management is POC-based (Picture Order Count),	the toolset syntax elements. These syntax elements, toolset_idc_h and toolset_i
	similar to HEVC. In the Main profile, substantially all reference picture list m	dc_l (located in the SPS), are bitmasks that allow encoders to indicate which co
	anipulations available in HEVC are available, including explicit transmissions/u	ding tools they are using within the menu of profiles offered by the profile tha
	pdates of reference picture lists, although for reference pictures management pu	t is also signaled. No decoder conformance point is associated with the toolset,
	rposes, EVC uses a modern VVC-like RPL approach, which is conceptually simpler t	but a bitstream that was using a coding tool that is indicated as not being use
	han the HEVC one. In the Baseline profile, reference picture management is more	d in the toolset syntax element would be non-compliant. While MPEG specifically
	restricted, allowing for a comparatively simple group of picture structures only	rules out the use of the toolset syntax element as a conformance point, walled g
	.</t>	arden implementations could do so without incurring the interoperability problem
	</li></ul>	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>


	<t>SEI Message</t>	<dt>Bitstream and elementary stream</dt>
		<dd><t>Above the Coded Video Sequence (CVS), EVC defines a video bitst
		ream that can be used as an elementary stream in the MPEG systems context. For t
		his document, the video bitstream syntax level is not relevant.</t></dd>
		<dt>Random access support</dt>
		<dd><t>EVC supports random access mechanisms based on IDR and clean ra
		ndom access (CRA) access units.</t></dd>
		<dt>Temporal scalability support</dt>
		<dd><t>EVC supports temporal scalability through the generalized refer
		ence picture selection approach known since AVC/SVC. Up to six temporal layers a
		re supported. The temporal layer is signaled in the NAL unit header (which co-se
		rves as the payload header in this document), in the nuh_temporal_id field.</t><
		/dd>


	<ul empty="true"><li>	<dt>Reference picture management</dt>
	<t>EVC inherits many of HEVC's SEI Messages, occasionally with syntax and/	<!-- [rfced] For clarity and to avoid use of "available" twice in close proximit
	or semantics changes, making them applicable to EVC. In addition, some of the co	y, may we update the first instance to "accessible", "offered", or otherwise?
	dec-agnostic SEI Messages of the VSEI specification are also mapped.</t>
	</li></ul>


	</section>	Original:
	<section anchor="parallel-processing-support-informative"><name>Parallel Process	In the Main profile, substantially all reference picture list
	ing Support (informative)</name>	manipulations available in HEVC are available, including explicit
		transmissions/updates of reference picture lists, although ...
		-->
		<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>
		<!-- [rfced] For clarity, may we update this sentence as follows?


	<ul empty="true"><li>	Original:
	<t>EVC's Baseline profile includes no tools specifically addressing parall	The slices are defined as
	el processing support. The Main profile includes independently decodable slices	any rectangular region within a picture and can be encoded to have no
	for parallel processing. The slices are defined as any rectangular region within	coding dependencies with other slices in the same picture but with
	a picture and can be encoded to have no coding dependencies with other slices i	other slices from the previous picture.
	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>	Perhaps:
	<section anchor="NALUnitHeader"><name>NAL Unit Header</name>	The slices are defined as
		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.
		-->


	<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"/>'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"/>'
	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 "MUST", "MUST NOT", "REQUIRED", &
	quot;SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	"NOT RECOMMENDED",
	"MAY", and "OPTIONAL" 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 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	<!-- [rfced] We used the <aside> element for Informative notes. Please review a
	f the picture and width specified by syntax elements in the PPS.</t>	nd let us know if any updates are needed. Note that the <aside> element is defi
		ned as "a container for content that is semantically less important or tangentia
	<t>Tile row: A rectangular region of CTUs having a height specified by syntax el	l to the
	ements in the PPS and a width equal to the width of the picture.</t>	content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
		.
	<t>Tile scan: A specific sequential ordering of CTUs partitioning a picture in w	-->
	hich the CTUs are ordered consecutively in CTU raster scan in a tile whereas til
	es in a picture are ordered consecutively in a raster scan of the tiles of the p
	icture.</t>

	<t>Video coding layer (VCL) NAL unit: A collective term for coded slice NAL unit
	s and the subset of NAL units that have reserved values of NalUnitType that are
	classified as VCL NAL units in this document.</t>

	</section>
	<section anchor="def"><name>Definitions Specific to This Document</name>

	<t>Media-Aware Network Element (MANE): A network element, such as a
	middlebox, selective forwarding unit, or application-layer gateway
	that is capable of parsing certain aspects of the RTP payload headers
	or the RTP payload and reacting to their contents.</t>

	<ul empty="true"><li>
	<t>Informative note: The concept of a MANE goes beyond normal routers or gatew
	ays in that a MANE has to be aware of the signaling (e.g., to learn about the pa
	yload type mappings of the media streams), and in that it has to be trusted when
	working with Secure RTP (SRTP). The advantage of using MANEs is that they allo
	w packets to be dropped according to the needs of the media coding. For example
	, if a MANE has to drop packets due to congestion on a certain link, it can iden
	tify and remove those packets whose elimination produces the least adverse effec
	t on the user experience. After dropping packets, MANEs must rewrite RTCP packe
	ts to match the changes to the RTP stream, as specified in Section 7 of <xref ta
	rget="RFC3550"/>.</t>
	</li></ul>

	<t>NAL unit decoding order: A NAL unit order that conforms to the constraints on
	NAL unit order given in Section 7.4.2.3 in <xref target="EVC"/>, follow the ord
	er of NAL units in the bitstream.</t>

	<t>NALU-time: The value that the RTP timestamp would have if the NAL unit would
	be transported in its own RTP packet.</t>

	<t>NAL unit output order: A NAL unit order in which NAL units of different acces
	s units are in the output order of the decoded pictures corresponding to the acc
	ess units, as specified in <xref target="EVC"/>, and in which NAL units within a
	n access unit are in their decoding order.</t>

	<t>RTP stream: See <xref target="RFC7656"/>. Within the scope of this document,
	one RTP stream is utilized to transport a EVC bitstream, which may contain one
	or more temporal sub-layers.</t>

	<t>Transmission order: The order of packets in ascending RTP sequence number ord
	er (in modulo arithmetic). Within an aggregation packet, the NAL unit transmiss
	ion order is the same as the order of appearance of NAL units in the packet.</t>

	</section>
	</section>
	<section anchor="abbreviations"><name>Abbreviations</name>

	<t>AU         Access Unit</t>

	<t>AP         Aggregation Packet</t>

	<t>APS        Adaptation Parameter Set</t>

	<t>ATS        Adaptive Transform Selection</t>

	<t>B          Bi-predictive</t>

	<t>CBR        Constant Bit Rate</t>

	<t>CPB        Coded Picture Buffer</t>

	<t>CTB        Coding Tree Block</t>

	<t>CTU        Coding Tree Unit</t>

	<t>CVS        Coded Video Sequence</t>

	<t>DPB        Decoded Picture Buffer</t>

	<t>HRD        Hypothetical Reference Decoder</t>

	<t>HSS        Hypothetical Stream Scheduler</t>

	<t>I          Intra</t>

	<t>IDR        Instantaneous Decoding Refresh</t>

	<t>LSB        Least Significant Bit</t>

	<t>LTRP       Long-Term Reference Picture</t>

	<t>MMVD       Merge with Motion Vector Difference</t>

	<t>MSB        Most Significant Bit</t>

	<t>NAL        Network Abstraction Layer</t>

	<t>P          Predictive</t>

	<t>POC        Picture Order Count</t>

	<t>PPS        Picture Parameter Set</t>

	<t>QP         Quantization Parameter</t>

	<t>RBSP       Raw Byte Sequence Payload</t>

	<t>RGB        Same as GBR</t>

	<t>SAR        Sample Aspect Ratio</t>

	<t>SEI        Supplemental Enhancement Information
	</t>

	<t>SODB       String Of Data Bits</t>

	<t>SPS        Sequence Parameter Set</t>

	<t>STRP       Short-Term Reference Picture</t>

	<t>VBR        Variable Bit Rate</t>

	<t>VCL        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	<aside><t>Informative note: The concept of a MANE goes beyond normal
	ted as	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
		media streams), and in that it has to be trusted when working with
		Secure RTP (SRTP). The advantage of using MANEs is that they
		allow packets to be dropped according to the needs of the media
		coding. For example, if a MANE has to drop packets due to
		congestion on a certain link, it can identify and remove those
		packets whose elimination produces the least adverse effect on the
		user experience. After dropping packets, MANEs must rewrite RTCP
		packets to match the changes to the RTP stream, as specified in
		<xref target="RFC3550" section="7" sectionFormat="of"/>.</t></aside>
		</dd>
		<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
		<xref target="EVC"/> and follows the order of NAL units in the
		bitstream.</dd>
		<dt>NALU-time:</dt><dd>The value that the RTP timestamp would have
		if the NAL unit would be transported in its own RTP packet.</dd>
		<dt>NAL unit output order:</dt><dd>A NAL unit order in which NAL
		units of different access units are in the output order of the
		decoded pictures corresponding to the access units, as specified in
		<xref target="EVC"/>, and in which NAL units within an access unit
		are in their decoding order.</dd>
		<dt>RTP stream:</dt><dd>See <xref target="RFC7656"/>. Within the
		scope of this document, one RTP stream is utilized to transport an
		EVC bitstream, which may contain one or more temporal
		sub-layers.</dd>
		<dt>Transmission order:</dt><dd>The order of packets in ascending
		RTP sequence number order (in modulo arithmetic). Within an
		Aggregation Packet (AP), the NAL unit transmission order is the same a
		s
		the order of appearance of NAL units in the packet.</dd>
		</dl>
		</section>
		</section>
		<section anchor="abbreviations">
		<name>Abbreviations</name>
		<dl newline="false" spacing="normal" indent="9">
		<dt>AU</dt>
		<dd>Access Unit</dd>
		<dt>AP</dt>
		<dd>Aggregation Packet</dd>
		<dt>APS</dt>
		<dd>Adaptation Parameter Set</dd>
		<dt>ATS</dt>
		<dd>Adaptive Transform Selection</dd>
		<dt>B</dt>
		<dd>Bi-predictive</dd>
		<dt>CBR</dt>
		<dd>Constant Bit Rate</dd>
		<dt>CPB</dt>
		<dd>Coded Picture Buffer</dd>
		<dt>CTB</dt>
		<dd>Coding Tree Block</dd>
		<dt>CTU</dt>
		<dd>Coding Tree Unit</dd>
		<dt>CVS</dt>
		<dd>Coded Video Sequence</dd>
		<dt>DPB</dt>
		<dd>Decoded Picture Buffer</dd>
		<dt>HRD</dt>
		<dd>Hypothetical Reference Decoder</dd>
		<dt>HSS</dt>
		<dd>Hypothetical Stream Scheduler</dd>
		<dt>I</dt>
		<dd>Intra</dd>
		<dt>IDR</dt>
		<dd>Instantaneous Decoding Refresh</dd>
		<dt>LSB</dt>
		<dd>Least Significant Bit</dd>
		<dt>LTRP</dt>
		<dd>Long-Term Reference Picture</dd>
		<dt>MMVD</dt>
		<dd>Merge with Motion Vector Difference</dd>
		<dt>MSB</dt>
		<dd>Most Significant Bit</dd>
		<dt>NAL</dt>
		<dd>Network Abstraction Layer</dd>
		<dt>P</dt>
		<dd>Predictive</dd>
		<dt>POC</dt>
		<dd>Picture Order Count</dd>
		<dt>PPS</dt>
		<dd>Picture Parameter Set</dd>
		<dt>QP</dt>
		<dd>Quantization Parameter</dd>
		<dt>RBSP</dt>
		<dd>Raw Byte Sequence Payload</dd>
		<dt>RGB</dt>
		<dd>Red, Green, and Blue</dd>
		<dt>SAR</dt>
		<dd>Sample Aspect Ratio</dd>
		<dt>SEI</dt>
		<dd>Supplemental Enhancement Information</dd>
		<dt>SODB</dt>
		<dd>String Of Data Bits</dd>
		<dt>SPS</dt>
		<dd>Sequence Parameter Set</dd>
		<dt>STRP</dt>
		<dd>Short-Term Reference Picture</dd>
		<dt>VBR</dt>
		<dd>Variable Bit Rate</dd>
		<dt>VCL</dt>
		<dd>Video Coding Layer</dd>
		</dl>
		</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"/>
		(included 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 "packet loss" 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 "sprop" 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, "sprop" parameters are being sent. This uncommo
	n characteristic of the "sprop" 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;video</t>

	<t>Subtype name:         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>	If (DON[n] > DON[n-1] and DON[n] - DON[n-1] < 32768),
	<t>Any application that relies on EVC-based video services over RTP</t>	AbsDon[n] = AbsDon[n-1] + DON[n] - DON[n-1]
	</li></ul>


	<t>Fragment identifier considerations: N/A</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]


	<t>Additional information: N/A</t>	If (DON[n] > DON[n-1] and DON[n] - DON[n-1] >= 32768),
		AbsDon[n] = AbsDon[n-1] - (DON[n-1] + 65536 - DON[n])


	<t>Person & email address to contact for further information:</t>	If (DON[n] < DON[n-1] and DON[n-1] - DON[n] < 32768),
		AbsDon[n] = AbsDon[n-1] - (DON[n-1] - DON[n])
		]]></artwork></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
	<t>Stephan Wenger (stewe@stewe.org)</t>	the NAL unit decoding order has different values of AbsDon, the
	</li></ul>	absolute difference between the two AbsDon values may be greater than
		or equal to 1.</t></aside>


	<t>Intended usage: COMMON</t>	<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>


	<t>Restrictions on usage: N/A</t>	</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.


	<t>Author: See Authors' Addresses section of RFC XXXX.</t>	<!-- [rfced] FYI - To avoid repetition in the phrase "factors ... MUST be
		factored in", we updated to "factors ... MUST be considered". Please let
		us know if there is objection.


	<t>Change controller:</t>	Original:
		To determine
		the exact time for decoding, factors such as a possible intentional
		delay to allow for proper inter-stream synchronization, MUST be
		factored in.


	<ul empty="true"><li>	Current:
	<t>IETF <avtcore@ietf.org></t>	To determine
	</li></ul>	the exact time for decoding, factors such as a possible intentional
		delay to allow for proper inter-stream synchronization, MUST be
		considered.
		-->


	<!-- Section 7.2 -->	To determine the exact time for decoding, factors such as a possible intentional
		delay to allow for proper inter-stream synchronization 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 7 -->

	</section>	</section>

	<section anchor="optionalParameters"><name>Optional Parameters Definition</name>	<section anchor="PayloadFormatParameters">
		<name>Payload Format Parameters</name>
	<t>profile-id, level-id, toolset-id:</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
	<ul empty="true"><li>	o provided for applications that use SDP.</t>
	<t>These parameters indicate the profile, the level, and constraints of the bi	<t>Parameters starting with the string "sprop" for stream properties can b
	tstream carried by the RTP stream, or a specific set of the profile, the level,	e used by a sender to provide a receiver with the properties of the stream that
	and constraints the receiver supports.</t>	is or will be sent. The media sender (and not the receiver) selects whether, and
	</li></ul>	with what values, "sprop" parameters are being sent. This uncommon characterist
		ic of the "sprop" parameters may not be intuitive in the context of some signali
	<ul empty="true"><li>	ng protocol concepts, especially with Offer/Answer. Please see <xref target="sd
	<t>More specifications of these parameters, including how they relate to synta	poa"/> for guidance specific to the use of sprop parameters in the Offer/Answer
	x elements specified in <xref target="EVC"/> are provided below.</t>	case.</t>
	</li></ul>	<!-- Section 7.1 -->

	<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 (',') 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 (',') 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 (',') 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>
	<ul empty="true"><li>
	<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>

	<ul empty="true"><li>
	<t>This parameter signals the capabilities of a receiver implementation and in
	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>
	<t>When not present, the value of depack-buf-cap is inferred to be equal to 42
	94967295. The value of depack-buf-cap MUST be an integer in the range of 1 to 4
	294967295, inclusive.</t>
	</li></ul>

	<ul empty="true"><li>
	<ul empty="true"><li>
	<t>Informative note: depack-buf-cap indicates the maximum possible size of t
	he de-packetization buffer of the receiver only, without allowing for network ji
	tter.</t>
	</li></ul>
	</li></ul>


	<!-- Section 7.3 -->	<section anchor="oparams">
		<name>Media Type Registration</name>
		<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 & 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 <avtcore@ietf.org></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>


	</section>	<dt>profile-id:</dt>
	<section anchor="sdp-parameters"><name>SDP Parameters</name>	<dd><t>When profile-id is not present, a value of 0 (i.e., the
		Baseline profile) <bcp14>MUST</bcp14> be inferred.</t>
		<t>When used to indicate properties of a bitstream, profile-id
		<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>


	<t>The receiver MUST ignore any parameter unspecified in this document.</t>	<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>


	<!-- Section 7.3.1 -->	<dt>toolset-id:</dt>
		<dd>This parameter is a base64-encoding representation (<xref
		target="RFC4648" section="4" sectionFormat="of"/>) of a 64-bit
		unsigned integer bit mask derived from the concatenation, in network
		byte order, of the syntax elements toolset_idc_h and toolset_idc_l.
		When used to indicate properties of a bitstream, its value
		<bcp14>MUST</bcp14> be derived from toolset_idh_h and toolset_idc_l in
		the sequence parameter set.</dd>


	<section anchor="mapping-of-payload-type-parameters-to-sdp"><name>Mapping of Pay	<dt>max-recv-level-id:</dt>
	load Type Parameters to SDP</name>	<dd><t>This parameter <bcp14>MAY</bcp14> be used to indicate the
		highest level a receiver supports.</t>
		<t>The value of max-recv-level-id <bcp14>MUST</bcp14> be in the range
		of 0 to 255, inclusive.</t>
		<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>


	<t>The media type video/evc string is mapped to fields in the Session Descriptio	<dt>sprop-sps:</dt>
	n Protocol (SDP) <xref target="RFC8866"/> as follows:</t>	<dd><t>This parameter <bcp14>MAY</bcp14> be used to convey sequence
		parameter set NAL units of the bitstream for out-of-band transmission
		of sequence parameter sets. The value of the parameter is a
		comma-separated (',') list of base64-encoding representations (<xref
		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><list style="symbols">	<dt>sprop-pps:</dt>
	<t>The media name in the "m=" line of SDP MUST be video.</t>	<dd><t>This parameter <bcp14>MAY</bcp14> be used to convey picture
	<t>The encoding name in the "a=rtpmap" line of SDP MUST be evc (the	parameter set NAL units of the bitstream for out-of-band transmission
	media subtype).</t>	of picture parameter sets. The value of the parameter is a
	<t>The clock rate in the "a=rtpmap" line MUST be 90000.</t>	comma-separated (',') list of base64-encoding representations (<xref
	<t>The OPTIONAL parameters profile-id, level-id, toolset-id, max-recv-level-id	target="RFC4648" section="4" sectionFormat="of"/>) of the picture
	, sprop-max-don-diff, sprop-depack-buf-bytes, and depack-buf-cap, when present,	parameter set NAL units as specified in Section 7.3.2.2 of <xref
	MUST be included in the "a=fmtp" line of SDP. The fmtp line is express	target="EVC"/>.</t></dd>
	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 "a=fmtp" line of SDP or conveyed using the &qu
	ot;fmtp" 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 "a=fmtp" line of S
	DP and conveyed using the "fmtp" source attribute. When included in th
	e "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. Whe
	n conveyed in the "a=fmtp" 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 "fmtp" source attribute
	, these parameters are only associated with the given source and payload type as
	parts of the "fmtp" source attribute.</t>
	</list></t>


	<ul empty="true"><li>	<dt>sprop-sei:</dt>
	<t>Informative note: Conveyance of sprop-sps and sprop-pps using the "fmt	<dd><t>This parameter <bcp14>MAY</bcp14> be used to convey one or more
	p" source attribute allows for out-of-band transport of parameter sets in t	SEI messages that describe bitstream characteristics. When present, a
	opologies like Topo-Video-switch-MCU, as specified in <xref target="RFC7667"/>.<	decoder can rely on the bitstream characteristics that are described
	/t>	in the SEI messages for the entire duration of the session,
	</li></ul>	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>


	<t>A general usage of media representation in SDP is as follows:</t>	<dt>sprop-max-don-diff:</dt>


	<figure><artwork><![CDATA[	<dd><t>If there is no NAL unit naluA that is followed in transmission
	m=video 49170 RTP/AVP 98	order by any NAL unit preceding naluA in decoding order (i.e., the transmission
	a=rtpmap:98 evc/90000	order of the NAL units is the same as the decoding order), the value of this pa
	a=fmtp:98 profile-id=1;	rameter <bcp14>MUST</bcp14> be equal to 0.</t>
	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 d receive could look like the following. Only the media codec-specific parts of the SDP are shown.</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>


	<figure><artwork><![CDATA[	<t>The value of sprop-max-don-diff <bcp14>MUST</bcp14> be an integer
	Offerer->Answerer:	in the range of 0 to 32767, inclusive.</t>
	m=video 49170 RTP/AVP 98
	a=rtpmap:98 evc/90000
	a=fmtp:98 profile-id=1; level_id=90;


	]]></artwork></figure>	<t>When not present, the value of sprop-max-don-diff is inferred to
		be equal to 0.</t>
		</dd>


	<ul empty="true"><li>	<dt>sprop-depack-buf-bytes:</dt>
	<t>The above represents an offer for symmetric video communication using <xref	<dd>
	target="EVC"/> and its payload specification at the main profile and level 3.0.
	Informally speaking, this offer tells the receiver of the offer that the sende
	r 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 p
	roperly decode EVC media up to and including level 3.0.</t>
	</li></ul>


	<figure><artwork><![CDATA[	<t>This parameter signals the required size of the de-packetization
	Answerer->Offerer:	buffer in units of bytes. The value of the parameter <bcp14>MUST</bcp14> be gre
	m=video 49170 RTP/AVP 98	ater than or equal to the maximum buffer occupancy (in units of bytes) of the de
	a=rtpmap:98 evc/90000	-packetization buffer as specified in <xref target="DepacketizationProcess" form
	a=fmtp:98 profile-id=1; level_id=60	at="default"/>.</t>
	]]></artwork></figure>


	<ul empty="true"><li>	<t>The value of sprop-depack-buf-bytes <bcp14>MUST</bcp14> be an int
	<ul empty="true"><li>	eger in the range of 0 to 4294967295, inclusive.</t>
	<t>Informative note: level_id shall be set equal to a value of 30 times the
	level number specified in Table A.1 of EVC.</t>
	</li></ul>
	</li></ul>


	<t>With this answer to the offer above, the system receiving the offer advises t he offerer that it is incapable of handing evc at level 3.0 but is capable of de coding level 2. As EVC video codecs must support decoding at all levels below th e maximum level they implement, the resulting user experience would likely be th at 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 cy cles or bandwidth or for other reasons.</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>


	<!-- Section 7.3.2 -->	<aside><t>Informative note: The value of
		sprop-depack-buf-bytes indicates the required size of the
		de-packetization buffer only. When network jitter can occur, an
		appropriately sized jitter buffer has to be available as
		well.</t></aside>
		</dd>


	</section>	<dt>depack-buf-cap:</dt>
	<section anchor="sdpoa"><name>Usage with SDP Offer/Answer Model</name>	<dd>
		<t>This parameter signals the capabilities of a receiver
		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>


	<t>This section describes the negotiation of unicast messages using the offer/an	<!-- [rfced] To match the informative note above this one, may we update
	swer model described in <xref target="RFC3264"/> and its updates.</t>	"depack-buf-cap indicates" to "The value of depack-buf-cap indicates"?


	<t>This section applies to all profiles defined in <xref target="EVC"/>, specifi	Previous Informative note:
	cally to Baseline, Main, and the associated still image profiles.</t>	\| Informative note: The value of sprop-depack-buf-bytes
		\| indicates the required size of the de-packetization buffer
		\| only. When network jitter can occur, an appropriately sized
		\| jitter buffer has to be available as well.


	<t>The following limitations and rules pertaining to the media configuration app	Original:
	ly:</t>	Informative note: depack-buf-cap indicates the maximum possible
		size of the de-packetization buffer of the receiver only,
		without allowing for network jitter.


	<t>The parameters identifying a media format configuration for EVC are profile-i	Perhaps:
	d and level-id. Profile_id MUST be used symmetrically.</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.
		-->


	<t>The answerer MUST structure its answer according to one of the following thre	<aside><t>Informative note: The value of depack-buf-cap indicates
	e options:</t>	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>


	<ul empty="true"><li>	</section>
	<t><list style="symbols">
	<t>maintain all configuration parameters with the values 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 a
	nswer is not higher than that indicated by the offer; or</t>
	</list></t>
	</li></ul>


	<ul empty="true"><li>	<section anchor="sdp-parameters">
	<t><list style="symbols">	<name>SDP Parameters</name>
	<t>remove the media format (payload type) completely (when one or more of th	<t>The receiver <bcp14>MUST</bcp14> ignore any parameter unspecified in
	e parameter values are not supported).</t>	this document.</t>
	</list></t>	<!-- Section 7.3.1 -->
	</li></ul>


	<t>Informative note: The above requirement for symmetric use does not apply for	<section anchor="mapping-of-payload-type-parameters-to-sdp">
	level-id and does not apply for the other bitstream or RTP stream properties and	<name>Mapping of Payload Type Parameters to SDP</name>
	capability parameters, as described in <xref target="formatconfig"/> (Payload f	<t>The media type video/evc string is mapped to fields in the Session
	ormat config) below.</t>	Description Protocol (SDP) <xref target="RFC8866"/> as follows:</t>
		<ul spacing="normal">
		<li>The media name in the "m=" line of SDP <bcp14>MUST</bcp14>
		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>
		<!-- [rfced] Should "fmtp" be "a=fmtp"?


	<t>To simplify handling and matching of these configurations, the same RTP paylo	Original (first sentence included for context):
	ad type number used in the offer SHOULD also be used in the answer, as specified	* The OPTIONAL parameters profile-id, level-id, toolset-id, max-
	in <xref target="RFC3264"></xref>.</t>	recv-level-id, sprop-max-don-diff, sprop-depack-buf-bytes, and
		depack-buf-cap, when present, MUST be included in the "a=fmtp"
		line of SDP. The fmtp line is expressed as a media type string,
		in the form of a semicolon-separated list of parameter=value
		pairs.
		-->
		<li>The <bcp14>OPTIONAL</bcp14> 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,
		<bcp14>MUST</bcp14> be included in the "a=fmtp" line of SDP. The
		"fmtp" line is expressed as a media type string, in the form of a
		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>The answer MUST NOT contain a payload type number used in the offer for the m edia subtype unless the configuration is the same as in the offer or the configu ration in the answer only differs from that in the offer with a different value of level-id.</t>	<t>A general usage of media representation in SDP is as follows:</t>


	<!-- Section 7.3.2.x -->	<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>


	<section anchor="formatconfig"><name>Payload Format Configuration</name>	<!-- [rfced] We believe SIP is correct, but please confirm that "SIP" is intende d, as it is the only occurrence in the document.


	<t>The following limitations and rules pertain to the configuration of the paylo	Original:
	ad format buffer management.</t>	A SIP offer/answer exchange wherein both parties are expected to both
		send and receive could look like the following.
		-->


	<t>The parameters sprop-max-don-diff and sprop-depack-buf-bytes describe the pro	<t>A SIP Offer/Answer exchange wherein both parties are expected to
	perties of an RTP stream that the offerer or the answerer is sending for the med	both send and receive could look like the following. Only the media
	ia format configuration. This differs from the normal usage of the offer/answer	codec-specific parts of the SDP are shown.</t>
	parameters; normally, such parameters declare the properties of the bitstream or
	RTP stream that the offerer or the answerer is able to receive. When dealing wi
	th EVC, the offerer assumes that the answerer will be able to receive media enco
	ded using the configuration being offered.</t>


	<t>Informative note: The above parameters apply for any RTP stream, when present	<artwork><![CDATA[
	, sent by a declaring entity with the same configuration. In other words, the ap	Offerer->Answerer:
	plicability of the above parameters to RTP streams depends on the source endpoin	m=video 49170 RTP/AVP 98
	t. Rather than being bound to the payload type, the values may have to be applie	a=rtpmap:98 evc/90000
	d to another payload type when being sent, as they apply for the configuration.<	a=fmtp:98 profile-id=1; level_id=90;
	/t>	]]></artwork>


	<t>When an offerer offers an interleaved stream, indicated by the presence of sp	<t>The above represents an offer for symmetric video communication
	rop-max-don-diff with a value larger than zero, the offerer MUST include the siz	using <xref target="EVC"/> and its payload specification at the main
	e of the de-packetization buffer sprop-depack-buf-bytes.</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>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	Answerer->Offerer:
	COMMENDED to include depack-buf-cap.</t>	m=video 49170 RTP/AVP 98
		a=rtpmap:98 evc/90000
		a=fmtp:98 profile-id=1; level_id=60
		]]></artwork>


	<t>The parameters sprop-sps, or sprop-pps, when present (included in the "a	<aside><t>Informative note: level_id shall be set equal to a
	=fmtp" line of SDP or conveyed using the "fmtp" source attribute,	value of 30 times the level number specified in Table A.1 of
	as specified in Section 6.3 of <xref target="RFC5576"></xref>), are used for ou	<xref target="EVC"/>.</t></aside>
	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	<t>With this answer to the offer above, the system receiving the
	swerer direction.</t>	offer advises the Offerer that it is incapable of handling evc at
		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>An offer MAY 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>	<!-- [rfced] The text introduces three options, but only two bullet points follo w. Is an option missing, or should the text refer to "two options"?


	<t>If the level to use in the offerer-to-answerer direction is equal to the defa	Original:
	ult level in the offer, the answerer MUST be prepared to use the parameter sets	The answerer MUST structure its answer according to one of the
	included in sprop-sps, and sprop-pps (either included in the "a=fmtp"	following three options:
	line of SDP or conveyed using the "fmtp" source attribute) for decodin
	g 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 MUST ignore sprop-vps, sprop-sps, and sprop-pps (either included
	in the "a=fmtp" line of SDP or conveyed using the "fmtp" 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	* maintain all configuration parameters with the values remaining
	fferer direction.</t>	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


	<t>An answer MAY include sprop-sps, and/or sprop-pps. If none of these parameter	* remove the media format (payload type) completely (when one or
	s are present in the answer, then only in-band transport of parameter sets is us	more of the parameter values are not supported).
	ed.</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 "a=fmtp" line of SDP or conveyed	one of the following two options:</t>
	using the "fmtp" 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 "fmtp" 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 "fm	fig"/> ("<xref target="formatconfig" format="title"/>").</t></aside>
	tp" 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 "fmtp" 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 "fmt	the answer, as specified in <xref target="RFC3264"/>.</t>
	p" 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'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'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'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.	<t>Parameters used for declaring receiver capabilities are, in gener
	However, to enable their usage, in most cases, a second offer is required from	al, downgradable, i.e., they express the upper limit for a sender's possible beh
	the offerer to provide the bitstream property parameters that the media sender w	avior. Thus, a sender <bcp14>MAY</bcp14> select to set its encoder using only lo
	ill use. This also has the effect that the offerer has to be able to receive thi	wer/lesser or equal values of these parameters.</t>
	s media format configuration, not only to send it.</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>


	</section>	<!-- [rfced] Note that we have updated the formatting of the following text to m
	</section>	atch what appears in RFC 9328 (see https://www.rfc-editor.org/rfc/rfc9328.html#s
	<section anchor="multicast"><name>Multicast</name>	ection-7.3.4). Please let us know if any updates are needed.


	<t>For bitstreams being delivered over multicast, the following rules apply:</t>	Original:
		Declaring actual configuration or bitstream properties:


	<t>The media format configuration is identified by profile-id and level-id. Thes	profile-id level-id sprop-sps sprop-pps sprop-max-don-diff sprop-
	e media format configuration parameters, including level-id, MUST be used symmet	depack-buf-bytes sprop-sei
	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>	Not usable (when present, they MUST be ignored):


	<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>	depack-buf-cap recv-sublayer-id


	<t>The rules for other parameters are the same as above for unicast as long as t	-->
	he three above rules are obeyed.</t>	<ul><li>
		<t>Declaring actual configuration or bitstream properties:</t>
		<ul spacing="compact"><li><t>profile-id</t></li>
		<li><t>level-id</t></li>
		<li><t>sprop-sps</t></li>
		<li><t>sprop-pps</t></li>
		<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 8 -->

	</section>	</section>

	<section anchor="declativeSessiondesc"><name>Usage in Declarative Session Descri	</section>
	ptions</name>	</section>
		<section anchor="FeedbackMessage">
	<t>When EVC over RTP is offered with SDP in a declarative style, as in Real Time	<name>Use with Feedback Messages</name>
	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	<!-- [rfced] For simplicity, may we update these two sentences to the
	recv-sublayer-id</t>	following sentence?


	<t>A receiver of the SDP is required to support all parameters and values of the	Original:
	parameters provided; otherwise, the receiver MUST reject (RTSP) or not particip	The following subsections define the use of the Picture Loss
	ate in (SAP) the session. It falls on the creator of the session to use values t	Indication (PLI) and Full Intra Request (FIR) feedback messages with
	hat are expected to be supported by the receiving application.</t>	[EVC]. The PLI is defined in [RFC4585], and the FIR message is
		defined in [RFC5104].


	</section>	Perhaps:
	<section anchor="consider4pps"><name>Considerations for Parameter Sets</name>	The following subsections define the use of the Picture Loss
		Indication (PLI) [RFC4585] and Full Intra Request (FIR) [RFC5104]
		feedback messages with [EVC].
		-->


	<t>When out-of-band transport of parameter sets is used, parameter sets MAY stil	<t>The following subsections define the use of the Picture Loss Indication
	l be additionally transported in-band unless explicitly disallowed by an applica	(PLI) <xref target="RFC4585" format="default"/> and Full Intra Request (FIR) <x
	tion, and some of these additional parameter sets may update some of the out-of-	ref target="RFC5104" format="default"/> feedback messages with <xref target="EVC
	band transported parameter sets. An update of a parameter set refers to the send	"/>.</t>
	ing of a parameter set of the same type using the same parameter set ID but with	<t>In accordance with this document, a sender <bcp14>MUST NOT</bcp14> send
	different values for at least one other parameter of the parameter set.</t>	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>


	<!-- Section 8 -->	<section anchor="PLI">
		<name>Picture Loss Indication (PLI)</name>
		<t>As specified in <xref target="RFC4585" sectionFormat="of" section="6.
		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>	<section anchor="FIR">
	</section>	<name>Full Intra Request (FIR)</name>
	<section anchor="FeedbackMessage"><name>Use with Feedback Messages</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
	<t>The following subsections define the use of the Picture Loss Indication (PLI)	gestion-control-related constraints, such as those set out in <xref target="RFC8
	and Full Intra Request (FIR) feedback messages with <xref target="EVC"/>. The P	082"/>.</t>
	LI is defined in <xref target="RFC4585"/>, and the FIR message is defined in <xr	<t>Upon reception of a FIR, a sender <bcp14>MUST</bcp14> send an IDR pic
	ef target="RFC5104"/>.</t>	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
	<t>In accordance with this document, a sender MUST NOT send Slice Loss Indicatio	l example for that is an understanding between the sender and receiver, establis
	n (SLI) or Reference Picture Selection Indication (RPSI), and a receiver MUST ig	hed by means outside this document, that parameter sets are exclusively sent out
	nore RPSI and MUST treat a received SLI as a received PLI, ignoring the "Fi	of band.</t>
	rst", "Number", and "PictureID" fields of the PLI.</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.


	<!-- Section 8.1 -->	<!-- [rfced] May we remove "are achieved" from the end of the sentence? Otherwi se, please clarify how it relates to the rest of the sentence?


	<section anchor="PLI"><name>Picture Loss Indication (PLI)</name>	Current:
		Packet loss is considered acceptable if a TCP flow across the
		same network path and experiencing the same network conditions would
		achieve an average throughput, measured on a reasonable timescale,
		that is not less than all RTP streams combined are achieved.
		-->


	<t>As specified in Section 6.3.1 of <xref target="RFC4585"/>, the reception of a	Packet loss is considered acceptable if a TCP flow across the same network path
	PLI by a media sender indicates "the loss of an undefined amount of coded	and experiencing the same network conditions would achieve an average throughput
	video data belonging to one or more pictures". Without having any specific	, measured on a reasonable timescale, that is not less than all RTP streams comb
	knowledge of the setup of the bitstream (such as use and location of in-band par	ined. This condition can be satisfied by implementing congestion-control mechani
	ameter sets, IDR picture locations, picture structures, and so forth), a reactio	sms to adapt the transmission rate by implementing the number of layers subscrib
	n to the reception of a PLI by a EVC sender SHOULD be to send an IDR picture and	ed for a layered multicast session or by arranging for a receiver to leave the s
	relevant parameter sets, potentially with sufficient redundancy so to ensure co	ession if the loss rate is unacceptably high.</t>
	rrect reception. However, sometimes information about the bitstream structure is	<t>The bitrate adaptation necessary for obeying the congestion control pri
	known. For example, such information can be parameter sets that have been conve	nciple is easily achievable when real-time encoding is used, for example, by ade
	yed out of band through mechanisms not defined in this document and that are kno	quately tuning the quantization parameter. However, when pre-encoded content is
	wn to stay static for the duration of the session. In that case, it is obviously	being transmitted, bandwidth adaptation requires the pre-coded bitstream to be t
	unnecessary to send them in-band as a result of the reception of a PLI. Other e	ailored for such adaptivity.</t>
	xamples could be devised based on a priori knowledge of different aspects of the	<t>The key mechanism available in <xref target="EVC"/> is temporal scalabi
	bitstream structure. In all cases, the timing and congestion control mechanisms	lity. A media sender can remove NAL units belonging to higher temporal sub-layer
	of <xref target="RFC4585"/> MUST be observed.</t>	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>


	<!-- Section 8.2 -->	</middle>
		<back>
		<references>
		<name>References</name>
		<references>
		<name>Normative References</name>


	</section>	<reference anchor="ISO23094-1" target="https://www.iso.org/standard/5779
	<section anchor="FIR"><name>Full Intra Request (FIR)</name>	7.html">
		<front>
		<title>Information technology - General video coding - Part 1: Essen
		tial video coding</title>
		<author>
		<organization/>
		</author>
		<date month="October" year="2020"/>
		</front>
		<seriesInfo name="ISO/IEC" value="23094-1:2020"/>
		</reference>


	<t>The purpose of the FIR message is to force an encoder to send an independent	<!-- [rfced] May we remove the reference to [ISO23094-1], as it appears to be a
	decoder refresh point as soon as possible while observing applicable congestion-	duplicate
	control-related constraints, such as those set out in <xref target="RFC8082"/>.<	to [EVC]. Note that we will update the reference entry and use [EVC] as the cit
	/t>	ation tag (as [EVC] was used more frequently and aligns with similar reference t
		ags).


	<t>Upon reception of a FIR, a sender MUST send an IDR picture. Parameter sets MU	Original
	ST also be sent, except when there is a priori knowledge that the parameter sets	[EVC] "ISO/IEC 23094-1 Essential Video Coding", 2020,
	have been correctly established. A typical example for that is an understanding	<https://www.iso.org/standard/57797.html>.
	between the sender and receiver, established by means outside this document, th
	at parameter sets are exclusively sent out of band.</t>


	</section>	[ISO23094-1]
	</section>	"ISO/IEC DIS Information technology - General video
	<section anchor="Security"><name>Security Considerations</name>	coding - Part 1 Essential video coding", n.d.,
		<https://www.iso.org/standard/57797.html>.
		-->


	<t>The scope of this section is limited to the payload format itself and to one	<reference anchor="EVC" target="https://www.iso.org/standard/57797.html"
	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	<front>
	plete system. Implementers are advised to read and understand relevant security-	<title>Information technology -- General video coding -- Part 1: Ess
	related documents, especially those pertaining to RTP (see the Security Consider	ential video
	ations section in <xref target="RFC3550"/>) and the security of the call-control	coding</title>
	stack chosen (that may make use of the media type registration of this document	<author>
	). Implementers should also consider known security vulnerabilities of video cod	<organization/>
	ing and decoding implementations in general and avoid those.</t>	</author>
		<date month="October" year="2020"/>
		</front>
		<seriesInfo name="ISO/IEC" value="23094-1:2020"/>
		</reference>


	<t>Within this RTP payload format, and with the exception of the user data SEI m	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	essage as described below, no security threats other than those common to RTP pa	328.xml"/>
	yload formats are known. In other words, neither the various media-plane-based m	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	echanisms nor the signaling part of this document seem to pose a security risk b	119.xml"/>
	eyond those common to all RTP-based systems.</t>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		550.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		551.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
		711.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
		585.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		124.xml"/>
		<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"/>


	<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 "Securing the RTP Frame work: Why RTP Does Not Mandate a Single Media Security Solution" <xref targ et="RFC7202"/> discusses, it is not an RTP payload format'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 "Option s for Securing RTP Sessions" <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>	<!-- [VSEI] has been updated to point to the 2024 release. Please let us know i f any corrections are needed.


	<t>Because the data compression used with this payload format is applied end-to-	Original:
	end, any encryption needs to be performed after compression. A potential denial-	[VSEI] "Versatile supplemental enhancement information messages
	of-service threat exists for data encodings using compression techniques that ha	for coded video bitstreams", 2020,
	ve non-uniform receiver-end computational load. The attacker can inject patholo	<https://www.itu.int/rec/T-REC-H.274>.
	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	Current:
	generate datagrams containing NAL units that affect the decoding process of many	[VSEI] ITU-T, "Versatile supplemental enhancement information
	future NAL units. Therefore, the usage of data origin authentication and data i	messages for coded video bitstreams", ITU-T
	ntegrity protection of at least the RTP packet is RECOMMENDED based on the thoug	Recommendation H.274, March 2024,
	hts of <xref target="RFC7202"/>.</t>	<https://www.itu.int/rec/T-REC-H.274>.
		-->


	<t>Like HEVC <xref target="RFC7798"/> and <xref target="VVC"/>, <xref target="EV	<reference anchor="VSEI" target="https://www.itu.int/rec/T-REC-H.274">
	C"/> includes a user data Supplemental Enhancement Information (SEI) message. Th	<front>
	is SEI message allows inclusion of an arbitrary bitstring into the video bitstre	<title>Versatile supplemental enhancement information messages for c
	am. Such a bitstring could include JavaScript, machine code, and other active co	oded video bitstreams</title>
	ntent.</t>	<author>
		<organization>ITU-T</organization>
		</author>
		<date month="March" year="2024"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="H.274"/>
		</reference>


	<t><xref target="EVC"></xref> leaves the handling of this SEI message to the rec	</references>
	eiving system. In order to avoid harmful side effects of the user data SEI messa	<references>
	ge, decoder implementations cannot naively trust its content. For example, forwa	<name>Informative References</name>
	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	<reference anchor="MPEG2S">
	tion will prevent a MANE from performing media-aware operations other than disca	<front>
	rding complete packets. In the case of confidentiality protection, it will even	<title>Information technology - Generic coding of moving pictures an
	be prevented from discarding packets in a media-aware way. To be allowed to pe	d associated audio information - Part 1: Systems</title>
	rform such operations, a MANE is required to be a trusted entity that is include	<author>
	d in the security context establishment.</t>	<organization>IS0/IEC</organization>
		</author>
		<date month="June" year="2013"/>
		</front>
		<seriesInfo name="ISO/IEC" value="13818-1:2013"/>
		</reference>


	</section>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<section anchor="CC"><name>Congestion Control</name>	184.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		190.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		656.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		667.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		201.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		202.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		798.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		974.xml"/>


	<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>	<!-- [rfced] We have updated [HEVC] to point to the most recent version publishe d in 2023. Please let us know if any corrections are needed.


	<t>The bitrate adaptation necessary for obeying the congestion control principle	Original:
	is easily achievable when real-time encoding is used, for example, by adequatel	[HEVC] "High efficiency video coding, ITU-T Recommendation
	y tuning the quantization parameter. However, when pre-encoded content is being	H.265", 2019, <https://www.itu.int/rec/T-REC-H.265>.
	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	Current:
	lity. A media sender can remove NAL units belonging to higher temporal sub-layer	[HEVC] ITU-T, "High efficiency video coding", ITU-T
	s (i.e., those NAL units with a large value of TID) until the sending bitrate dr	Recommendation H.265, September 2023,
	ops to an acceptable range.</t>	<https://www.itu.int/rec/T-REC-H.265>.
		-->
		<reference anchor="HEVC" target="https://www.itu.int/rec/T-REC-H.265">
		<front>
		<title>High efficiency video coding</title>
		<author>
		<organization>ITU-T</organization>
		</author>
		<date month="" year="2019"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="H.265"/>
		</reference>


	<t>The mechanisms mentioned above generally work within a defined profile and le	<reference anchor="VIDEO-CODING" target="https://www.itu.int/rec/T-REC-H.
	vel; therefore no renegotiation of the channel is required. Only when non-downgr	263">
	adable parameters (such as profile) are required to be changed does it become ne	<front>
	cessary to terminate and restart the RTP stream(s). This may be accomplished by	<title>Video coding for low bit rate communication</title>
	using different RTP payload types.</t>	<author>
		<organization>ITU-T</organization>
		</author>
		<date month="January" year="2005"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="H.263"/>
		</reference>


	<t>MANEs MAY remove certain unusable packets from the RTP stream when that RTP s	<!-- [rfced] For reference [AVC], is the intended reference to H.264
	tream was damaged due to previous packet losses. This can help reduce the networ	<https://www.itu.int/rec/T-REC-H.264>? If not, is the intent to reference ISO/
	k load in certain special cases. For example, MANEs can remove those FUs where t	IEC
	he leading FUs belonging to the same NAL unit have been lost, because the traili	14496-10:2022 <https://www.iso.org/standard/83529.html>?
	ng FUs are meaningless to most decoders. MANE can also remove higher temporal sc
	alable layers if the outbound transmission (from the MANE's viewpoint) exper
	iences congestion.</t>


	</section>	Note that on the landing page of the provided iso.org URL, the title does not ma
	<section anchor="iana-considerations"><name>IANA Considerations</name>	tch and the status is "Withdrawn".


	<t>A new media type, as specified in <xref target="oparams"/> of this document,	Original:
	has been registered with IANA.</t>	[AVC] "ITU-T Recommendation H.264 - Advanced video coding for
		generic audiovisual services", 2014,
		<https://www.iso.org/standard/66069.html>.


	</section>	Perhaps A:
	<section anchor="acknowledgements"><name>Acknowledgements</name>	[AVC] ISO/IEC, "Information technology Coding of audio-visual objects
		Part 10: Advanced Video Coding",
		ISO/IEC 14496-10:2014, September 2019,
		<https://www.iso.org/standard/66069.html>.


	<t>Large parts of this specification share text with the RTP payload format for	Perhaps B:
	VVC <xref target="RFC9328"/>. Roman Chernyak is thanksed for his valueable revie	[AVC] ITU-T, "Advanced video coding for generic audiovisual services",
	w comments. We thank the authors of that specification for their excellent work.	ITU-T Recommendation H.264, February 2014,
	</t>	<https://www.itu.int/rec/T-REC-H.264>.
		-->


	</section>	<reference anchor="AVC" target="https://www.iso.org/standard/66069.html"
		>
		<front>
		<title>Part 10: Advanced video coding</title>
		<author>
		<organization>ITU-T</organization>
		</author>
		<date month="October" year="2014"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="H.264"/>
		</reference>


	</middle>	<reference anchor="VVC" target="http://www.itu.int/rec/T-REC-H.266">
		<front>
		<title>Versatile video coding</title>
		<author>
		<organization>ITU-T</organization>
		</author>
		<date month="August" year="2020"/>
		</front>
		<seriesInfo name="ITU-T Recommendation" value="H.266"/>
		</reference>


	<back>	</references>
		</references>


	<references title='Normative References'>	<section anchor="acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>Large parts of this specification share text with the RTP payload
		format for VVC <xref target="RFC9328"/>. <contact fullname="Roman
		Chernyak"/> is thanked for his valuable review comments. We thank the
		authors of that specification for their excellent work.</t>
		</section>


	<reference anchor="ISO23094-1" target="https://www.iso.org/standard/57797.html">	<!-- [rfced] The following sentences or phrases seem to introduce a list of item
	<front>	s. Please consider whether the reader would benefit from formatting to help cla
	<title>ISO/IEC DIS Information technology --- General video coding --- Part	rify which paragraphs are included in "the following." We note that RFC 9328 us
	1 Essential video coding</title>	es lists for these as well.
	<author >
	<organization></organization>
	</author>
	<date year="n.d."/>
	</front>
	</reference>
	<reference anchor="EVC" target="https://www.iso.org/standard/57797.html">
	<front>
	<title>ISO/IEC 23094-1 Essential Video Coding</title>
	<author >
	<organization></organization>
	</author>
	<date year="2020"/>
	</front>
	</reference>


	<reference anchor="RFC9328">	A) Section 7.3.2.1 - do you want the text to appear in list form as it is in RFC
	<front>	9328?
	<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">	Original:
	<front>	The following limitations and rules pertain to the configuration of
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>	the payload format buffer management.
	<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">	The following rules apply to transport of parameter sets in the offerer-to-an
	<front>	swerer
	<title>RTP: A Transport Protocol for Real-Time Applications</title>	direction.
	<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">	The following rules apply to transport of parameter sets in the answerer-to-o
	<front>	fferer
	<title>RTP Profile for Audio and Video Conferences with Minimal Control</tit	direction.
	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">	Section 7.3.2:
	<front>	Original:
	<title>The Secure Real-time Transport Protocol (SRTP)</title>	The following limitations and rules pertaining to the media
	<author fullname="M. Baugher" initials="M." surname="Baugher"/>	configuration apply:
	<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">	Section 7.3.3:
	<front>	Original:
	<title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-	For bitstreams being delivered over multicast, the following rules
	Based Feedback (RTP/AVPF)</title>	apply:
	<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">	Section 7.3.4: as noted above, we updated the format of this section for clarity
	<front>	. We would like confirmation that matching the format of 9328 is intended before
	<title>Extended Secure RTP Profile for Real-time Transport Control Protocol	making further updates.
	(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">	<!-- [rfced] We have a few specific questions about abbreviations:
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protocol specif
	ications. This document aims to reduce the ambiguity by clarifying that only UPP
	ERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>


	<reference anchor="RFC3264">	A) For the abbreviation "RGB", the definition is "Same as GBR", but "GBR" is not
	<front>	defined in the document. How may we update this definition term/expansion?
	<title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
	<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
	<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
	<date month="June" year="2002"/>
	<abstract>
	<t>This document defines a mechanism by which two entities can make use of
	the Session Description Protocol (SDP) to arrive at a common view of a multimed
	ia session between them. In the model, one participant offers the other a descri
	ption of the desired session from their perspective, and the other participant a
	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">	Original:
	<front>	RGB: Same as GBR
	<title>SDP: Session Description Protocol</title>
	<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">	B) The following abbreviations are not expanded in the text. May we expand the
	<front>	terms as follows? Please consider whether these should appear in any of the abb
	<title>The Base16, Base32, and Base64 Data Encodings</title>	reviations sections.
	<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
	<date month="October" year="2006"/>
	<abstract>
	<t>This document describes the commonly used base 64, base 32, and base 16
	encoding schemes. It also discusses the use of line-feeds in encoded data, use
	of padding in encoded data, use of non-alphabet characters in encoded data, use
	of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4648"/>
	<seriesInfo name="DOI" value="10.17487/RFC4648"/>
	</reference>


	<reference anchor="RFC5576">	CABAC - as expanded in RFC 9328:
	<front>	context adaptive binary arithmetic coding [CABAC]
	<title>Source-Specific Media Attributes in the Session Description Protocol
	(SDP)</title>
	<author fullname="J. Lennox" initials="J." surname="Lennox"/>
	<author fullname="J. Ott" initials="J." surname="Ott"/>
	<author fullname="T. Schierl" initials="T." surname="Schierl"/>
	<date month="June" year="2009"/>
	<abstract>
	<t>The Session Description Protocol (SDP) provides mechanisms to describe
	attributes of multimedia sessions and of individual media streams (e.g., Real-ti
	me Transport Protocol (RTP) sessions) within a multimedia session, but does not
	provide any mechanism to describe individual media sources within a media stream
	. This document defines a mechanism to describe RTP media sources, which are ide
	ntified by their synchronization source (SSRC) identifiers, in SDP, to associate
	attributes with these sources, and to express relationships among sources. It a
	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">	Where the reference entry is as follows:
	<front>	[CABAC] Sole, J., et al., "Transform coefficient coding in HEVC", IEEE Transacti
	<title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback	ons on Circuits and Systems for Video Technology, DOI 10.1109/TCSVT.2012.2223055
	(AVPF)</title>	, December 2012, <https://doi.org/10.1109/TCSVT.2012.2223055>.
	<author fullname="S. Wenger" initials="S." surname="Wenger"/>
	<author fullname="U. Chandra" initials="U." surname="Chandra"/>
	<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
	<author fullname="B. Burman" initials="B." surname="Burman"/>
	<date month="February" year="2008"/>
	<abstract>
	<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">	CRA - clean random access (CRA)
	<front>	DON - Decoding Order Number
	<title>Using Codec Control Messages in the RTP Audio-Visual Profile with Fee	MCU - Multipoint Control Units (MCUs)
	dback with Layered Codecs</title>	NALU - Network Abstraction Layer Unit
	<author fullname="S. Wenger" initials="S." surname="Wenger"/>	SD TV - standard-definition television
	<author fullname="J. Lennox" initials="J." surname="Lennox"/>
	<author fullname="B. Burman" initials="B." surname="Burman"/>
	<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
	<date month="March" year="2017"/>
	<abstract>
	<t>This document updates RFC 5104 by fixing a shortcoming in the specifica
	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">	C) ADDB is introduced, but it's not used elsewhere in the document. Do you want
	<front>	to include the abbreviated form or should "(ADDB)" be removed?
	<title>Real-Time Streaming Protocol Version 2.0</title>
	<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
	<author fullname="A. Rao" initials="A." surname="Rao"/>
	<author fullname="R. Lanphier" initials="R." surname="Lanphier"/>
	<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
	<author fullname="M. Stiemerling" initials="M." role="editor" surname="Stiem
	erling"/>
	<date month="December" year="2016"/>
	<abstract>
	<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">	Original:
	<front>	In the Main profile, an Advanced Deblocking Filter
	<title>Versatile supplemental enhancement information messages for coded vid	(ADDB) can be used as an alternative, which can further reduce
	eo bitstreams</title>	undesirable compression artifacts.
	<author >	-->
	<organization></organization>
	</author>
	<date year="2020"/>
	</front>
	</reference>


	</references>	<!-- [rfced] We have a few specific questions about terminology related to hyphe ns, slashes, and capitalization:


	<references title='Informative References'>	A) To match usage in RFCs 7798 and 9328, may we update the terms to the form on the right?


	<reference anchor="MPEG2S" >	Inter-prediction > Inter prediction
	<front>	intra-coding > intra coding
	<title>Information technology - Generic coding ofmoving pictures and associa	offer/answer > Offer/Answer
	ted audio information - Part 1:Systems, ISO International Standard 13818-1</titl	answerer > Answerer
	e>	offerer > Offerer
	<author initials="" surname="IS0/IEC" fullname="IS0/IEC">
	<organization></organization>
	</author>
	<date year="2013"/>
	</front>
	</reference>


	<reference anchor="RFC6184">	B) Please review the usage of the slashes (/) in the following terms and let
	<front>	us know if they can be replaced with "and", "or", or "and/or" for clarity.
	<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">	mapping/clipping function
	<front>	transmissions/updates
	<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">	<!-- [rfced] We have some general questions about certain terms:
	<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">	A) We see instances of both "Start bit" and "End bit" used in the following, but
	<front>	"S bit" and "E bit" used elsewhere. Please let us know if S bit and E bit shou
	<title>RTP Topologies</title>	ld be used here for consistency. Should Start bit and End bit be introduced whe
	<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>	re S bit and E bit are first introduced?
	<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">	Original:
	<front>	A non-fragmented NAL unit MUST NOT be transmitted in one FU; i.e.,
	<title>Options for Securing RTP Sessions</title>	the Start bit and End bit MUST NOT both be set to 1 in the same FU
	<author fullname="M. Westerlund" initials="M." surname="Westerlund"/>	header.
	<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">	B) The following levels are named in the text. Do they all require a decimal,
	<front>	or may we remove the decimal from 3.0 (3.0 > 3) to make it consistent with the
	<title>Securing the RTP Framework: Why RTP Does Not Mandate a Single Media S	others?
	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">	level 1
	<front>	level 2
	<title>RTP Payload Format for High Efficiency Video Coding (HEVC)</title>	level 3
	<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang"/>	level 3.0
	<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">	<!-- [rfced] Please review the "Inclusive Language" portion of the online
	<front>	Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	<title>Session Announcement Protocol</title>	and let us know if any changes are needed.
	<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">	Note that our script did not flag any words in particular, but this should
	<front>	still be reviewed as a best practice.
	<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>	In addition, please consider whether "tradition" should be updated for clarity.
		While the NIST website
		<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
		uthor-instructions#table1>
		indicates that this term is potentially biased, it is also ambiguous.
		"Tradition" is a subjective term, as it is not the same for everyone.


	</back>	A) "traditional"
		EVC uses a traditional block-based coding structure, which divides
		the encoded image into blocks of up to 64x64 luma samples for the
		Baseline profile and 128x128 luma samples for the Main profile
		that can be recursively divided into smaller blocks.


	<!-- ##markdown-source:	B) "traditional"
	H4sIAOeOgmUAA+2963IbR7Yu+B9PUSNFnCamAVqkJEqi246mSKrFM7pwE5T6	The Main profile adds two advanced coding
	9PR2OApAgawWUIVdVSBFy97RP+f3xPw85zXmAeZR+klmXTNXZhVIyJb7MnPY	structure tools: 1) Binary Ternary Tree (BTT) partitioning that
	bpsEqvK6cl2/tXI4HPaavJln+8nZ+Wlymt7My3SavCirRdoks7JKjus6K5o8	allows non-square coding units and 2) Split Unit Coding Order
	nSfv82lWJoflNC8ukq3j94f9XjoeV9kVv7uUd2fm3feHvWk5KdIFtD+t0lkz	segmentation that changes the processing order of the blocks from
	zLNmNkyvmklZZcOqWQ6zq8nwwZPeNG3gmd0Huw+HO7vDnWe9Xt2kxfT7dF4W	traditional left-to-right and top-to-bottom scanning order
	8EVTrTL8qMrSxX5ycnz+Iun18mVF39TN7oMHzx7s9lL4ej85ODvvXV/sJ9JL	processing to an alternative right-to-left and bottom-to-top
	78M1vFE0WVVkzfAIR9GbpM1+UjfTXm9C04GH60me95b5fvLnppwMkrqsoLNZ	scanning order.
	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==


		C) "traditional"
		EVC also uses a traditional video codecs prediction model assuming
		two general types of predictions: Intra (spatial) and Inter
		(temporal) predictions.
	-->	-->


		</back>
	</rfc>	</rfc>

End of changes. 251 change blocks.
	2984 lines changed or deleted	2282 lines changed or added
This html diff was produced by rfcdiff 1.48.