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

[Stephan Wenger <[e-mail]>]

Hi Bernard, all,
Please see inline in blue.
Stephan

From: avt <[e-mail]> on behalf of Bernard Aboba <[e-mail]>
Date: Monday, August 16, 2021 at 16:08
To: IETF AVTCore WG <[e-mail]>
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?

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 <[e-mail]<mailto:[e-mail]>> 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