From nobody Mon Jun 1 08:56:20 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 EC5C13A117E; Mon, 1 Jun 2020 08:56:18 -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, superuser@gmail.com, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159102697843.19284.13508441497397999812@ietfa.amsl.com> Date: Mon, 01 Jun 2020 08:56:18 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 108 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 15:56:19 -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 108. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sun Jun 7 00:41: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 469F63A0A12 for ; Sun, 7 Jun 2020 00:41:50 -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=PyPgAKIt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qmEXucnY 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 7EoymwMZsLNo for ; Sun, 7 Jun 2020 00:41:48 -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 217DC3A0A11 for ; Sun, 7 Jun 2020 00:41:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C3BF35C00A8 for ; Sun, 7 Jun 2020 03:32:39 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 07 Jun 2020 03:32:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=6WAda1lgd6+huMojz7qM09BQFFDesmWCJZock4Dg8yM=; b=PyPgAKIt EfJGriTejMFnlDwEYRGk49c4KJnVjY7oa5pahHynJ/7xaeSLRm6tqps2UgwOzb8g Me0voOq5e9S1Oa9jL020Jg5u1Fkoets7spa/+drjk8aWBYcKWRzXPc9vDt8VGjWX 7XBLhr+ylERzyG6kpW30c8KSZcRaIw+0tZJBXsRK7fJz53+I0D6y2fevnlQzKjgN GxSyQKXlMbTiySM6/uRHFUmOWtwF1Aj7bb9dcViMIWqcT3dkSaUkZ3r50kyuxP5S ACUVils0lWuQ8ubYuCV2wsEFXxzyQfjxOE85qTOrATMOxMHkH0xVfbdof6/IhGZL xRNcYHmn9Leegw== 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=6WAda1lgd6+huMojz7qM09BQFFDes mWCJZock4Dg8yM=; b=qmEXucnYi9ExEB6NnOoe7gMgy2BPnu9HfBKoPEQN7sUTt BrpyWIAAygpy7ZNqw/6L+EEWvQ3IqA7ICsWfhDrKdepGAe/DfC1rNiy+vw3MtwlU Eg3NmTMhBLYFg1dd0rwUqq2mkDdbNP3edKdME5bmcI5TVBDLu2bmGF9FL8N42NVj IOoepnnss8GQDoKrYTiCIVzZpYko2QkgqUC/N/iNtyC49bBFw5AbCIhs3h5A5Swp 0RggwKJUF4RCGIdmyiqKhSReLg6DNIa7FN2TVFQdKNHyZ7/3YR6R0xZ0Ob+FE4Jm RCVPFwbdwfER8BoJwQbYscupnlVp77YWx8825CkAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepgedtrdeihedruddufedrud efvdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [40.65.113.132]) by mail.messagingengine.com (Postfix) with ESMTPA id 744B3328005A for ; Sun, 7 Jun 2020 03:32:39 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5138058859306245993==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200607073239.744B3328005A@mailuser.nyi.internal> Date: Sun, 7 Jun 2020 03:32:39 -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, 07 Jun 2020 07:41:50 -0000 --===============5138058859306245993== 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=AC6) 1 issues received 6 new comments: - #373 Write down how extra data is saved for usage with AVC & HEVC (6 by= doctorsirius, mbunkus, rcombs, steffenmanden) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 * cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC4) 1 issues received 4 new comments: - #341 XHTML Basic has been superseded (4 by retokromer, robUx4) https://github.com/cellar-wg/ebml-specification/issues/341 [bug] [forma= tting]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC2) 2 pull requests received 2 new comments: - #392 Fixes for website migration (1 by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/392 [website] = - #390 Add AVC and HEVC codec mappings with BlockAdditionMapping 2 (1 by = JeromeMartinez) https://github.com/cellar-wg/matroska-specification/pull/390=20 1 pull requests merged: - Fixes for website migration https://github.com/cellar-wg/matroska-specification/pull/392 [website] = * cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #339 add a more in-depth definition of an enum value (1 by robUx4) https://github.com/cellar-wg/ebml-specification/pull/339 [XML Schema] [= clarifications] [enhancement]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============5138058859306245993== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 07, 2020

Events without label "editorial"

Issues

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

1 issues received 6 new comments:

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

1 issues received 4 new comments:

Pull requests

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

2 pull requests received 2 new comments:

1 pull requests merged:

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

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============5138058859306245993==-- From nobody Sun Jun 14 00:33: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 0346F3A0CD1 for ; Sun, 14 Jun 2020 00:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=X09CvGts; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kMYcUekW 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 eJ5jTX8lYPQx for ; Sun, 14 Jun 2020 00:33:00 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69CC3A0C84 for ; Sun, 14 Jun 2020 00:33:00 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2745B433 for ; Sun, 14 Jun 2020 03:33:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 14 Jun 2020 03:33:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=jH4aq0KljybS+wr6lFYhXihwPjNMMCryNQK1cMH0xfs=; b=X09CvGts QyihJeftidwL3HumEycfGaCZttS1VsJ2WUG4oGgfMHMs8IQPuQLnI18mDa8yLPXm 4zpLwijOSqQwER4hdMWDPy8HsyugvIShPyIdbr3XBNHvp6CMhHIQqeYxdusHZp3j th3j8FR6ukeox+OgEJlC+/lZzBlEeDRG3A0OB/GkjJ61lPzytYhpobOArPP5d+BP 39H50jTwt6zzknU2NaCyElK6M+etEU2nzwXU0jLEOEAyhWt/HokQZw9TBmXCFh2+ WG3wQG4pNiPHt0oX35WNWpWJFuKARbDwFJq5Z+DJBy1T1kP/IX9Xzh/rSREC93Cb qwLHs8UNtDwDvA== 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=jH4aq0KljybS+wr6lFYhXihwPjNMM CryNQK1cMH0xfs=; b=kMYcUekWP0XVJwBJt/qtO9S1CZiQXEejGQvjFThfKGc/Q kwF4HsSVUGkcLU5HbMh/wqXFAx5bxgI1+BmF7H7bpP06So6yyXNJ80TTLtymtlgI hGfQy/rlPiTndgunVLYh3QHVIaLzRFH6QgCl23D49SN+MxWdB5AdiAybo1rbZPtO jEfsAcQ6KJHfPG/dm1kvaiWCvSA7WdNHxWjjjd59IvQM8+fdXNZLT7OrYp27PX/K kq9IsF6/Vnbinjso9use2iOU8982EC7bIcxVnNDaR1AaSpR6QRXKSh/kqa6PBg4N UjMaEqeAbUoFSk8fAE/B2OT1nAt1bMsqJ76W6scgQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeihedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddukeekrdduiedurd dutdenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az151.internal.cloudapp.net (unknown [52.188.161.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 8FBAB30614FA for ; Sun, 14 Jun 2020 03:32:59 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============2584595762149027093==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200614073259.8FBAB30614FA@mailuser.nyi.internal> Date: Sun, 14 Jun 2020 03:32:59 -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, 14 Jun 2020 07:33:11 -0000 --===============2584595762149027093== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC7) 3 pull requests received 7 new comments: - #390 Add AVC and HEVC codec mappings with BlockAdditionMapping 2 (4 by = JeromeMartinez, robUx4) https://github.com/cellar-wg/matroska-specification/pull/390 [codec map= ping] [spec_codecs]=20 - #389 Add AVC and HEVC codec mappings with BlockAdditionMapping (2 by mb= unkus, robUx4) https://github.com/cellar-wg/matroska-specification/pull/389 [codec map= ping] [spec_codecs]=20 - #377 Add AVC and HEVC codec mappings (1 by robUx4) https://github.com/cellar-wg/matroska-specification/pull/377 [codec map= ping] [spec_codecs]=20 * cellar-wg/ebml-specification (+7/-0/=F0=9F=92=AC0) 7 pull requests submitted: - add missing for in the range description (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/348 [bug] [formatt= ing]=20 - Clarify the big-endian storage of the EBML ID (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/347 [clarification= s]=20 - Fix the GlobalParentOccurence spelling (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/346 [clarification= s]=20 - reword the EBMLSchema XML usage as suggested in AUTH48 (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/345 [clarification= s]=20 - add some keywords to the document for easier searching in the RFCs (by = robUx4) https://github.com/cellar-wg/ebml-specification/pull/344 [build system]= =20 - rewrite introduction line as proposed during AUTH48 (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/343 [clarification= s]=20 - turn "xsd" sourcecode tag into "xml" tag (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/342 [bug] [formatt= ing]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============2584595762149027093== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 14, 2020

Events without label "editorial"

Pull requests

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

3 pull requests received 7 new comments:

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

7 pull requests submitted:

Repositories tracked by this digest:

--===============2584595762149027093==-- From nobody Wed Jun 17 08:38: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 ED14F3A0912 for ; Wed, 17 Jun 2020 08:38:05 -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 5ZDu0Tqd16k8 for ; Wed, 17 Jun 2020 08:38:04 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 2623D3A0907 for ; Wed, 17 Jun 2020 08:38:04 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id e4so3431193ljn.4 for ; Wed, 17 Jun 2020 08:38:04 -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=e8CAMAxnr3tEdybLyHT6UIp7ER8u/cVeFJDU72q+hjg=; b=GrSAVI/l4pS1AU+TIUUuqbZFPRGNAkn3xF8uuf6HsZ+jIlHu2Dbw4HtfrheZfgE9Nt yqkMPuEnxdsyzhu4JBbS0Pm34HzhPglR67UvmawmiXmZKpoqPhe3N4H9Cf8xE9uo4P5m RjEWq96FnYlHRc59vjG/q+NNaNt8xi0vh8zclejw8vnHSYoUVX+n2CErRImbh0IJDINq BWtJLCLq4kcXCSY7YdR6Q5NvZC73m8wvTxYuPNwgV76pEGKsGfyQPK+ltM2N9R2usDLC guRJ1vMZLPmOz9avNVEP3U74nFgIzd49KLE4TvphBxsAJXLqN10zhafTvACk/PWLhQCk YmEQ== 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=e8CAMAxnr3tEdybLyHT6UIp7ER8u/cVeFJDU72q+hjg=; b=RGQdwXNNXHAZ1mBYzv9+U+8o2JA5TVbjkbm9CPz6Hj58sy5+bRnnmnE5fw4HpJh6r8 tFOiwNgudMeepOzkkmgLnupqOp8lmPqXStXzSrvzJMD7SKf3e3u72RBXnlHJ53J/mj0A 9auI0xAZOF+lnFgE9YmPSwptl2qxN68P/Ah/2ibgeVwgKMUhmdAA88jvaMkmpDqv9xK5 FxRveQdr4nlTJbh4zgME/qx3WAdL43yrE1UW857/RF/sAkeqkEU52EWQm+nDL9NUS+MW GhfYih31eMj+Dlc1oDG/P8MXQ2eG1XhjtSUEDYpWI1E0qNznfbuGsaujme20ee1p7ugN E/lA== X-Gm-Message-State: AOAM5326qaOASrnzpjOehhjS1TVJC6iDFb0UzA9QfIXgb4IoOfYIYpjT LVb1KnhyzRlFPryyp0FrnRerjG2OJRT07bQqb7lNnr1z X-Google-Smtp-Source: ABdhPJymJt5i0+LiNRNt/yqxAsHCKKBVU55QEg8TBIoWjSFliwAXKSc3zdc6vyGEvbfFEsrWEaN2fmameZTCT7KJ3t8= X-Received: by 2002:a2e:9786:: with SMTP id y6mr4224851lji.398.1592408281750; Wed, 17 Jun 2020 08:38:01 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Wed, 17 Jun 2020 10:37:35 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000f8a16205a8497111" Archived-At: Subject: [Cellar] Agenda items for our virtual meeting on 6-23 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, 17 Jun 2020 15:38:06 -0000 --000000000000f8a16205a8497111 Content-Type: text/plain; charset="UTF-8" Dear CELLAR, Our next virtual meeting is coming up next Tuesday. If I didn't know any better, I'd suggest an agenda that looks this. Is there anything on my list that we've already handled, or that we can handle before the meeting? Is there anything we need to include in the agenda? Best, Spencer -- 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from April 28 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update EBML -- lots of pull requests in response to RFC Editor AUTH48 comments. Are we all OK with them? This is a product of the working group ... FFV1 -- version 14 was posted 26 May 2020 *** NEEDS REVISED VERSION after AD Review *** -14: almost complete after AD review, but 4 more items to do left in the draft. 5. EBML https://github.com/cellar-wg/ebml-specification/blame/master/specification.markdown#L582 This needs to be edited to match the XSD 6 Other Matroska issues AOB? --000000000000f8a16205a8497111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear CELLAR,=C2=A0

Our next virtual mee= ting is coming up next Tuesday.=C2=A0

If I didn= 9;t know any better, I'd suggest an agenda that looks this. Is there an= ything on my list that we've already handled, or that we can handle bef= ore the=C2=A0meeting?=C2=A0

Is there anything we n= eed to include in the=C2=A0agenda?

Best,

Spencer
--

1. Note Well.= https://www.ietf.org/abo= ut/note-well/
2. Accept draft minutes from April 28 meeting (attache= d below)
3. Logistics for Meeting.
2a) Etherpad for notes = https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=3Dtrue
2b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim
2c) Roll ca= ll

4. WG status update
EBML -- lots of pull requests in response = to RFC Editor AUTH48 comments. Are we all OK with them? This is a product o= f the working group ...=C2=A0
FFV1 -- version 14 was posted 26 May 2020 = *** NEEDS REVISED VERSION after AD Review ***
-14: almost complete after= AD review, but 4 more items to do left in the draft.

5. EBML <do= cumentation>
=C2=A0 =C2=A0https://github.co= m/cellar-wg/ebml-specification/blame/master/specification.markdown#L582=
This needs to be edited to match the XSD

6 Other Matroska issues=

AOB?
--000000000000f8a16205a8497111-- From nobody Wed Jun 17 17:56:16 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 DC17D3A08F3 for ; Wed, 17 Jun 2020 17:56:13 -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 1UK3ZXLOJKtN for ; Wed, 17 Jun 2020 17:56:12 -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 84B763A08E6 for ; Wed, 17 Jun 2020 17:56:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 14F9938A0C; Wed, 17 Jun 2020 20:53:36 -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 rlksyWHBR5i0; Wed, 17 Jun 2020 20:53:35 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EF11038A08; Wed, 17 Jun 2020 20:53:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64F3410F9; Wed, 17 Jun 2020 20:56:10 -0400 (EDT) From: Michael Richardson To: Spencer Dawkins at IETF cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Agenda items for our virtual meeting on 6-23 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, 18 Jun 2020 00:56:14 -0000 --=-=-= Content-Type: text/plain Spencer Dawkins at IETF wrote: > Our next virtual meeting is coming up next Tuesday. > If I didn't know any better, I'd suggest an agenda that looks this. Is > there anything on my list that we've already handled, or that we can handle > before the meeting? I haven't seen any reply from the rfc-editor about the missing AUTH48 files! > Is there anything we need to include in the agenda? September in-person. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7qu6oACgkQgItw+93Q 3WU8oggAs9gdoEzNPapaKjxBIsUD/ltEb6lC2xhyEl8ReeeHMfbW9uxjTn3oQ6GH TQL5OyvLD6lyxmrBNuTy/AH4bXjUX28ynXBp1b90BcUxvHFJ/EHriHPMU5yvzLqF WQk7HyaZqmIVYzH9ZjAdQSPVThvnQ02gtpJraJYAgGvyqkWnF0B/Wvhrqq7GDS/M 2cnWiyELIvuBosQCj0zSInwUYQGVim8itd5an7jfoyYO/H8IybxevmRI/JUNzo6s K32RxKM59zJODpGKSsx04zIJuIhw/Lz7zsgjMEEFE9Kzr0NuqyzuLiq57g8S7kzX pKWj9lwFNuTHozFyTQd9g+rfvt9IUA== =h5tx -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 18 19:06: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 4EA9F3A0FD7 for ; Thu, 18 Jun 2020 19:06:02 -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 GlML9zryrhNA for ; Thu, 18 Jun 2020 19:06:01 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 AFCA83A0FCA for ; Thu, 18 Jun 2020 19:06:00 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id i8so4650329lfo.4 for ; Thu, 18 Jun 2020 19:06:00 -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=KcekSI8Pm0mFTBn+AJhRDMGswdYdsF9trud8RhpoKHQ=; b=N2u/s4VTJ+t/qKwvfATU7/5VH5YMVz1dkQbDId+T6OVb+1Lbn0qVnZvA5P+EijYZJv zJUc9WlQQ4LgYGw5SffJCXgFibk9xxUAYMmOKuoWiIyRv3cMTEbxsHIQaSo8eKZu0/8l xtXt/+GlhQAXKbDR24pTd66f+3abWj7QQscDWHGQZtAD2+YdL9Fgri1XAXBgeD+fTZzg /UoTeW1FuIau9K6NJOlcB7BhCVe1bMwQ2DX3I5Xy1vPjT4fat3YyHqaDj019fLFetJn1 T+ffar08VvImnGsPnnxJF7QrUxawk3Y3/saPKVbXuOSgBGNQiOEzH0PIMiBvGWCP4PNo o1Pw== 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=KcekSI8Pm0mFTBn+AJhRDMGswdYdsF9trud8RhpoKHQ=; b=gF7ZmoeZ/dsFvnH+3g+a7rLc/pkBbnUNZzWsB7ZUgLQPlrCim+pLPRaS+Fa0Ff8rWA ejJDtztXRg3Ht5KalOfZa8js7fpuW4uacQacnTPe8Fv+Z1QWVt7v2M2VFV1uZcWseEsI W2ZzJ4/9scphDCjJCDIOSCqRLXIS2FV55fP+t3u8PluT+DnVEcYRqA6SamNudpcDrdSZ 1ZyHmfkgELV4HxFrjCNTzBkSrLgCe0M3CAlz0TFXRid/VckBrkB0RmD9NeLPrLFmzwp5 VMprkzO35h8qAr8gCbXmPpXfQo8ytiybidHgqVUkvohndSCx3sHpEMivYy63ycP00c8K GG7A== X-Gm-Message-State: AOAM530hAgf/f3bDaVbVEwXhn/W7Sbri7PA+y+3x4NlFt2zmsdyVMXUw dsstM6QIBsF4O+GNclVk1f8HY+JeGOXLKtE6KxI= X-Google-Smtp-Source: ABdhPJzmQCQso77KAr8trK/IAk4k8V1vdR0FUA8DvLLlsck8b2HgUVArYPTN0nyD9eJq4+5U3mnyX8vO6NjOJyYq0yY= X-Received: by 2002:ac2:558f:: with SMTP id v15mr579961lfg.187.1592532358706; Thu, 18 Jun 2020 19:05:58 -0700 (PDT) MIME-Version: 1.0 References: <5494.1592441770@localhost> In-Reply-To: <5494.1592441770@localhost> From: Spencer Dawkins at IETF Date: Thu, 18 Jun 2020 21:05:32 -0500 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000088bac305a86655ac" Archived-At: Subject: Re: [Cellar] Agenda items for our virtual meeting on 6-23 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, 19 Jun 2020 02:06:02 -0000 --00000000000088bac305a86655ac Content-Type: text/plain; charset="UTF-8" Hi, Michael, I've uploaded this at https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-06-cellar-01/ We'll talk next Tuesday! Best, Spencer On Wed, Jun 17, 2020 at 7:56 PM Michael Richardson wrote: > > Spencer Dawkins at IETF wrote: > > Our next virtual meeting is coming up next Tuesday. > > > If I didn't know any better, I'd suggest an agenda that looks this. > Is > > there anything on my list that we've already handled, or that we can > handle > > before the meeting? > > I haven't seen any reply from the rfc-editor about the missing AUTH48 > files! > > > Is there anything we need to include in the agenda? > > September in-person. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > --00000000000088bac305a86655ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0
=

We'll talk next Tuesday!

= Best,

Spencer
On Wed, Jun 17, 2020 at 7:56 = PM Michael Richardson <mcr@sandelman= .ca> wrote:

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > Our next virtual meeting is coming up next Tuesday.

=C2=A0 =C2=A0 > If I didn't know any better, I'd suggest an agen= da that looks this. Is
=C2=A0 =C2=A0 > there anything on my list that we've already handled= , or that we can handle
=C2=A0 =C2=A0 > before the meeting?

I haven't seen any reply from the rfc-editor about the missing AUTH48 f= iles!

=C2=A0 =C2=A0 > Is there anything we need to include in the agenda?

September in-person.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

--00000000000088bac305a86655ac-- From nobody Sun Jun 21 00:41: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 287573A0A0B for ; Sun, 21 Jun 2020 00:41:38 -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=ocQ430X4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qE5J6tfX 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 n1HqVD3zlgqp for ; Sun, 21 Jun 2020 00:41:36 -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 EE8B43A00B3 for ; Sun, 21 Jun 2020 00:41:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3868F5C008B for ; Sun, 21 Jun 2020 03:33:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 21 Jun 2020 03:33:00 -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=Z5yjqX/i06zQaZkgkhJQ+jUjGXK1mQNievR+mUGeTPE=; b=ocQ430X4 JorFr01556uBYo6f2VFU2+JvihrBshiKI7Qro6uFTW+yFg8rzvHcQPU2lAO8MK40 qd93E/JwBrGafEW/a13x8NJHYdmEJpmmbO5mSXkzzqo/V5K/ABEe9rgWB4z7GWA7 xByTwkS/yMTTTGgDZVaMZEgIELh387RqtGLpACFfo4dLa+dRdBoKOCC+drHwUEfM SaoZUBT9fOv4dZKouJT2lV6D9DfAenndXY2sAZJP3i0ZJsSSWqI39b04LIo4eRgW 8zcfLj9dkivWi0Tdf4S2bRQOERCH5+dRU2R4HQGPmkOCyHJ30ExIcXk/GrWNMGIw yB7U/26wtFgfyQ== 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=Z5yjqX/i06zQaZkgkhJQ+jUjGXK1m QNievR+mUGeTPE=; b=qE5J6tfXrODrSW4ummdgq0YaBWGpQGygRT0/c/Xy/i4n8 zBsqlUyAIQca6Z8YMomKUpKeOYod+6cpm3f4/UwP+jja4M75CtdrPaWtmxwGdjmn oRYPW9pUporbW51nEHJJqCYcL9/O0WNzGmFX2Y2UrDCmEs0WfFUYgl6sjWuYssyj usb0YcIdWnwTOUBSRbEcQRxfqmGQET26Wcs+11exP2O+nPmJVgSs/IRw90J9M/j2 thmcfcT88mUqc3y8MQu4DaZor8fZw4QeKPGdtWGuJA/7rU0j0ISe0uoSXVYPMddX ctWVsYmBUHlU0yo89fUERE2litUhT6QG0+2B5AwsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejledguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudegledrudehke drvddvheenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhm peguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az52.internal.cloudapp.net (unknown [52.149.158.225]) by mail.messagingengine.com (Postfix) with ESMTPA id F2D753280066 for ; Sun, 21 Jun 2020 03:32:59 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5193887851705001530==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200621073259.F2D753280066@mailuser.nyi.internal> Date: Sun, 21 Jun 2020 03:32:59 -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, 21 Jun 2020 07:41:38 -0000 --===============5193887851705001530== 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 (+2/-1/=F0=9F=92=AC2) 2 issues created: - Multiple WebVTT comment blocks (by mkver) https://github.com/cellar-wg/matroska-specification/issues/394=20 - Simplify the elements formatting (by robUx4) https://github.com/cellar-wg/matroska-specification/issues/393 [formatt= ing]=20 2 issues received 2 new comments: - #375 Add Support for Closed Captions to .MKV container (1 by MikeChenMM) https://github.com/cellar-wg/matroska-specification/issues/375 [codec m= apping]=20 - #373 Write down how extra data is saved for usage with AVC & HEVC (1 by= JeromeMartinez) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 1 issues closed: - Write down how extra data is saved for usage with AVC & HEVC https://gi= thub.com/cellar-wg/matroska-specification/issues/373 [codec mapping] [forma= t extension]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC2) 1 pull requests received 2 new comments: - #390 Add AVC and HEVC codec mappings with BlockAdditionMapping 2 (2 by = JeromeMartinez, dyspr0sium) https://github.com/cellar-wg/matroska-specification/pull/390 [codec map= ping] [spec_codecs]=20 1 pull requests merged: - Add AVC and HEVC codec mappings with BlockAdditionMapping 2 https://github.com/cellar-wg/matroska-specification/pull/390 [codec map= ping] [spec_codecs]=20 * cellar-wg/ebml-specification (+8/-13/=F0=9F=92=AC13) 8 pull requests submitted: - Use the 2003 correction of the ITU V42 CRC (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/356 [bug]=20 - fixed bullet-point text style (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/355 [clarification= s]=20 - Use the plural form of semantic when used as a noun (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/354 [bug] [clarifi= cations]=20 - Reword the DocTypeExtensionVersion support requirements (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/353 [clarification= s]=20 - Use consistent formatting for the id declarations (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/352 [formatting]=20 - fix typo (by retokromer) https://github.com/cellar-wg/ebml-specification/pull/351=20 - Apply the recursive punctuation change mentioned in AUTH48 12) (by robU= x4) https://github.com/cellar-wg/ebml-specification/pull/350 [clarification= s]=20 - Clean bool attributes text (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/349 [clarification= s]=20 7 pull requests received 13 new comments: - #356 Use the 2003 correction of the ITU V42 CRC (3 by dericed, robUx4) https://github.com/cellar-wg/ebml-specification/pull/356 [bug]=20 - #355 fixed bullet-point text style (1 by dericed) https://github.com/cellar-wg/ebml-specification/pull/355 [clarification= s]=20 - #351 fix typo (1 by retokromer) https://github.com/cellar-wg/ebml-specification/pull/351=20 - #347 Clarify the big-endian storage of the EBML ID (2 by dericed, robUx= 4) https://github.com/cellar-wg/ebml-specification/pull/347 [clarification= s]=20 - #346 Fix the GlobalParentOccurence spelling (3 by retokromer, robUx4) https://github.com/cellar-wg/ebml-specification/pull/346 [bug] [clarifi= cations]=20 - #342 turn "xsd" sourcecode tag into "xml" tag (1 by robUx4) https://github.com/cellar-wg/ebml-specification/pull/342 [bug] [formatt= ing]=20 - #340 Documentation definition fixes (2 by dericed, robUx4) https://github.com/cellar-wg/ebml-specification/pull/340 [bug]=20 13 pull requests merged: - Use the 2003 correction of the ITU V42 CRC https://github.com/cellar-wg/ebml-specification/pull/356 [bug]=20 - Clarify the big-endian storage of the EBML ID https://github.com/cellar-wg/ebml-specification/pull/347 [clarification= s]=20 - reword the EBMLSchema XML usage as suggested in AUTH48 https://github.com/cellar-wg/ebml-specification/pull/345 [clarification= s]=20 - Reword the DocTypeExtensionVersion support requirements https://github.com/cellar-wg/ebml-specification/pull/353 [clarification= s]=20 - rewrite introduction line as proposed during AUTH48 https://github.com/cellar-wg/ebml-specification/pull/343 [clarification= s]=20 - add some keywords to the document for easier searching in the RFCs https://github.com/cellar-wg/ebml-specification/pull/344 [build system]= =20 - Clean bool attributes text https://github.com/cellar-wg/ebml-specification/pull/349 [clarification= s]=20 - turn "xsd" sourcecode tag into "xml" tag https://github.com/cellar-wg/ebml-specification/pull/342 [bug] [formatt= ing]=20 - Use the plural form of semantic when used as a noun https://github.com/cellar-wg/ebml-specification/pull/354 [bug] [clarifi= cations]=20 - add missing for in the range description https://github.com/cellar-wg/ebml-specification/pull/348 [bug] [formatt= ing]=20 - Use consistent formatting for the id declarations https://github.com/cellar-wg/ebml-specification/pull/352 [formatting]=20 - Apply the recursive punctuation change mentioned in AUTH48 12) https://github.com/cellar-wg/ebml-specification/pull/350 [clarification= s]=20 - Fix the GlobalParentOccurence spelling https://github.com/cellar-wg/ebml-specification/pull/346 [bug] [clarifi= cations]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============5193887851705001530== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 21, 2020

Events without label "editorial"

Issues

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

2 issues created:

2 issues received 2 new comments:

1 issues closed:

Pull requests

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

1 pull requests received 2 new comments:

1 pull requests merged:

cellar-wg/ebml-specification (+8/-13/=F0=9F=92=AC13)

8 pull requests submitted:

7 pull requests received 13 new comments:

13 pull requests merged:

Repositories tracked by this digest:

--===============5193887851705001530==-- From nobody Tue Jun 23 12:12:53 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 DE6A43A07F7; Tue, 23 Jun 2020 12:12:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <159293956986.23437.659003564832844414@ietfa.amsl.com> Date: Tue, 23 Jun 2020 12:12:49 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt 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, 23 Jun 2020 19:12:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-15.txt Pages : 53 Date : 2020-06-23 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-15 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 23 12:13:01 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 0D26A3A094C; Tue, 23 Jun 2020 12:12:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <159293957001.23433.9125456838453855720@ietfa.amsl.com> Date: Tue, 23 Jun 2020 12:12:50 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-12.txt 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, 23 Jun 2020 19:12:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-12.txt Pages : 53 Date : 2020-06-23 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-12 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 23 12:26:14 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 8B6D83A0963 for ; Tue, 23 Jun 2020 12:26:07 -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 omXHQQ_u1Jkp for ; Tue, 23 Jun 2020 12:26:05 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 243643A0969 for ; Tue, 23 Jun 2020 12:26:05 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id i27so24723178ljb.12 for ; Tue, 23 Jun 2020 12:26:05 -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=8jQToiCwLubgnlWyRZAQ1U5OcJeL5NDffiAGLvt6mZI=; b=fVFORM24198qvjYJKU+QwUejC8+damrb2abpCZSnm9knq5Oy5/YjZHOhrb0XXmCO8W pXK7FYogfrBlwFy7OLrlsBDuscwYaaQo1vKuzDTpQjXpJZ5AVTfTiirwD+QMyGcWh8zZ W+X0dCdcfrkfTpPmPf4jfErQgrW1yidVfUIr3EaIpKzQtfLY/RTUpBYqCfWKJ07jZ/8z 9F/KsYc3cZ4Ff9SzadIrGcOdio71/fOskd0KRt7HsDBa+Y4FfvuLjsOK716FCixrgAVh pzUVW0tNopQ5gM4Du6Ea8IvSRjSU3ZDd5aLXc4YXPk3U3Ik5BQSsBE3zNkkWWo55oKKF Oi9w== 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=8jQToiCwLubgnlWyRZAQ1U5OcJeL5NDffiAGLvt6mZI=; b=FZhs3gDmaYUdgo7n5P7FEfaFGa9VqfnixCrR47gu69sHPVdo8kWmU9cy13tvRoZMUw oqw8hPr8qkTLJ8Xwt0hkmDDBF3wrYPg4EoJ4VuQf4Gk2lD5mcrhoNry94CsAS6rKms7q /gNVykmFT4Psx03CgRJnfa6WGrX+DeElM822gIIvIKeQOB8L88aAR2JvJtFmChhXisFr qsQ87/di83g/x5eg1f1RuydlXzizU+YNPuj5ohGaeaErpBFwSXqAvnC3JPZO8oFQMnWD HkcP+4LCUbLivWHp21qjHJH8QokpCIRnrjsS3Gr0Nao3blnJlz2L8NsOLyN8W1ZaqxFE P2Rw== X-Gm-Message-State: AOAM531ELBuPHkpYuzSOwZ4qOx/0Ci3f0UlbWA0BLETW67qrOW3Fzs7+ mKHeLv3sT8Bgo1ttNdUROwN7xeMRCgIajpOXouc= X-Google-Smtp-Source: ABdhPJxFH6pwLrtognqLEdCwAw7LYbP1JaLcrxdrwT/V/MUAmJO3yGizhaHWWoE+uQKNogeyUUaxFKZcf2O/ZK6jFlU= X-Received: by 2002:a2e:9786:: with SMTP id y6mr11422582lji.398.1592940363329; Tue, 23 Jun 2020 12:26:03 -0700 (PDT) MIME-Version: 1.0 References: <159293956986.23437.659003564832844414@ietfa.amsl.com> In-Reply-To: <159293956986.23437.659003564832844414@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 23 Jun 2020 14:25:37 -0500 Message-ID: To: Murray Kucherawy Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000081381305a8c554b0" Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 19:26:13 -0000 --00000000000081381305a8c554b0 Content-Type: text/plain; charset="UTF-8" Hi, Murray, We just confirmed during the Cellar virtual meeting that -15 IS actually ready for you to check and confirm that we've addressed the AD comments on this draft. Best, Spencer On Tue, Jun 23, 2020 at 2:12 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Codec Encoding for LossLess Archiving and > Realtime transmission WG of the IETF. > > Title : FFV1 Video Coding Format Version 0, 1, and 3 > Authors : Michael Niedermayer > Dave Rice > Jerome Martinez > Filename : draft-ietf-cellar-ffv1-15.txt > Pages : 53 > Date : 2020-06-23 > > Abstract: > This document defines FFV1, a lossless intra-frame video encoding > format. FFV1 is designed to efficiently compress video data in a > variety of pixel formats. Compared to uncompressed video, FFV1 > offers storage compression, frame fixity, and self-description, which > makes FFV1 useful as a preservation or intermediate video format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-cellar-ffv1-15 > https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-15 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --00000000000081381305a8c554b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Murray,=C2=A0

We just co= nfirmed during the Cellar virtual=C2=A0meeting that -15 IS actually ready f= or you to check and confirm that we've addressed the AD comments on thi= s draft.

Best,

Spencer
On = Tue, Jun 23, 2020 at 2:12 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Codec Encoding for LossLess Archiving and = Realtime transmission WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= FFV1 Video Coding Format Version 0, 1, and 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Niedermayer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dave Rice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jerome Martinez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cellar-ffv1-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 53
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-06-23

Abstract:
=C2=A0 =C2=A0This document defines FFV1, a lossless intra-frame video encod= ing
=C2=A0 =C2=A0format.=C2=A0 FFV1 is designed to efficiently compress video d= ata in a
=C2=A0 =C2=A0variety of pixel formats.=C2=A0 Compared to uncompressed video= , FFV1
=C2=A0 =C2=A0offers storage compression, frame fixity, and self-description= , which
=C2=A0 =C2=A0makes FFV1 useful as a preservation or intermediate video form= at.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= cellar-ffv1/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cellar-f= fv1-15
https://datatracker.ietf.org/doc/html= /draft-ietf-cellar-ffv1-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-cellar-ffv1-15


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000081381305a8c554b0-- From nobody Tue Jun 23 12:45:23 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 8A2A23A09C0; Tue, 23 Jun 2020 12:45:22 -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 xzTV6l5b6kWm; Tue, 23 Jun 2020 12:45:20 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 55A393A09BC; Tue, 23 Jun 2020 12:45:20 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id y11so24830056ljm.9; Tue, 23 Jun 2020 12:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=MqwxblVdEtxkKp7D38cMWjJcSisL88vfPEJ6ImKt21I=; b=CuHlkCO1EG4cqqHuSn+M3UnLxhjJ1k3EOEuTsqoTk1dfkjzycfbGS+/QrPPNEYpRev Gy2GzOieSIR7nPlqeXWedYkNEpw9paHYH5Uh3UQGACVnWQP4za7u2nO4QMYTtk+xg8L3 MK0XevJE6NSNb93pLCvn+2/onRO1ed16pz8UGBHH1aK/M7OueiHfcviQ76e6+O2Xg5gg NJANbjsqa/6548XFJxWaTYVb8GF55jWMYTSSVsdE/lYGXCQDo9DfEkMZvKwtUmvlRLjj Ed52fQmOE/UawjRlTv1MUePTyjbrc+Xu0KRPgecCO93hKec71kWr5EpjiGHWp1dIVvBw a8Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MqwxblVdEtxkKp7D38cMWjJcSisL88vfPEJ6ImKt21I=; b=TNYswDIGVe+9ONsc0lydZTEdPY8AeW9hDYiIGnPynprRsaQ0XFoTcw7M6d4coIApkv kYbVCuzM0L/O7n8w1rPBPmrT9S5VigAyND+nJCeBBKMdnqHDvwgzP0zG6X6O6bYaJzX6 9/8QFwj3W8QXMjZzQk/nSijOJw/UkWU2Z7CJk493NQRw6JW6hkpoFJ72QoI8iduZ7CK1 mterQnw6/E/0F9lUpCTZ0TJzG1AUrjDO5wvi8rGBrVj0mlrmd6dcG13gy/aecu/sbEnE ppeRVbq5PTI2UU3Q/BRh6dKvlqp+7HJyIdwriP3azYttwT3DIc/3WuXEgcxWbSBZ0SXL 6GzQ== X-Gm-Message-State: AOAM533Rhy9s+ZZ7tSnx/N/zewbmZmHBB4ZpfTaKa/U4BnrmKjVmWYLY uzr+zeBWLeneyezZejLfjWH6qjArPq7ZTyNtLiT1tNEG X-Google-Smtp-Source: ABdhPJxX8KPAaUJyydG3rASzD091HGDMw/3dsVSIIHXsq+bTeL6g5WkLqLuKK28qMo7zDSqA+TL4JHZPbpv4cw+mOgw= X-Received: by 2002:a2e:95d6:: with SMTP id y22mr12790096ljh.469.1592941518177; Tue, 23 Jun 2020 12:45:18 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Tue, 23 Jun 2020 14:44:52 -0500 Message-ID: To: IESG Secretary Cc: Murray Kucherawy , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000056ccb405a8c599e3" Archived-At: Subject: [Cellar] Cellar working group interim meeting will now be a virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 19:45:23 -0000 --00000000000056ccb405a8c599e3 Content-Type: text/plain; charset="UTF-8" Dear IESG Secretary, We had planned to hold the Cellar September meeting in-person in Amsterdam on 2020-09-22, but we have been overtaken by CoVid-19 events. This meeting was announced as in-person, in https://mailarchive.ietf.org/arch/msg/ietf-announce/SGNzRFW15U4dpymoEO3fzpPRUFE/ . Could you re-announce this as a virtual interim meeting? Best, Spencer and Michael --00000000000056ccb405a8c599e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear IESG Secretary,=C2=A0

We had plann= ed to hold the Cellar September meeting in-person in Amsterdam on=C2=A02020= -09-22, but we have been overtaken by CoVid-19 events.=C2=A0

=

Could you re-announce this as a virtual interim meeting?
<= br>
Best,

Spencer and Michael
--00000000000056ccb405a8c599e3-- From nobody Thu Jun 25 09:25:14 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 518673A0C81 for ; Thu, 25 Jun 2020 09:25:12 -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 szI21jamVk2W for ; Thu, 25 Jun 2020 09:25:10 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 643CC3A0C39 for ; Thu, 25 Jun 2020 09:25:10 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id k13so3867679vsm.13 for ; Thu, 25 Jun 2020 09:25:10 -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=3zEZJy2TR3R86wOZDnhA2k60rObsH63DvsNcpQuVuVU=; b=nIFXnSCWnP1ZzFP+e2PN7JpO5NLS1IHA7zhgdkj4YmLvTXLpEGAn34nK7uRpwbynty xDPcDtuEZMWFceGGM7VZ01ZEsE3Lr7ybwmF4p59np99OjZKgFC/MGTY/cKYQdLGkcwq2 K2xdSSF6tjDpqbaFY0yRxJlWwHCBhUYuSZW84twJMWX0dYeyGMtTjuTF9I7101ry0AfN RJ5uW6k2z6GvgjkJe36aXJZM5TXZjA3btDF45lQBuyZi7VVSDeOdvPcQQUHpli6mrq/R 1gfMwFs9vnVqsWgvVjvdj/1Lh98uUtwZ83axxyDeIMIKNwSyCc4jaSX1DL6hlOp4lNv0 89ig== 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=3zEZJy2TR3R86wOZDnhA2k60rObsH63DvsNcpQuVuVU=; b=Yo19Kls5byO9dL4V3HRDveGjsFdSUTtTAqpP3QRgq6h9cPvWHw7ZtzujL6C/366QOH xjbR74Tef6tXR9EBCJ6FlwBkn8CicZmmScFMSFmRvJIFVQdILJKZgb88MkabVVvkYSGp dOwV379HAeqaTqHSkfGmXS43AmIMZ/ihzgXBeQDfFdNsXVzD1KvJAIfBo9KBxF5KLN9b zRr936hqj8itzgqWE0395Cyd2ttRbPiNBA4+zEI7omMn2NGdwORduN+H8kbmGLXYSdEh SWrAzw1Wvf4u1IZgTsEylhYzpplw2jiC23pa9VxYse80ZoKm81I62jdP2P1rcP+1dSvM tmgA== X-Gm-Message-State: AOAM5329D9PWK0DUZ2dIP1nnZNQh51x7IFOCxGFgIG6CUoZ6BRquvi54 MXu25/5mXnNVpi8d2mXZ7Bicrf7f+N6Zr7bjBH0= X-Google-Smtp-Source: ABdhPJyvQJ4soE6u+iZyJP+VJRAXccpMhjqPdIFQS4QKonT5lw6aXCyg5XyWfJsQlc7Hs8Pe/+5GRNUrSI2edDa9re0= X-Received: by 2002:a67:7dcd:: with SMTP id y196mr28050749vsc.13.1593102309043; Thu, 25 Jun 2020 09:25:09 -0700 (PDT) MIME-Version: 1.0 References: <159293956986.23437.659003564832844414@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Thu, 25 Jun 2020 09:24:57 -0700 Message-ID: To: Spencer Dawkins at IETF Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000038b26f05a8eb0950" Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 16:25:12 -0000 --00000000000038b26f05a8eb0950 Content-Type: text/plain; charset="UTF-8" Hi, thanks for this. I'm looking now only at the diff between -13 (the last version I looked at) and this one. First and foremost, this is mostly better. Kudos for putting the work in. Hooray, most of those "type" columns are gone! But, alas, not all of them. They're still present in Sections 4.1 and below. I counted at least seven of them just in the diff I'm reviewing. As before, they should also be removed, or at least explained. A minor point: Prior to Section 3.8.2.3, it looks like all of the examples are in C. After that, they switch to pseudo code. Any reason we can't be consistent? I suggest that the prose below Table 8, which is a mix of pseudocode and English, would be better broken apart. Chairs: RFC 4732 is a downref; please make sure the shepherd calls this out in the writeup. There are a few code expressions that would benefit from being wrapped differently. For example: (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) : slice_pixel_height Maybe this? chroma_planes == 1 && (p == 1 || p == 2) ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) : slice_pixel_height -MSK On Tue, Jun 23, 2020 at 12:26 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Murray, > > We just confirmed during the Cellar virtual meeting that -15 IS actually > ready for you to check and confirm that we've addressed the AD comments on > this draft. > > Best, > > Spencer > > On Tue, Jun 23, 2020 at 2:12 PM wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Codec Encoding for LossLess Archiving >> and Realtime transmission WG of the IETF. >> >> Title : FFV1 Video Coding Format Version 0, 1, and 3 >> Authors : Michael Niedermayer >> Dave Rice >> Jerome Martinez >> Filename : draft-ietf-cellar-ffv1-15.txt >> Pages : 53 >> Date : 2020-06-23 >> >> Abstract: >> This document defines FFV1, a lossless intra-frame video encoding >> format. FFV1 is designed to efficiently compress video data in a >> variety of pixel formats. Compared to uncompressed video, FFV1 >> offers storage compression, frame fixity, and self-description, which >> makes FFV1 useful as a preservation or intermediate video format. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-cellar-ffv1-15 >> https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-15 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > --00000000000038b26f05a8eb0950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, thanks for this.=C2=A0 I'm looking now only at the diff betw= een -13 (the last version I looked at) and this one.

First and for= emost, this is mostly better.=C2=A0 Kudos for putting the work in.

Hooray, most of those "type" columns= are gone!=C2=A0 But, alas, not all of them.=C2=A0 They're still presen= t in Sections 4.1 and below.=C2=A0 I counted at least seven of them just in= the diff I'm reviewing.=C2=A0 As before, they should also be removed, = or at least explained.

A minor point: Prior to Section 3.8.2.3, it looks like al= l of the examples are in C.=C2=A0 After that, they switch to pseudo code.= =C2=A0 Any reason we can't be consistent?

I suggest that the prose below Tab= le 8, which is a mix of pseudocode and English, would be better broken apar= t.

Ch= airs: RFC 4732 is a downref; please make sure the shepherd calls this out i= n the writeup.

There are a few code expressions that would benefit from being wr= apped differently.=C2=A0 For example:

(chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2)) ? cei= l(slice_pixel_height
/ (1 << log2_v_chroma_subsample)) : slice_pix= el_height

Maybe this?

chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2)
=
=C2=A0 ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
=C2=A0 : slice_pixel_height

-MSK

On Tue, Jun 23, 2020 at 12:26 PM Spencer Dawkins a= t IETF <spencerdawkins.= ietf@gmail.com> wrote:
Hi, Murray,=C2=A0

<= div>We just confirmed during the Cellar virtual=C2=A0meeting that -15 IS ac= tually ready for you to check and confirm that we've addressed the AD c= omments on this draft.

Best,

<= div>Spencer

On Tue, Jun 23, 2020 at 2:12 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Codec Encoding for LossLess Archiving and = Realtime transmission WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= FFV1 Video Coding Format Version 0, 1, and 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Niedermayer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dave Rice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jerome Martinez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cellar-ffv1-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 53
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-06-23

Abstract:
=C2=A0 =C2=A0This document defines FFV1, a lossless intra-frame video encod= ing
=C2=A0 =C2=A0format.=C2=A0 FFV1 is designed to efficiently compress video d= ata in a
=C2=A0 =C2=A0variety of pixel formats.=C2=A0 Compared to uncompressed video= , FFV1
=C2=A0 =C2=A0offers storage compression, frame fixity, and self-description= , which
=C2=A0 =C2=A0makes FFV1 useful as a preservation or intermediate video form= at.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= cellar-ffv1/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cellar-f= fv1-15
https://datatracker.ietf.org/doc/html= /draft-ietf-cellar-ffv1-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-cellar-ffv1-15


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000038b26f05a8eb0950-- From nobody Thu Jun 25 09:43: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 07D713A0C51 for ; Thu, 25 Jun 2020 09:42:59 -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 6S6syHE__iaf for ; Thu, 25 Jun 2020 09:42:57 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 AE8E63A0C59 for ; Thu, 25 Jun 2020 09:42:56 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id 9so7243441ljc.8 for ; Thu, 25 Jun 2020 09:42:56 -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=JfVpV3jyhvksntnEB55C+NdlpR6bD0Wq38h/g849zjo=; b=LNcGYPGp9ZCjrclehkno/FdYjX+eYV/EWIpAvk4o83+f5WUxuh7C2o5QGcfbqidyyi 4WbVgJrUAK8j4pCpxWhEnypPiWua3cvEjGGe3qLEw6nGRPbHG6hJML1wv/EqU22z16oV 6xXnPv/oim+2xx4aCO2n3d9tlAu9agZw5RaojSeuQi+qeryoXVmGnjRtyMbHvegzzRlo 5SRDY+r59Owib+doyHHQPZBUuGHc+u7L7OHnAQIn5sWCDT+EX+jfBops48hhByE2CgQT z/hrT5G40JJVj6yGgoe8UNuQfCtOdSImlhhylETtnn6/EaRjX0TXhq/huqfY6IUuGGCn ceuA== 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=JfVpV3jyhvksntnEB55C+NdlpR6bD0Wq38h/g849zjo=; b=Mp8Bw8UAhlbI7tJ2Ypw2Xcb9a5dLz4j5vx2fzFcFm7lUNjQoDwzoJBqZWUsQsdxQSf A/SXUoaarHHgm4UaQR0/dw9wkSf40O888D36cFXeypvwraF8ntBhaLT2WJv5lGagIJv4 nfQXz6wXaAarMJSmU0fHzF/8yRDa/ntnv2NoqLDowEACoB0EfDRIyyertGpquCFz8CE6 YZMft4tPtRAnIfBFz3vKgjUXQ76EesHdiz9lhGpehFG00OoiesVwVBNTqNO3AYQ5TfRR +mDcGuPSGTDXFV+btIoU0ubQWltChtYPlpJM+3pVITE9xbzsth/OkSQuGe1U4QN+1guB +7Sw== X-Gm-Message-State: AOAM530/lSrbxFVYdF/n2NFxBx9NGkutWlABLsvChzZSVbRMN1UpvAeE uFJqH7ZqfOX336N5f+Ilu6S2JAWT8EPbcl4zp+Jiij2J X-Google-Smtp-Source: ABdhPJyRtHvZbD5rNfDZHis3paqrd4cfRi3SnkC1Id7I9GrA82VxyczbEdfAJkBwYn3v5KENvln6Tij4A506F9WAwlg= X-Received: by 2002:a2e:95d6:: with SMTP id y22mr18265903ljh.469.1593103374721; Thu, 25 Jun 2020 09:42:54 -0700 (PDT) MIME-Version: 1.0 References: <159293956986.23437.659003564832844414@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 25 Jun 2020 11:42:28 -0500 Message-ID: To: "Murray S. Kucherawy" Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000bda7db05a8eb48bc" Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 16:42:59 -0000 --000000000000bda7db05a8eb48bc Content-Type: text/plain; charset="UTF-8" Dear Cellar, On one point, On Thu, Jun 25, 2020 at 11:25 AM Murray S. Kucherawy wrote: > Hi, thanks for this. I'm looking now only at the diff between -13 (the > last version I looked at) and this one. > > First and foremost, this is mostly better. Kudos for putting the work in. > > Hooray, most of those "type" columns are gone! But, alas, not all of > them. They're still present in Sections 4.1 and below. I counted at least > seven of them just in the diff I'm reviewing. As before, they should also > be removed, or at least explained. > > A minor point: Prior to Section 3.8.2.3, it looks like all of the examples > are in C. After that, they switch to pseudo code. Any reason we can't be > consistent? > > I suggest that the prose below Table 8, which is a mix of pseudocode and > English, would be better broken apart. > > Chairs: RFC 4732 is a downref; please make sure the shepherd calls this > out in the writeup. > This means that RFC 4732 is not a standards-track document, while our draft is standards-track. That's fine, but we need to point that out when the document is sent for IETF Last Call, so the shepherd (or one of the working group chairs) should mention this in the "Other Points" section of https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/shepherdwriteup/. Best, Spencer > > > There are a few code expressions that would benefit from being wrapped > differently. For example: > > (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height > / (1 << log2_v_chroma_subsample)) : slice_pixel_height > > Maybe this? > > chroma_planes == 1 && (p == 1 || p == 2) > ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) > : slice_pixel_height > > -MSK > > On Tue, Jun 23, 2020 at 12:26 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, Murray, >> >> We just confirmed during the Cellar virtual meeting that -15 IS actually >> ready for you to check and confirm that we've addressed the AD comments on >> this draft. >> >> Best, >> >> Spencer >> >> On Tue, Jun 23, 2020 at 2:12 PM wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Codec Encoding for LossLess Archiving >>> and Realtime transmission WG of the IETF. >>> >>> Title : FFV1 Video Coding Format Version 0, 1, and 3 >>> Authors : Michael Niedermayer >>> Dave Rice >>> Jerome Martinez >>> Filename : draft-ietf-cellar-ffv1-15.txt >>> Pages : 53 >>> Date : 2020-06-23 >>> >>> Abstract: >>> This document defines FFV1, a lossless intra-frame video encoding >>> format. FFV1 is designed to efficiently compress video data in a >>> variety of pixel formats. Compared to uncompressed video, FFV1 >>> offers storage compression, frame fixity, and self-description, which >>> makes FFV1 useful as a preservation or intermediate video format. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-cellar-ffv1-15 >>> https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-15 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-15 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>> >> --000000000000bda7db05a8eb48bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Cellar,=C2=A0
=
On one point,=C2=A0

On Thu, Jun 25, 2020 at 11:25 AM Murray S= . Kucherawy <superuser@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Hi, thanks for this.=C2=A0 I'm looking now only at the diff betwe= en -13 (the last version I looked at) and this one.

First and fore= most, this is mostly better.=C2=A0 Kudos for putting the work in.

Hooray, most of those "type" columns = are gone!=C2=A0 But, alas, not all of them.=C2=A0 They're still present= in Sections 4.1 and below.=C2=A0 I counted at least seven of them just in = the diff I'm reviewing.=C2=A0 As before, they should also be removed, o= r at least explained.

A minor point: Prior to Section 3.8.2.3, it looks like al= l of the examples are in C.=C2=A0 After that, they switch to pseudo code.= =C2=A0 Any reason we can't be consistent?

I suggest that the prose below Tab= le 8, which is a mix of pseudocode and English, would be better broken apar= t.

Ch= airs: RFC 4732 is a downref; please make sure the shepherd calls this out i= n the writeup.


Best,

Spe= ncer
=C2=A0


There are a few code expressions that would benefit from being= wrapped differently.=C2=A0 For example:

(chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2)) ? = ceil(slice_pixel_height
/ (1 << log2_v_chroma_subsample)) : slice_= pixel_height

Maybe this?

chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2)
=C2=A0 ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))=
=C2=A0 : slice_pixel_height

-MSK

On Tue, Jun 23, 2020 at 12:26 PM Spencer Dawkins= at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Murray,=C2=A0

We just confirmed during the Cellar virtual=C2=A0me= eting that -15 IS actually ready for you to check and confirm that we'v= e addressed the AD comments on this draft.

Best,

Spencer

On Tue, Jun 23, 2020 at 2:12 PM <internet-drafts@ietf= .org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Codec Encoding for LossLess Archiving and = Realtime transmission WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= FFV1 Video Coding Format Version 0, 1, and 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael Niedermayer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Dave Rice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jerome Martinez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-cellar-ffv1-15.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 53
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-06-23

Abstract:
=C2=A0 =C2=A0This document defines FFV1, a lossless intra-frame video encod= ing
=C2=A0 =C2=A0format.=C2=A0 FFV1 is designed to efficiently compress video d= ata in a
=C2=A0 =C2=A0variety of pixel formats.=C2=A0 Compared to uncompressed video= , FFV1
=C2=A0 =C2=A0offers storage compression, frame fixity, and self-description= , which
=C2=A0 =C2=A0makes FFV1 useful as a preservation or intermediate video form= at.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= cellar-ffv1/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-cellar-f= fv1-15
https://datatracker.ietf.org/doc/html= /draft-ietf-cellar-ffv1-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-cellar-ffv1-15


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--000000000000bda7db05a8eb48bc-- From nobody Thu Jun 25 10:19: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 E138B3A0CF5 for ; Thu, 25 Jun 2020 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 szCQ0aT5hHNA for ; Thu, 25 Jun 2020 10:19:47 -0700 (PDT) Received: from 5.mo173.mail-out.ovh.net (5.mo173.mail-out.ovh.net [46.105.40.148]) (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 544A83A0DA1 for ; Thu, 25 Jun 2020 10:19:46 -0700 (PDT) Received: from player797.ha.ovh.net (unknown [10.108.35.210]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id E09E9144858 for ; Thu, 25 Jun 2020 19:19:44 +0200 (CEST) Received: from mediaarea.net (p548f9b22.dip0.t-ipconnect.de [84.143.155.34]) (Authenticated sender: jerome@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id 66439FB4491B; Thu, 25 Jun 2020 17:19:42 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G00186fd6e9e-dc37-4583-aac1-2b87e1793eb5, 0F666F60943D4F5378C79FE86E6D7543643A00EC) smtp.auth=jerome@mediaarea.net To: "Murray S. Kucherawy" Cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission References: <159293956986.23437.659003564832844414@ietfa.amsl.com> From: Jerome Martinez Message-ID: <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> Date: Thu, 25 Jun 2020 19:19:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1D2D3C3080D7B8D1073A3A7B" Content-Language: en-US X-Ovh-Tracer-Id: 15902210288158904465 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -51 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudekledgudduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepjefgtdetudetffffvdeuveeugffgkeekvddtveeuueeivefhleegleegteekvefhnecuffhomhgrihhnpehivghtfhdrohhrghdpihhtuhdrihhnthdpghhithhhuhgsrdhiohenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheehrdefgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleejrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 17:19:50 -0000 This is a multi-part message in MIME format. --------------1D2D3C3080D7B8D1073A3A7B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Murray, My answers inline: On 25/06/2020 18:24, Murray S. Kucherawy wrote: > Hi, thanks for this.  I'm looking now only at the diff between -13 > (the last version I looked at) and this one. > > First and foremost, this is mostly better.  Kudos for putting the work in. > > Hooray, most of those "type" columns are gone!  But, alas, not all of > them.  They're still present in Sections 4.1 and below. I counted at > least seven of them just in the diff I'm reviewing.  As before, they > should also be removed, or at least explained. > > A minor point: Prior to Section 3.8.2.3, it looks like all of the > examples are in C.  After that, they switch to pseudo code.  Any > reason we can't be consistent? The figures before section 4 are autonomous functions, used for describing a part of the algorithm and not used for directly reading out any symbol from the bitstream, so it was making sense to remove the "type" column at these places (this column was not used there). They could be more pseudocode nonetheless, as the C types ("int" etc) are not really relevant (they depends on the programming language). The figures in section 4 are for explaining the bitstream parsing order, and the "type" column is used for indicating the kind of value it is (types are described in https://tools.ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see that it is called "Symbol" here, we'll change "Symbol" to "Type" in this table). This kind of method for describing a video bitstream is very classic, for example in: - H.264, see the full spec (PDF to download) https://www.itu.int/rec/T-REC-H.264-201906-I/en - AV1, see an online direct example at https://aomediacodec.github.io/av1-spec/#frame-obu-syntax As in theses specs, we have some figures without usage of the "type" column because they are intermediate figures (the "type" column is used in the figures using this figure and the figures called by this figure), split from another figure, in order to have the spec more readable (focusing on a specific topic). AV1 uses it for example at https://aomediacodec.github.io/av1-spec/#decode-tile-syntax > > I suggest that the prose below Table 8, which is a mix of pseudocode > and English, would be better broken apart. We'll try to find a better wording for this line. > > Chairs: RFC 4732 is a downref; please make sure the shepherd calls > this out in the writeup. (Removing my question as Spencer answered my question before I send it :-p ) > > There are a few code expressions that would benefit from being wrapped > differently.  For example: > > (chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height > / (1 << log2_v_chroma_subsample)) : slice_pixel_height > > Maybe this? > > chroma_planes == 1 && (p == 1 || p == 2) >   ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) >   : slice_pixel_height It is on a full line in the specification source code, I see that the raw text version and the HTML version have different automatic line break position, we'll force some line breaks. Jérôme --------------1D2D3C3080D7B8D1073A3A7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Murray,

My answers inline:

On 25/06/2020 18:24, Murray S. Kucherawy wrote:
Hi, thanks for this.  I'm looking now only at the diff between -13 (the last version I looked at) and this one.

First and foremost, this is mostly better.  Kudos for putting the work in.

Hooray, most of those "type" columns are gone!  But, alas, not all of them.  They're still present in Sections 4.1 and below.  I counted at least seven of them just in the diff I'm reviewing.  As before, they should also be removed, or at least explained.

A minor point: Prior to Section 3.8.2.3, it looks like all of the examples are in C.  After that, they switch to pseudo code.  Any reason we can't be consistent?

The figures before section 4 are autonomous functions, used for describing a part of the algorithm and not used for directly reading out any symbol from the bitstream, so it was making sense to remove the "type" column at these places (this column was not used there). They could be more pseudocode nonetheless, as the C types ("int" etc) are not really relevant (they depends on the programming language).

The figures in section 4 are for explaining the bitstream parsing order, and the "type" column is used for indicating the kind of value it is (types are described in https://tools.ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see that it is called "Symbol" here, we'll change "Symbol" to "Type" in this table).
This kind of method for describing a video bitstream is very classic, for example in:
- H.264, see the full spec (PDF to download) https://www.itu.int/rec/T-REC-H.264-201906-I/en
- AV1, see an online direct example at https://aomediacodec.github.io/av1-spec/#frame-obu-syntax

As in theses specs, we have some figures without usage of the "type" column because they are intermediate figures (the "type" column is used in the figures using this figure and the figures called by this figure), split from another figure, in order to have the spec more readable (focusing on a specific topic). AV1 uses it for example at https://aomediacodec.github.io/av1-spec/#decode-tile-syntax



I suggest that the prose below Table 8, which is a mix of pseudocode and English, would be better broken apart.

We'll try to find a better wording for this line.



Chairs: RFC 4732 is a downref; please make sure the shepherd calls this out in the writeup.

(Removing my question as Spencer answered my question before I send it :-p )



There are a few code expressions that would benefit from being wrapped differently.  For example:

(chroma_planes == 1 && (p == 1 || p == 2)) ? ceil(slice_pixel_height
/ (1 << log2_v_chroma_subsample)) : slice_pixel_height

Maybe this?

chroma_planes == 1 && (p == 1 || p == 2)
  ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample))
  : slice_pixel_height


It is on a full line in the specification source code, I see that the raw text version and the HTML version have different automatic line break position, we'll force some line breaks.

Jérôme

--------------1D2D3C3080D7B8D1073A3A7B-- From nobody Thu Jun 25 10:32:02 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 26F343A0DFC for ; Thu, 25 Jun 2020 10:32:01 -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 tUawveKk8mu3 for ; Thu, 25 Jun 2020 10:31:59 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 3DA353A0DFA for ; Thu, 25 Jun 2020 10:31:59 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id r5so3990964vso.11 for ; Thu, 25 Jun 2020 10:31: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=Chun0cPwBVPxCN5TCLb9nMbiq787khBuSF9AzmR+lm4=; b=DMumqYm1AGme3kdPVM/KMXoXNaCoVnmISngKzVs8P2hYFJWuibnDPS9DJKA3mwHFX2 UHuRL+lkPhbzU+Psm4TzpdKNpn9xK5XzdglmbtUGmR929/xYIKkwLnfPESAaMFSyc8OP RCWUq7POoLiOdf7l4c4Y4xM+zCDKL/X+Ag7+Y7n0NHtvoWk9lgYtV4Mle+oeXFsbYnYy G5aCWaQQVI98jnrmu3Ke2f5MsVD21khm7O3puTLImveHTQCXUQHgo6e8s7Q2nIMtJ/KM 7IpoQ6Y9kR7/Jo3oRmuVJt8Vgxw8x5bUoZO4F4bJ5odtEkuorsvmTnmMjY5AXM/YT6Yy kLYQ== 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=Chun0cPwBVPxCN5TCLb9nMbiq787khBuSF9AzmR+lm4=; b=LWG5sxVTm7mCVaBE5AOpOnGhhzGLRN2Z1OfIh+Xz3/n7p5PAgrR8spoYJNjIr8FnUL YRSnlgXJX8TEGU+d2lyVJv9PFpxT0M1JMFrN3dVNSEH0i3jb4Vdw7yeafjkVqC5PeAJO ID9dexYnHYJWeyR4+z4oiKyJCmmHy6WqFp43nj6uy58E4ZFIKfLCGddAGvvql9p9lXlX yuCyTCc4mKIDeVCxEhiG+oqqIzQsCJQIPH/e9KfsRr4EseNaq6253yC/GZ24VAPaYJsn PwxDpk31XeIXsDeSZXyQxbT2FlvHjxbgECCgKuTQwaUSKHbdxRETv7dWwViZJrIoC4xo x64A== X-Gm-Message-State: AOAM532ntckU+8OwdN0ZDFF3fCC7K26+zA+//YuIPIVi/89tFUB8ovV6 7bU08fuPGbKf6Jd4PE66LD8j9vVPwDh+/Ds+ny4= X-Google-Smtp-Source: ABdhPJxRJRy3u2vuVtw2dEYTAU07/mfqYFj4GtGDk39YKg050IyqHqDbqe924tUv8N6jsbEVlci2249kzow+MCZ9/Ek= X-Received: by 2002:a67:7dcd:: with SMTP id y196mr28321757vsc.13.1593106317862; Thu, 25 Jun 2020 10:31:57 -0700 (PDT) MIME-Version: 1.0 References: <159293956986.23437.659003564832844414@ietfa.amsl.com> <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> In-Reply-To: <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> From: "Murray S. Kucherawy" Date: Thu, 25 Jun 2020 10:31:46 -0700 Message-ID: To: Jerome Martinez Cc: Spencer Dawkins at IETF , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000002a6d8005a8ebf818" Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 17:32:01 -0000 --0000000000002a6d8005a8ebf818 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 25, 2020 at 10:19 AM Jerome Martinez wrote: > On 25/06/2020 18:24, Murray S. Kucherawy wrote: > > Hooray, most of those "type" columns are gone! But, alas, not all of > them. They're still present in Sections 4.1 and below. I counted at least > seven of them just in the diff I'm reviewing. As before, they should also > be removed, or at least explained. > > A minor point: Prior to Section 3.8.2.3, it looks like all of the examples > are in C. After that, they switch to pseudo code. Any reason we can't be > consistent? > > The figures before section 4 are autonomous functions, used for describing > a part of the algorithm and not used for directly reading out any symbol > from the bitstream, so it was making sense to remove the "type" column at > these places (this column was not used there). They could be more > pseudocode nonetheless, as the C types ("int" etc) are not really relevant > (they depends on the programming language). > > The figures in section 4 are for explaining the bitstream parsing order, > and the "type" column is used for indicating the kind of value it is (types > are described in > https://tools.ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see > that it is called "Symbol" here, we'll change "Symbol" to "Type" in this > table). > This kind of method for describing a video bitstream is very classic, for > example in: > - H.264, see the full spec (PDF to download) > https://www.itu.int/rec/T-REC-H.264-201906-I/en > - AV1, see an online direct example at > https://aomediacodec.github.io/av1-spec/#frame-obu-syntax > > As in theses specs, we have some figures without usage of the "type" > column because they are intermediate figures (the "type" column is used in > the figures using this figure and the figures called by this figure), split > from another figure, in order to have the spec more readable (focusing on a > specific topic). AV1 uses it for example at > https://aomediacodec.github.io/av1-spec/#decode-tile-syntax > Your previous AD and I were both confused by the format and what it's trying to convey. I appreciate that it might be classic in some realms, but as neither of us had seen it, I imagine others on the IESG who don't work in our layers (i.e., most of them) will also ask about it. If you want to leave them in, I suggest including either some text about how to interpret them, or a reference to such guidance elsewhere. -MSK --0000000000002a6d8005a8ebf818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 25, 2020 at 10:19 AM Jerome M= artinez <jerome@mediaarea.net> wrote:
=20 =20 =20
On 25/06/2020 18:24, Murray S. Kucherawy wrote:
=20
Hooray, most of those "type" columns are gone!=C2=A0 But, ala= s, not all of them.=C2=A0 They're still present in Sections 4.1 and be= low.=C2=A0 I counted at least seven of them just in the diff I'm reviewing.=C2=A0 As before, they should also be removed, or at least explained.

= A minor point: Prior to Section 3.8.2.3, it looks like all of the examples are in C.=C2=A0 After that, they switch to pseudo code.=C2=A0 Any reason we can't be consistent?

The figures before section 4 are autonomous functions, used for describing a part of the algorithm and not used for directly reading out any symbol from the bitstream, so it was making sense to remove the "type" column at these places (this column wa= s not used there). They could be more pseudocode nonetheless, as the C types ("int" etc) are not really relevant (they depends on = the programming language).

The figures in section 4 are for explaining the bitstream parsing order, and the "type" column is used for indicating the kin= d of value it is (types are described in https://tools= .ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see that it is called "Symbol" here, we'll change &= quot;Symbol" to "Type" in this table).
This kind of method for describing a video bitstream is very classic, for example in:
- H.264, see the full spec (PDF to download) https://www.itu.int/r= ec/T-REC-H.264-201906-I/en
- AV1, see an online direct example at https://aomediaco= dec.github.io/av1-spec/#frame-obu-syntax

As in theses specs, we have some figures without usage of the "type" column because they are intermediate figures (the &q= uot;type" column is used in the figures using this figure and the figures called by this figure), split from another figure, in order to have the spec more readable (focusing on a specific topic). AV1 uses it for example at https://aomediacodec.github.io/= av1-spec/#decode-tile-syntax


= Your previous AD and I were both confused by the format and what it's t= rying to convey.=C2=A0 I appreciate that it might be classic in some realms= , but as neither of us had seen it, I imagine others on the IESG who don= 9;t work in our layers (i.e., most of them) will also ask about it.=C2=A0 I= f you want to leave them in, I suggest including either some text about how= to interpret them, or a reference to such guidance elsewhere.
-MSK

--0000000000002a6d8005a8ebf818-- From nobody Thu Jun 25 10:34: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 3C24E3A0DD4 for ; Thu, 25 Jun 2020 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCc81IaiJozu for ; Thu, 25 Jun 2020 10:34:48 -0700 (PDT) Received: from server172-5.web-hosting.com (server172-5.web-hosting.com [68.65.122.113]) (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 E58FA3A0DE8 for ; Thu, 25 Jun 2020 10:34:48 -0700 (PDT) Received: from cpe-69-203-78-204.nyc.res.rr.com ([69.203.78.204]:49546 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 1joVlr-003ClM-IJ; Thu, 25 Jun 2020 13:34:48 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Dave Rice In-Reply-To: <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> Date: Thu, 25 Jun 2020 13:34:41 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <159293956986.23437.659003564832844414@ietfa.amsl.com> <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> To: "Murray S. Kucherawy" , Jerome Martinez X-Mailer: Apple Mail (2.3608.80.23.2.2) X-OutGoing-Spam-Status: No, score=-1.0 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] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 17:34:54 -0000 Hi Murray, > On Jun 25, 2020, at 1:19 PM, Jerome Martinez = wrote: >=20 > Hi Murray, >=20 > My answers inline: >=20 > On 25/06/2020 18:24, Murray S. Kucherawy wrote: >> Hi, thanks for this. I'm looking now only at the diff between -13 = (the last version I looked at) and this one. >>=20 >> First and foremost, this is mostly better. Kudos for putting the = work in. >>=20 >> Hooray, most of those "type" columns are gone! But, alas, not all of = them. They're still present in Sections 4.1 and below. I counted at = least seven of them just in the diff I'm reviewing. As before, they = should also be removed, or at least explained. >>=20 >> A minor point: Prior to Section 3.8.2.3, it looks like all of the = examples are in C. After that, they switch to pseudo code. Any reason = we can't be consistent? > The figures before section 4 are autonomous functions, used for = describing a part of the algorithm and not used for directly reading out = any symbol from the bitstream, so it was making sense to remove the = "type" column at these places (this column was not used there). They = could be more pseudocode nonetheless, as the C types ("int" etc) are not = really relevant (they depends on the programming language). >=20 > The figures in section 4 are for explaining the bitstream parsing = order, and the "type" column is used for indicating the kind of value it = is (types are described in = https://tools.ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I see = that it is called "Symbol" here, we'll change "Symbol" to "Type" in this = table). > This kind of method for describing a video bitstream is very classic, = for example in: > - H.264, see the full spec (PDF to download) = https://www.itu.int/rec/T-REC-H.264-201906-I/en > - AV1, see an online direct example at = https://aomediacodec.github.io/av1-spec/#frame-obu-syntax >=20 > As in theses specs, we have some figures without usage of the "type" = column because they are intermediate figures (the "type" column is used = in the figures using this figure and the figures called by this figure), = split from another figure, in order to have the spec more readable = (focusing on a specific topic). AV1 uses it for example at = https://aomediacodec.github.io/av1-spec/#decode-tile-syntax >=20 >> I suggest that the prose below Table 8, which is a mix of pseudocode = and English, would be better broken apart. > We'll try to find a better wording for this line. >=20 >> Chairs: RFC 4732 is a downref; please make sure the shepherd calls = this out in the writeup. > (Removing my question as Spencer answered my question before I send it = :-p ) >=20 >> There are a few code expressions that would benefit from being = wrapped differently. For example: >>=20 >> (chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2)) ? = ceil(slice_pixel_height >> / (1 << log2_v_chroma_subsample)) : slice_pixel_height >>=20 >> Maybe this? >>=20 >> chroma_planes =3D=3D 1 && (p =3D=3D 1 || p =3D=3D 2) >> ? ceil(slice_pixel_height / (1 << log2_v_chroma_subsample)) >> : slice_pixel_height > It is on a full line in the specification source code, I see that the = raw text version and the HTML version have different automatic line = break position, we'll force some line breaks. I add line-breaks to this equation and a related one as you suggested in = this commit = https://github.com/FFmpeg/FFV1/pull/215/commits/1a4f83fb05591a1cfb4ef19768= 2d06212ecf0b56. I also reviewed other equations and moved many to code = blocks and manually set the line-wrapping. This work is to be reviewed = in the pull request at https://github.com/FFmpeg/FFV1/pull/215. Best Regards, Dave Rice From nobody Thu Jun 25 11:02:23 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 EB7003A0E4F; Thu, 25 Jun 2020 11:02:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159310813783.15906.6392274376486485829@ietfa.amsl.com> Date: Thu, 25 Jun 2020 11:02:17 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-09-22 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, 25 Jun 2020 18:02:18 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2020-09-22 from 19:00 to 20:00 UTC. Agenda: TBD Information about remote participation: https://whereby.com/cellar-interim From nobody Thu Jun 25 11:20:43 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 46B283A0ECE; Thu, 25 Jun 2020 11:20:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159310922773.9438.1231569445237493684@ietfa.amsl.com> Date: Thu, 25 Jun 2020 11:20:28 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Interim Meeting Cancelled (was 2020-09-22) 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, 25 Jun 2020 18:20:42 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) interim meeting for 2020-09-22 from 09:00 to 10:00 Europe/Amsterdam has been cancelled. From nobody Thu Jun 25 11:57: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 B6F4B3A0FE1 for ; Thu, 25 Jun 2020 11:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XPZf5FBsl7gt for ; Thu, 25 Jun 2020 11:57:25 -0700 (PDT) Received: from server172-5.web-hosting.com (server172-5.web-hosting.com [68.65.122.113]) (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 DDED23A0FDF for ; Thu, 25 Jun 2020 11:57:25 -0700 (PDT) Received: from cpe-69-203-78-204.nyc.res.rr.com ([69.203.78.204]:50115 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 1joX3n-004H4W-ON; Thu, 25 Jun 2020 14:57:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Dave Rice In-Reply-To: Date: Thu, 25 Jun 2020 14:57:17 -0400 Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <062D9003-0466-4E12-B42E-2E88E3726A3E@dericed.com> References: <159293956986.23437.659003564832844414@ietfa.amsl.com> <5eb696ba-3db5-aed1-80b8-bc92d604a721@mediaarea.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.3608.80.23.2.2) 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] I-D Action: draft-ietf-cellar-ffv1-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 18:57:28 -0000 > On Jun 25, 2020, at 1:31 PM, Murray S. Kucherawy = wrote: >=20 > On Thu, Jun 25, 2020 at 10:19 AM Jerome Martinez = wrote: > On 25/06/2020 18:24, Murray S. Kucherawy wrote: >> Hooray, most of those "type" columns are gone! But, alas, not all of = them. They're still present in Sections 4.1 and below. I counted at = least seven of them just in the diff I'm reviewing. As before, they = should also be removed, or at least explained. >>=20 >> A minor point: Prior to Section 3.8.2.3, it looks like all of the = examples are in C. After that, they switch to pseudo code. Any reason = we can't be consistent? > The figures before section 4 are autonomous functions, used for = describing a part of the algorithm and not used for directly reading out = any symbol from the bitstream, so it was making sense to remove the = "type" column at these places (this column was not used there). They = could be more pseudocode nonetheless, as the C types ("int" etc) are not = really relevant (they depends on the programming language). >=20 > The figures in section 4 are for explaining the bitstream parsing = order, and the "type" column is used for indicating the kind of value it = is (types are described in = https://tools..ietf.org/id/draft-ietf-cellar-ffv1-15.html#table-4 , I = see that it is called "Symbol" here, we'll change "Symbol" to "Type" in = this table). > This kind of method for describing a video bitstream is very classic, = for example in: > - H.264, see the full spec (PDF to download) = https://www.itu.int/rec/T-REC-H.264-201906-I/en > - AV1, see an online direct example at = https://aomediacodec.github.io/av1-spec/#frame-obu-syntax >=20 > As in theses specs, we have some figures without usage of the "type" = column because they are intermediate figures (the "type" column is used = in the figures using this figure and the figures called by this figure), = split from another figure, in order to have the spec more readable = (focusing on a specific topic). AV1 uses it for example at = https://aomediacodec.github.io/av1-spec/#decode-tile-syntax >=20 >=20 > Your previous AD and I were both confused by the format and what it's = trying to convey. I appreciate that it might be classic in some realms, = but as neither of us had seen it, I imagine others on the IESG who don't = work in our layers (i.e., most of them) will also ask about it. If you = want to leave them in, I suggest including either some text about how to = interpret them, or a reference to such guidance elsewhere. As a draft to try to address this, I added this paragraph and figure to = Section 2.2.1 which describes the use of pseudo-code within the = document: > In some instances, pseudo-code is presented in a two-column format > such as shown in Figure 1. In this form the "type" column provides = a > symbol as defined in Table 4 that defines the storage of the data > referenced in that same line of pseudo-code. >=20 > pseudo-code | = type > = --------------------------------------------------------------|----- > ExamplePseudoCode( ) { | > value | ur > } | >=20 > Figure 1: A depiction of type-labelled pseduo-code used within > this document. This proposed change is at = https://github.com/FFmpeg/FFV1/pull/217/files, comments/suggestions = welcome. Note that Section 4.8 of = https://aomediacodec.github.io/av1-spec/#method-of-describing-bitstream-sy= ntax uses a similar description for its own pseudo-code. Dave From nobody Sun Jun 28 00:41:27 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 8AF783A0BDE for ; Sun, 28 Jun 2020 00:41:25 -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=P/1BnoUU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vul3o/tW 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 5pt95naJnciT for ; Sun, 28 Jun 2020 00:41:23 -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 C0B193A0BED for ; Sun, 28 Jun 2020 00:41:23 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 446CE5C0090 for ; Sun, 28 Jun 2020 03:32:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 28 Jun 2020 03:32:40 -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=y4iOiXKEkYgQnfbG0O4JKZUxBOn/dvBuzIMOQ3MTax4=; b=P/1BnoUU tfPlBh+GZYLZtCwQ5E2ve+zslYaq7ANWhUTliuy+xdgxMD5wDJdBHQy5h1slxhVK CrKk7om59aIrjskhn1zwqv9iq88VyLhMVXUth9OVD4TG1An05+GsneT0/rk+kSTZ jOLSmowlFC7LiLZBAdl7eHXm9/ul0UnUfqio40Ev09t6PPKV0pTOpngn368C/DTe 7Cnq9qj9aUuQKQ0oQyX/CcrQI5hCP7P6fpi8xidQ8HFOyNHt1+SKFolkyc2a5YJF WqbK05and0zajGRnhDz9Oewl0ee8EWBksfr+FXfHJ8fjt4EbVPFaDGW0SX/kjUG+ 2gy0YNgWkuWwYg== 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=y4iOiXKEkYgQnfbG0O4JKZUxBOn/d vBuzIMOQ3MTax4=; b=Vul3o/tWhUEN/+IneC/p+KGpn54evv4kO5IuK8zDBsIqH mtJBD5a1C9TQgNt6kD7XI8688PyqqH26zOzcf/RFqG2pOrjI6qagVFHgXAcTiaLp y1tXB5afxeXLJUCkagNrUc5wSq1S3a+uH4aJr6AoljAiW5cTORFTyCRO+xM5CZm3 OYYHWHu+t+QB5J8biMpB2ENMJQgNuOOJC5uaXxd/iVyeXnLGk2ClgBa4lU4xrxx5 LWNJb1dN2Eb2gj/EyZIZANPQk4OtEiHxVbWkgfFNGF/aGHdISqmUOetOorY+TpH8 Aj6uBYt/1bDOFilf+G7/0u3XK66IJetqkED/r5MPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudelhedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheegrdefrddvvd eknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59.internal.cloudapp.net (unknown [52.254.3.228]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EEA23067AE1 for ; Sun, 28 Jun 2020 03:32:40 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3881155789925567881==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200628073240.0EEA23067AE1@mailuser.nyi.internal> Date: Sun, 28 Jun 2020 03:32:40 -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, 28 Jun 2020 07:41:27 -0000 --===============3881155789925567881== 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=AC1) 1 issues received 1 new comments: - #375 Add Support for Closed Captions to .MKV container (1 by sbshepherd) https://github.com/cellar-wg/matroska-specification/issues/375 [codec m= apping]=20 Pull requests ------------- * cellar-wg/ebml-specification (+4/-0/=F0=9F=92=AC0) 4 pull requests submitted: - replace the custom Matroska reference to one found by xml2rfc (by robUx= 4) https://github.com/cellar-wg/ebml-specification/pull/360 [formatting]=20 - Build rfc8794.xml from the markdown (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/359 [build system]= =20 - add the first version of the rfc8794 XML source (by robUx4) https://github.com/cellar-wg/ebml-specification/pull/358 [formatting]=20 - mark RFC2119 keywords with **<>** to mmark turns them into BCP14 code (= by robUx4) https://github.com/cellar-wg/ebml-specification/pull/357 [formatting]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============3881155789925567881== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday June 28, 2020

Events without label "editorial"

Issues

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

1 issues received 1 new comments:

Pull requests

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

4 pull requests submitted:

Repositories tracked by this digest:

--===============3881155789925567881==-- From nobody Tue Jun 30 07:27: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 472593A096C for ; Tue, 30 Jun 2020 07:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.102 X-Spam-Level: *** X-Spam-Status: No, score=3.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvKrMRDUR0T0 for ; Tue, 30 Jun 2020 07:27:44 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 1768D3A096B for ; Tue, 30 Jun 2020 07:27:43 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id z13so20422421wrw.5 for ; Tue, 30 Jun 2020 07:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=yU/gOFBDS5vBxFoRau/nFefl4Sj3y5q/tEgywGiQ7wU=; b=W+OhGV0ljBYeNW7AMI5x29l/zkJcCO1jpwunGJ9Y+F3rIvZr7/d5pUXHpYhZdYdKL7 Ke6w1RmkAxV/+m32giRinyjk3VcI88mBeye9kYvBET0Qw6i0EiJyJyeOFZl9vRH+NOcF MbKeGKn8SFTbxP06rhnVJ//qMIS8ctefuHpI4xJBkm+pLquL36pWxMA1OVKp/j5oqnWF iQ3uFDTNOByardOORBbIsbRcLeq4PAQ379zk2f3OKGq/qrdx09FxmwBty0JYu3z9ovDh sA/z1hznop4A9FdYKb9neJ7qdvl2uacpA3bTw8ju+1a4mdqEjMb+ktOTKzty8vSMAlTG 2y0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=yU/gOFBDS5vBxFoRau/nFefl4Sj3y5q/tEgywGiQ7wU=; b=G3CKsPLrGBMW72P61KwWI5BrgIyinAt4iij09wnqzrYVFvBIRdQGTyPjfOnwBb6/JL DJuTG5sd5uz5IUe3wutKpWGJdbsdFoFArjc9OR+paxNqT9Qoem4/pq9kTFyR8kNHHjek s2V0gEWGD2uc61xdgyKbxuhGiBNIEsNmo7wYXcqmY5CMAe2e6oE8bJYaDhV5OzSSdaAY 1Ms344zSv3lgtKiFUer4W8/JcIF66QxohFF47DTGeHZPiMOjliHBazzFJmasBEYKHyQ5 s9I05YclmGAH67SsRB5ZmNSVDi5FV3f/LQb7B2L8zRRj8wHREeCP3CxTdRPXvfXbOUe+ VlKw== X-Gm-Message-State: AOAM5329Z/WeN9DhjVJGPBzUOuw8k6HSp6vJuV5HLBxa494eBgo9V8EE yzsF3+FoYTqfUBHE4hp0WQdz3teJOz7Smw== X-Google-Smtp-Source: ABdhPJy8V3aS6ffO2zIXvnF0uDcbVN7gniiXA7eE6OBAJT/eboE7wYGTjmeYvw+AcDEoj/cuk3NlPQ== X-Received: by 2002:adf:e684:: with SMTP id r4mr22200890wrm.68.1593527262147; Tue, 30 Jun 2020 07:27:42 -0700 (PDT) Received: from [192.168.3.13] (85-168-154-201.rev.numericable.fr. [85.168.154.201]) by smtp.gmail.com with ESMTPSA id 12sm3642537wmg.6.2020.06.30.07.27.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 07:27:41 -0700 (PDT) To: Codec Encoding for LossLess Archiving and Realtime transmission From: Steve Lhomme Message-ID: <9c2428b6-e0c8-b165-842c-14b7ea19f22f@matroska.org> Date: Tue, 30 Jun 2020 16:27:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] EBML AUTH48 updates 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, 30 Jun 2020 14:27:45 -0000 Hi, Following the AUTH48 XML document being available, I updated our "source" to more or less match what they produce. At least we'll be on the same page. I submitted 12 PRs on github. Not all of them can be merged at the same time as they kinda depend on each other. But it's easier to review separately. The sum of all the PRs' can be found in a branch [1] that produces an XML file we could submit. So in the same format they gave us, not the bare format we get from mmarkdown. Please review the PRs and approve (or comment) them so we can move forward and submit the updated XML file. Their file has some issues and inconsitencies that are fixed in our file. [1] https://github.com/cellar-wg/ebml-specification/tree/comparable