Re: [AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)(Internet mail)

["shuaiizhao(Shuai Zhao)" <[e-mail]>]

Dear Colleagues, -09 was uploaded addressing Stephan’s comment below. We are now left SDP O/A before it completes.


A new version of I-D, draft-ietf-avtcore-rtp-vvc-09.txt
has been successfully submitted by Shuai Zhao and posted to the
IETF repository.

Name:                    draft-ietf-avtcore-rtp-vvc
Revision:                09
Title:                       RTP Payload Format for Versatile Video Coding (VVC)
Document date:    2021-06-02
Group:                    avtcore
Pages:                    53
URL:            https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-vvc-09.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-vvc-09

Abstract:
  This memo describes an RTP payload format for the video coding
  standard ITU-T Recommendation H.266 and ISO/IEC International
  Standard 23090-3, both also known as Versatile Video Coding (VVC) and
  developed by the Joint Video Experts Team (JVET).  The RTP payload
  format allows for packetization of one or more Network Abstraction
  Layer (NAL) units in each RTP packet payload as well as fragmentation
  of a NAL unit into multiple RTP packets.  The payload format has wide
  applicability in videoconferencing, Internet video streaming, and
  high-bitrate entertainment-quality video, among other applications.

Best,
Shuai
From: avt <[e-mail]> on behalf of Stephan Wenger <[e-mail]>
Date: Wednesday, May 26, 2021 at 1:36 PM
To: "[e-mail]" <[e-mail]>
Subject: [AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)(Internet mail)

All:
We have a few editor’s notes open in the current vvc draft (https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/), and here is how we suggest to deal with some of them.  Please comment within a week or so.  Absent comments/discussions, we will rev the draft incorporating the changes.  These should be relatively easy…

Editor-note 24:  We recently had consensus on this change.  Therefore, we plan to rename the bit (“Reserved” would be a bit misleading :-) and remove the note.

Editor-note 11: the sub-profile ID, in VVC, is a 32 bit unsigned binary.   The current text suggests that binary to be represented by a base 16 RFC4648 representation.  Similar fields (binaries in VVC, such as sprop-vps, sprop-sei etc.) use base64.  Therefore, we suggest using base164 here also (it saves a byte or so) and to remove the editor’s note.

Editor-note 19: I believe we had an agreement (at least in spirit) that packetization level buffer management is unnecessary.  Based on this decision, we should remove this note, and also “condition B” in the tenth paragraph of section 6.
However, please note that the buffer management here is not related to memory usage—which I think we said is a non-issue nowadays.  Instead, it’s related to minimizing startup delay, and that’s definitely not a non-issue.  Then again, the mechanism described here has been present in the HEVC payload format for many years, and I have not seen a single system that uses it.  It could also be trivially bolted on later, in case we figure out that removing the mechanism was a mistake.  Therefore, we suggest to remove it from this draft.

Editor-note 20: we will update the example for the next revision and remove that note.

With these editor notes taken care of, we have only two left: #14 and #21