Re: [MMUSIC] RSDP directorate review of draft-ietf-avtcore-rtp-vvc-14

[Stephan Wenger <[e-mail]>]

Hi Christer,

Thanks very much for this detailed and timely review.  Initial reactions inline.
Miska: please take a look at Q5 below and my answer.
AVTCore: please take a look at Q7 below, and my answer.  Is there interest, and are there volunteers?

Stephan

From: mmusic <[e-mail]> on behalf of Christer Holmberg <christer.holmberg=[e-mail]>
Date: Wednesday, March 30, 2022 at 11:39
To: IETF AVTCore WG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, mmusic <[e-mail]>
Subject: [MMUSIC] RSDP directorate review of draft-ietf-avtcore-rtp-vvc-14

Hi,

I have performed the SDP directorate review of draft-ietf-avtcore-rtp-vvc-14.

GEN:

In general, it is quite difficult to read and parse the SDP sections. Also, for the offer/answer procedures, we often have dedicated sub-sections for creating the offer, creating the answer, etc.

However, I will focus on things which I think are unclear.

---

Q1:

Section 7.2.1 says:

   *  The 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, max-lsr, max-
      fps, sprop-max-don-diff, sprop-depack-buf-bytes and depack-buf-
      cap, when present, MUST be included in the "a=fmtp" line of SDP.
      This parameter is expressed as a media type string, in the form of
      a semicolon-separated list of parameter=value pairs.

What does “this parameter” refer to? Do you mean “these parameters”?

---

I believe “this parameter” refers to the a=fmtp line.  Does that make sense?  If yes, we can rephrase by replacing “This parameter” with “The fmtp line”

Q2:

Section 7.2.1 says:


   *  The OPTIONAL parameter sprop-vps, sprop-sps, sprop-pps, sprop-sei,

      and sprop-dci, when present, MUST be included in the "a=fmtp" line

      of SDP or conveyed using the "fmtp" source attribute as specified

      in Section 6.3 of [RFC5576]<https://datatracker.ietf.org/doc/html/rfc5576#section-6.3>.

Why are you using the “fmtp” source attribute?

---


This was inherited from the comparable section of the H.265 payload format, RFC7798 (which most of the SDP stuff was copied from and adapted).  RFC7798 includes this informative note:

         Informative note: Conveyance of sprop-vps, sprop-sps, and
         sprop-pps using the "fmtp" source attribute allows for out-of-
         band transport of parameter sets in topologies like Topo-Video-
         switch-MCU as specified in [RFC7667].
We deleted the informative note for brevity’s sake but can reinsert it if you see a value (and if the note makes sense to you).


Q3:

Section 7.2.1 says:


      When included in

      the "a=fmtp" line of SDP, those parameters are expressed as a

      media type string, in the form of a semicolon-separated list of

      parameter=value pairs.  When conveyed in the "a=fmtp" line of SDP

      for a particular payload type, the parameters sprop-vps, sprop-

      sps, sprop-pps, sprop-sei, and sprop-dci MUST be applied to each

      SSRC with the payload type.

First, what is a “media type string”?

It’s not a term of art that I’m aware of.  Absent that, I think its definition is in the same sentence.  If “media type string” is confusing (and I think it may well be, considering that it sounds like a term of art without being one), we could simply remove “a media type string, in the form of”.  The result would read

      When included in

      the "a=fmtp" line of SDP, those parameters are expressed as

      a semicolon-separated list of

      parameter=value pairs.  When conveyed in the "a=fmtp" line of SDP

      for a particular payload type, the parameters sprop-vps, sprop-

      sps, sprop-pps, sprop-sei, and sprop-dci MUST be applied to each

      SSRC with the payload type.


Second, the “fmtp” attribute is ALWAYS associated with a particular payload type, isn’t it?

I believe so, yes.

---

Q4:

It would be very useful to have some SDP offer/answer examples.

This has come up before in the AVTCORE WG.  There are upsides and downsides to examples.  One key downside is that no few implementers have taken the presence of example as an excuse of not reading/understanding the spec, leading to botched implementations.  I’m not an implementer myself—never really was—but that’s a story I have heard often.  Therefore, we authors consciously minimized the number of examples in this spec.  As said, we discussed that in AVTCORE, last during IETF112.  Here are the relevant notes:

  5. RTP Payloads for VVC/EVC (Stefan Wenger, 15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-evc
- Stephan Wenger asked whether more complete examples of SDP Offer/Asnwer are needed, and recommends no. Simple cases already have examples.
- Bernard Aboba: Is an additional profile document needed to enable interoperability? Without this, we are seeing problems with HEVC interop.
- Mo Zanaty: examples for all complex cases are not needed, but some basic ones might help.
My recollection is that I went out of the virtual room with a clear mandate not to include more and more complex examples.  I don’t have time right now to verify that from the audio record.

In the light of this discussion, would you suggest to add more examples?

---

Q5:

Section 7.2.2.3 says:


      When dealing with VVC, the offerer assumes that the answerer will

      be able to receive media encoded using the configuration being

      offered.

And what if the answerer is not able to?

---


Once more, this is adapted from the H.265 payload format, RFC 7798, page 65 towards the bottom.  I have only a weak recollection of the reasoning.  The context of this sentence is the negotiation of sprop-max-don-diff and sprop-depack-buf-bytes.  For both of these parameters, there are reasonably low maximums that would prevent the use of the maximum range to become a serious implementation burden for a receiver.  Insofar, we require that the receiver is able to handle anything the sender could throw at him, within those hard limits of course.  Instead, these parameters are now packet stream properties that can be used to optimize/minimize playout delay in the receiver (by knowing the maximum interleaving and the maximum depacketization buffer that the sender is ever using).

Co-authors, especially Miska: I think you were deeper into this than me.  Is above about right?

Q6:

Is there a reason why Section 7.2.2.3 is not placed before Sections 7.2.2.1 and 7.2.2.2, as it applies to both?

---

Again, a copy-paste leftover and ancient RFC 7798 history.  No particular reason that I recall.

Q7:

The text says nothing (as far as I can tell) sending subsequent offers and answers within a session, and whether there are restrictions etc regarding which parameters can be modified etc.

Uh.  That’s a hard one.  Once more, our starting point RFC 7798 didn’t say anything either AFAICT, and no one complained about it.  Old payload formats for ITU codecs had somewhat similar SDP sections, and I also do not recall anyone complaining about the absence of that aspect.  Perhaps that is because most folks who use complex H.26x bitstreams negotiate them using something other than SDP.  Whatever.

I’m not against adding language, but, as it should be obvious by now, I’m far from an SDP expert or enthusiast, and AFAIK so are my co-authors.  If such modifications of existing sessions were desirable to anyone using SDP, we would need to find the right people to work towards it.  So, folks in AVTCore, is that something we should address, and who is willing to help?

---

Thanks again, Christer,

Stephan

Regards,

Christer