From nobody Sat Mar 7 23:28:39 2020 Return-Path: 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 5DBCF3A083D for ; Sat, 7 Mar 2020 23:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=matroska-org.20150623.gappssmtp.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 fwYJa_6dJ8-e for ; Sat, 7 Mar 2020 23:28:35 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 D12403A0838 for ; Sat, 7 Mar 2020 23:28:32 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id c144so3353390pfb.10 for ; Sat, 07 Mar 2020 23:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=O+FC5MjMgn0oFsDgknpaa1EncuJNAPILK7vKh51Y/Ok=; b=xvk41BUoccYvef+AJASZ/og80VyGay7s167RKBwlnSnJmOZlA/4g2OXJFgxHZnEsL2 Vfxoh0Cg9sE1obAyNWegVd1q6s8kHsyuWQSCjIyTdHbgxrfxaNZ/2ybKKTrX2cXblvU+ fLV01qA4qqG47sTOfNTHv3XJpTI9bFUADwW0OFUq2ZygmmGjU35WB/UIqkpcU8ZfPWsa O+Prkm4qcTGBkwEAd+e8vyv3q/2HH0EOrMBiQ3Q68nOYR0eY05LidNZEcjIc5Uud7hdG MORFjsINXuNEVknWrSANlkGXZZmke8cf22p4HzJvKua3321beS7LDObJRMFn4bZ4+OIP kI9Q== 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:content-transfer-encoding; bh=O+FC5MjMgn0oFsDgknpaa1EncuJNAPILK7vKh51Y/Ok=; b=d7P1k4EUHwzn8Jk7Tuh22bl+7CQPLRXdHjcAT+4mp8csZROCUdbN/eJEfloBaiZw5j Hmz/LFPW6ZzZg4faLQQVXIbqQ8ndvNKITIF/xLCb9FDXIYXMn+O2CvJ0z0Kr5OLogI/F arO/vQj/KxoqC9+GeVPc23X5MhUwKq/3esSg2qJOivzWvy/kXCP44P/XVr5iY+6OWo4L X/nuxQOnVm9Jw1LSXWBrpfzFCs0Nl1Npklt/j1W60nz9c5SVbVdhHTK9q+epEf0iJBh4 3bJinO+BkOqTbRVQlJjzdNvlz49Tc/ly3tq4B5sVCUXoQoizKQudsZv0XiwSN1KOCBIO sHRg== X-Gm-Message-State: ANhLgQ2CqV0M/ILEXsDgNChIR4FBqrqpZ3XpMZuOOcyF017NnU18r3dX kwpFPLe5idILY0dOsHJ0fJNVQaQXyPYu+6y+RluH6Q== X-Google-Smtp-Source: ADFU+vsLlmV15VuxLIK6MLAulDE1hXnBFGsHn5QJFDHEU/6GV6Fq84RFcBXxPz4Lg7HbsF/aiw41hcXUyD8Ji86g1NU= X-Received: by 2002:aa7:9508:: with SMTP id b8mr11221946pfp.171.1583652512000; Sat, 07 Mar 2020 23:28:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steve Lhomme Date: Sun, 8 Mar 2020 08:28:22 +0100 Message-ID: To: Spencer Dawkins at IETF Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Sun, 08 Mar 2020 07:28:37 -0000 Hi Spencer, The codec document will likely evolve more. I'd like to have one core document describing how codecs are mapped and each type of codec and small documents relating to this core document for each codec. (raw codecs could be just one big document) So I don't think the name is relevant yet. The tags will likely remain as it is now. But I'm not sure what is wrong with "Matroska Tags". Should it be longer ? Or in a different grammatical form like "Tags used in Matroska" ? The same question applies to the "Matroska Specifications". Is it too broad ? This is the core documentation of the format. Le mer. 19 f=C3=A9vr. 2020 =C3=A0 02:34, Spencer Dawkins at IETF a =C3=A9crit : > > Dear Cellar Folk, > > I'm wondering if the Matroska document titles could be more descriptive. > > I'm looking at the abstracts for these documents, and wondering if the ti= tles accurately describe the contents of the first two documents. (The thir= d document seems fine to me) > > Thoughts? > > Best, > > Spencer > > Matroska Codec - https://datatracker.ietf.org/doc/draft-ietf-cellar-codec= / > > Abstract > > This document defines the Matroska codec mappings, including the > codec ID, layout of data in a "Block Element" and in an optional > "CodecPrivate Element". > > Matroska Specifications - https://datatracker.ietf.org/doc/draft-ietf-cel= lar-matroska/ > > Abstract > > This document defines the Matroska audiovisual container, including > definitions of its structural elements, as well as its terminology, > vocabulary, and application. > > Matroska Tags - https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ > > Abstract > > This document defines the Matroska tags, namely the tag names and > their respective semantic meaning. > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sat Mar 7 23:41:21 2020 Return-Path: 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 684213A0868 for ; Sat, 7 Mar 2020 23:41:19 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=F9gBll2v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=guLh/rdJ 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 px5Q34TZZCV1 for ; Sat, 7 Mar 2020 23:41:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D56053A0869 for ; Sat, 7 Mar 2020 23:41:17 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0069221B2C for ; Sun, 8 Mar 2020 03:32:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 08 Mar 2020 03:32:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=4OhTJl/Yd3GJCy+zsxjLtKh44dUxFVGJAkKbOIUyvqg=; b=F9gBll2v n2bBAAYVcw7DdixsexiHDQwD5BuQLXCaWpkoaHVqMvFc91zWrxT01onhaQqD3Kyg 5htf3cmQyL5g8l0CMhDZgo9EX+Pfnm/aWynQkGv2UtpWIVFHxQo2DI5jMTh/56Z/ Qi6Mfrg/UYRMk2bl9VaY9PnQ8fmt211H7ry8oADTvA3LiBMHQLNoG5qFjFxnfLfS +0WbXRAyf0eEn1Efbfx3ScZjot3K86Mhfs5Y+cyg+n/YHFzBuMm5cwszma7Eq15/ di2vEtme2+Fd+jV2GACDgleteGt+criWjLR4/Z8yMLHDiZICynjFoeMkkF72NB0G TbIsy8C3PYjjIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=4OhTJl/Yd3GJCy+zsxjLtKh44dUxF VGJAkKbOIUyvqg=; b=guLh/rdJe6YuLMYmpoc3b4tnjqB4rBysQ/5k2QLKHX0Pa zgpHqHf9vXMMUOSHwrd6n3y3HbReimyt+h84355gYpV5KU+0TRAqb/xnloCyUSGh KNdRQt2Gs1lfQhlknd3gLrDEXx7tp8alaPuZBVSq2shYFELBQUjoIvit6SssMaPJ NEc97S8MNoAUG/0Ty4P7vyU+tT5VElea5lN23GjvrCx41peCwTwx+G7Ix6rQy9iP sUS4aeaxxPjFbOHW5TzUrwPlsS7Y+kEeLkc09RN0AGSJS/rNHsEKVXDf/yM9YQXZ DVyHrePbNUXwTQHLpKZoF9wRZslfRiLBXkizOIcWQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduhedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinh epghhithhhuhgsrdgtohhmnecukfhppeegtddruddugedrvdekrddvtdejnecuvehluhhs thgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvg hplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.114.28.207]) by mail.messagingengine.com (Postfix) with ESMTPA id BC3303280059 for ; Sun, 8 Mar 2020 03:32:46 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3435713380642424026==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200308073246.BC3303280059@mailuser.nyi.internal> Date: Sun, 8 Mar 2020 03:32:46 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org 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: Sun, 08 Mar 2020 07:41:19 -0000 --===============3435713380642424026== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC0) 1 issues closed: - bug in element naming https://github.com/cellar-wg/ebml-specification/i= ssues/336=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #348 block additional mapping for smpte 12m timecode (1 by robUx4) https://github.com/cellar-wg/matroska-specification/pull/348 [format ad= dition] [spec_codecs]=20 1 pull requests merged: - block additional mapping for smpte 12m timecode https://github.com/cellar-wg/matroska-specification/pull/348 [format ad= dition] [spec_codecs]=20 * cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #337 fix DocTypeExtension Child Element names (1 by dericed) https://github.com/cellar-wg/ebml-specification/pull/337=20 1 pull requests merged: - fix DocTypeExtension Child Element names https://github.com/cellar-wg/ebml-specification/pull/337=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============3435713380642424026== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday March 08, 2020

Events without label "editorial"

Issues

cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC0)

1 issues closed:

Pull requests

cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

1 pull requests merged:

cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============3435713380642424026==-- From nobody Mon Mar 9 18:02:19 2020 Return-Path: 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 577243A0BB9 for ; Mon, 9 Mar 2020 18:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_BLOCKED=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 o91X9yZbv_bK for ; Mon, 9 Mar 2020 18:02:15 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 009613A0BA5 for ; Mon, 9 Mar 2020 18:02:14 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id i10so9394858lfg.11 for ; Mon, 09 Mar 2020 18:02:14 -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=KXXKYiLc4tsdjOEbH/xNzP2KcXOdSMQm47goMhgL1Y0=; b=oZVU6Pv2l1ZfebRbJkhAPopqentY/2QcdrHtubqhdDt167w5vFik5l+YNetP58IfYc 2QnccETpQHaYNQ9dFrlY9G7PrEIp78NvndweOl18pGroJHWfBwqgM19xpCh3BInyQS9R J6CqaknUWTskjVD8V1Zw1tWrarPGW0vCvOtXcXssb5OlUuW8zeeqymmpI0RNT46hFZrg 3U/HZsbglO7vHACngbe/9FAI4qZJx/3Yw1Ha0Fa667j2EGdRyHmL3KjH2NZOkI3NeY30 pmeg9ChPkVYsVNZse+T2qGrBw+5VPe/wgCAOgiV+3PyrxYFNCtnwv/ToTDGKju5hJNCG g1AA== 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=KXXKYiLc4tsdjOEbH/xNzP2KcXOdSMQm47goMhgL1Y0=; b=fOWQGLkrOdVCEfJ3xB4skmQ1N8PGnsRXaU9prK1RWdMJivJzI6d3949YpMnNb0jjzI x/Tq9240J7uUYv+HXckwZbkG6xWYHpXhpnwJ7ts1NLxDzoEm5WllmXazuWPQwlzNQGeW jJD/s5CmXAhoVXuA/wdWwJZN/8Zf//wI61H0Fg6aQj1oGlmZw8Z2wIrjEO939wGv7vYN vAAzjcGjCJPFXVzkAwe2iQI4mb4xgLFrhY4qYBwuW1viKOHCtCUbq6IJHKOkR88y4omE rBuWDDeyMRQPYZTA6K2eXwSk+1tZNxk6KhpmWLB1tWuJNHaqs2yrqVe90ln7TuEF3s/F MaEg== X-Gm-Message-State: ANhLgQ2xTrDsm5OpuscNsHUEVDE68Gr0DZTAL5S3seNPcJw/41Lqmg0M ZkVcHAftjKTpDn1YiD9+xs6AhknIx/jbhQj1G17FbJmsVUgv4g== X-Google-Smtp-Source: ADFU+vsAL9IcjxNdEFpEQBQftD/stl+72FPFI78FLGk6anQDF54HPX+ROR11MXu2aNHRpOTGV7IFDH0U9UB6RbrO9sI= X-Received: by 2002:a05:6512:308c:: with SMTP id z12mr10970432lfd.27.1583802132977; Mon, 09 Mar 2020 18:02:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 9 Mar 2020 20:01:46 -0500 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000087db2205a075abbc" Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Tue, 10 Mar 2020 01:02:17 -0000 --00000000000087db2205a075abbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Steve, Thanks very much for following up on this. For the purpose of this note, please consider that I'm not replying as one of the co-chairs. On Sun, Mar 8, 2020 at 1:28 AM Steve Lhomme wrote: > Hi Spencer, > > The codec document will likely evolve more. I'd like to have one core > document describing how codecs are mapped and each type of codec and > small documents relating to this core document for each codec. (raw > codecs could be just one big document) So I don't think the name is > relevant yet. > I didn't say clearly enough that I have no desire to ask you folks to make structural changes to the Matroska document suite. I'm sorry if that confused anyone. I'm only curious about the document titles. And I really want to defer to the working group about the actual titles, so please do the right thing. So, here's what I've seen people do with multi-document specifications at the IETF. - People use common title prefixes in Internet Drafts and RFCs to make it easier to find stuff that is part of the specification, and to not fi= nd things that aren't. If something like "Matroska Media Container" as a prefix would apply to any of the specifications you're working on now or thinking about in the future, that would be helpful to your readers. I assumed that form in the following suggestions, so if you can think of a better prefix, please use it to improve the following suggestions! - For "Matroska Tags", that's pretty close to what I'd hope for. If it was "Matroska Media Container Tags", would that work? - For "Matroska Codec" - the abstract says this is actually "Matroska Codec Mappings", so that seems like the title needs to change a bit more= . If the document title was something like "Matroska Media Container Codec Mappings", would that work? - For "Matroska Specifications", that probably is too broad (because there are two other Matroska specifications in the working group now). Y= ou used the term "core" in your reply, and I know the working group has bee= n considering whether to publish chapters in a separate document, so it se= ems possible that there will be at least one non-core specification at some point. Would it be accurate to use something like "Matroska Media Contai= ner Core Specification" for this one? There are (many) other titles that would work for me, so please don't focus on the details. If it's helpful to know why I sent my first note ... - These documents are important enough that people who you don't know, are looking at them now, while they're still being developed. - I've been having conversations with people outside the working group, and outside my employer's community, about planning for Matroska. I expe= ct I'm not the only person doing that. It seems helpful for planners to be able to find what they need to be looking at. - Michael and I have been asked to provide a write-up about what's happening in CELLAR to the IEEE standards journal, and the Matroska documents would be featured prominently in that, and IEEE journals go al= l over the planet, but I don't want to confuse people all over the planet. - It's lightweight to change draft document titles, so even if you change a title more than once, it can accurately reflect the contents at any particular point in time. And thanks, again, for the opportunity to be clearer on what I was thinking= . Best, Spencer > The tags will likely remain as it is now. But I'm not sure what is > wrong with "Matroska Tags". Should it be longer ? Or in a different > grammatical form like "Tags used in Matroska" ? > > The same question applies to the "Matroska Specifications". Is it too > broad ? This is the core documentation of the format. > > Le mer. 19 f=C3=A9vr. 2020 =C3=A0 02:34, Spencer Dawkins at IETF > a =C3=A9crit : > > > > Dear Cellar Folk, > > > > I'm wondering if the Matroska document titles could be more descriptive= . > > > > I'm looking at the abstracts for these documents, and wondering if the > titles accurately describe the contents of the first two documents. (The > third document seems fine to me) > > > > Thoughts? > > > > Best, > > > > Spencer > > > > Matroska Codec - > https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ > > > > Abstract > > > > This document defines the Matroska codec mappings, including the > > codec ID, layout of data in a "Block Element" and in an optional > > "CodecPrivate Element". > > > > Matroska Specifications - > https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ > > > > Abstract > > > > This document defines the Matroska audiovisual container, including > > definitions of its structural elements, as well as its terminology, > > vocabulary, and application. > > > > Matroska Tags - https://datatracker.ietf.org/doc/draft-ietf-cellar-tags= / > > > > Abstract > > > > This document defines the Matroska tags, namely the tag names and > > their respective semantic meaning. > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman > --00000000000087db2205a075abbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Steve,=C2=A0

Thank= s very much for following up on this.=C2=A0

For th= e purpose of this note, please consider that I'm not replying as one of= the co-chairs.=C2=A0

On Sun, Mar 8, 2020 at 1:28 AM Steve Lhomme <= slhomme@matroska.org> wrote:=
Hi Spencer,

The codec document will likely evolve more. I'd like to have one core document describing how codecs are mapped and each type of codec and
small documents relating to this core document for each codec. (raw
codecs could be just one big document) So I don't think the name is
relevant yet.

I didn't say clearly = enough that I have no desire to ask you folks to make structural changes to= the Matroska document suite. I'm sorry if that confused anyone. I'= m only curious about the document titles.=C2=A0

An= d I really want to defer to the working group about the actual titles, so p= lease do the right thing.=C2=A0

So, here's what I've seen people do with = multi-document specifications at the IETF.
  • People use com= mon title prefixes in Internet Drafts and RFCs to make it easier to find st= uff that is part of the specification, and to not find things that aren'= ;t. If something like "Matroska=C2=A0Media Container" as a prefix= would apply to any of the specifications you're working on now or thin= king about in the future, that would be helpful to your readers. I assumed = that form in the following suggestions, so if you can think of a better pre= fix, please use it to improve the following suggestions!
  • For "= Matroska Tags", that's pretty close to what I'd hope for. If i= t was "Matroska Media Container Tags", would that work?
  • F= or "Matroska Codec" - the abstract says this is actually "Ma= troska Codec Mappings", so that seems like the title needs to change a= bit more. If the document title was something like "Matroska Media Co= ntainer Codec Mappings", would that work?
  • For "Matroska S= pecifications", that probably is too broad (because there are two othe= r Matroska specifications in the working group now). You used the term &quo= t;core" in your reply, and I know the working group has been consideri= ng whether to publish chapters in a separate document, so it seems possible= that there will be at least one non-core specification at some point. Woul= d it be accurate to use something like "Matroska Media Container Core = Specification" for this one?
There are (many) other titl= es that would work for me, so please don't focus on the details.=C2=A0<= /div>

If it's helpful to know why I sent = my first note ...=C2=A0
  • These documents are important eno= ugh that people who you don't know, are looking at them now, while they= 're still being developed.
  • I've been having conversatio= ns with people outside the working group, and outside my employer's com= munity, about planning for Matroska. I expect I'm not the only person d= oing that. It seems helpful for planners to be able to find what they need = to be looking at.=C2=A0
  • Michael and I have been asked to provide a = write-up about what's happening in CELLAR to the IEEE standards journal= , and the=C2=A0Matroska documents would be featured prominently in that, an= d IEEE journals go all over the planet, but I don't want to confuse peo= ple all over the planet.=C2=A0=C2=A0
  • It's lightweight to change= draft document titles, so even if you change a title more than once, it ca= n accurately reflect the contents at any particular point in time.=C2=A0=C2= =A0=C2=A0
And thanks, again, for the opportunity to be cle= arer on what I was thinking.

Best,

<= /div>
Spencer
=C2=A0
The tags will likely remain as it is now. But I'm not su= re what is
wrong with "Matroska Tags". Should it be longer ? Or in a differe= nt
grammatical form like "Tags used in Matroska" ?

The same question applies to the "Matroska Specifications". Is it= too
broad ? This is the core documentation of the format.

Le mer. 19 f=C3=A9vr. 2020 =C3=A0 02:34, Spencer Dawkins at IETF
<spen= cerdawkins.ietf@gmail.com> a =C3=A9crit :
>
> Dear Cellar Folk,
>
> I'm wondering if the Matroska document titles could be more descri= ptive.
>
> I'm looking at the abstracts for these documents, and wondering if= the titles accurately describe the contents of the first two documents. (T= he third document seems fine to me)
>
> Thoughts?
>
> Best,
>
> Spencer
>
> Matroska Codec - https://datatracker.i= etf.org/doc/draft-ietf-cellar-codec/
>
> Abstract
>
>=C2=A0 =C2=A0 This document defines the Matroska codec mappings, includ= ing the
>=C2=A0 =C2=A0 codec ID, layout of data in a "Block Element" a= nd in an optional
>=C2=A0 =C2=A0 "CodecPrivate Element".
>
> Matroska Specifications - https://d= atatracker.ietf.org/doc/draft-ietf-cellar-matroska/
>
> Abstract
>
>=C2=A0 =C2=A0 This document defines the Matroska audiovisual container,= including
>=C2=A0 =C2=A0 definitions of its structural elements, as well as its te= rminology,
>=C2=A0 =C2=A0 vocabulary, and application.
>
> Matroska Tags - https://datatracker.iet= f.org/doc/draft-ietf-cellar-tags/
>
> Abstract
>
>=C2=A0 =C2=A0 This document defines the Matroska tags, namely the tag n= ames and
>=C2=A0 =C2=A0 their respective semantic meaning.
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


--
Steve Lhomme
Matroska association Chairman
--00000000000087db2205a075abbc-- From nobody Mon Mar 16 16:01:15 2020 Return-Path: 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 1409A3A130C for ; Mon, 16 Mar 2020 16:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 eP3mP9M6Vjkr for ; Mon, 16 Mar 2020 16:00:55 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC9E3A1325 for ; Mon, 16 Mar 2020 16:00:54 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:45147 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1jDyj2-000mub-Uh; Mon, 16 Mar 2020 19:00:54 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0B2E734B-823C-4175-8B1A-0607E4A496FD" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Mon, 16 Mar 2020 19:00:47 -0400 In-Reply-To: Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission To: Spencer Dawkins at IETF References: X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Mon, 16 Mar 2020 23:01:14 -0000 --Apple-Mail=_0B2E734B-823C-4175-8B1A-0607E4A496FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 9, 2020, at 9:01 PM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Steve,=20 >=20 > Thanks very much for following up on this.=20 >=20 > For the purpose of this note, please consider that I'm not replying as = one of the co-chairs.=20 >=20 > On Sun, Mar 8, 2020 at 1:28 AM Steve Lhomme > wrote: > Hi Spencer, >=20 > The codec document will likely evolve more. I'd like to have one core > document describing how codecs are mapped and each type of codec and > small documents relating to this core document for each codec. (raw > codecs could be just one big document) So I don't think the name is > relevant yet. >=20 > I didn't say clearly enough that I have no desire to ask you folks to = make structural changes to the Matroska document suite. I'm sorry if = that confused anyone. I'm only curious about the document titles.=20 >=20 > And I really want to defer to the working group about the actual = titles, so please do the right thing.=20 >=20 > So, here's what I've seen people do with multi-document specifications = at the IETF. > People use common title prefixes in Internet Drafts and RFCs to make = it easier to find stuff that is part of the specification, and to not = find things that aren't. If something like "Matroska Media Container" as = a prefix would apply to any of the specifications you're working on now = or thinking about in the future, that would be helpful to your readers. = I assumed that form in the following suggestions, so if you can think of = a better prefix, please use it to improve the following suggestions! > For "Matroska Tags", that's pretty close to what I'd hope for. If it = was "Matroska Media Container Tags", would that work? > For "Matroska Codec" - the abstract says this is actually "Matroska = Codec Mappings", so that seems like the title needs to change a bit = more. If the document title was something like "Matroska Media Container = Codec Mappings", would that work? > For "Matroska Specifications", that probably is too broad (because = there are two other Matroska specifications in the working group now). = You used the term "core" in your reply, and I know the working group has = been considering whether to publish chapters in a separate document, so = it seems possible that there will be at least one non-core specification = at some point. Would it be accurate to use something like "Matroska = Media Container Core Specification" for this one? I=E2=80=99m not sure about the word =E2=80=98Media=E2=80=99, how about: Matroska File Format Specification Matroska File Format Codec Mappings Matroska File Format Metadata Tags I think the term =E2=80=9CFile Format=E2=80=9D is a bit more accessible = than =E2=80=9CContainer=E2=80=9D. Also I see that MXF uses similar = wording at = http://web.archive.org/web/20051210203751/http://www.smpte.org/smpte_store= /standards/pdf/s377m.pdf = . > There are (many) other titles that would work for me, so please don't = focus on the details.=20 >=20 > If it's helpful to know why I sent my first note ...=20 > These documents are important enough that people who you don't know, = are looking at them now, while they're still being developed. > I've been having conversations with people outside the working group, = and outside my employer's community, about planning for Matroska. I = expect I'm not the only person doing that. It seems helpful for planners = to be able to find what they need to be looking at.=20 > Michael and I have been asked to provide a write-up about what's = happening in CELLAR to the IEEE standards journal, and the Matroska = documents would be featured prominently in that, and IEEE journals go = all over the planet, but I don't want to confuse people all over the = planet. =20 > It's lightweight to change draft document titles, so even if you = change a title more than once, it can accurately reflect the contents at = any particular point in time. =20 > And thanks, again, for the opportunity to be clearer on what I was = thinking. >=20 > Best, >=20 > Spencer > =20 > The tags will likely remain as it is now. But I'm not sure what is > wrong with "Matroska Tags". Should it be longer ? Or in a different > grammatical form like "Tags used in Matroska" ? >=20 > The same question applies to the "Matroska Specifications". Is it too > broad ? This is the core documentation of the format. >=20 > Le mer. 19 f=C3=A9vr. 2020 =C3=A0 02:34, Spencer Dawkins at IETF > > = a =C3=A9crit : > > > > Dear Cellar Folk, > > > > I'm wondering if the Matroska document titles could be more = descriptive. > > > > I'm looking at the abstracts for these documents, and wondering if = the titles accurately describe the contents of the first two documents. = (The third document seems fine to me) > > > > Thoughts? > > > > Best, > > > > Spencer > > > > Matroska Codec - = https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ = > > > > Abstract > > > > This document defines the Matroska codec mappings, including the > > codec ID, layout of data in a "Block Element" and in an optional > > "CodecPrivate Element". > > > > Matroska Specifications - = https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ = > > > > Abstract > > > > This document defines the Matroska audiovisual container, = including > > definitions of its structural elements, as well as its = terminology, > > vocabulary, and application. > > > > Matroska Tags - = https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ = > > > > Abstract > > > > This document defines the Matroska tags, namely the tag names and > > their respective semantic meaning. > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_0B2E734B-823C-4175-8B1A-0607E4A496FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 9, 2020, at 9:01 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Steve, 
Thanks very much for following up on = this. 

For = the purpose of this note, please consider that I'm not replying as one = of the co-chairs. 

On Sun, Mar = 8, 2020 at 1:28 AM Steve Lhomme <slhomme@matroska.org> wrote:
Hi Spencer,

The codec document will likely evolve more. I'd like to have one core
document describing how codecs are mapped and each type of codec and
small documents relating to this core document for each codec. (raw
codecs could be just one big document) So I don't think the name is
relevant yet.

I didn't say clearly enough that I have = no desire to ask you folks to make structural changes to the Matroska = document suite. I'm sorry if that confused anyone. I'm only curious = about the document titles. 

And I really want to defer to the = working group about the actual titles, so please do the right = thing. 

So, here's = what I've seen people do with multi-document specifications at the = IETF.
  • People use = common title prefixes in Internet Drafts and RFCs to make it easier to = find stuff that is part of the specification, and to not find things = that aren't. If something like "Matroska Media Container" as a = prefix would apply to any of the specifications you're working on now or = thinking about in the future, that would be helpful to your readers. I = assumed that form in the following suggestions, so if you can think of a = better prefix, please use it to improve the following = suggestions!
  • For "Matroska Tags", that's pretty close = to what I'd hope for. If it was "Matroska Media Container Tags", would = that work?
  • For "Matroska Codec" - the abstract says = this is actually "Matroska Codec Mappings", so that seems like the title = needs to change a bit more. If the document title was something like = "Matroska Media Container Codec Mappings", would that work?
  • For "Matroska Specifications", that probably is too broad = (because there are two other Matroska specifications in the working = group now). You used the term "core" in your reply, and I know the = working group has been considering whether to publish chapters in a = separate document, so it seems possible that there will be at least one = non-core specification at some point. Would it be accurate to use = something like "Matroska Media Container Core Specification" for this = one?
I=E2=80=99m not = sure about the word =E2=80=98Media=E2=80=99, how = about:
Matroska File Format Specification
Matroska = File Format Codec Mappings
Matroska File Format Metadata = Tags

I think the term =E2=80=9CFile = Format=E2=80=9D is a bit more accessible than =E2=80=9CContainer=E2=80=9D.= Also I see that MXF uses similar wording at http://web.archive.org/web/20051210203751/http://www.smpte.org/= smpte_store/standards/pdf/s377m.pdf.

There are (many) = other titles that would work for me, so please don't focus on the = details. 

If it's helpful to know why I sent my first = note ... 
  • These = documents are important enough that people who you don't know, are = looking at them now, while they're still being developed.
  • I've been having conversations with = people outside the working group, and outside my employer's community, = about planning for Matroska. I expect I'm not the only person doing = that. It seems helpful for planners to be able to find what they need to = be looking at. 
  • Michael and I have been asked to = provide a write-up about what's happening in CELLAR to the IEEE = standards journal, and the Matroska documents would be featured = prominently in that, and IEEE journals go all over the planet, but I = don't want to confuse people all over the planet.  
  • It's lightweight to change draft document titles, so even if = you change a title more than once, it can accurately reflect the = contents at any particular point in time.   
And thanks, again, for the = opportunity to be clearer on what I was thinking.
Best,

Spencer
 
The tags will likely remain as it is = now. But I'm not sure what is
wrong with "Matroska Tags". Should it be longer ? Or in a different
grammatical form like "Tags used in Matroska" ?

The same question applies to the "Matroska Specifications". Is it too
broad ? This is the core documentation of the format.

Le mer. 19 f=C3=A9vr. 2020 =C3=A0 02:34, Spencer Dawkins at IETF
<spencerdawkins.ietf@gmail.com> a =C3=A9crit :
>
> Dear Cellar Folk,
>
> I'm wondering if the Matroska document titles could be more = descriptive.
>
> I'm looking at the abstracts for these documents, and wondering if = the titles accurately describe the contents of the first two documents. = (The third document seems fine to me)
>
> Thoughts?
>
> Best,
>
> Spencer
>
> Matroska Codec - https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ >
> Abstract
>
>    This document defines the Matroska codec mappings, = including the
>    codec ID, layout of data in a "Block Element" and in = an optional
>    "CodecPrivate Element".
>
> Matroska Specifications - https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/
>
> Abstract
>
>    This document defines the Matroska audiovisual = container, including
>    definitions of its structural elements, as well as its = terminology,
>    vocabulary, and application.
>
> Matroska Tags - https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ >
> Abstract
>
>    This document defines the Matroska tags, namely the = tag names and
>    their respective semantic meaning.
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
=


--
Steve Lhomme
Matroska association Chairman
_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_0B2E734B-823C-4175-8B1A-0607E4A496FD-- From nobody Mon Mar 16 17:19:22 2020 Return-Path: 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 D831F3A1417 for ; Mon, 16 Mar 2020 17:19:19 -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 jQSTgtM6vI3m for ; Mon, 16 Mar 2020 17:19:18 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 704A63A1416 for ; Mon, 16 Mar 2020 17:19:12 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 5so8548202lfr.2 for ; Mon, 16 Mar 2020 17:19:11 -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=CoHaby3zwl8f8XLlUk/UlZEjvGM/4TndXYku/+hFatQ=; b=MNfCQHJ3n/fMJ3rIxdiNC5ddXcrRc5+lC1i2XCLftEAyaap3z2qm8FqI3VklACBb9X N3ucsH4etw6pQ8mDCUq2T4Zum+gE58Z3w+TF8WaUn+OOc4WvnV8hl3GZ5j0qDV5Mi8Zz /jn3ypNZCKL+F/f6nGgro8CGnOhJitWAqozlXK1ZwL6IJchvEFZD5pzNvM6Rpa6olPyv ZIWBsBkcbO4iK2o1HW/9R9F5ObIfbxEgHcPq9sbgwIgsBufnZL92j2xIdLuQcVMkuZx4 y3VoDcakXlkH0Rqfecc+j9k0idZiY6+LGzh+ElZbgVWT6YO8HhUzfJNXPBUW4F3PcIb1 W+uw== 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=CoHaby3zwl8f8XLlUk/UlZEjvGM/4TndXYku/+hFatQ=; b=Qzrj3p1KhtG6b7yxqUeipWbY0TZWtbQi6f/1E8Cj9+iLgAYREHJxvTXLPgvdb2Hqf9 1oJhgEOcl3R3FHCALOEJYhI5h63hku3WWOdsKP7Iz6qQ8WUh+NYbgMEXNQcjTgWXQGbW bYTp3FuUDt9T8vhHYa1FQOyr6lsbdRfWEkFK5HOIOdunQxwz976CRXawGXLYuOZxGox0 yC4vvPfhufbzYTyqQrSzYg4Vo2I8l/DU2Dm0+veCoSoH/wbt4V2Ki2mxI7ivY2Fn75IV U4yJgR8x4fa9wWn+e6i9T48HyB/OGovW3HkzX7SiUkjUOoA98VqHocRNu28wbId5Z8cp WM9A== X-Gm-Message-State: ANhLgQ3lcthB2vMabeiWCtMxu3oGJkbhcwaiUGwUGZn5tJSAvSaXq7c5 tCoclACDxBSgjXgRXwrUB4VPPiOz7+56uESpSuL5gYvkLcM= X-Google-Smtp-Source: ADFU+vvtl97aoNPdyu6Ozwha6J63l3oyuU1sdDAbA3IleqIVNi9yxIH0IK7Fmw64EbT7WyF5xO7LSZPulzCQ3czkrLM= X-Received: by 2002:ac2:5f58:: with SMTP id 24mr87042lfz.81.1584404350104; Mon, 16 Mar 2020 17:19:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Mon, 16 Mar 2020 19:18:43 -0500 Message-ID: To: Dave Rice Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000077f90905a101e2b8" Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Tue, 17 Mar 2020 00:19:20 -0000 --00000000000077f90905a101e2b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Dave, On Mon, Mar 16, 2020 at 6:00 PM Dave Rice wrote: > > > On Mar 9, 2020, at 9:01 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, Steve, > > Thanks very much for following up on this. > > For the purpose of this note, please consider that I'm not replying as on= e > of the co-chairs. > > [deleted down to] > And I really want to defer to the working group about the actual titles, > so please do the right thing. > > So, here's what I've seen people do with multi-document specifications at > the IETF. > > - People use common title prefixes in Internet Drafts and RFCs to make > it easier to find stuff that is part of the specification, and to not = find > things that aren't. If something like "Matroska Media Container" as a > prefix would apply to any of the specifications you're working on now = or > thinking about in the future, that would be helpful to your readers. I > assumed that form in the following suggestions, so if you can think of= a > better prefix, please use it to improve the following suggestions! > - For "Matroska Tags", that's pretty close to what I'd hope for. If it > was "Matroska Media Container Tags", would that work? > - For "Matroska Codec" - the abstract says this is actually "Matroska > Codec Mappings", so that seems like the title needs to change a bit mo= re. > If the document title was something like "Matroska Media Container Cod= ec > Mappings", would that work? > - For "Matroska Specifications", that probably is too broad (because > there are two other Matroska specifications in the working group now).= You > used the term "core" in your reply, and I know the working group has b= een > considering whether to publish chapters in a separate document, so it = seems > possible that there will be at least one non-core specification at som= e > point. Would it be accurate to use something like "Matroska Media Cont= ainer > Core Specification" for this one? > > I=E2=80=99m not sure about the word =E2=80=98Media=E2=80=99, how about: > Matroska File Format Specification > Matroska File Format Codec Mappings > Matroska File Format Metadata Tags > > I think the term =E2=80=9CFile Format=E2=80=9D is a bit more accessible t= han =E2=80=9CContainer=E2=80=9D. > Also I see that MXF uses similar wording at > http://web.archive.org/web/20051210203751/http://www.smpte.org/smpte_stor= e/standards/pdf/s377m.pdf > . > > There are (many) other titles that would work for me, so please don't > focus on the details. > > I still want to defer to the working group on the exact titles, but your proposals capture the ideas I was trying to convey in my proposals (looks like a document set, clearer what the relationship between the documents is, and titles seem clear to me). And thanks for the pointer to the MXF document. It may be useful to match their terminology, given an opportunity to do so. Do The Right Thing, of course :-) Best, Spencer --00000000000077f90905a101e2b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Dave,=C2=A0

On Mon, Mar 16, 2020 at 6:= 00 PM Dave Rice <dave@dericed.com> wrote:



H= i, Steve,=C2=A0

Thanks very much for following up on thi= s.=C2=A0

For the purpose of this note, please cons= ider that I'm not replying as one of the co-chairs.=C2=A0
[deleted down to]=C2= =A0
And I really want to defer to the= working group about the actual titles, so please do the right thing.=C2=A0

So, here's what I've seen people do with = multi-document specifications at the IETF.
  • People use com= mon title prefixes in Internet Drafts and RFCs to make it easier to find st= uff that is part of the specification, and to not find things that aren'= ;t. If something like "Matroska=C2=A0Media Container" as a prefix= would apply to any of the specifications you're working on now or thin= king about in the future, that would be helpful to your readers. I assumed = that form in the following suggestions, so if you can think of a better pre= fix, please use it to improve the following suggestions!
  • For "= Matroska Tags", that's pretty close to what I'd hope for. If i= t was "Matroska Media Container Tags", would that work?
  • F= or "Matroska Codec" - the abstract says this is actually "Ma= troska Codec Mappings", so that seems like the title needs to change a= bit more. If the document title was something like "Matroska Media Co= ntainer Codec Mappings", would that work?
  • For "Matroska S= pecifications", that probably is too broad (because there are two othe= r Matroska specifications in the working group now). You used the term &quo= t;core" in your reply, and I know the working group has been consideri= ng whether to publish chapters in a separate document, so it seems possible= that there will be at least one non-core specification at some point. Woul= d it be accurate to use something like "Matroska Media Container Core = Specification" for this one?
I=E2=80=99m not sure about the word =E2=80=98Media=E2=80=99, how = about:
Matroska File Format Specification
Matroska File= Format Codec Mappings
Matroska File Format Metadata Tags

I think the term =E2=80=9CFile Format=E2=80=9D is a bit m= ore accessible than =E2=80=9CContainer=E2=80=9D. Also I see that MXF uses s= imilar wording at=C2=A0http://web.archive.org/web/20051210203751/http://www.smpte.org/smpte_stor= e/standards/pdf/s377m.pdf.

There are (many) other ti= tles that would work for me, so please don't focus on the details.=C2= =A0
I still want to defer to the working group on the exact titles, but your p= roposals capture the ideas I was trying to convey in my proposals (looks li= ke a document set, clearer what the relationship between the documents is, = and titles seem clear to me).

And thanks for the p= ointer to the MXF document. It may be useful to match their terminology, gi= ven an opportunity to do so.=C2=A0

Do The Right Th= ing, of course :-)

Best,

= Spencer=C2=A0
--00000000000077f90905a101e2b8-- From nobody Tue Mar 17 01:35:28 2020 Return-Path: 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 18C053A1AF5 for ; Tue, 17 Mar 2020 01:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 piubXIppwX8T for ; Tue, 17 Mar 2020 01:35:24 -0700 (PDT) Received: from 2.mo173.mail-out.ovh.net (2.mo173.mail-out.ovh.net [178.33.251.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140BA3A1AF4 for ; Tue, 17 Mar 2020 01:35:23 -0700 (PDT) Received: from player796.ha.ovh.net (unknown [10.108.35.90]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id 13C461336F3 for ; Tue, 17 Mar 2020 09:35:21 +0100 (CET) Received: from mediaarea.net (p548F9CE2.dip0.t-ipconnect.de [84.143.156.226]) (Authenticated sender: jerome@mediaarea.net) by player796.ha.ovh.net (Postfix) with ESMTPSA id 257BE10709523 for ; Tue, 17 Mar 2020 08:35:20 +0000 (UTC) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <4c58b215-2654-de39-7f98-ea39ca980987@mediaarea.net> Date: Tue, 17 Mar 2020 09:35:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 10072582043029934225 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefgedguddvtdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuffhomhgrihhnpeifihhkihhpvgguihgrrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudehiedrvddvieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleeirdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Tue, 17 Mar 2020 08:35:26 -0000 On 17/03/2020 00:00, Dave Rice wrote: > I’m not sure about the word ‘Media’, It may make titles too long without a big added value. > how about: > Matroska File Format Specification Matroska File Format Core Specification? > [...] > I think the term “File Format” is a bit more accessible than “Container”. Matroska can be used without a storage device, e.g. streaming. Checking a definition of "file" [1], it may limit the scope of Matroska in the mind of people. "Container" is more and more known [2] and more generic IMO. In contrast another well known container format [3], also having some streaming capabilities, has "file" in its name, so maybe better to match the terminology seen in other similar formats. [1] https://en.wikipedia.org/wiki/Computer_file [2] https://en.wikipedia.org/wiki/Digital_container_format [3] https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format From nobody Sun Mar 22 00:41:17 2020 Return-Path: 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 888573A0F2E for ; Sun, 22 Mar 2020 00:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=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=mnot.net header.b=VuQDlS2K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QEWgc+ut 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 3a6IugNug1Iz for ; Sun, 22 Mar 2020 00:41:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4AA3A0C44 for ; Sun, 22 Mar 2020 00:41:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 48A954D4 for ; Sun, 22 Mar 2020 03:32:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 22 Mar 2020 03:32:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=SDL2ehZfhg1gQ2rHqqSJKqT0SZb6QmhICZcInoCwHFk=; b=VuQDlS2K 14EgVFU3E6GXLaelt/oczu5fkUkCwEm5cw7UJdghBczAIz4/vLm6190ZFc6ijCbb 7Se9StyvPtj7FnRFsQ6QLz74Cfg6V0T+Mr0YEm23dln8QlrcygdUA6APbbremLJb pH3QOjiPGvnu8ZE4UDPnS0EpOWBKNDqos7B9+N5BTFwtd1fV/LnnAMliTJaNzznM 1o8XbCMLYmkMLxDQ3fu66KDQXAAoIrukOob9Xwe/b2Ahy2h49+0WLn+Cz41vTDQC fwhjNQlBWowd+9xAdscaq6vaOIwgAtKfWgmiJxNe9O5E+1jHGEGl0bss5cTnH+Xp X0JTdu0lGyJTEQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=SDL2ehZfhg1gQ2rHqqSJKqT0SZb6Q mhICZcInoCwHFk=; b=QEWgc+utWw4wBC3FixuqudS/HH/Uc5lbUtTbEXxQ53+d0 X0C5/d5bBeqrxz0Whfn2J9JDUbR5AplgWi8V8Wfsujs6OSQxGSgCDf/r6/9dufQp gg0sEK9EWrarKneRGMjV4zdEtNrKHN7p9y/HoE8gIm0vE1C56rpJlnCNRqSgB7fo Xf9BsBjqWh/yuXDftNDQ3kuCPkAAKx9sJFPLhdLwxBAFobo7FhjnxYgieLtUiF23 YN90d6huh45A1DP3jyo+gD3pOApkd77MVT1xQCTLty95Vd9P27oyvfmXYZdeSgJc 4ONDIGwR1DqanjSZBk5oYGhmzxxOsZSSzXOvSti9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeghedgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphepgedtrdejledrjedtrddvheenucevlhhushhtvghr ufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.79.70.25]) by mail.messagingengine.com (Postfix) with ESMTPA id AC00230624E4 for ; Sun, 22 Mar 2020 03:32:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2547870679571360782==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200322073226.AC00230624E4@mailuser.nyi.internal> Date: Sun, 22 Mar 2020 03:32:26 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org 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: Sun, 22 Mar 2020 07:41:11 -0000 --===============2547870679571360782== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #357 Create a register to identify an audiotrack as audiocommentry. (2 = by Nottt, mcr) https://github.com/cellar-wg/matroska-specification/issues/357 [format = addition]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============2547870679571360782== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday March 22, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

Repositories tracked by this digest:

 --===============2547870679571360782==-- From nobody Sun Mar 29 04:51:50 2020 Return-Path: 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 B246F3A182B for ; Sun, 29 Mar 2020 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=matroska-org.20150623.gappssmtp.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 6QFh74FYLMez for ; Sun, 29 Mar 2020 04:51:48 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 3030A3A1828 for ; Sun, 29 Mar 2020 04:51:47 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id z5so16614394wml.5 for ; Sun, 29 Mar 2020 04:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=Q3Pi4f8Rub+UyYZImwJS2wODFg4Hla5UuMsNmwy582Q=; b=kqwHSYMan8o2JTq84XzGQSc8YU/Q9TFQ/t5fX1o0i91tBlyyHPNy7xPJrdMQSmjd09 VLa9NPRTrE/k5lgqrxKPNkPl8X03Ky5WX8vD5NA5XTsojv75EDt437x33lP6irjUV1y6 MJWQ/avYIq9KvUM9VXr91fHIF3dNE4LS6zNBESm3PXI+GKPI9PpzapFiwRPmr2isVZen spZAzNe5tJ1mFQQ3AsocRXkHJ5ZuGraC6wTS6QFbyFl+NP8G3HVZ0VSkEstj5NMgtMWh 7FaZXRv8uoGNHU3GJN5hCbjPzfkGRDxuqf2xRErl9EoA46eMelyZ54AZZRsX8rOMjEci 08jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=Q3Pi4f8Rub+UyYZImwJS2wODFg4Hla5UuMsNmwy582Q=; b=Ep+lrpBtF5JUtyS9JBkWNoW3VRvNJOTDVx1lA1c2ysV+HDMUM4NArohiGK316nygRl DGOAyw7Ga2YJ7YtR9Uzf0eoEa6B+N2WQvaHHQKIM5qhq/Rnb3006QEie90MhR0CHBRE+ 5RG2wD0OzAFo6T1Ia22fUjHwyGEQFZyAoiwV+pyKFlb3+oXY+RAKr+CplcKErfvNjFnv tFB5vRQ/R5jPRV3SZyBd4Wj+T6f867iEPIVk+opOpMKE4US2bntv9QUMyVneod64S3LK UpqIhMy3rpkbdYecfHqXS8TA/YHwemYbGg2YW9B7uxDNxLAXNLI+zs6jZt0pTlbKqAMc /r5A== X-Gm-Message-State: ANhLgQ3L3L54Unh7J0dTTYfaxQRAuE6TDwmbitlqkAKN7AJvfHrW9rM1 5QvG/KgvfTcvLAutndzqGaFswDKh96m93g== X-Google-Smtp-Source: ADFU+vswMbgpvbAyDcyZD+0+MAqIIk9VipcCvKdvy6eQbjqbEU1fjCPwA3fpXnfRYO3/IDUaZ/tM5Q== X-Received: by 2002:a7b:cbd6:: with SMTP id n22mr2473690wmi.29.1585482706017; Sun, 29 Mar 2020 04:51:46 -0700 (PDT) Received: from [192.168.3.11] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id 19sm3676181wmi.32.2020.03.29.04.51.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Mar 2020 04:51:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Steve Lhomme Mime-Version: 1.0 (1.0) Date: Sun, 29 Mar 2020 13:51:44 +0200 Message-Id: <7BCDD252-0ADB-413C-BA0F-F73A65C1868B@matroska.org> References: <4c58b215-2654-de39-7f98-ea39ca980987@mediaarea.net> In-Reply-To: <4c58b215-2654-de39-7f98-ea39ca980987@mediaarea.net> To: cellar@ietf.org X-Mailer: iPad Mail (17D50) Archived-At: Subject: Re: [Cellar] Matroska document titles X-BeenThere: cellar@ietf.org 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: Sun, 29 Mar 2020 11:51:50 -0000 I agree with J=C3=A9r=C3=B4me on both. Container is the proper word, althoug= h nowadays it's more popular for other things. We should use the proper word= ASAP so we don't create confusion like we had with our own concept of timec= odes. The "core" may be tricky. It sounds like it's the bare minimum to Matroska w= hen in fact a lot of things are not essential (Cues or Chapters for example)= . How about=20 Matroska Media Container Format Specifications Matroska Media Container Codec Specifications Matroska Media Container Tags Specifications=20 > On 17 Mar 2020, at 09:35, Jerome Martinez wrote: >=20 > =EF=BB=BFOn 17/03/2020 00:00, Dave Rice wrote: >=20 >> I=E2=80=99m not sure about the word =E2=80=98Media=E2=80=99, >=20 > It may make titles too long without a big added value. >=20 >=20 >> how about: >> Matroska File Format Specification >=20 > Matroska File Format Core Specification? >=20 >=20 >> [...] >> I think the term =E2=80=9CFile Format=E2=80=9D is a bit more accessible t= han =E2=80=9CContainer=E2=80=9D. >=20 > Matroska can be used without a storage device, e.g. streaming. > Checking a definition of "file" [1], it may limit the scope of Matroska in= the mind of people. > "Container" is more and more known [2] and more generic IMO. > In contrast another well known container format [3], also having some stre= aming capabilities, has "file" in its name, so maybe better to match the ter= minology seen in other similar formats. >=20 > [1] https://en.wikipedia.org/wiki/Computer_file > [2] https://en.wikipedia.org/wiki/Digital_container_format > [3] https://en.wikipedia.org/wiki/ISO/IEC_base_media_file_format >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Mar 31 07:07:58 2020 Return-Path: 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 A61813A21C3; Tue, 31 Mar 2020 07:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no 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 oPS3zZcT9Ose; Tue, 31 Mar 2020 07:07:52 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B45A3A21E7; Tue, 31 Mar 2020 07:07:48 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:35341 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jJHYG-000zBX-VV; Tue, 31 Mar 2020 10:07:43 -0400 From: Dave Rice Message-Id: <9CF47172-A0AD-4ABF-B5BF-59D42E284867@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_30556DCC-56EA-4B1B-94B9-8E314D6BEEFE" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 31 Mar 2020 10:07:35 -0400 In-Reply-To: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Adam Roach To: draft-ietf-cellar-ffv1.all@ietf.org References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-2.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 14:07:57 -0000 --Apple-Mail=_30556DCC-56EA-4B1B-94B9-8E314D6BEEFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I=E2=80=99m providing an update to my status update on this review, the = prior one is at = https://mailarchive.ietf.org/arch/msg/cellar/UPdYs9A1FivzQJWiiW3uHLPSYwE/ = . To simply the reading of this email, I=E2=80=99m simply going to = remove what (IMHO) has already been addressed by = https://github.com/FFmpeg/FFV1/pull/185 = . > On Jan 9, 2020, at 11:02 AM, Dave Rice wrote: [=E2=80=A6] >> On Jan 2, 2020, at 6:26 PM, Adam Roach wrote: >>=20 >> This is my AD review for draft-ietf-cellar-ffv1, which I am = processing >> at Alexey Melinikov's request. Thanks to everyone who has taken the = time >> to document these formats for publication as an RFC. >>=20 >> I have identified a couple of issues that will need to be addressed = prior to >> IETF last call (which are clearly identified below), as well as a = number of >> smaller issues that can be addressed as normal IETF last call = comments. >>=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A72.2.2: >>=20 >>> Note: the operators and the order of precedence are the same as used >>> in the C programming language [ISO.9899.1990]. >> ... >>> "a ^ b" means a raised to the b-th power. >>=20 >> One of these two statements is incorrect: the "^" operator in C is a = bitwise >> XOR, not a power operator. C has no built-in exponentiation operator, = and >> relies on a library-provided `pow(a,b)` function. >>=20 >> Because this introduces an ambiguity into the specification, it will = need >> to be corrected before entering IETF last call. >=20 > This impacts a lot of the math. Is there consensus to replace `a^b` = with `pow(a,b)` or should `a^b` be defined locally as an exception? Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A72.2.2: >>=20 >>> "a >> b" means arithmetic right shift of two's complement integer >>> representation of a by b binary digits. >>=20 >> 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: >>=20 >> 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. >>=20 >> Because this introduces an ambiguity into the specification, it will = need >> to be corrected before entering IETF last call. >=20 > I=E2=80=99m uncertain, nudging the other authors. Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A72.2.5: >>=20 >>> a~b,c. the 'b,c'-th value of a sequence of a >>=20 >> Please explain this with more words. I can't figure out what it = means. >=20 > Same. I=E2=80=99m uncertain, nudging the other authors. Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.4: >>=20 >>> context =3D Q_{0}[l - tl] + >>> Q_{1}[tl - t] + >>> Q_{2}[t - tr] + >>> Q_{3}[L - l] + >>> Q_{4}[T - t] >>=20 >> This is the first time in the document we're encountering Q. Please = add a >> forward reference to its definition. >=20 > To do, as the language of the Quantization Table Sets section never = says that the table is referred to as Q. >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.1.1: >>=20 >>> S_{i+1,C_{i}} =3D zero_state_{S_{i,C_{i}}} XOR >>> l_i =3D L_i XOR >>> t_i =3D R_i - r_i <=3D=3D >>> b_i =3D 0 <=3D=3D> >>> L_i < R_i - r_i >>=20 >> Substantial parts of this syntax are undefined at this point in the = document. >>=20 >> Presumably "XOR" means "exclusive or," although it is unclear whether = this is >> intended to be a boolean or bitwise operation. >>=20 >> The "<=3D=3D" and "<=3D=3D>" notation is also without explanation, = and I can't even make >> an educated guess at their intended meaning. >>=20 >> There is no explanation what it might mean to combine a series of = assignment >> operations (and one comparison operation) with these XOR, <=3D=3D, = and <=3D=3D> symbols. >>=20 >> This needs to be clarified (for all of figures 7 through 9) before = the >> document can go to IETF last call. >=20 > To do Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = and = https://github.com/FFmpeg/FFV1/pull/188/files = . >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.1.1.1: >>=20 >>> Above describes the range decoding, encoding is defined as any >>> process which produces a decodable bytestream. >>=20 >> Would it be reasonable to include a non-normative example of one such >> process? >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.1.2: >>> exact contexts used are best described by the >>> following code, followed by some comments. >>=20 >> I can't find the referenced comments. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.1.2: >>=20 >>> 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=3D abs(v); | >>> int e=3D log2(a); | >>> | >>> for (i =3D 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 =3D e-1; i >=3D 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| >>> } | >>> } | >>> } | >>=20 >> The "type" column here appears superfluous, and should either = employed or >> removed. >=20 > To do >=20 >> The behavior of the function "put_rac" isn't defined anywhere. While = the purpose >> of its first two parameters can be deduced from context, the purpose = of the >> third parameter is baffling. For avoidance of doubt, please add a = description of >> what this function does, and what its parameters mean. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.2.1: >>=20 >>> pseudo-code | type >>> --------------------------------------------------------------|----- >>> int get_ur_golomb(k) { | >>> for (prefix =3D 0; prefix < 12; prefix++) { | >>> if (get_bits(1)) { | >>> return get_bits(k) + (prefix << k) | >>> } | >>> } | >>> return get_bits(bits) + 11 | >>> } | >>> | >>> int get_sr_golomb(k) { | >>> v =3D get_ur_golomb(k); | >>> if (v & 1) return - (v >> 1) - 1; | >>> else return (v >> 1); | >>> } >>=20 >> The "type" column here appears superfluous, and should either = employed or >> removed. >=20 > To do. >=20 >> Please clarify the meaning of "ur" and "sr" in the function names. >=20 > To do, define function names with references to ur / sr definitions. >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.2.1.1: >>=20 >>> +----------------+-------+ >>> | bits | value | >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ >>> | 1 | 0 | >>> +----------------+-------+ >>> | 01 | 1 | >>> +----------------+-------+ >>> | ... | ... | >>> +----------------+-------+ >>> | 0000 0000 0001 | 11 | >>> +----------------+-------+ >>> | 0000 0000 0000 | ESC | >>> +----------------+-------+ >>=20 >> This is pretty confusing, not least of all because the base of the = number on the >> right is unclear (given that all the shown values contain 1's and 0's >> exclusively). I would suggest: >>=20 >> +----------------+-------+ >> | bits | value | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ >> | 1 | 0 | >> +----------------+-------+ >> | 01 | 1 | >> +----------------+-------+ >> | ... | ... | >> +----------------+-------+ >> | 00 0000 0001 | 9 | >> +----------------+-------+ >> | 000 0000 0001 | 10 | >> +----------------+-------+ >> | 0000 0000 0001 | 11 | >> +----------------+-------+ >> | 0000 0000 0000 | ESC | >> +----------------+=E2=80=94=E2=80=94=E2=80=94+ >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.2.2.1: >>=20 >>> pseudo-code | type >>> --------------------------------------------------------------|----- >>> log2_run[41]=3D{ | >>> 0, 0, 0, 0, 1, 1, 1, 1, | >>> 2, 2, 2, 2, 3, 3, 3, 3, | >>> 4, 4, 5, 5, 6, 6, 7, 7, | >>> 8, 9,10,11,12,13,14,15, | >>> 16,17,18,19,20,21,22,23, | >>> 24, | >>> }; | >>> | >>> if (run_count =3D=3D 0 && run_mode =3D=3D 1) { = | >>> if (get_bits(1)) { | >>> run_count =3D 1 << log2_run[run_index]; | >>> if (x + run_count <=3D w) { | >>> run_index++; | >>> } | >>> } else { | >>> if (log2_run[run_index]) { | >>> run_count =3D get_bits(log2_run[run_index]); | >>> } else { | >>> run_count =3D 0; | >>> } | >>> if (run_index) { | >>> run_index--; | >>> } | >>> run_mode =3D 2; | >>> } | >>> } | >>=20 >>=20 >> The "type" column here appears superfluous, and should either = employed or >> removed. >>=20 >>=20 >>> The log2_run function is also used within [ISO.14495-1.1999]. >>=20 >> The reference to "log2_run" as a "function" is perplexing, as = log2_run is defined >> as an array in the above pseudocode. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A73.8.2.3: >>=20 >> Some light documentation of the "state" structure would make this = pseudocode >> much easier to follow. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74: >>=20 >>> The same context that is initialized to 128 is used for all fields = in >>> the header. >>=20 >> This phrasing is confusing, as it reads like it's referring to some >> previously-mentioned context that is best identified as containing = "128." After >> convincing myself that I didn't miss such a thing, I *think* you = might mean: >>=20 >> All fields in the header use the same context, which is >> initialized to 128. >>=20 >> Although, even with that adjustment, I'm not sure which header you're = talking >> about. The only header mentioned anywhere earlier in the document is = the >> "Slice Header," and that seems unlikely to be what you're referring = to. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74.1: >>=20 >>> state_transition_delta[ i ] | sr >> ... >>> QuantizationTableSet( i ) | >>=20 >> This psuedo-code appears to use both "[]" and "()" as array = operators. I >> understand this is only pseudocode, but please try to remain = consistent with >> the meaning of operators. >>=20 >> Also, "QuantiztionTableSet" is missing a type designation. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74.1.16: >>=20 >>> +-------+--------------------------------------------+ >>> | value | error detection/correction type | >>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+ >>> | 0 | 32-bit CRC on the global header | >>> +-------+--------------------------------------------+ >>> | 1 | 32-bit CRC per slice and the global header | >>> +-------+--------------------------------------------+ >>> | Other | reserved for future use | >>> +-------+--------------------------------------------+ >>=20 >> I'm still perplexed by the intended meaning of "header.=E2=80=9D >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74.1.17: >>=20 >>> +-------+-------------------------------------+ >>> | value | relationship | >>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + >>> | 0 | Frames are independent or dependent | >>> | | (keyframes and non keyframes) | >>> +-------+-------------------------------------+ >>> | 1 | Frames are independent (keyframes | >>> | | only) | >>> +-------+-------------------------------------+ >>> | Other | reserved for future use | >>> +-------+-------------------------------------+ >>>=20 >>> Table 14 >>=20 >> 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. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74.6: >>=20 >>> pseudo-code | type >>> --------------------------------------------------------------|----- >>> SliceContent( ) { | >>> if (colorspace_type =3D=3D 0) { | >>> for (p =3D 0; p < primary_color_count; p++) { | >>> for (y =3D 0; y < plane_pixel_height[ p ]; y++) { | >>> Line( p, y ) | >>> } | >>> } | >>> } else if (colorspace_type =3D=3D 1) { | >>> for (y =3D 0; y < slice_pixel_height; y++) { | >>> for (p =3D 0; p < primary_color_count; p++) { | >>> Line( p, y ) | >>> } | >>> } | >>> } | >>> } | >>=20 >> Without a "type" indicated on the "Line( p, y )" lines, this encoding = appears >> to be ambiguous. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A74.7: >>=20 >>> pseudo-code | type >>> --------------------------------------------------------------|----- >>> Line( p, y ) { | >>> if (colorspace_type =3D=3D 0) { | >>> for (x =3D 0; x < plane_pixel_width[ p ]; x++) { | >>> sample_difference[ p ][ y ][ x ] | >>> } | >>> } else if (colorspace_type =3D=3D 1) { | >>> for (x =3D 0; x < slice_pixel_width; x++) { | >>> sample_difference[ p ][ y ][ x ] | >>> } | >>> } | >>> } | >>=20 >> Although redundant with the request above regarding section 4.6, = please >> add "type" indicators for the "sample_difference[ p ][ y ][ x ]" = lines. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A76: >>=20 >> While it does provide compression (my understanding is that a typical >> ratio is about 2:1), FFV1 still produces a very large bitstream, due = to >> its lossless properties. This does present some security challenges = that >> need to be cited. >>=20 >> I would expect this document to include text that is roughly = equivalent to the >> final three paragraphs of RFC 4175, Section 8. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A77: >>=20 >>> This registration is done using the template defined in [RFC6838] = and >>> following [RFC4855]. >>=20 >> To avoid the need to dereference the cited RFC, please also include = the IANA >> table name ("Media Types") in this paragraph. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A77: >>=20 >>> This >>> media type is framed binary data Section 4.8 of [RFC6838]. >>=20 >> I think this means to say something like: >>=20 >> This media type is framed binary data; see Section 4.8 of = [RFC6838]. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> =C2=A77: >>=20 >>> Published specification: >>>=20 >>> [I-D.ietf-cellar-ffv1] and RFC XXXX. >>=20 >> I can't figure out why two documents are mentioned here -- it would = seem that >> both of these refer to the same document. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >>> 9. Appendixes >>>=20 >>> 9.1. Decoder implementation suggestions >>>=20 >>> 9.1.1. Multi-threading Support and Independence of Slices >>=20 >> This seems like an unnecessarily deep nesting for its contents. = Consider >> collapsing into a single section instead of three nested sections. >=20 > To do >=20 >> = --------------------------------------------------------------------------= - >>=20 >> Section 10 should contain instructions to the RFC editor to remove it = prior to >> publication. >=20 > To do >=20 >> Thanks! >>=20 >> /a >>=20 >=20 Best Regards, Dave Rice --Apple-Mail=_30556DCC-56EA-4B1B-94B9-8E314D6BEEFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,
I=E2=80=99m providing an update to my status update = on this review, the prior one is at https://mailarchive.ietf.org/arch/msg/cellar/UPdYs9A1FivzQJWiiW= 3uHLPSYwE/. To simply the reading of this email, I=E2=80=99m simply = going to remove what (IMHO) has already been addressed by https://github.com/FFmpeg/FFV1/pull/185.

On Jan 9, 2020, at 11:02 AM, Dave Rice <dave@dericed.com> = wrote:

[=E2=80=A6]
<= br class=3D"">
On Jan 2, 2020, at 6:26 = PM, Adam Roach <adam@nostrum.com> wrote:

This is my AD review for draft-ietf-cellar-ffv1, which I am = processing
at Alexey Melinikov's request. Thanks to = everyone who has taken the time
to document these formats = for publication as an RFC.

I have = identified a couple of issues that will need to be addressed prior to
IETF last call (which are clearly identified below), as well = as a number of
smaller issues that can be addressed as = normal IETF last call comments.

---------------------------------------------------------------= ------------

=C2=A72.2.2:

Note: the operators and = the order of precedence are the same as used
in the C = programming language [ISO.9899.1990].
...
"a ^ b" means a raised = to the b-th power.

One of = these two statements is incorrect: the "^" operator in C is a bitwise
XOR, not a power operator. C has no built-in exponentiation = operator, and
relies on a library-provided `pow(a,b)` = function.

Because this introduces an = ambiguity into the specification, it will need
to be = corrected before entering IETF last call.

This impacts a lot of the math. Is there consensus to replace = `a^b` with `pow(a,b)` or should `a^b` be defined locally as an = exception?

Michael Niedermayer resolved this in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A72.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=E2=80=99m uncertain, = nudging the other authors.
Michael Niedermayer resolved this in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A72.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=E2=80=99m = uncertain, nudging the other authors.

Michael= Niedermayer resolved this in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A73.4:

context =3D Q_{0}[l - tl] +
=           Q_{1}[tl - = t] +
=           Q_{2}[t - = tr] +
=           Q_{3}[L - l] =  +
=           Q_{4}[T - = t]

This is the first time in = the document we're encountering Q. Please add a
forward = reference to its definition.

To = do, as the language of the Quantization Table Sets section never says = that the table is referred to as Q.

---------------------------------------------------------------= ------------

=C2=A73.8.1.1:

S_{i+1,C_{i}} =3D =  zero_state_{S_{i,C_{i}}} XOR
=           l_i =3D =  L_i =             &n= bsp;        XOR
=           t_i =3D =  R_i - r_i =             &n= bsp;  <=3D=3D
=           b_i =3D =  0 =             &n= bsp;          <=3D=3D= >
=           L_i < =  R_i - r_i

Substantial = parts of this syntax are undefined at this point in the document.

Presumably "XOR" means "exclusive or," = although it is unclear whether this is
intended to be a = boolean or bitwise operation.

The "<=3D=3D= " and "<=3D=3D>" notation is also without explanation, and I can't = even make
an educated guess at their intended meaning.

There is no explanation what it might mean to = combine a series of assignment
operations (and one = comparison operation) with these XOR, <=3D=3D, and <=3D=3D> = symbols.

This needs to be clarified (for = all of figures 7 through 9) before the
document can go to = IETF last call.

To do


---------------------------------------------------------------= ------------

=C2=A73.8.1.1.1:

Above = describes the range decoding, encoding is defined as any
= process which produces a decodable bytestream.

Would it be reasonable to include = a non-normative example of one such
process?

To do

---------------------------------------------------------------= ------------

=C2=A73.8.1.2:
exact contexts used are = best described by the
following code, followed by some = comments.

I can't find the = referenced comments.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.1.2:
pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
void put_symbol(RangeCoder *c, uint8_t *state, int = v, int \   |
is_signed) { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">     int i; =             &n= bsp;           &nbs= p;            =             &n= bsp; |
    put_rac(c, state+0, = !v); =             &n= bsp;           &nbs= p;        |
=     if (v) { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">         int a=3D = abs(v); =             &n= bsp;           &nbs= p;            =   |
=         int e=3D log2(a); =             &n= bsp;           &nbs= p;            =  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
        for = (i =3D 0; i < e; i++) { =             &n= bsp;           &nbs= p;   |
=             pu= t_rac(c, state+1+min(i,9), 1); //1..10 =         |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=         put_rac(c, = state+1+min(i,9), 0); =             &n= bsp;        |
=         for (i =3D e-1; i >=3D = 0; i--) { =             &n= bsp;           &nbs= p;|
=             pu= t_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
        if = (is_signed) { =             &n= bsp;           &nbs= p;            = |
=             pu= t_rac(c, state+11 + min(e, 10), v < 0); //11..21|
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

The "type" column here appears = superfluous, and should either employed or
removed.

To do

The behavior of the = function "put_rac" isn't defined anywhere. While the purpose
of its first two parameters can be deduced from context, the = purpose of the
third parameter is baffling. For avoidance = of doubt, please add a description of
what this function = does, and what its parameters mean.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.1:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
int get_ur_golomb(k) { =             &n= bsp;           &nbs= p;            =   |
    for (prefix =3D 0; = prefix < 12; prefix++) { =             &n= bsp;   |
=         if (get_bits(1)) { =             &n= bsp;           &nbs= p;          |
=             re= turn get_bits(k) + (prefix << k) =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
=     return get_bits(bits) + 11 =             &n= bsp;           &nbs= p;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
int get_sr_golomb(k) { =             &n= bsp;           &nbs= p;            =   |
    v =3D = get_ur_golomb(k); =             &n= bsp;           &nbs= p;           |
    if (v & 1) return - (v >> = 1) - 1; =             &n= bsp;           |     else =       return   (v >> 1); =             &n= bsp;           &nbs= p;   |
}

The "type" column here appears superfluous, and should either = employed or
removed.

To do.

Please clarify the meaning of "ur" and "sr" in the function = names.

To do, define function = names with references to ur / sr definitions.

---------------------------------------------------------------= ------------

=C2=A73.8.2.1.1:

=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | bits =           | value |
=             &n= bsp;        +=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+
=             &n= bsp;        | 1 =             &n= bsp;| 0     |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 01 =             | = 1     |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | ... =            | ... =   |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 0000 0000 0001 | = 11    |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 0000 0000 0000 | = ESC   |
=             &n= bsp;        +----------------+----= ---+

This is pretty confusing, = not least of all because the base of the number on the
right= is unclear (given that all the shown values contain 1's and 0's
exclusively). I would suggest:

=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | bits =           | value |
=             &n= bsp;          +=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+
=             &n= bsp;          | 1 =             &n= bsp;| 0     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 01 =             | = 1     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | ... =            | ... =   |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 00 = 0000 0001   | 9     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 000 = 0000 0001  | 10    |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 0000 = 0000 0001 | 11    |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 0000 = 0000 0000 | ESC   |
=             &n= bsp;          +---------= -------+=E2=80=94=E2=80=94=E2=80=94+

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.2.1:

pseudo-code= =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
log2_run[41]=3D{ =             &n= bsp;           &nbs= p;            =           |
 0, 0, 0, 0, 1, 1, 1, 1, =             &n= bsp;           &nbs= p;            = |
 2, 2, 2, 2, 3, 3, 3, 3, =             &n= bsp;           &nbs= p;            = |
 4, 4, 5, 5, 6, 6, 7, 7, =             &n= bsp;           &nbs= p;            = |
 8, 9,10,11,12,13,14,15, =             &n= bsp;           &nbs= p;            = |
16,17,18,19,20,21,22,23, =             &n= bsp;           &nbs= p;            = |
24, =             &n= bsp;           &nbs= p;            =             &n= bsp;        |
}; =             &n= bsp;           &nbs= p;            =             &n= bsp;         |
= =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
if (run_count =3D=3D 0 && run_mode =3D=3D 1) = { =             &n= bsp;          |
    if (get_bits(1)) { =             &n= bsp;           &nbs= p;            =   |
=         run_count =3D 1 << = log2_run[run_index]; =             &n= bsp;   |
=         if (x + run_count <=3D = w) { =             &n= bsp;           &nbs= p;   |
run_index++; =             &n= bsp;           &nbs= p;            = |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">         if = (log2_run[run_index]) { =             &n= bsp;           &nbs= p;  |
=             ru= n_count =3D get_bits(log2_run[run_index]); =        |
=         } else { =             &n= bsp;           &nbs= p;            =         |
=             ru= n_count =3D 0; =             &n= bsp;           &nbs= p;          |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=         if (run_index) { =             &n= bsp;           &nbs= p;            = |
run_index--; =             &n= bsp;           &nbs= p;            = |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=         run_mode =3D 2; =             &n= bsp;           &nbs= p;            =    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |


The "type" column = here appears superfluous, and should either employed or
removed.


The log2_run function = is also used within [ISO.14495-1.1999].

The reference to "log2_run" as a "function" is perplexing, as = log2_run is defined
as an array in the above = pseudocode.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.3:
Some light documentation of the "state" structure would make = this pseudocode
much easier to follow.

To do

---------------------------------------------------------------= ------------

=C2=A74:

The same context that = is initialized to 128 is used for all fields in
the = header.

This phrasing is = confusing, as it reads like it's referring to some
previously-mentioned context that is best identified as = containing "128." After
convincing myself that I didn't = miss such a thing, I *think* you might mean:

=   All fields in the header use the same context, which is
  initialized to 128.

Although, even with that adjustment, I'm not sure which = header you're talking
about. The only header mentioned = anywhere earlier in the document is the
"Slice Header," = and that seems unlikely to be what you're referring to.

To do

---------------------------------------------------------------= ------------

=C2=A74.1:

=             st= ate_transition_delta[ i ] =             &n= bsp;         | sr
...
=         QuantizationTableSet( i = ) =             &n= bsp;           &nbs= p;   |

This = psuedo-code appears to use both "[]" and "()" as array operators. =  I
understand this is only pseudocode, but please try = to remain consistent with
the meaning of operators.

Also, "QuantiztionTableSet" is missing a type = designation.

To do

---------------------------------------------------------------= ------------

=C2=A74.1.16:

+-------+--------------------------------------------+
       | value | error = detection/correction type |
+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+
=        | 0     | = 32-bit CRC on the global header |
+-------+--------------------------------------------+
       | 1 =     | 32-bit CRC per slice and the global header = |
+-------+--------------------------------------------+
       | Other | reserved = for future use |
+-------+--------------------------------------------+

I'm still perplexed by the = intended meaning of "header.=E2=80=9D

To do

---------------------------------------------------------------= ------------

=C2=A74.1.17:

=            +-------= +-------------------------------------+
=            | = value | relationship =             &n= bsp;          |
=            +=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=            | 0 =     | Frames are independent or dependent |
=            | =       | (keyframes and non keyframes) =       |
=            +-------= +-------------------------------------+
=            | 1 =     | Frames are independent (keyframes =   |
=            | =       | only) =             &n= bsp;           &nbs= p;     |
=            +-------= +-------------------------------------+
=            | = Other | reserved for future use =             |<= br class=3D""> =            +-------= +-------------------------------------+

=             &n= bsp;           &nbs= p;      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.

To do

---------------------------------------------------------------= ------------

=C2=A74.6:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
SliceContent( ) { =             &n= bsp;           &nbs= p;            =        |
=     if (colorspace_type =3D=3D 0) { =             &n= bsp;           &nbs= p;     |
=         for (p =3D 0; p < = primary_color_count; p++) { =           |
=             fo= r (y =3D 0; y < plane_pixel_height[ p ]; y++) {   |
=             &n= bsp;   Line( p, y ) =             &n= bsp;           &nbs= p;        |
} =             &n= bsp;           &nbs= p;            =            |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else if = (colorspace_type =3D=3D 1) { =             &n= bsp;          |
        for (y =3D = 0; y < slice_pixel_height; y++) { =            |
=             fo= r (p =3D 0; p < primary_color_count; p++) { =       |
=             &n= bsp;   Line( p, y ) =             &n= bsp;           &nbs= p;        |
} =             &n= bsp;           &nbs= p;            =            |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

Without a "type" indicated on the = "Line( p, y )" lines, this encoding appears
to be = ambiguous.

To do

---------------------------------------------------------------= ------------

=C2=A74.7:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
Line( p, y ) { =             &n= bsp;           &nbs= p;            =           |
    if (colorspace_type =3D=3D 0) { =             &n= bsp;           &nbs= p;     |
=         for (x =3D 0; x < = plane_pixel_width[ p ]; x++) { =        |
=             sa= mple_difference[ p ][ y ][ x ] =             &n= bsp;    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else if = (colorspace_type =3D=3D 1) { =             &n= bsp;          |
        for (x =3D = 0; x < slice_pixel_width; x++) { =             |<= br class=3D""> =             sa= mple_difference[ p ][ y ][ x ] =             &n= bsp;    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

Although redundant with the = request above regarding section 4.6, please
add "type" = indicators for the "sample_difference[ p ][ y ][ x ]" lines.

To do

---------------------------------------------------------------= ------------

=C2=A76:

While it does provide = compression (my understanding is that a typical
ratio is = about 2:1), FFV1 still produces a very large bitstream, due to
its lossless properties. This does present some security = challenges that
need to be cited.

I would expect this document to include text that is roughly = equivalent to the
final three paragraphs of RFC 4175, = Section 8.

To do

---------------------------------------------------------------= ------------

=C2=A77:

This registration is = done using the template defined in [RFC6838] and
= following [RFC4855].

To avoid = the need to dereference the cited RFC, please also include the IANA
table name ("Media Types") in this paragraph.

To do

---------------------------------------------------------------= ------------

=C2=A77:

This
= media type is framed binary data Section 4.8 of [RFC6838].

I think this means to say = something like:

  This media = type is framed binary data; see Section 4.8 of [RFC6838].

To do

---------------------------------------------------------------= ------------

=C2=A77:

Published = specification:

[I-D.ietf-cellar-ffv1] and = RFC XXXX.

I can't figure out = why two documents are mentioned here -- it would seem that
both of these refer to the same document.

To do

---------------------------------------------------------------= ------------

9.  Appendixes

9.1. =  Decoder implementation suggestions

9.1.1.  Multi-threading Support and Independence of = Slices

This seems like an = unnecessarily deep nesting for its contents. Consider
collapsing into a single section instead of three nested = sections.

To do

---------------------------------------------------------------= ------------

Section 10 should contain = instructions to the RFC editor to remove it prior to
publication.

To = do

Thanks!

/a



Best Regards,
Dave = Rice

= --Apple-Mail=_30556DCC-56EA-4B1B-94B9-8E314D6BEEFE-- From nobody Tue Mar 31 08:17:59 2020 Return-Path: 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 801883A22C5; Tue, 31 Mar 2020 08:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no 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 rIi-APoPbj5v; Tue, 31 Mar 2020 08:17:54 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB3B3A16E0; Tue, 31 Mar 2020 08:17:54 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:39587 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jJIe9-001pM5-Su; Tue, 31 Mar 2020 11:17:52 -0400 From: Dave Rice Message-Id: <36024E3E-9672-4950-B9AA-1F07667DD311@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8E485551-3CF7-48A0-9839-B79D420EC761" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Tue, 31 Mar 2020 11:17:43 -0400 In-Reply-To: <9CF47172-A0AD-4ABF-B5BF-59D42E284867@dericed.com> Cc: Adam Roach , Codec Encoding for LossLess Archiving and Realtime transmission To: draft-ietf-cellar-ffv1.all@ietf.org References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> <9CF47172-A0AD-4ABF-B5BF-59D42E284867@dericed.com> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-2.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 15:17:58 -0000 --Apple-Mail=_8E485551-3CF7-48A0-9839-B79D420EC761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 A few updates in regards to https://github.com/FFmpeg/FFV1/pull/193 = > On Mar 31, 2020, at 10:07 AM, Dave Rice wrote: >=20 > Hi all, > I=E2=80=99m providing an update to my status update on this review, = the prior one is at = https://mailarchive.ietf.org/arch/msg/cellar/UPdYs9A1FivzQJWiiW3uHLPSYwE/ = . To simply the reading of this email, I=E2=80=99m simply going to = remove what (IMHO) has already been addressed by = https://github.com/FFmpeg/FFV1/pull/185 = . >=20 >> On Jan 9, 2020, at 11:02 AM, Dave Rice > wrote: >=20 > [=E2=80=A6] >=20 >>> On Jan 2, 2020, at 6:26 PM, Adam Roach > wrote: >>>=20 >>> This is my AD review for draft-ietf-cellar-ffv1, which I am = processing >>> at Alexey Melinikov's request. Thanks to everyone who has taken the = time >>> to document these formats for publication as an RFC. >>>=20 >>> I have identified a couple of issues that will need to be addressed = prior to >>> IETF last call (which are clearly identified below), as well as a = number of >>> smaller issues that can be addressed as normal IETF last call = comments. >>>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A72.2.2: >>>=20 >>>> Note: the operators and the order of precedence are the same as = used >>>> in the C programming language [ISO.9899.1990]. >>> ... >>>> "a ^ b" means a raised to the b-th power. >>>=20 >>> One of these two statements is incorrect: the "^" operator in C is a = bitwise >>> XOR, not a power operator. C has no built-in exponentiation = operator, and >>> relies on a library-provided `pow(a,b)` function. >>>=20 >>> Because this introduces an ambiguity into the specification, it will = need >>> to be corrected before entering IETF last call. >>=20 >> This impacts a lot of the math. Is there consensus to replace `a^b` = with `pow(a,b)` or should `a^b` be defined locally as an exception? >=20 > Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A72.2.2: >>>=20 >>>> "a >> b" means arithmetic right shift of two's complement integer >>>> representation of a by b binary digits. >>>=20 >>> 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: >>>=20 >>> 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. >>>=20 >>> Because this introduces an ambiguity into the specification, it will = need >>> to be corrected before entering IETF last call. >>=20 >> I=E2=80=99m uncertain, nudging the other authors. >=20 > Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A72.2.5: >>>=20 >>>> a~b,c. the 'b,c'-th value of a sequence of a >>>=20 >>> Please explain this with more words. I can't figure out what it = means. >>=20 >> Same. I=E2=80=99m uncertain, nudging the other authors. >=20 > Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = . >=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.4: >>>=20 >>>> context =3D Q_{0}[l - tl] + >>>> Q_{1}[tl - t] + >>>> Q_{2}[t - tr] + >>>> Q_{3}[L - l] + >>>> Q_{4}[T - t] >>>=20 >>> This is the first time in the document we're encountering Q. Please = add a >>> forward reference to its definition. >>=20 >> To do, as the language of the Quantization Table Sets section never = says that the table is referred to as Q. >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.1.1: >>>=20 >>>> S_{i+1,C_{i}} =3D zero_state_{S_{i,C_{i}}} XOR >>>> l_i =3D L_i XOR >>>> t_i =3D R_i - r_i <=3D=3D >>>> b_i =3D 0 <=3D=3D> >>>> L_i < R_i - r_i >>>=20 >>> Substantial parts of this syntax are undefined at this point in the = document. >>>=20 >>> Presumably "XOR" means "exclusive or," although it is unclear = whether this is >>> intended to be a boolean or bitwise operation. >>>=20 >>> The "<=3D=3D" and "<=3D=3D>" notation is also without explanation, = and I can't even make >>> an educated guess at their intended meaning. >>>=20 >>> There is no explanation what it might mean to combine a series of = assignment >>> operations (and one comparison operation) with these XOR, <=3D=3D, = and <=3D=3D> symbols. >>>=20 >>> This needs to be clarified (for all of figures 7 through 9) before = the >>> document can go to IETF last call. >>=20 >> To do >=20 > Michael Niedermayer resolved this in = https://github.com/FFmpeg/FFV1/pull/187 = and = https://github.com/FFmpeg/FFV1/pull/188/files = . >=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.1.1.1: >>>=20 >>>> Above describes the range decoding, encoding is defined as any >>>> process which produces a decodable bytestream. >>>=20 >>> Would it be reasonable to include a non-normative example of one = such >>> process? >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.1.2: >>>> exact contexts used are best described by the >>>> following code, followed by some comments. >>>=20 >>> I can't find the referenced comments. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.1.2: >>>=20 >>>> 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=3D abs(v); | >>>> int e=3D log2(a); | >>>> | >>>> for (i =3D 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 =3D e-1; i >=3D 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| >>>> } | >>>> } | >>>> } | >>>=20 >>> The "type" column here appears superfluous, and should either = employed or >>> removed. >>=20 >> To do >>=20 >>> The behavior of the function "put_rac" isn't defined anywhere. While = the purpose >>> of its first two parameters can be deduced from context, the purpose = of the >>> third parameter is baffling. For avoidance of doubt, please add a = description of >>> what this function does, and what its parameters mean. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.2.1: >>>=20 >>>> pseudo-code | = type >>>> = --------------------------------------------------------------|----- >>>> int get_ur_golomb(k) { | >>>> for (prefix =3D 0; prefix < 12; prefix++) { | >>>> if (get_bits(1)) { | >>>> return get_bits(k) + (prefix << k) | >>>> } | >>>> } | >>>> return get_bits(bits) + 11 | >>>> } | >>>> | >>>> int get_sr_golomb(k) { | >>>> v =3D get_ur_golomb(k); | >>>> if (v & 1) return - (v >> 1) - 1; | >>>> else return (v >> 1); | >>>> } >>>=20 >>> The "type" column here appears superfluous, and should either = employed or >>> removed. >>=20 >> To do. >>=20 >>> Please clarify the meaning of "ur" and "sr" in the function names. >>=20 >> To do, define function names with references to ur / sr definitions. >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.2.1.1: >>>=20 >>>> +----------------+-------+ >>>> | bits | value | >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ >>>> | 1 | 0 | >>>> +----------------+-------+ >>>> | 01 | 1 | >>>> +----------------+-------+ >>>> | ... | ... | >>>> +----------------+-------+ >>>> | 0000 0000 0001 | 11 | >>>> +----------------+-------+ >>>> | 0000 0000 0000 | ESC | >>>> +----------------+-------+ >>>=20 >>> This is pretty confusing, not least of all because the base of the = number on the >>> right is unclear (given that all the shown values contain 1's and = 0's >>> exclusively). I would suggest: >>>=20 >>> +----------------+-------+ >>> | bits | value | >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ >>> | 1 | 0 | >>> +----------------+-------+ >>> | 01 | 1 | >>> +----------------+-------+ >>> | ... | ... | >>> +----------------+-------+ >>> | 00 0000 0001 | 9 | >>> +----------------+-------+ >>> | 000 0000 0001 | 10 | >>> +----------------+-------+ >>> | 0000 0000 0001 | 11 | >>> +----------------+-------+ >>> | 0000 0000 0000 | ESC | >>> +----------------+=E2=80=94=E2=80=94=E2=80=94+ >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.2.2.1: >>>=20 >>>> pseudo-code | = type >>>> = --------------------------------------------------------------|----- >>>> log2_run[41]=3D{ | >>>> 0, 0, 0, 0, 1, 1, 1, 1, | >>>> 2, 2, 2, 2, 3, 3, 3, 3, | >>>> 4, 4, 5, 5, 6, 6, 7, 7, | >>>> 8, 9,10,11,12,13,14,15, | >>>> 16,17,18,19,20,21,22,23, | >>>> 24, | >>>> }; | >>>> | >>>> if (run_count =3D=3D 0 && run_mode =3D=3D 1) { = | >>>> if (get_bits(1)) { | >>>> run_count =3D 1 << log2_run[run_index]; | >>>> if (x + run_count <=3D w) { | >>>> run_index++; | >>>> } | >>>> } else { | >>>> if (log2_run[run_index]) { | >>>> run_count =3D get_bits(log2_run[run_index]); | >>>> } else { | >>>> run_count =3D 0; | >>>> } | >>>> if (run_index) { | >>>> run_index--; | >>>> } | >>>> run_mode =3D 2; | >>>> } | >>>> } | >>>=20 >>>=20 >>> The "type" column here appears superfluous, and should either = employed or >>> removed. >>>=20 >>>=20 >>>> The log2_run function is also used within [ISO.14495-1.1999]. >>>=20 >>> The reference to "log2_run" as a "function" is perplexing, as = log2_run is defined >>> as an array in the above pseudocode. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A73.8.2.3: >>>=20 >>> Some light documentation of the "state" structure would make this = pseudocode >>> much easier to follow. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74: >>>=20 >>>> The same context that is initialized to 128 is used for all fields = in >>>> the header. >>>=20 >>> This phrasing is confusing, as it reads like it's referring to some >>> previously-mentioned context that is best identified as containing = "128." After >>> convincing myself that I didn't miss such a thing, I *think* you = might mean: >>>=20 >>> All fields in the header use the same context, which is >>> initialized to 128. >>>=20 >>> Although, even with that adjustment, I'm not sure which header = you're talking >>> about. The only header mentioned anywhere earlier in the document is = the >>> "Slice Header," and that seems unlikely to be what you're referring = to. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74.1: >>>=20 >>>> state_transition_delta[ i ] | sr >>> ... >>>> QuantizationTableSet( i ) | >>>=20 >>> This psuedo-code appears to use both "[]" and "()" as array = operators. I >>> understand this is only pseudocode, but please try to remain = consistent with >>> the meaning of operators. >>>=20 >>> Also, "QuantiztionTableSet" is missing a type designation. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74.1.16: >>>=20 >>>> +-------+--------------------------------------------+ >>>> | value | error detection/correction type | >>>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+ >>>> | 0 | 32-bit CRC on the global header | >>>> +-------+--------------------------------------------+ >>>> | 1 | 32-bit CRC per slice and the global header | >>>> +-------+--------------------------------------------+ >>>> | Other | reserved for future use | >>>> +-------+--------------------------------------------+ >>>=20 >>> I'm still perplexed by the intended meaning of "header.=E2=80=9D >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74.1.17: >>>=20 >>>> +-------+-------------------------------------+ >>>> | value | relationship | >>>> +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + >>>> | 0 | Frames are independent or dependent | >>>> | | (keyframes and non keyframes) | >>>> +-------+-------------------------------------+ >>>> | 1 | Frames are independent (keyframes | >>>> | | only) | >>>> +-------+-------------------------------------+ >>>> | Other | reserved for future use | >>>> +-------+-------------------------------------+ >>>>=20 >>>> Table 14 >>>=20 >>> 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. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74.6: >>>=20 >>>> pseudo-code | = type >>>> = --------------------------------------------------------------|----- >>>> SliceContent( ) { | >>>> if (colorspace_type =3D=3D 0) { | >>>> for (p =3D 0; p < primary_color_count; p++) { | >>>> for (y =3D 0; y < plane_pixel_height[ p ]; y++) { | >>>> Line( p, y ) | >>>> } | >>>> } | >>>> } else if (colorspace_type =3D=3D 1) { | >>>> for (y =3D 0; y < slice_pixel_height; y++) { | >>>> for (p =3D 0; p < primary_color_count; p++) { | >>>> Line( p, y ) | >>>> } | >>>> } | >>>> } | >>>> } | >>>=20 >>> Without a "type" indicated on the "Line( p, y )" lines, this = encoding appears >>> to be ambiguous. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A74.7: >>>=20 >>>> pseudo-code | = type >>>> = --------------------------------------------------------------|----- >>>> Line( p, y ) { | >>>> if (colorspace_type =3D=3D 0) { | >>>> for (x =3D 0; x < plane_pixel_width[ p ]; x++) { | >>>> sample_difference[ p ][ y ][ x ] | >>>> } | >>>> } else if (colorspace_type =3D=3D 1) { | >>>> for (x =3D 0; x < slice_pixel_width; x++) { | >>>> sample_difference[ p ][ y ][ x ] | >>>> } | >>>> } | >>>> } | >>>=20 >>> Although redundant with the request above regarding section 4.6, = please >>> add "type" indicators for the "sample_difference[ p ][ y ][ x ]" = lines. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A76: >>>=20 >>> While it does provide compression (my understanding is that a = typical >>> ratio is about 2:1), FFV1 still produces a very large bitstream, due = to >>> its lossless properties. This does present some security challenges = that >>> need to be cited. >>>=20 >>> I would expect this document to include text that is roughly = equivalent to the >>> final three paragraphs of RFC 4175, Section 8. >>=20 >> To do >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A77: >>>=20 >>>> This registration is done using the template defined in [RFC6838] = and >>>> following [RFC4855]. >>>=20 >>> To avoid the need to dereference the cited RFC, please also include = the IANA >>> table name ("Media Types") in this paragraph. >>=20 >> To do Reworded to "This section completes the media type registration template = defined in [@!RFC6838] and following [@!RFC4855]=E2=80=9D in = https://github.com/FFmpeg/FFV1/pull/193 = . >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A77: >>>=20 >>>> This >>>> media type is framed binary data Section 4.8 of [RFC6838]. >>>=20 >>> I think this means to say something like: >>>=20 >>> This media type is framed binary data; see Section 4.8 of = [RFC6838]. >>=20 >> To do Addressed in https://github.com/FFmpeg/FFV1/pull/193 = . >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A77: >>>=20 >>>> Published specification: >>>>=20 >>>> [I-D.ietf-cellar-ffv1] and RFC XXXX. >>>=20 >>> I can't figure out why two documents are mentioned here -- it would = seem that >>> both of these refer to the same document. >>=20 >> To do Addressed in https://github.com/FFmpeg/FFV1/pull/193 = . >>> = --------------------------------------------------------------------------= - >>>=20 >>>> 9. Appendixes >>>>=20 >>>> 9.1. Decoder implementation suggestions >>>>=20 >>>> 9.1.1. Multi-threading Support and Independence of Slices >>>=20 >>> This seems like an unnecessarily deep nesting for its contents. = Consider >>> collapsing into a single section instead of three nested sections. >>=20 >> To do I reduced the 3 levels into "Appendix A: Multi-theaded decoder = implementation suggestions=E2=80=9D in = https://github.com/FFmpeg/FFV1/pull/193 = . >>> = --------------------------------------------------------------------------= - >>>=20 >>> Section 10 should contain instructions to the RFC editor to remove = it prior to >>> publication. >>=20 >> To do Addressed in https://github.com/FFmpeg/FFV1/pull/193 = . [=E2=80=A6] Best Regards, Dave Rice --Apple-Mail=_8E485551-3CF7-48A0-9839-B79D420EC761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 A = few updates in regards to https://github.com/FFmpeg/FFV1/pull/193

On Mar 31, 2020, at 10:07 AM, Dave Rice <dave@dericed.com> = wrote:

Hi all,
I=E2=80=99m providing an update to my status update on this = review, the prior one is at https://mailarchive.ietf.org/arch/msg/cellar/UPdYs9A1FivzQJWiiW= 3uHLPSYwE/. To simply the reading of this email, I=E2=80=99m simply = going to remove what (IMHO) has already been addressed by https://github.com/FFmpeg/FFV1/pull/185.

On Jan 9, 2020, at 11:02 AM, Dave Rice <dave@dericed.com> = wrote:

[=E2=80=A6]

On Jan 2, 2020, at 6:26 PM, Adam Roach <adam@nostrum.com> = wrote:

This is my AD review for = draft-ietf-cellar-ffv1, which I am processing
at Alexey = Melinikov's request. Thanks to everyone who has taken the time
to document these formats for publication as an RFC.

I have identified a couple of issues that will = need to be addressed prior to
IETF last call (which are = clearly identified below), as well as a number of
smaller = issues that can be addressed as normal IETF last call comments.

---------------------------------------------------------------= ------------

=C2=A72.2.2:

Note: the operators and = the order of precedence are the same as used
in the C = programming language [ISO.9899.1990].
...
"a ^ b" means a raised = to the b-th power.

One of = these two statements is incorrect: the "^" operator in C is a bitwise
XOR, not a power operator. C has no built-in exponentiation = operator, and
relies on a library-provided `pow(a,b)` = function.

Because this introduces an = ambiguity into the specification, it will need
to be = corrected before entering IETF last call.

This impacts a lot of the math. Is there consensus to replace = `a^b` with `pow(a,b)` or should `a^b` be defined locally as an = exception?

Michael Niedermayer resolved this = in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A72.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=E2=80=99m uncertain, = nudging the other authors.

Michael Niedermayer = resolved this in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A72.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=E2=80=99m = uncertain, nudging the other authors.

Michael Niedermayer resolved this = in https://github.com/FFmpeg/FFV1/pull/187.

---------------------------------------------------------------= ------------

=C2=A73.4:

context =3D Q_{0}[l - tl] +
=           Q_{1}[tl - = t] +
=           Q_{2}[t - = tr] +
=           Q_{3}[L - l] =  +
=           Q_{4}[T - = t]

This is the first time in = the document we're encountering Q. Please add a
forward = reference to its definition.

To = do, as the language of the Quantization Table Sets section never says = that the table is referred to as Q.

---------------------------------------------------------------= ------------

=C2=A73.8.1.1:

S_{i+1,C_{i}} =3D =  zero_state_{S_{i,C_{i}}} XOR
=           l_i =3D =  L_i =             &n= bsp;        XOR
=           t_i =3D =  R_i - r_i =             &n= bsp;  <=3D=3D
=           b_i =3D =  0 =             &n= bsp;          <=3D=3D= >
=           L_i < =  R_i - r_i

Substantial = parts of this syntax are undefined at this point in the document.

Presumably "XOR" means "exclusive or," = although it is unclear whether this is
intended to be a = boolean or bitwise operation.

The "<=3D=3D= " and "<=3D=3D>" notation is also without explanation, and I can't = even make
an educated guess at their intended meaning.

There is no explanation what it might mean to = combine a series of assignment
operations (and one = comparison operation) with these XOR, <=3D=3D, and <=3D=3D> = symbols.

This needs to be clarified (for = all of figures 7 through 9) before the
document can go to = IETF last call.

To do

Michael Niedermayer resolved this = in https://github.com/FFmpeg/FFV1/pull/187 and https://github.com/FFmpeg/FFV1/pull/188/files.

---------------------------------------------------------------= ------------

=C2=A73.8.1.1.1:

Above = describes the range decoding, encoding is defined as any
= process which produces a decodable bytestream.

Would it be reasonable to include = a non-normative example of one such
process?

To do

---------------------------------------------------------------= ------------

=C2=A73.8.1.2:
exact contexts used are = best described by the
following code, followed by some = comments.

I can't find the = referenced comments.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.1.2:
pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
void put_symbol(RangeCoder *c, uint8_t *state, int = v, int \   |
is_signed) { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">     int i; =             &n= bsp;           &nbs= p;            =             &n= bsp; |
    put_rac(c, state+0, = !v); =             &n= bsp;           &nbs= p;        |
=     if (v) { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">         int a=3D = abs(v); =             &n= bsp;           &nbs= p;            =   |
=         int e=3D log2(a); =             &n= bsp;           &nbs= p;            =  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
        for = (i =3D 0; i < e; i++) { =             &n= bsp;           &nbs= p;   |
=             pu= t_rac(c, state+1+min(i,9), 1); //1..10 =         |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
=         put_rac(c, = state+1+min(i,9), 0); =             &n= bsp;        |
=         for (i =3D e-1; i >=3D = 0; i--) { =             &n= bsp;           &nbs= p;|
=             pu= t_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
        if = (is_signed) { =             &n= bsp;           &nbs= p;            = |
=             pu= t_rac(c, state+11 + min(e, 10), v < 0); //11..21|
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

The "type" column here appears = superfluous, and should either employed or
removed.

To do

The behavior of the = function "put_rac" isn't defined anywhere. While the purpose
of its first two parameters can be deduced from context, the = purpose of the
third parameter is baffling. For avoidance = of doubt, please add a description of
what this function = does, and what its parameters mean.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.1:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
int get_ur_golomb(k) { =             &n= bsp;           &nbs= p;            =   |
    for (prefix =3D 0; = prefix < 12; prefix++) { =             &n= bsp;   |
=         if (get_bits(1)) { =             &n= bsp;           &nbs= p;          |
=             re= turn get_bits(k) + (prefix << k) =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
=     return get_bits(bits) + 11 =             &n= bsp;           &nbs= p;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
int get_sr_golomb(k) { =             &n= bsp;           &nbs= p;            =   |
    v =3D = get_ur_golomb(k); =             &n= bsp;           &nbs= p;           |
    if (v & 1) return - (v >> = 1) - 1; =             &n= bsp;           |     else =       return   (v >> 1); =             &n= bsp;           &nbs= p;   |
}

The "type" column here appears superfluous, and should either = employed or
removed.

To do.

Please clarify the meaning of "ur" and "sr" in the function = names.

To do, define function = names with references to ur / sr definitions.

---------------------------------------------------------------= ------------

=C2=A73.8.2.1.1:

=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | bits =           | value |
=             &n= bsp;        +=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+
=             &n= bsp;        | 1 =             &n= bsp;| 0     |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 01 =             | = 1     |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | ... =            | ... =   |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 0000 0000 0001 | = 11    |
=             &n= bsp;        +----------------+----= ---+
=             &n= bsp;        | 0000 0000 0000 | = ESC   |
=             &n= bsp;        +----------------+----= ---+

This is pretty confusing, = not least of all because the base of the number on the
right= is unclear (given that all the shown values contain 1's and 0's
exclusively). I would suggest:

=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | bits =           | value |
=             &n= bsp;          +=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D+
=             &n= bsp;          | 1 =             &n= bsp;| 0     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 01 =             | = 1     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | ... =            | ... =   |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 00 = 0000 0001   | 9     |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 000 = 0000 0001  | 10    |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 0000 = 0000 0001 | 11    |
=             &n= bsp;          +---------= -------+-------+
=             &n= bsp;          | 0000 = 0000 0000 | ESC   |
=             &n= bsp;          +---------= -------+=E2=80=94=E2=80=94=E2=80=94+

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.2.1:

pseudo-code= =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
log2_run[41]=3D{ =             &n= bsp;           &nbs= p;            =           |
 0, 0, 0, 0, 1, 1, 1, 1, =             &n= bsp;           &nbs= p;            = |
 2, 2, 2, 2, 3, 3, 3, 3, =             &n= bsp;           &nbs= p;            = |
 4, 4, 5, 5, 6, 6, 7, 7, =             &n= bsp;           &nbs= p;            = |
 8, 9,10,11,12,13,14,15, =             &n= bsp;           &nbs= p;            = |
16,17,18,19,20,21,22,23, =             &n= bsp;           &nbs= p;            = |
24, =             &n= bsp;           &nbs= p;            =             &n= bsp;        |
}; =             &n= bsp;           &nbs= p;            =             &n= bsp;         |
= =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;|
if (run_count =3D=3D 0 && run_mode =3D=3D 1) = { =             &n= bsp;          |
    if (get_bits(1)) { =             &n= bsp;           &nbs= p;            =   |
=         run_count =3D 1 << = log2_run[run_index]; =             &n= bsp;   |
=         if (x + run_count <=3D = w) { =             &n= bsp;           &nbs= p;   |
run_index++; =             &n= bsp;           &nbs= p;            = |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else { =             &n= bsp;           &nbs= p;            =             |<= br class=3D"">         if = (log2_run[run_index]) { =             &n= bsp;           &nbs= p;  |
=             ru= n_count =3D get_bits(log2_run[run_index]); =        |
=         } else { =             &n= bsp;           &nbs= p;            =         |
=             ru= n_count =3D 0; =             &n= bsp;           &nbs= p;          |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=         if (run_index) { =             &n= bsp;           &nbs= p;            = |
run_index--; =             &n= bsp;           &nbs= p;            = |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
=         run_mode =3D 2; =             &n= bsp;           &nbs= p;            =    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |


The "type" column = here appears superfluous, and should either employed or
removed.


The log2_run function = is also used within [ISO.14495-1.1999].

The reference to "log2_run" as a "function" is perplexing, as = log2_run is defined
as an array in the above = pseudocode.

To do

---------------------------------------------------------------= ------------

=C2=A73.8.2.3:
Some light documentation of the "state" structure would make = this pseudocode
much easier to follow.

To do

---------------------------------------------------------------= ------------

=C2=A74:

The same context that = is initialized to 128 is used for all fields in
the = header.

This phrasing is = confusing, as it reads like it's referring to some
previously-mentioned context that is best identified as = containing "128." After
convincing myself that I didn't = miss such a thing, I *think* you might mean:

=   All fields in the header use the same context, which is
  initialized to 128.

Although, even with that adjustment, I'm not sure which = header you're talking
about. The only header mentioned = anywhere earlier in the document is the
"Slice Header," = and that seems unlikely to be what you're referring to.

To do

---------------------------------------------------------------= ------------

=C2=A74.1:

=             st= ate_transition_delta[ i ] =             &n= bsp;         | sr
...
=         QuantizationTableSet( i = ) =             &n= bsp;           &nbs= p;   |

This = psuedo-code appears to use both "[]" and "()" as array operators. =  I
understand this is only pseudocode, but please try = to remain consistent with
the meaning of operators.

Also, "QuantiztionTableSet" is missing a type = designation.

To do

---------------------------------------------------------------= ------------

=C2=A74.1.16:

+-------+--------------------------------------------+
       | value | error = detection/correction type |
+=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+
=        | 0     | = 32-bit CRC on the global header |
+-------+--------------------------------------------+
       | 1 =     | 32-bit CRC per slice and the global header = |
+-------+--------------------------------------------+
       | Other | reserved = for future use |
+-------+--------------------------------------------+

I'm still perplexed by the = intended meaning of "header.=E2=80=9D

To do

---------------------------------------------------------------= ------------

=C2=A74.1.17:

=            +-------= +-------------------------------------+
=            | = value | relationship =             &n= bsp;          |
=            +=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
=            | 0 =     | Frames are independent or dependent |
=            | =       | (keyframes and non keyframes) =       |
=            +-------= +-------------------------------------+
=            | 1 =     | Frames are independent (keyframes =   |
=            | =       | only) =             &n= bsp;           &nbs= p;     |
=            +-------= +-------------------------------------+
=            | = Other | reserved for future use =             |<= br class=3D""> =            +-------= +-------------------------------------+

=             &n= bsp;           &nbs= p;      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.

To do

---------------------------------------------------------------= ------------

=C2=A74.6:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
SliceContent( ) { =             &n= bsp;           &nbs= p;            =        |
=     if (colorspace_type =3D=3D 0) { =             &n= bsp;           &nbs= p;     |
=         for (p =3D 0; p < = primary_color_count; p++) { =           |
=             fo= r (y =3D 0; y < plane_pixel_height[ p ]; y++) {   |
=             &n= bsp;   Line( p, y ) =             &n= bsp;           &nbs= p;        |
} =             &n= bsp;           &nbs= p;            =            |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else if = (colorspace_type =3D=3D 1) { =             &n= bsp;          |
        for (y =3D = 0; y < slice_pixel_height; y++) { =            |
=             fo= r (p =3D 0; p < primary_color_count; p++) { =       |
=             &n= bsp;   Line( p, y ) =             &n= bsp;           &nbs= p;        |
} =             &n= bsp;           &nbs= p;            =            |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

Without a "type" indicated on the = "Line( p, y )" lines, this encoding appears
to be = ambiguous.

To do

---------------------------------------------------------------= ------------

=C2=A74.7:

pseudo-code =             &n= bsp;           &nbs= p;            =             &n= bsp;| type
--------------------------------------------------------------|= -----
Line( p, y ) { =             &n= bsp;           &nbs= p;            =           |
    if (colorspace_type =3D=3D 0) { =             &n= bsp;           &nbs= p;     |
=         for (x =3D 0; x < = plane_pixel_width[ p ]; x++) { =        |
=             sa= mple_difference[ p ][ y ][ x ] =             &n= bsp;    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
    } else if = (colorspace_type =3D=3D 1) { =             &n= bsp;          |
        for (x =3D = 0; x < slice_pixel_width; x++) { =             |<= br class=3D""> =             sa= mple_difference[ p ][ y ][ x ] =             &n= bsp;    |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;  |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;      |
} =             &n= bsp;           &nbs= p;            =             &n= bsp;          |

Although redundant with the = request above regarding section 4.6, please
add "type" = indicators for the "sample_difference[ p ][ y ][ x ]" lines.

To do

---------------------------------------------------------------= ------------

=C2=A76:

While it does provide = compression (my understanding is that a typical
ratio is = about 2:1), FFV1 still produces a very large bitstream, due to
its lossless properties. This does present some security = challenges that
need to be cited.

I would expect this document to include text that is roughly = equivalent to the
final three paragraphs of RFC 4175, = Section 8.

To do

---------------------------------------------------------------= ------------

=C2=A77:

This registration is = done using the template defined in [RFC6838] and
= following [RFC4855].

To avoid = the need to dereference the cited RFC, please also include the IANA
table name ("Media Types") in this paragraph.

To do
<= div>
Reworded to "This section completes the = media type registration template defined in [@!RFC6838] and following = [@!RFC4855]=E2=80=9D in https://github.com/FFmpeg/FFV1/pull/193.

---------------------------------------------------------------= ------------

=C2=A77:

This
= media type is framed binary data Section 4.8 of [RFC6838].

I think this means to say = something like:

  This media = type is framed binary data; see Section 4.8 of [RFC6838].

To do
<= div>

---------------------------------------------------------------= ------------

=C2=A77:

Published = specification:

[I-D.ietf-cellar-ffv1] and = RFC XXXX.

I can't figure out = why two documents are mentioned here -- it would seem that
both of these refer to the same document.

To do
<= div>

---------------------------------------------------------------= ------------

9.  Appendixes

9.1. =  Decoder implementation suggestions

9.1.1.  Multi-threading Support and Independence of = Slices

This seems like an = unnecessarily deep nesting for its contents. Consider
collapsing into a single section instead of three nested = sections.

To do
<= div>
I reduced the 3 levels into "Appendix A: = Multi-theaded decoder implementation suggestions=E2=80=9D in https://github.com/FFmpeg/FFV1/pull/193.

---------------------------------------------------------------= ------------

Section 10 should contain = instructions to the RFC editor to remove it prior to
publication.

To = do
<= div>

[=E2=80=A6]

Best= Regards,
Dave Rice


= --Apple-Mail=_8E485551-3CF7-48A0-9839-B79D420EC761-- From nobody Tue Mar 31 08:31:42 2020 Return-Path: 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 46CBC3A231A for ; Tue, 31 Mar 2020 08:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no 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 SFf8LPAB5Ub9 for ; Tue, 31 Mar 2020 08:31:39 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F753A2319 for ; Tue, 31 Mar 2020 08:31:38 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:35762 helo=[10.0.1.6]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jJIrU-001zsV-9T for cellar@ietf.org; Tue, 31 Mar 2020 11:31:38 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_9B3258C9-225E-4978-84DF-C30A1A4505AC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: <5835AB11-6945-407B-8D1D-B3F3F4C66904@dericed.com> References: <157601326119.9994.2020948536628433649@ietfa.amsl.com> To: Codec Encoding for LossLess Archiving and Realtime transmission Date: Tue, 31 Mar 2020 11:31:29 -0400 X-Mailer: Apple Mail (2.3608.40.2.2.4) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] Fwd: Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-03-31 X-BeenThere: cellar@ietf.org 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: Tue, 31 Mar 2020 15:31:41 -0000 --Apple-Mail=_9B3258C9-225E-4978-84DF-C30A1A4505AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, Just a reminder about today=E2=80=99s meeting. The agenda is at = https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-03-cellar-01/ = . Best Regards, Dave > Begin forwarded message: >=20 > From: IESG Secretary > Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime = transmission (cellar) WG Virtual Meeting: 2020-03-31 > Date: December 10, 2019 at 4:27:41 PM EST > To: "IETF-Announce" > Cc: cellar@ietf.org >=20 > The Codec Encoding for LossLess Archiving and Realtime transmission = (cellar) Working Group will hold > a virtual interim meeting on 2020-03-31 from 21:00 to 22:00 = Europe/Amsterdam. >=20 > Agenda: > to be uploaded >=20 > Information about remote participation: > https://whereby.com/cellar-interim >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_9B3258C9-225E-4978-84DF-C30A1A4505AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = cellar,
Just a reminder about today=E2=80=99s meeting. = The agenda is at https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-03-= cellar-01/.
Best Regards,
Dave

Begin forwarded = message:

From: = IESG Secretary <iesg-secretary@ietf.org>
Subject: = [Cellar] Codec = Encoding for LossLess Archiving and Realtime transmission (cellar) WG = Virtual Meeting: 2020-03-31
Date: = December 10, 2019 at 4:27:41 PM = EST
To: = "IETF-Announce" <ietf-announce@ietf.org>
Cc: cellar@ietf.org

The Codec Encoding for = LossLess Archiving and Realtime transmission (cellar) Working Group will = hold
a virtual interim meeting on 2020-03-31 from 21:00 to = 22:00 Europe/Amsterdam.

Agenda:
to be uploaded

Information about = remote participation:
https://whereby.com/cellar-interim

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_9B3258C9-225E-4978-84DF-C30A1A4505AC-- From nobody Tue Mar 31 11:43:09 2020 Return-Path: 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 512EF3A26D8 for ; Tue, 31 Mar 2020 11:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: SERVFAIL)" header.d=reto.ch 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 Pw5Q6NhY_2HW for ; Tue, 31 Mar 2020 11:42:58 -0700 (PDT) Received: from smtp-42ac.mail.infomaniak.ch (smtp-42ac.mail.infomaniak.ch [84.16.66.172]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCC63A26C4 for ; Tue, 31 Mar 2020 11:42:58 -0700 (PDT) Received: from smtp-3-0000.mail.infomaniak.ch (unknown [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 48sJ9X3gWRzlhKSK for ; Tue, 31 Mar 2020 20:42:56 +0200 (CEST) Received: from Castor (unknown [IPV6:2a02:aa13:4680:f280:10b2:f988:978c:adc2]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 48sJ9X0jw3zlvywS for ; Tue, 31 Mar 2020 20:42:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=reto.ch; s=20191114; t=1585680176; bh=HZu+QDeflR5/XdpSj1r467LmfKjvEwciOaLCRyx5QPs=; h=Date:From:Subject:To:In-Reply-To:From; b=vXMiLnFnG7NtBIoEDuoEPK3p8odWR6nlbqRNytg59yaKTT25iD71qcIHe6ixbcnBQ Ud5LercihOkRWt5KTfm4RBuwgIEoPvepC0MNbHS1Njyxy3LVHBoBc55N3yEwGhBv/j KJhxzXfUwmTI7jmiF5xzKMi+pTaBYaNLw1/eyDZQ= Date: Tue, 31 Mar 2020 20:42:56 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: <5835AB11-6945-407B-8D1D-B3F3F4C66904@dericed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Fwd: Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-03-31 X-BeenThere: cellar@ietf.org 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: Tue, 31 Mar 2020 18:43:08 -0000 Dave Rice wrote: >Just a reminder about today=E2=80=99s meeting. Sorry, I am not sure I can make it. Best regards, Reto From nobody Tue Mar 31 12:04:46 2020 Return-Path: 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 2C98E3A2701 for ; Tue, 31 Mar 2020 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 a033yoJRPUC3 for ; Tue, 31 Mar 2020 12:04:36 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF673A2A28 for ; Tue, 31 Mar 2020 12:03:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 151783897B for ; Tue, 31 Mar 2020 15:01:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8EECDF3A for ; Tue, 31 Mar 2020 15:03:16 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] 2020-03-31: virtual interim meeting starting now X-BeenThere: cellar@ietf.org 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: Tue, 31 Mar 2020 19:04:44 -0000 --=-=-= Content-Type: text/plain Etherpad: https://etherpad.ietf.org:9009/p/notes-cellar-virtual?useMonospaceFont=true Link to conference: https://whereby.com/cellar-interim --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6Dk/QACgkQgItw+93Q 3WVwnwf/R7r91WBdLm4IIbB5vb/J1VL769ilaW3C18UtwemFIjdciyrguJwJKNe5 7jp16PftRnIr3uxyfsjuVSyfAm1+AfLmfwDu/eqI6DJejntnYKz3rMSMyPUXnD63 eodTujvuj8HDruP+aMS1IWiaa5rBuDh+B+d30fqiqsM+mSWtuzA6ecJMSuc4thO5 Sp+JVHsjhE1RnKn+MUBTT5B93WbeUe59Nyj9yEqxTuC54GcJ9bL2tycK0YO6JJwK 4+FOL654vXeAzZM2vNs6J3pDAlumftagedJ2txVcGatdLMCAyVhh+lbs/JjCQCfs MUQfEMP8wFhiIycGzGdZUPkVKKjGNg== =a/Ez -----END PGP SIGNATURE----- --=-=-=--