Re: [Cellar] Éric Vyncke's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)

Jerome Martinez <jerome@mediaarea.net> Mon, 05 October 2020 08:05 UTC

Return-Path: <jerome@mediaarea.net>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28873A0E1E for <cellar@ietfa.amsl.com>; Mon, 5 Oct 2020 01:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 EKa9acCuSCfu for <cellar@ietfa.amsl.com>; Mon, 5 Oct 2020 01:05:15 -0700 (PDT)
Received: from 10.mo179.mail-out.ovh.net (10.mo179.mail-out.ovh.net [46.105.79.46]) (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 CF1503A0E15 for <cellar@ietf.org>; Mon, 5 Oct 2020 01:05:14 -0700 (PDT)
Received: from player688.ha.ovh.net (unknown [10.108.57.245]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id DC7B917762E for <cellar@ietf.org>; Mon, 5 Oct 2020 10:05:11 +0200 (CEST)
Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 6259716BB1CC0; Mon, 5 Oct 2020 08:05:04 +0000 (UTC)
Authentication-Results: garm.ovh; auth=pass (GARM-99G0033bc0c976-45a4-4ae0-a30c-45ea28b86e0d, 8178DF97D6CAB652DFE84199EC146FBAF544A128) smtp.auth=jerome@mediaarea.net
To: =?UTF-8?Q?=c3=89ric_Vyncke?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>, "Peter B." <pb@das-werkstatt.com>
References: <160188283124.21655.15143738833011161583@ietfa.amsl.com>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <321b1372-14a0-039d-d022-0670db78c55a@mediaarea.net>
Date: Mon, 5 Oct 2020 10:05:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <160188283124.21655.15143738833011161583@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 15255662263859155053
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgedvgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpedvueegheeiiefhvefgvdfftdffkeekffetiedujedvkeelvdevieffheefgeejvdenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhdpfhhfmhhpvghgrdhorhhgpdifihhkihhpvgguihgrrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheikeekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/nDh7Sj5IGSfeqedi3N7vQ8difR8>
Subject: Re: [Cellar] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-cellar-ffv1-17=3A_=28with_COMMENT=29?=
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Oct 2020 08:05:17 -0000

Hi Éric, thank you for you review.
Answers inline:

On 05/10/2020 09:27, Éric Vyncke via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document. I found it fascinating while it
> describes the codec algorithms.
>
> Please find below a couple of non-blocking COMMENT points.
>
> I also support Alissa's point about using figure numbers/legends.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric

We added a couple of explanations and references, I hope it is easier to 
read now.

> == COMMENTS ==
>
> -- Abstract --
> May I suggest to expand/explain FFV1 on first use ? Still wondering what FFV1
> means BTW... Also, the lossless encoding is probably the key property of this
> codec and should probably be mentioned in the abstract.


I don't get the comment, as in my opinion it is fulfilled with the first 
sentence of the abstract "This document defines FFV1, a lossless 
intra-frame video encoding format." for both what is FFV1 and its 
lossless property. And it is similar to 
https://tools.ietf.org/html/rfc6716 . Could you be more explicit about 
what is missing from your point of view?
I added a definition of "FFV1" letters in 
https://github.com/FFmpeg/FFV1/pull/243
(source of the early origin, for curious people: 
https://ffmpeg.org/pipermail/ffmpeg-devel/2006-February/010315.html )

Note: we don't use the term "codec" for FFV1 itself as per 
https://en.wikipedia.org/wiki/Video_coding_format#Distinction_between_%22format%22_and_%22codec%22


> -- Section 2 --
> In an informational document, the use of BCP 14 is not required. Suggest to
> remove this part.

Even if it is an informational document so not required, we like to 
conform to it for being clear about the meaning of the related words, 
and this specification is the base of the FFV1 version 4 specification 
which is expected to be a standard document, I would prefer to keep the 
binding to BCP 14 instead of removing from this FFV1 version 0/1/3 
specification then reintroducing it in FFV1 version 4 specification, if 
not a blocking point.


> -- Section 7 --
> Should it be included in section 8 rather than referenced to?

I move section 7 in section 8, in https://github.com/FFmpeg/FFV1/pull/243

Jérôme