From nobody Sun May 3 00:38:57 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 918E53A16BF for ; Sun, 3 May 2020 00:38:48 -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=hXteYcG9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rYcp+nK7 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 FfsEqYxUbd1G for ; Sun, 3 May 2020 00:38:46 -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 6ED733A16C0 for ; Sun, 3 May 2020 00:38:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CD4F15C02F2 for ; Sun, 3 May 2020 03:32:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 03 May 2020 03:32:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=1D+e7SnsBRnNyWrREfq6+1WlXScbzd4QpbFRpk4EtJI=; b=hXteYcG9 xLuTYayIPfhOtOIjYfyn0Pca8O9nxCgMNgyQU50vlUwVvrTEe8GZO+SzsuUqWZJd 6fkROJQ/kssqrzDA4MRtl/XYhyHl/qkx+IC37Zl3m2Cgea2G2eYXwcQkP+dq4Ep6 /Lz8dmzyUbzAnCWD/Wy+YRdjc0u4PQcrPUrDzLAH108i9nZkCFQBJSlP0hJsA981 OOcCD9TBfKLWBg1qcw+hSEUSjmWlXMVYzwpOZfnxPAqgHeISICU0R63SgNYXJ/Zv Oj+tv7WTlSvznffa2NnEIQ9TZQpjQa5qKDXaDKfl5NHEAYCTgB18gPd8KlVpd5Ey QVp68t4sPasviQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=1D+e7SnsBRnNyWrREfq6+1WlXScbz d4QpbFRpk4EtJI=; b=rYcp+nK7SzovxzFqyn0qWgZy3Mw1Sx477zEq5y7cl0rrX KhlGPXs06m4y7CYd2LckPPMIlBpPGQMEfigxm4qgfUjQ9X+/ncuXGer2spdF4lUm S6HzqlNLTSBRVIN24I9OUV8zi4+FxeyZCAnAolJDQ3AlSPxSEdQJKgz0lh3CpF2d XTtfbrzbwKhod+h2/YmPfvhyBzggCyNSbm1BOjk6TZ+x5kivBr4MLtQaWmj+avQu xLI25SzxRAFSv4fQvpjowcjSUO/s2E4OjppgHznDXKbs227OiB1hR7UuxmrbjYCS lbHDL+u8nPMov628zDbCivzdQvyZIaRDDqsHaoAyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjedugddvudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudejjedrudejrddvge dvnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az59.internal.cloudapp.net (unknown [52.177.17.242]) by mail.messagingengine.com (Postfix) with ESMTPA id 869AF3280066 for ; Sun, 3 May 2020 03:32:27 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8819785479774818068==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200503073227.869AF3280066@mailuser.nyi.internal> Date: Sun, 3 May 2020 03:32:27 -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, 03 May 2020 07:38:54 -0000 --===============8819785479774818068== 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 (+4/-0/=F0=9F=92=AC16) 4 issues created: - deprecate LZO compression (by robUx4) https://github.com/cellar-wg/matroska-specification/issues/376 [clarifi= cations] [enhancement] [spec_main]=20 - Add Support for Closed Captions to .MKV container (by sbshepherd) https://github.com/cellar-wg/matroska-specification/issues/375=20 - clarify use of forced flag (by mcr) https://github.com/cellar-wg/matroska-specification/issues/374=20 - Allow for Dolby Vision Data to be saved within the mkv format (by steff= enmanden) https://github.com/cellar-wg/matroska-specification/issues/373=20 3 issues received 16 new comments: - #376 deprecate LZO compression (2 by retokromer, robUx4) https://github.com/cellar-wg/matroska-specification/issues/376 [clarifi= cations] [enhancement] [spec_main]=20 - #375 Add Support for Closed Captions to .MKV container (1 by JeromeMart= inez) https://github.com/cellar-wg/matroska-specification/issues/375=20 - #373 Allow for Dolby Vision Data to be saved within the mkv format (13 = by JeromeMartinez, Klaus1189, MikeChenMM, mbunkus, mcr, steffenmanden) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC4) 2 pull requests received 4 new comments: - #318 add a ChapterContentType to mark chapters with a type of content (= 2 by mcr) https://github.com/cellar-wg/matroska-specification/pull/318 [enhanceme= nt] [format addition] [new_document] [spec_main] [webm] [wontfix]=20 - #112 add T_QUICKTIME codec mapping (2 by JeromeMartinez, dericed) https://github.com/cellar-wg/matroska-specification/pull/112 [codec map= ping] [new_document] [spec_codecs]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============8819785479774818068== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 03, 2020

Events without label "editorial"

Issues

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

4 issues created:

3 issues received 16 new comments:

Pull requests

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

2 pull requests received 4 new comments:

Repositories tracked by this digest:

--===============8819785479774818068==-- From nobody Sun May 3 09:10:33 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 EAD483A0ECC for ; Sun, 3 May 2020 09:10:31 -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 iSUBHQUb1MrZ for ; Sun, 3 May 2020 09:10:29 -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 687D43A0ECE for ; Sun, 3 May 2020 09:10:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6238E3897B for ; Sun, 3 May 2020 12:08:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 10789135 for ; Sun, 3 May 2020 12:10:27 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376)) 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, 03 May 2020 16:10:32 -0000 --=-=-= Content-Type: text/plain Hi, I wanted to bring this item to the list's attention. Spencer: I seem to remember that the IETF has had compression IPR issues in specifications in the past. IPCOMP comes to mind, but I am guessing that other RTP/SIP groups have gone through this.. Is there possibly an IESG statement that might help us here? But, first, the software license on the libraries is not entirely germane. An IETF specification can well contain algorithms which are currently only available in software licensed in ways that might not be useable by all implementers. Someone just will have to write a new library with a license that suits them! What matters if that the specification (and any related patents!) is available to all. The IETF's minimum IPR requirement is generally RAND, which is often not good enough for open source, which requires RF. The decision as to which IPR claims to tolerate is a WG-level decision, with the proviso that the WG (and IETF) is informed about the issue. So even in the absense of the jackoalan and zivillian LZO implementations, the WG should be free to standardize LZO, if it the IPR claims on the algorithm itself are well understood. {In the compression space, my understanding is that there have been formats where there were no IPR claims on decompressors, but there was significant IPR-encumbered innovation on doing compression. An encoder might need a specific license in order to get 70% compression rather than just 40%, but this had no affect on the decoder. But, I don't recall the specific situations where this occured. Maybe back in the old ZOO/ARC/ZIP days...} Steve Lhomme wrote: > Matroska Blocks can be compressed with zlib, bz2 and lzo compression. > zlib and bz2 have decompression libraries available under permisssive > licenses (BSD like for bz2 and OSI approved, GPL compatible, non > copyleft for zlib). > lzo doesn't have such a permissive library. The [official > library](https://www.oberhumer.com/opensource/lzo/) is GPLv2, there is > also decompression code that doesn't rely on this library [in > FFmpeg](https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/lzo.c) > which is LGPLv2 which means grabbing the whole libavutil to compile. > This license is not permissive enough to be used in many closed source > products where they don't want to touch any GPL-based license. That > means a file that is created with LZO in a GPL/LGPL software may not be > read universally because of licensing issues. I think we should avoid > it and mark LZO as deprecated. > The LZO compression advantage over others is that it is [very fast to > compress/decompress](https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO). But > the compression ratio is not good. That is good for realtime > transmission but bad for long term storage. In the end automatic tools > that test each compression (like mkclean) will never pick it anyway. ... > I found 2 other options with better licenses: > - a [C++ version in MIT license](https://github.com/jackoalan/lzokay) with compression > - a [C# version in MIT license](https://github.com/zivillian/lzo.net) without decompression > They are both based on the [Linux Kernel documentation for > LZO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/lzo.txt). > In libmatroska2 I've been using minilzo GPLv2 but I may try to port one > of these in C so I can use it (or simply write a C wrapper around the > C++ one). That means there would be an alternative that is MIT license, > so freely used by anyone. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6u7PIACgkQgItw+93Q 3WXSLwf+LhGsCKZX6oedVtRI5RRZiUH0+R7ZFa9Sw99d003CzQEMXQq53+hXgKc+ i2j1fbLQ0wDEJuZw5pMzp9assvQtYUZ7Aa1K+YNOrOJabnPqy848a+nbfDcnBiAZ xDGlQO2ilOEYKaiflysOpsRvH2q401L5JMdbtb+jqtuFAeLWgvIBgC3RsfWCO/WJ vuHSl1+k5fJ82e9PvGPNYubzAis+V4AuPvDTUIYPKb45T3tlyhR709qZKUwI5tfP +Tow4+/e3GUFz1uoETPw0sIHJ/KFff2Owkq1/6vgpgRUcboPQ4HenJSTO6DtuAgI vxBXK65p0QFOPAaf0xcWUl2OCxOc2w== =TDpV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 5 05:13:41 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 5C01D3A165C for ; Tue, 5 May 2020 05:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKM8RSya3b9W for ; Tue, 5 May 2020 05:13:37 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 648323A164C for ; Tue, 5 May 2020 05:13:37 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id s30so1690564qth.2 for ; Tue, 05 May 2020 05:13:37 -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=+9lv1sMg11f6rH2I1tORoOtVZzEizuKF/T3mI12MZSQ=; b=sJn+cZFTqqioPiYfKqtP9rCsXMfJAlDoE/tnwDudxo9QhNu88BK4rS2MhDEZKMNeBV S8eQ3tVVwIWRgs4SQ42gEz5aIZ7Z8QiRWpjw5ZQ3VQKbYYT4tI2lA6Y3fYseByHrsOvF O+Mmxzr3KrLLfoYKjblu21aYmJfbEJ7Q3ABkYZ7dGPoNeaq97Qulx6N/2t7kztv/ufZJ xZWTglPmFcPWRbh7Uxt4fW9Kr48QXER6EnIeOBPVQVQpD/PohPgZZS2yV3itfXWmW+Gi nDwTBzhCXFGFJ43FWUldoL9DvpV/YBJ/uFQ2GMOsQrAkzvG4GwdfUkDbkiAhadDwziZw N9ww== 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=+9lv1sMg11f6rH2I1tORoOtVZzEizuKF/T3mI12MZSQ=; b=bF36pZ3l+3KsjzZhXTMhFetZlCEuN2pZh98XuWfptGS280UNxWXm62FKbZ8L0uzP9J e8cT8j5h5e/kxubsN3GxJVlXn3C2ZPIqQ+wFTGNkWcehT03p3vS26GGxuBnYi4CHeZtG pw7qzuPtu7groBIR1zuFTFvP4CmMrv32JqbWJYkVHtfLwqO0Yn+w2uO/7QnmzF2A+XED xgF5PzDZWtMe1casPcQ3X4q+Ut9tj9yE3OgKoVSqalkgZR4Qgtv3aT2hEL7tfjYE0Ive UEh14PQoY3XBizxqR4S1sEYEC1NJTl4z9vxTXRDRe0oud7OZauaotrU8w9o4uydfEzaz +99A== X-Gm-Message-State: AGi0Pubxq6XKv3jTFx1xbnhobtxt0fwcEIwfKBYQlllAbWozcJitaAa9 VfxoNw85yv0QGeoJANK3Fd8ZHr7Q2tSdnU+Ykw== X-Google-Smtp-Source: APiQypIyMYNIbvkAG7CPyuGLSkPhkX/eaIG4iQsMSEpNQ8ch38lth2U4j5IVXPZSEG/4SFZhe1ZblbSSTxWd9H1ckaY= X-Received: by 2002:aed:208c:: with SMTP id 12mr2240622qtb.152.1588680816511; Tue, 05 May 2020 05:13:36 -0700 (PDT) MIME-Version: 1.0 References: <353D4CFD-370C-4509-B7BE-3D572EC2DEFB@dericed.com> In-Reply-To: From: Kieran O Leary Date: Tue, 5 May 2020 13:13:27 +0100 Message-ID: To: Steve Lhomme , Neil Birkbeck Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="000000000000bace4105a4e593b8" Archived-At: Subject: Re: [Cellar] Mapping of MOV clean aperture values to Matroska 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, 05 May 2020 12:13:40 -0000 --000000000000bace4105a4e593b8 Content-Type: text/plain; charset="UTF-8" Hi all, I'm not sure if Neil is subscribed to this listserv, but if not - here's the rest of this thread: https://mailarchive.ietf.org/arch/browse/cellar/?q=clean%20aperture Just to flag that Neil Birkbeck is working on adding support to ffmpeg that will: map clap values from mov to mov using side data, as well as also mapping clap values to PixelCrop values within Matroska. Here's the thread: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261465.html Here's my testing - my mail settings are weird at the moment so I broke the threading on ffmpeg-devel which is embarrassing - here's my reply: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262155.html And seeing as the source mov file as created by Media Express has clap width values of 41472/59 , this was rounded up to an even 8 pixelcrop on each side of the image in the MAtroska file, creating a display output of 704/576. Whereas the source mov file would have been displayed as 703/576. I think that Neil is going to fix this, but I'm wondering if there's some restriction within PixelCrop so that only even values can be used? This reply by Neil showed the rounding issue: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261592.html Best, Kieran. On Mon, Dec 3, 2018 at 7:50 AM Steve Lhomme wrote: > > >> In Matroska we assume that we override what the codec says. > > >> But I don't think that's how it's handled in ffmpeg. Also there's the > > >> question of what these values apply to: on the decoded surface, which > > >> may include padding on the right/bottom or the area that's supposed to > > >> be visible. In Matroska the "PixelWidth/PixelHeight" correspond to the > > >> visible area, on which we apply extra cropping. (this is currently not > > >> written anywhere). > > >> > > >> As for the MOV atom, is there are spec somewhere ? Or is it clear that > > >> it's some cropping ? > > > > > > > > > I think this is as good of a spec that is freely available - the 'clap > section' > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-125850 > > > > OK, so we should support it in VLC (which we don't) and that seems to > > map more or less to Matroska values. > > I see you submitted a feature request already, excellent > https://trac.videolan.org/vlc/ticket/21179 > --000000000000bace4105a4e593b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm not sure if Neil is sub= scribed=C2=A0to this listserv, but if not - here's the rest of this thr= ead:=C2=A0https://mailarchive.ietf.org/arch/browse/cellar/?q=3Dclean= %20aperture=C2=A0
Just to flag that Neil Birkbeck is working = on adding support to ffmpeg that will:
map clap values from mov t= o mov using side data, as well as also mapping clap values to PixelCrop val= ues within Matroska.
Here= 9;s my testing - my mail settings are weird at the moment=C2=A0 so I broke = the threading=C2=A0on ffmpeg-devel which is embarrassing=C2=A0- here's = my reply:=C2=A0http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262155.html= =C2=A0
And seeing as the source mov file as = created by Media Express has clap width=C2=A0values=C2=A0of=C2=A041472/59 , this was rounded up = to an even 8 pixelcrop on each side of the image in the MAtroska file, crea= ting a display output of 704/576. Whereas the source mov file would have be= en displayed as 703/576. I think that Neil is going to fix this, but I'= m wondering if there's some restriction within PixelCrop so that only e= ven values can be used?
This reply by Neil showed the rounding issue: <= a href=3D"http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261592.html">= http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261592.html

Best,

Kieran.



On Mon, Dec 3, 2018 at 7:50 AM Steve Lhomme <slhomme@matroska.org> wrote:
=
> >> In Matroska= we assume that we override what the codec says.
> >> But I don't think that's how it's handled in ffmp= eg. Also there's the
> >> question of what these values apply to: on the decoded surfac= e, which
> >> may include padding on the right/bottom or the area that'= s supposed to
> >> be visible. In Matroska the "PixelWidth/PixelHeight"= ; correspond to the
> >> visible area, on which we apply extra cropping. (this is curr= ently not
> >> written anywhere).
> >>
> >> As for the MOV atom, is there are spec somewhere ? Or is it c= lear that
> >> it's some cropping ?
> >
> >
> > I think this is as good of a spec that is freely available - the = 'clap section' https://develop= er.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap3/qtff3.h= tml#//apple_ref/doc/uid/TP40000939-CH205-125850
>
> OK, so we should support it in VLC (which we don't) and that seems= to
> map more or less to Matroska values.

I see you submitted a feature request already, excellent
https://trac.videolan.org/vlc/ticket/21179
--000000000000bace4105a4e593b8-- From nobody Tue May 5 13:43: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 3B7B93A0A64 for ; Tue, 5 May 2020 13:43:49 -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 Ab4sHSAZcCPq for ; Tue, 5 May 2020 13:43:46 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 6FB4B3A0A65 for ; Tue, 5 May 2020 13:43:46 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id 188so2503450lfa.10 for ; Tue, 05 May 2020 13:43:46 -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=VkENzJPazxnlSzPxtFKZ15ZSMnGdD9+Z0G3bn/pylmo=; b=u+vWPO/w0O6R/wWCI4CWApAzsB9+SJgMuAKtQlXKYsDFiArCUQXgfEwtlP3yeF3C5+ OKXuy5/AOT+Cf9poTP4D8sfdb4AYIMdHQDY8oQZn7KQ2wKu7rwd4rEO9bOf4N2puuq9C pxz1eaxwrUzDxneYckFP9TPIY0kYzlgb+4uzJhFrRhXB0pdIzuwwjJtPi3G04B3Nt0bY ZTLtNSgLsBF5iS7NMbcNaIkWfB02tlqQL2IiRrUAOO5hNa849tWBgGeqC7gfxsG5cPQB iomgx6D8LOOMXPOHMzns5Q131F3bVTB7PZ86pfO9W7rhxeAewavZ1K+6AtLO+iMFgj4t 6KZw== 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=VkENzJPazxnlSzPxtFKZ15ZSMnGdD9+Z0G3bn/pylmo=; b=uL+PKLSVNBMEAk0u7lkX8Wt2srkNrlL9mgyAHYdMA8augZ2baKaym9sTvUH90sc4z7 A6WKWGzrD8bAB9Z+AKs54TVzdroP4QPdWZt1gRdYzBFegV7enkv3xN07RbeQvS43GMcl +04lmekapyfsS/ItYP7yJacg9GLTRKQe7eKRoGZIM88izRDsdOCprw8VTkhjq6Gc65bg y38jKCmxH9cYmvKxVWxIJON4X2mVa5dHb1zAph+GIVe9lewEfjsG5b10k4MNynCYolR1 u21jZ0dPaBnozk+ByEBnwerDce6JEvaTmLxVxNS70Xzc6pcnhkHXESRNuKwIQ5NKHGPM 6+ZA== X-Gm-Message-State: AGi0PubdqvSUMwf9kbF6SdUND91MKqOH+hgc7fTlNVl8RiVSomPtoPaB Yn3oUM9B2iG2VMn44c2O6ATxIAocBZyc24zT+PZWEzQQcDM= X-Google-Smtp-Source: APiQypLvcHzrdEQVdsvORWek+IsCWXgtvU05EpvmvmTYb8GUbOGTfiH5sWDHhlEoEafkpZdJc4cmrD25r5CFBAwUeTs= X-Received: by 2002:a19:f70f:: with SMTP id z15mr2791412lfe.53.1588711424698; Tue, 05 May 2020 13:43:44 -0700 (PDT) MIME-Version: 1.0 References: <24830.1588522227@localhost> In-Reply-To: <24830.1588522227@localhost> From: Spencer Dawkins at IETF Date: Tue, 5 May 2020 15:43:17 -0500 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000001eb07c05a4ecb498" Archived-At: Subject: Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376)) 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, 05 May 2020 20:43:49 -0000 --0000000000001eb07c05a4ecb498 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Sun, May 3, 2020 at 11:10 AM Michael Richardson wrote: > > Hi, I wanted to bring this item to the list's attention. > > Spencer: I seem to remember that the IETF has had compression IPR issues in > specifications in the past. IPCOMP comes to mind, but I am guessing that > other RTP/SIP groups have gone through this.. I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think you're remembering SIGCOMP. The complete list of disclosures that mention "compression" is at https://datatracker.ietf.org/ipr/search/?draft=&rfc=&doctitle=compression&submit=doctitle&group=&holder=&iprtitle=&patent= > Is there possibly an IESG > statement that might help us here? > I believe the only relevant IESG statement on licensing for repositories is to make it clear that they need to include standard boilerplate ( https://www.ietf.org/about/groups/iesg/statements/open-source-repositories-license/ ). > > But, first, the software license on the libraries is not entirely germane. > An IETF specification can well contain algorithms which are currently only > available in software licensed in ways that might not be useable by all > implementers. > Someone just will have to write a new library with a license that suits > them! > > What matters if that the specification (and any related patents!) is > available to all. The IETF's minimum IPR requirement is generally RAND, > which is often not good enough for open source, which requires RF. > The decision as to which IPR claims to tolerate is a WG-level decision, > with > the proviso that the WG (and IETF) is informed about the issue. > > So even in the absense of the jackoalan and zivillian LZO implementations, > the WG should be free to standardize LZO, if it the IPR claims on the > algorithm itself are well understood. > This is exactly right. The IESG cares that the working group made the decision to request publication on a document without being "submarined" by undisclosed patents or patients with vague or confusing licensing provisions. If we have our eyes open, we'll be fine. > {In the compression space, my understanding is that there have been formats > where there were no IPR claims on decompressors, but there was significant > IPR-encumbered innovation on doing compression. An encoder might need a > specific license in order to get 70% compression rather than just 40%, but > this had no affect on the decoder. But, I don't recall the specific > situations where this occured. Maybe back in the old ZOO/ARC/ZIP days...} > I have the same vague memories (perhaps I'm remembering that licensing was different, rather than decompressors hat no known IPR, but that's pretty close). I hope this helps! Spencer > Steve Lhomme wrote: > > Matroska Blocks can be compressed with zlib, bz2 and lzo compression. > > > zlib and bz2 have decompression libraries available under permisssive > > licenses (BSD like for bz2 and OSI approved, GPL compatible, non > > copyleft for zlib). > > > lzo doesn't have such a permissive library. The [official > > library](https://www.oberhumer.com/opensource/lzo/) is GPLv2, there > is > > also decompression code that doesn't rely on this library [in > > FFmpeg](https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/lzo.c > ) > > which is LGPLv2 which means grabbing the whole libavutil to compile. > > > This license is not permissive enough to be used in many closed > source > > products where they don't want to touch any GPL-based license. That > > means a file that is created with LZO in a GPL/LGPL software may not > be > > read universally because of licensing issues. I think we should avoid > > it and mark LZO as deprecated. > > > The LZO compression advantage over others is that it is [very fast to > > compress/decompress]( > https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO). > But > > the compression ratio is not good. That is good for realtime > > transmission but bad for long term storage. In the end automatic > tools > > that test each compression (like mkclean) will never pick it anyway. > > .... > > I found 2 other options with better licenses: > > > - a [C++ version in MIT license](https://github.com/jackoalan/lzokay) > with compression > > - a [C# version in MIT license](https://github.com/zivillian/lzo.net) > without decompression > > > They are both based on the [Linux Kernel documentation for > > LZO]( > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/lzo.txt > ). > > > In libmatroska2 I've been using minilzo GPLv2 but I may try to port > one > > of these in C so I can use it (or simply write a C wrapper around the > > C++ one). That means there would be an alternative that is MIT > license, > > so freely used by anyone. > --0000000000001eb07c05a4ecb498 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Sun, May 3, 2020 at = 11:10 AM Michael Richardson <mcr@san= delman.ca> wrote:

Hi, I wanted to bring this item to the list's attention.

Spencer: I seem to remember that the IETF has had compression IPR issues in=
specifications in the past.=C2=A0 IPCOMP comes to mind, but I am guessing t= hat
other RTP/SIP groups have gone through this..

<= div>I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think yo= u're remembering SIGCOMP.=C2=A0

=C2=A0
Is there possibly an IESG
statement that might help us here?

I be= lieve the only relevant IESG statement on licensing for repositories is to = make it clear that they need to include standard boilerplate (https://www.ietf.org/about/groups/iesg/statements/open-source-repos= itories-license/).

But, first, the software license on the libraries is not entirely germane.<= br> An IETF specification can well contain algorithms which are currently only<= br> available in software licensed in ways that might not be useable by all
implementers.
Someone just will have to write a new library with a license that suits the= m!

What matters if that the specification (and any related patents!) is
available to all.=C2=A0 The IETF's minimum IPR requirement is generally= RAND,
which is often not good enough for open source, which requires RF.
The decision as to which IPR claims to tolerate is a WG-level decision, wit= h
the proviso that the WG (and IETF) is informed about the issue.

So even in the absense of the jackoalan and zivillian LZO implementations,<= br> the WG should be free to standardize LZO, if it the IPR claims on the
algorithm itself are well understood.

T= his is exactly right. The IESG cares that the working group made the decisi= on to request publication on a document without being "submarined"= ; by undisclosed patents or patients with vague or confusing licensing prov= isions. If we have our eyes open, we'll be fine.=C2=A0
=C2=A0=
{In the compression= space, my understanding is that there have been formats
where there were no IPR claims on decompressors, but there was significant<= br> IPR-encumbered innovation on doing compression.=C2=A0 An encoder might need= a
specific license in order to get 70% compression rather than just 40%, but<= br> this had no affect on the decoder.=C2=A0 But, I don't recall the specif= ic
situations where this occured.=C2=A0 Maybe back in the old ZOO/ARC/ZIP days= ...}

I have the same vague memories (pe= rhaps I'm remembering that licensing was different, rather than decompr= essors hat no known IPR, but that's pretty close).=C2=A0

=
I hope this helps!

Spencer
= =C2=A0
Steve Lhomme = <notificat= ions@github.com> wrote:
=C2=A0 =C2=A0 > Matroska Blocks can be compressed with zlib, bz2 and lzo= compression.

=C2=A0 =C2=A0 > zlib and bz2 have decompression libraries available unde= r permisssive
=C2=A0 =C2=A0 > licenses (BSD like for bz2 and OSI approved, GPL compati= ble, non
=C2=A0 =C2=A0 > copyleft for zlib).

=C2=A0 =C2=A0 > lzo doesn't have such a permissive library. The [off= icial
=C2=A0 =C2=A0 > library](https://www.oberhumer.com/opens= ource/lzo/) is GPLv2, there is
=C2=A0 =C2=A0 > also decompression code that doesn't rely on this li= brary [in
=C2=A0 =C2=A0 > FFmpeg](https://githu= b.com/FFmpeg/FFmpeg/blob/master/libavutil/lzo.c)
=C2=A0 =C2=A0 > which is LGPLv2 which means grabbing the whole libavutil= to compile.

=C2=A0 =C2=A0 > This license is not permissive enough to be used in many= closed source
=C2=A0 =C2=A0 > products where they don't want to touch any GPL-base= d license. That
=C2=A0 =C2=A0 > means a file that is created with LZO in a GPL/LGPL soft= ware may not be
=C2=A0 =C2=A0 > read universally because of licensing issues. I think we= should avoid
=C2=A0 =C2=A0 > it and mark LZO as deprecated.

=C2=A0 =C2=A0 > The LZO compression advantage over others is that it is = [very fast to
=C2=A0 =C2=A0 > compress/decompress](https://catchchallenger.first-w= orld.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZO). But
=C2=A0 =C2=A0 > the compression ratio is not good. That is good for real= time
=C2=A0 =C2=A0 > transmission but bad for long term storage. In the end a= utomatic tools
=C2=A0 =C2=A0 > that test each compression (like mkclean) will never pic= k it anyway.

....
=C2=A0 =C2=A0 > I found 2 other options with better licenses:

=C2=A0 =C2=A0 > - a [C++ version in MIT license](https://githu= b.com/jackoalan/lzokay) with compression
=C2=A0 =C2=A0 > - a [C# version in MIT license](https://githu= b.com/zivillian/lzo.net) without decompression

=C2=A0 =C2=A0 > They are both based on the [Linux Kernel documentation f= or
=C2=A0 =C2=A0 > LZO](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/tree/Documentation/lzo.txt).

=C2=A0 =C2=A0 > In libmatroska2 I've been using minilzo GPLv2 but I = may try to port one
=C2=A0 =C2=A0 > of these in C so I can use it (or simply write a C wrapp= er around the
=C2=A0 =C2=A0 > C++ one). That means there would be an alternative that = is MIT license,
=C2=A0 =C2=A0 > so freely used by anyone.
--0000000000001eb07c05a4ecb498-- From nobody Tue May 5 14:18:49 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 BDE2D3A0B7C for ; Tue, 5 May 2020 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 lCRHABJhL2Id for ; Tue, 5 May 2020 14:18:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B0A5C3A0B7E for ; Tue, 5 May 2020 14:18:44 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 045LIZoE018011 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 5 May 2020 16:18:41 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1588713522; bh=rhCXXeqe7YVOegRNn1pecLUXI7Zt29N28jPmG24vcaY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=viKCO3rt8QsoVP9PgAp9n2q2qSjzlf+F4Fu/uLznNSX9CLHLFTKh+LCOAm4EhY2Y+ cb44XVRJfoDIcaZ0lyUQaerjofp8V3J3lb42jsjM+FbsQnCMqlMvBBy41ozVvxMYTu ZfheNfczXqgIoUcdDYr6Jy2fAEVlFh/Zc6Cl9PaI= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Spencer Dawkins at IETF , Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission References: <24830.1588522227@localhost> From: Adam Roach Message-ID: Date: Tue, 5 May 2020 16:18:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BCA0953A48E15FC4C5C99C5A" Content-Language: en-US Archived-At: Subject: Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376)) 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, 05 May 2020 21:18:48 -0000 This is a multi-part message in MIME format. --------------BCA0953A48E15FC4C5C99C5A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/5/2020 3:43 PM, Spencer Dawkins at IETF wrote: > Hi, Michael, > > On Sun, May 3, 2020 at 11:10 AM Michael Richardson > wrote: > > > Hi, I wanted to bring this item to the list's attention. > > Spencer: I seem to remember that the IETF has had compression IPR > issues in > specifications in the past.  IPCOMP comes to mind, but I am > guessing that > other RTP/SIP groups have gone through this.. > > > I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think > you're remembering SIGCOMP. Probably not: SIGCOMP sidestepped this specific issue altogether by normatively specifying precisely zero compression algorithms. It instead defined a virtual machine that message recipients would implement, and to which message senders would send bytecodes sufficient to decode subsequent messages. /a --------------BCA0953A48E15FC4C5C99C5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/5/2020 3:43 PM, Spencer Dawkins at IETF wrote:
Hi, Michael, 

On Sun, May 3, 2020 at 11:10 AM Michael Richardson <mcr@sandelman.ca> wrote:

Hi, I wanted to bring this item to the list's attention.

Spencer: I seem to remember that the IETF has had compression IPR issues in
specifications in the past.  IPCOMP comes to mind, but I am guessing that
other RTP/SIP groups have gone through this..

I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think you're remembering SIGCOMP. 


Probably not: SIGCOMP sidestepped this specific issue altogether by normatively specifying precisely zero compression algorithms. It instead defined a virtual machine that message recipients would implement, and to which message senders would send bytecodes sufficient to decode subsequent messages.

/a

--------------BCA0953A48E15FC4C5C99C5A-- From nobody Sun May 10 00:41:04 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 31D793A07C3 for ; Sun, 10 May 2020 00:41: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, 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=KKBMe0d9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PFmgxXPa 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 PkI-g8kiU84W for ; Sun, 10 May 2020 00:41:00 -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 1587F3A07BE for ; Sun, 10 May 2020 00:40:59 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5A4FD5C008B for ; Sun, 10 May 2020 03:32:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 10 May 2020 03:32:35 -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=3nHNBaQZDz4+3Od3AXa8vhoSeICe+Z8bVX2OiIgfHnM=; b=KKBMe0d9 SqcyX3YurAsRMBlWJ4r6hIG7qvbib4iBID7JBxIFbPeHAb264qSqebD9CMSbcZ5x vUoRSGzNaNoLniYpnQmP7OSYx5AdXyTI+8T7syzDsx95SQjazCpx8fXbrTAOo/ry Zo9vIqy3uIhBg3hZViaU8FEwx+wgx5t6BpsEeur6CcKLBU7S2gRLZhPY27iuU5Ys k1DVefzlCvKDy00JF06Fas/OuxSHv1hShfBtl4Ey4mz3ANNoXh6YdclHqUUiwJow 0PnlM4O8cwzz03jQYrC7SBnhp16BzlOoGxZTKEP9XwiKGSYJSQLDTEz4AcrNBCK6 +mRNorJbmAU3Qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=3nHNBaQZDz4+3Od3AXa8vhoSeICe+ Z8bVX2OiIgfHnM=; b=PFmgxXPaCuZ0tiUWMps7tKaSjCbZw6G4ZMH4roya5qDua GuU8Q/UVBecsBKdF1/8M+ff4aBTxa0Zb6aijKiSK5UyKMefcdiph3oCNQgL+cO8A e606euo9pM30oGLe+rQlO2MuIoqOt7nQD9Fln5EDbxQhlXs3MGKrs7jPNeCVaTpv lTQXWbJ474rZtrFmWMpe11QDn3vRr5Ci7BwYm5xmUGX+y3LCRmA5wNc/HaHF5/dQ vMy8q998uVgOTgsOvC77XxjdxUI9EDH76GhUVNFogQtyJF9nf81n6wQYR6UcFzsd CBAd4T+Qabp9ZbqSIKT/8Rank24ijfwWp2GWRYT+Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeejgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudejhedrvdefuddrud dttdenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [52.175.231.100]) by mail.messagingengine.com (Postfix) with ESMTPA id 05920328005A for ; Sun, 10 May 2020 03:32:34 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3611257575666462566==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200510073235.05920328005A@mailuser.nyi.internal> Date: Sun, 10 May 2020 03:32:34 -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, 10 May 2020 07:41:02 -0000 --===============3611257575666462566== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC4) 1 issues received 4 new comments: - #376 deprecate LZO compression (4 by JeromeMartinez, mkver, retokromer,= robUx4) https://github.com/cellar-wg/matroska-specification/issues/376 [clarifi= cations] [enhancement] [spec_main]=20 Pull requests ------------- * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #158 Adjust definition of "forced" and "default" flags to better reflec= t usage (1 by rcombs) https://github.com/cellar-wg/matroska-specification/pull/158 [clarifica= tions] [needs_to_be_rebased] [spec_main]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============3611257575666462566== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 10, 2020

Events without label "editorial"

Issues

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

1 issues received 4 new comments:

Pull requests

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

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============3611257575666462566==-- From nobody Thu May 14 07:34: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 021D23A0A8C for ; Thu, 14 May 2020 07:34: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 nFmi-9IIt1ul for ; Thu, 14 May 2020 07:34:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D843A0AAF for ; Thu, 14 May 2020 07:34:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EDF34389D5 for ; Thu, 14 May 2020 10:32:03 -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 XpHUPRYbAz76 for ; Thu, 14 May 2020 10:31:59 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BB5E5389D0 for ; Thu, 14 May 2020 10:31:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 84A25516 for ; Thu, 14 May 2020 10:34:05 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] on restricting Unknown-Sized Elements 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, 14 May 2020 14:34:13 -0000 --=-=-= Content-Type: text/plain My reply: 1) EBML is already past WGLC and has been approved by the IESG, so this issue is not in order! 2) your complaint is well taken, and it is reasonable for specific DocTypes (e.g., 'Matroska' or another) to state that Unknown-Sized elements are not allowed. 3) alternatively, you could author a new top-level EBML element which states "there are no Unknown-Sized" elements in this document. Creating a limited subset of EBML for specific purposes would make a lot of sense, the same way that PDF/A was created. I would encourage you to pursue this direction. https://github.com/cellar-wg/ebml-specification/issues/338 wm4 wrote: > This issue is about: > https://github.com/cellar-wg/ebml-specification/blob/master/specification.markdown#unknown-data-size > Normally, EBML is very simple to parse: since every element has a size, > elements can just be recursive parsed where each recursive call would > have the start end end byte position of the sub-element as > argument. Unknown elements can always be skipped. > Unknown-Sized Elements change this. Suddenly a sub-parser has to be > aware of all parent elements, and which elements they can contain. This > is a significant complication. When a parser encounters an unknown > sized element of unknown type, it has to assume it is a master element, > and has to skip through its sub-elements. Then for each element in this > mode, it has to determine whether this element is allowed in any of the > top levels, and if so "return" (assuming it's a recursive parser). > In addition, it becomes impossible to parse files that contain unknown > elements. Being able to skip unknown elements is very important for > extensibility, but it's not generally possible if Unknown-Sized > Elements are allowed. At least global elements can not be associated > with the correct level anymore if multiple unknown sized elements are > nested, and at least for CRC-32 elements this should be a real > problem. (Maybe I'm misunderstanding this. And I don't understand the > last example in the table in the paragraph in the specification link > above.) > The specification restricts use of Unknown-Sized Elements a little. For > one, the "EBML Schema" must set "unknownsizeallowed". And also it says > this: >> Unknown-Sized Elements MUST only be used if the Element Data Size is >> not known before the Element Data is written, such as in some cases of >> data streaming. > This is extremely unclear and vague. I interpret this as: "a writer can > use unknown-sized elements whenever it seems convenient". For example, > does that mean Clusters in Matroska can be unknown sized or not? Who > knows... > I find it surprising that the format has such an obscure > complication. Just look how EBML fared in the past. mkvtoolnix keeps > adding weird hacks to avoid any new elements (such as putting new > elements into specially named Matroska tags, instead of adding new > proper EBML elements) because some Matroska parsers were bad enough to > not skip unknown elements. And unknown elements are a pretty obvious > concept, and there were test files for this. How would the average > Matroska parser fare on files that use tricky combinations of > unknown-sized elements? I think this concept is too complicated. > I claim that unknown-sized elements are useful only in very specific > cases, such as specific Matroska elements when livestreaming. I suggest > that the EBML Schema is required to list elements which can have > unknown size, that no new unknown sized elements get added unless on > incompatible new versions of the schema, and that the use of unknown > sized elements is very conservative. Specifications based on EBML > should clearly define when the use of unknown-sized elements is allowed > at all. For example, Matroska could define that Segment and Cluster > elements can be unknown sized (and nothing else) if it's a streaming > case, and using known Segment or Cluster sizes would negatively affect > media latency. I suggest the vague sentence quoted above is removed > from the EBML specification. > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/cellar-wg/ebml-specification/issues/338 > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl69Vt0ACgkQgItw+93Q 3WVS3wf+Ioe+SSBgWBNG/z8UMRU6/MROail+Z5CGVY+G6q7LkKyOlBBDqFfniw5/ XiIIABmrd7EkUXtlCi0KQl9xYU4qSpnEnoE1oyvi9xxoIp0qijMe2LF61aQNRL6S CaUdP3ICseARN4rL2dyUvfNzq9hc6hvVRnDveIqhuMq3Mbn9750Lu5/j8vQZDG7w osXAcCq0/8WLKmv4ez9Q9ugKyr/jhdqnJBywwiY53KJdqxG8SDqMFdpDyw3XdHNJ 0nEK9Ebvwi/L14L9TuP78vHNBMdNm20UaJ15pJAqTmC2VKoT7E+/a7CVpTUlmkW9 7BwnNs6UOdV1zLoB6RY+PfGohZwOKQ== =bEsZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun May 17 00:41:24 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04703A0771 for ; Sun, 17 May 2020 00:41:21 -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=ZEF0ahBy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o4Wze72O 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 XlUDQOpy_VyX for ; Sun, 17 May 2020 00:41:19 -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 BF7073A074B for ; Sun, 17 May 2020 00:41:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 830CA5C0065 for ; Sun, 17 May 2020 03:32:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 17 May 2020 03:32:31 -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=ZYLuZhyIjMkoHRbVBvgvt5QRtEpmmoDyvvj5YuZRChM=; b=ZEF0ahBy AEGio2Wi+u2XuVuag3XybEDc9UDyTxR0qzJVVF3pUF9N+mIWSVk0hH9ehaWmEAUF VDm1LaAUaTuLxVyCzgCxUjRoywxA89UGtycCxNPu6ziIo7o2eJevRcbT0wHtvZwS 11U2ZNj/ohA24Ecf9EqfKYOcvaWlY+fyk1n/BL4l1AiDeXiqql8oIlrsyeJOGvjb hzq/MOcqnjDfOmQH2CrKLNuCTiQ/sI4SMWkLU7pxRN9ewVCK7eAOi3KRIJtuEGCv 0rZY4oL5XO+IcakLrlXGWAPVqstCyaegsFgX3HZeSzjpekAeVaq9mFhwp0n9Gpju 6RnBj/SPpNusZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ZYLuZhyIjMkoHRbVBvgvt5QRtEpmm oDyvvj5YuZRChM=; b=o4Wze72OMbE/wdLF6CO91xSpxHVd/n4EOOh4aNvpOiJ9L q1GwCUSvKdXeuFbc2+YigEe/V16fXarC+NFkLgq8yYJtk+Z0cdw8rMP7t6xVIVPW P/G1ZvaPWd900PtbiS3LZwjlOrmCZWyOjzlm9r5jhLn6AkqsjZYq2KdnWaG3+I5L 9fhfVS8kug3/LJwxcbs28f9FB5LY+dmj3a5+gsM210sqezbONZ2EKgmOyeuWpVRy F02KENzIOX8+GP5ZnkNeJWfb9Pj75/a0JPkMveVclsxseA2G96IeF4is+Sp2ncCv mOYKU45VAYLqPRKr6dSOVBImKBV000W5qFyKpn9gg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtvddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepudefrdeiiedrudelvddrud dvleenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [13.66.192.129]) by mail.messagingengine.com (Postfix) with ESMTPA id 2E8473280067 for ; Sun, 17 May 2020 03:32:31 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4001916534547971754==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200517073231.2E8473280067@mailuser.nyi.internal> Date: Sun, 17 May 2020 03:32:31 -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, 17 May 2020 07:41:22 -0000 --===============4001916534547971754== 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=AC5) 3 issues received 5 new comments: - #376 deprecate LZO compression (1 by retokromer) https://github.com/cellar-wg/matroska-specification/issues/376 [clarifi= cations] [enhancement] [spec_main]=20 - #375 Add Support for Closed Captions to .MKV container (1 by sbshepherd) https://github.com/cellar-wg/matroska-specification/issues/375=20 - #373 Write down how extra data is saved in CodecPrivate of AVC & HEVC (= 3 by JeromeMartinez, MikeChenMM, steffenmanden) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 * cellar-wg/ebml-specification (+1/-0/=F0=9F=92=AC4) 1 issues created: - Unknown-Sized Elements are very hard or impossible to parse, and should= be restricted (by wm4) https://github.com/cellar-wg/ebml-specification/issues/338=20 1 issues received 4 new comments: - #338 Unknown-Sized Elements are very hard or impossible to parse, and s= hould be restricted (4 by dericed, mcr, wm4) https://github.com/cellar-wg/ebml-specification/issues/338=20 Pull requests ------------- * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Add AVC and HEVC codec mappings (by JeromeMartinez) https://github.com/cellar-wg/matroska-specification/pull/377=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============4001916534547971754== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday May 17, 2020

Events without label "editorial"

Issues

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

3 issues received 5 new comments:

  • #376 deprecate LZO compression (1 by retokromer) clarifications enhancement spec_main
    • =20
  • #375 Add Support for Closed Captions to .MKV container (1 by sbsh= epherd)
    • =20
  • #373 Write down how extra data is saved in CodecPrivate of AVC & = HEVC (3 by JeromeMartinez, MikeChenMM, steffenmanden) codec mapping 1 issues created:

    1 issues received 4 new comments:

    Pull requests

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

    1 pull requests submitted:

    Repositories tracked by this digest:

    --===============4001916534547971754==-- From nobody Thu May 21 18:00:17 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770F03A0D5A for ; Thu, 21 May 2020 18:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7Mi2NLI5HVZ for ; Thu, 21 May 2020 18:00:12 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 22D2A3A0D58 for ; Thu, 21 May 2020 18:00:11 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id 202so5568842lfe.5 for ; Thu, 21 May 2020 18:00:11 -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=jVLAl1M5wrsZP4Oqf8dD/meLteHivF3ldhBxsqOMiBo=; b=K2Se9jFI60n1mBs33aV6izjjHl5mV3Q+/F3nBuDlN371HovcR4AGXQqdueS9Ty870A kgwfHD2U9rK19E9yT6gioovaX+bzot4zsUjJOOndHu/jwn0dTg5xue9ZpfGKtVPdnTYp CPQqIeVW/avDPwLZdiOa6x6N2JLAKGJlqwLuT+0nI0+NwzUMWfGJhHvL4FGSR+5/+MOz gUM0plxLYAEaoFpCUPrdZlNxAHB30MeDGiGcoTMQNx/GqBms0pWy/8sljo+KxJunlvhm XZrNMomewWRglT3IcRPoG94LU+3vppvwuEQP/yBVYPngG2PQjrgtKkZMjkDmbjlND4qK bPfg== 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=jVLAl1M5wrsZP4Oqf8dD/meLteHivF3ldhBxsqOMiBo=; b=ueFKRUpuUGbao8hrjx0UavWZqH6ayRDEzjvYxfXRthIvOZd3AO80taj0r0w910hAZq rFiTkeHJqN4sfl/6K3akSV3Y0M4GyW55vkhWP/rIhqnqwXG3mGk71iLM0H7IBYJ4LUJB GsNjCw7QKCGTVuFtZgMYvtmAeeCV6uN8BbNa9M61veTyFIxvVQJXbwWA/oAaBqH1PNsh 1qaSrLlCKzrsY9qSg7vwXN48BFFkc8kbkI3BiEZ2ZO7AxITjOC2zwBG3DdXHhPYVca1J /hUTPa4S13rxALXiPmkFiowqTSlHRyltDuAeG6u51dv+0MH2+/PYqZIuqN0B/8XSX5CF hPfQ== X-Gm-Message-State: AOAM532xhdiXPjBVc77KTHgrc8syPYwWefIRzDN34esh1r/Nv55DUgY0 TRo7h8mMmQMW3uiyacrfVqTrXD8ayJt7vf2Icym0iE+umVQ= X-Google-Smtp-Source: ABdhPJzWN/3UMWu1wSVuCCwiZckGlVoQ0u6fYyszPx1V6WcwcfcU3HPD0Wo54WKxygaq6u99DFwnh6rSRNJOQi3fprw= X-Received: by 2002:a05:6512:3111:: with SMTP id n17mr6170912lfb.137.1590109209853; Thu, 21 May 2020 18:00:09 -0700 (PDT) MIME-Version: 1.0 From: Spencer Dawkins at IETF Date: Thu, 21 May 2020 19:59:42 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000009b857905a632261f" Archived-At: Subject: [Cellar] Agenda for Cellar 2020-05 Virtual 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: Fri, 22 May 2020 01:00:16 -0000 --0000000000009b857905a632261f Content-Type: text/plain; charset="UTF-8" Just as a reminder, we have our May Cellar meeting next Tuesday. I've uploaded an agenda at https://github.com/cellar-wg/chair-notes/blob/master/interim-2020-06/agenda.md. Please let me know if you have additions or corrections. Best, Spencer --0000000000009b857905a632261f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Just as a reminder, we have our May Cellar meeting next Tu= esday.=C2=A0

    I've uploaded an agenda at=C2=A0https://github.com/cellar-wg/chair-notes/blob/master/interim-2020-= 06/agenda.md. Please let me know if you have additions or corrections.<= /div>

    Best,

    Spencer
    --0000000000009b857905a632261f-- From nobody Fri May 22 06:23:22 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6399A3A02BE for ; Fri, 22 May 2020 06:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCQo6o-o0fvV for ; Fri, 22 May 2020 06:23:17 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 68C953A00D2 for ; Fri, 22 May 2020 06:23:17 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id f6so5008533pgm.1 for ; Fri, 22 May 2020 06:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lPOn+/QLJVQ1SrTIZFfHltFmvN8BNEPk8pCY3QsvN7o=; b=y41URdXXSd/WtJn7r+gKEkWytv2NctZE2Wu43bDIKMZ+c2uXJTit+clvdPkJ1mCVNN cAhc6yVMjLjRM5d1gufCMBXeJpRIy0n9oNbQs3lofI2Vo9bUwpM6wBtjf1CNACsTKLfI A/ma8iRCWUdcGmptgaRjYlR18kwTu4UtXgJpD4iHZL/levPKQ0WmFmG3nReAbDoHEL7h Pt8iTyunqr+KaHMl9OeLfYBS8lO4ULu6IOA/cija1jbhyYdoICQ01y+5pKeCgnkhI0E0 H3zQu5t3oZSKwE7+ktMMzHOiun2Ljjp25KT6j6EqyBWQKixpnfywbwpyp+7K4yzj2g07 mVaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lPOn+/QLJVQ1SrTIZFfHltFmvN8BNEPk8pCY3QsvN7o=; b=C2DEfG5jEDPP5AaiXaOW6fdl8MxG065jiX1m0f19n+DRJkPyibqR9y2U5pGCqFLEoe Y95DEcib80Lurg5b0boZ3QvSiVfBj6Wyvgd4ipYoAqPZjTQDVIk1A2byc/PE9SkOyilb CLN+hgMEcP0Qzx9PyODH9a4vjJhB1XNFd/3Kzk2SKSXMufZzlhnXPQCitAOIRV4ePnkd 5gOCdYTIOBvLNy6Pa1Rb4iY+83GvcPn0Ym2WkEpKU9bD7r9oHZTIl7sq2hiYmSx9bGDF bkrO7IYpVJHWuZeTV4nESSKqXKNgpLRXqlqtWHUtJJBJPomDFBC8UCRtg4APPcNgCAwS nRyQ== X-Gm-Message-State: AOAM533M0Xk7Xnp6LpK61g+B/RYCzhqRsXUe/uzKVJ2LMKHssnJz69Ng WT8d1MpDnzFVLG+HV2llcthYpkDyoH0gqQlbQPk81w== X-Google-Smtp-Source: ABdhPJzi9wproK+WRrYu0faCm/BK/gKrAnASN9ymb1P3DNdjZvhfdP+H4puINsr2xg0ccUfmSFaUMlzjyafC0Tu93Zk= X-Received: by 2002:a63:ca45:: with SMTP id o5mr1199515pgi.103.1590153795883; Fri, 22 May 2020 06:23:15 -0700 (PDT) MIME-Version: 1.0 References: <24830.1588522227@localhost> In-Reply-To: From: Steve Lhomme Date: Fri, 22 May 2020 15:23:04 +0200 Message-ID: To: Adam Roach Cc: Spencer Dawkins at IETF , Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376)) 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, 22 May 2020 13:23:21 -0000 I hope we don't have to get to this point. In Matroska we (currently) have 4 compressions: - header compression: stripping the same bytes at the beginning of each frame, not sure if there's a patent/license issue on that. It was clearly designed in "clean room" (no knowledge of existing other formats doing that). - zlib: designed to have patent issues (and used widely for everything, even PNG ?) https://www.zlib.net/zlib_faq.html#faq31 - LZO which at least has some documentation in the Linux Kernel. I wouldn't imagine they would use that it there was any issue. - bzlib, which is fact bz2 an evolution of bzlib to avoid patents (https://en.wikipedia.org/wiki/Bzip2), also used very widely. My main concern was that LZO did not have a freely usable implementation (official being GPL or commercial) but then I found some more libs capable of that. So at least for implementation they all have free (as in everything) implementations. As for patents do we have to put some text that we believe their not covered by patents ? Le mar. 5 mai 2020 =C3=A0 23:18, Adam Roach a =C3=A9crit= : > > On 5/5/2020 3:43 PM, Spencer Dawkins at IETF wrote: > > Hi, Michael, > > On Sun, May 3, 2020 at 11:10 AM Michael Richardson wro= te: >> >> >> Hi, I wanted to bring this item to the list's attention. >> >> Spencer: I seem to remember that the IETF has had compression IPR issues= in >> specifications in the past. IPCOMP comes to mind, but I am guessing tha= t >> other RTP/SIP groups have gone through this.. > > > I had forgotten IPCOMP, but was remembering RoHC and RoHCv2. I think you'= re remembering SIGCOMP. > > > Probably not: SIGCOMP sidestepped this specific issue altogether by norma= tively specifying precisely zero compression algorithms. It instead defined= a virtual machine that message recipients would implement, and to which me= ssage senders would send bytecodes sufficient to decode subsequent messages= . > > /a > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Fri May 22 08:12:34 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 28B003A0C70 for ; Fri, 22 May 2020 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.276, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 7JtsnjkLDUMr for ; Fri, 22 May 2020 08:12:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7709D3A0C13 for ; Fri, 22 May 2020 08:12:21 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04MFCGCD074699 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 22 May 2020 10:12:17 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1590160338; bh=gJEmjLsi5yUtxgX/4FJ9A6KS1Qh/c5W7locnauVe7Xw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=nNMzXPIHLfez/b09nNGOR8KY1i29d/VgSsVkAv6mzukUmKUZzNVbqpVxDGQpVRwjb BaZY1BFukxIBbjZnXba0BjKDFIGzFPD6TxoFPa4bxkTH2AzFRDvOGCcsgr5rWZiIND BtyFukp4FhU9eORDjXOLqPR0TJP40QdfcccNngyY= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Steve Lhomme Cc: Spencer Dawkins at IETF , Michael Richardson , Codec Encoding for LossLess Archiving and Realtime transmission References: <24830.1588522227@localhost> From: Adam Roach Message-ID: Date: Fri, 22 May 2020 10:12:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] compression libraries in IETF specifications (was Re: [cellar-wg/matroska-specification] deprecate LZO compression (#376)) 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, 22 May 2020 15:12:33 -0000 On 5/22/2020 8:23 AM, Steve Lhomme wrote: > I hope we don't have to get to this point. Agreed -- I don't think it would be a good model for CELLAR. > As for patents do we have to put some text that we believe their not > covered by patents ? No, and in fact, you shouldn't. The IETF is very careful about not taking specific positions about the presence or validity of patents that apply to technologies. If someone _does_ know about patents, they're either required or strongly encouraged (depending on their relationship to the patent in question) to make a disclosure to the IETF, but these appear on https://www.ietf.org/ipr rather than in the documents themselves. There's no real way to assert "believed to be unencumbered." /a From nobody Sun May 24 00:41:44 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16F3A0A24 for ; Sun, 24 May 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=xvOgcKQy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I5lQT1YT 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 puABzq3-zQSP for ; Sun, 24 May 2020 00:41:21 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1468D3A0A1C for ; Sun, 24 May 2020 00:41:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 743BE5C007F for ; Sun, 24 May 2020 03:32:37 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 24 May 2020 03:32:37 -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=pyjGp83CYWPXDYV6Gv4WBf7Brk3Eeybjcr0pjBdZtoE=; b=xvOgcKQy NV8uM0DFrqO9MIhFRuwWsW96kY3W/YMJKC+fKHwp3VxLqspT/0qESMZnSN/Gdi5v eF5lyD0NdSynlMINyVmde+538l5KgdC8l2N735DfDsjFF7EiSMetkETF40ZAPadw NEw8IQxJyYcTNZ5TI0HRpc0LRojt4xdQRGQOuNgFYE6PluP9+K12t2DoD12elpUS SOa/tSA2NQiN5XqHS3ntHu+yJW+g/mf73JQY2mYmPbNWEA1+y5xqbrOeFy+QiwpA kONkNXGTCgxz2shj5eshpS/PF5S3PUKuSBUB8EnN9ssHJ3wv5VZL8KzPiK+jqNpb 7ovv+yj5/0JI/g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pyjGp83CYWPXDYV6Gv4WBf7Brk3Ee ybjcr0pjBdZtoE=; b=I5lQT1YTpzsxd+ROSswH0ZJiBxMFaadaAxcYgZ/vJcOiX 929RsrkxkoVI+m0ieMVog7T67p6j91X7KTNu3faia6f56bSleKiICf0NnWuK89Wz UJW7TqTn2gBI5VgaaIPIUZI1Y9PvzUEJk6jfTRvkIeEizkKmSuV9otsKYIA3rCOs u1pr37LWY2oTaseytDnaFRRkUXhfP1hD/eUePBQBAcU65e4JQSA0v4tE987R5oSy VVDkQ2jFoCbbH6uLLGXxQGXo6U4+PACMgRAzsGYrFaRDGFtC6vWhSv8jb0bdPTbI QGjVfgO2HTE1sP1YPkfiIwthiVWKT7fFx8XUKhA5w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddujedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddugeekrddujeehrd duledunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az134.internal.cloudapp.net (unknown [52.148.175.191]) by mail.messagingengine.com (Postfix) with ESMTPA id 106E0306646E for ; Sun, 24 May 2020 03:32:36 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3861189417811732931==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200524073237.106E0306646E@mailuser.nyi.internal> Date: Sun, 24 May 2020 03:32:36 -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, 24 May 2020 07:41:26 -0000 --===============3861189417811732931== 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 (+3/-3/=F0=9F=92=AC46) 3 issues created: - Split website stuff into separate repository? (by mbunkus) https://github.com/cellar-wg/matroska-specification/issues/386 [discuss= ion] [website]=20 - ebml_schema2html.xsl "max" column wrong if no maxOccurs attribute (by m= bunkus) https://github.com/cellar-wg/matroska-specification/issues/379 [bug]=20 - ebml_schema2html.xsl transform creates empty "level" column (by mbunkus) https://github.com/cellar-wg/matroska-specification/issues/378=20 3 issues received 46 new comments: - #386 Split website stuff into separate repository? (3 by robUx4) https://github.com/cellar-wg/matroska-specification/issues/386 [discuss= ion] [website]=20 - #378 ebml_schema2html.xsl transform creates empty "level" column (14 by= ablwr, mbunkus, retokromer, robUx4) https://github.com/cellar-wg/matroska-specification/issues/378 [bug] [w= ebsite]=20 - #373 Write down how extra data is saved in CodecPrivate of AVC & HEVC (= 29 by JeromeMartinez, MikeChenMM, mbunkus, mkver, rcombs, robUx4, steffenma= nden) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 3 issues closed: - deprecate LZO compression https://github.com/cellar-wg/matroska-specifi= cation/issues/376 [clarifications] [enhancement] [spec_main]=20 - ebml_schema2html.xsl "max" column wrong if no maxOccurs attribute https= ://github.com/cellar-wg/matroska-specification/issues/379 [bug] [website]=20 - ebml_schema2html.xsl transform creates empty "level" column https://git= hub.com/cellar-wg/matroska-specification/issues/378 [bug] [website]=20 * cellar-wg/ebml-specification (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #338 Unknown-Sized Elements are very hard or impossible to parse, and s= hould be restricted (1 by robUx4) https://github.com/cellar-wg/ebml-specification/issues/338=20 1 issues closed: - Unknown-Sized Elements are very hard or impossible to parse, and should= be restricted https://github.com/cellar-wg/ebml-specification/issues/338=20 Pull requests ------------- * cellar-wg/matroska-specification (+7/-4/=F0=9F=92=AC28) 7 pull requests submitted: - support `rationale` and `references` documentation in the website table= (by robUx4) https://github.com/cellar-wg/matroska-specification/pull/387 [website] = - Jekyll xslt (by robUx4) https://github.com/cellar-wg/matroska-specification/pull/385 [website] = - Schema to spec improvements (by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/384 [website] = - Spec to html table improvements (by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/383=20 - add an XSLT script to replace data2spec (by robUx4) https://github.com/cellar-wg/matroska-specification/pull/382 [website] = - Ebml schema2html fixes (by robUx4) https://github.com/cellar-wg/matroska-specification/pull/381=20 - XML-escape HTML elements in nodes (by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/380=20 6 pull requests received 28 new comments: - #385 Jekyll xslt (5 by retokromer, robUx4) https://github.com/cellar-wg/matroska-specification/pull/385 [website] = - #383 Spec to html table improvements (2 by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/383 [website] = - #382 add an XSLT script to replace data2spec (12 by mbunkus, robUx4) https://github.com/cellar-wg/matroska-specification/pull/382 [website] = - #381 Ebml schema2html fixes (1 by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/381 [website] = - #380 XML-escape HTML elements in nodes (4 by mbunkus, r= obUx4) https://github.com/cellar-wg/matroska-specification/pull/380=20 - #377 Add AVC and HEVC codec mappings (4 by JeromeMartinez, mbunkus, rco= mbs, steffenmanden) https://github.com/cellar-wg/matroska-specification/pull/377=20 4 pull requests merged: - Jekyll xslt https://github.com/cellar-wg/matroska-specification/pull/385 [website] = - Schema to spec improvements https://github.com/cellar-wg/matroska-specification/pull/384 [website] = - add an XSLT script to replace data2spec https://github.com/cellar-wg/matroska-specification/pull/382 [website] = - Ebml schema2html fixes https://github.com/cellar-wg/matroska-specification/pull/381 [website] = * cellar-wg/ebml-specification (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - add a more in-depth definition of an enum value (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 --===============3861189417811732931== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday May 24, 2020

    Events without label "editorial"

    Issues

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

    3 issues created:

    3 issues received 46 new comments:

    3 issues closed:

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

    1 issues received 1 new comments:

    1 issues closed:

    Pull requests

    cellar-wg/matroska-specification (+7/-4/=F0=9F=92=AC28)

    7 pull requests submitted:

    6 pull requests received 28 new comments:

    4 pull requests merged:

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

    1 pull requests submitted:

    Repositories tracked by this digest:

    --===============3861189417811732931==-- From nobody Sun May 24 09:05:35 2020 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8313A0AFF; Sun, 24 May 2020 09:05:32 -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 vMv0PIx0vIuq; Sun, 24 May 2020 09:05:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544343A0AFB; Sun, 24 May 2020 09:05:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5A64938A47; Sun, 24 May 2020 12:03:09 -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 U-Xy3eSfhmh2; Sun, 24 May 2020 12:03:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 271B638A43; Sun, 24 May 2020 12:03:08 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6B786B3; Sun, 24 May 2020 12:05:22 -0400 (EDT) From: Michael Richardson To: draft-ietf-cellar-ffv1@ietf.org cc: cellar@ietf.org X-Attribution: mcr 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: [Cellar] ffv1-13 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 May 2020 16:05:33 -0000 --=-=-= Content-Type: text/plain My understanding last month was that the -13 did not include all the changes needed by the AD review. The most recent list of changes needed is at: https://mailarchive.ietf.org/arch/msg/cellar/WyZVENFW9rkMUkvoajeu3eMzUls/ In particular, there are the items that are still marked TODO: https://mailarchive.ietf.org/arch/msg/cellar/Rlf3ivXHszpkVsnvmEwIL6CM0mo/ how can, Spencer, myself and the rest of the WG help the editors finish this off? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7Km0IACgkQgItw+93Q 3WUAUggAgbO+DhV9ItbElGDoHaBRLrKyRTRnPTmWTmuCu+hWjFxMJkL6kOdsgauD 3ZJRlMfxV+yhoXktyh4W1N3oi1wjx+0IXmAsjKMui1heCj6CyNuAZV5i7wj+Tuvd xJjcM9lKicsfq63vZIOiyxO2d9BjV8oaTbqbRWq4J8cf8On/XccuAasmLZxIZKxE F/9YWJLKzCRgz1lhi9sOWegoA5bMejnC87PtgpYpPwtAem76e/ua4FwlGkSQ9PHt aDMetCrx2YX1/91vkNoPPjG7US0nUH+5+PrB6GxONw7/U7wOAoi5BkwLVCmJ2ubg 50TdR+wKhUe92AIWlewlRwxRMCWWog== =HcHP -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon May 25 02:56: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 69B203A0A73 for ; Mon, 25 May 2020 02:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=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 SV8Vf7s08AZ6 for ; Mon, 25 May 2020 02:55:58 -0700 (PDT) Received: from 9.mo178.mail-out.ovh.net (9.mo178.mail-out.ovh.net [46.105.75.45]) (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 281973A0A67 for ; Mon, 25 May 2020 02:55:57 -0700 (PDT) Received: from player794.ha.ovh.net (unknown [10.110.115.149]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id 031EE99423 for ; Mon, 25 May 2020 11:55:55 +0200 (CEST) Received: from mediaarea.net (p548f991e.dip0.t-ipconnect.de [84.143.153.30]) (Authenticated sender: jerome@mediaarea.net) by player794.ha.ovh.net (Postfix) with ESMTPSA id 0CB75FA88870; Mon, 25 May 2020 09:55:52 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-96R001daf8ef8b-32a9-4ccd-8088-135cc6a4a471, 16A1746AEB8C8CE2CC175474552A9C934A1F9F8D) smtp.auth=jerome@mediaarea.net To: Michael Richardson , draft-ietf-cellar-ffv1@ietf.org Cc: cellar@ietf.org References: <7267.1590336322@localhost> From: Jerome Martinez Message-ID: Date: Mon, 25 May 2020 11:55:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <7267.1590336322@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 10820742532067627153 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedruddvtddgvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeevveeuteeigeeugfdvtdelgefhvdfgiedtkeejvdevudevfffhffektdfgffevhfenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheefrdeftdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejleegrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] ffv1-13 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2020 09:56:01 -0000 On 24/05/2020 18:05, Michael Richardson wrote: > In particular, there are the items that are still marked TODO: > https://mailarchive.ietf.org/arch/msg/cellar/Rlf3ivXHszpkVsnvmEwIL6CM0mo/ > > how can, Spencer, myself and the rest of the WG help the editors finish this off? > There were some patches merged last week: https://github.com/FFmpeg/FFV1/pull/199 https://github.com/FFmpeg/FFV1/pull/202 I am preparing a new bunch of updates for answering the parts marked "TODO" before requesting a new review. Jérôme From nobody Tue May 26 11:49:56 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 35BC53A0ECE; Tue, 26 May 2020 11:49:52 -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.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <159051899208.12358.14675567022621594235@ietfa.amsl.com> Date: Tue, 26 May 2020 11:49:52 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-14.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, 26 May 2020 18:49:52 -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-14.txt Pages : 51 Date : 2020-05-26 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-14 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 May 26 11:50:05 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 B77D43A0ED7; Tue, 26 May 2020 11:49:52 -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.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <159051899270.14145.4205729129006067644@ietfa.amsl.com> Date: Tue, 26 May 2020 11:49:52 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-11.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, 26 May 2020 18:49:53 -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-11.txt Pages : 53 Date : 2020-05-26 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-11 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 Sun May 31 00:41: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 F23833A1304 for ; Sun, 31 May 2020 00:41:17 -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=dAuNIuxv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zktn8tmb 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 Y8Aoqi8JqCnd for ; Sun, 31 May 2020 00:41:13 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2453A1306 for ; Sun, 31 May 2020 00:41:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 527F663B for ; Sun, 31 May 2020 03:32:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 31 May 2020 03:32:31 -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=7JjH2Isr3BOj97Uspib74+aNovYqZVgsyIYdO1oAS9U=; b=dAuNIuxv 8O6TMBW5Z88kMC683E0XEupG/wsopYco1InUZhAp7mtPj7kmCOBSWvlqdkxP9rO4 OM3Led+tyd93yktWPeBvtHSr4RgFKTluCRDInTLS59jv2eqyp4HuAp8kpkdwIVOS 4vbRyiWoH/3g0okWZtWx8kqt9XY357qeacVLZemN3Ng2q3tyZ58sKm2QJl9PQG33 wkuRiHkmOpBNleQVWyyhpoUiecVy/DtY9XtT/VZhEBNlgAQgThugEhjeBZFS4ELH E7wabtUYwdDGX8Usxc3Z/hGqIxqDgFFYDHdgUEEH13YfxRTodYHUUO+sqOG75+35 oIqlIYuKcMJsFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=7JjH2Isr3BOj97Uspib74+aNovYqZ VgsyIYdO1oAS9U=; b=Zktn8tmbETvJT5ngc0+JUAFrQq3gYBDt35opd6N8PTS5O p2ZbxJXUM/52MClYeQ6jzKarfuo95dR9XS2+Si28XHwI4oCtATP/neu+XVQ5RcGI D6KRy5PgRfLTnHovTQ8wqI8Suv3IJ2s4lT0bwpa5ZLR/oR1TpDuL+M/e4NyO+g4S avss+KdOEhdbGk4TJM4F1a8Y94YkY1+++xXTa7y7JMFL31gZWjt45uUd0j5MUqW+ OLyc8cjTuMFY2R7XyzkPPIj9mYjoSKZzDlEOX0Y0CJJsLSh10zJc3GNyUPFaY0b4 d0PETq7d2y50li/jjBAPVthwcToSwqzYTBUXEYWjQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefvddgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddukeefrdegtddrhe eknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [52.183.40.58]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E8123060FE7 for ; Sun, 31 May 2020 03:32:30 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3598334572083878954==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200531073230.9E8123060FE7@mailuser.nyi.internal> Date: Sun, 31 May 2020 03:32:30 -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, 31 May 2020 07:41:18 -0000 --===============3598334572083878954== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+1/-1/=F0=9F=92=AC32) 1 issues created: - av1.md and wavpack.md not included in codecs RFC (by mbunkus) https://github.com/cellar-wg/matroska-specification/issues/391 [bug] [c= odec mapping]=20 6 issues received 32 new comments: - #391 av1.md and wavpack.md not included in codecs RFC (1 by robUx4) https://github.com/cellar-wg/matroska-specification/issues/391 [bug] [c= odec mapping]=20 - #386 Split website stuff into separate repository? (4 by mbunkus, robUx= 4) https://github.com/cellar-wg/matroska-specification/issues/386 [discuss= ion] [website]=20 - #375 Add Support for Closed Captions to .MKV container (8 by JeromeMart= inez, dericed, mbunkus, robUx4) https://github.com/cellar-wg/matroska-specification/issues/375 [codec m= apping]=20 - #374 clarify use of forced flag (5 by rcombs, robUx4) https://github.com/cellar-wg/matroska-specification/issues/374 [clarifi= cations] [spec_main]=20 - #373 Write down how extra data is saved for usage with AVC & HEVC (9 by= JeromeMartinez, mbunkus, retokromer, steffenmanden) https://github.com/cellar-wg/matroska-specification/issues/373 [codec m= apping] [format extension]=20 - #316 Will codec spec update future? (5 by mbunkus, robUx4) https://github.com/cellar-wg/matroska-specification/issues/316 [spec_co= decs]=20 1 issues closed: - Split website stuff into separate repository? https://github.com/cellar= -wg/matroska-specification/issues/386 [discussion] [website]=20 * cellar-wg/ebml-specification (+1/-0/=F0=9F=92=AC0) 1 issues created: - XHTML Basic has been superseded (by retokromer) https://github.com/cellar-wg/ebml-specification/issues/341=20 Pull requests ------------- * cellar-wg/matroska-specification (+4/-1/=F0=9F=92=AC18) 4 pull requests submitted: - Fixes for website migration (by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/392=20 - Add AVC and HEVC codec mappings with BlockAdditionMapping 2 (by JeromeM= artinez) https://github.com/cellar-wg/matroska-specification/pull/390=20 - Add AVC and HEVC codec mappings with BlockAdditionMapping (by JeromeMar= tinez) https://github.com/cellar-wg/matroska-specification/pull/389=20 - allow extensions to CodecPrivate via BlockAdditionMapping (by mbunkus) https://github.com/cellar-wg/matroska-specification/pull/388=20 5 pull requests received 18 new comments: - #392 Fixes for website migration (4 by mbunkus, robUx4) https://github.com/cellar-wg/matroska-specification/pull/392 [website] = - #390 Add AVC and HEVC codec mappings with BlockAdditionMapping 2 (2 by = JeromeMartinez) https://github.com/cellar-wg/matroska-specification/pull/390=20 - #388 allow extensions to CodecPrivate via BlockAdditionMapping (1 by mb= unkus) https://github.com/cellar-wg/matroska-specification/pull/388=20 - #342 Start new Chapters (5 by hubblec4, robUx4) https://github.com/cellar-wg/matroska-specification/pull/342 [clarifica= tions] [enhancement] [spec_main]=20 - #158 Adjust definition of "forced" and "default" flags to better reflec= t usage (6 by mbunkus, rcombs, robUx4) https://github.com/cellar-wg/matroska-specification/pull/158 [clarifica= tions] [spec_main]=20 1 pull requests merged: - support `rationale` and `references` documentation in the website table https://github.com/cellar-wg/matroska-specification/pull/387 [website] = * cellar-wg/ebml-specification (+1/-0/=F0=9F=92=AC5) 1 pull requests submitted: - Documentation definition fixes (by dericed) https://github.com/cellar-wg/ebml-specification/pull/340=20 1 pull requests received 5 new comments: - #339 add a more in-depth definition of an enum value (5 by dericed, rob= Ux4) 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 --===============3598334572083878954== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

    Sunday May 31, 2020

    Events without label "editorial"

    Issues

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

    1 issues created:

    6 issues received 32 new comments:

    1 issues closed: