From nobody Sun Jun 6 02:06:16 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 1FF243A11BF for ; Sun, 6 Jun 2021 02:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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=R33klKwO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=am9HyLHu 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 8RGpDRgXkPN1 for ; Sun, 6 Jun 2021 02:06:04 -0700 (PDT) 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 AE69A3A11BD for ; Sun, 6 Jun 2021 02:06:03 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 98D9017C4 for ; Sun, 6 Jun 2021 04:19:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 06 Jun 2021 04:19:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm2; bh=s6vOu/x9jOk 7YI0QDeUVV+ORgYp5EjbQzsKFka30vf4=; b=R33klKwOZHGiXxQOfO47lMV8TGZ OtYuuxM9Pq0gciyaeVln0JRr0wSEfG0VZ+G8lYNNU1GIxOAtZXI0POjD9F2DhtFD rMlYoIHRV/6m3PmtptlmQbmiW04orMt1DBf5mxiSEyY6yt8O9QvTRdesSNcQX5mO XztS1rBsEC8kW8wmZC9cnX8qp3SNBZUaY39k3kkQt1+twdKn/Cpi05v5/+xGhUou NANdv1alz5EW81poXsBz8XYRsWXtouDJUz80JGjVUAa9vJSWWGlA/2oGTMs9dUio YvwWeB/FgBGfuckJtTVJHa5UOhQqnJU5xHrkvrFdJrDXutCw39Mwj+oGANg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=s6vOu/x9jOk7YI0QDeUVV+ORgYp5EjbQzsKFka30vf4=; b=am9HyLHu qw+x72lmXvjRdpeLBpspXLREW3V3UK/Es2/fnojIsxN6CzMX7Jz16Hd8yjut09+X ivzGKTwh4VBmqwwVEBCopiJivxXfDKbHfFZXxJjZMLaYqdUSGVGl0P1szFzJG8YG b3lfUXr9YKbH2BRtq1uZxb2ttOJrDYHqHnhdZqBkgDF2o9Kyhr8iikA7hTjrBGdP 60adTY+39OLIloN/o6zN1l8sQEzeyOFAHG+SZVWpyp8jQx0zk7iYJ3a+BczXtO/O QrVC0JaswUcNPdDlgiYBewOvGj8N0WzsYeb9Y9BuEeL7ndx/TWZUWfh64/8V3OzL vm/sI0JP3df91A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedthedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 6 Jun 2021 04:19:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6989119781436626906==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210606090603.AE69A3A11BD@ietfa.amsl.com> Date: Sun, 6 Jun 2021 02:06:03 -0700 (PDT) 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, 06 Jun 2021 09:06:12 -0000 --===============6989119781436626906== 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/ebml-specification (+0/-2/=F0=9F=92=AC6) 2 issues received 6 new comments: - #410 range attribute vs restriction element (1 by hubblec4) https://github.com/ietf-wg-cellar/ebml-specification/issues/410 [bug] [= errata-rfc8794]=20 - #409 Writing elements with a default value if the element can be multip= le (5 by hubblec4, mbunkus, robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/409 [clarif= ications] [errata-rfc8794]=20 2 issues closed: - Clarify the meaning of EBMLDocTypeVersion and EBMLDocTypeReadVersion ht= tps://github.com/ietf-wg-cellar/ebml-specification/issues/398 [bug] [errata= -rfc8794]=20 - DocType element default value https://github.com/ietf-wg-cellar/ebml-sp= ecification/issues/400 [bug] [errata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+0/-5/=F0=9F=92=AC4) 3 issues received 4 new comments: - #422 Consider providing a facility for integer-fraction timescales (2 b= y hubblec4, mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/issues/422 [cl= arifications] [format addition] [spec_main] [spec_tags]=20 - #419 Specify requirements around ReferenceBlock elements and how BlockG= roups signal random access points (1 by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/issues/419 [cl= arifications] [spec_main]=20 - #310 Non-mandatory elements with default values (1 by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/issues/310 [cl= arifications] [spec_main]=20 5 issues closed: - Should we make ChapterTimeEnd mandatory for ordered chapters ? https://= github.com/ietf-wg-cellar/matroska-specification/issues/470 [clarifications= ] [spec_main]=20 - Remove encryption elements that are not used https://github.com/ietf-wg= -cellar/matroska-specification/issues/45 [format addition] [spec_main]=20 - fix ChapterTimeEnd section https://github.com/ietf-wg-cellar/matroska-s= pecification/issues/478 [bug] [spec_main]=20 - Add the bogus TagDefault value in the RFC https://github.com/ietf-wg-ce= llar/matroska-specification/issues/508 [XML Schema] [format addition] [spec= _main]=20 - Non-mandatory elements with default values https://github.com/ietf-wg-c= ellar/matroska-specification/issues/310 [clarifications] [spec_main]=20 Pull requests ------------- * ietf-wg-cellar/ebml-specification (+0/-2/=F0=9F=92=AC0) 2 pull requests merged: - fix some inconsitencies with DocType(Read)Version names https://github.com/ietf-wg-cellar/ebml-specification/pull/405 [bug] [er= rata-rfc8794]=20 - remove bogus DocType default value https://github.com/ietf-wg-cellar/ebml-specification/pull/404 [bug] [er= rata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+1/-11/=F0=9F=92=AC12) 1 pull requests submitted: - makr SilentTracks as deprecated (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/516 [enha= ncement] [spec_main]=20 9 pull requests received 12 new comments: - #515 Remove range attribute from element with a (large) restriction sec= tion (2 by hubblec4, robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/515 [clar= ifications] [enhancement] [spec_main]=20 - #514 make ChapterDisplay use only one language at a time (2 by hubblec4= , robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/514 [bug]= [clarifications] [spec_main]=20 - #513 Expand the tocdepth to 4 (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/513 [form= atting]=20 - #511 move back the control track IDs in the main schema file (1 by hubb= lec4) https://github.com/ietf-wg-cellar/matroska-specification/pull/511 [XML = Schema] [build system]=20 - #499 Remove some default values/make some elements mandatory (1 by mbun= kus) https://github.com/ietf-wg-cellar/matroska-specification/pull/499 [XML = Schema] [clarifications] [spec_main]=20 - #487 Move the deprecated elements at the end of the specs (1 by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/pull/487 [form= atting] [spec_main]=20 - #481 add a stronger normative range for the ProjectionPose values (2 by= mbunkus, robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/481 [clar= ifications] [spec_main]=20 - #353 Add block additional mapping for generic type/value (1 by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/pull/353 [form= at addition] [spec_codecs]=20 - #115 info on storing/using font files in attachments (1 by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/pull/115 [clar= ifications] [spec_main]=20 11 pull requests merged: - make ChapterTimeEnd mandatory for ordered chapters https://github.com/ietf-wg-cellar/matroska-specification/pull/473 [clar= ifications] [spec_main]=20 - Deprecate internal signature on the content https://github.com/ietf-wg-cellar/matroska-specification/pull/491 [clar= ifications] [format addition] [spec_main]=20 - Clean chapterend section https://github.com/ietf-wg-cellar/matroska-specification/pull/504 [bug]= [spec_main]=20 - Add the 0x44B4 bogus TagDefault ID in the XSD https://github.com/ietf-wg-cellar/matroska-specification/pull/510 [XML = Schema] [format addition] [spec_main]=20 - Expand the tocdepth to 4 https://github.com/ietf-wg-cellar/matroska-specification/pull/513 [form= atting]=20 - tag TrackUID as preserved during stream copy using an extension https://github.com/ietf-wg-cellar/matroska-specification/pull/507 [XML = Schema] [build system] [clarifications] [spec_main]=20 - make some Video\Colour elements mandatory https://github.com/ietf-wg-cellar/matroska-specification/pull/502 [XML = Schema] [clarifications] [spec_main]=20 - remove default values from chapter examples https://github.com/ietf-wg-cellar/matroska-specification/pull/505 [clar= ifications] [spec_main]=20 - mark SilentTracks as deprecated https://github.com/ietf-wg-cellar/matroska-specification/pull/516 [enha= ncement] [spec_main]=20 - Make ordered chapters flag mandatory https://github.com/ietf-wg-cellar/matroska-specification/pull/457 [XML = Schema] [enhancement] [spec_main]=20 - Deprecate CodecDecodeAll https://github.com/ietf-wg-cellar/matroska-specification/pull/458 [enha= ncement] [spec_main]=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 --===============6989119781436626906== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 06, 2021

Events without label "editorial"

Issues

ietf-wg-cellar/ebml-specification (+0/-2/=F0=9F=92=AC6)

2 issues received 6 new comments:

2 issues closed:

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

3 issues received 4 new comments:

5 issues closed:

Pull requests

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

2 pull requests merged:

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

1 pull requests submitted:

9 pull requests received 12 new comments:

11 pull requests merged:

Repositories tracked by this digest:

--===============6989119781436626906==-- From nobody Tue Jun 8 13:00:54 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 0C2AA3A3BFD; Tue, 8 Jun 2021 13:00:52 -0700 (PDT) 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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162318245197.822.9104277550746178634@ietfa.amsl.com> Date: Tue, 08 Jun 2021 13:00:51 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 111 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: Tue, 08 Jun 2021 20:00:52 -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 111. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Jun 8 15:39:40 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 B75963A0D01 for ; Tue, 8 Jun 2021 15:39:39 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HB_aAmkfrdXo for ; Tue, 8 Jun 2021 15:39:34 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 AF62F3A0CFF for ; Tue, 8 Jun 2021 15:39:34 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id b13so32520924ybk.4 for ; Tue, 08 Jun 2021 15:39:34 -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=8XtGSYJfBwA+WgqfxehNCbVFP4j8zMe3k7BIq0nbLqk=; b=NcWH7Ddg/ZX9sio3zpPQfoPyauJML+sdOoVRvnDAa/Ym2I0MmW4TGJ+Y6r/uhPkXyM 6zZCNfy/lle0qiApJaeJdJom0kRTXcoXBh928sva4daWZiqQOasHOt8Y8LglXaECFgvs WQ7PsqP21aOeB1fHEIsVFNmFm/65ObExByVrUuTT7HVXvNfd+JlKxw1dBdU5O8FmeBWn VPoJ82o5o0Acsmo0LeQeM3HEIb6aUmlPSL7HZ1B33hHPJIdOEJ+7Je8CJDCRm98L65Pe PcFLfT6sgt0j50LS0vBhw2owI+fdcKBrZD2deLdxP744HoW7F1RcqJDGZyWyMP7cleDs IYTg== 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=8XtGSYJfBwA+WgqfxehNCbVFP4j8zMe3k7BIq0nbLqk=; b=kwkyYvMNRqfZsvx58QBcHbJlMA7wViRA0cuILBxum+4tmwNbtI2F3Bdx6WTJzo9//z 0LcZRkUiGR1cIEbo2kPw+MV5gMDVPgUivxQBzcGh50G7G7+xWnN67RrR4wY4q94iYH93 nCeWNWen/LA+CVeg8TFnMeP1T7pNDctDmVukoCWZ/3+DaYGTbaD4JL58ocxaJj2kIfBQ o3tiSRyHJ5HMlTiUL79gcqSuIuJfUnwfWQvzfrQlYS+CupsirYyXBLIuDaeE92LEW7eu hIbL8O+ULUOX0+wGh37JNGaNDdncxXDOWgynAa56DedpqyWQplekx69ewMF3AZJQd5pC lPqQ== X-Gm-Message-State: AOAM530V5W1+iiPasu9fu0rDibs1X0iJfri9XN4IUhDWUULqRSFs8OXo +htN1LgNlIhSqCQYLU/CwrZZPv9Apfetu36MWGfXcipaVtBTsA== X-Google-Smtp-Source: ABdhPJx6hjFMpPJ1Hxef1dxUZ8RKs/uJ54hyrMOFYBh+dqz5nJxFzkVAzLyd8XV03v4LCQmk3eOQmcdXCHVQERqeF9w= X-Received: by 2002:a25:86cf:: with SMTP id y15mr35570988ybm.389.1623191973082; Tue, 08 Jun 2021 15:39:33 -0700 (PDT) MIME-Version: 1.0 References: <87tumnrwz6.fsf@bunkus.online> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 8 Jun 2021 17:39:06 -0500 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000f53bb705c448d456" Archived-At: Subject: Re: [Cellar] IRC channel again 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, 08 Jun 2021 22:39:40 -0000 --000000000000f53bb705c448d456 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to follow up on this ... On Sun, May 30, 2021 at 1:42 AM Steve Lhomme wrote: > On 2021-05-28 12:09, Moritz Bunkus wrote: > > Hey, > > > > yeah, we talked about the IRC channel on Tuesday and decided to postpon= e > > the decision (or not to do anything at that point). Mostly people didn'= t > > have a strong opinion one way or the other. > > > > Over the last couple of days Freenode has cracked down on several hundr= ed > > channels, simply due to them having "libera.chat" in the topic. Not jus= t > on > > channels that actually planned to move, but also on channels that were > > simply thinking about moving or that did NOT in fact wanted to move and > > told their users via their topic. > > > > Cracking down means that a Freenode bot came in, renamed the channel, > > removed rights from existing ops, changed the topic and basically > archived > > the channel. They're seizing control of channels they have nothing to d= o > > with. > > > > Here are a couple of examples: > > > > > https://www.gentoo.org/news/2021/05/26/gentoo-freenode-channels-hijacked.= html > > https://mastodon.sdf.org/@kline/106299403921451814 > > > https://fridge.ubuntu.com/2021/05/26/announcing-ubuntus-move-to-libera-ch= at/ > > > > I find all of this highly offensive to a community of free/open source > > projects. > > > > Therefore I do have a strong opinion now: let's move our IRC to > > libera.chat, please. > > > > As all of you didn't have a strong opinion on Tuesday, I'll assume you'= re > > OK with that move. Unless someone objects by Sunday, I'll implement the > > move on Monday (closing the channel on Freenode, updating our web page)= . > > I support the move. This has become ridiculous. AFAIK Videolan is also > moving there. > > > Switching to other chat tools (XMPP/Jabber, Matrix=E2=80=A6) is a total= ly > different > > topic I'm not trying to tackle at this point; moving IRC is easy enough > to > > implement and somewhat time sensitive due to recent events. > We talked about this move at the last monthly meeting, and I'm not hearing objections, but this is something that the IETF wouldn't have an opinion about. We don't need to talk about it on our next agenda, do we? We'll let Moritz Do The RIght Thing, whatever that is ... Best, Spencer --000000000000f53bb705c448d456 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to follow up on this ...=C2=A0
=
On Sun= , May 30, 2021 at 1:42 AM Steve Lhomme <slhomme@matroska.org> wrote:
On 2021-05-28 12:09, Moritz Bunkus wrote:
> Hey,
>
> yeah, we talked about the IRC channel on Tuesday and decided to postpo= ne
> the decision (or not to do anything at that point). Mostly people didn= 't
> have a strong opinion one way or the other.
>
> Over the last couple of days Freenode has cracked down on several hund= red
> channels, simply due to them having "libera.chat" in the top= ic. Not just on
> channels that actually planned to move, but also on channels that were=
> simply thinking about moving or that did NOT in fact wanted to move an= d
> told their users via their topic.
>
> Cracking down means that a Freenode bot came in, renamed the channel,<= br> > removed rights from existing ops, changed the topic and basically arch= ived
> the channel. They're seizing control of channels they have nothing= to do
> with.
>
> Here are a couple of examples:
>
> https://www.gentoo= .org/news/2021/05/26/gentoo-freenode-channels-hijacked.html
> https://mastodon.sdf.org/@kline/1062994039214= 51814
> https://fridge.ubun= tu.com/2021/05/26/announcing-ubuntus-move-to-libera-chat/
>
> I find all of this highly offensive to a community of free/open source=
> projects.
>
> Therefore I do have a strong opinion now: let's move our IRC to > libera.chat, please.
>
> As all of you didn't have a strong opinion on Tuesday, I'll as= sume you're
> OK with that move. Unless someone objects by Sunday, I'll implemen= t the
> move on Monday (closing the channel on Freenode, updating our web page= ).

I support the move. This has become ridiculous. AFAIK Videolan is also
moving there.

> Switching to other chat tools (XMPP/Jabber, Matrix=E2=80=A6) is a tota= lly different
> topic I'm not trying to tackle at this point; moving IRC is easy e= nough to
> implement and somewhat time sensitive due to recent events.

We talked about this move at the last monthly mee= ting, and I'm not hearing objections, but this is something that the IE= TF wouldn't have an opinion about. We don't need to talk about it o= n our next agenda, do we?

We'll let=C2=A0Morit= z Do The RIght Thing, whatever that is ...=C2=A0

B= est,

Spencer=C2=A0
--000000000000f53bb705c448d456-- From nobody Wed Jun 9 00:51:49 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 283F33A1566 for ; Wed, 9 Jun 2021 00:51:38 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBtLh3DXm6kq for ; Wed, 9 Jun 2021 00:51:34 -0700 (PDT) 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 36C773A1531 for ; Wed, 9 Jun 2021 00:51:33 -0700 (PDT) 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 D1CD524000C; Wed, 9 Jun 2021 07:51:30 +0000 (UTC) Date: Wed, 9 Jun 2021 09:51:29 +0200 From: Michael Niedermayer To: Spencer Dawkins at IETF Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <20210609075129.GJ162012@pb2> References: <87tumnrwz6.fsf@bunkus.online> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1a+uSzIUoaGmLeog" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Cellar] IRC channel again 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, 09 Jun 2021 07:51:48 -0000 --1a+uSzIUoaGmLeog Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 08, 2021 at 05:39:06PM -0500, Spencer Dawkins at IETF wrote: [...] > We talked about this move at the last monthly meeting, and I'm not hearing > objections, but this is something that the IETF wouldn't have an opinion > about. We don't need to talk about it on our next agenda, do we? >=20 > We'll let Moritz Do The RIght Thing, whatever that is ... I suggest that a link to the IRC channel is added at some central place, i was not aware that cellar has or had an IRC channel thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives.= =20 -- Abba Eban --1a+uSzIUoaGmLeog Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYMBy/QAKCRBhHseHBAsP q1FSAJ4oNKUCMMeGPcte9goXcdOj/9kxQgCdF5uS0L/0NRLR1wllyTTlncLadhY= =A/G4 -----END PGP SIGNATURE----- --1a+uSzIUoaGmLeog-- From nobody Wed Jun 9 00:56:08 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 0C5503A1558 for ; Wed, 9 Jun 2021 00:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.395 X-Spam-Level: X-Spam-Status: No, score=0.395 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, FROM_SUSPICIOUS_NTLD=0.498, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online 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 cDC_WO3kXldL for ; Wed, 9 Jun 2021 00:56:02 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [144.76.140.85]) (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 39A3E3A1557 for ; Wed, 9 Jun 2021 00:56:02 -0700 (PDT) Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [192.168.191.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: email-relay) by liselle.bunkus.org (Postfix) with ESMTPSA id AC4B011F2324; Wed, 9 Jun 2021 09:55:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1623225358; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J3SUanctEV4J3iWpnlfj4N1273qA2e44hPHFKgT8P10=; b=eYSHROrPKOiSuIFwABViZj/S912wfpNUhVHux0YagWBQjZERIN5nGHpe0VCiHTjubDT9c4 51Q/RgCydnr6BlZkMj27Hjx/neI5Vq44vNeU+5ngKkj7U5PDgBUizSfKJmUAmN5o3ZimvU U7CWD9HxRyAydnvfaLPzR3Gid6FN3Lo= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 5F2BA63490CB; Wed, 9 Jun 2021 09:55:58 +0200 (CEST) References: <87tumnrwz6.fsf@bunkus.online> <20210609075129.GJ162012@pb2> User-agent: mu4e 1.4.15; emacs 27.2 From: Moritz Bunkus To: Michael Niedermayer Cc: Spencer Dawkins at IETF , Steve Lhomme , cellar@ietf.org In-reply-to: <20210609075129.GJ162012@pb2> Message-ID: <87r1hb8oa9.fsf@bunkus.online> Date: Wed, 09 Jun 2021 09:55:58 +0200 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] IRC channel again 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, 09 Jun 2021 07:56:07 -0000 Hey, this was about the #matroska IRC channel, not a CELLAR-specific one. We did move the #matroska channel, and no, I don't think this is something that we still need to talk about at our next meeting. Kind regards, mosu From nobody Wed Jun 9 01:04:59 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 0EFCA3A15B8 for ; Wed, 9 Jun 2021 01:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 piMO4LmM5xqm for ; Wed, 9 Jun 2021 01:04:55 -0700 (PDT) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27573A15B4 for ; Wed, 9 Jun 2021 01:04:54 -0700 (PDT) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay12.mail.gandi.net (Postfix) with ESMTPSA id C43D8200008; Wed, 9 Jun 2021 08:04:50 +0000 (UTC) Date: Wed, 9 Jun 2021 10:04:49 +0200 From: Michael Niedermayer To: Moritz Bunkus Cc: cellar@ietf.org, Spencer Dawkins at IETF , Steve Lhomme Message-ID: <20210609080449.GK162012@pb2> References: <87tumnrwz6.fsf@bunkus.online> <20210609075129.GJ162012@pb2> <87r1hb8oa9.fsf@bunkus.online> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6DpgemkcHclpK+A" Content-Disposition: inline In-Reply-To: <87r1hb8oa9.fsf@bunkus.online> Archived-At: Subject: Re: [Cellar] IRC channel again 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, 09 Jun 2021 08:04:58 -0000 --d6DpgemkcHclpK+A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2021 at 09:55:58AM +0200, Moritz Bunkus wrote: > Hey, >=20 > this was about the #matroska IRC channel, not a CELLAR-specific one. We d= id > move the #matroska channel, and no, I don't think this is something that = we > still need to talk about at our next meeting. ok, i misunderstood, that explains why i didnt know about the channel ;) i wondered, would a cellar specific IRC channel make sense ? not saying that i suggest one should be created, it was just a thought ... thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. --d6DpgemkcHclpK+A Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYMB2HQAKCRBhHseHBAsP q0w1AJwKC9UDLMesLqEi7XBsxngfgGs5WwCgjjg75bIuXh2B23hdv2gzXvuBBzo= =5iy7 -----END PGP SIGNATURE----- --d6DpgemkcHclpK+A-- From nobody Fri Jun 11 14:32: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 A56A33A0BD9 for ; Fri, 11 Jun 2021 14:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mNZaAjLPyAm7 for ; Fri, 11 Jun 2021 14:32:02 -0700 (PDT) Received: from mailfish.xiph.org (mailfish.xiph.osuosl.org [140.211.166.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2452D3A0BD7 for ; Fri, 11 Jun 2021 14:32:02 -0700 (PDT) Received: from [172.17.0.87] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) by mailfish.xiph.org (Postfix) with ESMTPSA id 771DB9FCC4 for ; Fri, 11 Jun 2021 21:32:01 +0000 (UTC) To: cellar@ietf.org From: "Timothy B. Terriberry" Message-ID: <1dee863c-3589-21f6-da13-db5beee25d8a@xiph.org> Date: Fri, 11 Jun 2021 14:31:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------0472CE6E14E8C375D9A30EF2" Archived-At: Subject: [Cellar] Timestamps again 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: Fri, 11 Jun 2021 21:32:05 -0000 This is a multi-part message in MIME format. --------------0472CE6E14E8C375D9A30EF2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello CELLAR friends, Michael Richardson asked me to review draft-cellar-matroska, which has been taking me longer than I had hoped, but I am making progress. However, I did run across one issue that might require some discussion on the list to resolve, so I thought I would send it sooner rather than later. Namely, I was skeptical that the procedures outlined in Section 26.5 would be able to reversibly translate between audio sample numbers and scaled timestamps. So I wrote a program to check. I set up the program to evaluate all audio sample rates between 8 kHz and 192 kHz in units of 1 Hz, and for each sample rate to check all sample numbers between 0 and the product of the sample rate and the TimestampScale, divided by the gcd of that number with 1,000,000,000 (basically, for this number, all of the divisions are exact, and beyond that number the remainders should repeat). This is actually quite a lot of cases to check exhaustively and would take quite a long time to complete. However, it may be able to generate counter-examples very quickly. I checked both strategies outlined in the text: (a) Truncate TimestampScale and round all other divisions, and (b) Use a slightly smaller TimestampScale and truncate the division in the raw to absolute timestamp conversion (as suggested in paragraph 5). In fact, the program (attached), was able to find counter examples for both strategies very quickly. For strategy (a), since 8,000 divides 1,000,000,000 exactly (giving a TimestampScale of 125,000), all of the divisions for all sample numbers are exact (whether or not you round), and everything is fine. However, the first counter example was found for 8,001 Hz (where the TimestampScale is 124,984), with sample number 165,781. The raw timestamp computed in the muxer is thus (1,000,000,000*165,781 + 4000)/8001 = 20,720,034,996 ns. The absolute timestamp is then (20,720,034,996 + 62,492)/124,984 = 165,782. This is approximately the same as the sample number, which given the choice of TimestampScale, is to be expected, and is in fact the first sample number where the match is not exact. However, the absolute timestamp computed in the Reader becomes 165,782*124,984 = 20,720,097,488 ns. This produces a sample number of (20,720,097,488*8,001 + 500,000,000)/1,000,000,000 = 165,782. This is off by one (in the positive direction) from the original. For strategy (b), the first counter example was for 8 kHz (where the "slightly smaller" TimestampScale is 124,999), with sample number 62,501. The raw timestamp computed in the muxer is thus (1,000,000,000*62,501 + 4000)/8000 = 7,812,625,000 ns. The absolute timestamp is then (7,812,625,000 + 62,499)/124,999 = 62,501. Here the match with the sample number is still exact. However, the raw timestamp computed in the Reader becomes 62,501*124,999 = 7,812,562,499 ns. This produces a sample number of (7,812,562,499*8,000 + 500,000,000)/1,000,000,000 = 62,500. This is also off by one from the original, but in the negative direction. I have attached the program's source code so that you can check whether or not I made any mistakes and modify the parameters to generate your own counter-examples (or test approaches to resolving the issue). --------------0472CE6E14E8C375D9A30EF2 Content-Type: text/x-csrc; name="checkmkvtime.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="checkmkvtime.c" #include #include long long sample_to_raw(long long r, long long n) { return (1000000000LL*n + (r >> 1))/r; } long long raw_to_absolute_always_round(long long s, long long t) { return (t + (s >> 1))/s; } long long raw_to_absolute_truncate(long long s, long long t) { return t/s; } long long absolute_to_raw(long long s, long long t) { return t*s; } long long raw_to_sample(long long r, long long t) { return (t*r + 500000000LL)/1000000000LL; } long long gcd(long long a, long long b) { while (b) { long long d; d = a % b; a = b; b = d; } return a; } int main(void) { long long r; for (r = 8000; r < 192000; r++) { long long s1; long long s2; long long m; long long n; s1 = 1000000000LL/r; s2 = s1 - 1; #if !defined(SKIP_ALWAYS_ROUND_CHECK) m = r*s1/gcd(r*s1, 1000000000LL); for (n = 0; n < m; n++) { long long t_r; long long t_a; long long n2; t_r = sample_to_raw(r, n); t_a = raw_to_absolute_always_round(s1, t_r); t_r = absolute_to_raw(s1, t_a); n2 = raw_to_sample(r, t_r); if (n != n2) { fprintf(stderr,"Sample rate: %lli TimestampScale: %lli " "Sample in: %lli Absolute: %lli Sample out: %lli\n", r, s1, n, t_a, n2); return EXIT_FAILURE; } } #endif #if !defined(SKIP_TRUNCATE_CHECK) m = r*s2/gcd(r*s2, 1000000000LL); for (n = 0; n < m; n++) { long long t_r; long long t_a; long long n2; t_r = sample_to_raw(r, n); t_a = raw_to_absolute_truncate(s2, t_r); t_r = absolute_to_raw(s2, t_a); n2 = raw_to_sample(r, t_r); if (n != n2) { fprintf(stderr,"Sample rate: %lli TimestampScale 2: %lli " "Sample in: %lli Absolute: %lli Sample out: %lli\n", r, s2, n, t_a, n2); return EXIT_FAILURE; } } #endif fprintf(stderr, "Finished sample rate %lli.\n", r); } return EXIT_SUCCESS; } --------------0472CE6E14E8C375D9A30EF2-- From nobody Sat Jun 12 08:33:44 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 F17973A173B for ; Sat, 12 Jun 2021 08:33:42 -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 o04qLi6RzQ_4 for ; Sat, 12 Jun 2021 08:33:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267203A14D2 for ; Sat, 12 Jun 2021 08:33:38 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [142.169.78.42]) by relay.sandelman.ca (Postfix) with ESMTPS id C60E41F47B; Sat, 12 Jun 2021 15:33:36 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 746AD1A0D1B; Sat, 12 Jun 2021 11:33:35 -0400 (EDT) From: Michael Richardson To: Dave Rice , cellar@ietf.org In-reply-to: References: <31695.1623507191@dooku> Comments: In-reply-to Dave Rice message dated "Sat, 12 Jun 2021 10:24:34 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sat, 12 Jun 2021 11:33:35 -0400 Message-ID: <34407.1623512015@dooku> Archived-At: Subject: [Cellar] auth48 coordination of XML files 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: Sat, 12 Jun 2021 15:33:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Rice wrote: >>>> So I think you might be working too hard here. >>=20 >>> Could you clarify: is it the work itself or the efficiency of the w= ork >>> that you=E2=80=99re commenting upon? >>=20 >> efficiency: I think that you might be causing yourself undo pain. > Mind if we move this conversation back on list?I=E2=80=99m happy to s= tep back > from this but would prefer this conversation occur with the other > authors. Yes. The RFC editor has FFV1 in AUTH48. They have edited our *XML* directly to put it into their format, which ignores our history of creating it via mmark and some of the table driven efforts. Dave seemed to trying to bring our XML (via mmark) into sync with what the RFC-editor was doing. I worried that Dave was expending a lot of effort here. Most WGs do not attempt to bring their "source" code inline with what the RFC-editor produces. The XML goes into the RFC-editor, and is transformed, and that's that. For WGs that have edited in XML, one can get the XML from from the rfc-edit= or at the end, and just go with that if one will do a "bis" in a few years. Dave pointed out that the things that the editor was doing would also apply to ffv1-v4! Ah, I say, GOOD POINT. >> Most drafts, once they are with the RFC editor, are no longer mainta= ined in >> git. (although i've argued that the rfc-editor should be sending a = pull >> request back to authors, that isn't happening yet). > I would like some consensus on this. We=E2=80=99ve been working with = a shared > base for the two documents nearly back to the working groups origins. I would say that at this point, the ffv1 (not-v4) direction is dead. We shouldn't think that we can make changes that matter to that direction. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmDE088ACgkQlUzhVv38 QpAKDwf/R9zHE9DRZb9Xk5IYd4JQaF5FM5fEWnHc/E35V8VQuO1m7RiNvrQCsjXq SILWpTwbw9aCTH51lsusCFkrrVbOsgutdkjhfB+BlFCuxvRGizZF/E7DY8TJnSp2 7hGwjNsPbujD0B0nk81Wh+7z7BrhTbrt6lxRO4/DlqxkUmTrzW/mJhkc9bvBQDJh bl5WTnPRsUzetTOJVaFx5Ug/LJ06KpsijKhXhkpberag6GRS/2Dj/hmrbs9nLE1Y USbYY1d7cD9XR0E45ojpSyswuUg7cCLsG11a8eHJsY10zqaumDWOvlexrmRNKSn0 07Le8eNX0ies99XPESte52qE9xrbqg== =/y2l -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jun 12 10:09:50 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 BFA963A1A27 for ; Sat, 12 Jun 2021 10:09:48 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 83No1S2nRSLz for ; Sat, 12 Jun 2021 10:09:44 -0700 (PDT) Received: from 2.mo7.mail-out.ovh.net (2.mo7.mail-out.ovh.net [87.98.143.68]) (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 B87CD3A1A31 for ; Sat, 12 Jun 2021 10:09:44 -0700 (PDT) Received: from player158.ha.ovh.net (unknown [10.110.208.83]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 36DEC1A6607 for ; Sat, 12 Jun 2021 19:09:36 +0200 (CEST) Received: from mediaarea.net (p548f9ee4.dip0.t-ipconnect.de [84.143.158.228]) (Authenticated sender: jerome@mediaarea.net) by player158.ha.ovh.net (Postfix) with ESMTPSA id 912851F0D50A5 for ; Sat, 12 Jun 2021 17:09:35 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-99G003670e9fca-bc77-4933-92df-18641336e4d4, 6367603D4FC665895053F61D1C6A37999B1F65BA) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.158.228 To: cellar@ietf.org References: <31695.1623507191@dooku> <34407.1623512015@dooku> From: Jerome Martinez Message-ID: Date: Sat, 12 Jun 2021 19:09:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <34407.1623512015@dooku> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 16883713532130889873 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfedvtddguddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhephfeludekvdeihfeugfeluddtfeeffeehffejteetgeevgeetkeehtdffvefhheeinecukfhppedtrddtrddtrddtpdekgedrudegfedrudehkedrvddvkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhduheekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] auth48 coordination of XML files 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: Sat, 12 Jun 2021 17:09:49 -0000 On 12/06/2021 17:33, Michael Richardson wrote: > Dave pointed out that the things that the editor was doing would also apply > to ffv1-v4! Ah, I say, GOOD POINT. > [...] > I would say that at this point, the ffv1 (not-v4) direction is dead. IMO the comments from auth48 are relevant for the quality of the FFV1 doc whatever is the version, and FFV1 v0-v3 doc may be dead, but our doc is actually unique, mixing all versions together, so the change Dave is making is mainly for v4, and the v0-v3 "automatic backport" is only a side effect. Advantage of putting auth48 changes in our working version is that theses changes will not have to be made again when we push the v4 version, and our working copy of v4 is in a better shape. It also permits to talk about the changes in public, maybe we could catch some other similar issues. For theses reasons, I second the work of bringing auth48 changes back in our working version. That said, it does not have to block the RFC publication, it is in parallel. Jérôme From nobody Sun Jun 13 00:39:40 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 5E34E3A0D3A for ; Sun, 13 Jun 2021 00:39:32 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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=sRHUmvJ/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aJ2ir8Ht 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 LPLAuswP3fd4 for ; Sun, 13 Jun 2021 00:39:29 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218053A0D35 for ; Sun, 13 Jun 2021 00:39:29 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 40A2410DD for ; Sun, 13 Jun 2021 03:39:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sun, 13 Jun 2021 03:39:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=497fJPTdGi9 kBg/NVLGeLvy13Jm261guSV1Am8kNrfc=; b=sRHUmvJ/W47jeAwpNcRsNglqG1K AATM2Mv8ZNX222ssEhWyxPqwArE3B/V6Ax0vpPDtnNIneKUUkwT+WdeuWYL+A+hX XF81ymvg88d5aY4E/lZjLDHtTUWWvAKvgs76NPmbqKwPXpExZDx3lajqmguR/8lE uG+2bOH/TQfgoFwHoHs28mSxjTMLv8iuz/chzj6ZGqt5PXLI4M3rWSRXuNygs3eX K5HTTWjaJFx95D3c0g8t4P+GGlK5yIrI6eoEHjRqtgnu6fA9/HEUEQcLfw1UXSzE TperQlu6HsdNbVXKr5FQ9irkWkjBpu8tJ6FUzUQR8Y8aCLNoYM3ExhuvrbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=497fJPTdGi9kBg/NVLGeLvy13Jm261guSV1Am8kNrfc=; b=aJ2ir8Ht JsXZJieEPfg8MqYV9VjXu9X/Mf3fdAC72HJkJ8ZLZN2ykZ6CqxvlTgrDcLcfuwgd pkVsDQOc0MNkb0Dt+KotkDDbbTLeWn4fkojv2h8IrQdiIS1zU1o7tpBBGsyYyvwN ap6tisLq8ACIJRzOBnyXWg0LVMYv/K6TQDHDl5jnu3aKMiHgEzLWINv/oieeGZOP ts3m0wyKQXv5UuKg1eZ8X2ak2ica01P02uMhG0sKu4GEwjXyxlp8JbU6VkGdOGgb VINOuIzCsnlFRn5cpEKxzHUp2lptAt6J846Oq5H4ytHTkUFazancEslc+1dqtmGk WODSTCWJx+FUZg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedvvddgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 13 Jun 2021 03:39:24 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============6407947304401279552==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210613073929.218053A0D35@ietfa.amsl.com> Date: Sun, 13 Jun 2021 00:39:29 -0700 (PDT) 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, 13 Jun 2021 07:39:39 -0000 --===============6407947304401279552== 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/ebml-specification (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #409 Writing elements with a default value if the element can be multip= le (2 by hubblec4, robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/409 [clarif= ications] [errata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+0/-1/=F0=9F=92=AC2) 1 issues received 2 new comments: - #104 Explain why ChapLanguage and ChapCountry are multiple (2 by hubble= c4, robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/104 [cl= arifications] [spec_main]=20 1 issues closed: - Reference deprecated IDs separately https://github.com/ietf-wg-cellar/m= atroska-specification/issues/305 [enhancement] [format extension] [spec_mai= n]=20 Pull requests ------------- * ietf-wg-cellar/ebml-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #406 add a minver attribute to enum values (1 by hubblec4) https://github.com/ietf-wg-cellar/ebml-specification/pull/406 [clarific= ations] [format addition]=20 * ietf-wg-cellar/matroska-specification (+0/-3/=F0=9F=92=AC3) 3 pull requests received 3 new comments: - #514 make ChapterDisplay use only one language at a time (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/514 [bug]= [clarifications] [spec_main]=20 - #487 Move the deprecated elements at the end of the specs (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/487 [form= atting] [spec_main]=20 - #481 add a stronger normative range for the ProjectionPose values (1 by= robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/481 [clar= ifications] [spec_main]=20 3 pull requests merged: - Remove range attribute from element with a (large) restriction section https://github.com/ietf-wg-cellar/matroska-specification/pull/515 [clar= ifications] [enhancement] [spec_main]=20 - Move the deprecated elements at the end of the specs https://github.com/ietf-wg-cellar/matroska-specification/pull/487 [form= atting] [spec_main]=20 - Remove some default values/make some elements mandatory https://github.com/ietf-wg-cellar/matroska-specification/pull/499 [XML = Schema] [clarifications] [spec_main]=20 * FFmpeg/FFV1 (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - Auth48 changes (by dericed) https://github.com/FFmpeg/FFV1/pull/264=20 1 pull requests received 2 new comments: - #264 Auth48 changes (2 by dericed, retokromer) https://github.com/FFmpeg/FFV1/pull/264=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 --===============6407947304401279552== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 13, 2021

Events without label "editorial"

Issues

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

1 issues received 2 new comments:

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

1 issues received 2 new comments:

1 issues closed:

Pull requests

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

1 pull requests received 1 new comments:

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

3 pull requests received 3 new comments:

3 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 2 new comments:

Repositories tracked by this digest:

--===============6407947304401279552==-- From nobody Sun Jun 13 01:08:13 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 3A7C63A0E91 for ; Sun, 13 Jun 2021 01:08:12 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 8U4MQmS30Pyi for ; Sun, 13 Jun 2021 01:08:09 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 9C6A63A0E8D for ; Sun, 13 Jun 2021 01:08:09 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id l1so11184217ejb.6 for ; Sun, 13 Jun 2021 01:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=gTqN6mT6lobsPNP5/QXz2aPGj4XBNCKn8b6VODlZTIc=; b=hCt3YU41QUjvJ+lkBSqc/Bx6sqK46WJhGrZRb+3tcTQU96E8KHHr+2A3EPyEg6ZrjO UrIunmjzRjYuysRM04xJ7VoEneqdq8Jkqne45JS3anMv+Wt/x7elhNCeEocZP3LRVwE6 l9/87WF6F1P6H7t3X6FgCl7TpR/cMxDiyDa0vDfaGFQndQLVN8MW/c7SxmkZEA9PKCx9 qP/sdeSjib98NPaAVnJpN4Z/eM73FSHXQe4QS0a8t/HeKsXHkD6fw+E62XNxmsQ+gVV0 Ggc2cs6fvU+4LvInVvXijiqB/EKi/WipbhA69IDBTwDHcWWXDALDchDDjabynyUQakPT w6mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gTqN6mT6lobsPNP5/QXz2aPGj4XBNCKn8b6VODlZTIc=; b=FltAofZ1eETZHKBOh2C8YdWDg7fI/UBb0Hg7hDq9oEjYAPkV8g7Kto4SNqXEs4gX1X vtwtVzurH0Kay42i52/o0og3x61e+PliO1HCRiGo7VIny/MHvdOAmYNXLymdvKrpVExI K8pdtwEEo7vSJGu5NxnGqzhY2f/UctmY3imi3Bw/6FDg8jT+b7xqd5YMOMXizWz5nrWk wbvRTXlFH04lJyff6+e4iic0+bXggutFNdeqAyTw2Bqs7/ihU85Xhzm7jmrSXQUXZv4N J4o/4dDcWFy+EIkNS8HrQxDf3lC/iIUk00B6AHeSA7906rIGK9TD+DBc5Sl/OAxZZYK1 iiIw== X-Gm-Message-State: AOAM5335d/Knuq2mpRQVL3/QyuNcP1a+J0A7RH0be5tCBedS2gQbQk5J QgwhFkgIznN7V/Y3WH0I/6k/U2b1l4gfBzxx X-Google-Smtp-Source: ABdhPJz33QVMWiZ1cQ+tHVMyhlcnL/IDhrQoC/PMf83A3VHqEpFzPXY7d7M2nqKc80AF75IrKwItcA== X-Received: by 2002:a17:907:2709:: with SMTP id w9mr10673965ejk.118.1623571687100; Sun, 13 Jun 2021 01:08:07 -0700 (PDT) Received: from ?IPv6:2a01:cb0c:20:e900:dcd5:90f3:761:feff? (2a01cb0c0020e900dcd590f30761feff.ipv6.abo.wanadoo.fr. [2a01:cb0c:20:e900:dcd5:90f3:761:feff]) by smtp.gmail.com with ESMTPSA id f20sm5185327edq.64.2021.06.13.01.08.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 01:08:06 -0700 (PDT) To: cellar@ietf.org References: <1dee863c-3589-21f6-da13-db5beee25d8a@xiph.org> From: Steve Lhomme Message-ID: <524efcdc-c93e-1b3c-71b5-d10e1e11509c@matroska.org> Date: Sun, 13 Jun 2021 10:08:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <1dee863c-3589-21f6-da13-db5beee25d8a@xiph.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Timestamps again 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, 13 Jun 2021 08:08:12 -0000 On 2021-06-11 23:31, Timothy B. Terriberry wrote: > Hello CELLAR friends, Hi Tim, > Michael Richardson asked me to review draft-cellar-matroska, which has = > been taking me longer than I had hoped, but I am making progress.=20 > However, I did run across one issue that might require some discussion = > on the list to resolve, so I thought I would send it sooner rather than= =20 > later. >=20 > Namely, I was skeptical that the procedures outlined in Section 26.5=20 > would be able to reversibly translate between audio sample numbers and = > scaled timestamps. So I wrote a program to check. I think this section is outdated. This is still an ongoing subject as we = tried to have some form of sample accuracy in Matroska. See the (lenghty) discussion at issue 422 [1]. One possibility is to use the existing TrackTimestampScale element which = wasn't designed for that but works pretty well. It's backward compatible = although there is a high chance a lot of readers don't handle it properly= =2E A more solid solution would be to write the proper sampling rate of the=20 source (but that becomes complicated in case of Variable Frame Rate as=20 found nowadays in video games). > I set up the program to evaluate all audio sample rates between 8 kHz=20 > and 192 kHz in units of 1 Hz, and for each sample rate to check all=20 > sample numbers between 0 and the product of the sample rate and the=20 > TimestampScale, divided by the gcd of that number with 1,000,000,000=20 > (basically, for this number, all of the divisions are exact, and beyond= =20 > that number the remainders should repeat). This is actually quite a lot= =20 > of cases to check exhaustively and would take quite a long time to=20 > complete. However, it may be able to generate counter-examples very=20 > quickly. >=20 > I checked both strategies outlined in the text: > (a) Truncate TimestampScale and round all other divisions, and > (b) Use a slightly smaller TimestampScale and truncate the division in = > the raw to absolute timestamp conversion (as suggested in paragraph 5).= >=20 > In fact, the program (attached), was able to find counter examples for = > both strategies very quickly. >=20 > For strategy (a), since 8,000 divides 1,000,000,000 exactly (giving a=20 > TimestampScale of 125,000), all of the divisions for all sample numbers= =20 > are exact (whether or not you round), and everything is fine. However, = > the first counter example was found for 8,001 Hz (where the=20 > TimestampScale is 124,984), with sample number 165,781. >=20 > The raw timestamp computed in the muxer is thus > =C2=A0 (1,000,000,000*165,781 + 4000)/8001 =3D 20,720,034,996 ns. > The absolute timestamp is then > =C2=A0 (20,720,034,996 + 62,492)/124,984 =3D 165,782. > This is approximately the same as the sample number, which given the=20 > choice of TimestampScale, is to be expected, and is in fact the first=20 > sample number where the match is not exact. However, the absolute=20 > timestamp computed in the Reader becomes > =C2=A0 165,782*124,984 =3D 20,720,097,488 ns. > This produces a sample number of > =C2=A0 (20,720,097,488*8,001 + 500,000,000)/1,000,000,000 =3D 165,782.= > This is off by one (in the positive direction) from the original. >=20 > For strategy (b), the first counter example was for 8 kHz (where the=20 > "slightly smaller" TimestampScale is 124,999), with sample number 62,50= 1. >=20 > The raw timestamp computed in the muxer is thus > =C2=A0(1,000,000,000*62,501 + 4000)/8000 =3D 7,812,625,000 ns. > The absolute timestamp is then > =C2=A0 (7,812,625,000 + 62,499)/124,999 =3D 62,501. > Here the match with the sample number is still exact. However, the raw = > timestamp computed in the Reader becomes > =C2=A0 62,501*124,999 =3D 7,812,562,499 ns. > This produces a sample number of > =C2=A0 (7,812,562,499*8,000 + 500,000,000)/1,000,000,000 =3D 62,500. > This is also off by one from the original, but in the negative directio= n. I think the TrackTimecodeScale solves both these examples, because it=20 using a floating point estimation before rounding the numbers. It allows = finer granularity for each sample. For audio-only files it's even=20 clearer because no matter what the TimestampScale you pick, the=20 TrackTimecodeScale is directly related to the sampling frequency, in=20 floating point. The drawback is that the samples are accurate per packed blocks of data, = then it's up to the decoder to determine the timestamp for each sample=20 in a packed block. I made a program [2] to check the tricky cases where a mixing of track=20 types/frequency forces some compromise on the TimestampScale and thus on = the rounding precision. I ran it with 8001 Hz and there is no error on=20 each possible tick of a Cluster, no matter the video frequency. As seen in this libavformat patch [3], the TrackTimecodeScale is=20 TimestampScale * FrameRate. This is very different than what is=20 explained in section 26.5 and 26.6 (which are now 27.5 and 27.6) where=20 it's normally around 1. I think both sections have to be rewritten to=20 clarify this (issue #517 [4]). Both the old way of using=20 TrackTimecodeScale and the new way should be mentioned since old files=20 may use the old way, although on the player side it will make no differen= ce. A big side note: this method cannot work in WebM because it doesn't have = TrackTimecodeScale. Using a rationale number would also not work there=20 as it would not supported. So we need to cover both methods in our=20 explanations. I think we should explain the possibilities and limits of both methods=20 (with and without TrackTimecodeScale) when solving issue #517. Both when = muxing and demuxing to explain what rounding should be used. > I have attached the program's source code so that you can check whether= =20 > or not I made any mistakes and modify the parameters to generate your=20 > own counter-examples (or test approaches to resolving the issue). [1] https://github.com/ietf-wg-cellar/matroska-specification/issues/422 [2]=20 https://github.com/robUx4/matroska-specification/blob/timestampscale-chec= k/fraction_timestamp.c [3]=20 https://github.com/FFmpeg/FFmpeg/compare/master...robUx4:tracktimestampsc= ale/0 [4] https://github.com/ietf-wg-cellar/matroska-specification/issues/517 From nobody Wed Jun 16 16:59: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 EF1A43A0DD5 for ; Wed, 16 Jun 2021 16:59:16 -0700 (PDT) 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 8thOGkIsjn1e for ; Wed, 16 Jun 2021 16:59:15 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 C5D1A3A0DA5 for ; Wed, 16 Jun 2021 16:59:14 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id i4so5555839ybe.2 for ; Wed, 16 Jun 2021 16:59:14 -0700 (PDT) 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=gK9FVdSeBQds9hD4EkTdHjYjDzVOXMxfW2g3FD8Q+5A=; b=jOE1oVAb2IAng+3OmfR0+mwTZmb303MwsHnW/IceuAanFTYBpW948JEV3JXSp8YKJ+ zWl+ySk8jrrwdVasP9HVVaZVze61pxNa9K0C3Nzj8OQijWiY/Br06xfZDJ6unvMO72ER uY9M1SXLXQUVtL3ZMCy9qsfGTiNKXILjRns7rxDW/9aBpVQ/L6pGbIK44P1aplbZdF3v nlr+7VT4pfuacJDVhoHTJKd1rCGtA0oaLe7xnRz5YF7Q4q/jGAiw+OsNZUEYFBjD9JvE 9vPdoOt9T6o81VlDYrk7Za5WbddBdAzyXG7kCLqF0V+1/JwGwXBCt2J7G1ey2TrNiv+v pu9A== 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=gK9FVdSeBQds9hD4EkTdHjYjDzVOXMxfW2g3FD8Q+5A=; b=sGzY/nIMaQOsHIlGb14SkxeqoHy/BS6x0Pk72U/ejSEH1sM/PwX3RHz+kq3bM69oP/ hXRjxVks1hQw/gmcZMspsmqlD5vTr2EOU7Xtjxx27kFiZNnmVGaMs1V9nG+2E5JdVYmE IVfA1Hqs8zNy97kWeMJx6w5bNc86gQ+y00JCv9/oNr2LnncPqLQcPheVRb3h/QxgviJg 2oojcN5483KaQCS7e7wp9MMzBa2R5MxCbItcs7YeEsAYZC1s3f5Gl9Z+LWd7pf68BZOH SPTEyv37Kgevt7q9KEMWF0AIm0FFG1yibCPF5SLxgj336G4NQio0j1karLusSctjf5p8 I6Hg== X-Gm-Message-State: AOAM5333IaDSYwCpiegqd4BfpGw11i/BtimEDXBE87C+fgxfJIaX8u3y t1380RqvI7Z/tsrww/2gAWvQcGc5UPvcEkFeLSjmHqKr+iiaBA== X-Google-Smtp-Source: ABdhPJwXIMeadvQULPPzG2g/Uj8vKReRQbvuQZsoB5Y6XG8clzlbciR4NVLtNe8bjp4OhUI7j8C495W3tht6HOLS6ks= X-Received: by 2002:a25:844f:: with SMTP id r15mr2306697ybm.297.1623887952487; Wed, 16 Jun 2021 16:59:12 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Wed, 16 Jun 2021 18:58:41 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000902ae505c4eae05f" Archived-At: Subject: [Cellar] Special agenda topics for our Cellar meeting on June 22? 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, 16 Jun 2021 23:59:26 -0000 --000000000000902ae505c4eae05f Content-Type: text/plain; charset="UTF-8" Dear Cellar, I am assuming that we'll need some agenda time to talk about any remaining questions/changes for draft-ietf-cellar-ffv1, currently in AUTH48 with the RFC Editor. Are there other topics that I need to put at the head of the agenda? Best, Spencer --000000000000902ae505c4eae05f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Cellar,

I am assuming that we'= ll need some agenda time to talk about any remaining questions/changes for= =C2=A0draft-ietf-cellar-ffv1, currently in AUTH48 with the RFC Editor.=C2= =A0

Are there other topics that I need to put at t= he head of the agenda?

Best,

<= div>Spencer
--000000000000902ae505c4eae05f-- From nobody Sat Jun 19 07:52:36 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 9A3E73A12DF; Sat, 19 Jun 2021 07:52:33 -0700 (PDT) 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 fBfxFlUCM3sI; Sat, 19 Jun 2021 07:52:31 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 E651C3A12D9; Sat, 19 Jun 2021 07:52:30 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id g142so18618644qke.4; Sat, 19 Jun 2021 07:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=QQUyWkcjVyUYkq2Y1ESKnE2AOMG8Ud108Gm0WqXO20c=; b=Cg2CZNsNukYRQuU+TAUv61PuXpH7PHZXcHkZy7zxvV4hgv0q9IKdo1/LF4nE+Uzh3l 2d34fN7L3XvS8qhU5KW64Gq6uOKiQA9BDOSvqxk8Qmmw8r/Vf2/kTNlEITPxNyhDXTYM r6bnYBfW06imJpzHawwPpKTQyzkkhxD2r4xyD3jDNxvJtuaxuGtW59i+1tdiwbRFOKXS MLMSJhG6aqwPLBbtN/EAzsf6d/30ncGX+LDP15MEdumISrFZSEY9vM8ED4+M9w1bJKon oJ7mtnDf2K22lvxEOg+C52JqcVvuCKyE7FqcW+IASelvi4okusAM6jr9/5UpZw9wYs9S zzww== 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:cc; bh=QQUyWkcjVyUYkq2Y1ESKnE2AOMG8Ud108Gm0WqXO20c=; b=f9ZcFByXQJUnovrMzdoifWt9e2r8r7m3T5DBR4JA4cukkFO2WgqwEv93HiLiv/8r9K hRk+3FsN/e+fn+sbpDEYOIGuxfJ0ZufQz4txfnJ1X1ZyanMnxNyNespFqajdlg2Xx2Fk IhOy9o+PjnioS4WW29G1PTyoVEEXCVWujLjaAP/+5/DOSeBnUYRWI0NnkNPHoskpPQDL 57N1Nq732vP9EKyWH/TW5ev2D+Kipyc1Y89223BsKHQ/mHU38vDrDSrIR4fvilU2m4qC b8+qdqigfe/1cyBgO5RgtNHEBwme4rm42KS2iqR1MrT79Y86jlnSpxkzANp7xwghD5Xq l2iw== X-Gm-Message-State: AOAM531hTzTepSbg+tFulCtJrvb1teKu9c8ISJhqqeAKZEjuMkOdQS+V TKoipPZMHGiVzDz9a8cHMmJm1aSrO0oKmTZX5pzoFC0OWoVzuQ== X-Google-Smtp-Source: ABdhPJznIXsDwzQwg6HOwzHppj52/gdbRuCdi9B7F+u+F5XJrYxHgge+YkKcofEx866Rdhuw4Hif+QqGmjWXEpw2orM= X-Received: by 2002:a25:3749:: with SMTP id e70mr20794261yba.53.1624114349007; Sat, 19 Jun 2021 07:52:29 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Sat, 19 Jun 2021 09:52:03 -0500 Message-ID: To: ART ADs Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000d8e74005c51f9692" Archived-At: Subject: [Cellar] So, which countries are countries this week? :-) 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: Sat, 19 Jun 2021 14:52:34 -0000 --000000000000d8e74005c51f9692 Content-Type: text/plain; charset="UTF-8" Dear Francesca and Murray, The CELLAR working group is thinking about moving to use "IETF country codes" in Matroska (they have been using ISO 639-2 for country codes, and have just realized that's for language codes, not country codes). The current issue on this is https://github.com/ietf-wg-cellar/matroska-specification/issues/519. Could you let us know what the current thinking is about this, since I note that both RFCs in BCP47 are over a decade old, and things like this don't change often, but they can change. (Replies in Github OR on this mailing list would be fine) Best, Spencer, who is pretty sure he can speak one language, but it's never clear what variant his EN is ... --000000000000d8e74005c51f9692 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Francesca and Murray,=C2=A0

The CE= LLAR working group is thinking about moving to use "IETF country codes= " in Matroska (they have been using=C2=A0=C2=A0ISO 639-2 for country c= odes, and have just realized that's for language codes, not country cod= es).=C2=A0


Could you let us know what the current thinkin= g is about this, since I note that both RFCs in BCP47 are over a decade old= , and things like this don't change often, but they can change.

(Replies in Github OR on this mailing list would be fine)=

Best,

Spencer, who is pr= etty sure he can speak one language, but it's never clear what variant = his EN is ...=C2=A0
--000000000000d8e74005c51f9692-- From nobody Sat Jun 19 10:19:05 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 2EFFB3A196C for ; Sat, 19 Jun 2021 10:19:04 -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 6WnjhQOOTbwL for ; Sat, 19 Jun 2021 10:18:59 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 18EF63A196E for ; Sat, 19 Jun 2021 10:18:58 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id bj15so17585289qkb.11 for ; Sat, 19 Jun 2021 10:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tjlXmuuTb5ziJrh2pkCtEf7FE8x4U2G9SjZ0Jdeu04M=; b=fNfuppMF1ZbyHiiQM5fWAJEszfgpVntr9m7TyvNOtKlpQJeQSScucr9r5VNdxryMas KBK4ZPDDzcvL4aCBHeI8nX4g4alLB6HbDIX12vPN9v/fC0BDpq1yJTEmKazhNAREZtff Pk9pp5afOQc/eAgk4M25bR01BgdxsuICxX6atQjtZgNQS0gJ9Cw+HuvcsYFxqqGXTiVk bTi9AdojRW5vKY3xpi1m1FbxQrE6AqnCZot+Tc663cJQLUWCjaERRC5O/TzXyE5v/Emd XYEngvnr2FH23zXhsy2ifx7joKVOG6KotKham8KAOhqF+3kyqp4jf5Rd5Ss9Zhn/q0/v 2kFw== 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:cc; bh=tjlXmuuTb5ziJrh2pkCtEf7FE8x4U2G9SjZ0Jdeu04M=; b=sB7vUqCSCWwX9su5+4SWOJmJsgwqb/rYyn6QUx/g/WvVOTNv5TO+plnzsYI09hflav UTQOfJdWwPc1EMlda9q4TDs9IsDqZDngtKQi5sXRUukk441C2tiwn1oQv4ZCffDs2VR/ BT5aGcfBExM9X2WEk8Y31prjTU0kZByFqXzJC//Y1YEcphIid5ksIVVnfqZB4DVzT81U ZDhGsCjRwN7L+S6L+JEnFf30BCi6FcF1fr1Jsuw1AqaaJl8CwtNHiJgkPRd01W0CSVfv g/E3CdKrcLIiC1RTxlAz4/EozgBQc5jwOn6ctxoHARFMvZyALTr2EPo7SX/KbP34vYAG 2HzQ== X-Gm-Message-State: AOAM5320tokMPGEE3cBtlu5fB6Rmt34G+TSMLIv7V0slmyPQGbvFh+30 iExmxXj/T9ytPX3jQlc6LJUTGerRNbaycVfDW4bAgotW0U+k4w== X-Google-Smtp-Source: ABdhPJwLd+Ux6Dm1md/SbTV93xUB3e0qJce5V0781gyDr9UaX7RTgk/GyJ/8sRtTsYBMOq/g0irijPjB3LlD43XwN8Q= X-Received: by 2002:a25:f446:: with SMTP id p6mr21724636ybe.288.1624123135796; Sat, 19 Jun 2021 10:18:55 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Sat, 19 Jun 2021 12:18:29 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: Murray Kucherawy Content-Type: multipart/alternative; boundary="00000000000094a99b05c521a255" Archived-At: Subject: [Cellar] Sample draft for updating RFC 8794 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: Sat, 19 Jun 2021 17:19:04 -0000 --00000000000094a99b05c521a255 Content-Type: text/plain; charset="UTF-8" Dear Jerome, I had an action after our last virtual meeting to provide a pointer to an RFC that updated another RFC, without replacing the previous RFC. The one I am most familiar with, is https://www.rfc-editor.org/rfc/rfc8540.html. I was the responsible AD for that RFC when it was printed. Based on my experience with that RFC (details on request, but https://datatracker.ietf.org/doc/rfc8540/ballot/ would give you some ideas),* here's what I'm suggesting that Cellar do differently* when we are updating https://datatracker.ietf.org/doc/rfc8794/. - Use something like "Extensible Binary Meta Language: Errata and Corrections for RFC 8794" as the title. - If we call this something like " Extensible Binary Meta Language: Corrections to RFC 8794" At some point, someone would ask about the relationship between the corrections in this draft and the corresponding errata in https://www.rfc-editor.org/errata_search.php?rfc=8794&rec_status=15&presentation=table (and there aren't any), so I'd avoid the use of the term "errata" anywhere in this draft in this draft. - I'd make clear early in this draft where these errors WERE reported to the working group - is it correct that they were all raised as issues in ietf-wg-cellar/ebml-specification? - Target standards-track, not Informational, so that this draft can update RFC 8794, which is also standards-track, and include "Updates: 8794" as part of the document header. - Use a three-part format for each correction - "text in RFC 8794", "what's incorrect or unclear in that text", and "replacement text for RFC 8794". If you include the strings "OLD" and "NEW" in front of the original text and replacement text, everyone will understand what you're doing. If you'd like for me to take a look at a rough outline for this draft before you start chewing on it in earnest, I'm happy to do that. When you've got a rough outline, please let me/Michael know - we will want to create a milestone for this draft in the datatracker, with an estimated date, and ask Murray to approve it. If this draft turns out to contain more than 8-10 corrections, we'll be talking seriously with our AD about whether making the changes in a replacement for RFC 8794 would be more appropriate, but we can trip over that boulder if we get to it. Does that make sense to you (and to the working group)? Best, Spencer --00000000000094a99b05c521a255 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Jerome,

I had an action after our = last virtual meeting to provide a pointer to an RFC that updated another RF= C, without replacing the previous RFC.=C2=A0

The o= ne I am most familiar with, is=C2=A0https://www.rfc-editor.org/rfc/rfc8540.html. I was the= responsible AD for that RFC when it was printed.=C2=A0

Based on my experience with that RFC (details on request, but=C2=A0https://datatrac= ker.ietf.org/doc/rfc8540/ballot/ would give you some ideas), here= 9;s what I'm suggesting that Cellar do differently when we are upda= ting https://datatrac= ker.ietf.org/doc/rfc8794/.
  • Use something like "E= xtensible Binary Meta Language: Errata and Corrections for RFC 8794" a= s the title.=C2=A0
    • If we call this something like " Extens= ible Binary Meta Language: Corrections to RFC 8794" At some point, someone would ask about the relationship between the correct= ions in this draft and the corresponding errata in=C2=A0https://www.rfc-editor.org/errata_search.php?rfc=3D8794&= amp;rec_status=3D15&presentation=3Dtable (and there aren't any)= , so I'd avoid the use of the term "errata" anywhere in this = draft in this draft.=C2=A0
    • I'd make clear early in this draft w= here these errors WERE reported to the working group - is it correct that t= hey were all raised as issues in=C2=A0ietf-wg-cellar/ebml-specification?
  • Target standards-track, not Informational, so that this draft ca= n update RFC 8794, which is also standards-track, and include "Updates= : 8794" as part of the document header.
  • Use a three-part forma= t for each correction - "text in RFC 8794", "what's inco= rrect or unclear in that text", and "replacement text for RFC 879= 4". If you include the strings "OLD" and "NEW" in = front of the original text and replacement text, everyone will understand w= hat you're doing.=C2=A0
If you'd like for me to take = a look at a rough outline for this draft before you start chewing on it in = earnest, I'm happy to do that.=C2=A0

Whe= n you've got a rough outline, please let me/Michael know - we will want= to create a milestone for this draft in the datatracker, with an estimated= date, and ask Murray to approve it.=C2=A0

If this= draft turns out to contain more than 8-10 corrections, we'll be talkin= g seriously with our AD about whether making the changes in a replacement f= or RFC 8794 would be more appropriate, but we can trip over that boulder if= we get to it.=C2=A0

Does that make sense to you (= and to the working group)?=C2=A0

Best,
<= br>
Spencer


--00000000000094a99b05c521a255-- From nobody Sat Jun 19 10:34:12 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 123433A19EC for ; Sat, 19 Jun 2021 10:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, 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 Zldm2u76574y for ; Sat, 19 Jun 2021 10:34:04 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 79D493A19EA for ; Sat, 19 Jun 2021 10:34:04 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id bj15so17646256qkb.11 for ; Sat, 19 Jun 2021 10:34:04 -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; bh=GZGrhxZUDV8k38UTEVV8dlbkoHWf57niH91Pw+iyIUw=; b=HMBLFEiZqNZZuaiCO3FSGPRENV++G3vfCOMiUMRjZFOI4tFlpxpJdaihhPSoZ9F8Ef Vr+rnBol47ar74QZzX5fHoSZztTi4GBcMtQIVj7WBHKmZKQzuBG1H8JAFR9LoNq5sfOp hLvIYUPBUKLKAf13/Mt5wK/pQyZsST4Gm2gS5IUWnITnsrr1vZDpWt4yieGFxnrQBdGg PwfFlDZlx0N6QBca4AqnVHi1yyKZ4jN7h80nEoXA/bOQq4pCAPu8V6Eu5XiJZA05lVdc APU7MViQY9lYw7NUipG+A98pFfM/aIzLx7qunod3nDec4VlG/C05RNTqJpS/4uB9zb3c 7/hw== 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=GZGrhxZUDV8k38UTEVV8dlbkoHWf57niH91Pw+iyIUw=; b=oV8m5T35t+7gDin3Gs/FnEDC/9uzCgwcgMlaH8pHVe29tPtwo8ybLp2M05jJa1x5AD O51ZoBRK/r52uRvKxjb9LTanMeQEZpQGe67vzF6qjd360qSXQXb2KBepamKNbHqOS0JP Hq7wvsanMXA4xLsH5BwmulSZ/9c/KEJsgPDKc7qaK34r3/2M6xVKDzPku9AXois/agai 2+OVfr8fkh6KIJxRFAFWadPFSsHTF73OrdWc/D/yjpB0FQEqRwa2rDaThKaQshue02Vs PQh37Zmh+qrIwhfqcXaWtpJsMlN7MM3MZiQg+w16h+4M25ZZzELOBWyaHsVCfJe5pKfZ oSZw== X-Gm-Message-State: AOAM5312c8pgbzGrpRXSve9Rj/4IasSKLEKNDXeDXdFKuwL7fpWA8rHm qZzGsOLHbs73Mc670mZDKtEu52AW04u4Du8bfs4k6N32F/+A7Q== X-Google-Smtp-Source: ABdhPJzvRbL6kvm7h8+HmYIP02VFoEW+nVqhnEIreDCPVYD0qaGCeOdorpmUYwWU/FF7L22vgtz8j8DVqoQtAEwL6w0= X-Received: by 2002:a5b:883:: with SMTP id e3mr5808757ybq.380.1624124042638; Sat, 19 Jun 2021 10:34:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Sat, 19 Jun 2021 12:33:36 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000a1fa1405c521d869" Archived-At: Subject: Re: [Cellar] Special agenda topics for our Cellar meeting on June 22? 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: Sat, 19 Jun 2021 17:34:10 -0000 --000000000000a1fa1405c521d869 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Cellar, I didn't hear any special requests for agenda items (although we can certainly add them if you need to), so I've posted an agenda that looks like this: I've tried to use more markup in this agenda than previously, to improve readability and, honestly, my ability to create new agendas without making dumb manual editing mistakes). If I went overboard, please tell me, and I can fix that ... Talk to you all on Tuesday! Best, Spencer CELLAR -- DRAFT AGENDA for Virtual Interim Meeting DateTime 2021-06-22 21:00 Amsterdam Note 20:00 UTC Meeting time is 16:00 NYC anchored to Amsterdam 13:00 San Francisco Administrivia INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-06 N= ote that we're now pointing to the Github repo for chair notes here WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.) Logistics for Meeting 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ :::warning Note that we do not have a July meeting - (Virtual) IETF 111 will be 2021-07-26 to 2021-07-30. Qur next meeting will be 2021-08-24 =E2=9A=A1 ::: - IETF 111 in July will definitely be virtual. - 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. 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. APPEAR.IN is now called "whereby.com" (https://whereby.com/cellar-interim) Agenda Items Note Well: https://www.ietf.org/about/note-well/ Roll call Attendees - Spencer Dawkins - Regrets * Accept draft minutes from previous meeting (attached below) - Any objections? Follow-up on Meetecho - We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an action to check on iOS and Android clients for Meetec= ho. WG status update - draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue, in AUTH48 (see [AUTH48] below) - draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exists - draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists - draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists Milestone review: - Close to celebrating on FFv1, but we need to get through AUTH48 - Matroska maybe at the end of Summer 2021? It's closer than we thought - FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he's unable to serve as editor, so the working group ha= s a decision to make about FLAC. From the mailing list: From Steve, on EBML errata - We are proceeding with a short RFC that UPDATES RFC 8794, not replacing that RFC, and this draft will contain only corrections for the errata we are aware of. - Jerome asked for an example of such an RFC - Spencer suggested https://datatracker.ietf.org/doc/rfc8540/ on the mailing list ("Subject: Sample draft for updating RFC 8794"), with suggestions for how to map th= at example onto the new Cellar draft. AUTH48 for draft-ietf-cellar-ffv1-20 Email subject: AUTH48 [JM]: RFC 9043 NOW AVAILABLE Current files from RFC-Editor 1. https://www.rfc-editor.org/authors/rfc9043.txt https://www.rfc-editor.org/authors/rfc9043.pdf https://www.rfc-editor.org/authors/rfc9043.html https://www.rfc-editor.org/authors/rfc9043.xml 2. This diff shows all changes from the approved Internet-Draft: https://www.rfc-editor.org/authors/rfc9043-diff.html https://www.rfc-editor.org/authors/rfc9043-rfcdiff.html (side by side) 3. This diff shows only the most recent changes: https://www.rfc-editor.org/authors/rfc9043-lastdiff.html https://www.rfc-editor.org/authors/rfc9043-lastrfcdiff.html (side by side) 4. This diff compares the submitted and current XML files: https://www.rfc-editor.org/authors/rfc9043-xmldiff1.html https://www.rfc-editor.org/authors/rfc9043-xmldiff2.html (side by side) - FFV1 v4 issues - We agreed at our previous meeting that we would use work on the introduction to the FFV1 v4 document as a way of agreeing on contents fo= r FFV1v4, and Jerome said he would start work on the Introduction (added a= s an issue) - https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md as our current plan - Any update? Matroska issues - FLAC issues - AOB? NEXT MEETING 2021-08-24. Notes from previous meeting for approval CELLAR -- DRAFT AGENDA for Virtual Interim Meeting May 25, 2021 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (*** Time is anchored to Amsterdam) INFO: https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-2021-05 (= *** Note that we're now pointing to the Github repo for chair notes here***) WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.) Attendees - Spencer Dawkins - Moritz Bunkus - Steve Lhomme - Reto Kromer - Jerome Martinez - Dave Rice - Martin Below Regrets - (possibly) Michael Richardson 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from previous meeting (attached below) objections asked for, and none received 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 3d) One-time Item: Changes to logistics (IRC, Jabber, Whereby, Meetecho ...= ) - Existing IRC server has been "taken over". Are we moving? Not moving yet, but we have a candidate server to move to. We can keep both channel= s open, for the time being. Actually using Github for most conversations f= or FFV1 and Matroska. - (Is there an iOS or Android app? Spencer will check!) 1. WG status update - draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue - draft-ietf-cellar-ffv1-v4-16 was posted 2020-12-01, in ID Exists (expiring in about a week - Dave submitted a keepalive version on the ca= ll) - draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists (thank you, Dave, for submitting this) - draft-ietf-cellar-matroska-07 was posted 2021-04-12, in ID Exists - draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists 1. Milestone review: - Matroska maybe at the end of Summer 2021? It's closer than we thought Action: we're making a lot of progress on this - we just need to figure out where we are - We had the big text move this month, We've submitted several issues as a part of this with known fixes. - FLAC still needs an editor to complete the work. Michael did hear back from Florin, and he's unable to serve as editor, so the working group ha= s a decision to make about FLAC. - FFV1-v4 requires more research, and it is unclear when we will know what a realistic goal date is. 1. 2021 virtual interim meeting dates - Please note our 2021 dates listed at https://datatracker.ietf.org/wg/cellar/meetings/ - IETF 111 in July will definitely be virtual. - 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. 1. From the mailing list: From Steve, on EBML errata - Spencer thought we submitted errata last time, but https://www.rfc-editor.org/errata_search.php?rfc=3D8794&rec_status=3D15&= presentation=3Dtable doesn't show any errata of any status - did this happen? - We have 2 merged changes and 2 pending changes in Github - In mailing list discussion, we think we have about four pages of text, with the identified errata, and the change to IANA instructions - Murray said that's likely fine as an Updates RFC, rather than a much bigger RFC that replaces RFC 8794 - Are we OK with producing a short RFC that would update the EBML RFC, probably around end-of-summer? - Jerome asked for an example of such an RFC - Spencer can provide this. 1. From the mailing list: From Steve, on Matroska #495 section reorderin= g - Steve rebuilt the txt/html files and sent before/after to the mailing list - Are we all happy with this? We are all happy. - Do we need to do anything else? - Merged during interim meeting 1. FFV1 v4 issues - Last month, we said we need some working group time to brainstorm on v4 - we can do this as a meeting, on the mailing list, or more broadly - What would a good plan look like? Can we schedule that time now? - Jerome said he would start work on the Introduction (added as an issue= ) - https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md as our current plan - We need to discuss line by line on the mailing list. 1. Matroska issues - Merged 512. - We will experiment with 513 (as in PR). - We'll take a littme more time with 511. - Merged 489. - 487 - adding a sentence that no known Matroska players use these elements. - Merged 475 - not possible to have values except 1 or 0. Removed support for other values in 2004. - Merged 498. - We note there are elements with ranges but also restrictions. We could remove the ranges but then we don't know how to validate values. We'll create an issue on this (do restrictions have priority over ranges?) 1. FLAC issues --000000000000a1fa1405c521d869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Cellar,=C2=A0

I didn't hear an= y special requests for agenda items (although we can certainly add them if = you need to), so I've posted an agenda that looks like this:
=
I've tried to use more markup in this agenda than previo= usly, to improve readability and, honestly, my ability to create new agenda= s without making dumb manual editing mistakes). If I went overboard, please= tell me, and I can fix that ...

Talk to you all o= n Tuesday!

Best,

Spencer<= /div>

CELLAR -- D= RAFT AGENDA for Virtual Interim Meeting

13:00 S= an Francisco
DateTime
2021-06-2221:00 Amsterdam
Note= 20:00 UTC
Meeting time is16:= 00 NYC
anchored to Amsterdam

Administrivia

INFO:

https://github.com/ietf-wg-cellar/chair-= notes/tree/master/interim-2021-06=C2=A0Note that we're now pointing to the Github repo f= or chair notes here

WEB CONFERENCE:

https://whereby.com/cellar-interim

THERE IS NO TELEPHONE DIALIN (You can try connecting to the whereby.com link at any time.)

2021 virtual interim meeting dates

Shared COMIMD for notetaki= ng:=C2=A0https://codimd.ietf.org/notes-cellar-virtual

  • Note that if you log in to the IETF datatracker, you'll be able t= o edit these notes, add your name to attendee lists, etc.
  • Please ask Spencer if you have que= stions.

    • APP= EAR.IN is now called "whereby.com" (https://whereby.com/cellar-interim)

    Agenda Items

    Note Well:=C2=A0= https://www.ietf.org/about/note-well/

    Roll call

    Attendees

    • Spencer Dawkins

    Regre= ts *

    Accept draft minutes from previous meeting (attache= d below)

    • Any objections?

    Follow-up on= Meetecho

    • We discussed moving to Meetecho (from whereby.com) at the May meeting, and Spencer had an act= ion to check on iOS and Android clients for Meetecho.

    WG = status update

    • draft-ietf-cellar-codec-06 was posted 2021-04-12= , in ID Exists
    • dr= aft-ietf-cellar-ffv1-20 was posted 2021-02-23, is now in RFC Editor Queue, = in AUTH48 (see [AUTH48] below)
    • draft-ietf-cellar-ffv1-v4-17 was posted 2021-05-25, in ID Exi= sts
    • draft-ietf-ce= llar-flac-01 was posted 2021-04-27, in ID Exists
    • draft-ietf-cellar-matroska-07 was posted 20= 21-04-12, in ID Exists
    • draft-ietf-cellar-tags-06 was posted 2021-04-12, in ID Exists

      • Milestone review:

      • Close to celebrating on FFv1, but = we need to get through AUTH48
      • Matroska maybe at the end of Summer 2021? It's closer than= we thought
      • FLAC = still needs an editor to complete the work. Michael did hear back from Flor= in, and he's unable to serve as editor, so the working group has a deci= sion to make about FLAC.

      From the mailing list: From Steve, on EBML er= rata

      • We are proceeding with a short RFC that UPDATES RFC 8794, = not replacing that RFC, and this draft will contain only corrections for th= e errata we are aware of.
      • Jerome asked for an example of such an RFC - Spencer suggested=C2= =A0https://datatracker.ietf.org/doc/rfc8540/=C2=A0on the mailin= g list ("Subject: Sample draft for updating RFC 8794"), with sugg= estions for how to map that example onto the new Cellar draft.
      AUTH48 for draft-ietf-cellar-= ffv1-20

      Email subject: AUTH48 [JM]: RFC 90= 43 <draft-ietf-cellar-ffv1-20.txt> NOW AVAILABLE

      Current files from RFC-Editor

      1. https://www.rf= c-editor.org/authors/rfc9043.txt=C2=A0https://www.rfc-edit= or.org/authors/rfc9043.pdf=C2=A0https://www.rfc-editor.or= g/authors/rfc9043.html=C2=A0https://www.rfc-editor.org/aut= hors/rfc9043.xml

      2. This diff shows all changes from the approved Internet-Draft:=C2=A0https://www.rfc-editor.org/authors/rfc9043-diff.html=C2= =A0https://www.rfc-editor.org/authors/rfc9043-rfcdif= f.html=C2=A0(side by side)

      3. This diff shows only the most recent changes:=C2=A0https://www.rfc-editor.org/authors/rfc9043-lastdiff.html=C2= =A0https://www.rfc-editor.org/authors/rfc9043-las= trfcdiff.html=C2=A0(side by side)

      4. This diff compares the submitted and current XML files:= =C2=A0https://www.rfc-editor.org/authors/rfc9043-xml= diff1.html=C2=A0https://www.rfc-editor.org/autho= rs/rfc9043-xmldiff2.html=C2=A0(side by side)

      • =

      FFV1 v4 issues

      • We agreed at our previous meeting that= we would use work on the introduction to the FFV1 v4 document as a way of = agreeing on contents for FFV1v4, and Jerome said he would start work on the= Introduction (added as an issue)
      • https://github.com/FFmpeg/FFV1/blob/master/ffv1-v= 4-goals.md=C2=A0as our current plan
      • Any update?

      Matroska issues

      FLAC issues

      AOB?

      NEXT MEETI=
NG 2021-08-24.

      Notes from previous meeting for approval

      CELLAR -- DRAFT AGENDA for = Virtual Interim Meeting

      May 25, 2021 21:00= Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (*** Time is anchore= d to Amsterdam)

      INFO:=C2=A0https://github.com/ietf-wg-cellar/chair-notes/tree/master/interim-20= 21-05=C2=A0(*** Note that we're now pointing to the Github repo for= chair notes here***)

      WEB CONFERENCE:

      https://whereby.com/cellar-interim

      THERE IS NO TELEPHONE DIALIN (You can try connectin= g to the whereby.com link at any time.)<= /p>

      Attendees

      • Spencer Dawkins
        • Moritz Bunkus
      • Steve Lhomme
      • Reto Kromer
      • Jerome Martinez
      • Dave Rice
      • Martin Below

      Regrets

      • (possibly) Michael Richardson
      1. <= p style=3D"box-sizing:border-box;margin-top:16px;margin-bottom:16px">Note W= ell.=C2=A0https://www.ietf.org/about/note-well/

      2. Accept draft minutes from previous = meeting (attached below) objections asked for, and none received

        3. Logistics for Meeting. 3a) S= hared COMIMD for notetaking:=C2=A0https://codimd.ietf.org/notes-= cellar-virtual

        • Note t= hat 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 y= ou have questions.

      3b) APPEAR.IN is now called "whereby.com"

         https://whereby.com/cellar-interim

      3c) Roll call

      3d) One-time Item: Changes to logistics (IRC, Jabber, = Whereby, Meetecho ...)

        Existing IRC server has been "taken = over". Are we moving? Not moving yet, but we have a candidate server t= o move to. We can keep both channels open, for the time being. Actually usi= ng Github for most conversations for FFV1 and Matroska.
      • (Is there an iOS or Android app? Spe= ncer will check!)
      1. WG status update
    • draft-ietf-cellar-codec-06 was posted 2021-04-12, in ID Exists
      • draft-ietf-cellar-ffv1-= 20 was posted 2021-02-23, is now in RFC Editor Queue
    • draft-ietf-cellar-ffv1-v4-16 was posted= 2020-12-01, in ID Exists (expiring in about a week - Dave submitted a keep= alive version on the call)
    • draft-ietf-cellar-flac-01 was posted 2021-04-27, in ID Exists (th= ank you, Dave, for submitting this)
    • draft-ietf-cellar-matroska-07 was posted 2021-04-12, in = ID Exists
    • draft-i= etf-cellar-tags-06 was posted 2021-04-12, in ID Exists
    1. Milestone review:
    • Matroska maybe at the end of = Summer 2021? It's closer than we thought

    Action: we're making a lot of progress on this - we just need t= o figure out where we are

    • We had the big text move this month, We'= ;ve submitted several issues as a part of this with known fixes.

      • FLAC still needs an editor t= o complete the work. Michael did hear back from Florin, and he's unable= to serve as editor, so the working group has a decision to make about FLAC= .

    • FFV1-v4 requires= more research, and it is unclear when we will know what a realistic goal d= ate is.

    1. 2021 virtual interim meeting dates=
    • Please note our 2021 dates listed at=C2=A0= https://datatracker.ietf.org/wg/cellar/meetings/
    • IETF 111 in July will definitely be vir= tual.
    • Sometime ar= ound 2021-09-28, we=E2=80=99ll see if we want to meet at IETF 112 on Novemb= er 6-12, 2021, in person in Madrid.
    1. From the m= ailing list: From Steve, on EBML errata
    • Spencer thought we= submitted errata last time, but=C2=A0https://www.rfc-editor.org/errata_search.php?= rfc=3D8794&rec_status=3D15&presentation=3Dtable=C2=A0doesn'= t show any errata of any status - did this happen?
    • We have 2 merged changes and 2 pending ch= anges in Github
    • I= n mailing list discussion, we think we have about four pages of text, with = the identified errata, and the change to IANA instructions
    • Murray said that's likely fin= e as an Updates RFC, rather than a much bigger RFC that replaces RFC 8794
    • Are we OK with pro= ducing a short RFC that would update the EBML RFC, probably around end-of-s= ummer?
    • Jerome ask= ed for an example of such an RFC - Spencer can provide this.
    1. From the mailing list: From Steve, on Matroska #495 section = reordering
    • Steve rebuilt the txt/html files and sent befor= e/after to the mailing list
    • Are we all happy with this? We are all happy.
    • Do we need to do anything else?
    • Merged during interi= m meeting
    1. FFV1 v4 issues
    • Last= month, we said we need some working group time to brainstorm on v4 - we ca= n do this as a meeting, on the mailing list, or more broadly
    • What would a good plan look li= ke? Can we schedule that time now?
    • Jerome said he would start work on the Introduction (adde= d as an issue)
    • https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md=C2= =A0as our current plan
    • We need to discuss line by line on the mailing list.
    1. Matroska issues
    • Merged 512.
    • We will experiment with 513 (as in= PR).
    • We'll t= ake a littme more time with 511.
    • Merged 489.
    • 487 - adding a sentence that no known Matroska players use these= elements.
    • Merged= 475 - not possible to have values except 1 or 0. Removed support for other= values in 2004.
    • = Merged 498.
    • We no= te there are elements with ranges but also restrictions. We could remove th= e ranges but then we don't know how to validate values. We'll creat= e an issue on this (do restrictions have priority over ranges?)
  • FLAC issues

    --000000000000a1fa1405c521d869-- From nobody Sun Jun 20 00:51:11 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 B2E323A1FAE for ; Sun, 20 Jun 2021 00:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=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=qhhvU9be; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jn7UOeTA 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 efBMg-yA0eZn for ; Sun, 20 Jun 2021 00:51:00 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62323A1FB7 for ; Sun, 20 Jun 2021 00:51:00 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 32053F96 for ; Sun, 20 Jun 2021 03:38:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 20 Jun 2021 03:38:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=mQGPcPtLxun Q9FVfSdJM1HH3E7ZnWoWwYgoPMnMNuQs=; b=qhhvU9befeWRlfsS6I/Tf7+60b7 a+CwOcD4jZwH36hFgxO0KexSmS/Midnv506h3hlHbxjE8+sRAFN+djGQTnwVjP9p vWtxn+ybobUTodZYRY9NvUsofE2+bcQOG1S4xryBTQuBqM+622mHeFjl/hc2hWrW GiD1H6n5JYdSs4JNsbjBacIRdqy0+8W9xX5PX0Z2QVZuDxldPJyr4jFIkKzJw5xg Hzm/a9gmk/5JIOw589Nooo5N5qX28De6VZtIjPq7o/1U9ya4ntGENlivE7IdMzOa K2flCdR3uMW29D3P/VEHOY0aDzK1rVn1wBVanrQaYxTMY3En2uGsReAnpPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=mQGPcPtLxunQ9FVfSdJM1HH3E7ZnWoWwYgoPMnMNuQs=; b=jn7UOeTA 1e0PNFEqZx1gmExzwl1KVtJz6lqRp+neHQT6mL3/Ehg5BA8KGfUPoEXhe52YW/m8 yF/Ae/KFgIzXc5ynNT1Lu5OkLdYywpLkHVyF2YaicSFDanusSp+ASV2VGNxgMhFI Rsj0iRA9ADnzWEaOZhpI7fANQ7vYgGDK1eNW/LbOTGUaEC76FbLNI+d2hxoXjUUV 4uENXFmPxvuPaF/BkuKD21mlVtnxWjydBFmeysMi4Oj/brU6dYZIzpMomZ8CaBl9 is/VRqBrA3WNttSS9QKHzM3rhsxPCe54+dg5H3rRi9uUMZyjDmsh4xQN7Uk2C2p7 mofADW2S1HJ6Dw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeefiedgudegudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 20 Jun 2021 03:38:42 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0340156740878555687==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210620075100.C62323A1FB7@ietfa.amsl.com> Date: Sun, 20 Jun 2021 00:51:00 -0700 (PDT) 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, 20 Jun 2021 07:51:06 -0000 --===============0340156740878555687== 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/ebml-specification (+2/-0/=F0=9F=92=AC2) 2 issues created: - create a new document containing all errata and additions to RFC 8794 (= by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/412 [errata= -rfc8794]=20 - Date Element specs: fix miscalculation & clarification about leap secon= ds (by Liisachan) https://github.com/ietf-wg-cellar/ebml-specification/issues/411=20 2 issues received 2 new comments: - #412 create a new document containing all errata and additions to RFC 8= 794 (1 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/412 [errata= -rfc8794]=20 - #411 Date Element specs: fix miscalculation & clarification about leap = seconds (1 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/411 [bug]=20 * ietf-wg-cellar/matroska-specification (+3/-0/=F0=9F=92=AC9) 3 issues created: - tags: COUNTRY description references wrong standard (by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/issues/519 [bu= g] [spec_tags] [tags]=20 - add a note about MIME types of font attachments (by mbunkus) https://github.com/ietf-wg-cellar/matroska-specification/issues/518=20 - rewrite general timestamp handling sections (by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/517 [cl= arifications]=20 2 issues received 9 new comments: - #519 tags: COUNTRY description references wrong standard (4 by JeromeMa= rtinez, SpencerDawkins, robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/519 [bu= g] [spec_tags] [tags]=20 - #518 add a note about MIME types of font attachments (5 by Liisachan, m= cr) https://github.com/ietf-wg-cellar/matroska-specification/issues/518 [en= hancement]=20 Pull requests ------------- * ietf-wg-cellar/matroska-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #501 forbid non mandatory default values that are not 0 (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/501 [bug]= [clarifications] [spec_main]=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 --===============0340156740878555687== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday June 20, 2021

    Events without label "editorial"

    Issues

    ietf-wg-cellar/ebml-specification (+2/-0/=F0=9F=92=AC2)

    2 issues created:

    2 issues received 2 new comments:

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

    3 issues created:

    2 issues received 9 new comments:

    Pull requests

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

    1 pull requests received 1 new comments:

    Repositories tracked by this digest:

    --===============0340156740878555687==-- From nobody Mon Jun 21 08:21:46 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 5B1093A0AD5 for ; Mon, 21 Jun 2021 08:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.338, 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 HDNXiKVK9qUD for ; Mon, 21 Jun 2021 08:21:41 -0700 (PDT) Received: from mailfish.xiph.org (mailfish.xiph.osuosl.org [140.211.166.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F27F3A0AD4 for ; Mon, 21 Jun 2021 08:21:40 -0700 (PDT) Received: from [172.17.0.87] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) by mailfish.xiph.org (Postfix) with ESMTPSA id D36839F707 for ; Mon, 21 Jun 2021 15:21:38 +0000 (UTC) To: cellar@ietf.org References: <1dee863c-3589-21f6-da13-db5beee25d8a@xiph.org> <524efcdc-c93e-1b3c-71b5-d10e1e11509c@matroska.org> From: "Timothy B. Terriberry" Message-ID: <0588f9af-9b43-21f9-1dd3-af5e0bc2f43b@xiph.org> Date: Mon, 21 Jun 2021 08:21:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.1 MIME-Version: 1.0 In-Reply-To: <524efcdc-c93e-1b3c-71b5-d10e1e11509c@matroska.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Timestamps again 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, 21 Jun 2021 15:21:44 -0000 Steve Lhomme wrote: > One possibility is to use the existing TrackTimestampScale element which > wasn't designed for that but works pretty well. It's backward compatible > although there is a high chance a lot of readers don't handle it properly. There are some other questions I had about interactions of it with other features, but given that it was deprecated I was not too worried about them. If you are planning to use it for this, maybe I should be, though. > A more solid solution would be to write the proper sampling rate of the > source (but that becomes complicated in case of Variable Frame Rate as > found nowadays in video games). Complicated things might be complicated, but you still need a reliable, documented way for the 99% of usage that will not have those complications. > I think the TrackTimecodeScale solves both these examples, because it > using a floating point estimation before rounding the numbers. It allows I think the issue here is not that there is insufficient precision. There are enough code points in the timestamp to uniquely identify each sample number, but the rounding rules are not constructed in such a way as to guarantee a reversible map between them. That problem could be exacerbated by introducing floating point if you are not very careful about defining how the truncation and rounding works, since not every floating point environment is implemented or configured the same way. It certainly becomes a lot harder to test exhaustively. For what it is worth, the program I attached passes using strategy (b) if you choose the "slightly smaller value" for TimestampScale to be 1/2 of the value recommended in the text, instead of the recommended value minus one. > I think we should explain the possibilities and limits of both methods > (with and without TrackTimecodeScale) when solving issue #517. Both when > muxing and demuxing to explain what rounding should be used. I agree. I look forward to seeing the rewrite of these sections. From nobody Thu Jun 24 13:32:05 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 DC8F13A2A33 for ; Thu, 24 Jun 2021 13:32:01 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 1KzW6CLOl7sE for ; Thu, 24 Jun 2021 13:31:59 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 8082D3A2A32 for ; Thu, 24 Jun 2021 13:31:54 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id b64so1194470yba.0 for ; Thu, 24 Jun 2021 13:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=B/NSxKimuz4IFhQNXrOU+DMumUhC+xlzde/C39Mujes=; b=AQ81K635NzN7UigyuOdC17h3S4GzQA2XxF5LNOeaXFVOIWn72cqYK2cUckig5NEyfE ki9akYX29VqlkcNM6Wbvfyue29TVfYH0UtZ0g+1g1Fo++ych3UtgK16kd7LKifoZCEC2 mVR7jUyQmKh3nFKIx0Oovk8n9uEkyGBFzi2qeHz/q1Ryds1g8CoZz+CYa4fnyiOwHdiO v0ok2uOiwtAs3AHWR1nv4SPolncjlJdb5sGTrz12Bp8fA5hSerHEXouA4/mgcLO4/Bj1 DccDhcocUC85O9LOxjOl9kl+Ij5JRSCbvo2EjU3krp3HJNIU9oLNzP7EuBdfeYvXy8t1 Qy5g== 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:cc; bh=B/NSxKimuz4IFhQNXrOU+DMumUhC+xlzde/C39Mujes=; b=H1mygg6yWyb7PeFjO+QSwCOm7HygkvjmLJ5xT+pRMY80EYhoSqEN+O5F2RxZpxUzGS nULh97qFcXgicu/DRzrWL/7b7rlyohg9DcP/Aq+6yKpl+41C0KMUEdcri2YD9aUQRB+6 Iipixt8cHOPNskd7d4QBmE9C80yG3h+0MhpItv++pYDfmqUsYppdUJRPp80U0rPOxPnC XoDTR7JDyBwUlHkR5qaHN2R1WF/oA0I558g/QsRqs8Z5Kl1AnYvPMwpaYGR2bxKlWfo/ /gfaJuvOC4PBWW1Xu2v32jI58sQMzi21glAp/xdgZBSB0JwMlWMkNZ34VktZSHPjMazO Kyfg== X-Gm-Message-State: AOAM5333GHpgL6utjzIQV1UbMpT0cp3H8R80wpf/c609iuQHEm3/oxCe ze2PFYMnPRA+jzqBttfrpuYsgiMsVAr78es9BmyIlm6yMqnKKw== X-Google-Smtp-Source: ABdhPJwTki08XogAtdzcYBgJWu4TsmM/RjSBoOdS+bOrL/TifXHGSq7b8eU/A1ksadzFOuqi+d7f3RV5zaw97r+eNrk= X-Received: by 2002:a25:3749:: with SMTP id e70mr7745622yba.53.1624566713180; Thu, 24 Jun 2021 13:31:53 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Thu, 24 Jun 2021 15:31:27 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: Murray Kucherawy Content-Type: multipart/alternative; boundary="000000000000da643c05c588e900" Archived-At: Subject: [Cellar] Publicity for CELLAR work on FFV1 Version 4 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: Thu, 24 Jun 2021 20:32:02 -0000 --000000000000da643c05c588e900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear CELLAR, >From our minutes earlier this week: Discussion on the call - We discussed https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md on the call. - What about infrared images? That could immediately interest people like autonomous vehicle community (who have money). - What about signatures for stored media? - What is needed here? Integrity, nonrepudiation, timestamps, =E2=80= =A6 we may need to talk about specific use cases to understand the requireme= nts. - No change to the current document contents for now - We can talk about this on the mailing list between now and IETF 111, and then between IETF 111 and our next working group meeting - ACTION: Spencer can take the action to do a short presentation in ARTAREA at IETF 111 in July, showing the proposed contents for FFV1 v4 and pointing people to Cellar. Thanks to our ADs, Michael and I have a chance to talk about FFV1 version 4 at IETF 111 in the ARTAREA meeting. If people think we need to say anything about proposed work that's not already in https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md, please let the working group know in the next week or two! Best, Spencer --000000000000da643c05c588e900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear CELLAR,

    From our minutes earlier t= his week:

    Discussion on the call
      <= ul>
    • We discussed https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.m= d on the call.
    • What about infrared images? That could immediate= ly interest people like autonomous vehicle community (who have money).
      • =
    • What about signatures for stored media?
    • What is needed here? In= tegrity, nonrepudiation, timestamps, =E2=80=A6 we may need to talk about sp= ecific use cases to understand the requirements.
    • No change to the c= urrent document contents for now
    • We can talk about this on the mail= ing list between now and IETF 111, and then between IETF 111 and our next w= orking group meeting
    • ACTION: Spencer can take the action to do a sh= ort presentation in ARTAREA at IETF 111 in July, showing the proposed conte= nts for FFV1 v4 and pointing people to Cellar.
    Thanks to= our ADs, Michael and I have a chance to talk about FFV1 version 4 at IETF = 111 in the ARTAREA meeting.=C2=A0

    If people = think we need to say anything about proposed work that's not already in= =C2=A0https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md, please = let the working group know in the next week or two!

    Best,

    Spencer
    --000000000000da643c05c588e900-- From nobody Sun Jun 27 00:41:03 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 1ECBE3A1F49 for ; Sun, 27 Jun 2021 00:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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_DNSWL_LOW=-0.7, 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=V3utrhBn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mEqAEFXs 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 ky3jRiwuft9W for ; Sun, 27 Jun 2021 00:40:56 -0700 (PDT) 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 7AEC03A1F48 for ; Sun, 27 Jun 2021 00:40:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 5615D320084E for ; Sun, 27 Jun 2021 03:32:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 27 Jun 2021 03:32:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm3; bh=ZqBCpUq2JfF VWs3gVwUvN9viur6bPasVoLSZC4mvj8Y=; b=V3utrhBn5cVH7rUM37py3TtkiEE YoGH5ctgMZFgQVkYhgXuTjPYZ06GU85MEV3kWl+C0l7e5HoLx1vG1WL6mB6j0imb l9UxFizCTMNptIVWt7G3c7NNOv25CBmo2+EV13vueLCXW06bJQtEGi7jRdBJAOwS tWdDVXrk804ib7iPsVnDwjGcsdM3wBlp7pA9ClZAxJM0tJYYvtKl+mRqDZ0s3Wl7 LBJTqC2SGng5+xIvqs8jsyA8EfAxa141OP+CD1SBtPvr5yn5n1Hn55RDfyjYkfRg /GXJ671B3S5KEKUTEobNhEU4f/uhSlS4XQXu/2YNmwOlRId0hPKOZEjtcag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=ZqBCpUq2JfFVWs3gVwUvN9viur6bPasVoLSZC4mvj8Y=; b=mEqAEFXs Sdo+bROu5sGfGPLygCqh7R1A2sEJW2k1TwRJJBDVRS29n5JEf/GMg+Po/x4BlhTJ E9STsa/TPi55k8qvpc7l1h0R2lHt1x9PebN8nGFVANJafS3hzRd78nLFrlMCxJGg 1jeODt2p50p68q6k0xairPGCxckUf39Q/35c0DEyxRycpJEenn4Cyjioat5WAsQ1 rwG2prathsFt9jX5inPR5lqHIGtBmk+guNiSZ7EEbtXTX7vD7Ci3lcTyf6HvjVcU 4FqeXKFOM8bBNT8YoH8XAB1lQ/nkHdVSfztjQc3eFaIX77Zx+sUQ4jPrZ7vhkWJV fYfxUhCWztYG2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehuddguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecupfhoucgurghtvgcufhhivghlugculdegledmne cujfgurheptggghffvufesrgdttdertddtjeenucfhrhhomheptfgvphhoshhithhorhih ucettghtihhvihhthicuufhumhhmrghrhicuuehothcuoeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeekfedvudetjedvfeekheeiveeu gfefhfetteevgeffkefffeetffdvleehudeiteenucffohhmrghinhepghhithhhuhgsrd gtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 27 Jun 2021 03:32:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3246898071581253890==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20210627074056.7AEC03A1F48@ietfa.amsl.com> Date: Sun, 27 Jun 2021 00:40:56 -0700 (PDT) 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, 27 Jun 2021 07:41:01 -0000 --===============3246898071581253890== 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/ebml-specification (+0/-1/=F0=9F=92=AC2) 1 issues received 2 new comments: - #411 Date Element specs: fix miscalculation & clarification about leap = seconds (2 by Liisachan, robUx4) https://github.com/ietf-wg-cellar/ebml-specification/issues/411 [bug] [= errata-rfc8794]=20 1 issues closed: - EBML ID 0x80 is marked invalid/reserved but it's used in Matroska https= ://github.com/ietf-wg-cellar/ebml-specification/issues/407 [bug] [errata-rf= c8794]=20 * ietf-wg-cellar/matroska-specification (+0/-0/=F0=9F=92=AC2) 2 issues received 2 new comments: - #519 tags: COUNTRY description references wrong standard (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/519 [bu= g] [spec_tags] [tags]=20 - #500 Add an EBML constraint about 0-length elements (1 by robUx4) https://github.com/ietf-wg-cellar/matroska-specification/issues/500 [cl= arifications] [format addition] [spec_main]=20 Pull requests ------------- * ietf-wg-cellar/ebml-specification (+2/-1/=F0=9F=92=AC6) 2 pull requests submitted: - Range and number of valid element IDs (by hubblec4) https://github.com/ietf-wg-cellar/ebml-specification/pull/414=20 - generate a new document for corrections (by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/413 [errata-r= fc8794]=20 4 pull requests received 6 new comments: - #414 Range and number of valid element IDs (1 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/414 [errata-r= fc8794]=20 - #413 generate a new document for corrections (3 by SpencerDawkins, robU= x4) https://github.com/ietf-wg-cellar/ebml-specification/pull/413 [errata-r= fc8794]=20 - #404 remove bogus DocType default value (1 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/404 [bug]=20 - #402 Void element: remove the maxOccurs attribute (1 by robUx4) https://github.com/ietf-wg-cellar/ebml-specification/pull/402 [bug]=20 1 pull requests merged: - allow 0x80 EBML ID since it's used in Matroska https://github.com/ietf-wg-cellar/ebml-specification/pull/408 [bug] [er= rata-rfc8794]=20 * ietf-wg-cellar/matroska-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #479 mark strings with no default value as not usable if empty (1 by ro= bUx4) https://github.com/ietf-wg-cellar/matroska-specification/pull/479 [XML = Schema] [clarifications] [spec_main]=20 * ietf-wg-cellar/chair-notes (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Reto cannot attend (by retokromer) https://github.com/ietf-wg-cellar/chair-notes/pull/1=20 1 pull requests merged: - Reto cannot attend https://github.com/ietf-wg-cellar/chair-notes/pull/1=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 --===============3246898071581253890== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday June 27, 2021

    Events without label "editorial"

    Issues

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

    1 issues received 2 new comments:

    1 issues closed:

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

    2 issues received 2 new comments:

    Pull requests

    ietf-wg-cellar/ebml-specification (+2/-1/=F0=9F=92=AC6)

    2 pull requests submitted:

    4 pull requests received 6 new comments:

    1 pull requests merged:

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

    1 pull requests received 1 new comments:

    ietf-wg-cellar/chair-notes (+1/-1/=F0=9F=92=AC0)

    1 pull requests submitted:

    1 pull requests merged:

    Repositories tracked by this digest:

    --===============3246898071581253890==--