Re: [media-types] Media type review requested for draft-ietf-avtcore-rtp-vvc-16

[Stephan Wenger <[e-mail]>]

Hi Martin, 
thanks for your advice (very far down in this email) that suggested to include the template in this email.  Template below.  It's looooong.
The link I posted earlier was no good.  Here's one that works. https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/16/
Stephan


   Type name:            video

   Subtype name:         H266

   Required parameters:  N/A

   Optional parameters:

      profile-id, tier-flag, sub-profile-id, interop-constraints, level-
      id, sprop-sublayer-id, sprop-ols-id, recv-sublayer-id, recv-ols-
      id, max-recv-level-id, sprop-dci, sprop-vps, sprop-sps, sprop-pps,
      sprop-sei, max-lsr, max-fps, sprop-max-don-diff, sprop-depack-buf-
      bytes, depack-buf-cap (Refer to Section 7.2 for definitions).

   Encoding considerations:

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

   Security considerations:

      See Section 9 of RFC XXXX.

   Interoperability considerations: N/A

   Published specification:

      Please refer to RFC XXXX and its Section 13.

   Applications that use this media type:

      Any application that relies on VVC-based video services over RTP

   Fragment identifier considerations: N/A

   Additional information: N/A

   Person & email address to contact for further information:

      Stephan Wenger ([e-mail])

   Intended usage: COMMON

   Restrictions on usage: N/A

   Author: See Authors' Addresses section of RFC XXXX.

   Change controller:

      IETF Audio/Video Transport Core Maintenance Working Group
      delegated from the IESG.

7.2.  Optional Parameters Definition

   profile-id, tier-flag, sub-profile-id, interop-constraints, and
   level-id:

      These parameters indicate the profile, tier, default level, sub-
      profile, and some constraints of the bitstream carried by the RTP
      stream, or a specific set of the profile, tier, default level,
      sub-profile and some constraints the receiver supports.

      The subset of coding tools that may have been used to generate the
      bitstream or that the receiver supports, as well as some
      additional constraints are indicated collectively by profile-id,
      sub-profile-id, and interop-constraints.

      Informative note: There are 128 values of profile-id.  The
         subset of coding tools identified by the profile-id can be
         further constrained with up to 255 instances of sub-profile-id.
         In addition, 68 bits included in interop-constraints, which can
         be extended up to 324 bits provide means to further restrict
         tools from existing profiles.  To be able to support this fine-
         granular signaling of coding tool subsets with profile-id, sub-
         profile-id and interop-constraints, it would be safe to require
         symmetric use of these parameters in SDP offer/answer unless
         recv-ols-id is included in the SDP answer for choosing one of
         the 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.

      In SDP offer/answer, when the SDP answer does not include the
      recv-ols-id parameter that is less than the sprop-ols-id parameter
      in the SDP offer, the following applies:

      -  The tier-flag, profile-id, sub-profile-id, and interop-
         constraints parameters MUST be used symmetrically, i.e., the
         value of each of these parameters in the offer MUST be the same
         as that in the answer, either explicitly signaled or implicitly
         inferred.

      -  The level-id parameter is changeable as long as the highest
         level indicated by the answer is either equal to or lower than
         that in the offer.  Note that a highest level higher than
         level-id in the offer for receiving can be included as max-
         recv-level-id.

      In SDP offer/answer, when the SDP answer does include the recv-
         ols-id parameter that is less than the sprop-ols-id parameter
         in the SDP offer, the set of tier-flag, profile-id, sub-
         profile-id, interop-constraints, and level-id parameters
         included in the answer MUST be consistent with that for the
         chosen output layer set as indicated in the SDP offer, with the
         exception that the level-id parameter in the SDP answer is
         changeable 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 syntax elements specified in [VVC] are provided below.

   profile-id:

      When profile-id is not present, a value of 1 (i.e., the Main 10
      profile) MUST be inferred.

      When used to indicate properties of a bitstream, profile-id is
      derived from the general_profile_idc syntax element that applies
      to the bitstream in an instance of the profile_tier_level( )
      syntax structure.

      VVC bitstreams transported over RTP using the technologies of this
      memo SHOULD contain only a single profile_tier_level( ) structure
      in the DCI, unless the sender can assure that a receiver can
      correctly decode the VVC bitstream regardless of which
      profile_tier_level( ) structure contained in the DCI was used for
      deriving profile-id and other parameters for the SDP O/A exchange.

      As specified in [VVC], a profile_tier_level( ) syntax structure
      may be contained in an SPS NAL unit, and one or more
      profile_tier_level( ) syntax structures may be contained in a VPS
      NAL unit and in a DCI NAL unit.  One of the following three cases
      applies to the container NAL unit of the profile_tier_level( )
      syntax structure containing syntax elements used to derive the
      values of profile-id, tier-flag, level-id, sub-profile-id, or
      interop-constraints: 1) The container NAL unit is an SPS, the
      bitstream is a single-layer bitstream, and the profile_tier_level(
      ) syntax structures in all SPSs referenced by the CVSs in the
      bitstream has the same values respectively for those
      profile_tier_level( ) syntax elements; 2) The container NAL unit
      is a VPS, the profile_tier_level( ) syntax structure is the one in
      the VPS that applies to the OLS corresponding to the bitstream,
      and the profile_tier_level( ) syntax structures applicable to the
      OLS corresponding to the bitstream in all VPSs referenced by the
      CVSs in the bitstream have the same values respectively for those
      profile_tier_level( ) syntax elements; 3) The container NAL unit
      is a DCI NAL unit and the profile_tier_level( ) syntax structures
      in all DCI NAL units in the bitstream has the same values
      respectively for those profile_tier_level( ) syntax elements.

      [VVC] allows for multiple profile_tier_level( ) structures in a
      DCI NAL unit, which may contain different values for the syntax
      elements used to derive the values of profile-id, tier-flag,
      level-id, sub-profile-id, or interop-constraints in the different
      entries.  However, herein defined is only a single profile-id,
      tier-flag, level-id, sub-profile-id, or interop-constraints.  When
      signaling these parameters and a DCI NAL unit is present with
      multiple profile_tier_level( ) structures, these values SHOULD be
      the same as the first profile_tier_level structure in the DCI,
      unless the sender has ensured that the receiver can decode the
      bitstream when a different value is chosen.

   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; if no
      level-id is present, a value of 51 (i.e., level 3.1) MUST be
      inferred.

      Informative note: The level values currently defined in the VVC
         specification are in the form of "majorNum.minorNum", and the
         value of the level-id for each of the levels is equal to
         majorNum * 16 + minorNum * 3.  It is expected that if any
         levels are defined in the future, the same convention will be
         used, but this cannot be guaranteed.

      When used to indicate properties of a bitstream, the tier-flag and
      level-id parameters are derived respectively from the syntax
      element general_tier_flag, and the syntax element
      general_level_idc or sub_layer_level_idc[j], that apply to the
      bitstream, in an instance of the profile_tier_level( ) syntax
      structure.

      If the tier-flag and level-id are derived from the
      profile_tier_level( ) syntax structure in a DCI NAL unit, the
      following applies:

      -  tier-flag = general_tier_flag

      -  level-id = general_level_idc

      Otherwise, if the tier-flag and level-id are derived from the
      profile_tier_level( ) syntax structure in an SPS or VPS NAL unit,
      and the bitstream contains the highest sublayer representation in
      the OLS corresponding to the bitstream, the following applies:

      -  tier-flag = general_tier_flag

      -  level-id = general_level_idc

      Otherwise, if the tier-flag and level-id are derived from the
         profile_tier_level( ) syntax structure in an SPS or VPS NAL
         unit, and the bitstream does not contain the highest sublayer
         representation in the OLS corresponding to the bitstream, the
         following applies, with j being the value of the sprop-
         sublayer-id parameter:

      -  tier-flag = general_tier_flag

      -  level-id = sub_layer_level_idc[j]

   sub-profile-id:

      The value of the parameter is a comma-separated (',') list of data
      using base64 [RFC4648] representation.

      When used to indicate properties of a bitstream, sub-profile-id is
      derived from each of the ptl_num_sub_profiles
      general_sub_profile_idc[i] syntax elements that apply to the
      bitstream in a profile_tier_level( ) syntax structure.

   interop-constraints:

      A base64 [RFC4648] representation of the data that includes the
      syntax elements ptl_frame_only_constraint_flag and
      ptl_multilayer_enabled_flag and the general_constraints_info( )
      syntax structure that apply to the bitstream in an instance of the
      profile_tier_level( ) syntax structure.

      If the interop-constraints parameter is not present, the following
      MUST be inferred:

      -  ptl_frame_only_constraint_flag = 1

      -  ptl_multilayer_enabled_flag = 0

      -  gci_present_flag in the general_constraints_info( ) syntax
         structure = 0

      Using interop-constraints for capability exchange results in a
      requirement on any bitstream to be compliant with the interop-
      constraints.

   sprop-sublayer-id:

      This parameter MAY be used to indicate the highest allowed value
      of TID in the bitstream.  When not present, the value of sprop-
      sublayer-id is inferred to be equal to 6.

      The value of sprop-sublayer-id MUST be in the range of 0 to 6,
      inclusive.

   sprop-ols-id:

      This parameter MAY be used to indicate the OLS that the bitstream
      applies to.  When not present, the value of sprop-ols-id is
      inferred to be equal to TargetOlsIdx as specified in 8.1.1 in
      [VVC].  If this optional parameter is present, sprop-vps MUST also
      be present or its content MUST be known a priori at the receiver.

      The value of sprop-ols-id MUST be in the range of 0 to 256,
      inclusive.

      Informative note: VVC allows having up to 257 output layer sets
         indicated in the VPS as the number of output layer sets minus 2
         is indicated with a field of 8 bits.

   recv-sublayer-id:

      This parameter MAY be used to signal a receiver's choice of the
      offered or declared sublayer representations in the sprop-vps and
      sprop-sps.  The value of recv-sublayer-id indicates the TID of the
      highest sublayer that a receiver supports.  When not present, the
      value of recv-sublayer-id is inferred to be equal to the value of
      the sprop-sublayer-id parameter in the SDP offer.

      The value of recv-sublayer-id MUST be in the range of 0 to 6,
      inclusive.

   recv-ols-id:

      This parameter MAY be used to signal a receiver's choice of the
      offered or declared output layer sets in the sprop-vps.  The value
      of recv-ols-id indicates the OLS index of the bitstream that a
      receiver supports.  When not present, the value of recv-ols-id is
      inferred to be equal to value of the sprop-ols-id parameter
      inferred from or indicated in the SDP offer.  When present, the
      value of recv-ols-id must be included only when sprop-ols-id was
      received and must refer to an output layer set in the VPS that
      includes no layers other than all or a subset of the layers of the
      OLS referred to by sprop-ols-id.  If this optional parameter is
      present, sprop-vps must have been received or its content must be
      known a priori at the receiver.

      The value of recv-ols-id MUST be in the range of 0 to 256,
      inclusive.

   max-recv-level-id:

      This parameter MAY be used to indicate the highest level a
      receiver supports.

      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.

   sprop-dci:

      This parameter MAY be used to convey a decoding capability
      information NAL unit of the bitstream for out-of-band
      transmission.  The parameter MAY also be used for capability
      exchange.  The value of the parameter a base64 [RFC4648]
      representations of the decoding capability information NAL unit as
      specified in Section 7.3.2.1 of [VVC].

   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 output layer sets and sublayer representations as
      defined in [VVC]).  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.3 of
      [VVC].

      The sprop-vps parameter MAY contain one or more than one video
      parameter set NAL units.  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 the number of OLSs in vpsA and vpsB is the
      same and any decoder that conforms to the profile, tier, level,
      and constraints indicated by the data starting from the syntax
      element general_profile_idc to the syntax structure
      general_constraints_info(), inclusive, in the profile_tier_level()
      syntax structure corresponding to any OLS with index olsIdx in
      vpsA can decode any CVS(s) referencing vpsB when TargetOlsIdx is
      equal to olsIdx that conforms to the profile, tier, level, and
      constraints indicated by the data starting from the syntax element
      general_profile_idc to the syntax structure
      general_constraints_info(), inclusive, in the profile_tier_level(
      ) syntax structure corresponding to the OLS with index
      TargetOlsIdx 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.4 of [VVC].

      A sequence parameter set spsB is said to be consistent with
      another sequence parameter set spsA if any decoder that conforms
      to the profile, tier, level, and constraints indicated by the data
      starting from the syntax element general_profile_idc to the syntax
      structure general_constraints_info(), inclusive, in the
      profile_tier_level( ) syntax structure in spsA can decode any
      CLVS(s) referencing spsB that conforms to the profile, tier,
      level, and constraints indicated by the data starting from the
      syntax element general_profile_idc to the syntax structure
      general_constraints_info(), inclusive, in the profile_tier_level(
      ) syntax structure in spsB.

   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.5 of [VVC].

   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
      [VSEI].

      The value of the parameter is a comma-separated (',') list of
      base64 [RFC4648] representations of SEI NAL units as specified in
      [VSEI].

      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 few examples
         are described below:

      1) 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 allows one to configure the renderer only once,
         avoiding unwanted artifacts.

      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 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).

   max-lsr:

      The max-lsr MAY be used to signal the capabilities of a receiver
      implementation and MUST NOT be used for any other purpose.  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.

      Informative note: When the OPTIONAL media type parameters are
         used to signal the properties of a bitstream, and max-lsr is
         not present, the values of tier-flag, profile-id, sub-profile-
         id interop-constraints, and level-id must always be such that
         the bitstream complies fully with the specified profile, tier,
         and 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 136 of [VVC] 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 136 of [VVC] 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 136 of
      [VVC] 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, max-lsr.

      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.

      Informative note: The max-fps parameter is semantically
         different from max-lsr in that max-fps is used to signal a
         constraint, lowering the maximum picture rate from what is
         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, max-lsr.

   sprop-max-don-diff:

      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.

      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.

   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 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.

      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.

   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 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.

      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.

      Informative note: depack-buf-cap indicates the maximum possible
         size of the de-packetization buffer of the receiver only,
         without allowing for network jitter.





On 6/15/22, 17:34, "Martin J. Dürst" <[e-mail]> wrote:

    Standard reminder for this list: Please put the template into the mail. 
    This increases the chance of getting comments.

    Regards,    Martin.

    On 2022-06-16 08:25, Stephan Wenger wrote:
    > Folks,
    > 
    > The involved people collectively forgot to ask for a media type review of the subject draft, located here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/16/  It took an AD DISCUSS to remind us __. The VVC payload is a straightforward RTP payload format for the H.266/VVC codec.
    > 
    > The draft is past IETF LC and is on tomorrow's IESG telechat.  Obviously, I can only hope that one of the good folks here could run a review overnight... but hoping I do.  If that's not workable, please time things as you see fit.
    > 
    > Thanks very much,
    > Stephan
    > 
    >