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

Jerome Martinez <> Wed, 07 October 2020 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 329883A0DE4 for <>; Wed, 7 Oct 2020 08:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.11
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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZVCApiUy7XB6 for <>; Wed, 7 Oct 2020 08:16:17 -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 5E7DC3A0C3D for <>; Wed, 7 Oct 2020 08:16:16 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 506F717BF46 for <>; Wed, 7 Oct 2020 17:16:13 +0200 (CEST)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id C050A16E25064; Wed, 7 Oct 2020 15:16:04 +0000 (UTC)
Authentication-Results:; auth=pass (GARM-95G001228cb78f-619a-4e4e-800b-6f1d137f53f8, FD998853DF21057F47A4E278FE6EA1CC7EFEAE1C)
To: Robert Wilton <>, The IESG <>
Cc:,,, Michael Richardson <>, "Peter B." <>
References: <>
From: Jerome Martinez <>
Message-ID: <>
Date: Wed, 7 Oct 2020 17:16: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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 15833530390383104109
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgeeigdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeekledvfeduhfeufeekjeevudffveduveevffehjedtjeffuefhvdevhefhudefleenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgtohhmphhrvghsshgtohhnshhulhhtrdgtohhmnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhduheekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh
Archived-At: <>
Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2020 15:16:20 -0000

Hi Robert,
Thank you for your comments. Answers inline:

On 05/10/2020 16:54, Robert Wilton via Datatracker wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> Thank you for taking the time to document FFV1 version 0, 1 and 3.
> I support Barry's discuss in that I found this document hard to read and
> interpret.  I think that I would struggle to implement a FFV1 encoder/decoded
> from scratch based on this document.  However, this is a long way outside my
> area of expertise and there is perhaps a corpus of basic video codec knowledge
> that is assumed in this specification.
> Is the intention of this document that it gets obsoleted when FFV1 version 4 is
> documented?

There is no definitive answer but I think that at long term FFV1 version 
4 specification is intended to be on IETF standard track, with the 
decoder based on the specification, and that we will remove all the 
parts specific to FFV1 version 0, 1 and 3 e.g. all the exceptions 
documented due to the spec written after the decoder and all the "if 
version is" related to previous versions, so this document would not be 
obsoleted when FFV1 version 4 is accepted as an IETF standard.

> I haven't reviewed the entirety of this document, but I do have some comments
> of particular areas of the document that I found hard to follow that additional
> text or explanation may be helpful.
> Overall, having some more introduction text explaining the overall structure of
> the encoding , i.e. how the different parts fit together would likely help
> readability.

Since the last IETF version we added a couple of  introduction texts, 
with links to other parts, hoping that it helps to clarify the 

> 3.1.  Border
>        Figure 2: A depiction of FFV1's assumed border for a set example
>                                    Samples.
> I wasn't sure whether an extra row at the bottom of this table would have been
> helpful, but perhaps it is not required because it is not referenced.

I don't get this sentence. In my opinion the figure has an arbitrary 
choice of a slice of 3x3 samples showing the dependencies between 
samples, showing the exception for the 1st and last lines and columns, 
and the references are all at the top, left or right. No bottom line 
here because the compute of the samples doesn't include any sample below 
the 3x3 samples.

> 3.2.  Samples
>     The labels for these relative "Samples" are made of the first letters
>     of the words Top, Left and Right.
> Don't feel obliged to change this, but I wonder whether keep lowercase for all
> of the relative positions might have been clearer.  E.g., perhaps using "tt"
> instead of "T" and "ll" instead of "L".

I am personally not in favor of that, the 2-letter lowercase strings 
being also used for the samples near the reference one, so in my opinion 
it makes sense to have another method for the sampls far from the 
reference one. I let another specification writer send a patch if there 
is a disagreement.

> 3.3.  Median Predictor
>     Exception for the median predictor ...
> Possibly putting the exception text into a 3.3.1 sub-section would aid
> readability.

I added this suggestion in

> 3.4.  Quantization Table Sets
> It wasn't clear to me what a "Quantized Sample Differences" is.

I added an introduction in

> 3.7.2.  RGB
>     Cb = b - g
>     Cr = r - g
>     Y = g + (Cb + Cr) >> 2
>     g = Y - (Cb + Cr) >> 2
>     r = Cr + g
>     b = Cb + g
> Perhaps split into two sets of 3 equations to define the relationship in either
> direction.

I have split the formulae in

>     Exception for the JPEG2000-RCT conversion ...
> Again, putting this into a sub-section ( might aid readability, i.e.
> the split between what is desired vs what is being described due to bugs in
> real implementations.

I added this suggestion in

> 3.8.  Coding of the Sample Difference
>     coder_input = [(sample_difference + 2 ^ (bits - 1)) &
>                   (2 ^ bits - 1)] - 2 ^ (bits - 1)
> It wasn't clear to me what [] brackets meant here.

It was for doing the difference between "near" parenthesis and "far" 
parenthesis, but maybe not a good idea.
I added this suggestion to use only parenthesis in

>  Range Binary Values
> I found this hard to follow, as in I couldn't figure out what it means.

This is the mathematical explanation behind the algorithm of Range 
Coder, without reproducing literature like in

I would not change that part because it would be hard in any case, due 
to the need of specific math skills.

>  State Transition Table
> It wasn't really clear to me what these were used for.

I added an introduction in

>  Signed Golomb Rice Codes
> Unclear what is meant by "ESC case"

I added an explanation in