Re: [Cellar] AD Review: draft-ietf-cellar-ffv1

Michael Niedermayer <michael@niedermayer.cc> Thu, 09 January 2020 18:23 UTC

Return-Path: <michael@niedermayer.cc>
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 935BB120108; Thu, 9 Jan 2020 10:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 5dH8FEXx6I7M; Thu, 9 Jan 2020 10:23:41 -0800 (PST)
Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D91120104; Thu, 9 Jan 2020 10:23:40 -0800 (PST)
Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay12.mail.gandi.net (Postfix) with ESMTPSA id E9870200003; Thu, 9 Jan 2020 18:23:36 +0000 (UTC)
Date: Thu, 09 Jan 2020 19:23:35 +0100
From: Michael Niedermayer <michael@niedermayer.cc>
To: Dave Rice <dave@dericed.com>
Cc: Adam Roach <adam@nostrum.com>, draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org
Message-ID: <20200109182335.GH1173@michaelspb>
References: <b71e9496-c924-b970-9094-2b29ba173bdd@nostrum.com> <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="GBDnBH7+ZvLx8QD4"
Content-Disposition: inline
In-Reply-To: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/eUb1NWraGjqjTx7qv7iPBOXn6Pw>
Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1
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: Thu, 09 Jan 2020 18:23:44 -0000

Hi

On Thu, Jan 09, 2020 at 11:02:31AM -0500, Dave Rice wrote:
> Hi Adam,
> Thanks for your review. I have addressed some of these in a pull request at https://github.com/FFmpeg/FFV1/pull/185 and left questions or nudges to other authors below.
> 
> > On Jan 2, 2020, at 6:26 PM, Adam Roach <adam@nostrum.com> wrote:
[...]
> > ---------------------------------------------------------------------------
> > 
> > §2.2.2:
> > 
> > >  "a >> b" means arithmetic right shift of two's complement integer
> > >  representation of a by b binary digits.
> > 
> > This needs to indicate whether the resulting value is sign-extended
> > or zero-padded. We can't rely on C's definition here, as right
> > shifting a signed value is implementation-defined by the standard:
> > 
> >     The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
> >     unsigned type or if E1 has a signed type and a nonnegative value, the
> >     value of the result is the integral part of the quotient of E1 / 2E2. If
> >     E1 has a signed type and a negative value, the resulting value is
> >     implementation-defined.
> > 
> > Because this introduces an ambiguity into the specification, it will need
> > to be corrected before entering IETF last call.
> 
> I’m uncertain, nudging the other authors.

The implementation definedness can be avoided by simply refering to an implementation
and not just "C90" or other. not sure "twos complement" is strictly enough but it
may be the cleanest way to specify it.


> 
> > ---------------------------------------------------------------------------
> > 
> > §2.2.5:
> > 
> > >  a~b,c.  the 'b,c'-th value of a sequence of a
> > 
> > Please explain this with more words. I can't figure out what it means.
> 
> Same. I’m uncertain, nudging the other authors.

maybe this notation can be avoidded and array indexes [] used, iam not sure
this would work better in all cases though

Thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad