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