Re: [AVTCORE] Zaheduzzaman Sarker's Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)

[Stephan Wenger <[e-mail]>]

Hi Zahed,

Thanks for your review.  Please see inline in blue.

Stephan



On 6/16/22, 06:00, "Zaheduzzaman Sarker via Datatracker" <[e-mail]> wrote:



[…]



    The document, along with other ballot positions, can be found here:

    https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/







    ----------------------------------------------------------------------

    DISCUSS:

    ----------------------------------------------------------------------



    I would like discuss if this specification should be making stronger statement

    to enforce the reinterpretation the SDP Offer/Answer model for parameters

    sprop-max-don-diff and sprop-depack-buf-bytes.



    In section 7.3.2.3, it says sprop-max-don-diff and sprop-depack-buf-bytes

    parameter should be interpreted differently than usual interpretation of the

    parameters according to RFC 3264. This is a significant change and kind of easy

    to miss. This section does not use any normative text to enforce the change

    either.



None of us authors is an SDP expert or has much interest in SDP (anymore).  Outside of the webrtc context, few use SDP for video nowadays.  The world has moved on to Jitsi and proprietary solutions and whatnot.  The webrtc guys still use SDP but seem to have subscribed to non-ITU video codecs and Opus, at least for last several years, and I do not see that their interest in ITU codecs comes back anytime soon.  I’m writing this not to justify shortcomings, but rather to explain that the energy that went into the signaling part of this draft was quite low.  We simply copied from RFC 7798 (RTP payload format for H.265) what we thought we needed, and adjusted what needed to be adjusted.  The latter was mostly names and references, and adjustments related to the few differences between H.265 and H.266.



If it were up to us authors, we would likely have omitted the signaling part of this payload format and/or moved it to a different document, to be processed if and when the need for it is shown, and by people who know what they are doing.  However, that would have gone against a standing agreement in the AVT working group.  (I personally have objected to that standing agreement in the past, noisily so, but do not plan to bang my head against this particular wall again.)



To the subject of the DISCUSS: The concept of sender-properties (sprop) and its diverging interpretation from traditional O/A exchanges was introduced by Magnus Westerlund, goes back to RFC3984 and, at the time, has led to long and hard discussions in AVT.  That was almost 20 years back and at a time when SDP still had relevance.  I think that the sprop concept was battle-proofed then; it was used in products, 3GPP specs referenced it, and so forth. Both sprop-max-don-diff and an equivalent to sprop-depack-buf-bytes (known as sprop-deint-buf-req)  were part of RFC 3984.  Like in the subject draft, also RFC3984 contains no normative language related to their use, and the relevant language explaining their purpose is virtually identical to what we have now.  See the second bullet of section 8.2.2 of RFC3984 if you are interested.  (https://datatracker.ietf.org/doc/html/rfc3984#section-8.2.2).  I do not recall having ever received inquiries about sprop, and I also do not recall that sprop-related issues ever came up in interop events (which were, at the time conducted in places like the IMTC).

Since then, sprop-style parameters, in essentially unmodified form have been copy-pasted into every RTP payload format for NAL-unit-based video codecs.  Given that SDP is essentiality legacy technology nowadays, I would think that the handful of people that may be reading this part of the payload format spec are likely familiar with it.  The rest (like us) doesn’t care, as (like us) they will focus almost exclusively on the media plane.



Therefore, I suggest no change.



If that were unacceptable to you, then please help us with identifying a solution that satisfies your request.  I assume this would be a sentence or two early in section 7.3.2.3.



    I am also supporting Francesca's discuss.



Please see my reply to Francesca’s review from yesterday.



    ----------------------------------------------------------------------

    COMMENT:

    ----------------------------------------------------------------------



    Thanks for working on this specification. This is a big task to define payload

    format for a video codec.



    I would note that the VVC specifications are behind paywall and we are heavily

    depended on the interpretation of the authors of the actual specification here.

    I hope the specification was somehow made available to the working group to

    have a look while developing this specification. Having said that I must thank

    the authors for providing details of the video codec specification that made

    this review possible.



One other AD also complained about the VVC spec not being publicly available for free.  That is not true.  Like all ITU Recs, also this one is available for free download.  H.266 is available from here: https://www.itu.int/itu-t/recommendations/rec.aspx?rec=14948  What’s currently tricky is that the newest version (V2) is only available with an ITU TIES account.  However, we cite V1, and that can be downloaded from above page.  One will be able to download V2 from the same link as soon as the pre-publication period for V2 ends (that is: once the ITU staff has finished their editorial editing round), which should be any day now.

Now, do I recommend a reviewer to download the 500+ pages of H.266V1 and attempt to wrap their head around it, to review a payload format?  No!  It’s way too complex, long, and dense a document.  But for those who insist: it’s there, and available for free.  And yes, in the AVT WG there are a number of people who are very familiar with eth doc as they contributing in writing it.



    I have some of observations -



    -  Section 4.3.1 : what is the PayloadHdr type for the single NAL unit packet?

    is this type not needed here?



Other ADs also found this confusing.  For single NAL unit packets, the NAL unit header co-serves as the payload header, and the type field values are taken from the values specified in H.266v1, section 7.4.2.2, table 5.  Let me note here also that implementers the payload format necessarily need to be familiar with at least the high-level syntax aspects of H.266 and the structure of the H.266 spec itself.  They are most likely also familiar with earlier video codecs that use the NAL unit concept, such as H.264 and H.265, and their respective payload formats including RFC 3984 and RFC 7798.  All these formats share the same mechanism, so we expect that implementers will most likely be familiar with it.

Regardless, as pointed out to other ADs also, we plan to add informative language to clarify the above.



    -  Section 7.3.2 : actually contains both unicast

    and multicast considerations but in the beginning of the section only mentioned

    unicast.



Francesca pointed that out as well.  The problem is a clerical error with the section numbering—what is currently 7.3.2.4 should be 7.3.3.  AFAIK, Offer/Answer is not defined for multicast.  We will correct the section numbering.



-  Section 10 : I think here AVPF (RFC 4584) is the proper profile

    example than 3551. But that for this section.



Per IETF dogma, congestion control needs to be applied to any RTP session regardless of any of the defined profiles.  (The real world does not necessarily concur in my experience, but that’s another story.). Insofar, what we wrote is not wrong.  However, we can (and should) add a reference to AVPF here as well.