Re: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt(Internet mail)

"shuaiizhao(Shuai Zhao)" <> Thu, 05 November 2020 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96C3E3A13E9 for <>; Thu, 5 Nov 2020 10:49:37 -0800 (PST)
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 Ul5lPmHGGjCB for <>; Thu, 5 Nov 2020 10:49:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A78573A12AC for <>; Thu, 5 Nov 2020 10:49:34 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 17FD35A14C for <>; Fri, 6 Nov 2020 02:49:32 +0800 (CST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=s202002; t=1604602172; bh=xbWmUl01++0Qrd4ZXN9VhI0QiiVsCjpi3t3v4l5opA0=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=jIzeIzl24TLsgN71qEfyUSEQC72nhWucZ4NoMaAW1NE0QioLYhqJ9dfkCyN64Vakv dgdga5Nvtqd0C4zqngB3vbMSitT+m0NmrDez4IARb835T3BmNZ4jI+/qxrHwSNKPGq tgPa4XRNhfJ15YIgdm0ZZoVpGre8Rgvdbn8VEIiI=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 6 Nov 2020 02:49:31 +0800
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 6 Nov 2020 02:49:29 +0800
Received: from ([fe80::2871:b384:ea95:2ddc]) by ([fe80::2871:b384:ea95:2ddc%4]) with mapi id 15.01.2106.002; Fri, 6 Nov 2020 02:49:29 +0800
From: "shuaiizhao(Shuai Zhao)" <>
To: Martin Pettersson M <>, "" <>
Thread-Topic: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt(Internet mail)
Thread-Index: Adax+3XG1UYuenjlQSmSlfNmJ+iHbQBItF8A
Date: Thu, 5 Nov 2020 18:49:29 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.42.20101102
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1C5F0C833D3744938F7E16C0CF621111tencentcom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt(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, 05 Nov 2020 18:49:38 -0000

Thanks Martin for your comments,

We will for sure address your comments in next revision.

Shuai Zhao

From: Martin Pettersson M <>
Date: Tuesday, November 3, 2020 at 08:38
To: "shuaiizhao(Shuai Zhao)" <>om>, "" <>
Subject: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt(Internet mail)


Thanks for the good progress on the VVC RTP payload format. Below are some suggested modifications for your consideration:

1)      In section 3.2, add “GDR                       Gradual Decoding Refresh”

2)      In section 8.4, change “Upon reception of a FIR, a sender must send an IDR picture.” to “Upon reception of a FIR, a sender must send an IDR, a CRA or a GDR picture.”

One of the versatile features in VVC is its support for low-latency coding where the GDR picture is a key component to achieve low latency. Compared to AVC and HEVC where GDR is signaled in an SEI message with optional support by the decoder, the GDR picture in VVC is a normative part of the specification and the decoder must be able to tune in at a GDR picture. Therefore it makes sense to allow a sender to respond with a GDR picture upon receiving a FIR. Note also that a gradual decoding refresh point is mentioned as a possible Decoder Refresh Point in response to the FIR command in

Sending a CRA picture as a response to FIR would be fine as well in my opinion. I don’t see the reason to exclude that.

3)      In section 9.1, change “The I bit MUST be 1 when the NAL unit type is 7-9 (inclusive), otherwise it MUST be 0.” to “The I bit MUST be 1 when the NAL unit type is 7-10 (inclusive), otherwise it MUST be 0.”

In section 9.2, change “The I bit MUST be 1 when the NAL unit type is 7-9 (inclusive), otherwise it MUST be 0.” to “The I bit MUST be 1 when the NAL unit type is 7-10 (inclusive), otherwise it MUST be 0.”

NAL unit type 10 is GDR_NUT.

In the I bit is specified as:
I: Independent Frame (1 bit) - MUST be 1 for frames that can be decoded independent of temporally prior frames, e.g. intra-frame, VPX keyframe, H.264 IDR [RFC6184], H.265 IDR/CRA/BLA/RAP [RFC7798]; otherwise MUST be 0.

The GDR picture is typically not fully refreshed in one frame, but it does not need prior temporal pictures to start the decoding process, i.e. a bitstream that starts with a GDR picture in VVC is a valid bitstream.

Best regards,
Martin Pettersson

From: avt <> On Behalf Of shuaiizhao(Shuai Zhao)
Sent: den 2 november 2020 23:11
Subject: [AVTCORE] FW: I-D Action: draft-ietf-avtcore-rtp-vvc-05.txt(Internet mail)

In this revision, Yago’s proposal for SDP parameters were implemented in section 7.2.1.

Editor’s notes were added for things we will provide clearfication in next revision.  So do review and critisize lightly. ☺


From: avt <<>> on behalf of "<>" <<>>
Reply-To: "<>" <<>>
Date: Monday, November 2, 2020 at 14:07
To: "<>" <<>>
Cc: "<>" <<>>
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-vvc-05.txt(Internet mail)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Core Maintenance WG of the IETF.

        Title           : RTP Payload Format for Versatile Video Coding (VVC)
        Authors         : Shuai Zhao
                          Stephan Wenger
                          Yago Sanchez
                          Ye-Kui Wang
                Filename        : draft-ietf-avtcore-rtp-vvc-05.txt
                Pages           : 61
                Date            : 2020-11-02

   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.

The IETF datatracker status page for this draft is:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

Audio/Video Transport Core Maintenance<>