Re: [AVTCORE] [Phishing Risk] Re: [External] Re: Comments on draft-ietf-avtcore-rtp-vvc-05.txt

Martin Pettersson M <martin.m.pettersson@ericsson.com> Fri, 06 November 2020 14:53 UTC

Return-Path: <martin.m.pettersson@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A9C3A11EA for <avt@ietfa.amsl.com>; Fri, 6 Nov 2020 06:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SAaYfuAzOrW for <avt@ietfa.amsl.com>; Fri, 6 Nov 2020 06:53:00 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40040.outbound.protection.outlook.com [40.107.4.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9E13A11EB for <avt@ietf.org>; Fri, 6 Nov 2020 06:52:59 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJUUA0GnxYee+LTnXxy007XmXuJSWJNOmzR2+2ZKUUO8NlCnGlff92Q/vcFobv7MQRjLTbSMPAA8iTnAVHRFglkZJvIyCTri6f8icFGjyJIpBmPaI1VFEvlRncFMT37HTxVdfR7JS+ZpiB6uwHbUWBjEUmc6posEilPBjHmKnlfyp5quskmJenmmmRc13VJ6dZwr/HCCkwVnUr8gh+Uzmj5oYr516l9gA6gpaD5JUrB6TlkohrTDZPtgFAvKmx29io9qshEfqpfmHzpK2SB+A437TUt3hO5WWAhYcPRVY0H4OxSxpu/4psWBqFU+6/nTfEFhysFkdOa5EdkMb+jQ8A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zF6qprlM34dvjY043wJf9jQdgafvxAXFMM70eEk0WHY=; b=aHBtbPWxppJFlyysQm+xRcsotOFQSxHxvUgQQIHjhPgQ3+YO2u6d2sqerVrVV7XURX9olvSzNA+DtXDE1nc5YW1zF+0SVTdFm1Qc/LJXtunGw0qHBVv9VKFaDF9HBNN3QYdIAVeicZZPk4JKiXIIfeF0glJ+Ylw/28oTh8nQMJoeEwAVE3bmYMakSW5LBvkrwwytuURqajbMbu0tC2I+3wel5gQrPhPLfG83wqV4zGiDUg373xiHOvCNNFqeo7sjpVpE+sth9pA0qmvnOWS5dqnR/ZoBpnOrmI8F7Ab6MIzA0B5SF8ccRK8VzsCbDtotXsM6XGgWlZg5YLwBEak6qw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zF6qprlM34dvjY043wJf9jQdgafvxAXFMM70eEk0WHY=; b=hYZgZl0mWVGPizJH7M4kpxYeU1oAG4NCtFsfW9SfNerzimGY3w2vMX12eT8PMK53KRt8w41UroL5VkBi48tZUOpglFOvoNGhgeVqJEmSnW3AIiEhB37QrkPx20NwXwd2NmkgTaSUEkN/AfCLa4uJ6WVk82owaNRFyRmhWkR+TVg=
Received: from HE1PR0702MB3642.eurprd07.prod.outlook.com (2603:10a6:7:8c::28) by HE1PR0702MB3787.eurprd07.prod.outlook.com (2603:10a6:7:8d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.14; Fri, 6 Nov 2020 14:52:39 +0000
Received: from HE1PR0702MB3642.eurprd07.prod.outlook.com ([fe80::f9da:25c:50c:dd1b]) by HE1PR0702MB3642.eurprd07.prod.outlook.com ([fe80::f9da:25c:50c:dd1b%4]) with mapi id 15.20.3541.017; Fri, 6 Nov 2020 14:52:38 +0000
From: Martin Pettersson M <martin.m.pettersson@ericsson.com>
To: Ye-Kui Wang <yekui.wang@bytedance.com>, "'Sanchez de la Fuente, Yago'" <yago.sanchez@hhi.fraunhofer.de>
CC: 'Stephan Wenger' <stewe@stewe.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] [Phishing Risk] Re: [External] Re: Comments on draft-ietf-avtcore-rtp-vvc-05.txt
Thread-Index: AQHWs81Nk1K4Xs+O1EWjarimimqgaam6xl6w
Date: Fri, 6 Nov 2020 14:52:37 +0000
Message-ID: <HE1PR0702MB36428650A8ECE9D1B2AD3C33CAED0@HE1PR0702MB3642.eurprd07.prod.outlook.com>
References: <HE1PR0702MB36425058B8AEE97940A0C736CA110@HE1PR0702MB3642.eurprd07.prod.outlook.com> <3584D9AA-D447-4F5C-9302-AD07629B838D@stewe.org> <1eaa01d6b3b5$64584fd0$2d08ef70$@bytedance.com> <EBD3EEA4-4A18-4063-8F98-A3A4A2FF7ECD@hhi.fraunhofer.de> <205101d6b3cd$42453df0$c6cfb9d0$@bytedance.com>
In-Reply-To: <205101d6b3cd$42453df0$c6cfb9d0$@bytedance.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: bytedance.com; dkim=none (message not signed) header.d=none; bytedance.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [31.208.187.131]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4140be11-86ee-4ac9-0232-08d882639a9a
x-ms-traffictypediagnostic: HE1PR0702MB3787:
x-microsoft-antispam-prvs: <HE1PR0702MB37878E3A91EF9FEC0530BD5CCAED0@HE1PR0702MB3787.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VaM4dJbvpSpfUtyGRoKxIgP9kz2C/z4Yp5+9MJi3It6bmwEOYyZIljTmFHATA2v3rDUgAAW+R9bepwDvR8E/XsaOURA15oA5HdoPt1a0/zY/KtgUkSH1BHl+3vzUh7WkHJ3doWD9o76LUUf7HeTDvm6yodYN8CzFdVLyelxgAIY5fQ0V2RwX0zIn8rDi3xu+EoZ3RLZeOVoibhMBqN+nLf0gyW5xext2FrydtVLfyQhMJhB3Q6gI4/QkytzP2gUu5pXqPmZBXi1ju87Uwv+dFdXQ0639MNdP1BRhuYuPt/0WJpe2liP4iJxq4SSHmRNg65KOCtkF7kLN5ooJcdqmbwCH0ZM2HBMJOIoJ1oyX8WTT41vsVSzmBKnlH1xBg5bGEMCpIDQ2sAkPo8wbOoUDQJGiSgP/agd67PxHZCGHXAHP8GYwicdWufvJYomQwr5DX0L+WAjdAL+LoAppszt5hQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3642.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(376002)(346002)(136003)(396003)(83380400001)(110136005)(54906003)(33656002)(316002)(76116006)(66946007)(86362001)(83080400002)(66476007)(66556008)(64756008)(66574015)(66446008)(8676002)(2906002)(5660300002)(478600001)(21615005)(30864003)(166002)(52536014)(186003)(26005)(7696005)(6506007)(53546011)(55016002)(4326008)(9686003)(71200400001)(8936002)(966005)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 6TWUvF2bwj/Vosa1CtKmnzaOpHWWso+kbLXa+gnDN0zpvyPjwkDPQhEPmiX1lUxWLlUZQJFNbKXkHuAyJwu3IriMiFkGmlk/yhRr6XQoxtLEvIoO44XfrLhZnPF/Q9cRxwIJg1rOerrrLd/mzNctKogWrAuom8Jqmmw6nYC0wTWxc5LZRtTSeiDqBMldSFa3ry0vcrsfdt1GZcFGSdm0UD3kI+hX/t+3o38PxfsUgR86WzDm1X18swygVDHVdxDcCI+l7pf/Btt6YKaKp1nMawu3jwWkU9NKS+l6smrmsgMpxQjiYUCVWfozfeA8K/GPQGb6z75CrFkf9/4+Jj62XV0H++HpcY6lYFu4wSAyuoDG/KI2vpC9DJCy5biB56rgvzTIMow+c/24xITvfgFGMGVGe1S30VAoKpjSGJuP6CG5RDLA3dliNabPXDjE86OZiOptY1nMEZhmsM/BBCRHatvrACgjQ1ynaxGGk8n3kCuj5pK3/Qwyd8eRhTYnb5D8wOMJwYgUDXNXE6JzfhGxboniEcWxXTR6PrW1lYahYJ4IBmVM8g+G9fcMC94qHasQwQDeJD5TB6BLJFSI1T4by5lEWwErjWPGP/OXYxAht8Chksh+skipmRxFYrHvc1FDfhVCgsyAmodgSzmHrGlLaSMMlqHNmlycMg4GjbphWeznILaX1MG1kxlW6X+I1jmcOmeDhirC/nj3PWxL8X3FJgGbTC07H97XAnx0pspUScVeMsN7lE6BFY/4brsnRNbnNzGG2yr+BcbDQV2z/rvbvug0CEGyCrpyTUKUmdYanI83bWtSZk6DppBpkNoTh38m1wx/lYngAV0wAbtpRCbXBRmbNJFS5QbXmC0R/fv4573SYraltrVgCcOw5YoTQMiEG70XIVpUBcAN0ziumu09XQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36428650A8ECE9D1B2AD3C33CAED0HE1PR0702MB3642_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3642.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4140be11-86ee-4ac9-0232-08d882639a9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2020 14:52:37.8763 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hOjgpA6zWPNXPJ79R/e9uglhtTOAYv88lpa9mLy/dUgqV4Y5h5bw31verCuq0ywVmBYbSzpJarziwiQsNJeXS8n/rbccFSnV0+kc5QmSSLxQboiPERFh0PNQ1QwJUhGb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3787
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/yfJhPOAnVZz0C4PXyULZ0agUl4o>
Subject: Re: [AVTCORE] [Phishing Risk] Re: [External] Re: Comments on draft-ietf-avtcore-rtp-vvc-05.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 14:53:05 -0000

Thanks Ye-Kui, Yago and Stephan for all the good comments. Please see my responses below.



FIR message for CRA pictures



Thanks Ye-Kui for clarifying why CRA pictures were not allowed as a response to a FIR message for HEVC. I agree that it would not be necessary for a sender to send a CRA picture instead of an IDR picture as a response to a FIR message (although I don’t see the harm in allowing it).



FIR message for VVC GDR pictures



> Firstly, regarding the suggestion of changing “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.” Herein, my hesitation is because that a FIR, as the name indicates, requests a full intra picture that immediately

> stop any prediction from earlier pictures, hoping that once this is received by the receiver, all pictures and all picture areas are correct. GDR won’t do

> that. And note that we are also in a low delay environment, using GDR would need the receiver to wait much longer (than using IDR) to have correct full

> pictures. Note that rfc5104 also mentions that using GDR the user experience would not be as good. My personal opinion is, if using GDR were really

> acceptable, we would have added that in RFC 7798 (the HEVC RTP payload format), even though in HEVC GDR is indicated by the recovery point SEI

> message instead of by a NAL unit type as in VVC.



I think that the key aspect for GDR in VVC compared to the previous standards is that the GDR picture is now normative and fully specified in VVC as pointed out by Stephan. Thus, every VVC decoder would be required to tune in at a GDR picture, which is far from guaranteed for HEVC and AVC where a non-normative SEI message is used. Moreover, when tuning into a GDR picture in VVC, the recovery point picture and the following pictures are guaranteed to be an exact match to as if the decoding had started at an IRAP picture prior to the GDR picture. For HEVC and AVC, the exact match is not guaranteed. Thus, I would expect the user experience to be much better for VVC than for HEVC and AVC.



I agree with you Ye-Kui, that there may be an expectation in some circumstances from the receiver sending the FIR message that the response from the sender should be a picture that may be directly decoded and displayed. As a suggestion to address the expectations of the receiver, an option could be to allow a receiver to request whether the Decoder Refresh Point needs to be an IDR picture, a GDR picture or any of the two. This may be either specified as a parameter in the FIR message or as a new request message, e.g. a refresh request message.



Frame marking for GDR pictures



Ye-Kui:

> Thirdly, including GDR to the I bit constraint confuses both the name and the semantics of the bit, “independent of temporally prior frames”. To me, if

> an indication of GDR is important, that should be included in draft-ietf-avtext-framemarking, preferrable using a separate indication, and if so, it should

> also include GDR in AVC and HEVC indicated by the recovery point SEI message, and then in this draft carries that over in the same way as carrying over

> the I bit. (BTW, Shuai, we should update the status of the [FrameMarking] reference.)



Yago:

> As for the I bit I agree with Ye-Kui that it seems cleaner to me that if an indication of GDR is desirable, a separate indication could be included in

> draft-ietf-avtext-framemarking instead of reusing  the existing one that states that a frame is independent. However, should we allow or disallow GDR

> pictures with ph_recovery_poc_cnt equal to 0 for this case?



I agree that it may cause confusion and that it would make sense to have a separate indication for GDR pictures in draft-ietf-avtext-framemarking as suggested.



But if we decide to not mark GDR pictures with the I-bit, then I think the semantics for the I-bit in draft-ietf-avtext-framemarking need to be rephrased as I think it would otherwise cause confusion the other way.



“I: Independent Frame (1 bit) - MUST be 1 for frames that can be decoded independent of temporally prior frames”



As it is stated now, in my interpretation, it suggests that GDR pictures must have the I-bit set since a GDR picture can be decoded (i.e. the decoding could be started) without using any temporally prior frames. In particular, for a GDR picture with recovery_poc_cnt equal to 0, the GDR picture can be fully decoded without dependency on any other frame.



BR, Martin





From: avt <avt-bounces@ietf.org> On Behalf Of Ye-Kui Wang
Sent: den 6 november 2020 00:42
To: 'Sanchez de la Fuente, Yago' <yago.sanchez@hhi.fraunhofer.de>
Cc: 'Stephan Wenger' <stewe@stewe.org>rg>; avt@ietf.org; 'Martin Pettersson M' <martin.m.pettersson=40ericsson.com@dmarc.ietf.org>
Subject: Re: [AVTCORE] [Phishing Risk] Re: [External] Re: Comments on draft-ietf-avtcore-rtp-vvc-05.txt



Hi Yago,



Regarding GDR pictures with ph_recovery_poc_cnt equal to 0, my opinion is similar as for CRA pictures, i.e., if as an encoder to response to a FIR, there is no reason for the encoder to encode an intra refresh picture as CRA or GDR with ph_recovery_poc_cnt equal to 0 instead of as IDR.



BR, YK



From: Sanchez de la Fuente, Yago <yago.sanchez@hhi.fraunhofer.de<mailto:yago.sanchez@hhi.fraunhofer.de>>
Sent: Thursday, November 5, 2020 13:12
To: Ye-Kui Wang <yekui.wang@bytedance.com<mailto:yekui.wang@bytedance.com>>
Cc: Stephan Wenger <stewe@stewe.org<mailto:stewe@stewe.org>>; Martin Pettersson M <martin.m.pettersson=40ericsson.com@dmarc.ietf.org<mailto:martin.m.pettersson=40ericsson.com@dmarc.ietf.org>>; shuaiizhao(Shuai Zhao) <shuaiizhao@tencent.com<mailto:shuaiizhao@tencent.com>>; avt@ietf.org<mailto:avt@ietf.org>
Subject: [Phishing Risk] Re: [AVTCORE] [External] Re: Comments on draft-ietf-avtcore-rtp-vvc-05.txt



Dear Ye-Kui, all,



After reading Ye-Kui’s email I thought again about my previous Email and even using GDR pictures with ph_recovery_poc_cnt equal to 0 would be questionable as a response for a FIR since in that case the same picture could have a NAL unit type of IDR. Same reasoning as Ye-Kui gave for CRA, there is no good reason for the encoder to encode an intra refresh picture as GDR pictures with ph_recovery_poc_cnt equal to 0 instead of as IDR if it could be an IDR.



As for the I bit I agree with Ye-Kui that it seems cleaner to me that if an indication of GDR is desirable, a separate indication could be included in draft-ietf-avtext-framemarking instead of reusing the existing one that states that a frame is independent. However, should we allow or disallow GDR pictures with ph_recovery_poc_cnt equal to 0 for this case?



Best regards,

Yago Sánchez



---

Department Video Coding & Analytics

Group Multimedia Communications

Fraunhofer HHI - Heinrich Hertz Institute
Einsteinufer 37, 10587 Berlin, Germany
http://www.hhi.fraunhofer.de/ip/mc<https://protect2.fireeye.com/v1/url?k=a723debd-f8b8e4f8-a7239e26-867b36d1634c-f397f8517be49b2f&q=1&e=525becb6-dd97-448d-a358-26fbd8ac83f5&u=http%3A%2F%2Fwww.hhi.fraunhofer.de%2Fip%2Fmc>

Tel.: +49 30 310 02663

yago.sanchez@hhi.fraunhofer.de<mailto:yago.sanchez@hhi.fraunhofer.de>







   On 5. Nov 2020, at 21:51, Ye-Kui Wang <yekui.wang@bytedance.com<mailto:yekui.wang@bytedance.com>> wrote:



   Hi Martin, Stephan, All,



   I was also hesitating to say yes when I first saw most of the suggestions, so hesitating such that I was hoping Stephan et al would reply and address them 😊



   Great that Stephan did respond. Thanks!



   Now a few additional comments from my side.



   Firstly, regarding the suggestion of changing “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.” Herein, my hesitation is because that a FIR, as the name indicates, requests a full intra picture that immediately stop any prediction from earlier pictures, hoping that once this is received by the receiver, all pictures and all picture areas are correct. GDR won’t do that. And note that we are also in a low delay environment, using GDR would need the receiver to wait much longer (than using IDR) to have correct full pictures. Note that rfc5104 also mentions that using GDR the user experience would not be as good. My personal opinion is, if using GDR were really acceptable, we would have added that in RFC 7798 (the HEVC RTP payload format), even though in HEVC GDR is indicated by the recovery point SEI message instead of by a NAL unit type as in VVC.



   Secondly, on adding CRA. Herein my hesitation is because CRA is not really supposed to be used in low-delay conversational application environment. If as an encoder you don’t plan to have some associated leading pictures encoded for a CRA picture, there is no reason for the encoder to encode an intra refresh picture as CRA instead of as IDR. That’s why we did not allow CRA as a response to FIR in RFC 7798.



   Thirdly, including GDR to the I bit constraint confuses both the name and the semantics of the bit, “independent of temporally prior frames”. To me, if an indication of GDR is important, that should be included in draft-ietf-avtext-framemarking, preferrable using a separate indication, and if so, it should also include GDR in AVC and HEVC indicated by the recovery point SEI message, and then in this draft carries that over in the same way as carrying over the I bit. (BTW, Shuai, we should update the status of the [FrameMarking] reference.)



   However, adding the GDR abbreviation is good, and I think we should also add a brief description of GDR into clause 1.1.2 (Systems and Transport Interfaces).



   BR, YK



   From: avt <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> On Behalf Of Stephan Wenger
   Sent: Thursday, November 5, 2020 10:50
   To: Martin Pettersson M <martin.m.pettersson=40ericsson.com@dmarc.ietf.org<mailto:martin.m.pettersson=40ericsson.com@dmarc.ietf.org>>; shuaiizhao(Shuai Zhao) <shuaiizhao@tencent.com<mailto:shuaiizhao@tencent.com>>; avt@ietf.org<mailto:avt@ietf.org>
   Subject: [External] Re: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt



   Hi Martin,



   Thanks for those suggested changes, which I think would consistently implement the option to react to a “Full Intra Request” (FIR) with a gradual decoder refresh (GDR) series of pictures.



   As to whether we should allow GDR as a reaction to a FIR: I’m a bit torn here.  Arguments can be made either way, please see below.  Would others in the WG please weigh in?



   On one hand, the argument (somewhat rephrased here) that VVC’s GDR pictures are a fully specified replacement for traditional “all intra” pictures is a good one.  I concur that this is somewhat new in VVC, compared to older video coding standards.  Pretty much all of those could do some form of GDR (even good old H.261 and MPEG-2), but things were clumsy, results were not guaranteed, or one had to rely on SEI messages and similar exotics for implementation.  In the environments where FIR matters—video conferencing mostly—no one ever used GDR in any context except in those ca. 1990 H.261-based systems which didn’t implement full intra pictures at all, and relied on intra macroblock walk-around during the initial communication setup.



   On the other hand, there’s a reason why FIR until now was consistently interpreted as a requirement of sending a single “all intra” picture (whatever that translates to in the various video coding standards and technologies).  That reason was related to the architecture of the MCUs that were around when RFC 5104 was written, back in the 2005-2008 timeframe.  What people requested then was that the internal architecture of an MCU should stay as independent of the codec in use as possible.  For FIR, that means that means: if an MCU sends out a FIR to a sending endpoint, it expects exactly one intra picture at the earliest opportunity that can be used to sync in added decoders of unknown state.  That logic would now have to change to receive either a single IDR picture or a series of pictures that make up a GDR.  A transcoding MCU would have to go further and include the decoding of those multiple pictures with all the tricky (though now fully specified!) stuff that goes on in VVC, before transcoding.



   Stephan





   From: avt <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> on behalf of Martin Pettersson M <martin.m.pettersson=40ericsson.com@dmarc.ietf.org<mailto:martin.m.pettersson=40ericsson.com@dmarc.ietf.org>>
   Date: Tuesday, November 3, 2020 at 08:38
   To: "shuaiizhao(Shuai Zhao)" <shuaiizhao@tencent.com<mailto:shuaiizhao@tencent.com>>, "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>
   Subject: [AVTCORE] Comments on draft-ietf-avtcore-rtp-vvc-05.txt



   Hi,



   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.”



   Motivation:

   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 https://tools.ietf.org/html/rfc5104.



   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.”



   Motivation:

   NAL unit type 10 is GDR_NUT.



   In https://tools.ietf.org/id/draft-ietf-avtext-framemarking-09.html 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 <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> On Behalf Of shuaiizhao(Shuai Zhao)
   Sent: den 2 november 2020 23:11
   To: avt@ietf.org<mailto:avt@ietf.org>
   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. ☺



   Best

   SZ



   From: avt <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> on behalf of "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
   Reply-To: "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>
   Date: Monday, November 2, 2020 at 14:07
   To: "i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>" <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
   Cc: "avt@ietf.org<mailto:avt@ietf.org>" <avt@ietf.org<mailto:avt@ietf.org>>
   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



   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.





   The IETF datatracker status page for this draft is:

   https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/



   There are also htmlized versions available at:

   https://tools.ietf.org/html/draft-ietf-avtcore-rtp-vvc-05

   https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc-05



   A diff from the previous version is available at:

   https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-vvc-05





   Please note that it may take a couple of minutes from the time of submission

   until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.



   Internet-Drafts are also available by anonymous FTP at:

   ftp://ftp.ietf.org/internet-drafts/





   _______________________________________________

   Audio/Video Transport Core Maintenance

   avt@ietf.org<mailto:avt@ietf.org>

   https://www.ietf.org/mailman/listinfo/avt





   _______________________________________________
   Audio/Video Transport Core Maintenance
   avt@ietf.org<mailto:avt@ietf.org>
   https://www.ietf.org/mailman/listinfo/avt