From nobody Mon Jan 4 08:59:23 2021 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 755103A0E82; Mon, 4 Jan 2021 08:59:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cellar-chairs@ietf.org, cellar@ietf.org, mcr+ietf@sandelman.ca, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160977956139.6273.9798929327288966282@ietfa.amsl.com> Date: Mon, 04 Jan 2021 08:59:21 -0800 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 110 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 04 Jan 2021 16:59:22 -0000 Michael Richardson, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 110. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Jan 19 15:42:55 2021 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 A3DA33A03EE for ; Tue, 19 Jan 2021 15:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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] 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 8_IKO_mxMfXQ for ; Tue, 19 Jan 2021 15:42:52 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 6BF1A3A03C9 for ; Tue, 19 Jan 2021 15:42:52 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id k4so17725246ybp.6 for ; Tue, 19 Jan 2021 15:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OSc9OmZ/Y+lHZuLhw0+NwolmXuvKMAnB4Za7KWV/I+g=; b=hAXJquTYsyvpa/iUNQWvjj3DvjQFwGKj5Ak2R5jA/cBY4YU06tEnYRJzPCCeWEJ7GI Rb1UhW2iBrY59gWKOB3MSiLpIpIWawjIG6gb0rYkH5nSh9KZkPCzD/GrYAkpcCVvFWaa IYGM8q4Rw5NsacxB44emKcjMOaXbxwJ2DT9F0s2KFxEnN/xNB3bXBRwg85KoQrC0hX6L c+wmbK+ne/6/fkAYuWa7b1G5fJY7Ji1+i8mlTFgkW0KftvJVVfCDPFQ2/M14Ca2cYTZQ afkEUKQ7Mjisj1aVQ6wUsHmcHRVFJy1nTe1UvmddhGhfdmY7yF6VpzrNE65YPV6vL0PS VlSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OSc9OmZ/Y+lHZuLhw0+NwolmXuvKMAnB4Za7KWV/I+g=; b=fVn95apdmLgJCCjB/0R9puNb80cxjXZzpWfwu5HN7CRluDfnraOu16yiLnA3NqT6k/ TkPX9b31AiUcSuImrV4tJfdF5/b5KPBYA40whW+6nUj8RnKJ5u3N/vvGsJ+PxDkqdqiZ XzTH3zkr0S4YFhN5H+/I9wDQx9e6i59f1+WuCXOatiLLEjDdB/z/Z1/4rOCZ3VaZ9eJK JKPejpsMWN/K2Te2l9yd0fpbg6nBStN3aE3TPd0Xxwt3pJE/QCySu80apt6nccDyrsou D522SeAMl4e6zB11XRiUnnhXZp5kVC8WAB8mm2Saxfp1NObDzaIHVdPjETtcHXYdurW4 iIEg== X-Gm-Message-State: AOAM532EAqR2Plp/wrq6jA4Sa2Rrj54MN+jE47A3suhm97B5TmWbf/Il 7x5K8gU0JbafsbjuuvVYx/wryLCO1+S61Lc3ELOFO2oT X-Google-Smtp-Source: ABdhPJyOJVXPs/t9GB79FXIxI638nS16Fs8BUJMLCYkUBANY2OE8yLxqVI2kTdS5oZlIvCDfEabFz1qcdCQEkt3JTiQ= X-Received: by 2002:a25:4e07:: with SMTP id c7mr9254914ybb.288.1611099771461; Tue, 19 Jan 2021 15:42:51 -0800 (PST) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 19 Jan 2021 17:42:25 -0600 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000093633a05b94965dc" Archived-At: Subject: [Cellar] Any special requests for agenda items in our January virtual interim meeting on January 26? 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, 19 Jan 2021 23:42:54 -0000 --00000000000093633a05b94965dc Content-Type: text/plain; charset="UTF-8" We've been mostly doing an agenda of "walking through Github issues and PRs" in recent meetings. Are there any other agenda items that Michael and I should add? Best, Spencer --00000000000093633a05b94965dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We've been mostly doing an agenda of "walking thr= ough Github issues=C2=A0and PRs" in recent meetings.=C2=A0

Are there any other agenda items that Michael and I should add?

Best,

Spencer
--00000000000093633a05b94965dc-- From nobody Sun Jan 24 00:51:15 2021 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 A37D43A1129 for ; Sun, 24 Jan 2021 00:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=F2+1t9AN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mp6JqQ3n 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 eywmNsqaW61V for ; Sun, 24 Jan 2021 00:51:11 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20D33A1127 for ; Sun, 24 Jan 2021 00:51:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C86E05C009A for ; Sun, 24 Jan 2021 03:14:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 24 Jan 2021 03:14:12 -0500 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= fm1; bh=e+QgW42CqdPqq8DI6rL6c6cdTl5k9Z+PpaWhOA/2/zs=; b=F2+1t9AN U/EWlFimqtWjvK5jLENVKia7hNiEow6GY8UU62y8ESmMcL240V9Ybxcv5xeQW0Xe 6/V1UKJM1qQC5tZI3YYRxhqt9/0Xmm3EUfUPfy1Dcc1QKrwbBbY1ywPeDqgFpW9u GoXgJPfCSaWuudXS9eS7rFb30VLGu6pcxcFlKUdHjJEEN9E17gibacPO5RVbGL3m mpLL+WjvbwmVt5j728qQwwPAOUkOBLA02mysYDS8h2TWYGn7uCYIH9ldhxqB/Ryh lzdzPLweXRKbshJoXsDTPO+ohPAZmVX0lEQsYpEDiPBBeXAXCn+44b6lNbUhiWm9 4YQ5/Le/+qKB4A== 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=fm1; bh=e+QgW42CqdPqq8DI6rL6c6cdTl5k9 Z+PpaWhOA/2/zs=; b=mp6JqQ3nvl6BHnxzzEt+i8l+ODZugY9wwoJ88UwLAa+EZ ZbodzwYMcs7ihP5ARODkwJLbKRCZjcJDXII8Ba0NaMndC7bPlaoqx9Wrxwxab5z3 okz/oglwBT+GvWLANgRJ8+GnPMtBZGcUqpSf/BPsVK5+4PQMfRvzS2kZuja/1PtO bIZd5qbrujWWGoGYRxXs07F1tAcpn38KwGps3t5gZp9C4ZcSJTm5leFi67lj1lQl AukYbLUNsL7bnb62SLN/4SXT/Cj8QTaVZxx74tYNiEsiOHoVO+0ymemLcWtwlga8 5JlVmnZDUiSPSm9F3jKUaYULPSFgXg9Jit74K/jyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvddvhedrvddvvddrge eknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az60-880.internal.cloudapp.net (unknown [52.225.222.48]) by mail.messagingengine.com (Postfix) with ESMTPA id A432524005B for ; Sun, 24 Jan 2021 03:14:12 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8295079110185766231==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210124081412.A432524005B@mailuser.nyi.internal> Date: Sun, 24 Jan 2021 03:14:12 -0500 (EST) 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, 24 Jan 2021 08:51:13 -0000 --===============8295079110185766231== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Errors while compiling the digest: - Repo ietf-cellar-wg/chair-notes/events yields 404 error Events without label "editorial" Pull requests ------------- * FFmpeg/FFV1 (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Correct typos in FFV1 definition (by gnafuthegreat) https://github.com/FFmpeg/FFV1/pull/257=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-cellar-wg/ebml-specification * https://github.com/ietf-cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-cellar-wg/Cellar-FLAC * https://github.com/ietf-cellar-wg/chair-notes --===============8295079110185766231== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday January 24, 2021

Errors while compiling the digest:
  • Repo ietf-cellar-wg/chair-notes/events yields 404 error

Events without label "editorial"

Pull requests

FFmpeg/FFV1 (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============8295079110185766231==-- From nobody Mon Jan 25 10:14:21 2021 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 7F8AA3A1826 for ; Mon, 25 Jan 2021 10:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 EIBXH5blZZQW for ; Mon, 25 Jan 2021 10:14:12 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 A73DC3A16F4 for ; Mon, 25 Jan 2021 10:14:10 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id z1so14205866ybr.4 for ; Mon, 25 Jan 2021 10:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eqOxtcIuE6o0UHN9jzdSv/s2C4lYW3ygcgejlMftF1E=; b=G4+l8Fk/Pfw/V1uVcI904TLLi3xYM+mFZfsQpkmyvVqL+/uxz+UmmsvzvzGBT6rk4W ncEoeIfNT935UaP9pjsZRWPUOst/V7AWyoCwLcU+VqaY5tKrWDUEXvo88Iznql85uv1/ z9+rHW3QGAMSjpG67dX6u+/lIa7tBmH8BJFZw98aTN0zHwKiBrEkwJCxuFL9u6wPfFjy oPfvlXjqE2tRgpEaffvHESxt800BimPZ9UNT+oeVfPgoZVd/k/3TSXF2PAqLQm1YZjXM gpvX64kFHZW7ts+3h/Wpv3GtC8W3aydAaL2SNFu5a9Ha6cxfV9Jn4SxeDIi5z+l8HaM2 a3kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eqOxtcIuE6o0UHN9jzdSv/s2C4lYW3ygcgejlMftF1E=; b=biIpv+9UM0QQa9Rgvy1D9ZFR2ipkqLXIR6n6Xt5cPgyv/Do3trAEy+yHVUBR/nhm1Q dW0xYMLO/DRnkdUBxyMtLAYXQBBhYtJKctXxDvmZIPHF2XdVbgnVqSO829kCsSRYdUmq 7NSRPS0KS7PodKjcvZv6uak02mMkXLuQNrot/b6BIgRPI52gG3CwOHJSQKGyPwNLI8gl fHlzQiE7yK+CviNIwevv3reeTfqo8o7TtAG8OAv2vkf1vRSXURSkWRuWhoV2qaPdktxG S9jv2elxKRzVs17REWHK8PC6vSMFOULau54ZlgoUYurikRKlWEnKu92B2I4e4R+olqIr h7Ow== X-Gm-Message-State: AOAM531Ak0dlWrucs2CxHzg5lxUCjrh4byquy+gXP0flPYJEVdH2NXa4 lHjEDKmy9P5Nypr556Llm/8Q04o/j5Pcid8d5YNSW6HuojA= X-Google-Smtp-Source: ABdhPJzo38NWdYV9xvOCMi9BSohVmDfpo46fs1v3JJjjjhkVwSsKumV3eDW2U1oYEVZGMNHbvurDmkoXuK0bcT5Yh3I= X-Received: by 2002:a25:1fc5:: with SMTP id f188mr2568199ybf.389.1611598449566; Mon, 25 Jan 2021 10:14:09 -0800 (PST) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Mon, 25 Jan 2021 12:13:43 -0600 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000001b691805b9bd8128" Archived-At: Subject: [Cellar] Agenda for our January 26 virtual interim meeting 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, 25 Jan 2021 18:14:19 -0000 --0000000000001b691805b9bd8128 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All, I've uploaded our agenda for tomorrow's meeting, It's available at https://github.com/ietf-wg-cellar/chair-notes/blob/master/interim-2021-01/a= genda.md. Please let us know if you have any questions or additions. Best, Spencer The current text is CELLAR -- DRAFT AGENDA for Virtual Interim Meeting January 26, 2021 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (Time is anchored to Amsterdam) INFO: https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-09-cellar-01= / WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes Attendees * Spencer Dawkins 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from October 27 meeting (attached below) 3. Logistics for Meeting. 3a) Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual * Note that if you log in to the IETF datatracker, you'll be able to edit these notes, add your name to attendee lists, etc. * Please ask Spencer if you have questions. 3b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 3c) Roll call 4. WG status update * draft-ietf-cellar-ffv1-19 was posted 2020-12-01, in AD Followup, but there's still an open discuss position * draft-ietf-cellar-codec-05 was posted 2020-10-19 * draft-ietf-cellar-matroska-06 was posted 2020-10-19 * draft-ietf-cellar-tags-05 was posted 2020-10-19 * has a FLAC specification been posted to the datatracker yet? * We agreed at the December meeting that we would have a focused conversation about FFV1 v4 in our Feberuary meeting, and noted then that the April 2021 date is not realistic. 5. 2021 virtual interim meeting dates * Please note that the proposed 2021 dates discussed at our previous meeting are now official, approved by our AD, and listed at https://datatracker.ietf.org/wg/cellar/meetings/ * Sometime around 2021-09-28, we=E2=80=99ll see if we want to meet at IE= TF 112 on November 6-12, 2021, in person in Madrid. 6. remaining FFV1 issues from DISCUSS * IESG ballot positions at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ballot/ * Have we closed on Barry's concerns about section 3.8.1.x? * Any remaining comments from any ADs that still need to be addressed? * If all of the above, what needs to happy to submit an updated draft? 7. From the mailing list: "What is the canonical procedure to create an "infinite" audio stream, using Opus and FLAC codecs?" I have been attempting to locate a site which streams Opus continuously to test. I also am interested in the exact opusenc, et al. commands necessary to achieve creation of live audio streams. The use cases are implementation of user-defined Web radio station, the capability to play the "infinite" stream using HTMLAudioElement (WHATWG/HTML) over HTTP. ("infinite" is quoted here as there is no way to verify infinity; the gist is playback should not stop; is not seekable). * 8. Matroska issues * 9. FLAC issues * AOB? NEXT MEETING February 23, 2021. Notes from previous meeting for approval CELLAR =E2=80=93 DRAFT AGENDA for Virtual Interim Meeting December 1, 2020 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (Time is anchored to Amsterdam) INFO: https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-09-cellar-01/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes Attendees Spencer Dawkins J=C3=A9r=C3=B4me Martinez Michael Richardson Steve Lhomme Michael Niedermayer Rohit Abhishek Regrets: Dave Rice Note Well. https://www.ietf.org/about/note-well/ Accept draft minutes from October 27 meeting (attached below) Logistics for Meeting. 3a) Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual * Note that if you log in to the IETF datatracker, you=E2=80=99ll be able to edit these notes, add your name to attendee lists, etc. * Please ask Spencer if you have questions. 3b) APPEAR.IN is now called =E2=80=9Cwhereby.com=E2=80=9D https://whereby.com/cellar-interim 3c) Roll call WG status update FFV1 =E2=80=93 version 18 was posted 2020-10-07, waiting for revision new document on github today -> new document to be uploaded to DT. some feedback sent to those with DISCUSS (Roman and Barry) ballots. 2021 Proposed virtual interim meeting dates Fourth Tuesdays in 2021 are January 26 February 23 March 23 April 27 May 25 June 22 July 28 clashes with IETF 111 so we won't meet on this date August 24 September 28 October 26 November 23. IETF 112: November 6-12, 2021: MAYBE in person meeting? * December 28 winter holidays so we won't meet on this date What do we need to change? Let=E2=80=99s book this pattern, and then, around 2021-09-28, we=E2=80=99ll= see if we want to meet in person in Madrid. NoTimeToWait (March 2021, cancelled), but maybe December 2021. [December 6 is Matroska=E2=80=99s birthday!!!] remaining FFV1 issues from DISCUSS no remaining issues! https://github.com/FFmpeg/FFV1/releases/tag/draft-ietf-cellar-ffv1-19_v4-16 Matroska issues much discussion about accurate time stamps, progress in a number of pull requests. FLAC issues no focus on this yet. AOB? A lot of debate about what we want to do for FFV1 v4. We will need a focused conversation about this. {have this conversation in Feb. meeting}: April 2021 date is not realistic. The RFC on FFV1 versions v1 to v3 coming out will be a big motivation for the industry. Next meeting is: January 26. --0000000000001b691805b9bd8128 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,=C2=A0

I've uploaded our a= genda for tomorrow's meeting, It's available at=C2=A0https://github.com/ietf-wg-cellar/chair-notes/blob/master/interim-20= 21-01/agenda.md. Please let us know if you have any questions or additi= ons.=C2=A0

Best,

Spencer<= /div>

The current text is=C2=A0

CELLAR -- DRAFT AGENDA for Virtual Interim Meeting
January 26, 2021 =C2= =A0 =C2=A0 =C2=A0 21:00 Amsterdam =C2=A0***
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A020:00 UTC
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A016:00 NYC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A013:00 San Francisco
(Time is anchored to Amsterd= am)

INFO:
=C2=A0 =C2=A0https://datatracker.ietf.org/do= c/agenda-interim-2020-cellar-09-cellar-01/

WEB CONFERENCE:
=C2=A0 =C2=A0https://where= by.com/cellar-interim

=C2=A0 =C2=A0THERE IS NO TELEPHONE DIALIN = (You can try this at any time.)

=C2=A0 =C2=A0These notes at: https://github.com/cellar-wg/= chair-notes
=C2=A0 =C2=A0
=C2=A0 =C2=A0Attendees
=C2=A0 =C2=A0= * Spencer Dawkins

1. Note Well. =C2=A0https://www.ietf.org/about/note-well/
2. Accept= draft minutes from October 27 meeting (attached below)

3. Logistics= for Meeting.
=C2=A0 =C2=A03a) Shared COMIMD for notetaking:
=C2=A0 = =C2=A0 =C2=A0 =C2=A0https://codimd.ietf.org/notes-cellar-virtual
=C2=A0 =C2=A0 =C2=A0 = =C2=A0* Note that if you log in to the IETF datatracker, you'll
=C2= =A0 =C2=A0 =C2=A0 =C2=A0be able to edit these notes, add your name to atten= dee
=C2=A0 =C2=A0 =C2=A0 =C2=A0lists, etc. *
=C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0Please ask Spencer if you have questio= ns.

=C2=A0 =C2=A03b) APPEAR.IN is n= ow called "whereby.com"
=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://whereby.com/cellar-interim

=C2=A0 =C2=A03c) Roll call
4. WG status update

=C2=A0 =C2=A0* draft-ietf-cellar-ffv1-19 wa= s posted 2020-12-01, in AD Followup, but there's still an open discuss = position
=C2=A0 =C2=A0* draft-ietf-cellar-codec-05 was posted 2020-10-19=
=C2=A0 =C2=A0* draft-ietf-cellar-matroska-06 was posted 2020-10-19
= =C2=A0 =C2=A0* draft-ietf-cellar-tags-05 was posted 2020-10-19
=C2=A0 = =C2=A0* has a FLAC specification been posted to the datatracker yet?
= =C2=A0 =C2=A0* We agreed at the December meeting that we would have a focus= ed conversation about FFV1 v4 in our Feberuary meeting, and noted then that= the April 2021 date is not realistic.

5. 2021 virtual interim meeti= ng dates

=C2=A0 =C2=A0* Please note that the proposed 2021 dates dis= cussed at our previous meeting are now official, approved by our AD, and li= sted at https:= //datatracker.ietf.org/wg/cellar/meetings/
=C2=A0 =C2=A0* Sometime a= round 2021-09-28, we=E2=80=99ll see if we want to meet at IETF 112 on Novem= ber 6-12, 2021, in person in Madrid.

6. remaining FFV1 issues from D= ISCUSS
=C2=A0 =C2=A0* IESG ballot positions at https://datatracker.ietf= .org/doc/draft-ietf-cellar-ffv1/ballot/
=C2=A0 =C2=A0* Have we close= d on Barry's concerns about section 3.8.1.x?
=C2=A0 =C2=A0* Any rema= ining comments from any ADs that still need to be addressed?
=C2=A0 =C2= =A0* If all of the above, what needs to happy to submit an updated draft?
7. From the mailing list: "What is the canonical procedure to cr= eate an "infinite" audio stream, using Opus and FLAC codecs?"= ;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have been attempting to locate a sit= e which streams Opus continuously to test.

I also am interested = in the exact opusenc, et al. commands necessary to achieve creation of live= audio streams.

The use cases are implementation of user-define= d Web radio station, the capability to play the "infinite" stream= using HTMLAudioElement (WHATWG/HTML) over HTTP.

("infinit= e" is quoted here as there is no way to verify infinity; the gist is p= layback should not stop; is not seekable).
=C2=A0 =C2=A0*

8. Mat= roska issues
=C2=A0 =C2=A0*

9. FLAC issues
=C2=A0 =C2=A0*

AOB?

=C2=A0 =C2=A0 NEXT MEETING February 23, 2021.

N= otes from previous meeting for approval

CELLAR =E2=80=93 DRAFT AGEND= A for Virtual Interim Meeting
December 1, 2020 21:00 Amsterdam ***
20= :00 UTC
16:00 NYC
13:00 San Francisco
(Time is anchored to Amsterd= am)

INFO:
https://datatracker.ietf.org/doc/agenda-inte= rim-2020-cellar-09-cellar-01/

WEB CONFERENCE:

https://whereby.com/cellar-interim<= br>THERE IS NO TELEPHONE DIALIN (You can try this at any time.)
These no= tes at: https://github= .com/cellar-wg/chair-notes

Attendees

Spencer Dawkins
J= =C3=A9r=C3=B4me Martinez
Michael Richardson
Steve Lhomme
Michael N= iedermayer
Rohit Abhishek
Regrets:

Dave Rice
Note Well. https://www.ietf.org/about/n= ote-well/

Accept draft minutes from October 27 meeting (attached= below)

Logistics for Meeting.
3a) Shared COMIMD for notetaking:<= br>https://codimd.= ietf.org/notes-cellar-virtual
* Note that if you log in to the IETF = datatracker, you=E2=80=99ll
be able to edit these notes, add your name t= o attendee
lists, etc. *

Please ask Spencer if you have questions= .
3b) APPEAR.IN is now called =E2=80=9C= whereby.com=E2=80=9D

https://whereby.com/cellar-interim3c) Roll call

WG status update

FFV1 =E2=80=93 version 18 wa= s posted 2020-10-07, waiting for revision
new document on github today -= > new document to be uploaded to DT.
some feedback sent to those with= DISCUSS (Roman and Barry) ballots.
2021 Proposed virtual interim meetin= g dates
Fourth Tuesdays in 2021 are

January 26
February 23
= March 23
April 27
May 25
June 22
July 28 clashes with IETF 111 = so we won't meet on this date
August 24
September 28
October 2= 6
November 23. IETF 112: November 6-12, 2021: MAYBE in person meeting?* December 28 winter holidays so we won't meet on this date
What d= o we need to change?
Let=E2=80=99s book this pattern, and then, around 2= 021-09-28, we=E2=80=99ll see if we want to meet in person in Madrid.
NoT= imeToWait (March 2021, cancelled), but maybe December 2021.
[December 6 = is Matroska=E2=80=99s birthday!!!]
remaining FFV1 issues from DISCUSS
no remaining issues!
https://github.com/FFmpeg/FFV1/re= leases/tag/draft-ietf-cellar-ffv1-19_v4-16
Matroska issues

mu= ch discussion about accurate time stamps, progress in a number of pull requ= ests.

FLAC issues

no focus on this yet.

AOB?

A = lot of debate about what we want to do for FFV1 v4.
We will need a focus= ed conversation about this. {have this conversation in Feb. meeting}: April= 2021 date is not realistic.
The RFC on FFV1 versions v1 to v3 coming ou= t will be a big motivation for the industry.

Next meeting is: Januar= y 26.
--0000000000001b691805b9bd8128-- From nobody Tue Jan 26 09:54:28 2021 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 0AE723A0CE3; Tue, 26 Jan 2021 09:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 b-t_CiykDbgD; Tue, 26 Jan 2021 09:54:22 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 0A6763A0CDF; Tue, 26 Jan 2021 09:54:22 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id c18so7881745ljd.9; Tue, 26 Jan 2021 09:54:21 -0800 (PST) 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=mVtwRjGHXrxCQL4pd5ptMha5TD+9zg5KEatycruOOyA=; b=rjfaLz/JpI3ywvUJvGq2b4ZPcpgvVhqCVD7jSAm4s9vwNXaIiwtoNRCVY6byV6X6LT BZK6BrmjY9Med600W5dwm34N4tOLwiAi6NrW5PhcBidme017L0vU4r0m4n0OIJRQgqkc e0GLUGV+llZ7uM4891l24+Nst3XU09rGMrZ/QKsx2PI617jhnErGhQlmE7YZS8hG4GeD o5R7Oua36KKSWGZbD+H4zQTRJa/EogFn7PN5ASdzr8aVvs4mhzPCpSsIaczYLrTFOwgg D4xgCJu2qc6qYeMXU+bWRj5jiGF+uo+REBD99mVdg0P4abLSM96OcnrmCbV7uJYLPHgw QSvg== X-Gm-Message-State: AOAM533I3kvKlJ0Em9sJ/FwYlsbTMONQJiqnoXSiUulCWZKJrVrOycQa j8ZTqj1U+igXulfwcFMSrgACUidDA4NJggZvxS4= X-Google-Smtp-Source: ABdhPJzhe4uSKpnimxwIcZeEgpBr+cjg96MwM65rbLItLSXtMzQAHZ03LXwJfK5AnsptACTyiTQF3BsSv8HTyo6r7Gk= X-Received: by 2002:a2e:959a:: with SMTP id w26mr3422769ljh.113.1611683660149; Tue, 26 Jan 2021 09:54:20 -0800 (PST) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> <20201204183342.GO2389354@pb2> In-Reply-To: <20201204183342.GO2389354@pb2> From: Barry Leiba Date: Tue, 26 Jan 2021 12:54:08 -0500 Message-ID: To: Michael Niedermayer Cc: Dave Rice , cellar-chairs@ietf.org, derek.buitenhuis@gmail.com, Michael Richardson , pb@das-werkstatt.com, draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) 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, 26 Jan 2021 17:54:24 -0000 Where are we on this? I had thought you had the token to try to move the notation to pseudocode, but given the time lag I'm not sure we're all in agreement about what the next step is and who has it to take. So let's sync up and try to get this done. Thanks, Barry On Fri, Dec 4, 2020 at 1:34 PM Michael Niedermayer wrote: > > On Thu, Dec 03, 2020 at 06:46:48PM -0500, Dave Rice wrote: > > Hi Barry, > > Thanks so much for your comments. > > > > > On Dec 2, 2020, at 5:43 PM, Barry Leiba wro= te: > > > > > > OK, Dave, here's where I am with 3.8.1.x: > > > > > > =E2=80=94 Section 3.8.1 =E2=80=94 > > > > > > CABAC was replaced by a Range coder based on an algorithm defined b= y > > > G. Nigel N. Martin in 1979 [range-coding]. > > > > > > Keep in mind as you read my comments below that I=E2=80=99m not verse= d in this > > > field at all, I am not familiar with Range coding, and can=E2=80=99t = easily > > > look up the reference. Ha=E2=80=A6 but after typing that, I just did= : I found > > > it here: > > > http://sachingarg.com/compression/entropy_coding/range_coder.pdf > > > > > > Maybe it would help to add that URI to the reference? Anyway, again, > > > this isn=E2=80=99t my area, so it=E2=80=99s valid to say, for any of = this below, that > > > someone actually implementing this would already understand these > > > things. > > > > We had some discussion on this at https://github.com/FFmpeg/FFV1/pull/2= 19 and considered adding a reference to http://www.compressconsult.com/ran= gecoder/#literature or https://web.archive.org/web/*/http://www.compresscon= sult.com/rangecoder/#literature. A reason against is that these are unoffic= ial sources of this knowledge and thus perhaps not ideal to use for the cit= ation. > > > > I did just check to see if other RFCs cite this and found that RFC6716 = cites http://en.wikipedia.org/w/index.php?title=3DRange_encoding&oldid=3D50= 9582757 as an informative reference. > > > > For IETF is there a preference for which of these citations if any to u= se? > > > > > =E2=80=94 Section 3.8.1.1 =E2=80=94 > > > > > > To encode binary digits efficiently a Range coder is used. C_(i) i= s > > > the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) = is > > > the i-th Range coded binary value, S_(0, i) is the i-th initial > > > state. The length of the bytestream encoding n binary symbols is > > > j_(n) bytes. > > > > > > Two things here: > > > > > > Editorial: I think it would be easier to read this as an item list > > > (what do you think?): > > > > > > NEW > > > To encode binary digits efficiently a Range coder is used. > > > - C_(i) is the i-th Context > > > - B_(i) is the i-th byte of the bytestream > > > - b_(i) is the i-th Range coded binary value > > > - S_(0, i) is the i-th initial state > > > - j_(n) is the length of the bytestream encoding n binary symbols > > > END > > > > Locally, I=E2=80=99ve tested converting this into a definition list per= https://tools.ietf.org/html/rfc7991#section-2.20, which rendered in the te= xt output as: > > > > C_(i) the i-th Context. > > B_(i) the i-th byte of the bytestream. > > b_(i) the i-th Range coded binary value. > > S_(0, i) the i-th initial State. > > j_(n) the length of the bytestream encoding n binary symbols. > > > > > Substantive: It would also help to add to that list L_(i), l_(i), > > > R_(i), r_(i), and t_(i), so things are complete. Maybe also S_(x, i)= , > > > where x is not 0. > > > > Nudging Michael Niedermayer and Derek Buitenhuis on this for help. Some= guess work but if I understand correctly. > > > > L_(i) is the Low value of the Range > > l_(i) is a temporary storage variable used in assigning values to L_(i) > > R_(i) is the Range value > > r_(i) is a temporary storage variable used in assigning values to R_(i) > > t_(i) is a temporary storage variable used in assigning values to R_(i) > > S_(x, i) is the =E2=80=98x, 1=E2=80=99-th State. > > > > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > > l_(i) =3D L_(i) AND > > > t_(i) =3D R_(i) - r_(i) <=3D=3D > > > b_(i) =3D 0 <=3D=3D> > > > L_(i) < R_(i) - r_(i) > > > > > > I still don=E2=80=99t understand how to read this. > > > > I should note that these equation appear a bit differently in the HTML = version of the draft where they are depicted in SVG images of LaTeX equatio= ns. In the SVG, the equation all exists on one line; however, in the plain = text output it doesn=E2=80=99t fit in the line width so we wrap the output = a bit for cosmetics. If more clear we could re-arrange the line breaks, suc= h as: > > > > ( > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > l_(i) =3D L_(i) AND > > t_(i) =3D R_(i) - r_(i) > > ) <=3D=3D ( b_(i) =3D 0 ) <=3D=3D> ( L_(i) < R_(i) - r_(i) ) > > > > > Perhaps explain verbally > > > what it=E2=80=99s supposed to mean, and I can help figure out some wo= rds to > > > add that will help others? > > > > b_(i) =3D 0 and L_(i) < R_(i) - r_(i) would imply each other as well a= s implies the other group of three assignments. > > > > > I don=E2=80=99t know what the =E2=80=9CAND=E2=80=9D and =E2=80=9C<=3D= =3D=E2=80=9C and > > > =E2=80=9C<=3D=3D>=E2=80=9D on the right are trying to tell me (I get = what =E2=80=9CA <=3D=3D B=E2=80=9D means, > > > but I don=E2=80=99t know how to interpret =E2=80=9C<=3D=3D=E2=80=9C a= t the end of the line, for > > > example). > > > > It is only a line break, if not for the line width limitation this woul= d be: > > > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) AN= D t_(i) =3D R_(i) - r_(i) <=3D=3D b_(i) =3D 0 <=3D=3D> L_(i) < R_(i) - r= _(i) > > > > which is closer to how it looks in the SVG HTML version. > > > > > Do others who haven=E2=80=99t worked on this understand it? It=E2=80= =99s quite > > > possible that it=E2=80=99s just me, in which case I=E2=80=99ll happil= y step aside. > > > But I=E2=80=99m also happy to try to make it more understandable. > > > > Yes, please more understandability. :) > > > > > S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k > > > > > > Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if > > > the value of "k" is unequal to the i-th value of Context. > > > > > > The caption on this does help, so now I see what it=E2=80=99s getting= at! But > > > I would *never* understand it without the caption. (1) The > > > right-to-left conditional is odd to me. (2) I=E2=80=99m not used to = that sort > > > of conditional being used as an =E2=80=9Cif-then=E2=80=9D statement. = I=E2=80=99m curious why > > > you didn=E2=80=99t write this whole section in pseudo-code, and perha= ps it=E2=80=99s > > > another artifact of my wading into a field that=E2=80=99s foreign to = me. Had > > > Figure 13 been written like this, I would understand it perfectly: > > > > > > if ( C_(i) !=3D k ) then { S_(i + 1, k) =3D S_(i, k) } > > > > Yes, in pseudo-code that is the same. > > Michael Niedermayer, any objection to converting some of the math to ps= eudocode? > > Iam perfectly fine with changing the notation so it is easier to understa= nd. > > One disadavantage of pure pseudocode could be that it may be hard to desc= ribe > encoding in such a way that it describes not one bitstream but a set of > bitstreams which are guranteed to be decoded correctly. > That is if the encoder side is described by pseudocode. > > If the approuch of trying to describe the bitstream by the non pseudocode > notation is disliked. Then maybe the decoder side can be described by > normative pseudocode and the encoder side by informative pseudocode > so that the encoder side would be "one possible" solution but not the onl= y > one. > We could of course also describe both by strict normative pseudocode but > that would be different from what the original intend was > > None of this is specific to the quoted line of code above of course > > I had not imagined that the notation would lead to so much confusion, > its definitly important that the text can be understood and implemented > by the average target audience, if the notation causes problems here it > certainly should be improved ... > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > There will always be a question for which you do not know the correct ans= wer. From nobody Tue Jan 26 10:46:09 2021 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 78EB83A0D7C; Tue, 26 Jan 2021 10:46:08 -0800 (PST) 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=[SPF_HELO_NONE=0.001, SPF_NONE=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 MqLgvxq7q8u7; Tue, 26 Jan 2021 10:46:05 -0800 (PST) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7733A0D7A; Tue, 26 Jan 2021 10:46:03 -0800 (PST) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay10.mail.gandi.net (Postfix) with ESMTPSA id C1476240004; Tue, 26 Jan 2021 18:45:58 +0000 (UTC) Date: Tue, 26 Jan 2021 19:45:57 +0100 From: Michael Niedermayer To: Barry Leiba Cc: cellar-chairs@ietf.org, Michael Richardson , derek.buitenhuis@gmail.com, pb@das-werkstatt.com, draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG , Dave Rice Message-ID: <20210126184557.GA2389354@pb2> References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> <20201204183342.GO2389354@pb2> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q6M0GVIna3Wg/yP0" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) 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, 26 Jan 2021 18:46:09 -0000 --q6M0GVIna3Wg/yP0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 26, 2021 at 12:54:08PM -0500, Barry Leiba wrote: > Where are we on this? I had thought you had the token to try to move > the notation to pseudocode, but given the time lag I'm not sure we're > all in agreement about what the next step is and who has it to take. > So let's sync up and try to get this done. I thought derek or someone else was working on the range coder description = / pseudocode because of: https://github.com/FFmpeg/FFV1/issues/231#issuecomment-697328963 But iam starting to have the feeling i have mixed this up a bit Thanks >=20 > Thanks, > Barry >=20 > On Fri, Dec 4, 2020 at 1:34 PM Michael Niedermayer > wrote: > > > > On Thu, Dec 03, 2020 at 06:46:48PM -0500, Dave Rice wrote: > > > Hi Barry, > > > Thanks so much for your comments. > > > > > > > On Dec 2, 2020, at 5:43 PM, Barry Leiba w= rote: > > > > > > > > OK, Dave, here's where I am with 3.8.1.x: > > > > > > > > =E2=80=94 Section 3.8.1 =E2=80=94 > > > > > > > > CABAC was replaced by a Range coder based on an algorithm defined= by > > > > G. Nigel N. Martin in 1979 [range-coding]. > > > > > > > > Keep in mind as you read my comments below that I=E2=80=99m not ver= sed in this > > > > field at all, I am not familiar with Range coding, and can=E2=80=99= t easily > > > > look up the reference. Ha=E2=80=A6 but after typing that, I just d= id: I found > > > > it here: > > > > http://sachingarg.com/compression/entropy_coding/range_coder.pdf > > > > > > > > Maybe it would help to add that URI to the reference? Anyway, agai= n, > > > > this isn=E2=80=99t my area, so it=E2=80=99s valid to say, for any o= f this below, that > > > > someone actually implementing this would already understand these > > > > things. > > > > > > We had some discussion on this at https://github.com/FFmpeg/FFV1/pull= /219 and considered adding a reference to http://www.compressconsult.com/r= angecoder/#literature or https://web.archive.org/web/*/http://www.compressc= onsult.com/rangecoder/#literature. A reason against is that these are unoff= icial sources of this knowledge and thus perhaps not ideal to use for the c= itation. > > > > > > I did just check to see if other RFCs cite this and found that RFC671= 6 cites http://en.wikipedia.org/w/index.php?title=3DRange_encoding&oldid=3D= 509582757 as an informative reference. > > > > > > For IETF is there a preference for which of these citations if any to= use? > > > > > > > =E2=80=94 Section 3.8.1.1 =E2=80=94 > > > > > > > > To encode binary digits efficiently a Range coder is used. C_(i)= is > > > > the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i= ) is > > > > the i-th Range coded binary value, S_(0, i) is the i-th initial > > > > state. The length of the bytestream encoding n binary symbols is > > > > j_(n) bytes. > > > > > > > > Two things here: > > > > > > > > Editorial: I think it would be easier to read this as an item list > > > > (what do you think?): > > > > > > > > NEW > > > > To encode binary digits efficiently a Range coder is used. > > > > - C_(i) is the i-th Context > > > > - B_(i) is the i-th byte of the bytestream > > > > - b_(i) is the i-th Range coded binary value > > > > - S_(0, i) is the i-th initial state > > > > - j_(n) is the length of the bytestream encoding n binary symbo= ls > > > > END > > > > > > Locally, I=E2=80=99ve tested converting this into a definition list p= er https://tools.ietf.org/html/rfc7991#section-2.20, which rendered in the = text output as: > > > > > > C_(i) the i-th Context. > > > B_(i) the i-th byte of the bytestream. > > > b_(i) the i-th Range coded binary value. > > > S_(0, i) the i-th initial State. > > > j_(n) the length of the bytestream encoding n binary symbols. > > > > > > > Substantive: It would also help to add to that list L_(i), l_(i), > > > > R_(i), r_(i), and t_(i), so things are complete. Maybe also S_(x, = i), > > > > where x is not 0. > > > > > > Nudging Michael Niedermayer and Derek Buitenhuis on this for help. So= me guess work but if I understand correctly. > > > > > > L_(i) is the Low value of the Range > > > l_(i) is a temporary storage variable used in assigning values to L_(= i) > > > R_(i) is the Range value > > > r_(i) is a temporary storage variable used in assigning values to R_(= i) > > > t_(i) is a temporary storage variable used in assigning values to R_(= i) > > > S_(x, i) is the =E2=80=98x, 1=E2=80=99-th State. > > > > > > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > > > l_(i) =3D L_(i) AND > > > > t_(i) =3D R_(i) - r_(i) <=3D=3D > > > > b_(i) =3D 0 <=3D=3D> > > > > L_(i) < R_(i) - r_(i) > > > > > > > > I still don=E2=80=99t understand how to read this. > > > > > > I should note that these equation appear a bit differently in the HTM= L version of the draft where they are depicted in SVG images of LaTeX equat= ions. In the SVG, the equation all exists on one line; however, in the plai= n text output it doesn=E2=80=99t fit in the line width so we wrap the outpu= t a bit for cosmetics. If more clear we could re-arrange the line breaks, s= uch as: > > > > > > ( > > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > > l_(i) =3D L_(i) AND > > > t_(i) =3D R_(i) - r_(i) > > > ) <=3D=3D ( b_(i) =3D 0 ) <=3D=3D> ( L_(i) < R_(i) - r_(i) ) > > > > > > > Perhaps explain verbally > > > > what it=E2=80=99s supposed to mean, and I can help figure out some = words to > > > > add that will help others? > > > > > > b_(i) =3D 0 and L_(i) < R_(i) - r_(i) would imply each other as well= as implies the other group of three assignments. > > > > > > > I don=E2=80=99t know what the =E2=80=9CAND=E2=80=9D and =E2=80=9C<= =3D=3D=E2=80=9C and > > > > =E2=80=9C<=3D=3D>=E2=80=9D on the right are trying to tell me (I ge= t what =E2=80=9CA <=3D=3D B=E2=80=9D means, > > > > but I don=E2=80=99t know how to interpret =E2=80=9C<=3D=3D=E2=80=9C= at the end of the line, for > > > > example). > > > > > > It is only a line break, if not for the line width limitation this wo= uld be: > > > > > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) = AND t_(i) =3D R_(i) - r_(i) <=3D=3D b_(i) =3D 0 <=3D=3D> L_(i) < R_(i) -= r_(i) > > > > > > which is closer to how it looks in the SVG HTML version. > > > > > > > Do others who haven=E2=80=99t worked on this understand it? It=E2= =80=99s quite > > > > possible that it=E2=80=99s just me, in which case I=E2=80=99ll happ= ily step aside. > > > > But I=E2=80=99m also happy to try to make it more understandable. > > > > > > Yes, please more understandability. :) > > > > > > > S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k > > > > > > > > Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State = if > > > > the value of "k" is unequal to the i-th value of Context. > > > > > > > > The caption on this does help, so now I see what it=E2=80=99s getti= ng at! But > > > > I would *never* understand it without the caption. (1) The > > > > right-to-left conditional is odd to me. (2) I=E2=80=99m not used t= o that sort > > > > of conditional being used as an =E2=80=9Cif-then=E2=80=9D statement= =2E I=E2=80=99m curious why > > > > you didn=E2=80=99t write this whole section in pseudo-code, and per= haps it=E2=80=99s > > > > another artifact of my wading into a field that=E2=80=99s foreign t= o me. Had > > > > Figure 13 been written like this, I would understand it perfectly: > > > > > > > > if ( C_(i) !=3D k ) then { S_(i + 1, k) =3D S_(i, k) } > > > > > > Yes, in pseudo-code that is the same. > > > Michael Niedermayer, any objection to converting some of the math to = pseudocode? > > > > Iam perfectly fine with changing the notation so it is easier to unders= tand. > > > > One disadavantage of pure pseudocode could be that it may be hard to de= scribe > > encoding in such a way that it describes not one bitstream but a set of > > bitstreams which are guranteed to be decoded correctly. > > That is if the encoder side is described by pseudocode. > > > > If the approuch of trying to describe the bitstream by the non pseudoco= de > > notation is disliked. Then maybe the decoder side can be described by > > normative pseudocode and the encoder side by informative pseudocode > > so that the encoder side would be "one possible" solution but not the o= nly > > one. > > We could of course also describe both by strict normative pseudocode but > > that would be different from what the original intend was > > > > None of this is specific to the quoted line of code above of course > > > > I had not imagined that the notation would lead to so much confusion, > > its definitly important that the text can be understood and implemented > > by the average target audience, if the notation causes problems here it > > certainly should be improved ... > > > > Thanks > > > > [...] > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > There will always be a question for which you do not know the correct a= nswer. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threat= s=20 related to an insecure 5G network, it needs to rethink the extent to which = it values corporate profits and government espionage over security.-Bruce Schn= eier --q6M0GVIna3Wg/yP0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYBBjYQAKCRBhHseHBAsP qwRUAKCSj8d/MQovb7DwXGSzgtmIfMZdpgCeO7rZg/nkt4RCNTdYCLhQ0Fzh3Tk= =snRG -----END PGP SIGNATURE----- --q6M0GVIna3Wg/yP0-- From nobody Tue Jan 26 12:29:32 2021 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 0894C3A0E5C for ; Tue, 26 Jan 2021 12:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 ZHDykOzVsvEH for ; Tue, 26 Jan 2021 12:29:29 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 E02D83A0E5A for ; Tue, 26 Jan 2021 12:29:28 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id k132so18083371ybf.2 for ; Tue, 26 Jan 2021 12:29:28 -0800 (PST) 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; bh=EEukXtGGpunuaPGzN8l3Xrc8sW8hQ9FWDrJoTRwadYc=; b=vZbMwDi6lfO5mC1ZmRbV+7VCOdnO0Vb3SbP4bScSzBPwDPZMBwPRerNoRI9tFHp4OX /uP5ehiUIefrVNMK6ISHdtrCfW4UcTzNMfRO0Ix4q7X7fxnFANRC8P7v1wdnX7FIUtku AsWVOkiGBC/x8N6wuHKjcozKaKEch6FXpgazRQyaag+aURuaAPkgbo9NjYIgbMaskQWU xtB+M0+KTInorw3KB8J+775u3jrwe65DVjEMSIAG/zwvdtzsflp6UPURV/XRAzkk9L0D bA94B4j/UrdYVOYKMyYVPKeWmJLq2+QwuI4oFG7vRtA+y2q5I38Wyod1tmmV3HnD9FNR ZxMg== 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; bh=EEukXtGGpunuaPGzN8l3Xrc8sW8hQ9FWDrJoTRwadYc=; b=BXbqBpkv4ab8bL+Lc93KLERxwbM2qWc77iFUrn8BfzMX+Ypeo9EgreWLc1PyWyRJOg dC7wlk9vVxXGXg2pezy2x5T0ZesWi3OqaUEksR1bfU5eW2ZoJGVJoDmBnq2VrGg3ALmj xCaLTmLm6smtmKTUhHE2nyfpSj73WVfusrdWCLLlENtAfDlvFrg1YN1jut5I1BrFaMXW NIrAtT5lGHBhJc1ZY9P8pW8TDeOgpq3kTokkEfNVzY8ID46uNbNYvdavEoldDE1qo3W1 osZ7M387rMXxOhi8p5mAB6kAOr+KlmBj95T6twifSx+sLbz4Iq2+ryWvhQitzTLknP/E KMGQ== X-Gm-Message-State: AOAM533q6NucP/Z4gbTXDG5PdqcHZzhuaWCdqw7DWRbovkVBeUEPvr8H 48QIqqRsw0aCxG6aT2qf/+80fNnnAHqtOUWBzlpMZpBn X-Google-Smtp-Source: ABdhPJxlDgU5wxtvW6ei0IuW3YchzF9tnHgsFw8mG44JmIefq8TjkvvoXkY0xshbpy0JtIoipTcZnSyOakjQmA2sk30= X-Received: by 2002:a25:245:: with SMTP id 66mr10809296ybc.53.1611692967699; Tue, 26 Jan 2021 12:29:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 26 Jan 2021 14:29:01 -0600 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000d3a9b605b9d38229" Archived-At: Subject: [Cellar] Fwd: Any special requests for agenda items in our January virtual interim meeting on January 26? 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, 26 Jan 2021 20:29:31 -0000 --000000000000d3a9b605b9d38229 Content-Type: text/plain; charset="UTF-8" My apologies - this was a private reply to my "any agenda item special requests?" e-mail. Best, Spencer ---------- Forwarded message --------- From: guest271314 Date: Tue, Jan 19, 2021 at 7:20 PM Subject: Re: [Cellar] Any special requests for agenda items in our January virtual interim meeting on January 26? To: Spencer Dawkins at IETF What is the canonical procedure to create an "infinite" audio stream, using Opus and FLAC codecs? I have been attempting to locate a site which streams Opus continuously to test. I also am interested in the exact opusenc, et al. commands necessary to achieve creation of live audio streams. The use cases are implementation of user-defined Web radio station, the capability to play the "infinite" stream using HTMLAudioElement (WHATWG/HTML) over HTTP. ("infinite" is quoted here as there is no way to verify infinity; the gist is playback should not stop; is not seekable). /guest271314/ On Tue, Jan 19, 2021 at 11:42 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > We've been mostly doing an agenda of "walking through Github issues and > PRs" in recent meetings. > > Are there any other agenda items that Michael and I should add? > > Best, > > Spencer > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --000000000000d3a9b605b9d38229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My apologies - this was a private reply to my "any ag= enda item special requests?" e-mail.=C2=A0

Best,

Spencer

---------- Forwarded message ---------
Fro= m: guest271314 <guest271314@gm= ail.com>
Date: Tue, Jan 19, 2021 at 7:20 PM
Subject: Re= : [Cellar] Any special requests for agenda items in our January virtual int= erim meeting on January 26?
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com><= br>


What is the canonical procedure to create= an "infinite" audio stream, using Opus and FLAC codecs?

=
I have been attempting to locate a site which streams Opus conti= nuously to test.

I also am interested in the exact= opusenc, et al. commands necessary to achieve creation of live audio strea= ms.

The use cases are implementation of user-defin= ed Web radio station, the capability to play the "infinite" strea= m using HTMLAudioElement (WHATWG/HTML) over HTTP.

= ("infinite" is quoted here as there is no way to verify infinity;= the gist is playback should not stop; is not seekable).
=C2=A0
/guest271314/

On Tue, Jan 19, 2021 at 11:42 PM Spencer Dawk= ins at IETF <spencerdawkins.ietf@gmail.com> wrote:
We've been mostly= doing an agenda of "walking through Github issues=C2=A0and PRs" = in recent meetings.=C2=A0

Are there any other agenda ite= ms that Michael and I should add?

Best,
=
Spencer
_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000d3a9b605b9d38229-- From nobody Tue Jan 26 13:00:06 2021 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 6B4DA3A0FC9 for ; Tue, 26 Jan 2021 13:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 SnCZKFlFMMBA for ; Tue, 26 Jan 2021 13:00:00 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 DBC023A0EED for ; Tue, 26 Jan 2021 12:59:58 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id 84so5186375yba.3 for ; Tue, 26 Jan 2021 12:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=c53TxQPyIKQdq400Is8UqNnK4Sq+kE/o+OG/MMKUe7A=; b=l6K1hBHLsKWQ8kjgidzJx9rmte+ZctDSGKG4MGsZHvq7KT2G35vmm/b500u1t6uEHc pwlMJ6Nv/7osalEwx+E0ZuwkvYqv6BBKz3aV1+Msgfenw+uAo9nDmINy7EnHLcViAZ7w didVMkvhlvF+tCfDZJwLvsr6ESmjOf1Cb0zLatgnnbiopoQ+d9rq4k5q7VwyNZoV20ay 3+P3TqHYqhS1ruHJeGj3VwCGHnH9IhJkhy9A6cidP1kCXTiAHNHloieYoTfJYfwRH5Gj j4b6/JcV7P5hwptjhiDnRMRtwBZX5SYt0Dbr6kujNzXVRf01Lg/orGAWjJQ8tk38Vw0p jb1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c53TxQPyIKQdq400Is8UqNnK4Sq+kE/o+OG/MMKUe7A=; b=CGXoUJSVMbRvOBICwoGro/rTVoRFw+zPecWb/pZ2fOIGvZI5IbtCqKLD/WIhEGJJYK fW9bQKFxokDP9ItXLumfFpOrPjQXuf8jpwOufhc1YS8tqKWvUa3ugllobFiiXHdtx2Qn 01Gr74xQWKn6Zy7VxTETf3Er4IWKDvObdhLg0RcmAA2CWKpFMn8bMFJ2nTb76IwQI63+ RKpzyg1QdvtZFf4EBusKMOVg3lcsVGHBJTYs3WtC6LixiHAsAwZyLErFVyLetxofYtDy gW9zBF3lOBmGvY/JXm0DhUcNP6ZgdsxpIoxWGKD5yTWupapYyIclMgzQTUkhWAX2ns+p KX9A== X-Gm-Message-State: AOAM533jsyC7Ep3h0O3FmPnOMHWAPaOrsvNaecMilxTW6AuF0PiAp/Aa 0ysSkEuTbbuwFOVJobF1358pYbmliD1yCwWydoXzOASiBUI= X-Google-Smtp-Source: ABdhPJymHc6MFaJDIW47Cr9yicDUJ+KyKlaIrA63eXFDCINCnUO6BkL6jzSTKQq3e3j3433Pv4Oy2guUwpr+dOBXuE0= X-Received: by 2002:a25:245:: with SMTP id 66mr10976613ybc.53.1611694797890; Tue, 26 Jan 2021 12:59:57 -0800 (PST) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 26 Jan 2021 14:59:32 -0600 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000ea296305b9d3ef3f" Archived-At: Subject: [Cellar] Updated weekly Github summary for Cellar 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, 26 Jan 2021 21:00:05 -0000 --000000000000ea296305b9d3ef3f Content-Type: text/plain; charset="UTF-8" Here's what I've got today (should appear in this week's summary on Sunday). "cellar@ietf.org": { "digest:sunday": { "eventFilter": { "notlabel": [ "editorial" ] }, "repos": [ "ietf-cellar-wg/ebml-specification", "ietf-cellar-wg/matroska-specification", "FFmpeg/FFV1", "ietf-wg-cellar/Cellar-FLAC", "ietf-cellar-wg/chair-notes" ], "topic": "CELLAR Activity Summary" } }, The FLAC entry was what I changed. It actually does exist (at https://github.com/ietf-wg-cellar/Cellar-FLAC). Please let me know if I'm still confused. Best, Spencer --000000000000ea296305b9d3ef3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's what I've got today (should appear in this = week's summary on Sunday).=C2=A0

=C2=A0 =C2=A0 "= ;cellar@ietf.org": {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 "digest:sunday": {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 "eventFilter": {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "notlabel": [
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "editorial&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ]
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 "repos": [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "ietf-cellar-wg/ebml-specification",
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "ietf-cellar-wg/matroska= -specification",
"FFmpeg/FFV1",
"ietf-wg-cella= r/Cellar-FLAC",
"ietf-cellar-wg/chair-notes&= quot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ],
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "topic": "CELLAR Activity Summary&q= uot;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 },
The FLAC entry was what I changed. It actually does exist (at= =C2=A0https://git= hub.com/ietf-wg-cellar/Cellar-FLAC).

Please le= t me know if I'm still confused.=C2=A0

Best,= =C2=A0

Spencer
--000000000000ea296305b9d3ef3f-- From nobody Tue Jan 26 13:34:17 2021 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 BB6F83A0FB0 for ; Tue, 26 Jan 2021 13:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 7aNKnJFAzZyR for ; Tue, 26 Jan 2021 13:34:13 -0800 (PST) Received: from 2.mo178.mail-out.ovh.net (2.mo178.mail-out.ovh.net [46.105.39.61]) (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 3EA0F3A0FAF for ; Tue, 26 Jan 2021 13:34:12 -0800 (PST) Received: from player168.ha.ovh.net (unknown [10.108.35.128]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id AE398C149E for ; Tue, 26 Jan 2021 22:34:10 +0100 (CET) Received: from mediaarea.net (p548f9592.dip0.t-ipconnect.de [84.143.149.146]) (Authenticated sender: jerome@mediaarea.net) by player168.ha.ovh.net (Postfix) with ESMTPSA id 849C61A67C108; Tue, 26 Jan 2021 21:34:06 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-104R005c5998b0e-2fb6-4d09-b679-79ae9e7aa164, 1FBEB7CDF052E4953D80234FC31011972D24E23A) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.149.146 To: cellar@ietf.org, guest271314 References: From: Jerome Martinez Message-ID: <84924790-b96d-55af-80d1-a844d780e937@mediaarea.net> Date: Tue, 26 Jan 2021 22:34:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F504580E798F7C69042D91A9" Content-Language: en-US X-Ovh-Tracer-Id: 10003057724300529713 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrvdeigdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpefgjefhueehhfelffevfffgvdevhfelkefglefhgeehfeduvedvuedthfehvedutdenucfkpheptddrtddrtddrtddpkeegrddugeefrddugeelrddugeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrudeikedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Fwd: Any special requests for agenda items in our January virtual interim meeting on January 26? 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, 26 Jan 2021 21:34:16 -0000 This is a multi-part message in MIME format. --------------F504580E798F7C69042D91A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit hi, On 26/01/2021 21:29, Spencer Dawkins at IETF wrote: > ---------- Forwarded message --------- > From: *guest271314* > > > What is the canonical procedure to create an "infinite" audio stream, > using Opus and FLAC codecs? The CELLAR working group is about FLAC and Matroska formats, so I speak only about them. No "procedure" as procedures are about tools which would encode such stream, not the purpose (IMO) of the working group. Technically, I don't see something blocking with FLAC infinite streaming, as FLAC frames are independent; there may be an issue with the sample number, which is a 36-bit value (so days of playback...), but this value is mostly used for seeking and a web radio station would not try to seek several days in the past. At the specification level there is maybe a lack of precision that the sample number value is modulo 36. For Matroska, I am less comfortable but it seems that there is nothing blocking for "big" timestamps (years of playback?) Jérôme --------------F504580E798F7C69042D91A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
hi,

On 26/01/2021 21:29, Spencer Dawkins at IETF wrote:
---------- Forwarded message ---------
From: guest271314 <guest271314@gmail.com>

What is the canonical procedure to create an "infinite" audio stream, using Opus and FLAC codecs?

The CELLAR working group is about FLAC and Matroska formats, so I speak only about them.
No "procedure" as procedures are about tools which would encode such stream, not the purpose (IMO) of the working group.

Technically, I don't see something blocking with FLAC infinite streaming, as FLAC frames are independent; there may be an issue with the sample number, which is a 36-bit value (so days of playback...), but this value is mostly used for seeking and a web radio station would not try to seek several days in the past. At the specification level there is maybe a lack of precision that the sample number value is modulo 36.

For Matroska, I am less comfortable but it seems that there is nothing blocking for "big" timestamps (years of playback?)

Jérôme
--------------F504580E798F7C69042D91A9-- From nobody Tue Jan 26 13:54:15 2021 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 F24943A1170 for ; Tue, 26 Jan 2021 13:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 Uft29Xux-tLc for ; Tue, 26 Jan 2021 13:54:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470E33A0FF0 for ; Tue, 26 Jan 2021 13:53:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 35D7A38A12; Tue, 26 Jan 2021 16:56:19 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7rC_0yeR7DM3; Tue, 26 Jan 2021 16:56:18 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B99C038A11; Tue, 26 Jan 2021 16:56:18 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0413B618; Tue, 26 Jan 2021 16:53:56 -0500 (EST) From: Michael Richardson To: Spencer Dawkins at IETF cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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 Date: Tue, 26 Jan 2021 16:53:55 -0500 Message-ID: <12952.1611698035@localhost> Archived-At: Subject: Re: [Cellar] Updated weekly Github summary for Cellar 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, 26 Jan 2021 21:54:14 -0000 Spencer Dawkins at IETF wrote: > Here's what I've got today (should appear in this week's summary on > Sunday). > "cellar@ietf.org": { "digest:sunday": { "eventFilter": { > "notlabel": [ "editorial" ] }, "repos": [ > "ietf-cellar-wg/ebml-specification", > "ietf-cellar-wg/matroska-specification", "FFmpeg/FFV1", > "ietf-wg-cellar/Cellar-FLAC", "ietf-cellar-wg/chair-notes" ], "topic": > "CELLAR Activity Summary" } }, They should all be ietf-wg-cellar now. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Tue Jan 26 13:55:00 2021 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 25BAA3A0EA7; Tue, 26 Jan 2021 13:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 gwlHCQwboM5r; Tue, 26 Jan 2021 13:02:11 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 7D67C3A0EA1; Tue, 26 Jan 2021 13:02:11 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id x78so18117909ybe.11; Tue, 26 Jan 2021 13:02:11 -0800 (PST) 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=hrPXTPVyhyDrhIeH6dPb4zsgQMiEEwUNEhDnEDTUz28=; b=nzhitd0870FmMo8KH5EK019qB6nUnTw9P91nSKuV1tAo5q2WBTBa1CYC3/r0HHLL/Q 5Tc/JCiq5Rvzp67Ja9Hsh9Bv012BOyeGEVZo2YVPRA4KRU1lem3MragO4aRtADG3n1RE 0MKVpOBLriWAXHSJscVVQnvS1Ue6ie6Bt3za0PPiKEKyWCe8EyxmI1Z1EIjcYqGwliNZ l7oddNNkTIN7w3qFQ+dniPjC/+mx0X6Z8RjK9R6xBwH5Vpcrjbq6XFoRlY52F0xLoCtR 8Of5KQqJgo7EA2wcdq4rB90w6KY2FaB3k6AQHiT76MZLedYsMZ6d4U2Ger99mVkCXmK/ P4jw== 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=hrPXTPVyhyDrhIeH6dPb4zsgQMiEEwUNEhDnEDTUz28=; b=EDh0C21O4CtDt6ljz8bsN0f27IBtFDb3N/99+gGu3v59J+NsMTb1guuyPpKTqL8NDn TATDgYmH6mkYsab2EjSsPuN7I6EtZDoGa/lO7O1VJN/DysOQ4qHWS8fkA7/grOkMuChY 6fH5fFFhpvlPsz18Kz4rqKkS0msxtju5dxfdK2ObxoLZUuYt8MFqSyLyGL4oVLzYSEh9 E8UC25QEcVaawe+Qv3x3qzxSMPgB6Lm9KVFEPv62CQnhSkjSthpCY3zMNR3CFZfj8CvB j/Ffo493DQe0eCeXNkFdZCJ1wVdef9UoDgEGd+6Yu1UkdLN8TNYxTDVtUBRe/WpfasrN K06w== X-Gm-Message-State: AOAM530CQRQ+cMmwNITRUC/E4FuWTjpEodTgkJtbOGOscxTmw+zH0oH1 G9CwfTWWDWBaZQ4lDQhIE+6yuUTCi4kDbLyZdk7s1jN0 X-Google-Smtp-Source: ABdhPJzR5TxmY1kM2uCCAadB+W9F1hEsf4B9W18pAhuzPSZyt3+ZYqPKoTgzuCwgOtzLwhnEJT7dKLH1lcLGNhnEk94= X-Received: by 2002:a25:d009:: with SMTP id h9mr11253950ybg.465.1611694930817; Tue, 26 Jan 2021 13:02:10 -0800 (PST) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> <20201204183342.GO2389354@pb2> <20210126184557.GA2389354@pb2> In-Reply-To: <20210126184557.GA2389354@pb2> From: Spencer Dawkins at IETF Date: Tue, 26 Jan 2021 15:01:44 -0600 Message-ID: To: Michael Niedermayer Cc: Barry Leiba , cellar-chairs@ietf.org, Michael Richardson , derek.buitenhuis@gmail.com, "Peter B." , draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG , Dave Rice Content-Type: multipart/alternative; boundary="000000000000d676a605b9d3f70d" Archived-At: X-Mailman-Approved-At: Tue, 26 Jan 2021 13:54:59 -0800 Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) 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, 26 Jan 2021 21:02:13 -0000 --000000000000d676a605b9d3f70d Content-Type: text/plain; charset="UTF-8" Hi, Barry, On Tue, Jan 26, 2021 at 12:46 PM Michael Niedermayer wrote: > On Tue, Jan 26, 2021 at 12:54:08PM -0500, Barry Leiba wrote: > > Where are we on this? I had thought you had the token to try to move > > the notation to pseudocode, but given the time lag I'm not sure we're > > all in agreement about what the next step is and who has it to take. > > So let's sync up and try to get this done. > > I thought derek or someone else was working on the range coder description > / pseudocode > because of: > https://github.com/FFmpeg/FFV1/issues/231#issuecomment-697328963 > But iam starting to have the feeling i have mixed this up a bit > > Thanks > Your timing is perfect. We discussed this at this afternoon's monthly interim meeting. Stay tuned for a description people can understand. Best, Spencer --000000000000d676a605b9d3f70d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Barry,=C2=A0

On Tue, Jan 26, 2021 at 1= 2:46 PM Michael Niedermayer <michael@niedermayer.cc> wrote:
=
On Tue, Jan 26, 2021 at 1= 2:54:08PM -0500, Barry Leiba wrote:
> Where are we on this?=C2=A0 I had thought you had the token to try to = move
> the notation to pseudocode, but given the time lag I'm not sure we= 're
> all in agreement about what the next step is and who has it to take. > So let's sync up and try to get this done.

I thought derek or someone else was working on the range coder description = / pseudocode
because of: https://github.com/FFmpe= g/FFV1/issues/231#issuecomment-697328963
But iam starting to have the feeling i have mixed this up a bit

Thanks

Your timing is perfect. We discu= ssed this at this afternoon's monthly interim meeting. Stay tuned for a= description people can understand.=C2=A0

Best,

Spencer=C2=A0
--000000000000d676a605b9d3f70d-- From nobody Tue Jan 26 13:55:04 2021 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 B093E3A0EAC; Tue, 26 Jan 2021 13:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 D-6R3FsXHTug; Tue, 26 Jan 2021 13:04:00 -0800 (PST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 35AAD3A0EA1; Tue, 26 Jan 2021 13:04:00 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id b2so2601179lfq.0; Tue, 26 Jan 2021 13:04:00 -0800 (PST) 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=b2eLVmzqxYFf3FFg8MTM6oPjYOOVqwF5Hx1XBuVtsp0=; b=kdisgzvTZYM7eq2LMuJr+xJ1aiGDgxlx5/9u2JIlPww6gRWnfzvGqplO6XlYSWpS2M osFMkH+YmKUegiwBYOxp3Rzo0OAXwV2fUqZJuGccHBkCO2gZ0GFIpywqf5J3yOUDOEGI e7Uo+Jydwg2oGOhZdUwoQNJULW84T0w7nOgM+v9Hbs1HiiLzdHSp5bGqzH9QssV95qvx 4uDXqikv9YtYfN+tEnZDJsDTN/2v0d6Dv7T7Uo9HI1fi4/Z/0p4oqeE5vY6myQqkgHB6 JYXVinpt+s2D4wMlT1Z7IwvPoi6QOmwARyzsxBLlggDnAtNHr1NdHMipKHQ/od/ynT/K RcDQ== X-Gm-Message-State: AOAM531yC/Bh8xy09sPzSLtXOTVXbzdO1R1Q7GbZaIdHoizylneBxKGr xsIwCab+d5b+VoWNqSuSNWkOQPfUtASzd0LMa6Y= X-Google-Smtp-Source: ABdhPJwTlIrwTtckxF36wuRA1TCuN1IHqGES2z7s86Rr2o2EHLhcHxYAcSQsa4KdeNUlSxElfNlAWD79b9jhsUWyDG8= X-Received: by 2002:ac2:592a:: with SMTP id v10mr3447627lfi.123.1611695038331; Tue, 26 Jan 2021 13:03:58 -0800 (PST) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> <20201204183342.GO2389354@pb2> <20210126184557.GA2389354@pb2> In-Reply-To: From: Barry Leiba Date: Tue, 26 Jan 2021 16:03:47 -0500 Message-ID: To: Spencer Dawkins at IETF Cc: Michael Niedermayer , cellar-chairs@ietf.org, Michael Richardson , derek.buitenhuis@gmail.com, "Peter B." , draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG , Dave Rice Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 26 Jan 2021 13:54:58 -0800 Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) 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, 26 Jan 2021 21:04:02 -0000 > Your timing is perfect. We discussed this at this afternoon's monthly interim meeting. Stay tuned for a description people can understand. Excellent! Thanks! With bated breath, I wait. :-) Barry > Hi, Barry, > > On Tue, Jan 26, 2021 at 12:46 PM Michael Niedermayer wrote: >> >> On Tue, Jan 26, 2021 at 12:54:08PM -0500, Barry Leiba wrote: >> > Where are we on this? I had thought you had the token to try to move >> > the notation to pseudocode, but given the time lag I'm not sure we're >> > all in agreement about what the next step is and who has it to take. >> > So let's sync up and try to get this done. >> >> I thought derek or someone else was working on the range coder description / pseudocode >> because of: https://github.com/FFmpeg/FFV1/issues/231#issuecomment-697328963 >> But iam starting to have the feeling i have mixed this up a bit From nobody Tue Jan 26 18:35:48 2021 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 B1EF33A10F2 for ; Tue, 26 Jan 2021 18:35:46 -0800 (PST) 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 hCErt1ovcF29 for ; Tue, 26 Jan 2021 18:35:45 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 32F6F3A10F0 for ; Tue, 26 Jan 2021 18:35:45 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id k132so623428ybf.2 for ; Tue, 26 Jan 2021 18:35:45 -0800 (PST) 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=ySBs314HCuLAFeGkgKGjYCbmA7bRz65YKUnQsQCQzOk=; b=u3HHB/2L9zeA1Lxg5BBrcw203kkn1py4XBFXXsz+vm0kyxYmUxg+PbSSK+QcAtWbRE k+2uNO4oy64FEvlxKQjm86iv7TCqlVAJcDna1HHo1D6FalkRvYti7B1zhWeLFQGdgUnN 2iWqgwecxQhboiffw25/RjzjN7XJZMmf/irVKlRp5L1YljZVJHsdZ8OtfLSU2K08yDIl y/hKgJqALSDlNp51w4ndWuz53rjeQUC/uXYguQrEB9SCRB6vhWzPSjDlX+u9iK1uZGhK rpi/+jyZWVTWKpkTcUNwYutglT+rtUQESctiyIOj7uz8cWLAQot8VT2nqMlXFjDtNYF0 EntQ== 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=ySBs314HCuLAFeGkgKGjYCbmA7bRz65YKUnQsQCQzOk=; b=m86/0x882hH2WBTfCWKOCVgtHzR/LNT/2wbVyX97X+P75VYPsE77nASsOctUPolC+U OrZlDcLkSaZFd2dDBGDTsVdeOzke3Egh1vSbD/YmNMgOpgRZo+QHJTpeW7UbufkzEDTw Lni1cYLc/RxFW4iU18VY1pIAc5idXtLyRdhbl/ElKQS3WuvA2cfCWfDL77nufyoeVrRB /E28coZuECzXYFwfLEUtP7iEfumwsjgageqaI1VSCnnLpwQ50r9v9rQLXt8kwp8ApTHN G7R0V50HPc4AxHg9oNzumRZGxYoNQPy/vxSOiverVHubw7xfPcIVm1vZsH5yWZmqggGB RFSw== X-Gm-Message-State: AOAM5335xzgJtVyNnyddu6W9eaNSb2/maRGILG/HOqTDbTuMHyZkTVJT vw62K0lfClUkyXA/VesRoyGpGEa1DY6cxn+FRhTabTb9 X-Google-Smtp-Source: ABdhPJwlIvOfikoSDkLak/LLrSqkHmMm5vSD83FGHNAh1kLiuljWiXZlHswYyYahGq7PjUBPqnkn6rSUh+R+nXioFe0= X-Received: by 2002:a25:245:: with SMTP id 66mr12563544ybc.53.1611714944254; Tue, 26 Jan 2021 18:35:44 -0800 (PST) MIME-Version: 1.0 References: <12952.1611698035@localhost> In-Reply-To: <12952.1611698035@localhost> From: Spencer Dawkins at IETF Date: Tue, 26 Jan 2021 20:35:18 -0600 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000bb45c405b9d8a065" Archived-At: Subject: Re: [Cellar] Updated weekly Github summary for Cellar 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: Wed, 27 Jan 2021 02:35:47 -0000 --000000000000bb45c405b9d8a065 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Tue, Jan 26, 2021 at 3:53 PM Michael Richardson wrote: > Spencer Dawkins at IETF wrote: > > Here's what I've got today (should appear in this week's summary on > > Sunday). > > > "cellar@ietf.org": { "digest:sunday": { "eventFilter": { > > "notlabel": [ "editorial" ] }, "repos": [ > > "ietf-cellar-wg/ebml-specification", > > "ietf-cellar-wg/matroska-specification", "FFmpeg/FFV1", > > "ietf-wg-cellar/Cellar-FLAC", "ietf-cellar-wg/chair-notes" ], > "topic": > > "CELLAR Activity Summary" } }, > > They should all be ietf-wg-cellar now. And now, they are! Best, Spencer --000000000000bb45c405b9d8a065 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Tue, Jan 26, 2021 at= 3:53 PM Michael Richardson <mcr@san= delman.ca> wrote:
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:=
=C2=A0 =C2=A0 > Here's what I've got today (should appear in thi= s week's summary on
=C2=A0 =C2=A0 > Sunday).

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0"cellar@ietf.org": { "digest:sunday"= ;: { "eventFilter": {
=C2=A0 =C2=A0 > "notlabel": [ "editorial" ] }, "= ;repos": [
=C2=A0 =C2=A0 > "ietf-cellar-wg/ebml-specification",
=C2=A0 =C2=A0 > "ietf-cellar-wg/matroska-specification", "= ;FFmpeg/FFV1",
=C2=A0 =C2=A0 > "ietf-wg-cellar/Cellar-FLAC", "ietf-cella= r-wg/chair-notes" ], "topic":
=C2=A0 =C2=A0 > "CELLAR Activity Summary" } },

They should all be ietf-wg-cellar now.

And = now, they are!=C2=A0

Best,

Spencer=C2=A0
--000000000000bb45c405b9d8a065-- From nobody Sun Jan 31 00:01:14 2021 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 2172B3A03F3 for ; Sun, 31 Jan 2021 00:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=kTTDg9Kh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BtzuFqNb 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 meOc8604fNwp for ; Sun, 31 Jan 2021 00:01:11 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0783B3A03EC for ; Sun, 31 Jan 2021 00:01:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A886E6C2 for ; Sun, 31 Jan 2021 02:44:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 31 Jan 2021 02:44:11 -0500 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= fm1; bh=+NbKPeOOXmrj/wbUF1T0NBYRhIliULiGMU40o5FWXgw=; b=kTTDg9Kh Idd4/BMrOED0Php/25qfAMl0Q4J9LxQFdgRgz/uJGpyuqZXNUYAYIU4KSBSIpwa2 dySxcBtSIdC+un+yJ+W0aCl9NoMp9TBqC5q9QAdT0DW69baTpfdLwWuvFUY0Z6da 7odu3DrfrvvwDr+Txq5+Fre5Kk8KfCc9rTh1o1EDeDCmzFUW3ojRyej7oKI7OIwk 3/Hfv1F1DLCmU6Sc7WP8NYFy4b+KfpW9wqBvWUDIufKkIK/+DuVk+/P2bHPjE5iZ YN7xFW3oUp5IX6JvOmuhtqNLEv2B5yXsj4VrCYQlJ9hduqbOadbflajfwFJxrA0U 90kriDar14UGjg== 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=fm1; bh=+NbKPeOOXmrj/wbUF1T0NBYRhIliU LiGMU40o5FWXgw=; b=BtzuFqNb0f+u882GfMYfm2OuV3UNASGJJ/lN4Kn0mp8Pp 9YVRR60/I0EqU0izqUooIJxofdOs8adcN3BzLYzQS5u5PDYp4Ko/XDMIc/q01ewT yigX+OWRYtdGRHZhsewpJv+QAh4baat32m/QqwqML3likHsz5SrO+/h2zFm/Oo1g sp1igCho7MuJPp3o7x5oZ6G3p7AS9mIfH2VfWQVzB5Ajd12Evt4YCY4KdgD0JE8K 0Qu8P7ZuXVKGkWzPXdeFdggT+cMEjHosRsIY81/xwwdpcGu1HksrFchqeRLBLTB9 6kP/AdHVvKHdiz9CQSVbcQvAEzAcw9vZSr+69fPMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrdduieejrdduheeird dufeelnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59-841.internal.cloudapp.net (unknown [52.167.156.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 2AED324005A for ; Sun, 31 Jan 2021 02:44:11 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0648627112238471915==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210131074411.2AED324005A@mailuser.nyi.internal> Date: Sun, 31 Jan 2021 02:44:11 -0500 (EST) 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, 31 Jan 2021 08:01:13 -0000 --===============0648627112238471915== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-cellar/matroska-specification (+0/-1/=F0=9F=92=AC0) 1 issues closed: - clarify use of forced flag https://github.com/ietf-wg-cellar/matroska-s= pecification/issues/374 [clarifications] [spec_main]=20 * FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #230 section 3.8.1.2 needs to define get_rac (1 by michaelni) https://github.com/FFmpeg/FFV1/issues/230=20 Pull requests ------------- * ietf-wg-cellar/matroska-specification (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Improve track autoselection capabilities and documentation https://github.com/ietf-wg-cellar/matroska-specification/pull/447 [clar= ifications] [format addition] [spec_main]=20 * FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Correct typos in FFV1 definition https://github.com/FFmpeg/FFV1/pull/257=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-cellar/ebml-specification * https://github.com/ietf-wg-cellar/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-wg-cellar/Cellar-FLAC * https://github.com/ietf-wg-cellar/chair-notes --===============0648627112238471915== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday January 31, 2021

Events without label "editorial"

Issues

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

1 issues closed:

FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

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

1 pull requests merged:

FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

Repositories tracked by this digest:

--===============0648627112238471915==--