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

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 02 July 2020 05:38 UTC

Return-Path: <superuser@gmail.com>
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 8D3653A0D00 for <cellar@ietfa.amsl.com>; Wed, 1 Jul 2020 22:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 f2h5xh1ZghfA for <cellar@ietfa.amsl.com>; Wed, 1 Jul 2020 22:38:41 -0700 (PDT)
Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960B23A0CFF for <cellar@ietf.org>; Wed, 1 Jul 2020 22:38:41 -0700 (PDT)
Received: by mail-ua1-x930.google.com with SMTP id q15so8307232uap.4 for <cellar@ietf.org>; Wed, 01 Jul 2020 22:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=abFAXDCdiyyfJKg+vNgBrcOE93gCDFdivMyMW8CLTBI=; b=cdVQN/xb8az4ial6MpD+PQVBk+NstfZ1tEnIAr0JpMDWicsN9zIs3qrsK+YF6EizQw iPnmmfnRdXaZ3nlxIe1dSt4fILWRKDP9qLsmurfVFjH2/Dout21cqeWEYdVnoaer0lHo V/eLi2l7C695qLjqmKghvID9a4uc4p00HfPudin1uAeHNtvrXKNaSOG6q4lHg0+kUgQM RsJJ5LIhCiNa6jhc59GppWCjLRAC1HMPa2r7ys9f7SkWmDtJZhY4Gtx9Z0EErGJq5yIv uovvuKiElpYQjETlFT1+NelbdMEL1ULndKkJckK3LVPcFmR0QiiQ27lAtvPPi2a1cCmi /H6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=abFAXDCdiyyfJKg+vNgBrcOE93gCDFdivMyMW8CLTBI=; b=TYcmp4FEHceENnwh0d7g++EXeLHXKV9rUYd2SEkWErLDMnDjL/yXLC/8C0uzTw0cu1 wtmBiSZ727Tb6yr5XsTK14yATg6IHe4DeYf6FKOW+RWKRnDMa67VwVhTBlnxtbYSnPgj G42WRyb2TylljJptGky6qVI+Gl7arYMCgBpUn8JQP2wCujy3EOqYbI71FAcpYs34EoG/ yE4qlygdjgGfK0ezUDJcgcWlYRYzRvwHm7SkJ+9OuzLTEkcwWgGTcjWK+yybD4TneZu4 aPOZ5nDke0ceX10b2h52x8g7lvrCDfTiF/QE8D5Xy8RPOCQb9AaqW5ocJ0m4Zk/OiRn8 kG/g==
X-Gm-Message-State: AOAM5302GuH+2iVZmKEe9Rd+0GJMn+VeD6IrdbSmYibFyJTm6MKw8Vnm ebu0PejAha1Jni/SH7Nnx9hyLOk4vnBhsrFqMh0=
X-Google-Smtp-Source: ABdhPJzmMKpYVpnUfgopsawdzG/UspxK30b+BFaTsv48tswgECc4w86CyOGXQT9wDheSR0JPcSQ4pLF9eBzDhaOxv6c=
X-Received: by 2002:ab0:7056:: with SMTP id v22mr14330310ual.67.1593668320380; Wed, 01 Jul 2020 22:38:40 -0700 (PDT)
MIME-Version: 1.0
References: <159293956986.23437.659003564832844414@ietfa.amsl.com> <CAKKJt-csgcrjsekG8VDPNPUip3_4T1Nuv-1DSje2WkdsrjfxkA@mail.gmail.com> <CAL0qLwZugn7HZN6-QT6CYjuPV89q8Suz_Jujn92Jya6ez7gG3g@mail.gmail.com> <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> <BF2B51D9-B580-4997-85A5-719FD3AD41C6@dericed.com>
In-Reply-To: <BF2B51D9-B580-4997-85A5-719FD3AD41C6@dericed.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Wed, 1 Jul 2020 22:38:29 -0700
Message-ID: <CAL0qLwZuM3o68tpR2T58Qr-SGfUHAU_83PakDWrMgvGqXLCjHg@mail.gmail.com>
To: Dave Rice <dave@dericed.com>
Cc: Jerome Martinez <jerome@mediaarea.net>, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000020499105a96ed200"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/lwJM5d6CH7kXGQaURN8E1UwCSSM>
Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt
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, 02 Jul 2020 05:38:44 -0000

Thanks, this looks much nicer!

On Thu, Jun 25, 2020 at 10:34 AM Dave Rice <dave@dericed.com> wrote:

> Hi Murray,
>
> > On Jun 25, 2020, at 1:19 PM, Jerome Martinez <jerome@mediaarea.net>
> 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 3.8.2.3, 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
> https://tools.ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , 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)
> https://www.itu.int/rec/T-REC-H.264-201906-I/en
> > - AV1, see an online direct example at
> https://aomediacodec.github.io/av1-spec/#frame-obu-syntax
> >
> > 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
> https://aomediacodec.github.io/av1-spec/#decode-tile-syntax
> >
> >> 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
> https://github.com/FFmpeg/FFV1/pull/215/commits/1a4f83fb05591a1cfb4ef197682d06212ecf0b56.
> 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
> https://github.com/FFmpeg/FFV1/pull/215.
>
> Best Regards,
> Dave Rice
>
>