Subject: Re: [AVTCORE] WGLC on “RTP Payload Format for Versatile Video Coding (VVC)”

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Sep 2021 08:48:04 -0500

Hi, Stephan,

On Mon, Aug 30, 2021 at 11:08 AM Stephan Wenger <[email-masked]> wrote:

> Hi Bernard, all,
>
> Please see inline in blue.
>
> Stephan
>
>
>
> *From: *avt <[email-masked]> on behalf of Bernard Aboba <
> [email-masked]>
> *Date: *Monday, August 16, 2021 at 16:08
> *To: *IETF AVTCore WG <[email-masked]>
> *Subject: *Re: [AVTCORE] WGLC on “RTP Payload Format for Versatile Video
> Coding (VVC)”
>
>
>
> Review of draft-ietf-avtcore-rtp-vvc-10
>
> Reviewer: Bernard Aboba
>
> Status: Ready with issues
>
>
>
> Section 1.1.2
>
>    VVC includes support of temporal scalability, by inclusion of the
>
>    signaling of TemporalId in the NAL unit header, the restriction that
>
>    pictures of a particular temporal sublayer cannot be used for inter
>
>    prediction reference by pictures of a lower temporal sublayer, the
>
>    sub-bitstream extraction process, and the requirement that each sub-
>
>    bitstream extraction output be a conforming bitstream.  Media-Aware
>
>    Network Elements (MANEs) can utilize the TemporalId in the NAL unit
>
>    header for stream adaptation purposes based on temporal scalability.
>
>
>
> [BA] I'd omit "signaling of" here, since this isn't really signaling.
>
>
>
> We can do that, but I will note that, for the high level syntax video codec implementers—which realistically are the main audience for this spec due to the tight coupling between the RTP payload and the high level syntax implementations—it surely is signaling.
>
>
>
> Section 7.2.2.1
>
>
>
> [BA] This section (for temporal) as well as Section 7.2.2.2 (for other scalability)
>
> appears to cover the negotiation of scalability structures. However, no examples of
>
> the negotiation are provided. This leads me to wonder whether the specification will
>
> in practice require a profile for seamless SVC interoperability to be achieved.
>
>
>
> When you talk profile, you mean in the sense of the H.264/SVC “profiles” developed by IMTC/UCIF of yonder?  I wouldn’t rule that out.  While we have done what we could to minimize interop points, we still have way too many to ensure interop of high performance systems if they follow different design/implementation strategies for scalability.  I think that’s inevitable given a) the tremendous flexibility of modern video scalability syntax (starting form H.264/SVC), and b) the limitations of SDP and offer/answer.  It also hasn’t slowed down any industries using scalable video in practice.
>
> I will note, though, that an offer-answer negotiation using this payload format and two sensible implementations will always (or almost always—leaving out corner cases of incompatible video profiles and such) lead to some interop point, even if that interop would fall back to non-scalable encoding.
>
>
>
> Section 4.2
>
>
>
> "          For Discussion: quite possibly something similar can be said
> for
>
>       the Layer_id in layered coding, but perhaps not in multiview
>
>       coding.  (The relevant part of the spec is relatively new,
>
>       therefore the soft language).  However, for serious layer pruning,
>
>       interpretation of the VPS is required.  We can add language about
>
>       the need for stateful interpretation of LayerID vis-a-vis
>
>       stateless interpretation of TID later."
>
>
>
> [BA] This looks like an unresolved issue.
>
>
>
> Yes, and this was also commented on by Miska, and I think we have already
> converged on how to address it.
>
>
>
> Section 7
>
>
>
> There are no complete examples of SDP Offer/Answer negotiation.
>
>
>
> Yes, and in that we follow what RFC7798 has done.  At the time, it was
> remarked that too many examples can be counter-productive towards a full
> implementation of the spec.  All too often, implementers take shortcuts by
> copy-pasting code sniplets in specs into their production implementation
> and expect that implementation to work.
>
> I’m not fundamentally against adding an example here, but I think 7798 did
> the right thing.  What does the WG think?
>

I can't speak to whether one example is "too many" examples, but

   - That was certainly the experience of the SIP community (some people
   implementing based on examples as templates and then debugging to add
   things they'd missed because the examples didn't completely describe the
   protocol that needed to be supported), and
   - I'm seeing a fair number of recent drafts that show one SDP offer,
   that includes the key SDP attributes that need to be included to explain
   what is going on, with no SDP answer, and no additional SDP material that
   would likely be present (ICE, for example) but isn't relevant to what's
   being defined in the specification.

Does that help?

Spencer

> NITs
>
>
>
> Section 1.1.2
>
>
>
>    The ideo parameter set (VPS) pertains to a coded video sequences
>
>    (CVS) of multiple layers covering the same range of access units, and
>
>    includes, among other information decoding dependency expressed as
>
>    information for reference picture list construction of enhancement
>
>    layers.  The VPS provides a "big picture" of a scalable sequence,
>
>    including what types of operation points are provided, the profile,
>
>    tier, and level of the operation points, and some other high-level
>
>    properties of the bitstream that can be used as the basis for session
>
>    negotiation and content selection, etc.  One VPS may be referenced by
>
>    one or more sequence parameter sets.
>
>
>
> How about this instead?
>
>
>
>    "The video parameter set (VPS) pertains to a coded video sequence
>
>    (CVS) of multiple layers covering the same range of access units, and
>
>    includes, among other information, decoding dependencies expressed as
>
>    information for reference picture list construction of enhancement
>
>    layers.  The VPS provides a "big picture" of a scalable sequence,
>
>    including what types of operation points are provided, the profile,
>
>    tier, and level of the operation points, and some other high-level
>
>    properties of the bitstream that can be used as the basis for session
>
>    negotiation and content selection, etc.  One VPS may be referenced by
>
>    one or more sequence parameter sets."
>
>
>
> I agree we need to fix the language, as ours included grammatical errors.
>
> A VPS can pertain to one or more CVSs, hence singular in the first
> sentence is perhaps inadvisable, and “one or more” is better.
>
> The missing comma in the first sentence can be attributed to none of us
> being native English speakers, and needs to be fixed :-).  Thanks for
> spotting.
>
> I think that were the only two differences between the original and your
> suggestion.
>
>
>
>
>
> On Mon, Aug 16, 2021 at 1:29 PM Bernard Aboba <[email-masked]>
> wrote:
>
> This is an announcement of WG last call on "RTP Payload Format for Versatile Video Coding (VVC)”.
>
>
>
> The document is available for inspection here:
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
>
>
>
>
>
> WG Last Call will end on August 30, 2021.
>
>
>
> In response, please state one of the following:
>
>
>
> * I support advancing the document to Proposed Standard
>
>
>
> * I object to advancement to Proposed Standard, due to Issues
>
> described below <Issue description or link>.
>
>
>
> Bernard Aboba
>
>
>
> For the Chairs
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>