Re: [media-types] Media type review request for draft-ietf-avtcore-rtp-evc-04

[Ron Even <[e-mail]>]

Hi,
The draft you reference is expired and I am not sure what was decided.
Rfc8126 say IESG. I do not care either way. maybe Barry Leiba can provide
the current guidelines
Roni

On Tue, 4 Apr 2023 at 17:41 shuai zhao <[e-mail]> wrote:

> Hi all,
>
> Regarding the change controller, I recall it was one of the comments from
> IESG during VVC time (see attached email discussion), I copy/paste the
> relevant text below:
>
> “
>    Re the IANA registration: in recent years we have preferred to use
> "IETF" for
>    change controller, to indicate that this comes from a consensus
> document, as
>    document in
>
> https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00
> .
>    So in this case I would suggest using "IETF <[e-mail]>". I am
> ok with
>    no changes for the other review comments, thanks for the replies.
>
>    Francesca
> "
>
>
> Best,
> Shuai
>
>
>
> ---------- Forwarded message ----------
> From: Stephan Wenger <[e-mail]>
> To: Francesca Palombini <[e-mail]>, The IESG <
> [e-mail]>
> Cc: "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> Bcc:
> Date: Mon, 20 Jun 2022 15:20:10 +0000
> Subject: Re: Francesca Palombini's No Objection on
> draft-ietf-avtcore-rtp-vvc-16: (with COMMENT)
> HI Francesca,
> Thanks very much for clearing the discuss, and we will implement as
> documented below.
> Stephan
>
> On 6/20/22, 03:02, "Francesca Palombini via Datatracker" <
> [e-mail]> wrote:
>
>     Francesca Palombini has entered the following ballot position for
>     draft-ietf-avtcore-rtp-vvc-16: No Objection
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>
>
>     Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>     for more information about how to handle DISCUSS and COMMENT positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     # ART AD Review of draft-ietf-avtcore-rtp-vvc-16
>
>     cc @fpalombini
>
>     Thank you for the work on this document, and for addressing my previous
>     DISCUSSes.
>
>     Thanks for posting the media-types review request
>
> https://mailarchive.ietf.org/arch/msg/media-types/iinskT_KIviiCsmnL32ql4PuQfU/
>     and thanks to Martin Dürst for his review.
>
>     Re the IANA registration: in recent years we have preferred to use
> "IETF" for
>     change controller, to indicate that this comes from a consensus
> document, as
>     document in
>
> https://datatracker.ietf.org/doc/html/draft-leiba-ietf-iana-registrations-00
> .
>     So in this case I would suggest using "IETF <[e-mail]>". I am
> ok with
>     no changes for the other review comments, thanks for the replies.
>
>     Francesca
>
>     ## Comments
>
>     ### DONL and NALU size in figures 5 and 6
>
>     Section 4.3.2:
>     ```
>        The first aggregation unit in an AP consists of a conditional 16-bit
>        DONL field (in network byte order) followed by a 16-bit unsigned
> size
>        information (in network byte order) that indicates the size of the
>     ```
>     Which indicates DONL to be a 16-bit field, but in the figure 5 DONL
> appears to
>     be 24 bits.
>
>     ```
>        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
>     ```
>
>     Same for the NALU size: 16 bits in the paragraph above, but 24 bits in
> figure 6.
>
>     EDIT: from the authors - "Aggregation units can start and end at octet
>     boundaries.  We tried to emphasize that by having the first octet in
> the 32-bit
>     dword belonging to something else.  That’s why there’s the colon
> between bit 7
>     and bit 8.  The colon signifies the start and end of the aggregation
> unit. " I
>     suggest adding a sentence clarifying the above to avoid confusion in
> the reader.
>
>     ### Values from \[VVC\] undefined
>
>     In section 3.1.1, there are a number of values that are not defined:
> GDR_NUT,
>     CRA_NUT, IDR_W_RADL, IDR_N_LP. I understand these come from \[VVC\]
> and are
>     reported as is, however they make the text harder to parse since to
> reference
>     to these values is given.
>
>     ### Wrong reference
>
>     Section 4.3:
>     ```
>           header.  This payload structure is specified in Section 4.4.1.
>     ```
>     4.4.1 should be 4.3.1.
>
>     ### sprop-max-don-diff
>
>     sprop-max-don-diff appears first in section 4.3.1 - it would be good
> to add a
>     reference to 7.2, where its meaning is defined.
>
>     ### Base 64
>
>     In Section 7.2, Base64 is used - please specify if the encoding
> follows "Base
>     64 Encoding" (Section 4) or "Base 64 Encoding with URL and Filename
> Safe
>     Alphabet" (Section 5) of RFC 4648. (This can easily be done in one
> sentence,
>     rather than repeated everytime base64 is mentioned).
>
>     ## Notes
>
>     This review is in the ["IETF Comments" Markdown format][ICMF], You can
> use the
>     [`ietf-comments` tool][ICT] to automatically convert this review into
>     individual GitHub issues.
>
>     [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>     [ICT]: https://github.com/mnot/ietf-comments
>
>
>
>
>
>
> On Apr 4, 2023, at 7:12 AM, Stephan Wenger <[e-mail]> wrote:
>
> Hi Roni,
>
> Long time….
> Thanks for this review.
>
> As for the substance, when drafting the media type registration we started
> from the VVC registration as available from IANA (
> https://www.iana.org/assignments/media-types/video/H266).  The relevant
> part of that registration is:
>         Change controller:  IETF <avtcore&ietf.org>
>
> I also checked another recent RTP payload format for video, namely jpeg-xs
> (RFC 9134), which was published around the same time as the VVC payload
> format (https://www.iana.org/assignments/media-types/video/jxsv).  They
> use:
>         Change controller:
>         IETF Audio/Video Transport Working Group delegated from the IESG.
>
> Unless I’m missing something subtle, it looks like either change
> controller can be used, and/or no one cares.
>
> Media-types list: besides Roni, has anyone else a preference?
>
> Thanks,
> Stephan
>
>
>
>
> *From: *Ron Even <[e-mail]>
> *Date: *Sunday, April 2, 2023 at 23:13
> *To: *Stephan Wenger <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>, Bernard Aboba <
> [e-mail]>, Youngkwon Lim <[e-mail]>,
> [e-mail] <[e-mail]>
> *Subject: *Re: [media-types] Media type review request for
> draft-ietf-avtcore-rtp-evc-04
> Hi,
> I reviewed the media type registration. It looks OK but I have one comment
> about the change controller , I think it should be
>
>
>  Change controller:
>
> IETF AVTCore Working Group delegated from the IESG.
>
>
> Roni Even
>
> On Wed, Mar 29, 2023 at 9:27 AM Stephan Wenger <[e-mail]> wrote:
>
> Folks,
> The media type registration of the subject draft is in the authors’
> opinion ready for review.  It follows closely the registration of the VVC
> RTP payload format that was discussed here in June 2022, and we hope we are
> not repeating the beginners’ mistakes again.
>
> The filled-in template can be found below.
> The draft itself is here and the template is in section 7.1:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-evc/
> For reference: the media type definition for VVC (video/H266):
> https://www.iana.org/assignments/media-types/video/H266
>
> Thanks for your feedback,
> Stephan
>
> *Media type definition as to be registered with IANA:*
>
>
> Type name:            video
>
> Subtype name:         evc
>
> Required parameters: N/A
>
> Optional parameters: 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 Section 7.2
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#optionalParameters> for
> definitions)
>
> Encoding considerations:
>
> ·         This type is only defined for transfer via RTP (RFC 3550).
>
> Security considerations:
>
> ·         See Section 9
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#Security> of
> RFC XXXX.
>
> Interoperability considerations: N/A
>
> Published specification:
>
> ·         Please refer to RFC XXXX and EVC standard [EVC
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#EVC>].
>
> Applications that use this media type:
>
> ·         Any application that relies on EVC-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 [e-mail]
>
>
>
> *For completeness, section 7.2:*
> 7.2.
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#section-7.2>Optional
> Parameters Definition
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#name-optional-parameters-definit>
>
> profile-id, level-id, toolset-id:
>
> ·         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.
>
> ·         More specifications of these parameters, including how they
> relate to syntax elements specified in [EVC
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#EVC>]are
> provided below.
>
> profile-id:
>
> ·         When profile-id is not present, a value of 0 (i.e., the
> Baseline profile) MUST be inferred.
>
> ·         When used to indicate properties of a bitstream, profile-id
> MUST be derived from the profile_idc in the SPS.
>
> ·         EVC bitstreams transported over RTP using the technologies of
> this memo SHOULD 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 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.
>
> level-id:
>
> ·         When level-id is not present, a value of 90 (corresponding to
> level 3, which allows for approximately SD TV resolution and frame rates;
> for details please see Annex A of EVC) MUST be inferred.
>
> ·         When used to indicate properties of a bitstream, level-id MUST
> be derived from the level_idc in the SPS.
>
> ·         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 MUST also be supported.
>
> toolset-id:
>
> ·         This parameter is a base64 encoding (Section 4 of [RFC4648
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#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. When used to indicate properties of a bitstream, its
> value MUST be derived from toolset_idh_h and toolset_idc_l in the sequence
> parameter set.
>
> 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.P.
>
> 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-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
> encoding (Section 4 of [RFC4648
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#RFC4648>])
> representations of the sequence parameter set NAL units as specified in
> Section 7.3.2.1 of [EVC
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#EVC>].
>
> 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
> encoding (Section 4 of [RFC4648
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#RFC4648>])
> representations of the picture parameter set NAL units as specified in
> Section 7.3.2.2 of [EVC
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#EVC>].
>
> 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
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#VSEI>
> ].
>
> ·         The value of the parameter is a comma-separated (',') list of
> base64 encoding (Section 4 of [RFC4648
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#RFC4648>])
> representations of SEI NAL units as specified in [VSEI
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#VSEI>
> ].
>
> ·
>
> o    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:
>
> ·
>
> o    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.
>
> ·
>
> o    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).
>
> 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.
>
> ·
>
> o    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.
>
> ·
>
> o    Informative note: depack-buf-cap indicates the maximum possible size
> of the de-packetization buffer of the receiver only, without allowing for
> network jitter.¶
> <https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-evc-04.html#section-7.2-42.1.1.1.1>
>
>
>
>
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types
>
>
>