Re: [AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14--looking for help on the media type registration stuff

[Bernard Aboba <[e-mail]>]

Stephan --

You raise a good question about the usefulness of defining SDP parameters
which are unlikely to be implemented.  The RTP payload specification for
VVC has done a good job of dropping features (e.g. MRST) which were rarely
implemented, or caused interop issues. Is this another opportunity to apply
the "less is more" principle?

There is a WebRTC implementation of HEVC in Safari behind a flag, and it
seems quite possible that there will be a WebRTC implementation of VVC as
well.  RFC 7742 Section 6.2 defines the WebRTC SDP parameters for H.264,
and my understanding is that H.265/H.266 implementations are likely to take
a similar approach.  For example, RFC 7742 specifies that sprop-parameters
are always sent in-band, not signaled in SDP.

In terms of how to proceed with registering a modern codec, it does seem
that the bar has been raised.   The AV1 registration had some of the same
challenges (and frustrations):
https://www.iana.org/assignments/media-types/video/AV1

BTW, in looking through the IANA registration pages, one weird thing I
found is that a number of recent payload formats have not made their way
into the IANA registry:
Real-Time Transport Protocol (RTP) Parameters (iana.org)
<https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-2>

On Wed, Apr 13, 2022 at 9:44 AM Stephan Wenger <[e-mail]> wrote:

> Hi Murray and all,
>
>
>
> I went through Murray’s comments in a bit more detail.  Most of them are
> easily addressable and make sense to me.
>
>
>
> The one I find personally unpalatable is the need to rework the media type
> registration.  In my experience, real-world systems using any of the
> advanced features of the newer ITU video codecs use means not based on SDP
> for capability exchange.  Webrtc is nowadays mostly VP9 based, and I have
> not heard of an HEVC/RFC7798 based webrtc system using more than the
> barebones of the RFC7798 media type.  No one seems to use SIP anymore, and
> certainly(?) not in conjunction with modern codecs.  Frankly, I at least
> consider most of this section boilerplate, except for that it gives
> implementation advise for those who use jingle or whatnot.  For that, we
> don’t need template compliance.  Addressing boilerplate for boilerplate’s
> sake is annoying.
>
>
>
> What we did when drafting this section was to start with RFC7798’s media
> type registration, and adjusted from there.  It looks like RFC7798 may well
> have the same problems as this draft.  No one has ever complained about it.
>
>
>
> I wonder whether there’s anyone here on this list with a) an interest in
> VVC’s media type registration, and b) at least basic knowledge of the
> requirements of RFC6838?  If that person would step forward and help us
> with that section, I would very much appreciate it.
>
>
>
> Failing that, we will try to populate the template based on the current
> text and our (likely incomplete) understanding of the details of RFC6838.
> Which will probably lead to us getting things wrong, and in more review
> cycles.
>
>
>
> So, in short: HELP, PLEASE.
>
>
>
> Thanks,
>
> Stephan
>
>
>
>
>
> *From: *avt <[e-mail]> on behalf of "Murray S. Kucherawy" <
> [e-mail]>
> *Date: *Monday, April 11, 2022 at 10:55
> *To: *IETF AVTCore WG <[e-mail]>
> *Subject: *[AVTCORE] AD Review of draft-ietf-avtcore-rtp-vvc-14
>
>
>
> Hi all,
>
>
>
> Comments on this draft before we move it forward.  I bounced around the
> document as I went through this, checking references and whatnot, so this
> is not in any particular order.
>
>
>
> Generally, this seems to be in good shape.  Structurally, the major thing
> that needs attention is the IANA stuff.  A pet peeve of mine in documents
> these days is abuse of SHOULD, but this seems to have used it properly for
> the most part (I raised a couple of them below) so kudos there.
>
>
>
> This is an area of ART in which I'm not particularly strong, so it's
> possible there are technical issues I've missed.  I'm trusting that the WG
> and other reviewers are comfortable with how solid this is in that regard.
>
>
>
> As a reminder, I will be around for the rest of this week and then on
> vacation from IETF work until May.
>
>
>
> -MSK
>
>
>
> INTERESTING STUFF
>
> SECTION 1
>
>
>
> The first sentence of the first paragraph appears to be incomplete.
>
>
>
> SECTION 7.1
>
>
>
> This media type registration form is not complete.  Several sections are
> missing.  Please use the template found in Section 5.6 of RFC 6838.  Also,
> "Required Parameters" should be "N/A", not "None".
>
>
>
> I suggest you include the completed template in Section 11.  It can refer
> to Section 7.1 for all the details about the optional parameters, etc.
>
>
>
> The general format of this section is also confusing.  For instance, it
> gradually goes through all of the optional parameters, but then just after
> "interop-constraints", which is an optional parameter, it gets into
> "sprop-sublayer-id" which is not in the list at the top of the template.  I
> can't tell if there should be a section break here, or if the list of
> optional parameters is incomplete, or something else.
>
>
>
> SECTION 3.2
>
>
>
> This section lists "RPS" as an acronym used in this document, but it isn't.
>
>
>
> SECTION 4.3.2
>
>
>
> When would an implementation legitimately not do what the SHOULD says here?
>
>
>
> SECTION 7.2.2.3
>
> I don't understand the SHOULD here.  Can this work if an implementation
> doesn't understand all of the media type parameters?  When might one
> legitimately continue without that being the case?
>
>
>
> APPENDIX A
>
>
>
> Please add a note to the RFC Editor to delete this section prior to
> publication (which I assume is the intent).
>
>
>
> NITS
>
> SECTION 1.1.1
>
>
>
> "... the maximum size of coding tree unit ..." -- missing "a" or "the"?
>
>
>
> s/signalling/signaling/
>
>
>
> SECTION 1.1.2
>
>
>
> s/labelled/labeled/
>
>
>
> s/labelling/labeling/ (2x)
>
>
>
> s/signalling/signaling/ (2x)
>
>
>
> s/MPGEG/MPEG/
>
>
>
> SECTION 1.1.3
>
>
>
> s/signalling/signaling/ (3x)
>
>
>
> SECTION 5
>
>
>
> "... aggregation packet together one or more NAL units ..." -- missing a
> "with"?
>
>
>
> SECTION 6
>
>
>
> "... RTP sequences number ..." -- s/sequences/sequence/
>
>
>
> SECTION 7.1
>
>
>
> s/signalling/signaling/
>
>
>
> s/signalled/signaled/ (3x)
>
>
>
> SECTION 10
>
>
>
> s/achieving/achieved/
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>