Re: [Cellar] AD Review: draft-ietf-cellar-ffv1
Michael Niedermayer <michael@niedermayer.cc> Tue, 28 January 2020 21:24 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 79765120106; Tue, 28 Jan 2020 13:24:07 -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 IvUka3oGx4hY; Tue, 28 Jan 2020 13:24:05 -0800 (PST)
Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1E512011F; Tue, 28 Jan 2020 13:24:04 -0800 (PST)
Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 934F7240003; Tue, 28 Jan 2020 21:24:01 +0000 (UTC)
Date: Tue, 28 Jan 2020 22:24:00 +0100
From: Michael Niedermayer <michael@niedermayer.cc>
To: Adam Roach <adam@nostrum.com>
Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org
Message-ID: <20200128212400.GN1173@michaelspb>
References: <b71e9496-c924-b970-9094-2b29ba173bdd@nostrum.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7R/oUIX7ilUHG0fO"
Content-Disposition: inline
In-Reply-To: <b71e9496-c924-b970-9094-2b29ba173bdd@nostrum.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/9I1sa3AkYRMZukINIOoL-SLgNkI>
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: Tue, 28 Jan 2020 21:24:11 -0000
On Thu, Jan 02, 2020 at 05:26:07PM -0600, Adam Roach wrote: [...] > > §3.8.1.2: > > exact contexts used are best described by the > > following code, followed by some comments. > > I can't find the referenced comments. I think this refered to the put_symbol() code below and the comments inside it. pseudo-code | type --------------------------------------------------------------|----- void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | is_signed) { | int i; | put_rac(c, state+0, !v); | if (v) { | int a= abs(v); | int e= log2(a); | | for (i = 0; i < e; i++) { | put_rac(c, state+1+min(i,9), 1); //1..10 | } | | put_rac(c, state+1+min(i,9), 0); | for (i = e-1; i >= 0; i--) { | put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | } | | if (is_signed) { | put_rac(c, state+11 + min(e, 10), v < 0); //11..21| } | } | } | [...] > --------------------------------------------------------------------------- > > §4.1.17: > > > +-------+-------------------------------------+ > > | value | relationship | > > +=======+=====================================+ > > | 0 | Frames are independent or dependent | > > | | (keyframes and non keyframes) | > > +-------+-------------------------------------+ > > | 1 | Frames are independent (keyframes | > > | | only) | > > +-------+-------------------------------------+ > > | Other | reserved for future use | > > +-------+-------------------------------------+ > > > > Table 14 > > I'm having a hard time understanding "Other" in this table. Section 4.3 > defines "keyframe" to be of "br" type. I'm confused about how a boolean > variable can take on more than two values. This table does not describe the keyframe flag but the intra value from the global header. I think this should already be clear as it refers to that field "4.1.17. intra " and not the keyframe flag. But we could of course rename the field if that would make it clearer. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
- [Cellar] AD Review: draft-ietf-cellar-ffv1 Adam Roach
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Dave Rice
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Adam Roach
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Dave Rice
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Michael Niedermayer
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Adam Roach
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Michael Niedermayer
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Michael Niedermayer
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Dave Rice
- Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 Dave Rice