Re: [video-codec] Benjamin Kaduk's Discuss on draft-ietf-netvc-requirements-09: (with DISCUSS and COMMENT)

Filippov Alexey <Alexey.Filippov@huawei.com> Thu, 13 June 2019 14:37 UTC

Return-Path: <Alexey.Filippov@huawei.com>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E17E12030F; Thu, 13 Jun 2019 07:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 X2j9koZbHBD5; Thu, 13 Jun 2019 07:37:31 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AAA75120306; Thu, 13 Jun 2019 07:37:30 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8BD80D7715F0CC3BDDAD; Thu, 13 Jun 2019 15:37:28 +0100 (IST)
Received: from fraeml704-chm.china.huawei.com (10.206.15.53) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Jun 2019 15:37:28 +0100
Received: from fraeml705-chm.china.huawei.com (10.206.15.54) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 13 Jun 2019 16:37:27 +0200
Received: from fraeml705-chm.china.huawei.com ([10.206.112.183]) by fraeml705-chm.china.huawei.com ([10.206.112.183]) with mapi id 15.01.1713.004; Thu, 13 Jun 2019 16:37:27 +0200
From: Filippov Alexey <Alexey.Filippov@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-netvc-requirements@ietf.org" <draft-ietf-netvc-requirements@ietf.org>, Mo Zanaty <mzanaty@cisco.com>, "netvc-chairs@ietf.org" <netvc-chairs@ietf.org>, "video-codec@ietf.org" <video-codec@ietf.org>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-netvc-requirements-09: (with DISCUSS and COMMENT)
Thread-Index: AQHVIevha/t94duTcEKqqE2CqdML4qaZlNzQ
Date: Thu, 13 Jun 2019 14:37:27 +0000
Message-ID: <6546942c71054cc884b6cb671cfcd918@huawei.com>
References: <156043220008.12531.8325545739299673939.idtracker@ietfa.amsl.com>
In-Reply-To: <156043220008.12531.8325545739299673939.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.198.51.251]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/video-codec/uaDmijbjc9LSd9sUEXVU11KeFnw>
Subject: Re: [video-codec] Benjamin Kaduk's Discuss on draft-ietf-netvc-requirements-09: (with DISCUSS and COMMENT)
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2019 14:37:36 -0000

Dear Benjamin, all,

Thank you a lot for commenting our draft.

> I support Roman's Discuss.
Got it and try to answer the raised question as soon as possible.

> I am sympathetic to the tsv-art reviewer's concerns that this document is focused on video technology of 5 years ago and may lack relevant in the current world.
I'd like to comment the tsv-art reviewer's concerns. According to my understanding, the review is focused on the fact that support for quality and resolution scalability is not mandatory. These types of scalability are important but usually some price in terms of compression performance should be paid for their support. So, if it is efficiently implemented in a candidate codec (i.e. "with compression efficiency penalty up to 5% of BD-rate increase per layer" as pointed out in Section 3.3.2), they will be in the main profile. Otherwise, " a separate profile is needed ...". In my opinion, supporting for quality and resolution scalability without taking into account compression efficiency penalty may prevent successful adoption of NETVC codec by industry.

Another concern raised by the tsv-art reviewer is that support for screen content coding tools is not explicitly mentioned.
I absolutely agree that absence of these tools will harm compression performance of a candidate codec. So, if these tools are not used in a codec, it can't be competitive as compared to other candidate codecs. It will become apparent while testing it (by the way, the testing draft contains screen content materials). On the other hand, we shouldn't insist on supporting for specific screen content tools that would restrict the freedom of codec developers.

Please note that these and other concerns were addressed in my response:
https://mailarchive.ietf.org/arch/msg/tsv-art/RpypjqRJD_Njens-SYwdpRRQFU0

--
Best regards,
Alexey Filippov

-----Original Message-----
From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] 
Sent: Thursday, June 13, 2019 4:23 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netvc-requirements@ietf.org; Mo Zanaty <mzanaty@cisco.com>; netvc-chairs@ietf.org; mzanaty@cisco.com; video-codec@ietf.org
Subject: Benjamin Kaduk's Discuss on draft-ietf-netvc-requirements-09: (with DISCUSS and COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netvc-requirements-09: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netvc-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's Discuss.

I am sympathetic to the tsv-art reviewer's concerns that this document is focused on video technology of 5 years ago and may lack relevant in the current world.  I don't intend to hold a Discuss point for any specific resolution, but I do think the IESG should discuss whether this concern affects the value of publishing this document as an RFC.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2.1

What do "PAM" and "RA" mean?  Moving Appendix A earlier (before Section
2) or referring to it from the Introduction would be helpful.  Note that RFC style is to expand on first use...

       . High Dynamic Range (HDR), Wide Color Gamut (WCG), high
          resolution (currently, up to 4K), high frame-rate content are
          important use cases, the codec should be able to encode such
          content efficiently.

nits: missing "and" in serial list, and the last comma is a comma splice.

Section 2.5

[Google didn't help me find reference [9].]

Section 2.6

The (long) list in Section 2.5 includes "cloud gaming"; how much overlap does that have with this service?

Section 3.1, 3.2

What is the difference between "General Requirements" and "Basic Requirements"?

ection 3.2.1

Is "Exemplary input source formats" supposed to just be an example, or an indication of the pinnacle of possible values?

Section 4.1

   Initially, for the codec selected as a reference one (e.g., HEVC or
   VP9), a set of 10 QP (quantization parameter) values should be
   specified (in a separate document on Internet video codec testing)
   and corresponding quality values should be calculated. [...]

This seems to suggest ("Initially", "for the codec selected") that the evaulation requirements are not yet complete.  Are they intended to be a single set of requirements for the codec's development, or customized to some per-application requirements?  (Is there a reference needed to ongoing work to solidify these requirements?)

   QP'k = argmin { abs(Q'i(QP'i) - Qk(QPk)) },
          i in R

I would suggest defining the argmin function.

It's surprising to see no reference to draft-ietf-netvc-testing from this document.

Section 6

I don't see much need for a "Conclusions" section of this nature, in this document.

Appendix B

Defining (e.g.) "high dynamic range" and "wide color gamut" with respect to "normal" or "conventional" mechanisms does not really provide a stable and archival reference for comparison.