Hi,

draft-=
ietf-payload-rtp-h265-04  is in =
Working Group Last Call in the Payload Working Group. =

The =
document registers media subtype H265.  =

The new =
registrations are in Section 7.1 of the document and is also given =
bellow.

Comments on the registration are = welcome.

Thanks

Roni = Even

Payload WG = co-chair

Media = Type name: video

Media subtype name: = H265

Required parameters: = none

OPTIONAL = parameters:

profile-space, = tier-flag, profile-id, profile-compatibility-

indicator, = interop-constraints, and level-id:

These = parameters indicate the profile, tier, default = level,

and = some constraints of the bitstream carried by the = RTP

= stream and all RTP streams the RTP stream depends on, or = a

= specific set of the profile, tier, default level, and = some

= constraints the receiver supports.

The = profile and some constraints are indicated collectively = by

= profile-space, profile-id, = profile-compatibility-indicator,

and = interop-constraints. The profile specifies the subset = of

= coding tools that may have been used to generate the = bitstream

or = that the receiver supports.

&= nbsp; Informative note: There are 32 values of profile-id, = and

&= nbsp; there are 32 flags in profile-compatibility-indicator, = each

&= nbsp; flag corresponding to one value of profile-id. = According

&= nbsp; to HEVC version 1 in [HEVC], when more than one of the = 32

&= nbsp; flags is set for a bitstream, the bitstream would = comply

&= nbsp; with all the profiles corresponding to the set = flags.

&= nbsp; However, in a draft of HEVC version 2 in [HEVC draft = v2],

&= nbsp; subclause A.3.5, 19 Format Range Extensions profiles = have

&= nbsp; been specified, all using the same value of profile-id = (4),

&= nbsp; differentiated by some of the 48 bits in = interop-

&= nbsp; constraints - this (rather unexpected way of = profile

&= nbsp; signalling) means that one of the 32 flags may = correspond

&= nbsp; to multiple profiles. To be able to support whatever = HEVC

&= nbsp; extension profile that might be specified and = indicated

&= nbsp; using profile-space, profile-id, = profile-compatibility-

&= nbsp; indicator, and interop-constraints in the future, it = would

&= nbsp; be safe to require symmetric use of these parameters in = SDP

&= nbsp; offer/answer unless recv-sub-layer-id is included in = the

&= nbsp; SDP answer for choosing one of the sub-layers = offered.

The = tier is indicated by tier-flag. The default level = is

= indicated by level-id. The tier and the default level = specify

the = limits on values of syntax elements or = arithmetic

= combinations of values of syntax elements that are = followed

when = generating the bitstream or that the receiver = supports.

A set = of profile-space, tier-flag, profile-id, = profile-

= compatibility-indicator, interop-constraints, and = level-id

= parameters ptlA is said to be consistent with another set = of

these = parameters ptlB if any decoder that conforms to = the

= profile, tier, level, and constraints indicated by ptlB = can

= decode any bitstream that conforms to the profile, = tier,

= level, and constraints indicated by ptlA.

In = SDP offer/answer, when the SDP answer does not include = the

= recv-sub-layer-id parameter that is less than the = sprop-sub-

= layer-id parameter in the SDP offer, the following = applies:

= o The profile-space, = tier-flag, profile-id, profile-

&= nbsp; compatibility-indicator, and = interop-constraints

&= nbsp; parameters MUST be used symmetrically, i.e. the = value of

&= nbsp; each of these parameters in the offer MUST be = the same as

&= nbsp; that in the answer, either explicitly signalled = or

&= nbsp; implicitly inferred.

&= nbsp; o The level-id parameter is changeable as long as = the

&= nbsp; highest level indicated by the answer is either = equal to

= or lower than that in the offer. = Note that the highest

&= nbsp; level is indicated by level-id and = max-recv-level-id

&= nbsp; together.

In = SDP offer/answer, when the SDP answer does include = the

= recv-sub-layer-id parameter that is less than the = sprop-sub-

= layer-id parameter in the SDP offer, the set of = profile-space,

= tier-flag, profile-id, = profile-compatibility-indicator,

= interop-constraints, and level-id parameters included in = the

= answer MUST be consistent with that for the chosen = sub-layer

= representation as indicated in the SDP offer, with = the

= exception that the level-id parameter in the SDP answer = is

= changable as long as the highest level indicated by the = answer

is = either lower than or equal to that in the offer.

More = specifications of these parameters, including how = they

= relate to the values of the profile, tier, and level = syntax

= elements specified in [HEVC] are provided below.

profile-space, = profile-id:

The = value of profile-space MUST be in the range of 0 to = 3,

= inclusive. The value of profile-id MUST be in the range of = 0

to = 31, inclusive.

When = profile-space is not present, a value of 0 MUST = be

= inferred. When profile-id is not present, a value of 1 = (i.e.

the = Main profile) MUST be inferred.

When = used to indicate properties of a bitstream, = profile-space

and = profile-id are derived from the profile, tier, and = level

= syntax elements in SPS or VPS NAL units as follows, = where

= general_profile_space, general_profile_idc,

= sub_layer_profile_space[j], and sub_layer_profile_idc[j] = are

= specified in [HEVC]:

= If the RTP stream is the highest RTP stream, the = following

&= nbsp; applies:

&= nbsp; o profile_space =3D = general_profile_space

&= nbsp; o profile_id =3D general_profile_idc

&= nbsp; Otherwise (the RTP stream is a dependee RTP stream), = the

= following applies, with = j being the value of the sprop-sub-

&= nbsp; layer-id parameter:

&= nbsp; o profile_space =3D = sub_layer_profile_space[j]

&= nbsp; o profile_id =3D = sub_layer_profile_idc[j]

tier-flag, = level-id:

The = value of tier-flag MUST be in the range of 0 to = 1,

= inclusive. The value of level-id MUST be in the range of = 0

to = 255, inclusive.

If = the tier-flag and level-id parameters are used to = indicate

= properties of a bitstream, they indicate the tier and = the

= highest level the bitstream complies with.

If = the tier-flag and level-id parameters are 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 MUST also be supported.

If no = tier-flag is present, a value of 0 MUST be inferred = and

if no = level-id is present, a value of 93 (i.e. level 3.1) = MUST

be = inferred.

When = used to indicate properties of a bitstream, the = tier-flag

and = level-id parameters are derived from the profile, = tier,

and = level syntax elements in SPS or VPS NAL units as = follows,

where = general_tier_flag, general_level_idc,

= sub_layer_tier_flag[j], and sub_layer_level_idc[j] = are

= specified in [HEVC]:

&= nbsp; If the RTP stream is the highest RTP stream, the = following

&= nbsp; applies:

&= nbsp; o tier-flag =3D general_tier_flag

= o level-id =3D = general_level_idc

&= nbsp; Otherwise (the RTP stream is a dependee RTP stream), = the

&= nbsp; following applies, with j being the value of the = sprop-sub-

&= nbsp; layer-id parameter:

&= nbsp; o tier-flag =3D = sub_layer_tier_flag[j]

&= nbsp; o level-id =3D = sub_layer_level_idc[j]

= interop-constraints:

A = base16 [RFC4648] (hexadecimal) representation of six = bytes

of = data, consisting of progressive_source_flag,

= interlaced_source_flag, = non_packed_constraint_flag,

= frame_only_constraint_flag, and = reserved_zero_44bits.

If = the interop-constraints parameter is not present, = the

= following MUST be inferred:

&= nbsp; o progressive_source_flag =3D 1

&= nbsp; o interlaced_source_flag =3D 0

&= nbsp; o non_packed_constraint_flag =3D 1

&= nbsp; o frame_only_constraint_flag =3D 1

&= nbsp; o reserved_zero_44bits =3D 0

When = the interop-constraints parameter is used to = indicate

= properties of a bitstream, the following applies, = where

= general_progressive_source_flag,

= general_interlaced_source_flag,

= general_non_packed_constraint_flag,

= general_frame_only_constraint_flag,

= general_reserved_zero_44bits,

= sub_layer_progressive_source_flag[j],

= sub_layer_interlaced_source_flag[j],

= sub_layer_non_packed_constraint_flag[j],

= sub_layer_frame_only_constraint_flag[j], and

= sub_layer_reserved_zero_44bits[j] are specified in = [HEVC]:

&= nbsp; If the RTP stream is the highest RTP stream, the = following

&= nbsp; applies:

&= nbsp; o progressive_source_flag =3D = general_progressive_source_flag

&= nbsp; o interlaced_source_flag =3D = general_interlaced_source_flag

&= nbsp; o non_packed_constraint_flag =3D

&= nbsp; &n= bsp; = general_non_packed_constraint_flag

&= nbsp; o frame_only_constraint_flag =3D

&= nbsp; &n= bsp; = general_frame_only_constraint_flag

= o reserved_zero_44bits =3D = general_reserved_zero_44bits

&= nbsp; Otherwise (the RTP stream is a dependee RTP stream), = the

&= nbsp; following applies, with j being the value of the = sprop-sub-

&= nbsp; layer-id parameter:

&= nbsp; o progressive_source_flag =3D

&= nbsp; &n= bsp; = sub_layer_progressive_source_flag[j]

&= nbsp; o interlaced_source_flag =3D

&= nbsp; &n= bsp; = sub_layer_interlaced_source_flag[j]

&= nbsp; o non_packed_constraint_flag =3D

&= nbsp; &n= bsp; = sub_layer_non_packed_constraint_flag[j]

&= nbsp; o frame_only_constraint_flag =3D

&= nbsp; &n= bsp; = sub_layer_frame_only_constraint_flag[j]

&= nbsp; o reserved_zero_44bits =3D = sub_layer_reserved_zero_44bits[j]

Using = interop-constraints for capability exchange results in = a

= requirement on any bitstream to be compliant with the = interop-

= constraints.

= profile-compatibility-indicator:

A = base16 [RFC4648] representation of four bytes of = data.

When = profile-compatibility-indicator is used to = indicate

= properties of a bitstream, the following applies, = where

= general_profile_compatibility_flag[j] and

= sub_layer_profile_compatibility_flag[i][j] are specified = in

= [HEVC]:

&= nbsp; The profile-compatibility-indicator in this case = indicates

&= nbsp; additional profiles to the profile defined = by

&= nbsp; profile_space, profile_id, and interop-constraints = the

&= nbsp; bitstream conforms to. A decoder that conforms to any = of

&= nbsp; all the profiles the bitstream conforms to would be = capable

&= nbsp; of decoding the bitstream. These additional profiles = are

&= nbsp; defined by profile-space, each set bit of = profile-

&= nbsp; compatibility-indicator, and = interop-constraints.

&= nbsp; If the RTP stream is the highest RTP stream, the = following

&= nbsp; applies for each value of j in the range of 0 to = 31,

&= nbsp; inclusive:

&= nbsp; o bit j of profile-compatibility-indicator = =3D

= general_profi= le_compatibility_flag[j]

&= nbsp; Otherwise (the RTP stream is a dependee RTP stream), = the

&= nbsp; following applies for i equal to sprop-sub-layer-id and = for

&= nbsp; each value of j in the range of 0 to 31, = inclusive:

= o bit = j of profile-compatibility-indicator =3D

&= nbsp; = sub_layer_profile_compatibility_flag[i][j]

Using = profile-compatibility-indicator for capability = exchange

= results in a requirement on any bitstream to be compliant = with

the = profile-compatibility-indicator. This is intended = to

= handle cases where any future HEVC profile is defined as = an

= intersection of two or more profiles.

If = this parameter is not present, this parameter defaults = to

the = following: bit j, with j equal to profile-id, of = profile-

= compatibility-indicator is inferred to be equal to 1, and = all

other = bits are inferred to be equal to 0.

= sprop-sub-layer-id:

This = parameter MAY be used to indicate the highest = allowed

value = of TID in the bitstream. When not present, the value = of

= sprop-sub-layer-id is inferred to be equal to 6.

The = value of sprop-sub-layer-id MUST be in the range of = 0

to 6, = inclusive.

= recv-sub-layer-id:

This = parameter MAY be used to signal a receiver's choice = of

the = offered or declared sub-layer representations in = the

= sprop-vps. The value of recv-sub-layer-id indicates the = TID

of = the highest sub-layer of the bitstream that a = receiver

= supports. When not present, the value of recv-sub-layer-id = is

= inferred to be equal to the value of the = sprop-sub-layer-id

= parameter in the SDP offer.

The = value of recv-sub-layer-id MUST be in the range of 0 to = 6,

= inclusive.

= max-recv-level-id:

This = parameter MAY be used to indicate the highest level = a

= receiver supports. The highest level the receiver supports = is

equal = to the value of max-recv-level-id divided by 30.

The = value of max-recv-level-id MUST be in the range of = 0

to = 255, inclusive.

When = max-recv-level-id is not present, the value is = inferred

to be = equal to level-id.

= max-recv-level-id MUST NOT be present when the highest = level

the = receiver supports is not higher than the default = level.

= tx-mode:

This = parameter indicates whether the transmission mode is = SSM

or = MSM.

The = value of tx-mode MUST be equal to either "MSM" or = "SSM".

When = not present, the value of tx-mode is inferred to be = equal

to = "SSM".

If = the value is equal to "MSM", MSM MUST be in use. = Otherwise

(the = value is equal to "SSM"), SSM MUST be in = use.

The = value of tx-mode MUST be equal to "MSM" for all = RTP

= sessions in an MSM.

= sprop-vps:

This = parameter MAY be used to convey any video parameter = set

NAL = unit of the bitstream for out-of-band transmission = of

video = parameter sets. The parameter MAY also be used = for

= capability exchange and to indicate sub-stream = characteristics

(i.e. = properties of sub-layer representations as defined = in

= [HEVC]). The value of the parameter is a = comma-separated

(',') = list of base64 [RFC4648] representations of the = video

= parameter set NAL units as specified in Section 7.3.2.1 = of

= [HEVC].

The = sprop-vps parameter MAY contain one or more than one = video

= parameter set NAL unit. However, all other video = parameter

sets = contained in the sprop-vps parameter MUST be = consistent

with = the first video parameter set in the sprop-vps = parameter.

A = video parameter set vpsB is said to be consistent = with

= another video parameter set vpsA if any decoder that = conforms

to = the profile, tier, level, and constraints indicated by = the

12 = bytes of data starting from the syntax element

= general_profile_space to the syntax element = general_level_id,

= inclusive, in the first profile_tier_level( ) syntax = structure

in = vpsA can decode any bitstream that conforms to the = profile,

tier, = level, and constraints indicated by the 12 bytes of = data

= starting from the syntax element general_profile_space to = the

= syntax element general_level_id, inclusive, in the = first

= profile_tier_level( ) syntax structure in vpsB.

= sprop-sps:

This = parameter MAY 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 [RFC4648] = representations

of = the sequence parameter set NAL units as specified = in

= Section 7.3.2.2 of [HEVC].

= sprop-pps:

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 [RFC4648] representations = of

the = picture parameter set NAL units as specified in = Section

= 7.3.2.3 of = [HEVC].

= sprop-sei:

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 characteristics that = are

= described in the SEI messages for the entire duration = of the

= session, independently from the persistence scopes of the = SEI

= messages as specified in [HEVC].

The = value of the parameter is a comma-separated (',') list = of

= base64 [RFC4648] representations of SEI NAL units as = specified

in = Section 7.3.2.4 of [HEVC].

&= nbsp; Informative note: Intentionally, no list of applicable = or

&= nbsp; inapplicable SEI messages is specified here. = Conveying

&= nbsp; certain SEI messages in sprop-sei may be sensible in = some

&= nbsp; application scenarios and meaningless in others. = However,

&= nbsp; a few examples are described below:

&= nbsp; 1) In an environment where the bitstream was created = from

= film-based source material, and no = splicing is going to

&= nbsp; occur during the lifetime of the session, = the film grain

&= nbsp; characteristics SEI message or the tone = mapping

&= nbsp; information SEI message are likely = meaningful, and

&= nbsp; sending them in sprop-sei rather than in = the bitstream

&= nbsp; at each entry point may help saving bits = and allows to

&= nbsp; configure the renderer only once, avoiding = unwanted

&= nbsp; artifacts.

&= nbsp; 2) The structure of pictures information SEI message = in

&= nbsp; sprop-sei can be used to inform a decoder = of information

&= nbsp; on the NAL unit types, picture order count = values, and

&= nbsp; prediction dependencies of a sequence of = pictures.

&= nbsp; Having such knowledge can be helpful for = error recovery.

&= nbsp; 3) Examples for SEI messages that would be meaningless = to

&= nbsp; be conveyed in sprop-sei include the = decoded picture

&= nbsp; hash SEI message (it is close to = impossible that all

&= nbsp; decoded pictures have the same hash-tag), = the display

&= nbsp; orientation SEI message when the device is = a handheld

&= nbsp; device (as the display orientation may = change when the

&= nbsp; handheld device is turned around), or the = filler payload

&= nbsp; SEI message (as there is no point in just = having more

&= nbsp; bits in SDP).

max-lsr, max-lps, = max-cpb, max-dpb, max-br, max-tr, max-tc:

These = parameters MAY be used to signal the capabilities of = a

= receiver implementation. These parameters MUST NOT be = used

for = any other purpose. The highest level (specified by = max-

= recv-level-id) MUST be such that the receiver is fully = capable

= of supporting. = max-lsr, max-lps, max-cpb, max-dpb, max-br,

= max-tr, and max-tc MAY be used to indicate capabilities of = the

= receiver that extend the required capabilities of the = highest

= level, as specified below.

When = more than one parameter from the set (max-lsr, = max-lps,

= max-cpb, max-dpb, max-br, max-tr, max-tc) is present, = the

= receiver MUST support all signaled capabilities

= simultaneously. For example, if both max-lsr and max-br = are

= present, the highest level with the extension of both = the

= picture rate and bitrate is supported. That is, the = receiver

is = able to decode bitstreams in which the luma sample rate = is

up to = max-lsr (inclusive), the bitrate is up to max-br

= (inclusive), the coded picture buffer size is derived = as

= specified in the semantics of the max-br parameter below, = and

the = other properties comply with the highest level = specified

by = max-recv-level-id.

&= nbsp; Informative note: When the OPTIONAL media type = parameters

&= nbsp; are used to signal the properties of a bitstream, and = max-

&= nbsp; lsr, max-lps, max-cpb, max-dpb, max-br, max-tr, and = max-tc

&= nbsp; are not present, the values of profile-space, = tier-flag,

&= nbsp; profile-id, profile-compatibility-indicator, = interop-

&= nbsp; constraints, and level-id must always be such that = the

&= nbsp; bitstream complies fully with the specified profile, = tier,

&= nbsp; and level.

= max-lsr:

The = value of max-lsr is an integer indicating the = maximum

= processing rate in units of luma samples per second. The = max-

lsr = parameter signals that the receiver is capable of = decoding

video = at a higher rate than is required by the highest = level.

When = max-lsr is signaled, the receiver MUST be able to = decode

= bitstreams that conform to the highest level, with = the

= exception that the MaxLumaSR value in Table A-2 of [HEVC] = for

the = highest level is replaced with the value of = max-lsr.

= Senders MAY use this knowledge to send pictures of a = given

size = at a higher picture rate than is indicated in the = highest

= level.

When = not present, the value of max-lsr is inferred to be = equal

to = the value of MaxLumaSR given in Table A-2 of [HEVC] for = the

= highest level.

The = value of max-lsr MUST be in the range of MaxLumaSR = to

16 * = MaxLumaSR, inclusive, where MaxLumaSR is given in = Table

A-2 = of [HEVC] for the highest level.

= max-lps:

The = value of max-lps is an integer indicating the = maximum

= picture size in units of luma samples. The max-lps = parameter

= signals that the receiver is capable of decoding = larger

= picture sizes than are required by the highest level. = When

= max-lps is signaled, the receiver MUST be able to = decode

= bitstreams that conform to the highest level, with = the

= exception that the MaxLumaPS value in Table A-1 of [HEVC] = for

the = highest level is replaced with the value of = max-lps.

= Senders MAY use this knowledge to send larger pictures at = a

= proportionally lower picture rate than is indicated in = the

= highest level.

When = not present, the value of max-lps is inferred to be = equal

to = the value of MaxLumaPS given in Table A-1 of [HEVC] for = the

= highest level.

The = value of max-lps MUST be in the range of MaxLumaPS = to

= 16 * MaxLumaPS, inclusive, = where MaxLumaPS is given in Table

A-1 = of [HEVC] for the highest level.

= max-cpb:

The = value of max-cpb is an integer indicating the = maximum

coded = picture buffer size in units of CpbBrVclFactor bits = for

the = VCL HRD parameters and in units of CpbBrNalFactor bits = for

the = NAL HRD parameters, where CpbBrVclFactor and

= CpbBrNalFactor are defined in Section A.4 of [HEVC]. The = max-

cpb = parameter signals that the receiver has more memory = than

the = minimum amount of coded picture buffer memory required = by

the = highest level. When max-cpb is signaled, the = receiver

MUST = be able to decode bitstreams that conform to the = highest

= level, with the exception that the MaxCPB value in Table = A-1

of = [HEVC] for the highest level is replaced with the value = of

= max-cpb. Senders MAY use this knowledge to construct = coded

= bitstreams with greater variation of bitrate than can = be

= achieved with the MaxCPB value in Table A-1 of = [HEVC].

When = not present, the value of max-cpb is inferred to be = equal

to = the value of MaxCPB given in Table A-1 of [HEVC] for = the

= highest level.

The = value of max-cpb MUST be in the range of MaxCPB = to

16 * = MaxCPB, inclusive, where MaxLumaCPB is given in Table = A-1

of = [HEVC] for the highest level.

&= nbsp; Informative note: The coded picture buffer is used in = the

&= nbsp; hypothetical reference decoder (Annex C of HEVC). The = use

&= nbsp; of the hypothetical reference decoder is recommended = in

&= nbsp; HEVC encoders to verify that the produced = bitstream

&= nbsp; conforms to the standard and to control the output = bitrate.

= Thus, the coded picture buffer is = conceptually independent

&= nbsp; of any other potential buffers in the receiver, = including

&= nbsp; de-packetization and de-jitter buffers. The coded = picture

&= nbsp; buffer need not be implemented in decoders as specified = in

&= nbsp; Annex C of HEVC, but rather standard-compliant decoders = can

&= nbsp; have any buffering arrangements provided that they = can

&= nbsp; decode standard-compliant bitstreams. Thus, in = practice,

&= nbsp; the input buffer for a video decoder can be integrated = with

&= nbsp; de-packetization and de-jitter buffers of the = receiver.

= max-dpb:

The = value of max-dpb is an integer indicating the = maximum

= decoded picture buffer size in units decoded pictures at = the

= MaxLumaPS for the highest level, i.e. the number of = decoded

= pictures at the maximum picture size defined by the = highest

= level. The value of max-dpb MUST be in the range of 1 to = 16,

= respectively. The max-dpb parameter signals that the = receiver

has = more memory than the minimum amount of decoded = picture

= buffer memory required by default, which is MaxDpbPicBuf = as

= defined in [HEVC] (equal to 6). When max-dpb is signaled, = the

= receiver MUST be able to decode bitstreams that conform to = the

= highest level, with the exception that the MaxDpbPicBuff = value

= defined in [HEVC] as 6 is replaced with the value of = max-dpb.

= Consequently, a receiver that signals max-dpb MUST be = capable

of = storing the following number of decoded pictures

= (MaxDpbSize) in its decoded picture buffer:

&= nbsp; &n= bsp; if( PicSizeInSamplesY <=3D ( MaxLumaPS = >> 2 ) )

&= nbsp; MaxDpbSize =3D Min( 4 * max-dpb, 16 = )

&= nbsp; else if ( PicSizeInSamplesY <=3D ( MaxLumaPS >> 1 ) = )

&= nbsp; MaxDpbSize =3D Min( 2 * max-dpb, 16 = )

&= nbsp; else if ( PicSizeInSamplesY <=3D ( ( 3 * MaxLumaPS ) >> 2 = ) )

&= nbsp; MaxDpbSize =3D Min( (4 * max-dpb) / 3, 16 = )

&= nbsp; else

&= nbsp; MaxDpbSize =3D max-dpb

&= nbsp; &n= bsp; Wherein MaxLumaPS given in Table A-1 of [HEVC] for the = highest

level = and PicSizeInSamplesY is the current size of = each

= decoded picture in units of luma samples as defined in = [HEVC].

&= nbsp; &n= bsp; The value of max-dpb MUST be greater than or equal to = the

value = of MaxDpbPicBuf (i.e. 6) as defined in [HEVC]. = Senders

MAY = use this knowledge to construct coded bitstreams = with

= improved compression.

&= nbsp; &n= bsp; When not present, the value of max-dpb is inferred to be = equal

to = the value of MaxDpbPicBuf (i.e. 6) as defined in = [HEVC].

&= nbsp; Informative note: This parameter was added primarily = to

&= nbsp; complement a similar codepoint in the ITU-T = Recommendation

&= nbsp; H.245, so as to facilitate signaling gateway designs. = The

&= nbsp; decoded picture buffer stores reconstructed samples. = There

&= nbsp; is no relationship between the size of the decoded = picture

&= nbsp; buffer and the buffers used in RTP, especially = de-

&= nbsp; packetization and de-jitter buffers.

= max-br:

The = value of max-br is an integer indicating the maximum = video

= bitrate in units of CpbBrVclFactor bits per second for the = VCL

HRD = parameters and in units of CpbBrNalFactor bits per = second

for = the NAL HRD parameters, where CpbBrVclFactor and

= CpbBrNalFactor are defined in Section A.4 of = [HEVC].

The = max-br parameter signals that the video decoder of = the

= receiver is capable of decoding video at a higher bitrate = than

is = required by the highest level.

When = max-br is signaled, the video codec of the receiver = MUST

be = able to decode bitstreams that conform to the = highest

= level, with the following exceptions in the limits = specified

by = the highest level:

= o The value of max-br replaces the MaxBR value in Table = A-2

&= nbsp; of [HEVC] for the highest level.

= o When the max-cpb parameter is not present, the result = of

&= nbsp; the following formula replaces the value of MaxCPB in = Table

&= nbsp; A-1 of [HEVC]:

&= nbsp; (MaxCPB of the highest level) * max-br / = (MaxBR of the

&= nbsp; highest level)

For = example, if a receiver signals capability for Main = profile

Level = 2 with max-br equal to 2000, this indicates a = maximum

video = bitrate of 2000 kbits/sec for VCL HRD parameters, = a

= maximum video bitrate of 2200 kbits/sec for NAL = HRD

= parameters, and a CPB size of 2000000 bits (2000000 / = 1500000

* = 1500000).

= Senders MAY use this knowledge to send higher bitrate video = as

= allowed in the level definition of Annex A of HEVC to = achieve

= improved video quality.

When = not present, the value of max-br is inferred to be = equal

to = the value of MaxBR given in Table A-2 of [HEVC] for = the

= highest level.

The = value of max-br MUST be in the range of MaxBR to

16 * = MaxBR, inclusive, where MaxBR is given in Table A-2 = of

= [HEVC] for the highest level.

&= nbsp; Informative note: This parameter was added primarily = to

&= nbsp; complement a similar codepoint in the ITU-T = Recommendation

&= nbsp; H.245, so as to facilitate signaling gateway designs. = The

&= nbsp; assumption that the network is capable of handling = such

&= nbsp; bitrates at any given time cannot be made from the value = of

&= nbsp; this parameter. In particular, no conclusion can be = drawn

&= nbsp; that the signaled bitrate is possible under = congestion

&= nbsp; control constraints.

= max-tr:

The = value of max-tr is an integer indication the = maximum

= number of tile rows. The max-tr parameter signals that = the

= receiver is capable of decoding video with a larger number = of

tile = rows than the value allowed by the highest = level.

When = max-tr is signaled, the receiver MUST be able to = decode

= bitstreams that conform to the highest level, = with the

= exception that the MaxTileRows value in Table A-1 of = [HEVC]

for = the highest level is replaced with the value of = max-tr.

= Senders MAY use this knowledge to send pictures utilizing = a

= larger number of tile rows than the value allowed by = the

= highest level.

When = not present, the value of max-tr is inferred to be = equal

to = the value of MaxTileRows given in Table A-1 of [HEVC] = for

the = highest level.

The = value of max-tr MUST be in the range of MaxTileRows = to

16 * = MaxTileRows, inclusive, where MaxTileRows is given = in

Table = A-1 of [HEVC] for the highest level.

= max-tc:

The = value of max-tc is an integer indication the = maximum

= number of tile columns. The max-tc parameter signals that = the

= receiver is capable of decoding video with a larger number = of

tile = columns than the value allowed by the highest = level.

When = max-tc is signaled, the receiver MUST be able to = decode

= bitstreams that conform to the highest level, with = the

= exception that the MaxTileCols value in Table A-1 of = [HEVC]

for = the highest level is replaced with the value of = max-tc.

= Senders MAY use this knowledge to send pictures utilizing = a

= larger number of tile columns than the value allowed by = the

= highest level.

When = not present, the value of max-tc is inferred to be = equal

to = the value of MaxTileCols given in Table A-1 of [HEVC] = for

the = highest level.

The = value of max-tc MUST be in the range of MaxTileCols = to

16 * = MaxTileCols, inclusive, where MaxTileCols is given = in

Table = A-1 of [HEVC] for the highest level.

= max-fps:

The = value of max-fps is an integer indicating the = maximum

= picture rate in units of pictures per 100 seconds that can = be

= effectively processed by the receiver. The max-fps = parameter

MAY = be used to signal that the receiver has a constraint = in

that = it is not capable of processing video effectively at = the

full = picture rate that is implied by the highest level = and,

= when present, one or more of = the parameters max-lsr, max-lps,

and = max-br.

The = value of max-fps is not necessarily the picture rate = at

which = the maximum picture size can be sent, it constitutes = a

= constraint on maximum picture rate for all = resolutions.

&= nbsp; Informative note: The max-fps parameter is = semantically

&= nbsp; different from max-lsr, max-lps, max-cpb, max-dpb, = max-br,

&= nbsp; max-tr, and max-tc in that max-fps is used to signal = a

= constraint, lowering the maximum picture rate from what = is

&= nbsp; implied by other parameters.

The = encoder MUST use a picture rate equal to or less than = this

= value. In cases where the max-fps parameter is absent = the

= encoder is free to choose any picture rate according to = the

= highest level and any signaled optional = parameters.

The = value of max-fps MUST be smaller than or equal to the = full

= picture rate that is implied by the highest level and, = when

= present, one or more of the parameters max-lsr, max-lps, = and

= max-br.

= sprop-max-don-diff:

The = value of this parameter MUST be equal to 0, if the = RTP

= stream does not depend on other RTP streams and there is = no

= NAL unit naluA that is = followed in transmission order by any

NAL = unit preceding naluA in decoding order. 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 transmission order.

The = value of sprop-max-don-diff MUST be an integer in = the

range = of 0 to 32767, inclusive.

When = not present, the value of sprop-max-don-diff is = inferred

to be = equal to 0.

When = the RTP stream depends on one or more other RTP = streams

(in = this case tx-mode MUST be equal to "MSM" and MSM is = in

= use), this parameter = MUST be present and the value MUST be

= greater than 0.

&= nbsp; Informative note: When the RTP stream does not depend = on

&= nbsp; other RTP streams, either MSM or SSM may be in = use.

= sprop-depack-buf-nalus:

This = parameter specifies the maximum number of NAL units = that

= precede a NAL unit in transmission order and follow the = NAL

unit = in decoding order.

The = value of sprop-depack-buf-nalus MUST be an integer in = the

range = of 0 to 32767, inclusive.

When = not present, the value of sprop-depack-buf-nalus = is

= inferred to be equal to 0.

When = the RTP stream depends on one or more other RTP = streams

(in = this case tx-mode MUST be equal to "MSM" and MSM is = in

use), = this parameter MUST be present and the value MUST = be

= greater than 0.

= sprop-depack-buf-bytes:

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.

The = value of sprop-depack-buf-bytes MUST be an integer in = the

range = of 0 to 4294967295, inclusive.

When = the RTP stream depends on one or more other RTP = streams

(in = this case tx-mode MUST be equal to "MSM" and MSM is = in

use) = or sprop-max-don-diff is present and greater than 0, = this

= parameter MUST be present and the value MUST be greater = than

= 0.

&= nbsp; Informative note: The value of = sprop-depack-buf-bytes

&= nbsp; indicates the required size of the de-packetization = buffer

&= nbsp; only. When network jitter can occur, an = appropriately

&= nbsp; sized jitter buffer has to be available as = well.

= depack-buf-cap:

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 one or more RTP streams. A receiver is able = to

= handle any RTP stream, and all RTP streams the RTP = stream

= depends on, when present, for which the value of the = sprop-

= depack-buf-bytes parameter is smaller than or equal to = this

= parameter.

When = not present, the value of depack-buf-cap is inferred = to

be = equal to 4294967295. The value of depack-buf-cap MUST = be

an = integer in the range of 1 to 4294967295, = inclusive.

&= nbsp; Informative note: depack-buf-cap indicates the = maximum

&= nbsp; possible size of the de-packetization buffer of = the

&= nbsp; receiver only. When network jitter can occur, = an

&= nbsp; appropriately sized jitter buffer has to be available = as

&= nbsp; well.

= sprop-segmentation-id:

This = parameter MAY be used to signal the segmentation = tools

= present in the bitstream and that can be used = for

= parallelization. The value of sprop-segmentation-id MUST = be

an = integer in the range of 0 to 3, inclusive. When = not

= present, the value of sprop-segmentation-id is inferred to = be

equal = to 0.

When = sprop-segmentation-id is equal to 0, no information = about

the = segmentation tools is provided. When = sprop-segmentation-

id is = equal to 1, it indicates that slices are present in = the

= bitstream. When sprop-segmentation-id is equal to 2, = it

= indicates that tiles are present in the bitstream. = When

= sprop-segmentation-id is equal to 3, it indicates that WPP = is

used = in the bitstream.

= sprop-spatial-segmentation-idc:

A = base16 [RFC4648] representation of the syntax = element

= min_spatial_segmentation_idc as specified in [HEVC]. = This

= parameter MAY be used to describe parallelization = capabilities

of = the bitstream.

= dec-parallel-cap:

This = parameter MAY be used to indicate the decoder's

= additional decoding capabilities given the presence of = tools

= enabling parallel decoding, such as slices, tiles, and WPP, = in

= the bitstream. The = decoding capability of the decoder may

vary = with the setting of the parallel decoding tools = present

in = the bitstream, e.g. the size of the tiles that are = present

in a = bitstream. Therefore, multiple capability points may = be

= provided, each indicating the minimum required = decoding

= capability that is associated with a parallelism = requirement,

which = is a requirement on the bitstream that enables = parallel

= decoding.

Each = capability point is defined as a combination of 1) = a

= parallelism requirement, 2) a profile (determined by = profile-

space = and profile-id), 3) a highest level, and 4) a = maximum

= processing rate, a maximum picture size, and a maximum = video

= bitrate that may be equal to or greater than that = determined

by = the highest level. The parameter's syntax in = ABNF

= [RFC5234] is as follows:

&= nbsp; dec-parallel-cap =3D "dec-parallel-cap=3D{" = cap-point *(","

= &= nbsp; &n= bsp;cap-point) "}"

&= nbsp; cap-point =3D ("w" / "t") ":" = spatial-seg-idc 1*(";"

&= nbsp; &n= bsp; cap-parameter)

&= nbsp; spatial-seg-idc =3D 1*4DIGIT ; = (1-4095)

&= nbsp; cap-parameter =3D tier-flag / level-id / = max-lsr

= &= nbsp; &n= bsp; / max-lps / max-br

&= nbsp; tier-flag =3D "tier-flag" EQ ("0" / = "1")

&= nbsp; level-id =3D "level-id" EQ 1*3DIGIT ; = (0-255)

&= nbsp; max-lsr =3D "max-lsr" EQ = 1*20DIGIT ; (0-

&= nbsp; 18,446,744,073,709,551,615)

= max-lps =3D = "max-lps" EQ 1*10DIGIT ; = (0-4,294,967,295)

&= nbsp; max-br =3D "max-br" EQ = 1*20DIGIT ; (0-

&= nbsp; 18,446,744,073,709,551,615)

&= nbsp; EQ =3D "=3D"

The = set of capability points expressed by the = dec-parallel-cap

= parameter is enclosed in a pair of curly = braces ("{}"). Each

set = of two consecutive capability points is separated by = a

comma = (','). Within each capability point, each set of = two

= consecutive parameters, and when present, their values, = is

= separated by a semicolon (';').

The = profile of all capability points is determined by = profile-

space = and profile-id that are outside the = dec-parallel-cap

= parameter.

Each = capability point starts with an indication of = the

= parallelism requirement, which consists of a parallel = tool

type, = which may be equal to 'w' or 't', and a decimal value = of

the = spatial-seg-idc parameter. When the type is 'w', = the

= capability point is valid only for H.265 bitstreams with = WPP

in = use, i.e. entropy_coding_sync_enabled_flag equal to = 1.

When = the type is 't', the capability point is valid only = for

H.265 = bitstreams with WPP not in use (i.e.

= entropy_coding_sync_enabled_flag equal to 0). The = capability-

point = is valid only for H.265 bitstreams with

= min_spatial_segmentation_idc equal to or greater than = spatial-

= seg-idc.

After = the parallelism requirement indication, each = capability

point = continues with one or more pairs of parameter and = value

in = any order for any of the following parameters:

&= nbsp; o tier-flag

&= nbsp; o level-id

&= nbsp; o max-lsr

&= nbsp; o max-lps

&= nbsp; o max-br

At = most one occurrence of each of the above five parameters = is

= allowed within each capability point.

The = values of dec-parallel-cap.tier-flag and = dec-parallel-

= cap.level-id for a capability point indicate the highest = level

of = the capability point. The values of = dec-parallel-cap.max-

lsr, = dec-parallel-cap.max-lps, and dec-parallel-cap.max-br = for

a = capability point indicate the maximum processing rate = in

units = of luma samples per second, the maximum picture size = in

units = of luma samples, and the maximum video bitrate (in = units

of = CpbBrVclFactor bits per second for the VCL HRD = parameters

and = in units of CpbBrNalFactor bits per second for the NAL = HRD

= parameters where CpbBrVclFactor and CpbBrNalFactor are = defined

in = Section A.4 of [HEVC]).

When = not present, the value of dec-parallel-cap.tier-flag = is

= inferred to be equal to the value of tier-flag outside = the

= dec-parallel-cap parameter. When not present, the value = of

= dec-parallel-cap.level-id is inferred to be equal to the = value

of = max-recv-level-id outside the dec-parallel-cap = parameter.

When = not present, the value of dec-parallel-cap.max-lsr, = dec-

= parallel-cap.max-lps, or dec-parallel-cap.max-br is = inferred

to be = equal to the value of max-lsr, max-lps, or = max-br,

= respectively, outside the dec-parallel-cap = parameter.

The = general decoding capability, expressed by the set = of

= parameters outside of dec-parallel-cap, is defined as = the

= capability point that is determined by the = following

= combination of parameters: 1) the parallelism = requirement

= corresponding to the value of sprop-segmentation-id = equal to 0

for a = bitstream, 2) the profile determined by = profile-space,

= profile-id, profile-compatibility-indicator, and = interop-

= constraints, 3) the tier and the highest level determined = by

= tier-flag and max-recv-level-id, and 4) the maximum = processing

rate, = the maximum picture size, and the maximum video = bitrate

= determined by the highest level. The general = decoding

= capability MUST NOT be included as one of the set = of

= capability points in the dec-parallel-cap = parameter.

For = example, the following parameters express the = general

= decoding capability of 720p30 (Level 3.1) plus an = additional

= decoding capability of 1080p30 (Level 4) given that = the

= spatially largest tile or slice used in the bitstream is = equal

to or = less than 1/3 of the picture size:

&= nbsp; a=3Dfmtp:98 = level-id=3D93;dec-parallel-cap=3D{t:8;level-id=3D120}

For = another example, the following parameters express = an

= additional decoding capability of 1080p30, using = dec-parallel-

= cap.max-lsr and dec-parallel-cap.max-lps, given that WPP = is

used = in the bitstream:

&= nbsp; a=3Dfmtp:98 = level-id=3D93;dec-parallel-cap=3D{w:8;

&= nbsp; &n= bsp; max-lsr=3D62668800;max-lps=3D2088960}

&= nbsp; Informative note: When min_spatial_segmentation_idc = is

&= nbsp; present in a bitstream and WPP is not used, = [HEVC]

&= nbsp; specifies that there is no slice or no tile in = the

&= nbsp; bitstream containing more than 4 * PicSizeInSamplesY = /

&= nbsp; ( min_spatial_segmentation_idc + 4 ) luma = samples.

= include-dph:

This = parameter is used to indicate the capability and

= preference to utilize or include decoded picture hash = (DPH)

SEI = messages (See Section D.3.19 of [HEVC]) in the = bitstream.

DPH = SEI messages can be used to detect picture corruption = so

the = receiver can request picture repair, see Section 8. = The

= value is a comma separated = list of hash types that is

= supported or requested to be used, each hash type provided = as

an = unsigned integer value (0-255), with the hash types = listed

from = most preferred to the least preferred. = Example:

= "include-dph=3D0,2", which indicates the capability for = MD5

(most = preferred) and Checksum (less preferred). If = the

= parameter is not included or the value contains no hash = types,

then = no capability to utilize DPH SEI messages is = assumed.

Note = that DPH SEI messages MAY still be included in = the

= bitstream even when there is no declaration of capability = to

use = them, as in general SEI messages do not affect = the

= normative decoding process and decoders are allowed to = ignore

SEI = messages.

Encoding = considerations:

This = type is only defined for transfer via RTP (RFC = 3550).

Security = considerations:

See = Section 9 of RFC XXXX.

Public = specification:

= Please refer to Section 13 of RFC XXXX.

Additional information: = None

File extensions: = none

Macintosh file type = code: none

Object identifier or = OID: none

Person & email = address to contact for further information:

Intended usage: = COMMON

Author: See Section 14 = of RFC XXXX.

Change = controller:

IETF = Audio/Video Transport Payloads working group = delegated

from = the IESG.