Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt

Jerome Martinez <> Thu, 25 June 2020 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E138B3A0CF5 for <>; Thu, 25 Jun 2020 10:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 szCQ0aT5hHNA for <>; Thu, 25 Jun 2020 10:19:47 -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 544A83A0DA1 for <>; Thu, 25 Jun 2020 10:19:46 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id E09E9144858 for <>; Thu, 25 Jun 2020 19:19:44 +0200 (CEST)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 66439FB4491B; Thu, 25 Jun 2020 17:19:42 +0000 (UTC)
Authentication-Results:; auth=pass (GARM-95G00186fd6e9e-dc37-4583-aac1-2b87e1793eb5, 0F666F60943D4F5378C79FE86E6D7543643A00EC)
To: "Murray S. Kucherawy" <>
Cc: Spencer Dawkins at IETF <>, Codec Encoding for LossLess Archiving and Realtime transmission <>
References: <> <> <>
From: Jerome Martinez <>
Message-ID: <>
Date: Thu, 25 Jun 2020 19:19:42 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------1D2D3C3080D7B8D1073A3A7B"
Content-Language: en-US
X-Ovh-Tracer-Id: 15902210288158904465
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudekledgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepjefgtdetudetffffvdeuveeugffgkeekvddtveeuueeivefhleegleegteekvefhnecuffhomhgrihhnpehivghtfhdrohhrghdpihhtuhdrihhnthdpghhithhhuhgsrdhiohenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheehrdefgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleejrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh
Archived-At: <>
Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt
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: Thu, 25 Jun 2020 17:19:50 -0000

Hi Murray,

My answers inline:

On 25/06/2020 18:24, Murray S. Kucherawy wrote:
> Hi, thanks for this.  I'm looking now only at the diff between -13 
> (the last version I looked at) and this one.
> First and foremost, this is mostly better.  Kudos for putting the work in.
> Hooray, most of those "type" columns are gone!  But, alas, not all of 
> them.  They're still present in Sections 4.1 and below. I counted at 
> least seven of them just in the diff I'm reviewing.  As before, they 
> should also be removed, or at least explained.
> A minor point: Prior to Section, it looks like all of the 
> examples are in C.  After that, they switch to pseudo code.  Any 
> reason we can't be consistent?

The figures before section 4 are autonomous functions, used for 
describing a part of the algorithm and not used for directly reading out 
any symbol from the bitstream, so it was making sense to remove the 
"type" column at these places (this column was not used there). They 
could be more pseudocode nonetheless, as the C types ("int" etc) are not 
really relevant (they depends on the programming language).

The figures in section 4 are for explaining the bitstream parsing order, 
and the "type" column is used for indicating the kind of value it is 
(types are described in , I see 
that it is called "Symbol" here, we'll change "Symbol" to "Type" in this 
This kind of method for describing a video bitstream is very classic, 
for example in:
- H.264, see the full spec (PDF to download)
- AV1, see an online direct example at

As in theses specs, we have some figures without usage of the "type" 
column because they are intermediate figures (the "type" column is used 
in the figures using this figure and the figures called by this figure), 
split from another figure, in order to have the spec more readable 
(focusing on a specific topic). AV1 uses it for example at

> I suggest that the prose below Table 8, which is a mix of pseudocode 
> and English, would be better broken apart.

We'll try to find a better wording for this line.

> Chairs: RFC 4732 is a downref; please make sure the shepherd calls 
> this out in the writeup.

(Removing my question as Spencer answered my question before I send it :-p )

> There are a few code expressions that would benefit from being wrapped 
> differently.  For example:
> (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height
> / (1 << log2_v_chroma_subsample)) : slice_pixel_height
> Maybe this?
> chroma_planes == 1 && (p == 1 || p == 2)
>   ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
>   : slice_pixel_height

It is on a full line in the specification source code, I see that the 
raw text version and the HTML version have different automatic line 
break position, we'll force some line breaks.