Re: [Cellar] draft-ietf-cellar-ffv1-13 comments

"Murray S. Kucherawy" <> Thu, 30 April 2020 01:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CE853A0CB4 for <>; Wed, 29 Apr 2020 18:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MXmIG7UTRqYh for <>; Wed, 29 Apr 2020 18:51:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 774B03A0CE3 for <>; Wed, 29 Apr 2020 18:51:47 -0700 (PDT)
Received: by with SMTP id a7so1763121uak.2 for <>; Wed, 29 Apr 2020 18:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tIDh8ylD1I+sGbVemk65KjWDEB0R8s/Po+x60ZDU8Jg=; b=Mp4Ycsetk1U5FHhvYDq3P7M4qc96Kp6ztnfQw1Zx09HSa2l4z0supNRtPZJQDvPkpp gfdVoNcOn260f0twBkgBBGLl32oxm1qUuyr3mmcmUUivRkzmRDGZi3swBK+ewa+74AaL T0+ZuON1PSpmbPifzcdg6hL5FdPIZvaUKnf5rXoDKtENrZpH5fnX9R9wTZkTxz+3C1Un igpIU5Cisr8qPipXFPSvJ0W+l2LpdL5J9C2FI9TuzxVRGvt09/VpcpdCUnaDky/VxNYU wicYrSxdOAZjzouMU1ciAdNWOrO536eBwgH8kJx5RiiJxT2RuaWjgyeqYur1oMbEKJcw LXNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tIDh8ylD1I+sGbVemk65KjWDEB0R8s/Po+x60ZDU8Jg=; b=OJItuI9HRG/jMBIpncMnKofIaXNQOT+gObwQQGvqQqvTLoy9wzyj+lYP9+wY1fZbMV etH0aHVLFIT95XUvBih6wpEzJygklMcE+LL4W8NrEUIly0kq0NIwDh+s+htZFikZE/yk VAJMhyRkqwft/6IjzNeOVV1CElsQMndNbNgVLxEL/cNdYwwzesSIY1RLCB7nIgzJYGc9 mO5r9Wu3gxqCbYvc88MvFi0PhmgaP13+FqXpA2T22LQB9aVN2Gx2ICAq/hbgMw4s1NKA 5I4+IlPC4I49SvijQUPPXaZjxX4G1xu4m5JPFk3vrQ8UTNddzOlcnbUw7QTO/1x3vSPy 0BYw==
X-Gm-Message-State: AGi0PuYAnd+GnaE3APWJHMdxhgoE6HcuGzp2ZnlDDpZzn1c0dcQeQFDj O0/PTswqEk3NKAO4hk0IzzEqwk+kQWRrAhksPurPc59l2is=
X-Google-Smtp-Source: APiQypIOpJhgVy0f6j0TkgjCRRevMFNGVPka8oUX5BItiZfCGEZXGuKWljdjcKFYHpeJGlJzVx9Akz0RMTdJUJsgW84=
X-Received: by 2002:ab0:4503:: with SMTP id r3mr618117uar.101.1588211506290; Wed, 29 Apr 2020 18:51:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Wed, 29 Apr 2020 18:51:34 -0700
Message-ID: <>
To: Jerome Martinez <>
Cc:, Adam Roach <>
Content-Type: multipart/alternative; boundary="000000000000a9240805a4784e77"
Archived-At: <>
Subject: Re: [Cellar] draft-ietf-cellar-ffv1-13 comments
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, 30 Apr 2020 01:51:50 -0000

On Wed, Apr 29, 2020 at 1:48 PM Jerome Martinez <>

> Section
> * Same issue about "value".
> Murray, I didn't get it (no comma there)

Sorry, disregard.  This referred to an issue I had with an earlier section
but I changed my mind, and deleted that one but forgot to delete this one.

> Section
> * "AVI " should be just "AVI" (i.e., remove the trailing space)
> Murray, the "trailing" space is required. It is a part of a 4-letter
> identifier found in AVI files (0x41564920 in hexadecimal).
Interesting.  You might want to make that clear, because I expect the RFC
Editor will have exactly the same question.

> Section 4.6:
> * Another table with an empty "type" column.  I think I see now that the
> column is populated against each line that outputs something, but can it
> not just be omitted when there's no output to the function?
> Same as with other tables.
> * But does this function really output nothing?
> Murray, not sure I understand the question.
> This function read nothing from the input, and call Line() which calls
> Pixel().
> It is in a standalone pseudo-code block for an having blocks easy to
> understand (SliceHeader(), SliceContent(), SliceHeader()).
> SliceContent() could move into Slice() but IMO it is less readable.

This goes back to not understanding how to interpret these these "type"
columns.  But also, this is another place where a forward reference to
Line() would be helpful.  And then down in Line(), there are lines of
pseudo-code that appear to be standalone array references.  In the table in
Section 4.1, those lines have types, which I thought means there's some
output happening.  Is that not the case here?  If not, then this is a
nested set f function calls that do some computation but don't appear to
yield anything.  That's why I'm confused here.

Sections 4.6.1 through 4.6.4:
> * Same comment as before about inline formulae.
> Fixed.
> But it means that all is in one chapter, IMO it is a lot of formulae.
You don't have to put them all in one chapter.   I was thinking of just
this for 4.6.1, for example:

"primary_color_count" is defined as:

    1 + ( chroma_planes ? 2 : 0 ) + ( extra_plane ? 1 : 0 )

That even parses in C. :-)