From nobody Sun Sep 6 00:41:15 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D43A0115 for ; Sun, 6 Sep 2020 00:41:14 -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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=dwB2xslj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Bl3jER3g 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 eNFOpTRuvrfn for ; Sun, 6 Sep 2020 00:41:12 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0423A0112 for ; Sun, 6 Sep 2020 00:41:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F1DC3B3E for ; Sun, 6 Sep 2020 03:32:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 06 Sep 2020 03:32:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=m3Ft5ykfOZeiu0/NfFLQ0rWXHXPwiGOlBc+4GohnVQk=; b=dwB2xslj vgt6Boc6Kn5RPxoAy1vFj0/DkwpBIkboQGBAdWGw4tNrmi+RxAadp4LUtSUqxoJ4 qzZzVxCb6ZVaqZbjZ/QX5N/Eqx8WSUvgVwf2IXOfkLwEMKfAddzop0zzC87EJoPT sMnFZ6l3PkvHmj8eILVNCYEKybfHBdx1iM/D8OKecqSh2E8wXypApuRDPVVWaa+B bKT063QYtZDz9T0OrTH2EXNAQzOUYZRShDp79Nzg6QCiSheawuOV/ku6dQdXDmNf r47DHVNzqi2AYNG3+a/BCjP6yuXparRXdj2zoR2ERmVcL/+34/j34hAVHqS7wam9 KB6XoFiIGW71rQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=m3Ft5ykfOZeiu0/NfFLQ0rWXHXPwi GOlBc+4GohnVQk=; b=Bl3jER3gMRYZ0Lww4DG4WXo8T7hZsriTeNckyc+3ueywB 6mSyLwo71BXethipQBW6wCebNDKSvljz2AFwhF6w8lDK1cVrJd5vB0LEXdVYugIq PT4axfV0YgDGtwipqTCBnC7LT26qqzMSFCcNGD7qtDq7X+SgytOdsilS4Vt9+y6L u0Y7WXMt/ODUHxeLTa/QDiHc3+pYAgJJv/5weugU8TVGeER0uubbBfyl9q5cwnCA RoEmgXvi04hhFhp1lV2cD7oJ9iZAP3L+UOotFGGa1K3VLacqksTIXKxyKfKNra8k 5NU1mZzpTbuJtusL2P/dLnG2cJAz7yb4Rmq1X1iGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegiedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvtdefrd dujedunecuufhprghmkfhppfgvthifohhrkhepgedtrdeihedrvddtfedrudejudenucev lhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhoth gprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60.internal.cloudapp.net (unknown [40.65.203.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 658303280059 for ; Sun, 6 Sep 2020 03:32:50 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4046331619962145917==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200906073250.658303280059@mailuser.nyi.internal> Date: Sun, 6 Sep 2020 03:32:50 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2020 07:41:14 -0000 --===============4046331619962145917== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC3) 1 issues received 3 new comments: - #419 Specify requirements around ReferenceBlock elements and how BlockG= roups signal random access points (3 by mjbshaw, robUx4) https://github.com/cellar-wg/matroska-specification/issues/419 [clarifi= cations] [spec_main]=20 * cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #341 XHTML Basic has been superseded (1 by robUx4) https://github.com/cellar-wg/ebml-specification/issues/341 [bug] [forma= tting]=20 1 issues closed: - XHTML Basic has been superseded https://github.com/cellar-wg/ebml-speci= fication/issues/341 [bug] [formatting]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-3/=F0=9F=92=AC6) 2 pull requests received 6 new comments: - #421 use legacy and RFC element references HTML anchors (4 by retokrome= r, robUx4) https://github.com/cellar-wg/matroska-specification/pull/421 [website] = - #412 Added AVS2 video codec mapping (2 by robUx4, xatabhk) https://github.com/cellar-wg/matroska-specification/pull/412 [format ad= dition] [spec_codecs]=20 3 pull requests merged: - Added AVS2 video codec mapping https://github.com/cellar-wg/matroska-specification/pull/412 [format ad= dition] [spec_codecs]=20 - use legacy and RFC element references HTML anchors https://github.com/cellar-wg/matroska-specification/pull/421 [website] = - Clean/Fix Punctuation https://github.com/cellar-wg/matroska-specification/pull/405 [enhanceme= nt] [formatting]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============4046331619962145917== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday September 06, 2020

Events without label "editorial"

Issues

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

1 issues received 3 new comments:

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

1 issues received 1 new comments:

1 issues closed:

Pull requests

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

2 pull requests received 6 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============4046331619962145917==-- From nobody Sun Sep 6 01:28:59 2020 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 C5FDD3A08AE; Sun, 6 Sep 2020 01:28:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Qin Wu via Datatracker To: Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.15.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159938093648.7188.7752393359382713628@ietfa.amsl.com> Reply-To: Qin Wu Date: Sun, 06 Sep 2020 01:28:56 -0700 Archived-At: Subject: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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: Sun, 06 Sep 2020 08:28:57 -0000 Reviewer: Qin Wu Review result: Ready I have reviewed this document on behalf of the Operations and Management Directorate. Four questions need to be clarified： 1. why document v0,v1,v3 in draft-ietf-cellar-ffv1 as informational and document v4 in draft-ietf-cellar-ffv1-v4-14 as standard track? Not clear the key difference between v04 and all other previous versions? 2. Why not specify transport, is container sto which the ffv1 is mapped equivalent to transport? without transport, how to provide confidentiality, integrity, and source authenticity? 3. how error_status and crc parity are used? e.g., using crc parity detect error? can error be repaired? how? 4. Is bitstream parameters such as version, micor-version,num_h_slices,num_v_slices sensitity information that can disclosed? any security risk? From nobody Sun Sep 6 03:55:43 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659523A0CD1 for ; Sun, 6 Sep 2020 03:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 XuP_nzjS6VQM for ; Sun, 6 Sep 2020 03:55:32 -0700 (PDT) Received: from 4.mo69.mail-out.ovh.net (4.mo69.mail-out.ovh.net [46.105.42.102]) (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 325293A0CCC for ; Sun, 6 Sep 2020 03:55:31 -0700 (PDT) Received: from player711.ha.ovh.net (unknown [10.110.171.49]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id BA6499B65C for ; Sun, 6 Sep 2020 12:55:29 +0200 (CEST) Received: from mediaarea.net (p548f996f.dip0.t-ipconnect.de [84.143.153.111]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id 1417115B4F43D; Sun, 6 Sep 2020 10:55:23 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-100R0032f67823d-548f-4b27-8d74-a45b4bd5f0e3, E9516DFBA202DD949415F05DBAC7B10ABF94B0F5) smtp.auth=jerome@mediaarea.net To: Qin Wu , ops-dir@ietf.org Cc: last-call@ietf.org, cellar@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org References: <159938093648.7188.7752393359382713628@ietfa.amsl.com> From: Jerome Martinez Message-ID: Date: Sun, 6 Sep 2020 12:55:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <159938093648.7188.7752393359382713628@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 13844346730796552363 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudegjedgfeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeejffeuvdejjeevieefvdefhefgieeijeeffffgteeikeevheejhfdvheefteduvdenucffohhmrghinhepmhgvughirggrrhgvrgdrnhgvthdpihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudehfedrudduudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejuddurdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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 Sep 2020 10:55:43 -0000 Hi Qin, Thank you for your review, answers inline: On 06/09/2020 10:28, Qin Wu via Datatracker wrote: > Reviewer: Qin Wu > Review result: Ready > > I have reviewed this document on behalf of the Operations and Management > Directorate. Four questions need to be clarified： 1. why document v0,v1,v3 in > draft-ietf-cellar-ffv1 as informational and document v4 in > draft-ietf-cellar-ffv1-v4-14 as standard track? Not clear the key difference > between v04 and all other previous versions? v0,v1,v3 bitstreams are already in the wild, the FFV1 v0,v1,v3 specification documents what is already in use and we adapt the specification (including documenting issues found during the review of the encoders and decoders) to the bitstream in the wild instead of a clean change of the bistream when an issue is found, this is not really a standard with a consensus during the writing of the specification, the choice was to have informational status due to this. FFV1 v4 is not in the wild (the only encoder able to create such bitstream need to receive a "experimental" flag in order to create such bitstream), it is a future specification, clean, and we'll adapt the encoders/decoders to the decided specification, so standard status. Note that v4 i based on v0,v1,v3 so evolves at the same time but is not ready and not part of this last call review. > 2. Why not specify transport, is > container sto which the ffv1 is mapped equivalent to transport? without > transport, how to provide confidentiality, integrity, and source authenticity? FFV1 is a video coding format, like Opus is an audio coding format, Opus does not specify transport too. FFV1 is intended to be encapsulated in a container and we don't feel the need to have a dedicated transport for FFV1, we use (de facto or not) standard like MP4 (ISO standard) or Matroska (de facto standard and IETF standard candidate) for the transport. Note that Opus is an IETF standard (RFC 6716) without transport. Confidentiality, integrity, and source authenticity is delegated to the transport layer, as it is the case with Opus or many other coding formats. > 3. how error_status and crc parity are used? e.g., using crc parity detect > error? can error be repaired? how? error_status was intended for storing information about errors found in the bitstream, AFAIK it is not used in any encoder or decoder for filling (it is always 0) or reading (value discarded) this value but the informal specification has always planned this byte for error status so we currently keep it as instead of flagging it e.g as "reserved". We can not remove it from the bitstream as we document what is already in use in v0,v1,v3. crc parity is used for detecting a transport or storage error, in order to detect that losslessness is compromised by an unintentional change. the reference decoder (FFmpeg) first computes the CRC and rejects the slice if a CRC is not the expected one before trying to decode, and a conformance checker like MediaConch indicates that the file has a problem if a CRC is not the expected one. The purpose is not especially to repair (this is not an error correction code), only to detect integrity issues, but there is a proof of concept of repairing a bit flip based on CRC at https://mediaarea.net/MediaConch/Documentation/Fixity > 4. Is bitstream parameters such as version, > micor-version,num_h_slices,num_v_slices sensitity information that can > disclosed? any security risk? All these parameters are needed for setting up the decoder, and they are not sensitive, it i just a configuration of the bitstream (for example an higher minor_version could indicate that there is an extra field after the configuration but would not indicate the encoder name). We documented the security risks we know in the security section (updated through https://mailarchive.ietf.org/arch/msg/cellar/XVidil8tTd7eNoGmTCQPOI_C-sA/ after a remark from Secdir), and the decoder is expected to reject incoherent values e.g. num_h_slices bigger than pixel width. Jérôme From nobody Sun Sep 6 10:31:51 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A123A102F for ; Sun, 6 Sep 2020 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qy68SXt0fdob for ; Sun, 6 Sep 2020 10:31:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011B63A102E for ; Sun, 6 Sep 2020 10:31:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C6CC389BD; Sun, 6 Sep 2020 13:09:56 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UnLUTrXpLRxP; Sun, 6 Sep 2020 13:09:55 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B8C7389B4; Sun, 6 Sep 2020 13:09:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0E1D7FB; Sun, 6 Sep 2020 13:31:03 -0400 (EDT) From: Michael Richardson To: Jerome Martinez cc: cellar@ietf.org In-Reply-To: References: <159938093648.7188.7752393359382713628@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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 Sep 2020 17:31:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for the great response Jerome! =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9VHNYACgkQgItw+93Q 3WVq8wf+P0Ft/2QX1gIbmJLu25ryoT83wFq+u6DDDX8JSAMO3+/Al87kQh3QG/sP Z/dgtI0HwhMSMdtmMYNN0Xj+fZ3oL9UxbYYHv3uDdRSsc8TSRpkykw5FwRbSgjJW Rf/bVz7GDfD7ptF41xu+axaYoQ+pRPRSfneE7OvsGQZuPIZ33fKttlSdzclD6+2R VayvIU3dry3ZYK0u+BsM+XYiZtIqM+dSk2IFVgJ+VooM1JET6BAzDdaWWQ25H44f vxY7ypLSHpnAqUpuxA0Mpl2Teuv73e1gS2L70TfdjDlNBYrm5Gj2/5XISjqHf5ba cfHYsF6NDDbkpip0QZjO3oR9YygSQQ== =bom+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Sep 6 19:29:10 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76813A1404; Sun, 6 Sep 2020 19:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 xQLdexvylYJn; Sun, 6 Sep 2020 19:29:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AE07B3A1400; Sun, 6 Sep 2020 19:29:05 -0700 (PDT) Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 648F9D666DA1C035E49C; Mon, 7 Sep 2020 03:29:04 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 7 Sep 2020 03:29:04 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 7 Sep 2020 03:29:03 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.186]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 7 Sep 2020 10:28:57 +0800 From: Qin Wu To: Jerome Martinez , "ops-dir@ietf.org" CC: "last-call@ietf.org" , "cellar@ietf.org" , "draft-ietf-cellar-ffv1.all@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-cellar-ffv1-17 Thread-Index: AdaEvHLbKy+w4BDOQSGasCL9iR9XPA== Date: Mon, 7 Sep 2020 02:28:57 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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, 07 Sep 2020 02:29:08 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBKZXJvbWUgTWFydGluZXogW21haWx0 bzpqZXJvbWVAbWVkaWFhcmVhLm5ldF0gDQrlj5HpgIHml7bpl7Q6IDIwMjDlubQ55pyINuaXpSAx ODo1NQ0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IG9wcy1kaXJAaWV0 Zi5vcmcNCuaKhOmAgTogbGFzdC1jYWxsQGlldGYub3JnOyBjZWxsYXJAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtY2VsbGFyLWZmdjEuYWxsQGlldGYub3JnDQrkuLvpopg6IFJlOiBPcHNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWNlbGxhci1mZnYxLTE3DQoNCkhpIFFpbiwNCg0KVGhh bmsgeW91IGZvciB5b3VyIHJldmlldywgYW5zd2VycyBpbmxpbmU6DQoNCk9uIDA2LzA5LzIwMjAg MTA6MjgsIFFpbiBXdSB2aWEgRGF0YXRyYWNrZXIgd3JvdGU6DQo+IFJldmlld2VyOiBRaW4gV3UN Cj4gUmV2aWV3IHJlc3VsdDogUmVhZHkNCj4NCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1l bnQgb24gYmVoYWxmIG9mIHRoZSBPcGVyYXRpb25zIGFuZCANCj4gTWFuYWdlbWVudCBEaXJlY3Rv cmF0ZS4gRm91ciBxdWVzdGlvbnMgIG5lZWQgdG8gYmUgY2xhcmlmaWVk77yaIDEuIHdoeSANCj4g ZG9jdW1lbnQgdjAsdjEsdjMgaW4NCj4gZHJhZnQtaWV0Zi1jZWxsYXItZmZ2MSBhcyBpbmZvcm1h dGlvbmFsIGFuZCBkb2N1bWVudCB2NCBpbg0KPiBkcmFmdC1pZXRmLWNlbGxhci1mZnYxLXY0LTE0 IGFzIHN0YW5kYXJkIHRyYWNrPyBOb3QgY2xlYXIgdGhlIGtleSANCj4gZGlmZmVyZW5jZSBiZXR3 ZWVuIHYwNCBhbmQgYWxsIG90aGVyIHByZXZpb3VzIHZlcnNpb25zPw0KDQp2MCx2MSx2MyBiaXRz dHJlYW1zIGFyZSBhbHJlYWR5IGluIHRoZSB3aWxkLCB0aGUgRkZWMSB2MCx2MSx2MyBzcGVjaWZp Y2F0aW9uIGRvY3VtZW50cyB3aGF0IGlzIGFscmVhZHkgaW4gdXNlIGFuZCB3ZSBhZGFwdCB0aGUg c3BlY2lmaWNhdGlvbiAoaW5jbHVkaW5nIGRvY3VtZW50aW5nIGlzc3VlcyBmb3VuZCBkdXJpbmcg dGhlIHJldmlldyBvZiB0aGUgZW5jb2RlcnMgYW5kIGRlY29kZXJzKSB0byB0aGUgYml0c3RyZWFt IGluIHRoZSB3aWxkIGluc3RlYWQgb2YgYSBjbGVhbiBjaGFuZ2Ugb2YgdGhlIGJpc3RyZWFtIHdo ZW4gYW4gaXNzdWUgaXMgZm91bmQsIHRoaXMgaXMgbm90IHJlYWxseSBhIHN0YW5kYXJkIHdpdGgg YSBjb25zZW5zdXMgZHVyaW5nIHRoZSB3cml0aW5nIG9mIHRoZSBzcGVjaWZpY2F0aW9uLCB0aGUg Y2hvaWNlIHdhcyB0byBoYXZlIGluZm9ybWF0aW9uYWwgc3RhdHVzIGR1ZSB0byB0aGlzLg0KDQpG RlYxIHY0IGlzIG5vdCBpbiB0aGUgd2lsZCAodGhlIG9ubHkgZW5jb2RlciBhYmxlIHRvIGNyZWF0 ZSBzdWNoIGJpdHN0cmVhbSBuZWVkIHRvIHJlY2VpdmUgYSAiZXhwZXJpbWVudGFsIiBmbGFnIGlu IG9yZGVyIHRvIGNyZWF0ZSBzdWNoIGJpdHN0cmVhbSksIGl0IGlzIGEgZnV0dXJlIHNwZWNpZmlj YXRpb24sIGNsZWFuLCBhbmQgd2UnbGwgYWRhcHQgdGhlIGVuY29kZXJzL2RlY29kZXJzIHRvIHRo ZSBkZWNpZGVkIHNwZWNpZmljYXRpb24sIHNvIHN0YW5kYXJkIHN0YXR1cy4gTm90ZSB0aGF0IHY0 IGkgYmFzZWQgb24gdjAsdjEsdjMgc28gZXZvbHZlcyBhdCB0aGUgc2FtZSB0aW1lIGJ1dCBpcyBu b3QgcmVhZHkgYW5kIG5vdCBwYXJ0IG9mIHRoaXMgbGFzdCBjYWxsIHJldmlldy4NCg0KW1Fpbl06 IEkgZ2V0IGltcHJlc3Npb24geW91IGNoYW5nZSB1cGRhdGUgUkZDIHByb2Nlc3MsIHVzdWFsbHkg d2UgaGF2ZSBleGlzdGluZywgcHVibGlzaGVkIFJGQyBmaXJzdCwgYW5kIHRoZW4gbWFrZSBiaXMg ZG9jdW1lbnQgYW5kIHJldmlzZSB0aGUgZXhpc3RpbmcgUkZDLCBub3cgeW91IHByb2dyZXNzIG11 bHRpcGxlIHJlbGVhc2UgaW4gcGFyYWxsZWwsIHdoaWNoIGlzIHNvbWV0aGluZyBJIGhhdmVuJ3Qg c2VlbiBiZWZvcmUuDQpBbnl3YXksIHRoaXMgaXMgV0cgZGVjaXNpb24sIHdoaWNoIEkgaGF2ZSBu byBzdHJvbmcgb3BpbmlvbiBvbiB0aGlzLg0KPiAgIDIuIFdoeSBub3Qgc3BlY2lmeSB0cmFuc3Bv cnQsIGlzDQo+IGNvbnRhaW5lciBzdG8gd2hpY2ggdGhlIGZmdjEgaXMgbWFwcGVkIGVxdWl2YWxl bnQgdG8gdHJhbnNwb3J0PyANCj4gd2l0aG91dCB0cmFuc3BvcnQsIGhvdyB0byBwcm92aWRlIGNv bmZpZGVudGlhbGl0eSwgaW50ZWdyaXR5LCBhbmQgc291cmNlIGF1dGhlbnRpY2l0eT8NCg0KRkZW MSBpcyBhIHZpZGVvIGNvZGluZyBmb3JtYXQsIGxpa2UgT3B1cyBpcyBhbiBhdWRpbyBjb2Rpbmcg Zm9ybWF0LCBPcHVzIGRvZXMgbm90IHNwZWNpZnkgdHJhbnNwb3J0IHRvby4gRkZWMSBpcyBpbnRl bmRlZCB0byBiZSBlbmNhcHN1bGF0ZWQgaW4gYSBjb250YWluZXIgYW5kIHdlIGRvbid0IGZlZWwg dGhlIG5lZWQgdG8gaGF2ZSBhIGRlZGljYXRlZCB0cmFuc3BvcnQgZm9yIEZGVjEsIHdlIHVzZSAo ZGUgZmFjdG8gb3Igbm90KSBzdGFuZGFyZCBsaWtlIE1QNCAoSVNPIHN0YW5kYXJkKSBvciBNYXRy b3NrYSAoZGUgZmFjdG8gc3RhbmRhcmQgYW5kIElFVEYgc3RhbmRhcmQgY2FuZGlkYXRlKSBmb3Ig dGhlIHRyYW5zcG9ydC4gTm90ZSB0aGF0IE9wdXMgaXMgYW4gSUVURiBzdGFuZGFyZCAoUkZDIDY3 MTYpIHdpdGhvdXQgdHJhbnNwb3J0Lg0KDQpbUWluXTogV2UgYWxzbyBzZWUgT1BVUyB3aXRoIFJU UCB0cmFuc3BvcnQgaGFzIGJlZW4gcHVibGlzaGVkIGFzIFJGQzc1ODcuIEFueXdheSBJIGxlYXZl IHRoaXMgaXNzdWUgdG8geW91Lg0KDQpDb25maWRlbnRpYWxpdHksIGludGVncml0eSwgYW5kIHNv dXJjZSBhdXRoZW50aWNpdHkgaXMgZGVsZWdhdGVkIHRvIHRoZSB0cmFuc3BvcnQgbGF5ZXIsIGFz IGl0IGlzIHRoZSBjYXNlIHdpdGggT3B1cyBvciBtYW55IG90aGVyIGNvZGluZyBmb3JtYXRzLg0K DQoNCj4gMy4gaG93IGVycm9yX3N0YXR1cyBhbmQgY3JjIHBhcml0eSBhcmUgdXNlZD8gZS5nLiwg dXNpbmcgY3JjIHBhcml0eSBkZXRlY3QNCj4gZXJyb3I/IGNhbiBlcnJvciBiZSByZXBhaXJlZD8g aG93Pw0KDQplcnJvcl9zdGF0dXMgd2FzIGludGVuZGVkIGZvciBzdG9yaW5nIGluZm9ybWF0aW9u IGFib3V0IGVycm9ycyBmb3VuZCBpbiANCnRoZSBiaXRzdHJlYW0sIEFGQUlLIGl0IGlzIG5vdCB1 c2VkIGluIGFueSBlbmNvZGVyIG9yIGRlY29kZXIgZm9yIA0KZmlsbGluZyAoaXQgaXMgYWx3YXlz IDApIG9yIHJlYWRpbmcgKHZhbHVlIGRpc2NhcmRlZCkgdGhpcyB2YWx1ZSBidXQgdGhlIA0KaW5m b3JtYWwgc3BlY2lmaWNhdGlvbiBoYXMgYWx3YXlzIHBsYW5uZWQgdGhpcyBieXRlIGZvciBlcnJv ciBzdGF0dXMgc28gDQp3ZSBjdXJyZW50bHkga2VlcCBpdCBhcyBpbnN0ZWFkIG9mIGZsYWdnaW5n IGl0IGUuZyBhcyAicmVzZXJ2ZWQiLiBXZSBjYW4gDQpub3QgcmVtb3ZlIGl0IGZyb20gdGhlIGJp dHN0cmVhbSBhcyB3ZSBkb2N1bWVudCB3aGF0IGlzIGFscmVhZHkgaW4gdXNlIA0KaW4gdjAsdjEs djMuDQoNCmNyYyBwYXJpdHkgaXMgdXNlZCBmb3IgZGV0ZWN0aW5nIGEgdHJhbnNwb3J0IG9yIHN0 b3JhZ2UgZXJyb3IsIGluIG9yZGVyIA0KdG8gZGV0ZWN0IHRoYXQgbG9zc2xlc3NuZXNzIGlzIGNv bXByb21pc2VkIGJ5IGFuIHVuaW50ZW50aW9uYWwgY2hhbmdlLg0KdGhlIHJlZmVyZW5jZSBkZWNv ZGVyIChGRm1wZWcpIGZpcnN0IGNvbXB1dGVzIHRoZSBDUkMgYW5kIHJlamVjdHMgdGhlIA0Kc2xp Y2UgaWYgYSBDUkMgaXMgbm90IHRoZSBleHBlY3RlZCBvbmUgYmVmb3JlIHRyeWluZyB0byBkZWNv ZGUsIGFuZCBhIA0KY29uZm9ybWFuY2UgY2hlY2tlciBsaWtlIE1lZGlhQ29uY2ggaW5kaWNhdGVz IHRoYXQgdGhlIGZpbGUgaGFzIGEgDQpwcm9ibGVtIGlmIGEgQ1JDIGlzIG5vdCB0aGUgZXhwZWN0 ZWQgb25lLg0KDQpUaGUgcHVycG9zZSBpcyBub3QgZXNwZWNpYWxseSB0byByZXBhaXIgKHRoaXMg aXMgbm90IGFuIGVycm9yIGNvcnJlY3Rpb24gDQpjb2RlKSwgb25seSB0byBkZXRlY3QgaW50ZWdy aXR5IGlzc3VlcywgYnV0IHRoZXJlIGlzIGEgcHJvb2Ygb2YgY29uY2VwdCANCm9mIHJlcGFpcmlu ZyBhIGJpdCBmbGlwIGJhc2VkIG9uIENSQyBhdCANCmh0dHBzOi8vbWVkaWFhcmVhLm5ldC9NZWRp YUNvbmNoL0RvY3VtZW50YXRpb24vRml4aXR5DQoNCltRaW5dOiBHb29kLCB0aGFua3MgZm9yIHlv dXIgY2xhcmlmaWNhdGlvbi4NCg0KPiAgIDQuIElzIGJpdHN0cmVhbSBwYXJhbWV0ZXJzIHN1Y2gg YXMgdmVyc2lvbiwNCj4gbWljb3ItdmVyc2lvbixudW1faF9zbGljZXMsbnVtX3Zfc2xpY2VzIHNl bnNpdGl0eSBpbmZvcm1hdGlvbiB0aGF0IGNhbg0KPiBkaXNjbG9zZWQ/IGFueSBzZWN1cml0eSBy aXNrPw0KDQpBbGwgdGhlc2UgcGFyYW1ldGVycyBhcmUgbmVlZGVkIGZvciBzZXR0aW5nIHVwIHRo ZSBkZWNvZGVyLCBhbmQgdGhleSBhcmUgDQpub3Qgc2Vuc2l0aXZlLCBpdCBpIGp1c3QgYSBjb25m aWd1cmF0aW9uIG9mIHRoZSBiaXRzdHJlYW0gKGZvciBleGFtcGxlIA0KYW4gaGlnaGVyIG1pbm9y X3ZlcnNpb24gY291bGQgaW5kaWNhdGUgdGhhdCB0aGVyZSBpcyBhbiBleHRyYSBmaWVsZCANCmFm dGVyIHRoZSBjb25maWd1cmF0aW9uIGJ1dCB3b3VsZCBub3QgaW5kaWNhdGUgdGhlIGVuY29kZXIg bmFtZSkuDQoNCg0KW1Fpbl06IHdoaWNoIHByb3RvY29sIGlzIHVzZWQgdG8gY29uZmlndXJlIHRo ZXNlIHBhcmFtZXRlcnM/IEhvdyBkbyB5b3UgcHJldmVudCBtaXNjb25maWd1cmF0aW9uIGZyb20g bWFsaWNpb3VzIGNsaWVudD8NCg0KV2UgZG9jdW1lbnRlZCB0aGUgc2VjdXJpdHkgcmlza3Mgd2Ug a25vdyBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiANCih1cGRhdGVkIHRocm91Z2ggDQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2NlbGxhci9YVmlkaWw4dFRkN2VOb0dtVENR UE9JX0Mtc0EvIA0KYWZ0ZXIgYSByZW1hcmsgZnJvbSBTZWNkaXIpLCBhbmQgdGhlIGRlY29kZXIg aXMgZXhwZWN0ZWQgdG8gcmVqZWN0IA0KaW5jb2hlcmVudCB2YWx1ZXMgZS5nLiBudW1faF9zbGlj ZXMgYmlnZ2VyIHRoYW4gcGl4ZWwgd2lkdGguDQoNCkrDqXLDtG1lDQoNCg== From nobody Sun Sep 6 19:40:39 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954BD3A13BB; Sun, 6 Sep 2020 19:40:37 -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 LQiBER7LosOM; Sun, 6 Sep 2020 19:40:34 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AF33A13AB; Sun, 6 Sep 2020 19:40:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CC740389C1; Sun, 6 Sep 2020 22:19:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m5qsfq5wZnV0; Sun, 6 Sep 2020 22:19:22 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5644C389BD; Sun, 6 Sep 2020 22:19:22 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A4DCA4D7; Sun, 6 Sep 2020 22:40:30 -0400 (EDT) From: Michael Richardson To: Qin Wu cc: Jerome Martinez , "ops-dir\@ietf.org" , "last-call\@ietf.org" , "draft-ietf-cellar-ffv1.all\@ietf.org" , "cellar\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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, 07 Sep 2020 02:40:38 -0000 <#secure method=3Dpgpmime mode=3Dsign> Qin Wu wrote: > [Qin]: I get impression you change update RFC process, usually we have > existing, published RFC first, and then make bis document and revise > the existing RFC, now you progress multiple release in parallel, which > is something I haven't seen before. There are many processes. The IETF has often published an Informational draft on an existing "defacto" specification that is unchangeable because it is already deployed. I believe this happened for POP3, IMAP, HTTP 0.9, and a number of other well known protocols. Then we do "v2.0" which is standards track, and which is subject to IETF change control. Except that this time, it is 4.0 not 2.0. [In fact, there is no v2 for ffv because it never got deployed] (Such a process was not done, btw. for TACACS for reasons that were never adequately explained to me) jerome> FFV1 is a video coding format, like Opus is an audio coding jerome> format, Opus does not specify transport too. FFV1 is intended to jerome> be encapsulated in a container and we don't feel the need to ha= ve jerome> a dedicated transport for FFV1, we use (de facto or not) standa= rd jerome> like MP4 (ISO standard) or Matroska (de facto standard and IETF jerome> standard candidate) for the transport. Note that Opus is an IETF jerome> standard (RFC 6716) without transport. > [Qin]: We also see OPUS with RTP transport has been published as > RFC7587. Anyway I leave this issue to you. Yes, but RFC7587 does not define the OPUS CODEC. The OPUS Codec is defined in RFC6716. RFC7587 defines how to carry RFC6716 transmissions in RFC3550 format. We have a document, draft-ietf-cellar-matroska, which is a bit equivalent t= o RFC7587. But, not involving RTP. If there were interest in using ffv4 in the future over RTP, then we'd have to explain how to do that. CELLAR is focused on archival needs, not real time needs. > [Qin]: which protocol is used to configure these parameters? How do y= ou > prevent misconfiguration from malicious client? First, it's a data format, not a protocol. So there is no configuration or negotiation involved. The chosen parameters are either valid, and the decoder can deal with them, or it can't. -- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide From nobody Sun Sep 6 19:53:58 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33DD3A1445; Sun, 6 Sep 2020 19:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 2Ff9qH7uY-WS; Sun, 6 Sep 2020 19:53:55 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 280783A1444; Sun, 6 Sep 2020 19:53:55 -0700 (PDT) Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1C833A2A0AFDC47F1A67; Mon, 7 Sep 2020 03:53:52 +0100 (IST) Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 7 Sep 2020 03:53:51 +0100 Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 7 Sep 2020 03:53:51 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.186]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Mon, 7 Sep 2020 10:53:46 +0800 From: Qin Wu To: Michael Richardson CC: Jerome Martinez , "ops-dir@ietf.org" , "last-call@ietf.org" , "draft-ietf-cellar-ffv1.all@ietf.org" , "cellar@ietf.org" Thread-Topic: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 Thread-Index: AdaEwa1X1/v+oztpQ/KoO4IbPmC/Uw== Date: Mon, 7 Sep 2020 02:53:45 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17 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, 07 Sep 2020 02:53:57 -0000 LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBNaWNoYWVsIFJpY2hhcmRzb24gW21h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdIA0K5Y+R6YCB5pe26Ze0OiAyMDIw5bm0OeaciDfm l6UgMTA6NDENCuaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+DQrmioTpgIE6 IEplcm9tZSBNYXJ0aW5leiA8amVyb21lQG1lZGlhYXJlYS5uZXQ+OyBvcHMtZGlyQGlldGYub3Jn OyBsYXN0LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtY2VsbGFyLWZmdjEuYWxsQGlldGYub3Jn OyBjZWxsYXJAaWV0Zi5vcmcNCuS4u+mimDogUmU6IFtDZWxsYXJdIE9wc2RpciBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtY2VsbGFyLWZmdjEtMTcNCg0KDQo8I3NlY3VyZSBtZXRob2Q9 cGdwbWltZSBtb2RlPXNpZ24+DQoNClFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPiB3cm90ZToN CiAgICA+IFtRaW5dOiBJIGdldCBpbXByZXNzaW9uIHlvdSBjaGFuZ2UgdXBkYXRlIFJGQyBwcm9j ZXNzLCB1c3VhbGx5IHdlIGhhdmUNCiAgICA+IGV4aXN0aW5nLCBwdWJsaXNoZWQgUkZDIGZpcnN0 LCBhbmQgdGhlbiBtYWtlIGJpcyBkb2N1bWVudCBhbmQgcmV2aXNlDQogICAgPiB0aGUgZXhpc3Rp bmcgUkZDLCBub3cgeW91IHByb2dyZXNzIG11bHRpcGxlIHJlbGVhc2UgaW4gcGFyYWxsZWwsIHdo aWNoDQogICAgPiBpcyBzb21ldGhpbmcgSSBoYXZlbid0IHNlZW4gYmVmb3JlLg0KDQpUaGVyZSBh cmUgbWFueSBwcm9jZXNzZXMuDQpUaGUgSUVURiBoYXMgb2Z0ZW4gcHVibGlzaGVkIGFuIEluZm9y bWF0aW9uYWwgZHJhZnQgb24gYW4gZXhpc3RpbmcgImRlZmFjdG8iIHNwZWNpZmljYXRpb24gdGhh dCBpcyB1bmNoYW5nZWFibGUgYmVjYXVzZSBpdCBpcyBhbHJlYWR5IGRlcGxveWVkLg0KSSBiZWxp ZXZlIHRoaXMgaGFwcGVuZWQgZm9yIFBPUDMsIElNQVAsIEhUVFAgMC45LCBhbmQgYSBudW1iZXIg b2Ygb3RoZXIgd2VsbCBrbm93biBwcm90b2NvbHMuDQoNClRoZW4gd2UgZG8gInYyLjAiIHdoaWNo IGlzIHN0YW5kYXJkcyB0cmFjaywgYW5kIHdoaWNoIGlzIHN1YmplY3QgdG8gSUVURiBjaGFuZ2Ug Y29udHJvbC4gIEV4Y2VwdCB0aGF0IHRoaXMgdGltZSwgaXQgaXMgNC4wIG5vdCAyLjAuDQpbSW4g ZmFjdCwgdGhlcmUgaXMgbm8gdjIgZm9yIGZmdiBiZWNhdXNlIGl0IG5ldmVyIGdvdCBkZXBsb3ll ZF0NCg0KKFN1Y2ggYSBwcm9jZXNzIHdhcyBub3QgZG9uZSwgYnR3LiBmb3IgVEFDQUNTIGZvciBy ZWFzb25zIHRoYXQgd2VyZSBuZXZlciBhZGVxdWF0ZWx5IGV4cGxhaW5lZCB0byBtZSkNCltRaW5d OiBHb29kIGNsYXJpZmljYXRpb24sIHRoYW5rcyBNaWNoYWxlLg0KICAgIGplcm9tZT4gRkZWMSBp cyBhIHZpZGVvIGNvZGluZyBmb3JtYXQsIGxpa2UgT3B1cyBpcyBhbiBhdWRpbyBjb2RpbmcNCiAg ICBqZXJvbWU+IGZvcm1hdCwgT3B1cyBkb2VzIG5vdCBzcGVjaWZ5IHRyYW5zcG9ydCB0b28uIEZG VjEgaXMgaW50ZW5kZWQgdG8NCiAgICBqZXJvbWU+IGJlIGVuY2Fwc3VsYXRlZCBpbiBhIGNvbnRh aW5lciBhbmQgd2UgZG9uJ3QgZmVlbCB0aGUgbmVlZCB0byBoYXZlDQogICAgamVyb21lPiBhIGRl ZGljYXRlZCB0cmFuc3BvcnQgZm9yIEZGVjEsIHdlIHVzZSAoZGUgZmFjdG8gb3Igbm90KSBzdGFu ZGFyZA0KICAgIGplcm9tZT4gbGlrZSBNUDQgKElTTyBzdGFuZGFyZCkgb3IgTWF0cm9za2EgKGRl IGZhY3RvIHN0YW5kYXJkIGFuZCBJRVRGDQogICAgamVyb21lPiBzdGFuZGFyZCBjYW5kaWRhdGUp IGZvciB0aGUgdHJhbnNwb3J0LiBOb3RlIHRoYXQgT3B1cyBpcyBhbiBJRVRGDQogICAgamVyb21l PiBzdGFuZGFyZCAoUkZDIDY3MTYpIHdpdGhvdXQgdHJhbnNwb3J0Lg0KDQogICAgPiBbUWluXTog V2UgYWxzbyBzZWUgT1BVUyB3aXRoIFJUUCB0cmFuc3BvcnQgaGFzIGJlZW4gcHVibGlzaGVkIGFz DQogICAgPiBSRkM3NTg3LiBBbnl3YXkgSSBsZWF2ZSB0aGlzIGlzc3VlIHRvIHlvdS4NCg0KWWVz LCBidXQgUkZDNzU4NyBkb2VzIG5vdCBkZWZpbmUgdGhlIE9QVVMgQ09ERUMuDQpUaGUgT1BVUyBD b2RlYyBpcyBkZWZpbmVkIGluIFJGQzY3MTYuDQoNClJGQzc1ODcgZGVmaW5lcyBob3cgdG8gY2Fy cnkgUkZDNjcxNiB0cmFuc21pc3Npb25zIGluIFJGQzM1NTAgZm9ybWF0Lg0KV2UgaGF2ZSBhIGRv Y3VtZW50LCBkcmFmdC1pZXRmLWNlbGxhci1tYXRyb3NrYSwgd2hpY2ggaXMgYSBiaXQgZXF1aXZh bGVudCB0byBSRkM3NTg3Lg0KQnV0LCBub3QgaW52b2x2aW5nIFJUUC4gIElmIHRoZXJlIHdlcmUg aW50ZXJlc3QgaW4gdXNpbmcgZmZ2NCBpbiB0aGUgZnV0dXJlIG92ZXIgUlRQLCB0aGVuIHdlJ2Qg aGF2ZSB0byBleHBsYWluIGhvdyB0byBkbyB0aGF0Lg0KQ0VMTEFSIGlzIGZvY3VzZWQgb24gYXJj aGl2YWwgbmVlZHMsIG5vdCByZWFsIHRpbWUgbmVlZHMuDQoNCltRaW5dOk5vdCBteSBzdWdnZXN0 aW9uIHRvIHN1cHBvcnQgUlRQLCBqdXN0IHByb3ZpZGUgYW5hbG9neS4gWW91ciBjbGFyaWZpY2F0 aW9uIGxvb2tzIGdvb2QgdG8gbWUgbm93LiBUaGFua3MuDQoNCiAgICA+IFtRaW5dOiB3aGljaCBw cm90b2NvbCBpcyB1c2VkIHRvIGNvbmZpZ3VyZSB0aGVzZSBwYXJhbWV0ZXJzPyBIb3cgZG8geW91 DQogICAgPiBwcmV2ZW50IG1pc2NvbmZpZ3VyYXRpb24gZnJvbSBtYWxpY2lvdXMgY2xpZW50Pw0K DQpGaXJzdCwgaXQncyBhIGRhdGEgZm9ybWF0LCBub3QgYSBwcm90b2NvbC4NClNvIHRoZXJlIGlz IG5vIGNvbmZpZ3VyYXRpb24gb3IgbmVnb3RpYXRpb24gaW52b2x2ZWQuDQoNClRoZSBjaG9zZW4g cGFyYW1ldGVycyBhcmUgZWl0aGVyIHZhbGlkLCBhbmQgdGhlIGRlY29kZXIgY2FuIGRlYWwgd2l0 aCB0aGVtLCBvciBpdCBjYW4ndC4NCltRaW5dOiBHb29kIGV4cGxhbmF0aW9uLCB0aGUgd29yZCAi Y29uZmlndXJhdGlvbiIgY29uZnVzZXMgbWUgYSBsb3QsIHdoaWNoIG1ha2UgbWUgd29uZGVyIHdo byBnZW5lcmF0ZSBjb25maWd1cmF0aW9uLCB3aG8gaW5zdGFsbCBjb25maWd1cmF0aW9uLCB3aGVy ZSB0aGVzZSBjb25maWd1cmF0aW9uIGlzIGV4ZWN1dGVkLg0KLS0NCk1pY2hhZWwgUmljaGFyZHNv biA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcg KQ0KICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdv cmxkd2lkZQ0K From nobody Mon Sep 7 06:56:53 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52953A0D42 for ; Mon, 7 Sep 2020 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHf6q0rsXK_2 for ; Mon, 7 Sep 2020 06:56:49 -0700 (PDT) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 53CC13A0D41 for ; Mon, 7 Sep 2020 06:56:49 -0700 (PDT) Received: from cpe-69-203-78-204.nyc.res.rr.com ([69.203.78.204]:64074 helo=[192.168.0.177]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kFHdT-004Lwg-EH; Mon, 07 Sep 2020 09:56:48 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_1465C232-E660-45C3-B41B-28B76F92814D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 7 Sep 2020 09:56:42 -0400 References: To: Codec Encoding for LossLess Archiving and Realtime transmission , cellar-wg/matroska-specification In-Reply-To: Message-Id: <43E3FC4D-855C-4067-A58A-F2EAB3470A9B@dericed.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [cellar-wg/matroska-specification] Consider providing a facility for integer-fraction timescales (#422) 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, 07 Sep 2020 13:56:52 -0000 --Apple-Mail=_1465C232-E660-45C3-B41B-28B76F92814D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I see this was brought up as an issue in the GitHub repository and am = cross-posting to the cellar working group. > On Sep 7, 2020, at 12:02 AM, rcombs wrote: > It's pretty well-established that Matroska's poor timebase support is = one of the format's worst properties. While it support very precise = timestamps (down to the nanosecond), it's very inefficient to do so (and = the resulting values still aren't exact for most input rates), so muxers = tend to default to 1ms timestamps, which can lead to a variety of subtle = issues, especially with high-packet-rate streams (e.g. audio) and VFR = video content. Muxers can choose rates that are closer to the time base = of their inputs (or the packet rate of the content), but exactly how = best to do so has always been unclear, and some of the possible options = would lead to either worse player behavior, or timestamp drift. I'm = proposing a format addition to remedy this. >=20 > The only actual normative change I propose is this: in addition to the = classic nanosecond-denominator time scale, muxers could provide 2 = additional integers, serving as a numerator and denominator time base = value, which is required to round to the existing nanosecond-scaled = value. >=20 > This should be paired with some advice for muxer implementations on = how to make use of this feature. This depends on the properties of the = input. For reference, here are some examples of the error produced by = rounding a variety of common time bases to the nearest nanosecond, = scaled by 3 hours (a reasonable target for the duration of a film): >=20 > nearest_ns(x) =3D round(x * 1,000,000,000) / 1,000,000,000 > ceil_ns(x) =3D ceil(x * 1,000,000,000) / 1,000,000,000 > floor_ns(x) =3D floor(x * 1,000,000,000) / 1,000,000,000 > nearest_error(x) =3D 1 - (x / nearest_ns(x)) > ceil_error(x) =3D 1 - (x / ceil_ns(x)) > floor_error(x) =3D 1 - (x / floor_ns(x)) > nearest_error_3h(x) =3D nearest_error(x) * 60 * 60 * 3 > ceil_error_3h(x) =3D ceil_error(x) * 60 * 60 * 3 > floor_error_3h(x) =3D floor_error(x) * 60 * 60 * 3 > e(x) =3D nearest_error_3h(1 / x) > ce(x) =3D ceil_error_3h(1 / x) > fe(x) =3D floor_error_3h(1 / x) >=20 > # Integer video frame rates > e(24) =3D> 8.64e-5 > e(25) =3D> 0 > e(30) =3D> -0.0001 > e(48) =3D> -0.0002 > e(50) =3D> 0 > e(60) =3D> 0.0002 > e(120) =3D> -0.0004 >=20 > # NTSC video frame rates > e(24/1.001) =3D> -8.6314e-5 > e(30/1.001) =3D> 0.0001 > e(48/1.001) =3D> 0.0002 > e(60/1.001) =3D> -0.0002 > e(120/1.001) =3D> 0.0004 >=20 > # TrueHD frame rates > e(44100/40) =3D> -0.0057 > e(48000/40) =3D> -0.0043 > e(88200/40) =3D> 0.0062 > e(96000/40) =3D> 0.0086 >=20 > # AAC frame rates > e(44100/960) =3D> -0.0002 > e(48000/960) =3D> 0 > e(88200/960) =3D> 0.0003 > e(96000/960) =3D> 0 > e(44100/1024) =3D> 0.0002 > e(48000/1024) =3D> -0.0002 > e(88200/1024) =3D> -0.0003 > e(96000/1024) =3D> 0.0003 >=20 > # MP3 frame rates > e(44100/1152) =3D> 8.4375e-6 > e(48000/1152) =3D> 0 > e(88200/1152) =3D> -0.0004 > e(96000/1152) =3D> 0 >=20 > # Other audio frame rates > e(44100/128) =3D> -0.0012 > e(48000/128) =3D> 0.0013 > e(88200/128) =3D> -0.0012 > e(96000/128) =3D> -0.0027 > e(44100/2880) =3D> -7.425e-5 > e(48000/2880) =3D> 2.3981e-12 > e(88200/2880) =3D> -7.425e-5 > e(96000/2880) =3D> 2.3981e-12 >=20 > # GCF of common short-first audio frame sizes > e(44100/64) =3D> -0.0012 > e(48000/64) =3D> -0.0027 > e(88200/64) =3D> 0.0062 > e(96000/64) =3D> 0.0054 >=20 > # Raw audio sample rates > e(44100) =3D> 0.1253 > e(48000) =3D> -0.1728 > e(88200) =3D> 0.1253 > e(96000) =3D> 0.3456 >=20 > fe(44100) =3D> -0.351 > ce(48000) =3D> 0.3456 > fe(88200) =3D> -0.8273 > fe(96000) =3D> -0.6912 >=20 > # MPEGTS time base > e(90000) =3D> -0.108 >=20 > ce(90000) =3D> 0.8639 >=20 > # Common multiples > e(30000) =3D> -0.108 > e(60000) =3D> 0.216 > e(120000) =3D> -0.432 > e(240000) =3D> 0.8639 > e(480000) =3D> -1.7283 >=20 > ce(30000) =3D> 0.216 > fe(60000) =3D> -0.432 > ce(120000) =3D> 0.8639 > fe(240000) =3D> -1.7283 > ce(480000) =3D> 3.4549 > As we can see, rounding common video and audio frame rates (including = e.g. the least common multiple of 24 and 60 for that VFR case) produces = a negligible amount of error over a reasonable duration. This means that = for content where all timestamps can reasonably be expressed in integer = values of those rates, there would be no significant error over common = file durations, even if different streams were muxed with different time = bases. >=20 > There are a few real-world time bases that would produce significant = rounding error (upwards of 100ms) over the course of 3 hours when used = in existing players: MPEGTS's 90000Hz, all common raw audio sample = rates, and least-common-multiples between integer and NTSC video frame = rates. This essentially means that mixing these rates with others would = produce significant desync over a reasonable duration for static on-disk = content; the same issue could occur when muxing very lengthy content = (e.g. streaming). >=20 > All of these issues can be addressed in one of the following ways: >=20 > Using a lower rate (e.g. 90,000Hz isn't usually the real content rate = but instead an artifact of its previous container; expressing timestamps = in samples rather than frames is usually unnecessary) > Choosing the highest of the input rates for all streams (e.g. 48000 is = a multiple of many common frame rates, including 24/1.001) > Choosing a more precise common-multiple rate that may create a larger = total drift, but does so equally for all streams (see the "Common = multiples" section; 1/30000 is suitable for mixing 24fps and 30/1.001fps = content alongside most common framed audio rates, while the later listed = bases are suitable for increasingly large sets). > Round some tracks' nanosecond timescales in the opposite direction, = creating a larger drift, but potentially one with the same sign (and = thus a closer value) as the drift in other tracks (this is probably too = complex and niche to have substantial use) > Fall back to classic rounded nanosecond-based timestamps (and don't = write an integer-fraction time base at all) > Use the extension, resulting in significant sync drift in older = players that haven't implemented the change > This last option is usually unacceptable, but may be fine for files = that use codecs that become available after the change is made (and thus = are unavoidably non-backwards-compatible anyway). >=20 > If combined with clear advice in the spec on how muxers SHOULD (or = MAY) decide on time bases for various possible input cases, I think this = extension could get actual adoption in muxers and solve one of the = format's longest-standing problems. >=20 This has been discussed on the list before though I don=E2=80=99t = remember clear consensus on how to address this. Steve even compiled a = list of discussions on this at = https://mailarchive.ietf.org/arch/msg/cellar/ZpZxhG1gML9xVx_ir1Jf6_gcI8U/ = . I proposed an option in this = https://mailarchive.ietf.org/arch/msg/cellar/mTprgjNqVbe20e6hyYxns8ZnVwY/ = where one of the existing reserved bits of the Block Header (in the = byte that contains the keyframe, invisible, and lacing flags) be used as = a flag for Timescale Alignment. With this approach, new elements could be added to the track header with = a numerator and denominator of a rationale time scale and if Timescale = Alignment were set to true, then the nearest increment of the rationale = time scale would be used. Example: > Thus if the frame rate of the track header is 120000/1001, then >=20 > If Matroska timecode is 4 and Enable TimeScale Alignment is 0, than it = is at 4 / (1000000000 / TimecodeScale ). > If Matroska timecode is 4 and Enable TimeScale Alignment is 1, than it = is at 0 / 1200000 (nearest increment of the rationale frame rate). >=20 > If Matroska timecode is 17 and Enable TimeScale Alignment is 0, than = it is at 17 / (1000000000 / TimecodeScale ). > If Matroska timecode is 17 and Enable TimeScale Alignment is 1, than = it is at 2002 / 1200000 (nearest increment of the rationale frame rate). In a Matroska demuxer doesn=E2=80=99t understand the new nom/denom = elements or the Alignment flag then it would simply use the existing = nanosecond timestamp system. In that thread there were other proposals, for example Steve discussed = using a float to depict a point in time. Dave= --Apple-Mail=_1465C232-E660-45C3-B41B-28B76F92814D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,
I see this was brought up as an issue in = the GitHub repository and am cross-posting to the cellar working = group.

On Sep 7, 2020, at 12:02 AM, rcombs <notifications@github.com> wrote:
It's pretty well-established that Matroska's poor timebase = support is one of the format's worst properties. While it support very = precise timestamps (down to the nanosecond), it's very inefficient to do = so (and the resulting values still aren't exact for most input rates), = so muxers tend to default to 1ms timestamps, which can lead to a variety = of subtle issues, especially with high-packet-rate streams (e.g. audio) = and VFR video content. Muxers can choose rates that = are closer to the time base of their inputs (or the packet rate of the = content), but exactly how best to do so has always been unclear, and = some of the possible options would lead to either worse player behavior, = or timestamp drift. I'm proposing a format addition to remedy = this.

The only actual normative change I propose is = this: in addition to the classic nanosecond-denominator time scale, = muxers could provide 2 additional integers, serving as a numerator and = denominator time base value, which is required to round to the existing = nanosecond-scaled value.

This should be paired with = some advice for muxer implementations on how to make use of this = feature. This depends on the properties of the input. For reference, = here are some examples of the error produced by rounding a variety of = common time bases to the nearest nanosecond, scaled by 3 hours (a = reasonable target for the duration of a film):

nearest_ns(x) =3D round(x * =
1,000,000,000) / 1,000,000,000
ceil_ns(x) =3D ceil(x * 1,000,000,000) / 1,000,000,000
floor_ns(x) =3D floor(x * 1,000,000,000) / 1,000,000,000
nearest_error(x) =3D 1 - (x / nearest_ns(x))
ceil_error(x) =3D 1 - (x / ceil_ns(x))
floor_error(x) =3D 1 - (x / floor_ns(x))
nearest_error_3h(x) =3D nearest_error(x) * 60 * 60 * 3
ceil_error_3h(x) =3D ceil_error(x) * 60 * 60 * 3
floor_error_3h(x) =3D floor_error(x) * 60 * 60 * 3
e(x) =3D nearest_error_3h(1 / x)
ce(x) =3D ceil_error_3h(1 / x)
fe(x) =3D floor_error_3h(1 / x)

# Integer video frame rates
e(24)        =3D> 8.64e-5
e(25)        =3D> 0
e(30)        =3D> -0.0001
e(48)        =3D> -0.0002
e(50)        =3D> 0
e(60)        =3D> 0.0002
e(120)       =3D> -0.0004

# NTSC video frame rates
e(24/1.001)  =3D> -8.6314e-5
e(30/1.001)  =3D> 0.0001
e(48/1.001)  =3D> 0.0002
e(60/1.001)  =3D> -0.0002
e(120/1.001) =3D> 0.0004

# TrueHD frame rates
e(44100/40)   =3D> -0.0057
e(48000/40)   =3D> -0.0043
e(88200/40)   =3D> 0.0062
e(96000/40)   =3D> 0.0086

# AAC frame rates
e(44100/960)  =3D> -0.0002
e(48000/960)  =3D> 0
e(88200/960)  =3D> 0.0003
e(96000/960)  =3D> 0
e(44100/1024) =3D> 0.0002
e(48000/1024) =3D> -0.0002
e(88200/1024) =3D> -0.0003
e(96000/1024) =3D> 0.0003

# MP3 frame rates
e(44100/1152)  =3D> 8.4375e-6
e(48000/1152)  =3D> 0
e(88200/1152)  =3D> -0.0004
e(96000/1152)  =3D> 0

# Other audio frame rates
e(44100/128)   =3D> -0.0012
e(48000/128)   =3D> 0.0013
e(88200/128)   =3D> -0.0012
e(96000/128)   =3D> -0.0027
e(44100/2880)  =3D> -7.425e-5
e(48000/2880)  =3D> 2.3981e-12
e(88200/2880)  =3D> -7.425e-5
e(96000/2880)  =3D> 2.3981e-12

# GCF of common short-first audio frame sizes
e(44100/64)   =3D> -0.0012
e(48000/64)   =3D> -0.0027
e(88200/64)   =3D> 0.0062
e(96000/64)   =3D> 0.0054

# Raw audio sample rates
e(44100)     =3D> 0.1253
e(48000)     =3D> -0.1728
e(88200)     =3D> 0.1253
e(96000)     =3D> 0.3456

fe(44100)    =3D> -0.351
ce(48000)    =3D> 0.3456
fe(88200)    =3D> -0.8273
fe(96000)    =3D> -0.6912

# MPEGTS time base
e(90000)     =3D> -0.108

ce(90000)    =3D> 0.8639

# Common multiples
e(30000)     =3D> -0.108
e(60000)     =3D> 0.216
e(120000)    =3D> -0.432
e(240000)    =3D> 0.8639
e(480000)    =3D> -1.7283

ce(30000)    =3D> 0.216
fe(60000)    =3D> -0.432
ce(120000)   =3D> 0.8639
fe(240000)   =3D> -1.7283
ce(480000)   =3D> 3.4549

As we can see, rounding common video and = audio frame rates (including e.g. the least common multiple of 24 and 60 = for that VFR case) produces a negligible amount of error over a = reasonable duration. This means that for content where all timestamps = can reasonably be expressed in integer values of those rates, there = would be no significant error over common file durations, even if = different streams were muxed with different time bases.

There are a few real-world time bases that would produce significant rounding error (upwards of = 100ms) over the course of 3 hours when used in existing players: = MPEGTS's 90000Hz, all common raw audio sample rates, and = least-common-multiples between integer and NTSC video frame rates. This = essentially means that mixing these rates with others would produce = significant desync over a reasonable duration for static on-disk = content; the same issue could occur when muxing very lengthy content = (e.g. streaming).

All of these issues can be addressed = in one of the following ways:

  • Using a lower rate (e.g. 90,000Hz isn't usually the real = content rate but instead an artifact of its previous container; = expressing timestamps in samples rather than frames is usually = unnecessary)
  • Choosing the highest of the input rates for all streams = (e.g. 48000 is a multiple of many common frame rates, including = 24/1.001)
  • Choosing a more precise common-multiple rate that may = create a larger total drift, but does so equally for all streams (see = the "Common multiples" section; 1/30000 is suitable for mixing 24fps and = 30/1.001fps content alongside most common framed audio rates, while the = later listed bases are suitable for increasingly large sets).
  • Round some tracks' nanosecond timescales in the opposite = direction, creating a larger drift, but potentially one with the same = sign (and thus a closer value) as the drift in other tracks (this is = probably too complex and niche to have substantial use)
  • Fall back to classic rounded nanosecond-based timestamps = (and don't write an integer-fraction time base at all)
  • Use the extension, resulting in significant sync drift in = older players that haven't implemented the change

This last option is usually unacceptable, but may be = fine for files that use codecs that become available after the change is = made (and thus are unavoidably non-backwards-compatible anyway).

If combined with clear advice in the spec on how muxers = SHOULD (or MAY) decide on time bases for various possible input cases, I = think this extension could get actual adoption in muxers and solve one = of the format's longest-standing = problems.

This has been discussed on the = list before though I don=E2=80=99t remember clear consensus on how to = address this. Steve even compiled a list of discussions on this = at https://mailarchive.ietf.org/arch/msg/cellar/ZpZxhG1gML9xVx_ir1= Jf6_gcI8U/.

I proposed an option in this https://mailarchive.ietf.org/arch/msg/cellar/mTprgjNqVbe20e6hyY= xns8ZnVwY/ where one of the existing reserved bits of the Block = Header (in the byte that contains the keyframe, invisible, and lacing = flags) be used as a flag for Timescale Alignment.
With this approach, new elements could = be added to the track header with a numerator and denominator of a = rationale time scale and if Timescale Alignment were set to true, then = the nearest increment of the rationale time scale would be used. = Example:

Thus= if the frame rate of the track header is 120000/1001, then

If Matroska timecode is = 4 and Enable TimeScale Alignment is 0, than it is at 4 / (1000000000 / = TimecodeScale ).
If Matroska timecode is 4 and = Enable TimeScale Alignment is 1, than it is at 0 / 1200000 (nearest = increment of the rationale frame rate).

If Matroska timecode is 17 and Enable = TimeScale Alignment is 0, than it is at 17 / (1000000000 / TimecodeScale = ).
If Matroska timecode is 17 and Enable TimeScale = Alignment is 1, than it is at 2002 / 1200000 (nearest increment of the = rationale frame rate).

In a Matroska demuxer doesn=E2=80=99t understand the new = nom/denom elements or the Alignment flag then it would simply use the = existing nanosecond timestamp system.

In that thread there were other = proposals, for example Steve discussed using a float to depict a point = in time.
Dave
= --Apple-Mail=_1465C232-E660-45C3-B41B-28B76F92814D-- From nobody Tue Sep 8 16:00:36 2020 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 AF9103A0959; Tue, 8 Sep 2020 16:00:27 -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: mcr+ietf@sandelman.ca, cellar@ietf.org, cellar-chairs@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159960602769.11050.6691993155249473390@ietfa.amsl.com> Date: Tue, 08 Sep 2020 16:00:27 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 109 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 Sep 2020 23:00:35 -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 109. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sun Sep 13 00:41:25 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133253A0A21 for ; Sun, 13 Sep 2020 00:41:23 -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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=kTNyN9tX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Dx5ky6R6 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 LMlY6fC0gsMj for ; Sun, 13 Sep 2020 00:41:21 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519893A0A1D for ; Sun, 13 Sep 2020 00:41:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 30E7C5C0138 for ; Sun, 13 Sep 2020 03:32:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Sep 2020 03:32:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=iv1I7zsMcUqxTW4qloC0mUqUAcB0hUq6NuDzh5lomCE=; b=kTNyN9tX 4pgCRnSfByorqJ1Eg6SkFcRzzpu8JKR7xNP9W085uPfaSUscyWmS02ANzeClJcJI lOJRN9CT5UjDn1pnH4Zgflr2KODZAkydd521jYxhCL7vN2Rpwl0p8/7z1HIYlceu SpN/SpYqn7J7dm1vSxVQciPGyEKcQht1EEZDJABSLjdeR79yF6UagzcdMlnAzueS Hy5xJzKXhf3lYJAdR6RYgla4uN02lFfJ6ZztksSvLtg0iN8YRzMIwkxjZVm+E04x oAreXsBeFG0sizfA5JrgpiS0/ae7NlFJPsjD7y5XqznoKJ9vJm8EI8urAVSSbsqt j8d5SHqFlME8Zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=iv1I7zsMcUqxTW4qloC0mUqUAcB0h Uq6NuDzh5lomCE=; b=Dx5ky6R6z9W903Kh9OokPeStZawvyIB5WJlowelHQZKyx pAC0BwT0dxDofE/M7OYAbarGgYu03w7K5JAPZ0y6WXMzgzZZuoqpJofkFQ5wWlhu FpBdwPxLPTLchIN06l6exqW4tv+bdunl3uXpb6jREsr0p6/x5j4lj4WbnJ41hxYa oMhB8FR6PRpncx80oHcupUbDcaFEjIu3c7UoBa+L5ORL5y+iOSpMsnuSKtw5LWc6 bMBGw/+OYhJe6RUuN14oUi1tV+vgWeV2aVrz/dphWycdsWGgGn34Iyf/86tiUWWT lQWtinlNRRuf7qvmRDcgBksuka3BbOA2icLRdJ3nQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeivddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrvdehhedrudegvd drvdefieenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [52.255.142.236]) by mail.messagingengine.com (Postfix) with ESMTPA id E9EB7328005D for ; Sun, 13 Sep 2020 03:32:56 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2073995410465453021==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200913073256.E9EB7328005D@mailuser.nyi.internal> Date: Sun, 13 Sep 2020 03:32:56 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2020 07:41:23 -0000 --===============2073995410465453021== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC10) 1 issues created: - Consider providing a facility for integer-fraction timescales (by rcomb= s) https://github.com/cellar-wg/matroska-specification/issues/422=20 2 issues received 10 new comments: - #422 Consider providing a facility for integer-fraction timescales (9 b= y dericed, gbooker, mbunkus, rcombs, wm4) https://github.com/cellar-wg/matroska-specification/issues/422=20 - #419 Specify requirements around ReferenceBlock elements and how BlockG= roups signal random access points (1 by mjbshaw) https://github.com/cellar-wg/matroska-specification/issues/419 [clarifi= cations] [spec_main]=20 Pull requests ------------- * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC3) 1 pull requests submitted: - Add support for zstd content compression (by rcombs) https://github.com/cellar-wg/matroska-specification/pull/423=20 1 pull requests received 3 new comments: - #423 Add support for zstd content compression (3 by mcr, rcombs) https://github.com/cellar-wg/matroska-specification/pull/423=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============2073995410465453021== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday September 13, 2020

Events without label "editorial"

Issues

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

1 issues created:

2 issues received 10 new comments:

Pull requests

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

1 pull requests submitted:

1 pull requests received 3 new comments:

Repositories tracked by this digest:

--===============2073995410465453021==-- From nobody Tue Sep 15 09:06:25 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED2B3A0E1B for ; Tue, 15 Sep 2020 09:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 EylJjSnvvvAQ for ; Tue, 15 Sep 2020 09:06:19 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D423A0E0E for ; Tue, 15 Sep 2020 09:06:18 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id h206so3007051ybc.11 for ; Tue, 15 Sep 2020 09:06:18 -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=AbVjTfmWxp6KGOYYWDjzbXil0ZfpblJY6A3CjWu0FoQ=; b=K08t9VRj2ZFLBXjYtEjY1GDOBBlPB/0s9MxbsY9q/a8ZqdjSf1hct2y4VYbCXvcBoU SIoAwEsN6FpxILyw0W1Hf/n0yfv1O6NA8RAeFp2+ihLA4QkEXjoHRtMn6OL7vKqSlc2t X2FOc6jIerX8b/aR7sBo7C0XW0fRdvWCBiN/hlM78KpYPNvZ4fZMZV2P3Ppu23s8NuEo NvvfgVmKXT7mv3+01osRSyJY5XVx1pOKLexeJJA1dmc2gro6p95+5PVrwGd2JxYSTPWU GMY6vYZvdLPz5/jkWRSt3YJDkDRRhSnBgU5FKNZ3qznDo1mJNBRjW1t8qXeRxosCGA+u YfRQ== 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=AbVjTfmWxp6KGOYYWDjzbXil0ZfpblJY6A3CjWu0FoQ=; b=FXZfKwYqaWWgcoA8PoAZ8vQjgJiMsd3Cql5FMboOPI3Jv0hcf7jHrRunByNM0u30Pd dc+z+74N9W6O9zPTBE/QmTFJuEkTtcAw5GG4N/aIFinIMfDsbsWOW/8E8dsfbQL+faJT 8R8o+GYY4QTLiOOV75R8JHxjdrJrAWwTRssZhw0qkgwd5LAOv35S7D3rzsBbbbudWKLY GXBgRin2clhN2dFn6sDXEGkS/raC9vWKNvBiuUGbt7uPltehZ8pUCuTSu/UYWkAjsxcn oPyMeMtacZhxrJ/d2UPaZeOfOU+Gb9U6OUz0orJ3OPkmRsIrLc64ziZ0vaeNeYD9/70L OnDA== X-Gm-Message-State: AOAM532N/XIVukadL8+DvKIkoJanTku/fWlWKoqSDogNbOx/qUY0IhHl VpP2OfiTC1/ed4lj8hOCW/Sc9ZYGGkC4q9gJWScMj2IDq70= X-Google-Smtp-Source: ABdhPJxNzB4V6OHZGifYXLgVltscHENbzBDqYeE/4+gsvb1I4AFFqQNMac4IAH7QcIKy9/Zom2EvP9IBfYTvLpk3Ktw= X-Received: by 2002:a25:ab8e:: with SMTP id v14mr10375048ybi.465.1600185977958; Tue, 15 Sep 2020 09:06:17 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 15 Sep 2020 11:05:52 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000ca737105af5c546d" Archived-At: Subject: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 16:06:24 -0000 --000000000000ca737105af5c546d Content-Type: text/plain; charset="UTF-8" Dear CELLAR, Here's what's popping up for me as agenda topics for our September meeting. - draft-ietf-cellar-ffv1-17 is on the IESG agenda for 9-24, but we should have most reviews and ballots by our meeting - Confirm no action required on https://datatracker.ietf.org/doc/rfc8794/ HTML5.2 reference - Matroska issues - FLAC issues Does that seem right? Anything else I'm missing? Best, Spencer --000000000000ca737105af5c546d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CELLAR,

Here's what's popp= ing=C2=A0up for me as agenda topics for our September meeting.
  • draft-ietf-cellar-ffv1-17 is on the IESG agenda for 9-24, but we shou= ld have most reviews and ballots by our meeting
  • Confirm no acti= on required on=C2=A0h= ttps://datatracker.ietf.org/doc/rfc8794/ HTML5.2 reference
  • Matr= oska issues
  • FLAC issues
    • Does that seem=C2=A0right? An= ything else I'm missing?

    Best,

    Spencer
    --000000000000ca737105af5c546d-- From nobody Tue Sep 15 11:32:30 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933FA3A16C8 for ; Tue, 15 Sep 2020 11:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 EEFgruq6XsJk for ; Tue, 15 Sep 2020 11:32:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A0F8A3A16C7 for ; Tue, 15 Sep 2020 11:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1600194742; bh=HS/GxS55U7S0i6xRpfYXBC4Do0z8pEZw6MmK1OVyiY0=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=D6mFYqpH8R9IDQzZTaWwQh1+L2nSZl6Wag9gSOA1w4n/7h3YhO6W4/sbCdF4QK5yu yg0YUYh17J612PyiuFbvPrzd1Ex8xlbLd9U+ADZbN7Qhcnybr7d15of32kdCebyPC4 U0u9yyLbxBKspBUeSnw47BHTQ2+4v3hrUBqdEuD8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.101] ([93.242.172.51]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNbp3-1k7bqv0xpL-00P4GY for ; Tue, 15 Sep 2020 20:32:22 +0200 To: cellar@ietf.org References: From: hubblec4 Message-ID: Date: Tue, 15 Sep 2020 20:32:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------131D1D4E0186828EC4AF8045" X-Provags-ID: V03:K1:Nb2LBwNJI/+QxTnv2qkIiKN6f9TH5Eh2ZyHV5A/PVsNOCCVGj7v qIxLfe6DDQ5oyysQGcL7XtXf1S9o1Nk6k4mGHqNFJyIQTAMmUlLVv6oc3WuAU43Gwb5pd2Y HsS3EupOcNHPig7gos1gkqA6yL19nVMrZV44j9bdO0eTcAItapMJJ3Gipxh6F9is6W0tAV/ 4EtXP0Lj6FmWwFEn+ndYQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:z05Q5mRLnAQ=:H9RkNexRDoJS0hDIAJKGtE 4qgFFosm+pD3gjrb8X5uIcHM4QQCMmixAOdGBMlJlWue/pnfBVXXyqowm3UHUaCgzGtkpDznU GttGL9sgWB6O9kcsWqhp817ubQpBuWFyCGlm+vY7jC+9c6spMCwPjv6WzSJtxytYxL4lBMjoC 9TLPSji0eVE1m9anzV50/3d4qtLd9ZlZgTwV8qQS6WZBXPfjkJxNhYM1U63m+1ByvCSth29gV 5PJZePLTLBEQhmzkTlFxIFMQ9lr0MZWqCEKBOvasPtAxoQ6Zoid1izJuDRhRBxWAKml/ZEVbR XvvKrS3Q6sEaBfiSJKWQ8xnKO+Ms6uU7NnqBrObiz8T446HqArGmvuogtwiy6mjIkvYTMgGeZ 2jazuUD6BEKYkCDA6+RYU2YyD3i7oBarn6j4bZKoHQqTxhS8KVMeWVnupikBIjI1UWEVLEp6m MOVqZsaFI6O8IBX/0cAmHl/m0ZwsOVgUJ9oFQ2FgvSXyGAw0zEIR66+uEPEBiYQPdbocglxP5 uqWR9ZAASO1YS8DCYXGjESl+otcMOSIKM8eJG8Pjo5Soxxg7EwdZSx8poLQNR68JJ6iIw2A7x fXR6/0/75JRSmDRuU8O+Z/yZPHINCl6rRbUAvYqnuppWuYZLZAfBjwMdCh/+wmeTF0++lLgLV eaoKdAWIKD8AuCLA9sZAKbTPORh8LzpGB4GQtQtYObjL80AP0de9LMDbB9NddlNbXYo1uvHQP TJvm2q0Il0M+ATrRhILU833w5aLFb0xXcIKfNufj4PpY6DDFL7jS7mKQmuUlX2GZ5ScRvjuc5 VfhnXC8VT9QCLeTWXCUEL2aH4Xa/czuryZ4ZWISQGPICGdu7pQyEMwecP/DafSsom3z+xAOEm ewGJJtsoDf3PET/QBJ/3pnWSaS/Pdyd3r0UMD2EQmLd6x2Sr8p7H77EakJRAt+qEso411ibzo QPrhsh+wxTHi4j9PZHGf4pGjtEZlXhUaPAyqzM6VMXJ3VEfG1F/CQxeKR+m+gbEMxG1mq1W3/ 94MwcJpZw+FftCjvn1w6JavRa3pkrlDFKhQNlnT7Iuuhkdypjpx2C0I4oSdC1xNYCR4kSZqSK bDsl4IVxtmx3Z/anZNFeTDG+y6e4w69ddkscrJlXnpUMS9DWTsncu1s6btaRBfIZZO/3sqhzG 17XyM5AVrEqXCehufVEcXgTpU7WpXE9CSizlp28h3IAdqWGPBbtqnXwY7WuXErnS848Z/71/K V2jvFXrxQpAvM9fIT Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 18:32:28 -0000 This is a multi-part message in MIME format. --------------131D1D4E0186828EC4AF8045 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Am 15.09.2020 um 18:05 schrieb Spencer Dawkins at IETF: > Dear CELLAR, > > Here's what's popping=C2=A0up for me as agenda topics for our September > meeting. > > * draft-ietf-cellar-ffv1-17 is on the IESG agenda for 9-24, but we > should have most reviews and ballots by our meeting > * Confirm no action required on > https://datatracker.ietf.org/doc/rfc8794/ HTML5.2 reference > * Matroska issues > * FLAC issues > > Does that seem=C2=A0right? Anything else I'm missing? There are two new EBML PRs. regards Martin > > Best, > > Spencer > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------131D1D4E0186828EC4AF8045 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

    Hi

    Am 15.09.2020 um 18:05 schrieb Spencer Dawkins at IETF:
    Dear CELLAR,

    Here's what's popping=C2=A0up for me as agenda topics for our September meeting.
    • draft-ietf-cellar-ffv1-17 is on the IESG agenda for 9-24, but we should have most reviews and ballots by our meeting
    • Confirm no action required on=C2=A0https://datatracker.ietf.org/doc/= rfc8794/ HTML5.2 reference
    • Matroska issues
    • FLAC issues
    Does that seem=C2=A0right? Anything else I'm missing?

    There are two new EBML PRs.


    regards

    Martin




    Best,

    Spencer

    _____________________________=
__________________
Cellar mailing list
Cell=
ar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
    --------------131D1D4E0186828EC4AF8045-- From nobody Tue Sep 15 12:09:55 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4443A0E4C for ; Tue, 15 Sep 2020 12:09:54 -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 ktEw_kegZKt2 for ; Tue, 15 Sep 2020 12:09:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A822F3A0AE7 for ; Tue, 15 Sep 2020 12:09:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 707F0389A1; Tue, 15 Sep 2020 14:48:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id c7iS5M3_dka5; Tue, 15 Sep 2020 14:48:34 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E9153899E; Tue, 15 Sep 2020 14:48:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 38C51118B; Tue, 15 Sep 2020 15:09:50 -0400 (EDT) From: Michael Richardson To: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 19:09:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Spencer Dawkins at IETF wrote: > - draft-ietf-cellar-ffv1-17 is on the IESG agenda for 9-24, but we > should have most reviews and ballots by our meeting > - Confirm no action required on https://datatracker.ietf.org/doc/rfc8= 794/ > HTML5.2 reference > - Matroska issues > - FLAC issues > Does that seem right? Anything else I'm missing? I think that's mostly it. We are still getting regular questions about why v0,1,3 are not standards track, why EBML is not in CBOR, etc. I wonder if there is some charter or abstract text that we should tweak to make this more obvious. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9hEX0ACgkQgItw+93Q 3WXxXwgAm1gx7vLOt7OYR6GMYeNtv0CzG+tWhLIWiyx9LTtfM9prxlB2dolzk126 hSqsbeSQWny8tdiKPa41mUYDKI831xAvZG6KKKzoFspdenSvPrhVie/BnYe6Tfhz Ro1WY24cVrLk45h83rWjawalxBz4lL1H921bytpk8tGyUvy3aqFBlcECZnC7YmKz JCufiFFEAzaYNuJdLhjvfVHO1gF6CXPtAulu4zhw1s6gXCgQoR4AATkGOlNWh7MJ nhJPO5f3nU09sTG1MdYD3M28v7zJGgSKHjE3ItM7eVS0bQ/4vuhIzPolhI9UjuNa oI6Q55xRKolbPoaPJD6aVUM3awb0XQ== =EUrA -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 15 12:15:07 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D9D3A17F9 for ; Tue, 15 Sep 2020 12:15:05 -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 XCUbOWBYpCmq for ; Tue, 15 Sep 2020 12:15:04 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) (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 10B5A3A17FB for ; Tue, 15 Sep 2020 12:14:58 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kIGPn-0000qR-Ld; Tue, 15 Sep 2020 19:14:55 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1kIGPn-0004i1-IS; Tue, 15 Sep 2020 21:14:55 +0200 From: Florian Weimer To: Spencer Dawkins at IETF Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: Date: Tue, 15 Sep 2020 21:14:55 +0200 In-Reply-To: (Spencer Dawkins at IETF's message of "Tue, 15 Sep 2020 11:05:52 -0500") Message-ID: <87een23l8w.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 19:15:06 -0000 * Spencer Dawkins at IETF: > - FLAC issues Is this in part of the issues that I've filed recently, about perceived gaps in the specification? I have some more items, but I wasn't sure if these comments were useful. (I'm not an experience audio codec implementer, so I'm hardly the target audience for the specification.) From nobody Tue Sep 15 12:24:53 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054363A1839 for ; Tue, 15 Sep 2020 12:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 zqHik8VF-y4V for ; Tue, 15 Sep 2020 12:24:50 -0700 (PDT) Received: from 6.mo178.mail-out.ovh.net (6.mo178.mail-out.ovh.net [46.105.53.132]) (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 133CA3A0EA8 for ; Tue, 15 Sep 2020 12:24:49 -0700 (PDT) Received: from player695.ha.ovh.net (unknown [10.108.42.83]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id CAF4AB0046 for ; Tue, 15 Sep 2020 21:24:47 +0200 (CEST) Received: from mediaarea.net (p548f99b4.dip0.t-ipconnect.de [84.143.153.180]) (Authenticated sender: jerome@mediaarea.net) by player695.ha.ovh.net (Postfix) with ESMTPSA id 58B46160FD1D6 for ; Tue, 15 Sep 2020 19:24:47 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-104R00556263045-2d75-4a43-96e9-cdc1893f312a, 5EA37130AB3CE0496EF1A8D63F4A6935C729F257) smtp.auth=jerome@mediaarea.net To: cellar@ietf.org References: <87een23l8w.fsf@mid.deneb.enyo.de> From: Jerome Martinez Message-ID: <10667194-f2f3-c49b-f4b9-404798c2978c@mediaarea.net> Date: Tue, 15 Sep 2020 21:24:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <87een23l8w.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Ovh-Tracer-Id: 1512928000861343889 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrtddtgddutdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeelgeehgeehiefhjeeijefhjeefteehieeltefhueevhfevfeeuieeviedvgefgvdenucffohhmrghinhepmhgvughirggrrhgvrgdrnhgvthenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheefrddukedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrieelhedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 19:24:52 -0000 On 15/09/2020 21:14, Florian Weimer wrote: > I have some more items, but I wasn't sure if these comments were > useful. (I'm not an experience audio codec implementer, so I'm hardly > the target audience for the specification.) They are very useful, as we sometimes don't catch issues in spec when we are too much used with the spec/format and when decoder was written before the spec. your work on an alternate decoder based on the spec especially permits to know that the spec is not in sync with reality / reference decoder. So please go ahead and open 1 issue ticket per issue you found, and we'll fix the spec. No ETA promised, but it will be handled. For your information the same kind of work was done for FFV1, someone wrote a decoder based only on the spec and no knowledge of any other decoder, the corresponding presentation is at https://mediaarea.net/Events/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from%20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf From nobody Tue Sep 15 13:05:12 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CE3A09CD for ; Tue, 15 Sep 2020 13:05:10 -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 SBZuXwGEda4i for ; Tue, 15 Sep 2020 13:05:09 -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 0FC643A09CC for ; Tue, 15 Sep 2020 13:05:09 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id c17so3616308ybe.0 for ; Tue, 15 Sep 2020 13:05:09 -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=bbvpH2AmlBeFV27QpgG5/o13fK6hyXMZBlbhMUTy4i0=; b=TiWMlNTYsXd0HIUrFp/x8U7abLbddMvKj2vN70C5u1eLkgZ6nH8ZqbuuKklh3JrrlR 811zm2vpvVoYDP/B626YntuYlQWwG+kQ2pLUePZo5ySjJiAJXdOqi1xHL2x7uUO5ViPN YDZFwimzzB11bJdTJAWk+JHaNlTGvhGJxs0nx+tpzquwLf8Dd/R4cw8wdmVWuQJMqOi5 LwtXPSA8MU4luHDxg2oDNbhBoC+7PN8N0URR8+aaKwWsVIKnXI6O6A8KsYwwxPbPHfvc Sw8NDGJ7irY5ut4UMiiITqFUzidwQhhZ9NzGEl/SjB8ENK60IYsu13WUP4Y+gdRVDdzD R3ng== 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=bbvpH2AmlBeFV27QpgG5/o13fK6hyXMZBlbhMUTy4i0=; b=oPxoIT6rkKG2LFTbVfvJ++iiEmCl5ffNkJvvZNK8OIRRELErBH7obodgQimfQkT+xF 5DImhwJRe0Ww1het5y+7/3L3QAIY9GhqIIuTcdlAyz4dT1QRUoSu/DBNBupVPcrUYJzH lbHMkqaUAvOuVavf7kck0eCNwhhCUcP+KOYFyQSAp02t7MZkTVQ7PW2PIUgjC5tpw+WD 17kEWH2ChESCrCDKH33Ig8JXDOgDJzFr8NQjHC+XutbUahrTGVIEUAl7hwgNpk7QRn93 8aVUDrj09jnUfU2LM4ScEu1TeFUGCF9mtmqRE+Lxmm8IxeDmihPkvgyLiF+xWe+2BeEW gltQ== X-Gm-Message-State: AOAM530zVnRy52Zc63vlWnxs/HHZdH/NhRkgAbHuoelb/wln2dADjhby FlT9KIr2FKyR1Od0C7HyOByzYHZwWiUsZ62MuwGqss0q X-Google-Smtp-Source: ABdhPJybmdzt753QtKdQ3NMFc0ViI+sWvRFggTA0A+tqwG9hoUqgb9OtYvjRb6FX/0b8Td/DiNF3izUSLoLVxJCC3qU= X-Received: by 2002:a25:3752:: with SMTP id e79mr11837599yba.154.1600200308194; Tue, 15 Sep 2020 13:05:08 -0700 (PDT) MIME-Version: 1.0 References: <87een23l8w.fsf@mid.deneb.enyo.de> <10667194-f2f3-c49b-f4b9-404798c2978c@mediaarea.net> In-Reply-To: <10667194-f2f3-c49b-f4b9-404798c2978c@mediaarea.net> From: Spencer Dawkins at IETF Date: Tue, 15 Sep 2020 15:04:42 -0500 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000f080c205af5faae8" Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 20:05:11 -0000 --000000000000f080c205af5faae8 Content-Type: text/plain; charset="UTF-8" Just to answer Florien's question - yes, exactly. I was looking at issues. Thanks for helping (as Jerome said)! Best, Spencer On Tue, Sep 15, 2020 at 2:24 PM Jerome Martinez wrote: > On 15/09/2020 21:14, Florian Weimer wrote: > > I have some more items, but I wasn't sure if these comments were > > useful. (I'm not an experience audio codec implementer, so I'm hardly > > the target audience for the specification.) > > They are very useful, as we sometimes don't catch issues in spec when we > are too much used with the spec/format and when decoder was written > before the spec. your work on an alternate decoder based on the spec > especially permits to know that the spec is not in sync with reality / > reference decoder. > So please go ahead and open 1 issue ticket per issue you found, and > we'll fix the spec. No ETA promised, but it will be handled. > > For your information the same kind of work was done for FFV1, someone > wrote a decoder based only on the spec and no knowledge of any other > decoder, the corresponding presentation is at > > https://mediaarea.net/Events/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from%20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --000000000000f080c205af5faae8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Just to answer Florien's question - yes, exactly. I wa= s looking at issues.=C2=A0

    Thanks for helping (as Jerome= said)!

    Best,

    Spencer

    On Tue, Sep 15, 2020 at 2:24 PM Jerome Martinez <jerome@mediaarea.net> wrote:
    On 15/09/2020 21:14, Florian Weimer = wrote:
    > I have some more items, but I wasn't sure if these comments were > useful. (I'm not an experience audio codec implementer, so I'm= hardly
    > the target audience for the specification.)

    They are very useful, as we sometimes don't catch issues in spec when w= e
    are too much used with the spec/format and when decoder was written
    before the spec. your work on an alternate decoder based on the spec
    especially permits to know that the spec is not in sync with reality /
    reference decoder.
    So please go ahead and open 1 issue ticket per issue you found, and
    we'll fix the spec. No ETA promised, but it will be handled.

    For your information the same kind of work was done for FFV1, someone
    wrote a decoder based only on the spec and no knowledge of any other
    decoder, the corresponding presentation is at
    https://mediaarea.net/Eve= nts/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%= 20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from= %20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf

    _______________________________________________
    Cellar mailing list
    Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
    --000000000000f080c205af5faae8-- From nobody Tue Sep 15 13:14:36 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422B43A08C0 for ; Tue, 15 Sep 2020 13:14:34 -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 KFWAuipkqOmj for ; Tue, 15 Sep 2020 13:14:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48223A084D for ; Tue, 15 Sep 2020 13:14:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8CFD0389A1; Tue, 15 Sep 2020 15:53:15 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qmQnfw1619XO; Tue, 15 Sep 2020 15:53:11 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 961723899E; Tue, 15 Sep 2020 15:53:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE7AD11B3; Tue, 15 Sep 2020 16:14:27 -0400 (EDT) From: Michael Richardson To: Florian Weimer cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <87een23l8w.fsf@mid.deneb.enyo.de> References: <87een23l8w.fsf@mid.deneb.enyo.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 15 Sep 2020 20:14:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Weimer wrote: > * Spencer Dawkins at IETF: >> - FLAC issues > Is this in part of the issues that I've filed recently, about > perceived gaps in the specification? > I have some more items, but I wasn't sure if these comments were > useful. (I'm not an experience audio codec implementer, so I'm hardly > the target audience for the specification.) This kind of review is often really valuable. Thank you! =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9hIKMACgkQgItw+93Q 3WXU9Qf/a0j43rw1gmQDaDhUdagMVX38DdLnMRpAv9meP+FLXWLHvYxG46tAA0s/ Xw5NZsdoHhW4ob9oDDlqItrpCpMZQZmd1pBFWxP7QpoAbI4qKUlsuoSmRV19eG9a E7ne78SjdAZMBu1+1re3z67yAGX+0id20MasahaOzNhOHB6KXt4rlBC7Zz6ZCuJm 3z45sLKlLx0pm9CWwwPPQCkCpsOTqCUULFkFkoMM/Vgu1jY9Mbg+QFlk5x3uXWsY KedsQrN+8dvUitpXV+eJXeeC9WfcB1RUF9v8bJ0rUTN9bOw1/UATAQMH6JVDMK7J FiSU1gIx+eTubOZ+StFT+sFAtOeJZA== =1bFt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 18 21:38:47 2020 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 D17673A08C7; Fri, 18 Sep 2020 21:38:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160049032442.20595.4616862102756589735@ietfa.amsl.com> Date: Fri, 18 Sep 2020 21:38:44 -0700 Archived-At: Subject: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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 Sep 2020 04:38:45 -0000 Barry Leiba has entered the following ballot position for draft-ietf-cellar-ffv1-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There are a number of things I’d like to discuss, because I find them not understandable. Perhaps it’s simply because I’m not a codec expert, but, while I understand that this is written for readers who will actually be implementing he FFV1 codec, some of them will also not be “experts”. That said, I’m sure some of this is just a case of “give Barry some clue and it’s fine.” — Section 2.1 — You use the term “symbol” here and later, without defining it, and I don’t know what it is. A byte? A character? A string of bits? What length? — Section 3.8.1.1 — I’m not sure how to interpret the stuff in this section. First, I don’t know why there are seven “figures”, with no captions nor other explanation. Second, I’m having trouble making sense out of things like this: S_(i + 1, C_(i)) = zero_state_(S_(i, C_(i))) AND l_(i) = L_(i) AND t_(i) = R_(i) - r_(i) <== b_(i) = 0 <==> L_(i) < R_(i) - r_(i) Can you explain how this is meant to be read? Maybe it’s just me, and maybe after you explain it I’ll whack myself on the head and say, “Doh!” Third, you say, “S_(0, i) is the i-th initial state,” but you haven’t previously introduced the term “state”, and I don’t know what it means. — Section 3.8.1.2 — "get_rac" returns a boolean, computed from the bytestream as described in Section 3.8.1.1. I see nothing in Section 3.8.1.1 that describes get_rac. — Section 3.8.1.3 — At keyframes all Range coder state variables are set to their initial state. What does “at keyframes” mean? — Section 3.8.1.5 — This is just a list of numbers with no explanation. It needs text explaining what it means. — Section 3.8.2.2 — The level is identical to the predicted one. The run and the first different level are coded. What does “level” mean? It’s not defined anywhere. — Section 4.3.1 — "reserved_for_future_use" has semantics that are reserved for future use. Yes, that seems rather obvious, though it’s oddly worded. But then you say what to do with “this value”, and nowhere do you say what the value is. How does one know? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some editorial comments that I ask you to please consider: General: It’s jarring to see the defined terms, such as “Sample” and “Pixel” in quotes every time they’re used. More common practice is to quote them when they’re first defined, and then to just use the capitalization to show that they’re defined terms. I find that the quotes affect the readability and make it somewhat more of a challenge to read. — Section 2.1 — "Plane": A discrete component of a static image comprised of Total, total nit, and pet peeve: “composed of” or “comprising”, but not “comprised of”. — Section 2.2.2 — You’re missing “a % b”, which is referenced in Section 2.2.6. — Section 2.2.4 — "a > b" means a is greater than b. "a >= b" means a is greater than or equal to b. "a < b" means a is less than b. "a <= b" means a is less than or equal b. "a == b" means a is equal to b. "a != b" means a is not equal to b. I don’t think anyone will misunderstand this, so it’s a very small thing, but… might this be better said as, ‘ "a > b" is true when a is greater than b. ‘ (and similarly for the rest)? — Section 2.2.5 — "min(a,b)" means the smallest of two values a and b. "max(a,b)" means the largest of two values a and b. Nit: “smaller” and “larger”, for only two. — Section 2.2.7 — "a...b" means any value starting from a to b, inclusive. “starting”? I would leave that word out. — Section 2.2.9.1 — "remaining_bits_in_bitstream( )" means the count of remaining bits Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do Sections 4.4 and 4.5. This should too, yes? — Section 3.2 — Figure 3: A depiction of how relatively positions Samples are references within this document. I think you mean “positioned” and “referenced”, yes? — Section 3.3 — Background: a two's complement signed 16-bit signed integer was used I’d remove the first “signed”. — Section 3.8.2 — The end of the bitstream of the "Frame" is filled with 0-bits until that the bitstream contains a multiple of 8 bits. Is “that” just an extra word that needs to be struck, or is something else wrong here? And is this meant to be what we usually call “padding”? — Section 4 — Within the following sub-sections, pseudo-code is used to explain the structure of each FFV1 bitstream component, as described in Section 2.2.1. I read this as saying that Section 2.2.1 describes the structure of each FFV1 bitstream component, until I went back there and looked. I suggest reordering the sentence to help the reader a bit: NEW Within the following sub-sections, pseudo-code is used, as described in Section 2.2.1, to explain the structure of each FFV1 bitstream component. END — Section 4.5 — Encoders SHOULD NOT fill these bits. Decoders SHOULD ignore these bits. Before this you describe two kinds of bits, and it’s not clear whether these are talking about both kinds, or just the latter. I think changing “these” to “reserved” is better. — Section 6 — A frequent security problem in image and video codecs is also to not check for integer overflows, for example to allocate "frame_pixel_width * frame_pixel_height" in "Pixel" count computations without considering that the multiplication result may have overflowed the arithmetic types range. This is somewhat complex and awkward (arguably a comma splice), and I suggest splitting the sentence thus: NEW A frequent security problem in image and video codecs is failure to check for integer overflows. An example is allocating "frame_pixel_width * frame_pixel_height" in "Pixel" count computations without considering that the multiplication result may have overflowed the arithmetic types range. END I might also make the “must” in the last sentence of that paragraph be “MUST”. From nobody Sun Sep 20 00:40:59 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9851C3A1109 for ; Sun, 20 Sep 2020 00:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZkIw7/Xu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JGqj24WN 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 35_tMMiTstuY for ; Sun, 20 Sep 2020 00:40:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344EE3A110B for ; Sun, 20 Sep 2020 00:40:51 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 033095C00B2 for ; Sun, 20 Sep 2020 03:32:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 20 Sep 2020 03:32:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=nLO/m3/7j9aXDJoLfOFcO/of1h8eO7pngx4oVoL5er8=; b=ZkIw7/Xu PFWRJKOSGO0dYx+1fqSQgo/mSyRd+9Cyk4/vOSA5ljLx51dweZtG1Xirzpu5ziW4 U8lkPt34lsjaSoHKzNa6/ttP2ViTpZg8f/LuxCcHuxhWa/ys2MALj4Oomm+k8HU2 72EXFklF9CBH7H8iuf787S3xZ4NIOqW+p1BusTxs0zsUNqf2JdPPGi7xFUBfThPa qK+Yb8TpjGmkPLaZGrAIEsYnhRsylqYF787+aKkt98jqthVGj+fjjugBRf/Y61Je xnuwq5xGPqEDu/3xYsqt3lxuysh0xDxM+N/xmvNx9gl2xwJSoTUoZ/VZ+pbac3pR 8Um1aUArsIf6pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=nLO/m3/7j9aXDJoLfOFcO/of1h8eO 7pngx4oVoL5er8=; b=JGqj24WNd2ulHIo01pON17mUpuyLLN+1tsZQiHv1zPxdy idsws1j5ujzHLjK0PNIZZD9/O2POx/RyDclsIWcjug7+dsErn3sYDncICbqRq8+B Z0EhdRTiZAX9HQOwjY5x0ymadJC4uIns8n9W2sdy1TmEI39P8fuKx+XhPYhq7FbR UcfyBtFiSQ2gLpH2/z0MKiIiho+AFboUYvP/ymc8+27b5ysxyvBwCAyRqVnIPOM/ 6vD+n5DKyJ5mQ4oQzLw2DgQZz57LWKXg2OfQBzVtj9cVrKGnMmpzotB/tnFWJVMS UxAPLQL0b8IWa72ZtfbX6cwD7eClG3f1pbL/KDisQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrtdelgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddujeelrdduieefrd ejieenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60.internal.cloudapp.net (unknown [52.179.163.76]) by mail.messagingengine.com (Postfix) with ESMTPA id BDC113280059 for ; Sun, 20 Sep 2020 03:32:42 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============0108841626247882658==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200920073242.BDC113280059@mailuser.nyi.internal> Date: Sun, 20 Sep 2020 03:32:42 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 07:40:54 -0000 --===============0108841626247882658== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC4) 2 issues received 4 new comments: - #422 Consider providing a facility for integer-fraction timescales (2 b= y robUx4, t11s) https://github.com/cellar-wg/matroska-specification/issues/422=20 - #419 Specify requirements around ReferenceBlock elements and how BlockG= roups signal random access points (2 by robUx4) https://github.com/cellar-wg/matroska-specification/issues/419 [clarifi= cations] [spec_main]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC3) 1 pull requests received 3 new comments: - #423 Add support for zstd content compression (3 by rcombs, robUx4) https://github.com/cellar-wg/matroska-specification/pull/423 [clarifica= tions] [format addition] [spec_main]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============0108841626247882658== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday September 20, 2020

    Events without label "editorial"

    Issues

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

    2 issues received 4 new comments:

    Pull requests

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

    1 pull requests received 3 new comments:

    Repositories tracked by this digest:

    --===============0108841626247882658==-- From nobody Mon Sep 21 22:32:33 2020 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 A7E8F3A13A8; Mon, 21 Sep 2020 22:32:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160075274666.1307.15063603679468881336@ietfa.amsl.com> Date: Mon, 21 Sep 2020 22:32:26 -0700 Archived-At: Subject: [Cellar] Erik Kline's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) 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, 22 Sep 2020 05:32:27 -0000 Erik Kline has entered the following ballot position for draft-ietf-cellar-ffv1-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 3.3 ] * Suggest either defining colorspace_type value and coder_type values before using them, or provide a reference in this section (i.e. just include a reference to sections 4.2.3 and 4.2.5). [[ nits ]] [ section 3.2 ] * In the description of Figure 3: "relatively positions" -> "relatively positioned", I think. [ section 3.3 ] * "signed 16-bit signed integer": choose any one instance of 'signed', I'd say [ section 3.7.2 ] * "and then if used transparency" -> "and then, if used, transparency" From nobody Tue Sep 22 06:53:35 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB243A0DEE for ; Tue, 22 Sep 2020 06:53: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, 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 qOIL7FKYyPE8 for ; Tue, 22 Sep 2020 06:53:31 -0700 (PDT) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 A52FF3A0DED for ; Tue, 22 Sep 2020 06:53:31 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id k18so4166089ybh.1 for ; Tue, 22 Sep 2020 06:53:31 -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=mTocRkGrLxAY5WrahXI125LZy7hB++UXdcLdDC97VUI=; b=FgJg3BrjK+0LzvsF53eUC00AONWbVCfZ8MAW0xU8zNb6YV7RIemH/BkRmaDBujUfjK rGcaQ0nzrFrkLEKcqbD/2tpOd10JiHe0QCxFNti2p+TrqREUR15hXPs4cxMtUTWNIzEO 5lRw5Rg7rNKIFxv7ROYzKD7aRjkPbwSRbS0jwix5rvMQpOZoZJZLgKS5FpPnK7TEXSXx ka5maA2nq7lFZE0wi1K/wPXrFSufQ94cdf3DFOa7gMpdgl1Mjck63948x+Q/eDSt7ZP9 i2nqDCUkuom8q6BRIt8BHBEo1I5uK3J2wQaXtpdczwVFr9I/blWWw5UNZebTOLucxFr4 7Lsw== 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=mTocRkGrLxAY5WrahXI125LZy7hB++UXdcLdDC97VUI=; b=b0YppYz7i13FARHi+USU79mhBep4j5pg+DioDH+y/gz7uaMltNheMl/fOnlZjtzHfS xIuLVnSAK5y2JKr+WnHfhBDNOw1hN3ETm9p9wFm+LGFasGVJB48rly+VSwhhbyTwtJ94 p0BLnWYCcpBhk89LdOx8SmHXJ1f+2hZYilOZrZOcoSvAe+enzKnrQg2iqnI7ivwVGhG2 14rF28JqKy1exwe3t4fb6aDQuDWO2PRGJYYdGd7FOUSBISe3y3A/AfJNTA3MyTAIVWPe n3qTN4SU5zScKxXGmxRc+WDwlu6Q2ZZ8SWd8EaaNxDejE9wsuI4/emYDHSBDrc15c68p Bv0g== X-Gm-Message-State: AOAM532VpS7f6anZ4bZLbiS0j26W9LXauTzi317R2IB5NRN5ZRYqmSKT 6arDsK7bETFAJYa5T/V/kvq97aSI1FVCr9Zs4bG8QzzcFNo= X-Google-Smtp-Source: ABdhPJy2LEYBntqlsnZ0EcVogkJWjl6jQ2WRDKypEonY0zG2/fQdDrVNWRY/moSh+4LQm+jTllnusAMJ61mN1M9o2oo= X-Received: by 2002:a25:ae4d:: with SMTP id g13mr6695677ybe.288.1600782810748; Tue, 22 Sep 2020 06:53:30 -0700 (PDT) MIME-Version: 1.0 References: <5271.1600196990@localhost> In-Reply-To: <5271.1600196990@localhost> From: Spencer Dawkins at IETF Date: Tue, 22 Sep 2020 08:53:04 -0500 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000cc18e605afe74a74" Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 22 Sep 2020 13:53:33 -0000 --000000000000cc18e605afe74a74 Content-Type: text/plain; charset="UTF-8" Dear Cellar, I've uploaded the agenda for Tuesday's meeting at https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-11-cellar-01/ and made the corresponding commits in Github. Please note that we're moving from Etherpad to CodiMD as of this meeting - the new URL is included in the agenda, but it's here for your convenience: Best, Spencer --000000000000cc18e605afe74a74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Cellar,=C2=A0
    =
    I've uploaded the agenda for Tuesday's meeting at=C2= =A0https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-1= 1-cellar-01/ and made the corresponding commits in Github.=C2=A0
    <= div>
    Please note that we're moving from Etherpad to CodiM= D as of this meeting - the new URL is included in the agenda, but it's = here for your convenience:=C2=A0

    Best,
    <= br>
    Spencer
    --000000000000cc18e605afe74a74-- From nobody Tue Sep 22 08:09:24 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE6E3A0F88 for ; Tue, 22 Sep 2020 08:09:23 -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 zgJBeT6r5kR6 for ; Tue, 22 Sep 2020 08:09:22 -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 1CFEF3A0FB2 for ; Tue, 22 Sep 2020 08:09:22 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id h9so5557894ybm.4 for ; Tue, 22 Sep 2020 08:09:22 -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=pIxw13nxb0U1Zbui3vg/Uae7JFxy64XSSdNWc0cLX8E=; b=larwhpPE6eeAMZH0327Poozhv7Eljx+vrxJeHS1PwG+OR7poF+QJtexf8+9Uhp9gZF bgl6aagkrG4C8jgmoFk92qIpaOAvMWcdB5mxW/g0VL7IoP8dFv2i/RzrvXi/yMtJOuRI Hmu0is0UsEU9yePLi4CilVjcmWgTaOd8vrU/Ewqv7KkTGJAb/phspBwBJdERSeWQR7Pm EOr2SW2jPMlNx1yfM7M7bw9RpCHSyvPEEw00/1Mi1NFKcVkIYiKjhspCa0SyDZdDuSYN rkyqOyXO60NlR4zh6jvSexgaSbvJC+QD1EuDs7hJDi6wL82jIfbkLwov+FMMPpozMhdq dDdw== 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=pIxw13nxb0U1Zbui3vg/Uae7JFxy64XSSdNWc0cLX8E=; b=Z9bTwTK48cYGzmLPU/PvbsgpxNtTVcs/FDq9MkPUrtbwQvDQwrvwdfpJzx1DTmqsUN mm6GPb2JJYofYHoMlOQa72MaVOXPmEAwPIkKnQJiuWc28bnT1AhVPlLFE2L3ppSscrWO DXX6UI5zjwMh1pgJ2r1MocBzJx+LKVRjU/xyaULNPDcg1Lji3aFSrmdj7ICVq8ZCxk9s w1LXP96nY3hakpWC9zVuK/K+D6ZEFS6xYkF9glE/4mci1H3OZ7DrroywLohQvLyvp6RO neUcOKFhZTCvBPE4IrCjoiJVOjDZsgO2rYyKNs9dBALcg66f5P+qCUdBJnd87sZhme2j JAlQ== X-Gm-Message-State: AOAM530df6sO5qQKIpMc9/KTn6pxJRPUG7wyLPFvOM9+BOMJ52YWK401 nS3AGsrlb4G8nn7c19vXO38z6LNSH/ZqyjD08t8= X-Google-Smtp-Source: ABdhPJxV2CVQODPS1ak3hByzcG/pTPW3/G4Lsr1KQbasdRMeIaL57im0bcmFri+Yz51WdvoeR9cv/wI48c6LxoJrv2o= X-Received: by 2002:a25:a290:: with SMTP id c16mr536548ybi.84.1600787361324; Tue, 22 Sep 2020 08:09:21 -0700 (PDT) MIME-Version: 1.0 References: <5271.1600196990@localhost> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 22 Sep 2020 10:08:55 -0500 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000008639305afe85a83" Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 22 Sep 2020 15:09:24 -0000 --00000000000008639305afe85a83 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 22, 2020 at 8:53 AM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Dear Cellar, > > I've uploaded the agenda for Tuesday's meeting at > https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-11-cellar-01/ > and made the corresponding commits in Github. > > Please note that we're moving from Etherpad to CodiMD as of this meeting - > the new URL is included in the agenda, but it's here for your convenience: > And by "here", I mean HERE. https://codimd.ietf.org/notes-cellar-virtual?edit. Note that you'll need to log into the IETF datatracker for this. Best, Spencer > > Best, > > Spencer > --00000000000008639305afe85a83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Tue, Sep 22, 2020 at 8:53 AM Spenc= er Dawkins at IETF <spe= ncerdawkins.ietf@gmail.com> wrote:
    Dear Cellar,=C2= =A0

    I've uploaded the agenda for T= uesday's meeting at=C2=A0https://datatrack= er.ietf.org/doc/agenda-interim-2020-cellar-11-cellar-01/ and made the c= orresponding commits in Github.=C2=A0

    Please note = that we're moving from Etherpad to CodiMD as of this meeting - the new = URL is included in the agenda, but it's here for your convenience:=C2= =A0

    And by "here", I = mean HERE.=C2=A0https://codimd.ietf.org/notes-cellar-virtual?edit.

    Note that you'll need to log into the IETF datatracker for this= .

    Best,

    Spencer=C2=A0
    <= br>
    Best,

    Spencer
    --00000000000008639305afe85a83-- From nobody Tue Sep 22 08:44:36 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C383A0FD5 for ; Tue, 22 Sep 2020 08:44:34 -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 JbaRM0IePtL7 for ; Tue, 22 Sep 2020 08:44:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7C13A083B for ; Tue, 22 Sep 2020 08:44:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B6EA0389BD for ; Tue, 22 Sep 2020 11:23:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FuAny3os-0ox for ; Tue, 22 Sep 2020 11:23:07 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 15C8F389AB for ; Tue, 22 Sep 2020 11:23:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1BE814F5 for ; Tue, 22 Sep 2020 11:44:29 -0400 (EDT) From: Michael Richardson To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <5271.1600196990@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2020 11:44:29 -0400 Message-ID: <9060.1600789469@localhost> Archived-At: Subject: Re: [Cellar] Agenda topics for our teleconference next 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: Tue, 22 Sep 2020 15:44:34 -0000 Spencer Dawkins at IETF wrote: > I've uploaded the agenda for Tuesday's meeting at > https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-11-cella= r-01/ > and made the corresponding commits in Github. > Please note that we're moving from Etherpad to CodiMD as of this mee= ting - > the new URL is included in the agenda, but it's here for your conven= ience: I'll share the CodiMD. Note that there are buttons at the top to see it: 1) just edit view. 2) just rendered view. 3) see edit/rendered view split left/right. (I wish it was top/bottom) Many people miss the edit button. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Tue Sep 22 08:57:05 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4283A16B6 for ; Tue, 22 Sep 2020 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 UHoD3TXgdU1V for ; Tue, 22 Sep 2020 08:56:58 -0700 (PDT) Received: from 13.mo4.mail-out.ovh.net (13.mo4.mail-out.ovh.net [178.33.251.8]) (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 112203A1050 for ; Tue, 22 Sep 2020 08:56:57 -0700 (PDT) Received: from player698.ha.ovh.net (unknown [10.108.42.170]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id BABFD24E3AB for ; Tue, 22 Sep 2020 17:56:55 +0200 (CEST) Received: from mediaarea.net (p548f92df.dip0.t-ipconnect.de [84.143.146.223]) (Authenticated sender: jerome@mediaarea.net) by player698.ha.ovh.net (Postfix) with ESMTPSA id E961B16623EB0; Tue, 22 Sep 2020 15:56:47 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-103G0051531b214-729a-427a-b19c-d8d90048421d, 718808425E05DC05DB325B3072315A76E660D1E1) smtp.auth=jerome@mediaarea.net To: Erik Kline , The IESG Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." References: <160075274666.1307.15063603679468881336@ietfa.amsl.com> From: Jerome Martinez Message-ID: <7c1e4bdd-2b9a-d51d-381b-fbe9cf27490f@mediaarea.net> Date: Tue, 22 Sep 2020 17:56:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <160075274666.1307.15063603679468881336@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 2217741345573507181 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrudeggdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeekhfdvgfeuhffggefhfffhtdehfffhudeuveejtdfgjefgleelueejheetfffgjeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegiedrvddvfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheileekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Erik Kline's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2020 15:57:00 -0000 Hi Erik, Thank you for your feedback. I handled the issues in the following PR: https://github.com/FFmpeg/FFV1/pull/229 And it is being reviewed by other FFV1 spec authors. Jérôme On 22/09/2020 07:32, Erik Kline via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ comments ]] > > [ section 3.3 ] > > * Suggest either defining colorspace_type value and coder_type values > before using them, or provide a reference in this section (i.e. just > include a reference to sections 4.2.3 and 4.2.5). > > > [[ nits ]] > > [ section 3.2 ] > > * In the description of Figure 3: > "relatively positions" -> "relatively positioned", I think. > > [ section 3.3 ] > > * "signed 16-bit signed integer": choose any one instance of 'signed', I'd say > > [ section 3.7.2 ] > > * "and then if used transparency" -> "and then, if used, transparency" From nobody Tue Sep 22 17:50:40 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846E43A090E for ; Tue, 22 Sep 2020 17:50:38 -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 9IaoFXnHAVH6 for ; Tue, 22 Sep 2020 17:50:37 -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 5400C3A0907 for ; Tue, 22 Sep 2020 17:50:37 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id v60so14165636ybi.10 for ; Tue, 22 Sep 2020 17:50:37 -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=O028bjY5tDj8L2MjClur7XD6dp4+5+XfVAq4g5z3rdo=; b=L/QkTaYe2u4H5k57Zl1uwDVgpKfkSr85ueKXRTO+7tJkjwz7DS9JMNSD+rmvovF7E5 1Ihij6G8Ix7lfnewfg4VW+KKqhwl4sFzD0RtQ2LwiRAwwhKBfokYVd7UHLfKjcElsvAQ sJjlW01dj0YOYdnKpApZ5tTMwAvqvoYybFYN0nRZK6QZ4zFWVQyM4H1T+/8C+mwny7o3 d1B2v341YqekHBC/tV0gjlDceOVoHqSD7WRnHPTNw5XBLVicCrBfKgr83/qtOq65syIQ BYE6yjby5tnOQAc2+nsCkBkxyuY7Y9uTIaj/A0uKyi8klbkXjMr8b3L5Zky6bpG1eFMb vtYg== 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=O028bjY5tDj8L2MjClur7XD6dp4+5+XfVAq4g5z3rdo=; b=CTGHzN9RiArTPyO/oJUiojJtuu8G7TYpccUDKeJ/NF9t+Pcssw2/XOQFNFavn3Yoxi jwmCWHnl6pZXZk1bYcRbnVlbSoeFVTojpLKcMowenv/8iDL7YvXAMM9ZsukGLVbNwEvQ yBBWv+hS5kiI80hymLqO07mviHiCK4Q7C7A7NP0G9GmLfE37UpauAmSOGztyLZWgqY56 EHCz/Bywl6JpcuKYKqmKys9tEe/glLDZT636WI9Kwt8jZOeSrsekykZt6wTAYsj8jtkC EmSSOIqrXWb5q6mIek2W173C0PuKwX+0Y3JkkKFa/62AHd2dLf0IfE+zaGIjcRngqCR6 55Cg== X-Gm-Message-State: AOAM5337e1TLA6/H/RD42AUHY8YIp+zjXv2aMFw0xJkgCXSnZJuHIFHv 4FOnn5JoqG9YhO1dVETeeCAzPKUHqpCqvwkTM3Q5VOzaIJg= X-Google-Smtp-Source: ABdhPJxrwVMo9e/7Y29qkLy7FKUryr/kOos6HXx8tJz/v9CBr0+1rmkuhh+voANRSCyKN+dTPDYprhry9I01+6RC5ig= X-Received: by 2002:a25:ab8e:: with SMTP id v14mr10853837ybi.465.1600822236211; Tue, 22 Sep 2020 17:50:36 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 22 Sep 2020 19:50:10 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000bcf11b05aff07856" Archived-At: Subject: [Cellar] Updated Cellar Github weekly 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: Wed, 23 Sep 2020 00:50:39 -0000 --000000000000bcf11b05aff07856 Content-Type: text/plain; charset="UTF-8" Dear Cellar, We noted on today's conference call that not everyone was aware of all the Gitbub issues and PRs that people have been working on. After poking around, I discovered that we were only asking for two repos to be included in our weekly summaries. I added all the repos I know about that people have been discussing, so we should now get weekly summaries on all of these: "repos": [ "cellar-wg/ebml-specification" "cellar-wg/matroska-specification", "FFmpeg/FFV1" "cellar-wg/Cellar-FLAC" "cellar-wg/chair-notes" Am I missing anything? Best, Spencer --000000000000bcf11b05aff07856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Cellar,=C2=A0

    We noted on today= 9;s conference call that not everyone was aware of all the Gitbub=C2=A0issu= es and PRs that people have been working on. After poking around, I discove= red that we were only asking for two repos to be included in our weekly sum= maries.=C2=A0

    I added all the repos I know about t= hat people have been discussing, so we should now get weekly summaries on a= ll of these:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "repos": [
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "cellar-wg/ebml-specification"
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "cellar-wg/matroska-specificati= on",
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= FFmpeg/FFV1"
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "cellar-wg/Cellar-FLAC"
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 "cellar-wg/chair-notes"

    <= /div>
    Am I missing anything?

    Best,
    <= br>
    Spencer
    --000000000000bcf11b05aff07856-- From nobody Wed Sep 23 19:28:25 2020 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 677493A1717; Wed, 23 Sep 2020 19:28:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160091449895.4375.5470050808465123697@ietfa.amsl.com> Date: Wed, 23 Sep 2020 19:28:19 -0700 Archived-At: Subject: [Cellar] Alissa Cooper's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) 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: Thu, 24 Sep 2020 02:28:19 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cellar-ffv1-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Glad to see this work finishing up. I think it would be better if each figure were explained in the text (e.g., "..., as shown in Figure 9"), or if the figure numbers were dropped. From nobody Wed Sep 23 19:31:12 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FAE3A1718; Wed, 23 Sep 2020 19:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=KE11sHY0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RuG4YkX0 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 MImJm7Mz8YZN; Wed, 23 Sep 2020 19:31:07 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1683A1717; Wed, 23 Sep 2020 19:31:06 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 222455C00FB; Wed, 23 Sep 2020 22:31:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 23 Sep 2020 22:31:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=KVsxtM+ADy2bX3jic0Wt03C BVvdAitN7H3IAirZnNLA=; b=KE11sHY0dEyvAe24oy30YRdAo3ow1OaYGGs1lX8 aIBKIJROj+1PJbAUyPig9ayhv0xbBPvtTDtA+m95tFIAyDTbUvcSxKu7irQ1vX9X IdXfbPRBKtd8fep7PSYCnpuVhMutrrAElyGPX3CN7xEv1CElspLE5Sh3M5HFTmy2 4QLB+lvqRGzMWavmns6aoWX5so7b4rsgSWkh2o9pkR0wpaUSJbsRExBo910zjW6H ekWPC20a41KPx9Fgrd8eJ48ULE3qeW+53oRpQZPpR0SvxzDhqr28zZF6i9hhaTxl Z3M2FOBBG1lw5YyPVPEHx19vZdiRdr+2BhY3CJTJ1qpqaCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=KVsxtM +ADy2bX3jic0Wt03CBVvdAitN7H3IAirZnNLA=; b=RuG4YkX0iG1r97SrZkLkGC QsS/oQjOhIrsIq8RegBtSOs0q1mdXo98ajJzawY2uvzSQC3Sie+yCWjB2HvfGD+N VmGMEjRJsINP+mLp6XbRGjdjM1JlI8Hsonpbz7xG/gUjG2lPlL3vWbIfexu6V5V1 bomqCWCRvFGm7yU9uy7bM7YoCdlER5ycBnbefCtft2jBSY+ysWSZPqdebaA2Jvbx Aqm01YXEzQMR1wzSH/xx5yYH5JcfCLRuaAxCH/bqfqStUy6PLlmczlFLq1U7T426 AsJz+ou5+upSRJVzxAT4q0wD0va9YP6et+F7SssF8waOvccOojqlK/EhefHEjvww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtjeenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpeeggefffeduvdfffeelgfehkedtiefghefftdetteeifeefhfefudegudeuvdev hfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrje ejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl ihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 581703064674; Wed, 23 Sep 2020 22:31:05 -0400 (EDT) From: Alissa Cooper Message-Id: <1DAF68ED-510B-4960-B1F2-4647073F5274@cooperw.in> Content-Type: multipart/alternative; boundary="Apple-Mail=_3430C6E0-07F9-4120-AB8B-424CC1C9B27E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 23 Sep 2020 22:31:04 -0400 In-Reply-To: Cc: last-call@ietf.org, gen-art , Codec Encoding for LossLess Archiving and Realtime transmission , draft-ietf-cellar-ffv1.all@ietf.org To: Spencer Dawkins at IETF , Joel Halpern References: <159470027331.24170.16229303627582288772@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cellar] [Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16 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 Sep 2020 02:31:10 -0000 --Apple-Mail=_3430C6E0-07F9-4120-AB8B-424CC1C9B27E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, thanks for your review. Spencer, thanks for helping to get = Joel=E2=80=99s comments addressed. I entered a No Objection ballot. Alissa > On Jul 16, 2020, at 11:17 AM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Joel,=20 >=20 > On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via Datatracker = > wrote: > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > >. >=20 > Document: draft-ietf-cellar-ffv1-16 > Reviewer: Joel Halpern > Review Date: 2020-07-13 > IETF LC End Date: 2020-07-16 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: This document appears to be ready for publication as an = Informational > RFC. >=20 > *I would have raised question about the intended status, but it = appears that > this is an established IETF convention and I see no reason to argue.) >=20 > Major issues: >=20 > Minor issues: > Section 3.4 (Context) introduces the notation Q_{#}[ subscript }. = As that > is the first reference to Q_{#}, it is rather confusing to the = reader. I > grant that the term is defined in the next section (3.5). = Couldn't they be > reversed? >=20 > Section 3.8.1.1 refers to C(i), C_{i}, and C_i. Are these all the = same > thing. >=20 > Section 3.8.1.2 refers to get-rac (which is treated as a function = in the > pseudo-code) as being the process described in section 3.8.1.1. = The text > in 3.8.1.1 does not call out any of its computed values as an = explicit > result or return. While I would guess that the intention is to = use the > byte stream (B()), the text does not actually say that. If that = is the > intention, could the last line of 3.8.1.1 be "get_rac() returns = sequential > bytes from the Byte Stream (B()) as computed by the computation = described > in section 3.8.1.1"? >=20 > Nits/editorial comments: >=20 > Thanks for the review! We'll work through these comments. >=20 > Best, >=20 > Spencer=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_3430C6E0-07F9-4120-AB8B-424CC1C9B27E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Joel,= thanks for your review. Spencer, thanks for helping to get Joel=E2=80=99s= comments addressed. I entered a No Objection ballot.

    Alissa


    On Jul 16, 2020, at 11:17 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

    Hi, Joel, 

    On Mon, Jul 13, 2020 at 11:17 PM Joel Halpern via = Datatracker <noreply@ietf.org> wrote:
    Reviewer: Joel Halpern
    Review result: Ready

    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments = just
    like any other last call comments.

    For more information, please see the FAQ at

    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

    Document: draft-ietf-cellar-ffv1-16
    Reviewer: Joel Halpern
    Review Date: 2020-07-13
    IETF LC End Date: 2020-07-16
    IESG Telechat date: Not scheduled for a telechat

    Summary: This document appears to be ready for publication as an = Informational
    RFC.

    *I would have raised question about the intended status, but it appears = that
    this is an established IETF convention and I see no reason to argue.)

    Major issues:

    Minor issues:
        Section 3.4 (Context) introduces the notation Q_{#}[ = subscript }.  As that
        is the first reference to Q_{#}, it is rather confusing to = the reader.  I
        grant that the term is defined in the next section = (3.5).  Couldn't they be
        reversed?

        Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are = these all the same
        thing.

        Section 3.8.1.2 refers to get-rac (which is treated as a = function in the
        pseudo-code) as being the process described in section = 3.8.1.1.  The text
        in 3.8.1.1 does not call out any of its computed values as = an explicit
        result or return.  While I would guess that the = intention is to use the
        byte stream (B()), the text does not actually say = that.  If that is the
        intention, could the last line of 3.8.1.1 be "get_rac() = returns sequential
        bytes from the Byte Stream (B()) as computed by the = computation described
        in section 3.8.1.1"?

    Nits/editorial comments:

    Thanks for the review! We'll work = through these comments.

    Best,

    Spencer 
    _______________________________________________
    Gen-art = mailing list
    Gen-art@ietf.org
    https://www.ietf.org/mailman/listinfo/gen-art

    = --Apple-Mail=_3430C6E0-07F9-4120-AB8B-424CC1C9B27E-- From nobody Wed Sep 23 19:32:00 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381413A17A5; Wed, 23 Sep 2020 19:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=dPhBEldY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AGWbcE4V 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 mqGQMRG_vOVJ; Wed, 23 Sep 2020 19:31:51 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FA33A1773; Wed, 23 Sep 2020 19:31:42 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 42A8F5C011D; Wed, 23 Sep 2020 22:31:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 23 Sep 2020 22:31:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=W KOYgjdAw9V1F6w9Nj4cMSs2U45SyCPInoP1OofmmMU=; b=dPhBEldYCECe1LXdA WK6qZQ0tDuXu8Px+lr2J5RN2/ZeYiCkXFJypcCyEs48ZEsYeg+rg2mnUc73EsiVx jxPxvsBccmekWyuPBMU1mKFYfcK36nqAxmZZ3fv4Kg1Rv3FersUvOf2AbnwuzvU3 qc0CZhpx80VH7nrg4nCy98lI0CBAmlAu+t14URn0BkKmKMlFxnY6dZ75XBOB/YLl mVpfTs8XMD9dDn/4MUskdN5zNsH2c3guxFkZfpy6z/CbXR9iUAPSJL9zPHxsvUbR uld71Gk2j3MNGzXm7V99vZvwik/q5wrh5wpxuS7rLNlBZE6ZuvkzKhN3QM0rFPvn yKzJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=WKOYgjdAw9V1F6w9Nj4cMSs2U45SyCPInoP1Oofmm MU=; b=AGWbcE4VXVGcytYDQA4uBpxGn1uJgcsbizxWRYkcuvDvVVm5ozZIGjBjL KKonCRK1DxZx5j6Fqt6JInX0yryRJodKy69Dc8HnN6NUrf1Iw41mnYpR30qRpXQv Yg/cZAviNt9GBzPQgY4TyXyIXBffkLpnD76b3qOiZE9AFNjCgqfH3CY6Klw8JA65 29zcKVTupatog8iVmKvQNgXGDcvTJPyUZi+1DCGuujs8yLCWjZOHRLmmkTEUhcL3 xYurw1ntMazlAhtZ4o/GJeTFSa3emuTxulw7ZyvCOMmR5P+h3CzqzydeNih7SAd2 66Fw6UbI/El72bOTfuEIG2Je6CodQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnheptdejtdeuteekieejuddvuefhjeeggfeuffffkeeltedugfdtfedtjeduieet veehnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecukfhppe dujeefrdefkedruddujedrjeejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.77]) by mail.messagingengine.com (Postfix) with ESMTPA id B15CA306467E; Wed, 23 Sep 2020 22:31:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Alissa Cooper In-Reply-To: <31b43c76-1c3f-a669-fc1d-9f08999cebf3@outer-planes.net> Date: Wed, 23 Sep 2020 22:31:41 -0400 Cc: Dave Rice , gen-art@ietf.org, cellar@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5395D1B9-6229-4AC1-8F09-9AAC1E9089D2@cooperw.in> References: <153082443369.26281.17163340643478720739@ietfa.amsl.com> <4016F335-7C19-4F25-AED8-B4A97E0F3A97@dericed.com> <31b43c76-1c3f-a669-fc1d-9f08999cebf3@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [Cellar] [Gen-art] Genart early review of draft-ietf-cellar-ffv1-03 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 Sep 2020 02:31:59 -0000 Matt, thanks for your (long-ago) review. Dave, thanks for addressing = Matt=E2=80=99s comments. Alissa > On Jul 6, 2018, at 1:50 PM, Matthew A. Miller = wrote: >=20 > Thanks Dave for the quick work! I've read through the PR and commits > you provided, and think it will be in much better shape. I look = forward > to reviewing the next published revision. >=20 > I've made contextual responses below to outstanding questions. >=20 > On 18/07/06 09:23, Dave Rice wrote: >> Hi, >> Thank you Matthew for this detailed review. Here are my comments = related >> to a PR at https://github.com/FFmpeg/FFV1/pull/119 which responds to >> some of these comments. Other comments below may require more = discussion. >>=20 >>> On Jul 5, 2018, at 5:00 PM, Matthew Miller >>> >> > wrote: >>>=20 >>> Reviewer: Matthew Miller >>> Review result: On the Right Track >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> . >>>=20 >>> Document: draft-ietf-cellar-ffv1-03 >>> Reviewer: Matthew A. Miller >>> Review Date: 2018-07-05 >>> IETF LC End Date: N/A >>> IESG Telechat date: N/A >>>=20 >>> Summary: >>>=20 >>> This document is moving in the right direction, but needs >>> work. Overall, the document feels unfinished. It's clear >>> a lot of work has gone into this, and there's been tremendous >>> effort put into the details. However, it's lacking some >>> clarity, that was present in older revisions that were removed; >>> speculatively is it due to more generic coverage that >>> later revisions covered? >>=20 >> I=E2=80=99m not sure I understand as it hasn=E2=80=99t seemed like = many parts have been >> removed during the drafting work. Could you provide an example? >>=20 >=20 > When I first opened this document, I felt overwhelmed by some of the > terminology and unclear on what the structure/architecture was, so I = did > some spelunking. It's largely why I took my review is five days late > despite having 30 days to get through it (that, and I still > procrastinated some in the middle). >=20 > I went all the way back to versions prior to WG adoption and saw there > were some additional prose throughout; although it seemed the earlier > revisions were more restricted in what could be represented in FFV1 = than > the current document allows, it helped me better understand. >=20 > I apologize for not taking more detailed note of which sections in = those > previous revisions helped me the most, but I can try to do that. > However, I think the additions and reorganization in the PR goes a = long > way to helping already. >=20 >>> The introduction is quite helpful in answering the inevitable >>> question "What is a FFV1?". For the most part, the flow of >>> the document seems to make sense. >>>=20 >>> Major issues: >>>=20 >>> I can understand relying on pseudo-code for something very math- >>> and/or algorithm-heavy, but some prose would be quite helpful in >>> understanding how and why the parts relate to one another. The >>> Definitions section is essentially what I would look for, but only >>> accounts for some of the terms used within the rest of the >>> document. As written, this document depends entirely on the >>> reader being intimately familiar with the subject matter. >>=20 >> This has been discussed before and I=E2=80=99ve appreciated how some = other IETF >> documents which include pseudo-code include an =E2=80=9Cas read=E2=80=9D= narrative >> version of the code as well. I think there may have been some concern = of >> any risk of discrepancy between what the pseudo-code and the = narrative >> of the pseudo-code communicate. If anyone know some boilerplate for >> managing this, please share. >>=20 >=20 > My experience has been that (pseud-)code is great to cover the = details, > but the overall forest can get lost reading each tree. I think the > additional terms added plus some of the reorganizing addresses this > concern, but I'd need to re-read the document with all the changes to = be > sure. >=20 >>> Minor issues: >>>=20 >>> * Please consider moving the text of Section 2.2.6. "Pseudo-code" >>> up a level to 2.2. "Conventions" or as the first sub-section under >>> 2.2. "Conventions". This points seems to me to warrant more >>> significance than it currently has. >>=20 >> I started a pull request at https://github.com/FFmpeg/FFV1/pull/119 = and >> moved this section. >>=20 >>> * In reading this, I wondered if it would help improve the >>> understanding of this document if Sections 3. and 4. swapped >>> places. I think it's worth considering, but accept this >>> suggestion could be rejected. >>=20 >> I reviewed these sections and feel hesitant swapping the order = outright. >> Any other comments from cellar on this proposal? >>=20 >=20 > I personally felt I had a better grasp of the document after reading > Section 4 and re-reading Section 3. If such a big change is too much, > think it might be possible to expand the introduction or background a > bit to restate/duplicate some of the high-level structure; e.g., how > Containers, Frames, and Slices fit together. >=20 >>> * Please consider moving Section 4.8. "Parameters" to immediately >>> proceed from Section 4.1. "Configuration Record". I think it >>> would help with understanding the document. >>=20 >> I agree. I moved it in the pull request. >>=20 >>> * Please consider moving the ASCII diagram of a Frame from >>> Section 9.1.1. "Multi-threading support and independence of slices" >>> to Section 4.2. "Frame=E2=80=9D. >>=20 >> I agree. I moved it in the pull request. >>=20 >>> Nits/editorial comments: >>>=20 >>> * In Section 2.1. "Definitions", a short description of what a >>> "Frame" and "Slice" are conceptually would be very helpful. >>=20 >> I agree. I moved it in the pull request. Comments welcome on these >> definitions: >>=20 >> `Frame`: An encoded representation of a complete static image. >>=20 >> `Slice`: A spatial sub-section of a `Frame` that is encoded = separately >> from an other region of the same frame. >>=20 >>> * In Section 2.2.4. "Mathematical functions", the definition of >>> "ceil(a)"" appears to be a copy from "floor(a)"; I would suggest: >>>=20 >>> """ >>> ceil(a) the smallest integer greater than or equal to a >>> =E2=80=9C"" >>=20 >> Already fixed >> in = https://github.com/FFmpeg/FFV1/commit/a6191aae2beb29879ac7f82530fa92a950f8= a4bb. >>=20 >>> * In Section 2.2.6. "Pseudo-code", the word "as" ought to be >>> "and" in "as uses its=E2=80=9D. >>=20 >> Fixed in PR. >>=20 >>> * The first use of "JEP2000-RCT" (in Section 3.3.) is not >>> immediately followed with its reference. >>=20 >> I added the reference to the first use in the PR. >>=20 >>> * In Section 3.7.2. "RGB", there is a paragraph that is solely >>> ""[ISO.15444-1.2016]"", almost as if it's a reference that was >>> meant a section heading. >>=20 >> Fixed >> in = https://github.com/FFmpeg/FFV1/commit/8b6304ebf25764b5d2820497be1ad90ebadc= 624f. >>=20 >>> * In Section 3.8.1. "Range coding mode", there appears to be some >>> odd formatting with "_G. Nigel_ and "N. Martin_"; is this an >>> attempt to italicize? >>=20 >> Removed in PR. >>=20 >>> * Most of the subsection contents with Section 4. seem to have >>> extraneous newlines (e.g., 4.1.1. "reserved_for_future_use=E2=80=9D). >>=20 >> I suggest some discussion on this. I remember that it was discussed = by >> not resolved. See https://github.com/FFmpeg/FFV1/pull/85. >>=20 >=20 > I read the commentary from that PR, and appreciate the argument. I'm > also anticipating the RFC Editor coming back with proposed changes = that > better match their conventions. >=20 > If I may suggest after read the PR comments, taking the current line > breaks and treating them as paragraphs seems like a reasonable = editorial > change to me that appears to align with the comments. >=20 >>> * In Section 4.4.9. "sar_den", the text is identical to the >>> preceding section. I think this is meant to be the denominator >>> to complement "sar_num" as the numerator. >>=20 >> Thanks. Fixed in PR. >>=20 >>> * In Section 4.5.1. "primary_color_count", the pseudo-code is >>> inline with no quotes, which is inconsistent with the rest of the >>> document. >>=20 >> Thanks. Fixed in PR. >>=20 >>> * In Section 4.7.1. "slice_size", the "Note:" appears to be two >>> sentence fragments. I think the following conveys the same >>> meaning: >>>=20 >>> """ >>> Note: this allows finding the start of slices before previous >>> slices have been fully decoded, and allows parallel decoding as >>> well as error resilience. >>> =E2=80=9C"" >>=20 >> Thanks. Fixed in PR. >>=20 >>> * Section 11. "ToDo" still as one item remaining. >>=20 >> This is moved to a github issue. >>=20 >> Thanks again, >> Dave Rice >>=20 >=20 > And thank you, >=20 >=20 > - m&m >=20 > Matthew A. Miller >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Sep 24 02:07:44 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744193A03FC for ; Thu, 24 Sep 2020 02:07:41 -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 gyCfV4wzH7f7 for ; Thu, 24 Sep 2020 02:07:38 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 4BA7A3A03FB for ; Thu, 24 Sep 2020 02:07:38 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id w25so1659422vsk.9 for ; Thu, 24 Sep 2020 02:07:38 -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=hSPdNUV5O2kSU4Q1M8pI8X+n1csjqkaMMbsWG28mpDk=; b=QdhnlCgbtH7bUE5D24l7TfUnlz8ce0NkQPlnyUgsyIZHFA7Z/0H0oAih6hPDUqcllJ OrSTgOfQzfv7dv3sSeW4MXaTUpHlempV0Rol9V8W1FiPDgQdX2L6Kohm4dPfhY35VFvi z1i3HNXYQi9erktKqjyQ19EZjzWlhYT+n9dNFktZ6q0YkqbRx5fvmFew5BdcyTMqDWa+ N/EeD2D3Libfk+G4DpWP4/uebBHKB9L/ddx/QFp15eaB9OCn62jTsFh1eNagl+EBpZxu 3xvykrwHhXJacbhMPhbOkcYU7fqwAjMPxg7nRvLHYMMZI7C0JJsy0wQUBkKCkF8w9UPE h55Q== 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=hSPdNUV5O2kSU4Q1M8pI8X+n1csjqkaMMbsWG28mpDk=; b=PjMa4Y53MkJeAlR0qAyMAmh1nAkOm/e1aCxaT8ZbKiRX2y2nLrd8yuJUhQG2odkRyk tCfQWFTgc80ePssKVF95++Oy9YAUkJqpCF9OetNiKYdbZdfzx5a+S7UOFwBZkHoYfMWo T5tviBGRQKqcsAjRsMLlfeb9ix0HlurOIF4c/QtssAJ39XC1YOcQd2hJQyoN+X0uMzhA A02YH2u5H/6O5Y+i3Die5Gz+2Np8C7atI33XRRysIW0rtGngdmyxsAHWwnTGqqtd4AkE ojPWfEGA1pqV7JLpj/3sIgf8Iu9c2KRYHDImO33ySqxnD8iXX2kN27tj9iIOBmHg96Qq CLmQ== X-Gm-Message-State: AOAM532Oa+IIVyBvdukN2xxLwxe6rhSexkBaOVmgx9qGjv78aCX6Hcor AeFL/Wp++7l3Iuj6B+W+ASySrGyWAtYyO4MQ0aw= X-Google-Smtp-Source: ABdhPJzwG5vc8bYMibGCQ33+I95LyfTQ3qoKjBjC2A9S/S8xX3YL0H+zuDUqQomdCav3CIHQ2oI9qEUmt+nXTMi7RSg= X-Received: by 2002:a67:e248:: with SMTP id w8mr2777325vse.33.1600938457235; Thu, 24 Sep 2020 02:07:37 -0700 (PDT) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> In-Reply-To: <160049032442.20595.4616862102756589735@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Thu, 24 Sep 2020 02:07:22 -0700 Message-ID: To: Barry Leiba Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000000d02e305b00b88c9" Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 09:07:42 -0000 --0000000000000d02e305b00b88c9 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 18, 2020 at 9:38 PM Barry Leiba via Datatracker < noreply@ietf.org> wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-cellar-ffv1-17: Discuss > [...] > There were enough issues raised in Barry's DISCUSS that I decided to push this document off of this week's telechat agenda to the next one (in two weeks) rather than having the whole IESG look at it. Could we get a new version out by, say, October 4th, that clarifies as much of this as possible? -MSK --0000000000000d02e305b00b88c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Fri, Sep 18, 2020 at 9:38 PM Barry Lei= ba via Datatracker <noreply@ietf.org= > wrote:
    Barry Leiba has entered the following ballot pos= ition for
    draft-ietf-cellar-ffv1-17: Discuss
    [...]

    There were enough issues raised in Barry's DISCUSS tha= t I decided to push this document off of this week's telechat agenda to= the next one (in two weeks) rather than having the whole IESG look at it.= =C2=A0 Could we get a new version out by, say, October 4th, that clarifies = as much of this as possible?

    =
    -MSK
    --0000000000000d02e305b00b88c9-- From nobody Thu Sep 24 02:10:46 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEA63A0407 for ; Thu, 24 Sep 2020 02:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URHZUiWWyLJ2 for ; Thu, 24 Sep 2020 02:10:39 -0700 (PDT) Received: from 4.mo6.mail-out.ovh.net (4.mo6.mail-out.ovh.net [87.98.184.159]) (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 B96FB3A03FB for ; Thu, 24 Sep 2020 02:10:39 -0700 (PDT) Received: from player778.ha.ovh.net (unknown [10.110.115.195]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 7C43E22969F for ; Thu, 24 Sep 2020 11:10:37 +0200 (CEST) Received: from mediaarea.net (p548f92df.dip0.t-ipconnect.de [84.143.146.223]) (Authenticated sender: jerome@mediaarea.net) by player778.ha.ovh.net (Postfix) with ESMTPSA id BBCC0167DDAD9 for ; Thu, 24 Sep 2020 09:10:36 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-100R0033fcc9638-a151-41cc-8af2-bdce203a7f71, C1E30036F02E62C420EEA0DCDE13D441F4B0E5A6) smtp.auth=jerome@mediaarea.net To: cellar@ietf.org References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> From: Jerome Martinez Message-ID: <564afa37-447d-4edf-d815-0f12d9ded2da@mediaarea.net> Date: Thu, 24 Sep 2020 11:10:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EE30BDE3D22BCFA6D64AA506" Content-Language: en-US X-Ovh-Tracer-Id: 7101332189675524241 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrudekgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpefgjefhueehhfelffevfffgvdevhfelkefglefhgeehfeduvedvuedthfehvedutdenucfkpheptddrtddrtddrtddpkeegrddugeefrddugeeirddvvdefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeejkedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 09:10:42 -0000 This is a multi-part message in MIME format. --------------EE30BDE3D22BCFA6D64AA506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 24/09/2020 11:07, Murray S. Kucherawy wrote: > > There were enough issues raised in Barry's DISCUSS that I decided to > push this document off of this week's telechat agenda to the next one > (in two weeks) rather than having the whole IESG look at it.  Could we > get a new version out by, say, October 4th, that clarifies as much of > this as possible? We are working on the issues, October 4th seems a good dead line for a new version. Jérôme --------------EE30BDE3D22BCFA6D64AA506 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    On 24/09/2020 11:07, Murray S. Kucherawy wrote:

    There were enough issues raised in Barry's DISCUSS that I decided to push this document off of this week's telechat agenda to the next one (in two weeks) rather than having the whole IESG look at it.  Could we get a new version out by, say, October 4th, that clarifies as much of this as possible?

    We are working on the issues, October 4th seems a good dead line for a new version.

    Jérôme

    --------------EE30BDE3D22BCFA6D64AA506-- From nobody Thu Sep 24 07:32:10 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C103E3A0D5E; Thu, 24 Sep 2020 07:32:07 -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 HIHR8cZLV-5H; Thu, 24 Sep 2020 07:32:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A993A0D4E; Thu, 24 Sep 2020 07:32:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EED15389B4; Thu, 24 Sep 2020 10:10:38 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WKhyuptvkH7W; Thu, 24 Sep 2020 10:10:38 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CC0A389B3; Thu, 24 Sep 2020 10:10:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CECD5824; Thu, 24 Sep 2020 10:32:01 -0400 (EDT) From: Michael Richardson To: Alissa Cooper cc: "The IESG" , draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, "Peter B." In-Reply-To: <160091449895.4375.5470050808465123697@ietfa.amsl.com> References: <160091449895.4375.5470050808465123697@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Alissa Cooper's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2020 14:32:08 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alissa Cooper via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Glad to see this work finishing up. > I think it would be better if each figure were explained in the text = (e.g., > "..., as shown in Figure 9"), or if the figure numbers were dropped. It was the topic of Tuesday's virtual interim. I think that the section will get rewritten. The notation takes a bit of getting used, but it is still a bit difficult. It's obvious to people who already wrote code, but much less obvious to tho= se who are trying to write code. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9sreEACgkQgItw+93Q 3WWS3wgAj464/VIkzSyi5BlxXwu0kLZ8nFoq8X4J1x+Z77Qnfxz13YGBHxRQQs+z OfYJaAIrsMVGQUrkbcvAlI1vhmH5GlglnP37Hu2QE+siKWdwIyQXOs4fAcCFrVKX lChp77Uwci2T3Oxo3xq8vA0GSuHdEhB+UXULpql0r1zvALwT94HUFWUFMVlbREXg K25GnLGnvULNQAycY526ryErSR2XVYBJJeTVlvyg6sJdCJnDvyb3xDgrD9lWkw0u ByX+u9mp+lx+kN/vnyHka1/LC9GpZbv720lL/9HCVyG0P2q4xJzTngY9hHCvHRXk lk/5iZ8FyPWSULzUdQte0l2EXAXYmA== =LCcn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 25 08:17:03 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC31B3A0E53; Fri, 25 Sep 2020 08:17:00 -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 eu7u7yInDado; Fri, 25 Sep 2020 08:16:59 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 68CA03A0D56; Fri, 25 Sep 2020 08:16:59 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id x20so2239932ybs.8; Fri, 25 Sep 2020 08:16:59 -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=lSzBt5UtXhPRCrErAfvubkMlzMHOSbB9ldOepaRWjfQ=; b=gYjIQgooAHuuleVU918xXuzv7AVyPXAhoR2p35/Y0sX5fFjnMdeetICmafDUDYJtN0 YsPpiqzQmevVZRPiu5BJJwAe3YyuWH6Y+GSB1xsZ5uF/nFxOMScM7v9dBSWcEnSGYrTT Wsuy98xuJlJ70cUQG8bRwYfZj2iBSznhggEPt7wE6sNh/VCYhqR78K7+2CHRT452QuDl uAq6zBltZpiJFGEkFjJ0EnSTP4aKOqFDm6zXm0eh8E+QJq9wwPUlJjpnliMDRysHdNBi OLKdKKAKbXUwrT01erIh1nqa03ArDEONwQn00lZtYNqxiOIYPsEzKMwm94uGEqYvL0uL 2dJQ== 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=lSzBt5UtXhPRCrErAfvubkMlzMHOSbB9ldOepaRWjfQ=; b=CEGIZj4d73/wY5yf76+czt+fsDcDk7MpdA37HtNbjOGMv+XpfJmJy/5by0tdAcEJmJ 8zDTZESq5nLeE/ariDxnT2r11EUugzlKEi9E2yWMH/UYQPgv7gN2kKO2d7kM0zyB0v4c A1cW/RFjNmC09qFHMehucQK/HZ6Ky20MT2kUSlEYAIuLhA8hcseSHRa1PVPPayyrrm3m yylaZmY5dvLsKHA4uHIbijUtKLvLjICRbqKu8effqT5XwoVD+1lt/C++TwOZZhYgA9T2 asS3x2qWA28UPE4ay+oWmo8tBIkgr0XlRCthn0sqhJcp7h/mcio1VTxMUXkhy+bPZFNn +uaA== X-Gm-Message-State: AOAM531HJ/GgHAj8hFtjsJqzCyK0NcfYaCADspqD3C8AF9PxprBSZynl Pq+tlt5XL5m5HlJsZ4F5VVzu37GX2eLuilGTqFRZJ+dxt+k= X-Google-Smtp-Source: ABdhPJwoiu4p1hgURHEHMCvWyrCJjjlPn62wWe1YgxKDSiQ+7aRN18k24LIq2ijr/fsBXhZFuRngFu1G5yfcas2efQg= X-Received: by 2002:a25:9d92:: with SMTP id v18mr5736978ybp.297.1601047018468; Fri, 25 Sep 2020 08:16:58 -0700 (PDT) MIME-Version: 1.0 References: <160091449895.4375.5470050808465123697@ietfa.amsl.com> <3363.1600957921@localhost> In-Reply-To: <3363.1600957921@localhost> From: Spencer Dawkins at IETF Date: Fri, 25 Sep 2020 10:16:32 -0500 Message-ID: To: Michael Richardson Cc: Alissa Cooper , The IESG , draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , "Peter B." Content-Type: multipart/alternative; boundary="000000000000cdfc2305b024ce26" Archived-At: Subject: Re: [Cellar] Alissa Cooper's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2020 15:17:01 -0000 --000000000000cdfc2305b024ce26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Top-posting to say that I've posted minutes from our interim meeting at https://www.ietf.org/proceedings/interim-2020-cellar-11/minutes/minutes-int= erim-2020-cellar-11-202009221900-00 . Best, Spencer On Thu, Sep 24, 2020 at 9:32 AM Michael Richardson wrote: > Alissa Cooper via Datatracker wrote: > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > Glad to see this work finishing up. > > > I think it would be better if each figure were explained in the tex= t > (e.g., > > "..., as shown in Figure 9"), or if the figure numbers were dropped= . > > It was the topic of Tuesday's virtual interim. > I think that the section will get rewritten. > > The notation takes a bit of getting used, but it is still a bit difficult= . > It's obvious to people who already wrote code, but much less obvious to > those > who are trying to write code. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > --000000000000cdfc2305b024ce26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Top-posting to say that I've posted minutes from = our interim meeting at=C2=A0https://www.ietf.org/proceedings/interim-2020-cellar-11/minutes/minutes-in= terim-2020-cellar-11-202009221900-00.

    Best,

    Spencer

    On Thu, Sep 24, 2020 at 9:32 AM Michael Richa= rdson <mcr+ietf@sandelman.ca<= /a>> wrote:
    A= lissa Cooper via Datatracker <noreply@ietf.org> wrote:
    =C2=A0 =C2=A0 > --------------------------------------------------------= --------------
    =C2=A0 =C2=A0 > COMMENT:
    =C2=A0 =C2=A0 > --------------------------------------------------------= --------------

    =C2=A0 =C2=A0 > Glad to see this work finishing up.

    =C2=A0 =C2=A0 > I think it would be better if each figure were explained= in the text (e.g.,
    =C2=A0 =C2=A0 > "..., as shown in Figure 9"), or if the figure= numbers were dropped.

    It was the topic of Tuesday's virtual interim.
    I think that the section will get rewritten.

    The notation takes a bit of getting used, but it is still a bit difficult.<= br> It's obvious to people who already wrote code, but much less obvious to= those
    who are trying to write code.

    --
    Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




    --000000000000cdfc2305b024ce26-- From nobody Sun Sep 27 00:41:17 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2643A09B7 for ; Sun, 27 Sep 2020 00:41:15 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=gq0Q4EHz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pCUiLxrp 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 Wgr-S3h0G3uL for ; Sun, 27 Sep 2020 00:41:13 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B533A09A4 for ; Sun, 27 Sep 2020 00:41:13 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 43EC45C00F9 for ; Sun, 27 Sep 2020 03:33:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 27 Sep 2020 03:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=sqlXDt/gi/ffWU2KOsmLpC7tjtnHkCQ0HDPf7gLYSWc=; b=gq0Q4EHz 8RPQdfgKLTqw0+ilpgoYP1DuvQPK1HCFkTE0GyFFBjgUQWdFNHYqam344k4Zq0MG gaVKCgQymFcbr3MPAcqwa76fCEmc84G4op1qzcoPHE93OXo1y73EgVYdFQsedK/X Fdn/ihY+rsv0nAxewiSNLq9f2sjwgJL3QMpSf2E+GwvZB+EPtKu0MNVgYqhaPpwJ EjjaDsYgGtol6sQANHraN+uQZObXz53wsIf0y3YsvHW950xeTbZ8do+yqOIQeu6u gITyZhhjE8d6P3TLGlFd5n7/30+6Ujx2q5ytQCKqFWrqS7fvThdt5FuZ1Mn361e1 N4MV5RhNCbrI9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=sqlXDt/gi/ffWU2KOsmLpC7tjtnHk CQ0HDPf7gLYSWc=; b=pCUiLxrpabCPGmc1BEdW+pD9helPb4MtCbNztpQKP8oGg pWQPKg5nme3IdDllrgezsG/aEuqHS3RQDmKKBQDEutzK9oAKWMev3otxCh5DU3b4 cyk1UsxutgSnge41lfONz9/XCDnvvR+P5NYaa1A6E1G7b0i5VJwf/pgFdQrCMNn2 vh6C6KXq6T0N7fJLkkCqpdq3oV+4w0N228a8I2TvBh6t7o9xcNadVs6k3pM3jaNZ qeYc47R7GSRLjx2tTtUSCtSuJJfAntAsMezupFTgOLAnNT/Ggq2NicumLa7g+xqt 7+tI5iwyOg2VRU/KpAHGk40MjQ2QFvlvab5zJKmSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefgdduudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepudefrdeltddrfeekrdehie enucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [13.90.38.56]) by mail.messagingengine.com (Postfix) with ESMTPA id 0BA90328005D for ; Sun, 27 Sep 2020 03:33:22 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2867212656258172749==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200927073322.0BA90328005D@mailuser.nyi.internal> Date: Sun, 27 Sep 2020 03:33:22 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 07:41:16 -0000 --===============2867212656258172749== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/ebml-specification (+1/-0/=F0=9F=92=AC0) 1 issues created: - there is no 'minver' attribute for enum values (by robUx4) https://github.com/cellar-wg/ebml-specification/issues/390 [XML Schema]= [enhancement]=20 * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC0) 1 issues created: - Add V_MJPEG codec ID (by robUx4) https://github.com/cellar-wg/matroska-specification/issues/424 [format = addition] [spec_codecs]=20 * FFmpeg/FFV1 (+3/-1/=F0=9F=92=AC22) 3 issues created: - [v4] slices (by retokromer) https://github.com/FFmpeg/FFV1/issues/233=20 - section 3.8.1.1 should have pseudocode (by mcr) https://github.com/FFmpeg/FFV1/issues/231=20 - section 3.8.1.2 needs to define getrac (by mcr) https://github.com/FFmpeg/FFV1/issues/230=20 4 issues received 22 new comments: - #233 [v4] slices (5 by dericed, dwbuiten, retokromer) https://github.com/FFmpeg/FFV1/issues/233=20 - #231 section 3.8.1.1 should have pseudocode (11 by JeromeMartinez, dwbu= iten, mcr, michaelni) https://github.com/FFmpeg/FFV1/issues/231=20 - #230 section 3.8.1.2 needs to define get_rac (5 by dericed, dwbuiten, m= cr) https://github.com/FFmpeg/FFV1/issues/230=20 - #221 [v4] Consider other RCTs (1 by dwbuiten) https://github.com/FFmpeg/FFV1/issues/221=20 1 issues closed: - [v4] slices https://github.com/FFmpeg/FFV1/issues/233=20 * cellar-wg/Cellar-FLAC (+6/-0/=F0=9F=92=AC0) 6 issues created: - Unclear meaning of maximum frame size (with respect to reference implem= entation behavior) (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/91=20 - Missing singedness indication (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/90=20 - Included fixed LPC parameters (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/89=20 - LPC decoding details missing (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/88=20 - Missing specification of wasted bits-per-sample value (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/87=20 - Minimum block size does not include the last block (by fweimer) https://github.com/cellar-wg/Cellar-FLAC/issues/86=20 Pull requests ------------- * cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #220 Don't use all caps and distinguish between upper bound and maximum= (1 by robUx4) https://github.com/cellar-wg/ebml-specification/pull/220 [clarification= s]=20 * FFmpeg/FFV1 (+2/-1/=F0=9F=92=AC0) 2 pull requests submitted: - simplify artwork process (by dericed) https://github.com/FFmpeg/FFV1/pull/232=20 - IETF review update (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/229=20 1 pull requests merged: - IETF review update https://github.com/FFmpeg/FFV1/pull/229=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/ebml-specification * https://github.com/cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/cellar-wg/Cellar-FLAC * https://github.com/cellar-wg/chair-notes --===============2867212656258172749== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday September 27, 2020

    Events without label "editorial"

    Issues

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

    1 issues created:

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

    1 issues created:

    FFmpeg/FFV1 (+3/-1/=F0=9F=92=AC22)

    3 issues created:

    4 issues received 22 new comments:

    1 issues closed:

    cellar-wg/Cellar-FLAC (+6/-0/=F0=9F=92=AC0)

    6 issues created:

    Pull requests

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

    1 pull requests received 1 new comments:

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

    2 pull requests submitted:

    1 pull requests merged:

    Repositories tracked by this digest:

    --===============2867212656258172749==--