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

[Bernard Aboba <[e-mail]>]

Stefan said:

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

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


[BA] The specific situation that I was referring to in the notes is the
situation with WebRTC support for HEVC. It is currently supported in Safari
behind a flag, but interop has been tricky, both at the SDP and RTP
levels.  RFC 7742 covers H.264 but not HEVC, and the lack of SDP examples
in RFC 7798 has added to the vacuum.   One might cover HEVC and VVC in a
followon to RFC 7798 and do the profiling and examples there.  But having
some basic examples to draw upon would provide a foundation for that.

On Thu, Mar 31, 2022 at 3:24 PM Stephan Wenger <[e-mail]> wrote:

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