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

"shuaiizhao(Shuai Zhao)" <> Thu, 03 June 2021 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A86063A219E for <>; Wed, 2 Jun 2021 17:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ULOGNdywzWvy for <>; Wed, 2 Jun 2021 17:31:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D7483A21A1 for <>; Wed, 2 Jun 2021 17:31:14 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id A904B5A2E1 for <>; Thu, 3 Jun 2021 08:31:09 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=s202002; t=1622680269; bh=B5S5DbQUrAE4N7LiN2fI/CBfcxMHxcOamQ6fQ9xkQa8=; h=From:To:Subject:Date:References:In-Reply-To; b=UXg6pbqtRC6kUun8PBLvqaSvn+9VgjuoY+rjOEdt64MMVbVTETzJWmmSKtSY1maI8 Qb1QSIHQVTqkJKGeUpo1wZt2yhG/B3KnW/A+1lwKVOtDCx4h3gbAp+JoPS89TaF1av nQXltXl06q/gH+oNq7hzl6oKwhsZwyVf758+Qjag=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 3 Jun 2021 08:31:09 +0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 3 Jun 2021 08:31:07 +0800
Received: from ([fe80::f458:deab:626d:4d6a]) by ([fe80::f458:deab:626d:4d6a%4]) with mapi id 15.01.2242.008; Thu, 3 Jun 2021 08:31:07 +0800
From: "shuaiizhao(Shuai Zhao)" <>
To: "" <>
Thread-Topic: [AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)(Internet mail)
Thread-Index: AQHXUm6yNcyd4tVOU0Cex59ZdFHkrqsAfyWA
Date: Thu, 3 Jun 2021 00:31:07 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.49.21050901
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2C5B7869040741199F4310E98129341Dtencentcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [AVTCORE] VVC payload format, open issue cluster #3 (editor-notes #24, #11, #19, and #20)(Internet mail)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Jun 2021 00:31:20 -0000

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

  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.

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

We have a few editor’s notes open in the current vvc draft (, 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