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

Dave Rice <> Thu, 25 June 2020 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C24E3A0DD4 for <>; Thu, 25 Jun 2020 10:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eCc81IaiJozu for <>; Thu, 25 Jun 2020 10:34:48 -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 E58FA3A0DE8 for <>; Thu, 25 Jun 2020 10:34:48 -0700 (PDT)
Received: from ([]:49546 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1joVlr-003ClM-IJ; Thu, 25 Jun 2020 13:34:48 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Dave Rice <>
In-Reply-To: <>
Date: Thu, 25 Jun 2020 13:34:41 -0400
Cc: Codec Encoding for LossLess Archiving and Realtime transmission <>, Spencer Dawkins at IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Murray S. Kucherawy" <>, Jerome Martinez <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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:34:54 -0000

Hi Murray,

> On Jun 25, 2020, at 1:19 PM, Jerome Martinez <> wrote:
> 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 table).
> 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.

I add line-breaks to this equation and a related one as you suggested in this commit I also reviewed other equations and moved many to code blocks and manually set the line-wrapping. This work is to be reviewed in the pull request at

Best Regards,
Dave Rice