From nobody Tue Nov 1 01:29:47 2016 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 5EE781294E0 for ; Tue, 1 Nov 2016 01:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 EJG5P4-ZMEHO for ; Tue, 1 Nov 2016 01:29:45 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 1EE20126FDC for ; Tue, 1 Nov 2016 01:29:45 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l124so26071276ywb.3 for ; Tue, 01 Nov 2016 01:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=wgtu5pcE0hCEQtVKoAhyQ7uAEr+mLir9nImT+j8KUSM=; b=X/+6Zu26pw5kGGhnIMfa3jxkmNKe2Lhjnhq57tYZl8ATyPlvZTUoolTmvUEtYdZq4x Ps8ph931RFf2BjjkgHGOoVPmHNDzkUS6E6cn4d9kr2zeRGD5PMlhgBW/EFKrTi38g2Jw NisB7yANpU2TgxOhAamSNCPqTdz7XvOnT3UPvv0l1UQCB8Cctw+fcieBfM3wy8yMZ0lP JHbFY51r9VX5OV1bMRiccgHr/CmR2VitZCehgXgXKxHOMlzdXBYYNBq+zCXdzQPPznRy 0ZiVpTTuWHR6Oy0hymELJqAfij0Gm2hdrxK0LZIqdcIIjAiE8fNYtTXLxDwL1C16O4A3 C4rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wgtu5pcE0hCEQtVKoAhyQ7uAEr+mLir9nImT+j8KUSM=; b=DwyUTY7HT3h9bCcTCK0bDiylh6BN/LHhZKaE4UP8ViT38JMiDfDxDxjHajwkTDfS6f M/kmgJWeBbcISWJsJgYakZcrtNDKRlyhaqMwBlSSYPeH2QBFFDkUb98I/rdsAkn9axNk hfpntV0Y4LX/GpzGaru5PlqDkK2BUNoFscts3jc4sYwov8YAN0J4VTkd9I7ulAQWRAs/ CJv5kvJYHoaNb//HtKOqpL6rzHQkhjesohog9OgKyun9LRRNhZb1QBqSKQpiv9aCXOPN JsK0XQepnKFCUM6/w/iLh1A+ZHmHhcT2FiKplgM9zQk+VR+LN5H649BFXrMqXEuFQlvw M2aw== X-Gm-Message-State: ABUngvf6rMym791E0MAsqib5P/Miz7v6irz1J7pPaDicxenAOGb3HYrRYgOEAt26+lxSf35Kv1ypfRTEE9TdtQ== X-Received: by 10.129.53.139 with SMTP id c133mr20447684ywa.70.1477988984115; Tue, 01 Nov 2016 01:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Tue, 1 Nov 2016 01:29:43 -0700 (PDT) From: Steve Lhomme Date: Tue, 1 Nov 2016 09:29:43 +0100 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] Unknown Size Element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Nov 2016 08:29:46 -0000 So far the Unknown Size element didn't require its parent to have an unknown size. I propose that all parents of such an element must also have an unknown size. If it's known later it's better to update the children elements that have their boundaries known too. That's also a way to restrict unknown size usage to case where we can't do without. https://github.com/Matroska-Org/ebml-specification/pull/125 -- Steve Lhomme Matroska association Chairman From nobody Tue Nov 1 05:37:22 2016 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 515081296C5 for ; Tue, 1 Nov 2016 05:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dktDUK-VCl0M for ; Tue, 1 Nov 2016 05:37:19 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 8FB891296C4 for ; Tue, 1 Nov 2016 05:37:19 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l124so32815910ywb.3 for ; Tue, 01 Nov 2016 05:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LcA/4PgYAvf8VRwdb8NWWvmZuFOfLpkNjxkTijwCbf0=; b=LW8lXjFHZw3O0ypVPLdHWsdgGzqy2Fd3tgCTSB+cz8zJVTGEA6P8ftp8HBn9Y5M4YE uWa/HcnyfeOHMbzLHad6ePmhJ+jEtRQKxkD6B8hiDB91251uK2MQ5cjdE3Xh4m0iaz6P lsn3xOLE4TbF6vHfgTMR0/PR9ZqAaf73354Rp3WpdSvjkPJ8tL9FZp5P+w6mSsgGyMPk qJ9ZYh57PASshBfUChMSRyzg+E3RtUMwQ3IyvCWgSTEC1iKs8qr5N0817p1AZgtc2Xkt HUEE/T3ZXoxQ9iTXFFM3E45dMOqiaHShIA7G+8puf8//oDC+JVtr9Z/Q+whvcfdqlMhC V60Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LcA/4PgYAvf8VRwdb8NWWvmZuFOfLpkNjxkTijwCbf0=; b=nNhw50SrWPeFXrfljUWnGAiy1fOmGIICojJqEEzYTXH8mjPXoG6cZzxFQ+ZYXQRU3M f1cFLWR86avmnddEoSBeSp7pTltLh0K+ayCQw2uqmz6TPbYXHq05YBXAGb69I6jNI7k/ SQ7nAH03Y8bZU/bRbYVGlq5bioYeZhhFmZ/ZtqtaT5cFnD/bwAf7GynEIRq9h3bb2maS zyIl33SFZW0s/UpXnvjl+C9EnZNC7qGwiPIPxAdrnUggnynbJyfzdbzCCEQuIC/miLzR wDbwlikVny2jvjOXHdLhzv5EsEeSq3Oa/B63C5XoJwaJvMVP8YNemzaEdnRfGNaGHD7M QXpw== X-Gm-Message-State: ABUngvfGdLPhgUqfstZswlRDkbQsGlVflASwmUYXQyIAqOlBL9q/TNSFcfBJ/NPCALnKC+1CXccNZCwaLkno0EDc X-Received: by 10.36.208.209 with SMTP id m200mr788206itg.49.1478003838555; Tue, 01 Nov 2016 05:37:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.197 with HTTP; Tue, 1 Nov 2016 05:37:17 -0700 (PDT) In-Reply-To: References: From: Michael Bradshaw Date: Tue, 1 Nov 2016 05:37:17 -0700 Message-ID: To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a1149e1e2c6614d05403c9592 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Unknown Size Element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 01 Nov 2016 12:37:21 -0000 --001a1149e1e2c6614d05403c9592 Content-Type: text/plain; charset=UTF-8 I'm in favor of this change. Note that even with this wording change, it's still permitted to create a parent element with a known size and the child element with an unknown size within a particular file. I think prohibiting that too would be nice. It would have simplified the WebM parser I wrote. On Tuesday, November 1, 2016, Steve Lhomme wrote: > So far the Unknown Size element didn't require its parent to have an > unknown size. > > I propose that all parents of such an element must also have an > unknown size. If it's known later it's better to update the children > elements that have their boundaries known too. That's also a way to > restrict unknown size usage to case where we can't do without. > > https://github.com/Matroska-Org/ebml-specification/pull/125 > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a1149e1e2c6614d05403c9592 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm in favor of this change. Note that even with this wording change, i= t's still permitted to create a parent element with a known size and th= e child element with an unknown size within a particular file. I think proh= ibiting that too would be nice. It would have simplified the WebM parser I = wrote.

On Tuesday, November 1, 2016, Steve Lhomme <<= a href=3D"mailto:slhomme@matroska.org">slhomme@matroska.org> wrote:<= br>
So far the Unknown Size element didn'= t require its parent to have an
unknown size.

I propose that all parents of such an element must also have an
unknown size. If it's known later it's better to update the childre= n
elements that have their boundaries known too. That's also a way to
restrict unknown size usage to case where we can't do without.

https://github.com/Matroska-Org/ebml-specification/pull= /125

--
Steve Lhomme
Matroska association Chairman

_______________________________________________
Cellar mailing list
Cellar@ietf.org
= https://www.ietf.org/mailman/listinfo/cellar
--001a1149e1e2c6614d05403c9592-- From nobody Tue Nov 1 17:57:11 2016 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 7016F129438 for ; Tue, 1 Nov 2016 17:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KruUD_5qP0uE for ; Tue, 1 Nov 2016 17:57:06 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 CC02D127078 for ; Tue, 1 Nov 2016 17:57:05 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id q124so7313697itd.1 for ; Tue, 01 Nov 2016 17:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YSSpU3mqL4dK5c3akhTEJNLp7395O9lekyoIn6MUZAs=; b=SeO0goX6qvcOx1zP/chDa2djWWfq2TTrei4H3sITgoSGsKHZI15qAKBjTb8IcVTdPZ NHaN9s09p1liN9LUNEpHA5LcWVfxaPOJYN+iMFIkZ3HuG6QIivPO3IBuFEoNrBS1xrno OCeHhaFUVSr4dLGOcPyzk80aQEMvU47+bJjWJ//l6clWZhQTbIOYyTtGl4S6jzE5FciR a1WNV5+w9BANya3OeTJfHGcyLIAsFtnNC1FtowZLUCfISv5XC8BOxr910DWns58lSWRg w0lvtKXmn+mqQAcGphWWPOQ6ipJArWiAGE4wiSEW+UyHaIduNpSlUThDXOScXHSGnFPJ 75ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YSSpU3mqL4dK5c3akhTEJNLp7395O9lekyoIn6MUZAs=; b=FRUeloGaXNvfUQTe5CssPVMoHlf9xMycKkSTMC2fJ9u8J88NOkFiIzQofEMzB0bWoc 1hmaBb0XngWUco7/KEHSEX1Ja/9NtE5+3rx/a1OTOw818WAs7r8QuA50C6Th/1cRL/ia np5n7R7v3vXRfLQEpS+jh1gb7jVzHmiuTVgGpPXhOfQo7zSpkZqrS+qMJ7K+aKxVThGI 3vDktDJky0ZV5gGej4owBfT1qLTUzQkkEtzXwVjHGoBiiG1THXeCwlGUx9CgBMf3hGax b9UiqPNdQhgSoayX8ZOkaZ2JiinADuEc7Tr1v0TrbZf/rqw4qZ8MeXf+rYOHy+PWw7Wv FpWA== X-Gm-Message-State: ABUngveJdXM6iOZpC1Lse6O5oNfQjyZNJ07AdNb52jYKUPh7jgJ6Vnf4hF22A0VnRzSZ0bJnxTQihe1luzgzzQ== X-Received: by 10.36.225.135 with SMTP id n129mr635309ith.56.1478048224939; Tue, 01 Nov 2016 17:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.132 with HTTP; Tue, 1 Nov 2016 17:57:04 -0700 (PDT) In-Reply-To: <3BB8346D-3BA7-4CE3-B8BB-691903B7A52E@dericed.com> References: <3BB8346D-3BA7-4CE3-B8BB-691903B7A52E@dericed.com> From: Ashley Blewer Date: Tue, 1 Nov 2016 20:57:04 -0400 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=94eb2c19d4626896dc054046ebf5 Archived-At: Cc: Ethan T Gates , cellar@ietf.org Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 00:57:09 -0000 --94eb2c19d4626896dc054046ebf5 Content-Type: text/plain; charset=UTF-8 This is a great list of beginner fixes for the specifications, thanks so much Dave for putting it together. I just assigned myself to the last linked issue, matroska-46, in Github and will get cracking on it. If anyone else out there needs help getting started, don't hesitate to reach out to me! Happy to spend as much time as necessary explaining Github or open source pull request patterns. Ashley On Tue, Oct 18, 2016 at 12:57 PM, Dave Rice wrote: > Hi Ethan and others, > > Thanks for this message. In regards to how people can contribute, we've > been trying to file tickets in the associated repositories and these vary > from very easy to complex. I'd suggest that if you'd like contribute but > feel the need for support, please feel welcome to ask for a mentor. > > Here's a highlight of some of the more approachable issues: > > https://github.com/Matroska-Org/ebml-specification/issues/117 > This is basically just a find/replace to correct a misspelling of > "Occurence" with "Occurrence", mostly in this section: https://github.com/ > Matroska-Org/ebml-specification/blob/master/specification.markdown#path. > > https://github.com/Matroska-Org/matroska-specification/issues/48 > This issue is resolved basically by removing https://github.com/ > Matroska-Org/matroska-specification/blob/gh-pages/overhead.md from the > matroska-specification repo as the discussion suggests that it should not > be part of the specification. > > https://github.com/Matroska-Org/matroska-specification/issues/50 > This calls for some sections to be reviewed against the EBML specification > to ensure that they are redundant and then remove the identified redundant > sections from the Matroska specification. > > https://github.com/Matroska-Org/ebml-specification/issues/114 > This requires some XML knowledge, but this is a recommendation that > enumeration lists be moved from an informal "(1: option A, 2: option > B)"-style structure. A example of the current enumeration list is here: > https://github.com/Matroska-Org/matroska-specification/blob/ > 2c0a14d3e0117175c1bf224c7be6496eedb28541/ebml_matroska.xml#L195. So this > issue is two part, first propose a new structure, then once accepted adjust > ebml_matroska.xml to use it. > > https://github.com/Matroska-Org/matroska-specification/issues/49 > This relates to the metadata documenation at https://github.com/ > Matroska-Org/matroska-specification/blob/gh-pages/tagging.md. Moritz has > noted the meaning of tag names prefixed by underscores at > https://github.com/Matroska-Org/matroska-specification/issues/49# > issuecomment-254039146, so a section should be added to tagging.md to > explain the meaning of tag names prefixed by underscores and what they > imply and what a Reader should do with them. > > https://github.com/Matroska-Org/matroska-specification/issues/46 > This involves cleaning up Matroska's method for defining how to define > codecs in Matroska. There's a markdown table that needs to be cleaned up > and the structure of codec definitions themselves needs to be documented > (such as the name style of Codec IDs, what information is needed in a > description). > > If you'd like to take a particular issue please note so in the Github > issue tracker and feel welcome to ask any clarifying questions or request a > mentor there so that we can assign both to the issue. Thanks much, > > Dave Rice > > On Oct 9, 2016, at 9:48 AM, Ethan T Gates wrote: > > Hi all, > > Another novice lurker here - I second Brendan's thanks to you all for both > the content and admirable form of this process and Genevieve's desire to > observe and soak up as much as I can, as I've been doing by poring over > these threads. I would love to attend a NYC meeting, could make weekends > work, and might humbly suggest a quick word about how exactly newbies or > those without much or any experience with programming or metadata > standardization can contribute! (provision of sample files? copy editing > documentation?) You all have been doing a stellar job of getting CELLAR's > mission out into the wider archival community lately and I think interest > in participation is only going to keep growing. > > Best, > Ethan Gates > > On Sat, Oct 8, 2016 at 7:01 PM, Genevieve HK wrote: > >> 1. Yes! >> 2. weekends are doable >> 3. +1 metadata (but I generally would just be attending to listen & learn >> more about *everything*) >> >> Thanks for planning this! >> >> >> On Sat, Oct 8, 2016 at 3:00 PM, wrote: >> >>> Send Cellar mailing list submissions to >>> cellar@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/cellar >>> or, via email, send a message with subject or body 'help' to >>> cellar-request@ietf.org >>> >>> You can reach the person managing the list at >>> cellar-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Cellar digest..." >>> >>> Today's Topics: >>> >>> 1. Re: NYC cellar meetup? (ashley.blewer@gmail.com) >>> 2. Re: NYC cellar meetup? (Murray, Kate) >>> 3. Re: NYC cellar meetup? (Doug Ewell) >>> 4. Re: NYC cellar meetup? (Reto Kromer) >>> 5. Re: NYC cellar meetup? (Brendan Allen) >>> >>> >>> ---------- Forwarded message ---------- >>> From: ashley.blewer@gmail.com >>> To: Dave Rice >>> Cc: cellar@ietf.org >>> Date: Fri, 7 Oct 2016 21:13:10 +0200 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> >>> >>> > On Oct 7, 2016, at 8:52 PM, Dave Rice wrote: >>> > >>> > Hi all, >>> > >>> > There's been some offlist discussion about having a meetup in New York >>> City on cellar issues (quite a few New Yorkers on the list). In general I >>> think the agenda could be informal but address things like: discussion of >>> open issues, how to contribute, planning upcoming work, collaboration. >>> > >>> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >>> York Public Library. >>> > >>> > So some questions for the group: >>> > >>> > 1. Is such a meeting of interest? >>> > >>> Yes! >>> >>> > 2. Should it occur during an evening or the weekend? An evening may be >>> easier to local folks to coordinate but would be too late for most remote >>> participation from Europe. >>> > >>> Also prefer evenings but more so prefer potential Euro participation! >>> >>> > 3. Recommendations for agenda items, things you'd like to learn, >>> things you'd like to see done? >>> >>> FLAC attack. >>> >>> >>> > Dave Rice >>> > _______________________________________________ >>> > Cellar mailing list >>> > Cellar@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cellar >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Murray, Kate" >>> To: "'cellar@ietf.org'" >>> Cc: >>> Date: Fri, 7 Oct 2016 15:16:30 -0400 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Thanks for this Dave. I'm game to (virtually) meet up with other >>> interested folks if scheduling permits. >>> >>> Best from Kate >>> ********** >>> Kate Murray >>> Technology Policy Directorate >>> Library of Congress >>> 202-707-4894 >>> kmur@loc.gov >>> >>> >>> >>> -----Original Message----- >>> From: Dave Rice [mailto:dave@dericed.com] >>> Sent: Friday, October 07, 2016 2:53 PM >>> To: cellar@ietf.org >>> Subject: [Cellar] NYC cellar meetup? >>> >>> Hi all, >>> >>> There's been some offlist discussion about having a meetup in New York >>> City on cellar issues (quite a few New Yorkers on the list). In general I >>> think the agenda could be informal but address things like: discussion of >>> open issues, how to contribute, planning upcoming work, collaboration. >>> >>> Nick Krabbenhoeft has offered to arrange for a meeting space at New York >>> Public Library. >>> >>> So some questions for the group: >>> >>> 1. Is such a meeting of interest? >>> >>> 2. Should it occur during an evening or the weekend? An evening may be >>> easier to local folks to coordinate but would be too late for most remote >>> participation from Europe. >>> >>> 3. Recommendations for agenda items, things you'd like to learn, things >>> you'd like to see done? >>> >>> Dave Rice >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Doug Ewell >>> To: cellar@ietf.org >>> Cc: >>> Date: Fri, 07 Oct 2016 15:45:05 -0700 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Dave Rice wrote: >>> >>> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >>> > York Public Library. >>> >>> That's rather a distance from Colorado, so rather than making the trek, >>> I'll just repeat my request that BCP 47 be adopted as the >>> language-tagging standard instead of (or at least in strong preference >>> to) the existing approach which combines ISO 639-2/B with ccTLDs. >>> >>> -- >>> Doug Ewell | Thornton, CO, US | ewellic.org >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Reto Kromer >>> To: cellar@ietf.org >>> Cc: >>> Date: Sat, 8 Oct 2016 07:05:28 +0200 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Dave Rice wrote: >>> >>> >1. Is such a meeting of interest? >>> >>> Indeed. >>> >>> >2. Should it occur during an evening or the weekend? An >>> >evening may be easier to local folks to coordinate but >>> >would be too late for most remote participation from >>> >Europe. >>> >>> A schedule permitting remote participation from Europe would >>> be ideal. >>> >>> >3. Recommendations for agenda items, things you'd like to >>> >learn, things you'd like to see done? >>> >>> Clear metadata embedding in Matroska, in order to maintain >>> the relevant information about the RGB flavour encoded by >>> FFV1. This would facilitate the native implementations into >>> the current cutting, grading, restoration, etc. softwares. >>> And, therefore, advocating for adoption. >>> >>> +1 FLAC >>> >>> Best regards, Reto >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Brendan Allen >>> To: Reto Kromer >>> Cc: "cellar@ietf.org" >>> Date: Sat, 8 Oct 2016 12:06:24 -0400 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Hi everyone, >>> I've been lurking on this thread for awhile trying to follow. I'd like >>> to say thanks to all of you for the work you're doing to standardize these >>> formats. Also, its pretty cool how open, inclusive and transparent this >>> process is. >>> I live in nyc and could meet-up at the library. My interests are in >>> embedded metadata and FLAC >>> >>> kind regards, >>> Brendan Allen >>> >>> Sent from my iPhone >>> >>> > On Oct 8, 2016, at 1:05 AM, Reto Kromer wrote: >>> > >>> > Dave Rice wrote: >>> > >>> >> 1. Is such a meeting of interest? >>> > >>> > Indeed. >>> > >>> >> 2. Should it occur during an evening or the weekend? An >>> >> evening may be easier to local folks to coordinate but >>> >> would be too late for most remote participation from >>> >> Europe. >>> > >>> > A schedule permitting remote participation from Europe would >>> > be ideal. >>> > >>> >> 3. Recommendations for agenda items, things you'd like to >>> >> learn, things you'd like to see done? >>> > >>> > Clear metadata embedding in Matroska, in order to maintain >>> > the relevant information about the RGB flavour encoded by >>> > FFV1. This would facilitate the native implementations into >>> > the current cutting, grading, restoration, etc. softwares. >>> > And, therefore, advocating for adoption. >>> > >>> > +1 FLAC >>> > >>> > Best regards, Reto >>> > >>> > _______________________________________________ >>> > Cellar mailing list >>> > Cellar@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cellar >>> >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>> >>> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > > > -- > Ethan Gates > Moving Image Archiving and Preservation Technician > Department of Cinema Studies, MIAP > New York University > 665 Broadway, Room 613 > New York, NY 10012 > 212-998-1732 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --94eb2c19d4626896dc054046ebf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a great list of beginner fixes for the specificati= ons, thanks so much Dave for putting it together. I just assigned myself to= the last linked issue, matroska-46, in Github and will get cracking on it.=

If anyone else out there needs help getting started, do= n't hesitate to reach out to me! Happy to spend as much time as necessa= ry explaining Github or open source pull request patterns.

Ashley

On Tue, Oct 18, 2016 at 12:57 PM, Dave Rice <dave@dericed.com= > wrote:
Hi Ethan and others,

Thanks= for this message. In regards to how people can contribute, we've been = trying to file tickets in the associated repositories and these vary from v= ery easy to complex. I'd suggest that if you'd like contribute but = feel the need for support, please feel welcome to ask for a mentor.

Here's a highlight of some of the more approachable i= ssues:

This is basical= ly just a find/replace to correct a misspelling of "Occurence" wi= th "Occurrence", mostly in this section:=C2=A0https://github.com/Matroska-Org/ebml-s= pecification/blob/master/specification.markdown#path.
This issue is resolved basic= ally by removing=C2=A0https://github.co= m/Matroska-Org/matroska-specification/blob/gh-pages/overhead= .md=C2=A0from the matroska-specification repo as the discussion suggest= s that it should not be part of the specification.

https://github.com/Matroska-Org/matroska-specific= ation/issues/50
This calls for some sections to be revie= wed against the EBML specification to ensure that they are redundant and th= en remove the identified redundant sections from the Matroska specification= .

This requires some X= ML knowledge, but this is a recommendation that enumeration lists be moved = from an informal "(1: option A, 2: option B)"-style structure. A = example of the current enumeration list is here:=C2=A0https://github.co= m/Matroska-Org/matroska-specification/blob/2c0a14d3e0117175c= 1bf224c7be6496eedb28541/ebml_matroska.xml#L195. So this issue= is two part, first propose a new structure, then once accepted adjust ebml= _matroska.xml to use it.

https= ://github.com/Matroska-Org/matroska-specification/issues/49
This relates to the metadata documenation at=C2=A0https://github.com/Matroska-Org/matroska-speci= fication/blob/gh-pages/tagging.md. Moritz has noted the meaning of= tag names prefixed by underscores at=C2=A0https://github.com/Matroska-Org/matroska-specificatio= n/issues/49#issuecomment-254039146, so a section should be added t= o tagging.md to explain= the meaning of tag names prefixed by underscores and what they imply and w= hat a Reader should do with them.

This involves cleaning up Matroska's method for defin= ing how to define codecs in Matroska. There's a markdown table that nee= ds to be cleaned up and the structure of codec definitions themselves needs= to be documented (such as the name style of Codec IDs, what information is= needed in a description).

If you'd like to ta= ke a particular issue please note so in the Github issue tracker and feel w= elcome to ask any clarifying questions or request a mentor there so that we= can assign both to the issue. Thanks much,

Dave R= ice

On = Oct 9, 2016, at 9:48 AM, Ethan T Gates <ethan.gates@nyu.edu> wrote:

H= i all,

Another novice lurker here - I second Brendan's thanks to= you all for both the content and admirable form of this process and Genevi= eve's desire to observe and soak up as much as I can, as I've been = doing by poring over these threads. I would love to attend a NYC meeting, c= ould make weekends work, and might humbly suggest a quick word about how ex= actly newbies or those without much or any experience with programming or m= etadata standardization can contribute! (provision of sample files? copy ed= iting documentation?) You all have been doing a stellar job of getting CELL= AR's mission out into the wider archival community lately and I think i= nterest in participation is only going to keep growing.

Best,
Ethan Gates

On Sat, Oct 8, 2016 at 7:01 PM, Genevieve HK <gen.fhk@gma= il.com> wrote:
1. Yes!
2. weekends are doable
3. +1= metadata (but I generally would just be attending to listen & learn mo= re about *everything*)

Thanks for planning this!

=

On Sat, Oct 8, 2016 at 3:00 PM, <cellar-request@ietf.org>= wrote:
Send Cellar mailing list s= ubmissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/cellar
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cellar digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: NYC cellar meetup? (ashley.blewer@gmail.com)
=C2=A0 =C2=A02. Re: NYC cellar meetup? (Murray, Kate)
=C2=A0 =C2=A03. Re: NYC cellar meetup? (Doug Ewell)
=C2=A0 =C2=A04. Re: NYC cellar meetup? (Reto Kromer)
=C2=A0 =C2=A05. Re: NYC cellar meetup? (Brendan Allen)


---------- Forwarded message ----------
From:=C2=A0ashley.blewer@gmail.com=
To:=C2=A0Dave Rice <dave@dericed.com>
Cc:=C2=A0cellar@ietf.org
Date:=C2=A0Fri, 7 Oct 2016 21:1= 3:10 +0200
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?


> On Oct 7, 2016, at 8:52 PM, Dave Rice <dave@dericed.com> wrote:
>
 > Hi all,
>
> There's been some offlist discussion about having a meetup in New = York City on cellar issues (quite a few New Yorkers on the list). In genera= l I think the agenda could be informal but address things like: discussion = of open issues, how to contribute, planning upcoming work, collaboration. >
 > Nick Krabbenhoeft has offered to arrange for a meeting space at New Yo= rk Public Library.
>
 > So some questions for the group:
>
 > 1. Is such a meeting of interest?
>
 Yes!

> 2. Should it occur during an evening or the weekend? An evening may be= easier to local folks to coordinate but would be too late for most remote = participation from Europe.
>
 Also prefer evenings but more so prefer potential Euro participation!

 > 3. Recommendations for agenda items, things you'd like to learn, t= hings you'd like to see done?

 FLAC attack.


> Dave Rice
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar




---------- Forwarded message ----------
From:=C2=A0= "Murray, Kate" <kmur@loc.gov>
To:=C2=A0"'cellar@ietf.org'" <cellar@ietf.org>
Cc:=C2=A0=
Date:=C2=A0Fri, 7 Oct 2016 15:16:30 -0400
Subject:=C2=A0Re: [Cellar]= NYC cellar meetup?
Thanks for this Dave. I'm game to (virtually) me= et up with other interested folks if scheduling permits.

Best from Kate
**********
Kate Murray
Technology Policy Directorate
Library of Congress
202-7= 07-4894
kmur@loc.gov



-----Original Message-----
From: Dave Rice [mailto:dave@dericed.com]
Sent: Friday, October 07, 2016 2:53 PM
To: cellar@ietf.org
Subject: [Cellar] NYC cellar meetup?

Hi all,

There's been some offlist discussion about having a meetup in New York = City on cellar issues (quite a few New Yorkers on the list). In general I t= hink the agenda could be informal but address things like: discussion of op= en issues, how to contribute, planning upcoming work, collaboration.

Nick Krabbenhoeft has offered to arrange for a meeting space at New York Pu= blic Library.

 So some questions for the group:

 1. Is such a meeting of interest?

 2. Should it occur during an evening or the weekend? An evening may be easi= er to local folks to coordinate but would be too late for most remote parti= cipation from Europe.

 3. Recommendations for agenda items, things you'd like to learn, things= you'd like to see done?

 Dave Rice




---------- Forwarded message ----------
From:=C2=A0Doug Ewell &l= t;doug@ewellic.org>
To:=C2=A0cell= ar@ietf.org
Cc:=C2=A0
Date:=C2=A0Fri, 07 Oct 2016 15:45:05 -0700<= br>Subject:=C2=A0Re: [Cellar] NYC cellar meetup?
Dave Rice wrote:

> Nick Krabbenhoeft has offered to arrange for a meeting space at New > York Public Library.

That's rather a distance from Colorado, so rather than making the trek,=
I'll just repeat my request that BCP 47 be adopted as the
language-tagging standard instead of (or at least in strong preference
to) the existing approach which combines ISO 639-2/B with ccTLDs.

--
Doug Ewell | Thornton, CO, US | ewellic.org



---------- Forwarded message ----------
From:=C2=A0= Reto Kromer <lists@re= to.ch>
To:=C2=A0cellar@ietf.org
Cc:=C2=A0
Date:=C2=A0Sat, 8 Oct 2016 07:05:2= 8 +0200
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?
Dave Rice wrote= :

>1. Is such a meeting of interest?

Indeed.

>2. Should it occur during an evening or the weekend? An
>evening may be easier to local folks to coordinate but
>would be too late for most remote participation from
>Europe.

A schedule permitting remote participation from Europe would
be ideal.

>3. Recommendations for agenda items, things you'd like to
>learn, things you'd like to see done?

Clear metadata embedding in Matroska, in order to maintain
the relevant information about the RGB flavour encoded by
FFV1. This would facilitate the native implementations into
the current cutting, grading, restoration, etc. softwares.
And, therefore, advocating for adoption.

+1 FLAC

Best regards, Reto




---------- Forwa= rded message ----------
From:=C2=A0Brendan Allen <brendanallen.ba@gmail.com&g= t;
To:=C2=A0Reto Kromer <lists@reto.ch>
Cc:=C2=A0"cellar@ietf.org" <cellar@ietf.org>
Date:=C2=A0Sat,= 8 Oct 2016 12:06:24 -0400
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?=
Hi everyone,
I've been lurking on this thread for awhile trying to follow. I'd l= ike to say thanks to all of you for the work you're doing to standardiz= e these formats. Also, its pretty cool how open, inclusive and transparent = this process is.
I live in nyc and could meet-up at the library. My interests are in embedde= d metadata and FLAC

kind regards,
Brendan Allen

Sent from my iPhone

> On Oct 8, 2016, at 1:05 AM, Reto Kromer <lists@reto.ch> wrote:
>
> Dave Rice wrote:
>
>> 1. Is such a meeting of interest?
>
> Indeed.
>
>> 2. Should it occur during an evening or the weekend? An
>> evening may be easier to local folks to coordinate but
>> would be too late for most remote participation from
>> Europe.
>
> A schedule permitting remote participation from Europe would
> be ideal.
>
>> 3. Recommendations for agenda items, things you'd like to
>> learn, things you'd like to see done?
>
> Clear metadata embedding in Matroska, in order to maintain
> the relevant information about the RGB flavour encoded by
> FFV1. This would facilitate the native implementations into
> the current cutting, grading, restoration, etc. softwares.
> And, therefore, advocating for adoption.
>
> +1 FLAC
>
> Best regards, Reto
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar

=

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar



--
Ethan Gates
Moving Image Archiving and= Preservation Technician
Department of Cinema Studies, MIAP
New York = University
665 Broadway, Room 613
New York, NY 10012
_______________________________________________
Cellar mailing list=
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar


________________________________= _______________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--94eb2c19d4626896dc054046ebf5-- From nobody Tue Nov 1 19:49:10 2016 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 5286512997F for ; Tue, 1 Nov 2016 19:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vIH9BnzKZbjM for ; Tue, 1 Nov 2016 19:49:07 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBF212946F for ; Tue, 1 Nov 2016 19:49:07 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id m138so63321529itm.1 for ; Tue, 01 Nov 2016 19:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=45ZoGkdY/CeHOnw2w6S9wlGHfoUxibxAwqk+REtmRac=; b=k/e6MROfXaKhCNPu9Q0va2V7wrgmo9vdR2MCUlz2RSfO14aboiJpTJ3zigEGht0SAP 20DzBrtNkbMhbO5W8WE4GUPo2RXwqeWDV78foZDDZ7E94EOmWBNxby0JAXP0ToBHCm+x EDLbfNdRt1CyKKNk+gcXH3pDPny5z3ubA4ynPKnyQJyBn2SlV46Er0NJrVSRrVWxOioh u1+Kz3EhWqa+bxdrKOkpXThgT6o6QqD6I5Zf7lkkOlswy/94edun3A6jTkCRmyUUG818 fZd+WgGWJmuI0cIPn/kdsW/3hVCmNZzMz0QsC2P1JjuxVCJZM6d4JsahIJHemV9tUnqP /cuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=45ZoGkdY/CeHOnw2w6S9wlGHfoUxibxAwqk+REtmRac=; b=IMYw4P816vKLmVukn/Vd0ka82pm2BHAcwmGfsbdiS+HA22VCkK4+YTR3HfQX3Xfk/c 35HKdJc6tS6A/IGdtlwE/YeP1NkT2Y3eJeIlBP6taQbZnDuAzmG93GXIAD+ucGlymzi0 zQ9zDW6Ja5NTNKGHmVB/FN2Zz4aviXD/0iqS9Gn0nMXuOk0NWtTYK9oNsfeLPmZkpbSW i31z96nhDpPUjega8NbQLsjZYLjeQqmTSAT0cw4O0BYXgF/Y7TWNzuMu8CQbSmJfmV3x +JMOsE2Yw6SV1NMHCGCfjbIVMn2n7Pfcp1SJoKHE8UGj7DL+GS276+W/ram1UltxBYrF a1cA== X-Gm-Message-State: ABUngveGoh3MKYdpQrqb62MoNevwBFYK2L8+BYNuvCK1UFl9lHG0jlQjam1yoqHmOVyZJK2uCneD13LvzrauBA== X-Received: by 10.107.136.229 with SMTP id s98mr1834293ioi.171.1478054946877; Tue, 01 Nov 2016 19:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.132 with HTTP; Tue, 1 Nov 2016 19:49:06 -0700 (PDT) From: Ashley Blewer Date: Tue, 1 Nov 2016 22:49:06 -0400 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a113ed55c1137b70540487cf5 Archived-At: Subject: [Cellar] Cleaning up the Codec Specs section of the Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 02:49:09 -0000 --001a113ed55c1137b70540487cf5 Content-Type: text/plain; charset=UTF-8 Hello! I just opened this pull request on matroska-specification, here: https://github.com/Matroska-Org/matroska-specification/pull/66 With the following sentiment... "Hello! This pull request seeks, primarily, to break the approved codecs out of their occasionally-hierarchical table and into more simple charting for better viewing in Markdown, HTML, and (most importantly) RFC text. This pull request does NOT attempt to make assertions about the codecs or their descriptions, which will need to be reviewed by people with a stronger historical knowledge." So, like I said in the comment, the descriptions, and maybe the codecs existing or not, need a lot of refinements that I can't solely work on, so any help is appreciated. I think this above pull request should be (commented/modified) and merged based on structural changes only, and then we can proceed to refactor the content at a more granular level. Is there redundant information? Are there codecs that should be eliminated from the list? Has a codec been modified? Should a CodecPrivate element be defined, or must it? Thanks! Ashley --001a113ed55c1137b70540487cf5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello! I just opened this pull request on matroska-specifi= cation, here: https://github.com/Matroska-Org/matroska-specification/pull/6= 6

With the following sentiment...=C2=A0
"Hello! This pul= l request seeks, primarily, to break the approved codecs out of their occas= ionally-hierarchical table and into more simple charting for better viewing= in Markdown, HTML, and (most importantly) RFC text. This pull request does= NOT attempt to make assertions about the codecs or their descriptions, whi= ch will need to be reviewed by people with a stronger historical knowledge.= "

So, like I said in the comment, the descriptions,= and maybe the codecs existing or not, need a lot of refinements that I can= 't solely work on, so any help is appreciated.

I think this above pull request should be (commented/modified) and merged = based on structural changes only, and then we can proceed to refactor the c= ontent at a more granular level. Is there redundant information? Are there = codecs that should be eliminated from the list? Has a codec been modified? = Should a CodecPrivate element be defined, or must it?

<= div>Thanks!

Ashley

--001a113ed55c1137b70540487cf5-- From nobody Wed Nov 2 11:57:36 2016 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 B2887129B59 for ; Wed, 2 Nov 2016 11:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QpUcgr94cJ3H for ; Wed, 2 Nov 2016 11:57:32 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 89B10129B54 for ; Wed, 2 Nov 2016 11:57:32 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t125so19654562ywc.1 for ; Wed, 02 Nov 2016 11:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CAJ9qfxXyu7SKL7Otzexw6GerYiIbBl8NjkqxGX8gnk=; b=cd5RVahGZ76KD4IHh3NQAvLyuy6F/6URIgcg/7iEGJB8sugxXjyKEKYV/Cjvwhp/qV asPwgrSkq5MrYzoag01Anl5vCClw9qyv9ZEiQU1D6qI4b/G+MQEQgBR/EkXsldItJq2S 25wrZDA6aftyyhB1tupL7a8O1VU98O738WUVRjBPdBy9sccAxuX9xIv5lTZ6M39UHmU4 ThY2PWganOZVjOqHCnDIe3rq+A6b21qEms/0WM3c75fmNf0DBm+Ap3nAfGYvfExhdxLF KDNQxcAlUvT5CIAMetUlrx3HXD0fCc3nKMaU9OMiFiVaQrk45tCgFO5Yuz0uXRoZieeR gHLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CAJ9qfxXyu7SKL7Otzexw6GerYiIbBl8NjkqxGX8gnk=; b=F7u3QE94nFG+RA6eMww/0zDHBQ0hDbcSsPlgGSqqyMnDPnfkGNAtEbXP2mG7wvqMQo wQQoF7cQDOObojdQVATkoXcfgFXEGZqXgTR63ySgC+mLB9+Hn33Jh9PYaWjF+eB38EfJ lVebzuVHrFq4PIRyoi1e7a2fkydDprMzhGVQaoMlHfeP4DQ+ZGfdL4YpWSR6xssg3yLd 08eR/wkgv1Vd+TnfANwZPus4CY+S51/YaT3jiDil5cSqrMC7n8lY+cPKNdlYuLk0tWdD iF2gqITq0eYcSkwlSIJbv2VEOHOd5jchGwhNd3Sxvk/KwO1b2mlGnrkskEZipDbCcNyf NGvg== X-Gm-Message-State: ABUngvfsxtrvYNy0nmzZ9RX/8hlXT481nRNqLb7yPHeoevJZWMVjmViuaozHiUnhEhnzSUG27AS8Yv1IBcMHmP27 X-Received: by 10.107.170.230 with SMTP id g99mr6267087ioj.111.1478113051714; Wed, 02 Nov 2016 11:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.35.197 with HTTP; Wed, 2 Nov 2016 11:57:11 -0700 (PDT) In-Reply-To: References: From: Michael Bradshaw Date: Wed, 2 Nov 2016 11:57:11 -0700 Message-ID: To: Ashley Blewer Content-Type: multipart/alternative; boundary=001a1142e6b06304ac0540560331 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Cleaning up the Codec Specs section of the Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 18:57:35 -0000 --001a1142e6b06304ac0540560331 Content-Type: text/plain; charset=UTF-8 Is there a particular Markdown renderer I should use to look at this? GitHub's rendering isn't very readable (granted, the original looked even worse on GitHub ). I think making the spec more readable is a good idea. On Tue, Nov 1, 2016 at 7:49 PM, Ashley Blewer wrote: > Hello! I just opened this pull request on matroska-specification, here: > https://github.com/Matroska-Org/matroska-specification/pull/66 > > With the following sentiment... > "Hello! This pull request seeks, primarily, to break the approved codecs > out of their occasionally-hierarchical table and into more simple charting > for better viewing in Markdown, HTML, and (most importantly) RFC text. This > pull request does NOT attempt to make assertions about the codecs or their > descriptions, which will need to be reviewed by people with a stronger > historical knowledge." > > So, like I said in the comment, the descriptions, and maybe the codecs > existing or not, need a lot of refinements that I can't solely work on, so > any help is appreciated. > > I think this above pull request should be (commented/modified) and merged > based on structural changes only, and then we can proceed to refactor the > content at a more granular level. Is there redundant information? Are there > codecs that should be eliminated from the list? Has a codec been modified? > Should a CodecPrivate element be defined, or must it? > > Thanks! > > Ashley > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a1142e6b06304ac0540560331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there a particular Markdown renderer I should use to lo= ok at this? GitHub's rend= ering isn't very readable=C2=A0(granted, the original looked even worse on GitHub). I= think making the spec more readable is a good idea.

On Tue, Nov 1, 2016 at 7:49 PM, As= hley Blewer <ashley.blewer@gmail.com> wrote:
Hello! I just opened this pull re= quest on matroska-specification, here: https://github.com= /Matroska-Org/matroska-specification/pull/66

With the = following sentiment...=C2=A0
"Hello! This pull request seeks, prima= rily, to break the approved codecs out of their occasionally-hierarchical t= able and into more simple charting for better viewing in Markdown, HTML, an= d (most importantly) RFC text. This pull request does NOT attempt to make a= ssertions about the codecs or their descriptions, which will need to be rev= iewed by people with a stronger historical knowledge."

<= div>So, like I said in the comment, the descriptions, and maybe the codecs = existing or not, need a lot of refinements that I can't solely work on,= so any help is appreciated.

I think this above pu= ll request should be (commented/modified) and merged based on structural ch= anges only, and then we can proceed to refactor the content at a more granu= lar level. Is there redundant information? Are there codecs that should be = eliminated from the list? Has a codec been modified? Should a CodecPrivate = element be defined, or must it?

Thanks!

Ashley


_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--001a1142e6b06304ac0540560331-- From nobody Wed Nov 2 12:02:16 2016 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 AF1ED129B5D for ; Wed, 2 Nov 2016 12:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Uj7rxcAScBrc for ; Wed, 2 Nov 2016 12:02:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4040B129B84 for ; Wed, 2 Nov 2016 12:01:40 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l124so19776404ywb.3 for ; Wed, 02 Nov 2016 12:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s3t9wGRpR/suAzCget5A4HhNK/N9Ql8aI9oHm48fY5k=; b=ILmLJQ3StWWylrhXi3ErqFY+N34vh27J7dqCSKh+THhmTlXm6l4p4zZPpD3i/zbOuV +IcKvG9nkXinWKWIHezrhDyHODXBC9ZEd9yTCtBsTu5Py19/Ms0DPhr82EbY7C6nO2MY OM43wAL6BrSgHgBzRnsS84wrmvSn48FIeMpsFWxp1mGkL1v1QII0q5v8z95Boiasx6ct lYPhm8HWmvgsLV0h4P5xq7vqHBMrJf5rNE7gtp+Dm8elrygCHXKAxKLcQFlHo8Qd8zFK P+eW8J6SQwS5ZRRGXmI8kNWPWhBBwUyW+iOzHWu1f4wpXypagL0jGz6D6nVeSW2NmCgk yI5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s3t9wGRpR/suAzCget5A4HhNK/N9Ql8aI9oHm48fY5k=; b=LJ0lgwshSwWtT3WWQYWgYQtIIaJcqo2xyiRaIvlKNaHHkKbdlaTM1iOgpdMzjOTTyw NIK3tiis94WO0pXiDnFTB9FrswC9BBGHR0c43UCev90UY6yjvYumtXSHsnZ0jXZZCYOM 1ytfwyoz9UoD7toejp4f/0733Yap7QDwrDjbBc1iGxFJ45zNpLJ/aKy1OfQqnAM2hwKO M34XgKhljQ7P127Vl1njBLoGaPEGGPurw6IGbvLkiPxEpV4wQ8vwdNWWwhg5Q9gIegmW 0Gc6OJyU+DiIgJg3nFflJX/XgbXGaQXhy0DfpChYCMYyF+StWUPt0bxcsVZ05L/PHheJ GCQg== X-Gm-Message-State: ABUngvft/tn++loB7xD5/ek6LO0Dppt+Ez01I0l8TF8tHILVUsxm8R9NMLjJgGlnmFIVlQfm30qNIUkm5RH1fQ== X-Received: by 10.107.136.229 with SMTP id s98mr5652311ioi.171.1478113299494; Wed, 02 Nov 2016 12:01:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.132 with HTTP; Wed, 2 Nov 2016 12:01:39 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Wed, 2 Nov 2016 15:01:39 -0400 Message-ID: To: Michael Bradshaw Content-Type: multipart/alternative; boundary=001a113ed55c277c7f0540561285 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Cleaning up the Codec Specs section of the Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:02:15 -0000 --001a113ed55c277c7f0540561285 Content-Type: text/plain; charset=UTF-8 Ohhh. You'd think I'd take a look at the results IN Markdown (in addition to the other two) after changing them TO Markdown, right? I forget Github gets a little finicky with the acknowledgement of new line characters. Thanks, let me just bulk-add some spaces in between. On Wed, Nov 2, 2016 at 2:57 PM, Michael Bradshaw wrote: > Is there a particular Markdown renderer I should use to look at this? GitHub's > rendering isn't very readable > (granted, > the original looked even worse on GitHub > ). > I think making the spec more readable is a good idea. > > On Tue, Nov 1, 2016 at 7:49 PM, Ashley Blewer > wrote: > >> Hello! I just opened this pull request on matroska-specification, here: >> https://github.com/Matroska-Org/matroska-specification/pull/66 >> >> With the following sentiment... >> "Hello! This pull request seeks, primarily, to break the approved codecs >> out of their occasionally-hierarchical table and into more simple charting >> for better viewing in Markdown, HTML, and (most importantly) RFC text. This >> pull request does NOT attempt to make assertions about the codecs or their >> descriptions, which will need to be reviewed by people with a stronger >> historical knowledge." >> >> So, like I said in the comment, the descriptions, and maybe the codecs >> existing or not, need a lot of refinements that I can't solely work on, so >> any help is appreciated. >> >> I think this above pull request should be (commented/modified) and merged >> based on structural changes only, and then we can proceed to refactor the >> content at a more granular level. Is there redundant information? Are there >> codecs that should be eliminated from the list? Has a codec been modified? >> Should a CodecPrivate element be defined, or must it? >> >> Thanks! >> >> Ashley >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > --001a113ed55c277c7f0540561285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ohhh. You'd think I'd take a look at the results I= N Markdown (in addition to the other two) after changing them TO Markdown, = right? I forget Github gets a little finicky with the acknowledgement of ne= w line characters. Thanks, let me just bulk-add some spaces in between.

On Wed, Nov 2, = 2016 at 2:57 PM, Michael Bradshaw <mjbshaw@google.com> wrot= e:
Is there a particular= Markdown renderer I should use to look at this? GitHub's rendering isn't very= readable=C2=A0(granted, the original looked even worse on GitHub). I t= hink making the spec more readable is a good idea.

On Tue, Nov 1= , 2016 at 7:49 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hello! I just opened this pull request on matroska= -specification, here: https://github.com/Matroska-Or= g/matroska-specification/pull/66

With the following sentime= nt...=C2=A0
"Hello! This pull request seeks, primarily, to break th= e approved codecs out of their occasionally-hierarchical table and into mor= e simple charting for better viewing in Markdown, HTML, and (most important= ly) RFC text. This pull request does NOT attempt to make assertions about t= he codecs or their descriptions, which will need to be reviewed by people w= ith a stronger historical knowledge."

So, like I sa= id in the comment, the descriptions, and maybe the codecs existing or not, = need a lot of refinements that I can't solely work on, so any help is a= ppreciated.

I think this above pull request should= be (commented/modified) and merged based on structural changes only, and t= hen we can proceed to refactor the content at a more granular level. Is the= re redundant information? Are there codecs that should be eliminated from t= he list? Has a codec been modified? Should a CodecPrivate element be define= d, or must it?

Thanks!

Ashley


_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar


--001a113ed55c277c7f0540561285-- From nobody Wed Nov 2 12:38:18 2016 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 5C41612985B for ; Wed, 2 Nov 2016 12:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 a1E5obfJK60g for ; Wed, 2 Nov 2016 12:38:15 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 63F95129857 for ; Wed, 2 Nov 2016 12:38:15 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l124so21470383ywb.3 for ; Wed, 02 Nov 2016 12:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/yZtdidDIw0XD3f5fGrch/vQfyuErC0Meeh9lGJ5Yc8=; b=F83dqVlHImU8dzjXYcf0H+kZElgekCJhwsBpNLWVi0iTGy40faZXOH00U2luRQ6oj2 FLgvkVzP7ieuH19eUX99enUsnyvoZwm3w9hfK5nUOHYGhGo4xNOl+odPHrEriWl0PuJn Bw7hmFS5S9TmHQykIrjiiWDsBwH2XEDlCo5/NJRz94+liYt/Cr30DvbDjvt6GB3p8tVe FS1+eqXDCpl62rXBlTUbXNbkiSWBb+eO4OfTdvJ2FlO807Aw172DK3eIC71wxMxyJg0h KgOcOt1NBK0LJZCWb/Oh7p7MEC6SqzFvIFb0ZZxKaLQY2PHemp1fLxewJm72fpH9T0kQ 6o/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/yZtdidDIw0XD3f5fGrch/vQfyuErC0Meeh9lGJ5Yc8=; b=CXLXxqq/ZOc8VWagpeQ+zlHbq6zjUXWUYqiY6DdAFHcwcwgxMR0gRK5Z/x8zZev02h IqKr1YoQvg9cvkEY8C0cC7LGnvWNcV9Af7EE3Hrez6feNSFvtehHsdQPrEypKMxOBDvQ JGiMYQtC2bLLALA375+AREXQfDVUyXmK+9PuQ4OMPBoM2bKxOusQTSG7F4PvlOWUf8M8 YfbarBSBR8HrvCe/h9dyQueV3WRagqazeLwjbxWSL4tB3QUrcngz9Jwtu89yvdkjV9ER HZZkMvwTq9kGztEc/M5QgAGNzwXDrDk07xRtt6jWBqlpXmkUzIkSbEq2AiyOqxu33JVh 1ABw== X-Gm-Message-State: ABUngvezCXCszcKBleKfWeZNmxvl6wcn5nd0yD21ygReSL/PxJNaJJJ7F6DVFRfinvvkvfkxs8jwT3wWLoHK5Q== X-Received: by 10.107.13.194 with SMTP id 185mr5688335ion.122.1478115494601; Wed, 02 Nov 2016 12:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.132 with HTTP; Wed, 2 Nov 2016 12:38:14 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Wed, 2 Nov 2016 15:38:14 -0400 Message-ID: To: Michael Bradshaw Content-Type: multipart/alternative; boundary=001a113a2b04fe29cb054056947e Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Cleaning up the Codec Specs section of the Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:38:17 -0000 --001a113a2b04fe29cb054056947e Content-Type: text/plain; charset=UTF-8 The latest in the branch should look better in Github Markdown: https://github.com/ablwr/matroska-specification/blob/ab/codec_specs-table/ codec_specs.md I also added emphasis around the Codec ID, name, description for improved readability. On Wed, Nov 2, 2016 at 3:01 PM, Ashley Blewer wrote: > Ohhh. You'd think I'd take a look at the results IN Markdown (in addition > to the other two) after changing them TO Markdown, right? I forget Github > gets a little finicky with the acknowledgement of new line characters. > Thanks, let me just bulk-add some spaces in between. > > On Wed, Nov 2, 2016 at 2:57 PM, Michael Bradshaw > wrote: > >> Is there a particular Markdown renderer I should use to look at this? GitHub's >> rendering isn't very readable >> (granted, >> the original looked even worse on GitHub >> ). >> I think making the spec more readable is a good idea. >> >> On Tue, Nov 1, 2016 at 7:49 PM, Ashley Blewer >> wrote: >> >>> Hello! I just opened this pull request on matroska-specification, here: >>> https://github.com/Matroska-Org/matroska-specification/pull/66 >>> >>> With the following sentiment... >>> "Hello! This pull request seeks, primarily, to break the approved codecs >>> out of their occasionally-hierarchical table and into more simple charting >>> for better viewing in Markdown, HTML, and (most importantly) RFC text. This >>> pull request does NOT attempt to make assertions about the codecs or their >>> descriptions, which will need to be reviewed by people with a stronger >>> historical knowledge." >>> >>> So, like I said in the comment, the descriptions, and maybe the codecs >>> existing or not, need a lot of refinements that I can't solely work on, so >>> any help is appreciated. >>> >>> I think this above pull request should be (commented/modified) and >>> merged based on structural changes only, and then we can proceed to >>> refactor the content at a more granular level. Is there redundant >>> information? Are there codecs that should be eliminated from the list? Has >>> a codec been modified? Should a CodecPrivate element be defined, or must it? >>> >>> Thanks! >>> >>> Ashley >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>> >>> >> > --001a113a2b04fe29cb054056947e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The latest in the branch should look better in Github Mark= down:=C2=A0https://github.com/<= wbr>ablwr/matroska-specification/blob/ab/codec_specs-table/codec_= specs.md

I also added emphasis around the Codec ID, = name, description for improved readability.

On Wed, Nov 2, 2016 at 3:01 PM, Ashle= y Blewer <ashley.blewer@gmail.com> wrote:
Ohhh. You'd think I'd take a= look at the results IN Markdown (in addition to the other two) after chang= ing them TO Markdown, right? I forget Github gets a little finicky with the= acknowledgement of new line characters. Thanks, let me just bulk-add some = spaces in between.

On Wed, Nov 2, 2016 at 2:57= PM, Michael Bradshaw <mjbshaw@google.com> wrote:
Is there a particular Markdown re= nderer I should use to look at this? GitHub's rendering isn't very readable=C2=A0(granted, the original looked even worse on GitHub). I think making = the spec more readable is a good idea.

=
On = Tue, Nov 1, 2016 at 7:49 PM, Ashley Blewer <ashley.blewer@gmail.com<= /a>> wrote:
Hello! I just opened= this pull request on matroska-specification, here: https= ://github.com/Matroska-Org/matroska-specification/pull/66
=
With the following sentiment...=C2=A0
"Hello! This pull request= seeks, primarily, to break the approved codecs out of their occasionally-h= ierarchical table and into more simple charting for better viewing in Markd= own, HTML, and (most importantly) RFC text. This pull request does NOT atte= mpt to make assertions about the codecs or their descriptions, which will n= eed to be reviewed by people with a stronger historical knowledge."
So, like I said in the comment, the descriptions, and mayb= e the codecs existing or not, need a lot of refinements that I can't so= lely work on, so any help is appreciated.

I think = this above pull request should be (commented/modified) and merged based on = structural changes only, and then we can proceed to refactor the content at= a more granular level. Is there redundant information? Are there codecs th= at should be eliminated from the list? Has a codec been modified? Should a = CodecPrivate element be defined, or must it?

Thank= s!
<= font color=3D"#888888">

Ashley

<= /font>

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar



--001a113a2b04fe29cb054056947e-- From nobody Thu Nov 3 16:38:21 2016 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 D928A12946A for ; Thu, 3 Nov 2016 16:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 u7cU5nK2XEik for ; Thu, 3 Nov 2016 16:38:15 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 E29F512711D for ; Thu, 3 Nov 2016 16:38:14 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x4so118524226oix.2 for ; Thu, 03 Nov 2016 16:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MkMz1OHk5IYdVRLxmOKxefQP3LRRbuTm7BfjMJlbbnM=; b=kUEdgtsNEkmaMhrCeUGRI9t87A6iGnrOngIMemj8wsm6cFviR2dirZneU3vAUuFxTT vKSzPjsJ5bLecndmhqO6svkprDy4aBSDU68G1IFjHMLJa4avrfbVhqWGAAikhVhr470+ g08Gxbc3LHT/Y6bw1ELLmtO4W13g/00xwWp+AzxCkQqMpKH/FgdfZsL7dodKB1VGGqDy Q5ffdt9lWPo5OsX0gkoTqTz6GxVBfAQUSwea8Bji76EY3sEbB2Q2bUIAm+COYTSWy+X8 vN9B3gpFemylGHW22W5vqKM1/9ppPAwVs0jOccIL/Pj6iueInxD+cJKY43BkuOulysyH t8KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MkMz1OHk5IYdVRLxmOKxefQP3LRRbuTm7BfjMJlbbnM=; b=BZvDgUDNhFUeq7pew5T7J6h/GYQpYvoJHvtcEsp8MI7a7PMSlgjciLrKxwJXKGdo91 eOHsWDFkNqLSXWTURPf8uj9HH6Avscq/4cl6iij/Ys4CoVlNZvqedkJy63puVmqE7bxY S9Et6wgKnpRi8JZDqLof564E1a8uQBgp8mGU997rZ88ypQ8S3hnLv2DB7IrCcACICstS Xpf6rK4pyyOqN+WrB137GeKvMQ2dFrNE2/mDNILRFHfhbazO7onZ2Y8XRJYynxCTgokc ziCuE3VCsGOyAkT1AkTLUkEP4tM7H+HcZNeovWHwGJT21q+Ylg4VN3H4gIqZkADlM7VJ h/zA== X-Gm-Message-State: ABUngvc84htJMlCUctmSspXuVltj8HsQUPlVsvqqlHQaCveQgWWuR6doFxojsXDyC4FLKP28837A0VtX+glXNg== X-Received: by 10.107.13.194 with SMTP id 185mr10523002ion.122.1478216294174; Thu, 03 Nov 2016 16:38:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.132 with HTTP; Thu, 3 Nov 2016 16:38:13 -0700 (PDT) In-Reply-To: <3BB8346D-3BA7-4CE3-B8BB-691903B7A52E@dericed.com> References: <3BB8346D-3BA7-4CE3-B8BB-691903B7A52E@dericed.com> From: Ashley Blewer Date: Thu, 3 Nov 2016 19:38:13 -0400 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a113a2b041d978b05406e0dee Archived-At: Cc: Ethan T Gates , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 03 Nov 2016 23:38:19 -0000 --001a113a2b041d978b05406e0dee Content-Type: text/plain; charset=UTF-8 Following up on these open issues Dave mentioned with in-line comments...! On Tue, Oct 18, 2016 at 12:57 PM, Dave Rice wrote: > Hi Ethan and others, > > Thanks for this message. In regards to how people can contribute, we've > been trying to file tickets in the associated repositories and these vary > from very easy to complex. I'd suggest that if you'd like contribute but > feel the need for support, please feel welcome to ask for a mentor. > > Here's a highlight of some of the more approachable issues: > > https://github.com/Matroska-Org/ebml-specification/issues/117 > This is basically just a find/replace to correct a misspelling of > "Occurence" with "Occurrence", mostly in this section: https://github.com/ > Matroska-Org/ebml-specification/blob/master/specification.markdown#path. > > ^^^ Completed! > https://github.com/Matroska-Org/matroska-specification/issues/48 > This issue is resolved basically by removing https://github.com/ > Matroska-Org/matroska-specification/blob/gh-pages/overhead.md from the > matroska-specification repo as the discussion suggests that it should not > be part of the specification. > ^^^ PR opened! > > https://github.com/Matroska-Org/matroska-specification/issues/50 > This calls for some sections to be reviewed against the EBML specification > to ensure that they are redundant and then remove the identified redundant > sections from the Matroska specification. > > ^^^ PR opened! > https://github.com/Matroska-Org/ebml-specification/issues/114 > This requires some XML knowledge, but this is a recommendation that > enumeration lists be moved from an informal "(1: option A, 2: option > B)"-style structure. A example of the current enumeration list is here: > https://github.com/Matroska-Org/matroska-specification/blob/ > 2c0a14d3e0117175c1bf224c7be6496eedb28541/ebml_matroska.xml#L195. So this > issue is two part, first propose a new structure, then once accepted adjust > ebml_matroska.xml to use it. > > ^^^ Conversation in progress in ticket! > https://github.com/Matroska-Org/matroska-specification/issues/49 > This relates to the metadata documenation at https://github.com/ > Matroska-Org/matroska-specification/blob/gh-pages/tagging.md. Moritz has > noted the meaning of tag names prefixed by underscores at > https://github.com/Matroska-Org/matroska-specification/issues/49# > issuecomment-254039146, so a section should be added to tagging.md to > explain the meaning of tag names prefixed by underscores and what they > imply and what a Reader should do with them. > > ^^^ Untouched! > https://github.com/Matroska-Org/matroska-specification/issues/46 > This involves cleaning up Matroska's method for defining how to define > codecs in Matroska. There's a markdown table that needs to be cleaned up > and the structure of codec definitions themselves needs to be documented > (such as the name style of Codec IDs, what information is needed in a > description). > > ^^^ PR opened! Will need more work after, though, for technical review of the codecs. > If you'd like to take a particular issue please note so in the Github > issue tracker and feel welcome to ask any clarifying questions or request a > mentor there so that we can assign both to the issue. Thanks much, > > Dave Rice > > On Oct 9, 2016, at 9:48 AM, Ethan T Gates wrote: > > Hi all, > > Another novice lurker here - I second Brendan's thanks to you all for both > the content and admirable form of this process and Genevieve's desire to > observe and soak up as much as I can, as I've been doing by poring over > these threads. I would love to attend a NYC meeting, could make weekends > work, and might humbly suggest a quick word about how exactly newbies or > those without much or any experience with programming or metadata > standardization can contribute! (provision of sample files? copy editing > documentation?) You all have been doing a stellar job of getting CELLAR's > mission out into the wider archival community lately and I think interest > in participation is only going to keep growing. > > Best, > Ethan Gates > > On Sat, Oct 8, 2016 at 7:01 PM, Genevieve HK wrote: > >> 1. Yes! >> 2. weekends are doable >> 3. +1 metadata (but I generally would just be attending to listen & learn >> more about *everything*) >> >> Thanks for planning this! >> >> >> On Sat, Oct 8, 2016 at 3:00 PM, wrote: >> >>> Send Cellar mailing list submissions to >>> cellar@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/cellar >>> or, via email, send a message with subject or body 'help' to >>> cellar-request@ietf.org >>> >>> You can reach the person managing the list at >>> cellar-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Cellar digest..." >>> >>> Today's Topics: >>> >>> 1. Re: NYC cellar meetup? (ashley.blewer@gmail.com) >>> 2. Re: NYC cellar meetup? (Murray, Kate) >>> 3. Re: NYC cellar meetup? (Doug Ewell) >>> 4. Re: NYC cellar meetup? (Reto Kromer) >>> 5. Re: NYC cellar meetup? (Brendan Allen) >>> >>> >>> ---------- Forwarded message ---------- >>> From: ashley.blewer@gmail.com >>> To: Dave Rice >>> Cc: cellar@ietf.org >>> Date: Fri, 7 Oct 2016 21:13:10 +0200 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> >>> >>> > On Oct 7, 2016, at 8:52 PM, Dave Rice wrote: >>> > >>> > Hi all, >>> > >>> > There's been some offlist discussion about having a meetup in New York >>> City on cellar issues (quite a few New Yorkers on the list). In general I >>> think the agenda could be informal but address things like: discussion of >>> open issues, how to contribute, planning upcoming work, collaboration. >>> > >>> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >>> York Public Library. >>> > >>> > So some questions for the group: >>> > >>> > 1. Is such a meeting of interest? >>> > >>> Yes! >>> >>> > 2. Should it occur during an evening or the weekend? An evening may be >>> easier to local folks to coordinate but would be too late for most remote >>> participation from Europe. >>> > >>> Also prefer evenings but more so prefer potential Euro participation! >>> >>> > 3. Recommendations for agenda items, things you'd like to learn, >>> things you'd like to see done? >>> >>> FLAC attack. >>> >>> >>> > Dave Rice >>> > _______________________________________________ >>> > Cellar mailing list >>> > Cellar@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cellar >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: "Murray, Kate" >>> To: "'cellar@ietf.org'" >>> Cc: >>> Date: Fri, 7 Oct 2016 15:16:30 -0400 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Thanks for this Dave. I'm game to (virtually) meet up with other >>> interested folks if scheduling permits. >>> >>> Best from Kate >>> ********** >>> Kate Murray >>> Technology Policy Directorate >>> Library of Congress >>> 202-707-4894 >>> kmur@loc.gov >>> >>> >>> >>> -----Original Message----- >>> From: Dave Rice [mailto:dave@dericed.com] >>> Sent: Friday, October 07, 2016 2:53 PM >>> To: cellar@ietf.org >>> Subject: [Cellar] NYC cellar meetup? >>> >>> Hi all, >>> >>> There's been some offlist discussion about having a meetup in New York >>> City on cellar issues (quite a few New Yorkers on the list). In general I >>> think the agenda could be informal but address things like: discussion of >>> open issues, how to contribute, planning upcoming work, collaboration. >>> >>> Nick Krabbenhoeft has offered to arrange for a meeting space at New York >>> Public Library. >>> >>> So some questions for the group: >>> >>> 1. Is such a meeting of interest? >>> >>> 2. Should it occur during an evening or the weekend? An evening may be >>> easier to local folks to coordinate but would be too late for most remote >>> participation from Europe. >>> >>> 3. Recommendations for agenda items, things you'd like to learn, things >>> you'd like to see done? >>> >>> Dave Rice >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Doug Ewell >>> To: cellar@ietf.org >>> Cc: >>> Date: Fri, 07 Oct 2016 15:45:05 -0700 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Dave Rice wrote: >>> >>> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >>> > York Public Library. >>> >>> That's rather a distance from Colorado, so rather than making the trek, >>> I'll just repeat my request that BCP 47 be adopted as the >>> language-tagging standard instead of (or at least in strong preference >>> to) the existing approach which combines ISO 639-2/B with ccTLDs. >>> >>> -- >>> Doug Ewell | Thornton, CO, US | ewellic.org >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Reto Kromer >>> To: cellar@ietf.org >>> Cc: >>> Date: Sat, 8 Oct 2016 07:05:28 +0200 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Dave Rice wrote: >>> >>> >1. Is such a meeting of interest? >>> >>> Indeed. >>> >>> >2. Should it occur during an evening or the weekend? An >>> >evening may be easier to local folks to coordinate but >>> >would be too late for most remote participation from >>> >Europe. >>> >>> A schedule permitting remote participation from Europe would >>> be ideal. >>> >>> >3. Recommendations for agenda items, things you'd like to >>> >learn, things you'd like to see done? >>> >>> Clear metadata embedding in Matroska, in order to maintain >>> the relevant information about the RGB flavour encoded by >>> FFV1. This would facilitate the native implementations into >>> the current cutting, grading, restoration, etc. softwares. >>> And, therefore, advocating for adoption. >>> >>> +1 FLAC >>> >>> Best regards, Reto >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Brendan Allen >>> To: Reto Kromer >>> Cc: "cellar@ietf.org" >>> Date: Sat, 8 Oct 2016 12:06:24 -0400 >>> Subject: Re: [Cellar] NYC cellar meetup? >>> Hi everyone, >>> I've been lurking on this thread for awhile trying to follow. I'd like >>> to say thanks to all of you for the work you're doing to standardize these >>> formats. Also, its pretty cool how open, inclusive and transparent this >>> process is. >>> I live in nyc and could meet-up at the library. My interests are in >>> embedded metadata and FLAC >>> >>> kind regards, >>> Brendan Allen >>> >>> Sent from my iPhone >>> >>> > On Oct 8, 2016, at 1:05 AM, Reto Kromer wrote: >>> > >>> > Dave Rice wrote: >>> > >>> >> 1. Is such a meeting of interest? >>> > >>> > Indeed. >>> > >>> >> 2. Should it occur during an evening or the weekend? An >>> >> evening may be easier to local folks to coordinate but >>> >> would be too late for most remote participation from >>> >> Europe. >>> > >>> > A schedule permitting remote participation from Europe would >>> > be ideal. >>> > >>> >> 3. Recommendations for agenda items, things you'd like to >>> >> learn, things you'd like to see done? >>> > >>> > Clear metadata embedding in Matroska, in order to maintain >>> > the relevant information about the RGB flavour encoded by >>> > FFV1. This would facilitate the native implementations into >>> > the current cutting, grading, restoration, etc. softwares. >>> > And, therefore, advocating for adoption. >>> > >>> > +1 FLAC >>> > >>> > Best regards, Reto >>> > >>> > _______________________________________________ >>> > Cellar mailing list >>> > Cellar@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cellar >>> >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>> >>> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > > > -- > Ethan Gates > Moving Image Archiving and Preservation Technician > Department of Cinema Studies, MIAP > New York University > 665 Broadway, Room 613 > New York, NY 10012 > 212-998-1732 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a113a2b041d978b05406e0dee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following up on these open issues Dave mentioned with in-l= ine comments...!

On Tue, Oct 18, 2016 at 12:57 PM, Dave Rice <dave@dericed.com> wrote:
Hi Ethan and others,

Thanks for this m= essage. In regards to how people can contribute, we've been trying to f= ile tickets in the associated repositories and these vary from very easy to= complex. I'd suggest that if you'd like contribute but feel the ne= ed for support, please feel welcome to ask for a mentor.

Here's a highlight of some of the more approachable issues:

This is basically just a f= ind/replace to correct a misspelling of "Occurence" with "Oc= currence", mostly in this section:=C2=A0https://github.com/Matroska-Org/ebml-specificatio= n/blob/master/specification.markdown#path.

^^^ Completed!
=C2=A0
This issue is resolved basically by removing=C2= =A0https://github.com/Matroska-Org= /matroska-specification/blob/gh-pages/overhead.md=C2=A0from t= he matroska-specification repo as the discussion suggests that it should no= t be part of the specification.

^^^ PR opened!=C2=A0

Th= is calls for some sections to be reviewed against the EBML specification to= ensure that they are redundant and then remove the identified redundant se= ctions from the Matroska specification.

^^^ PR opened!
=C2=A0
http= s://github.com/Matroska-Org/ebml-specification/issues/114
This requires some XML knowledge, but this is a recommendation that = enumeration lists be moved from an informal "(1: option A, 2: option B= )"-style structure. A example of the current enumeration list is here:= =C2=A0https://github.com/Matroska-Org/matroska-specificatio= n/blob/2c0a14d3e0117175c1bf224c7be6496eedb28541/ebml_matroska.xml= #L195. So this issue is two part, first propose a new structure, t= hen once accepted adjust ebml_matroska.xml to use it.

<= /div>
^^^ Conversation in progress in ticket!
= =C2=A0
This relates to the m= etadata documenation at=C2=A0https://git= hub.com/Matroska-Org/matroska-specification/blob/gh-pages/ta= gging.md. Moritz has noted the meaning of tag names prefixed by undersc= ores at=C2=A0https://github.com/= Matroska-Org/matroska-specification/issues/49#issuecomment-2= 54039146, so a section should be added to tagging.md to explain the meaning of tag names prefi= xed by underscores and what they imply and what a Reader should do with the= m.

^^^ Untouched!
=C2= =A0
This involves cleaning u= p Matroska's method for defining how to define codecs in Matroska. Ther= e's a markdown table that needs to be cleaned up and the structure of c= odec definitions themselves needs to be documented (such as the name style = of Codec IDs, what information is needed in a description).

<= /div>
^^^ PR opened! Will need more work after, thou= gh, for technical review of the codecs.
=C2=A0
If yo= u'd like to take a particular issue please note so in the Github issue = tracker and feel welcome to ask any clarifying questions or request a mento= r there so that we can assign both to the issue. Thanks much,
Dave Rice

On Oct 9, 2016, at 9:48 AM, Ethan T Gates <ethan.gates@nyu.edu> wrot= e:

<= div dir=3D"ltr">Hi all,

Another novice lurker here - I second Brenda= n's thanks to you all for both the content and admirable form of this p= rocess and Genevieve's desire to observe and soak up as much as I can, = as I've been doing by poring over these threads. I would love to attend= a NYC meeting, could make weekends work, and might humbly suggest a quick = word about how exactly newbies or those without much or any experience with= programming or metadata standardization can contribute! (provision of samp= le files? copy editing documentation?) You all have been doing a stellar jo= b of getting CELLAR's mission out into the wider archival community lat= ely and I think interest in participation is only going to keep growing.
Best,
Ethan Gates

On Sat, Oct 8, 2016 at 7:01 PM, Genevieve H= K <gen.fhk@gmail.com> wrote:
1. Yes!
2. weekends are doable=
3. +1 metadata (but I generally would just be attending to listen= & learn more about *everything*)

Thanks for planning this= !


On Sat, Oct 8, 2016 at 3:00 PM, <cellar-request@i= etf.org> wrote:
Send Cellar= mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/cellar
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Cellar digest..."

Today's Topics:

=C2=A0 =C2=A01. Re: NYC cellar meetup? (ashley.blewer@gmail.com)
=C2=A0 =C2=A02. Re: NYC cellar meetup? (Murray, Kate)
=C2=A0 =C2=A03. Re: NYC cellar meetup? (Doug Ewell)
=C2=A0 =C2=A04. Re: NYC cellar meetup? (Reto Kromer)
=C2=A0 =C2=A05. Re: NYC cellar meetup? (Brendan Allen)


---------- Forwarded message ----------
From:=C2=A0ashley.blewer@gmail.com=
To:=C2=A0Dave Rice <dave@dericed.com>
Cc:=C2=A0cellar@ietf.org
Date:=C2=A0Fri, 7 Oct 2016 21:1= 3:10 +0200
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?


> On Oct 7, 2016, at 8:52 PM, Dave Rice <dave@dericed.com> wrote:
>
 > Hi all,
>
> There's been some offlist discussion about having a meetup in New = York City on cellar issues (quite a few New Yorkers on the list). In genera= l I think the agenda could be informal but address things like: discussion = of open issues, how to contribute, planning upcoming work, collaboration. >
 > Nick Krabbenhoeft has offered to arrange for a meeting space at New Yo= rk Public Library.
>
 > So some questions for the group:
>
 > 1. Is such a meeting of interest?
>
 Yes!

> 2. Should it occur during an evening or the weekend? An evening may be= easier to local folks to coordinate but would be too late for most remote = participation from Europe.
>
 Also prefer evenings but more so prefer potential Euro participation!

 > 3. Recommendations for agenda items, things you'd like to learn, t= hings you'd like to see done?

 FLAC attack.


> Dave Rice
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar




---------- Forwarded message ----------
From:=C2=A0= "Murray, Kate" <kmur@loc.gov>
To:=C2=A0"'cellar@ietf.org'" <cellar@ietf.org>
Cc:=C2=A0=
Date:=C2=A0Fri, 7 Oct 2016 15:16:30 -0400
Subject:=C2=A0Re: [Cellar]= NYC cellar meetup?
Thanks for this Dave. I'm game to (virtually) me= et up with other interested folks if scheduling permits.

Best from Kate
**********
Kate Murray
Technology Policy Directorate
Library of Congress
202-7= 07-4894
kmur@loc.gov



-----Original Message-----
From: Dave Rice [mailto:dave@dericed.com]
Sent: Friday, October 07, 2016 2:53 PM
To: cellar@ietf.org
Subject: [Cellar] NYC cellar meetup?

Hi all,

There's been some offlist discussion about having a meetup in New York = City on cellar issues (quite a few New Yorkers on the list). In general I t= hink the agenda could be informal but address things like: discussion of op= en issues, how to contribute, planning upcoming work, collaboration.

Nick Krabbenhoeft has offered to arrange for a meeting space at New York Pu= blic Library.

 So some questions for the group:

 1. Is such a meeting of interest?

 2. Should it occur during an evening or the weekend? An evening may be easi= er to local folks to coordinate but would be too late for most remote parti= cipation from Europe.

 3. Recommendations for agenda items, things you'd like to learn, things= you'd like to see done?

 Dave Rice




---------- Forwarded message ----------
From:=C2=A0Doug Ewell &l= t;doug@ewellic.org>
To:=C2=A0cell= ar@ietf.org
Cc:=C2=A0
Date:=C2=A0Fri, 07 Oct 2016 15:45:05 -0700<= br>Subject:=C2=A0Re: [Cellar] NYC cellar meetup?
Dave Rice wrote:

> Nick Krabbenhoeft has offered to arrange for a meeting space at New > York Public Library.

That's rather a distance from Colorado, so rather than making the trek,=
I'll just repeat my request that BCP 47 be adopted as the
language-tagging standard instead of (or at least in strong preference
to) the existing approach which combines ISO 639-2/B with ccTLDs.

--
Doug Ewell | Thornton, CO, US | ewellic.org



---------- Forwarded message ----------
From:=C2=A0= Reto Kromer <lists@re= to.ch>
To:=C2=A0cellar@ietf.org
Cc:=C2=A0
Date:=C2=A0Sat, 8 Oct 2016 07:05:2= 8 +0200
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?
Dave Rice wrote= :

>1. Is such a meeting of interest?

Indeed.

>2. Should it occur during an evening or the weekend? An
>evening may be easier to local folks to coordinate but
>would be too late for most remote participation from
>Europe.

A schedule permitting remote participation from Europe would
be ideal.

>3. Recommendations for agenda items, things you'd like to
>learn, things you'd like to see done?

Clear metadata embedding in Matroska, in order to maintain
the relevant information about the RGB flavour encoded by
FFV1. This would facilitate the native implementations into
the current cutting, grading, restoration, etc. softwares.
And, therefore, advocating for adoption.

+1 FLAC

Best regards, Reto




---------- Forwa= rded message ----------
From:=C2=A0Brendan Allen <brendanallen.ba@gmail.com&g= t;
To:=C2=A0Reto Kromer <lists@reto.ch>
Cc:=C2=A0"cellar@ietf.org" <cellar@ietf.org>
Date:=C2=A0Sat,= 8 Oct 2016 12:06:24 -0400
Subject:=C2=A0Re: [Cellar] NYC cellar meetup?=
Hi everyone,
I've been lurking on this thread for awhile trying to follow. I'd l= ike to say thanks to all of you for the work you're doing to standardiz= e these formats. Also, its pretty cool how open, inclusive and transparent = this process is.
I live in nyc and could meet-up at the library. My interests are in embedde= d metadata and FLAC

kind regards,
Brendan Allen

Sent from my iPhone

> On Oct 8, 2016, at 1:05 AM, Reto Kromer <lists@reto.ch> wrote:
>
> Dave Rice wrote:
>
>> 1. Is such a meeting of interest?
>
> Indeed.
>
>> 2. Should it occur during an evening or the weekend? An
>> evening may be easier to local folks to coordinate but
>> would be too late for most remote participation from
>> Europe.
>
> A schedule permitting remote participation from Europe would
> be ideal.
>
>> 3. Recommendations for agenda items, things you'd like to
>> learn, things you'd like to see done?
>
> Clear metadata embedding in Matroska, in order to maintain
> the relevant information about the RGB flavour encoded by
> FFV1. This would facilitate the native implementations into
> the current cutting, grading, restoration, etc. softwares.
> And, therefore, advocating for adoption.
>
> +1 FLAC
>
> Best regards, Reto
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar

=

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar



--
Ethan Gates
Moving Image Archiving and= Preservation Technician
Department of Cinema Studies, MIAP
New York = University
665 Broadway, Room 613
New York, NY 10012
_______________________________________________
Cellar mailing list=
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar


________________________________= _______________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--001a113a2b041d978b05406e0dee-- From nobody Sun Nov 6 01:17:38 2016 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 6BBD11296F9 for ; Sun, 6 Nov 2016 01:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 0epXdi4Wn7mj for ; Sun, 6 Nov 2016 01:17:36 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 019E61296DB for ; Sun, 6 Nov 2016 01:17:35 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id t125so116825208ywc.1 for ; Sun, 06 Nov 2016 01:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kziMr1YOcTCZQWZBb6IxWcHVCfdIA/BNsu2RcDRR+M8=; b=z6GErCoZXr/XYi18VzYOzPQkk4/n7NmRphoCXHbhHWfpvYPNdvqkouMexjJrla0Vcm kSJ3gbXuM2NFsBmMFYT6/NSegSjW0Ufw5NxK4bT379D8JbHRC9ermsgZeSWiwSGfzp+T FRlHdUWGbFi0fZDLVDEXH/HySZoQxGB8J+0sP9hrdaa8BBGTfj9LYaEmXekBA2LSz7nX KRVI4fovdQ7XBKeB/2cilWsuPOsj+27SOcQ/AGwl6WE7ZsJxYX1yLzG6ndIDUm7JSrDT Pn9IVJgfe2lj7KpdHrvqIlAwToJRRSah0p0wxqDnbLTPdkercqD5ukkpRCxRqFkuWkbR Q+hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kziMr1YOcTCZQWZBb6IxWcHVCfdIA/BNsu2RcDRR+M8=; b=Suoq9TN6QrdqoSs80fJa0f7cvqadXlY4eHjViCu+pM1TkZ/EQJdO2++fwQcKnMaalT 6PCKF1k1eReA6D00+QZjzWm+8IInMUUoFUjSJH0bJHNRZngfsbswBR1eK+l9FJkHaJgY B/4UlNwfA4oKNYpD3TXDFYW56sBcUCHrfbkjfKeR5rvWsNbHse4pGQW4uYCT4O6HB94g 5jZtf0f9azH2bZz/manxgk98h3adQHSm3KizvLY3Ah4iRkQ3DZ5jeMMIHBNPIFVGCgBX uOeljdKrqTaB7it6syfAFdGJrkiG0cg92DYytHriT8JGG8RFYfDbJwj2GaOMVslq+u0E dBFQ== X-Gm-Message-State: ABUngveqWSr9j4ouprDNHfCz7z/qfWL4Td7lyP3ERKSUn0oTAVnYOk4Z/qlnu/qIFk590kL7Jkfs9vJW3DAaGg== X-Received: by 10.129.163.149 with SMTP id a143mr1161103ywh.242.1478423855228; Sun, 06 Nov 2016 01:17:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 6 Nov 2016 01:17:34 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sun, 6 Nov 2016 10:17:34 +0100 Message-ID: To: Michael Bradshaw Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Unknown Size Element X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Nov 2016 09:17:37 -0000 2016-11-01 13:37 GMT+01:00 Michael Bradshaw : > I'm in favor of this change. Note that even with this wording change, it's > still permitted to create a parent element with a known size and the child > element with an unknown size within a particular file. I think prohibiting > that too would be nice. It would have simplified the WebM parser I wrote. How is that possible ? If the Element has an unknown size, its parent must have an unknown size as well, its parent's parent too and so on. This is a MUST requirement so it should not be allowed to do otherwise. I wonder if files exist in the wild where this requirement is not met. The only possible way I can think of is if a live stream that was recorded and then the Segment size was updated at the end. I doubt that ever existed. If one wants to do that they will now have to edit each Cluster size as well. > On Tuesday, November 1, 2016, Steve Lhomme wrote: >> >> So far the Unknown Size element didn't require its parent to have an >> unknown size. >> >> I propose that all parents of such an element must also have an >> unknown size. If it's known later it's better to update the children >> elements that have their boundaries known too. That's also a way to >> restrict unknown size usage to case where we can't do without. >> >> https://github.com/Matroska-Org/ebml-specification/pull/125 >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sat Nov 19 09:18:31 2016 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 460CC129430 for ; Sat, 19 Nov 2016 09:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYQ6q6O781wf for ; Sat, 19 Nov 2016 09:18:28 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 2EE731295A1 for ; Sat, 19 Nov 2016 09:18:28 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:36791 helo=[10.0.1.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1c89HV-002zjb-KN; Sat, 19 Nov 2016 12:18:27 -0500 From: Dave Rice Message-Id: <85BFF784-A1E5-423D-9A05-45B1D271FD81@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_10C5404C-897F-41C9-B83E-5227B386DE1B" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sat, 19 Nov 2016 12:18:23 -0500 In-Reply-To: To: Ashley Blewer References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Michael Bradshaw , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Cleaning up the Codec Specs section of the Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 17:18:30 -0000 --Apple-Mail=_10C5404C-897F-41C9-B83E-5227B386DE1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I added a few comments in the pull request, but support merging this = as-is as a formatting update, so that we can work on content adjustments = in subsequent pull requests. Dave > On Nov 2, 2016, at 3:38 PM, Ashley Blewer = wrote: >=20 > The latest in the branch should look better in Github Markdown: = https://github.com/ablwr/matroska-specification/blob/ab/codec_specs-table/= codec_specs.md = >=20 > I also added emphasis around the Codec ID, name, description for = improved readability. >=20 > On Wed, Nov 2, 2016 at 3:01 PM, Ashley Blewer > wrote: > Ohhh. You'd think I'd take a look at the results IN Markdown (in = addition to the other two) after changing them TO Markdown, right? I = forget Github gets a little finicky with the acknowledgement of new line = characters. Thanks, let me just bulk-add some spaces in between. >=20 > On Wed, Nov 2, 2016 at 2:57 PM, Michael Bradshaw > wrote: > Is there a particular Markdown renderer I should use to look at this? = GitHub's rendering isn't very readable = (granted, the original looked even = worse on GitHub = ). I think making the spec = more readable is a good idea. >=20 > On Tue, Nov 1, 2016 at 7:49 PM, Ashley Blewer > wrote: > Hello! I just opened this pull request on matroska-specification, = here: https://github.com/Matroska-Org/matroska-specification/pull/66 = >=20 > With the following sentiment...=20 > "Hello! This pull request seeks, primarily, to break the approved = codecs out of their occasionally-hierarchical table and into more simple = charting for better viewing in Markdown, HTML, and (most importantly) = RFC text. This pull request does NOT attempt to make assertions about = the codecs or their descriptions, which will need to be reviewed by = people with a stronger historical knowledge." >=20 > So, like I said in the comment, the descriptions, and maybe the codecs = existing or not, need a lot of refinements that I can't solely work on, = so any help is appreciated. >=20 > I think this above pull request should be (commented/modified) and = merged based on structural changes only, and then we can proceed to = refactor the content at a more granular level. Is there redundant = information? Are there codecs that should be eliminated from the list? = Has a codec been modified? Should a CodecPrivate element be defined, or = must it? >=20 > Thanks! >=20 > Ashley >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_10C5404C-897F-41C9-B83E-5227B386DE1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I added a few comments in the pull request, = but support merging this as-is as a formatting update, so that we can = work on content adjustments in subsequent pull requests.
Dave

On Nov 2, 2016, at 3:38 PM, Ashley Blewer <Ashley.Blewer@gmail.com> wrote:

The latest in the branch should look better in Github = Markdown: https://github.com/ablwr/matroska-specification/blob/ab/codec_specs-table/codec_specs.md

I also added emphasis around the Codec ID, name, description = for improved readability.

On Wed, Nov 2, 2016 at 3:01 PM, = Ashley Blewer <ashley.blewer@gmail.com> wrote:
Ohhh. You'd think I'd take a look at the results IN Markdown = (in addition to the other two) after changing them TO Markdown, right? I = forget Github gets a little finicky with the acknowledgement of new line = characters. Thanks, let me just bulk-add some spaces in = between.

On Wed, = Nov 2, 2016 at 2:57 PM, Michael Bradshaw <mjbshaw@google.com> wrote:
Is there a particular Markdown renderer I should use to look = at this? GitHub's rendering isn't very readable (granted, the = original looked even worse on GitHub). I think making the spec = more readable is a good idea.

On Tue, Nov 1, 2016 at 7:49 PM, = Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hello! I just opened this pull request on = matroska-specification, here: https://github.com/Matroska-Org/matroska-specification/pull/66

With the following sentiment... 
"Hello! This pull request seeks, primarily, to break the = approved codecs out of their occasionally-hierarchical table and into = more simple charting for better viewing in Markdown, HTML, and (most = importantly) RFC text. This pull request does NOT attempt to make = assertions about the codecs or their descriptions, which will need to be = reviewed by people with a stronger historical knowledge."

So, like I said in the = comment, the descriptions, and maybe the codecs existing or not, need a = lot of refinements that I can't solely work on, so any help is = appreciated.

I = think this above pull request should be (commented/modified) and merged = based on structural changes only, and then we can proceed to refactor = the content at a more granular level. Is there redundant information? = Are there codecs that should be eliminated from the list? Has a codec = been modified? Should a CodecPrivate element be defined, or must = it?

Thanks!

Ashley


_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar




_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_10C5404C-897F-41C9-B83E-5227B386DE1B-- From nobody Sun Nov 20 16:56:42 2016 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 1019A12960A for ; Sun, 20 Nov 2016 16:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCzyaGXAb9G1 for ; Sun, 20 Nov 2016 16:56:34 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 B447C1295ED for ; Sun, 20 Nov 2016 16:56:34 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:47203 helo=[10.0.1.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1c8cuO-001AJi-W3; Sun, 20 Nov 2016 19:56:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Sun, 20 Nov 2016 19:56:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> To: Ben Campbell X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org, Steve Lhomme , "Sebastian G." Subject: Re: [Cellar] Matroska Attachments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 00:56:36 -0000 > On Mar 28, 2016, at 10:45 AM, Ben Campbell wrote: >=20 > On 28 Mar 2016, at 7:30, Steve Lhomme wrote: >=20 >> Having more ways to interact with attachments in Matroska seems like = a >>> good thing to me. Safely handling the attachments is up to the >>> application anyway. Should anyone be concerned about security >>> attachments could be ignored. >>=20 >>=20 >> Yes, for example there might be a virus in a font and you might have >> to install it on the system before you can use it. Same thing with a >> PNG or a JPEG. That's already a concern with what we have now. But >> it's out of the scope of Matroska how each type of file is used. As >> long as we extract the proper data, not more, not less with the = proper >> strings attached, we're fine. >=20 >=20 > Any ability to carry arbitrary (potentially executable) attachments = will get scrutiny from at least the security ADs and the security = directorate reviewer(s). I agree it's out of scope for Matroska to = police those, but you will want to at least have language describing the = issue, and to point out that applications (or OSs or something) need to = police them. I started adding this to the Security section: Attacks on a `Matroska Reader` could include: - Storage of a arbitrary and potentially executable data within an = `Attachments Element`. `Matroska Readers` that extract or use data from = Matroska Attachments SHOULD check that the data adheres to expectations. Is there any particular boilerplate to include in a scenario like this? Dave Rice From nobody Sun Nov 20 17:21:21 2016 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 7FAFB1295A6 for ; Sun, 20 Nov 2016 17:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyUYUjd4YcPA for ; Sun, 20 Nov 2016 17:21:17 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 DAF911294B3 for ; Sun, 20 Nov 2016 17:21:17 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:40436 helo=[10.0.1.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1c8dII-001Iza-OT for cellar@ietf.org; Sun, 20 Nov 2016 20:21:17 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_924F718F-42E5-4E5E-BC97-4817911F000C" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sun, 20 Nov 2016 20:21:12 -0500 References: <8CA1DDC1-A3B8-47EC-8E40-941E1B79F13F@dericed.com> <56EEECD1.1020109@gmx.de> <18E69030-167D-4A3E-953D-86BB3205F39A@dericed.com> <20160328155227.GQ7792@bunkus.org> <20160328193617.GB25812@nb4> <95199A2E-8442-40D6-A275-5D5598F07F87@dericed.com> To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <95199A2E-8442-40D6-A275-5D5598F07F87@dericed.com> Message-Id: <70A9FD57-B86B-42D2-AF24-F905A385E0D9@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska Attachments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 01:21:20 -0000 --Apple-Mail=_924F718F-42E5-4E5E-BC97-4817911F000C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, > On Mar 29, 2016, at 11:21 AM, Dave Rice wrote: >=20 >> On Mar 28, 2016, at 3:36 PM, Michael Niedermayer = > wrote: >>=20 >> On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz Bunkus wrote: >>> Hey, >>>=20 >>>> Presently an attached file in Matroska is only described with a >>>> FileName, mimetype, and description. There is no permissions, uid, >>>> gid, modification timestamps, etc. So IIUC there no method to = clarify >>>> if an attached file is executable or not. >>>>=20 >>>> Perhaps the specifications should clarify though, if any = permissions >>>> should be presumed of an attachment. For instance if a parser = exports >>>> the Attachment back to a file, what defaults should be used for >>>> permissions and other file attributes. >>>=20 >>> I don't think that it's our (the spec's) job to specify how local = system >>> security should be managed. This would be a slippery slope. We're = not >>> security experts, and security is one of those fields someone has to = be >>> really knowledgeable to get it right. >>>=20 >>> I also don't see the point in making any kind of rules from our >>> side. There are use cases across the whole board regarding system >>> security: from not using any attachments at all; over keeping them = in a >>> temporary location only accessible to the current user and deleting = them >>> right after playback; to asking the user if she wants to install the >>> fonts extracted from the attachments into the system's font = database. It >>> should not be up to the specs to make any kind of assumption here. >>>=20 >>> The specs should mention attachments and the various attack vectors = in >>> any future RFC's security section, of course. >>=20 >> The specs could list a "core" set of attachment mime types that >> are recommanded to be supported. >=20 > +1 >=20 >> That would make it easier for applications generating files to know >> what can be put in that is likely going to be interpreted and >> applications on the receiving end to know what minium set makes sense >> to support. (or looking at it from the other side what mime types >> can be ignored to minimize the attack surface without impacting the >> majority of uses) >=20 >=20 > For a whitelist we could use: > text/* > image/* > video/* > application/pdf > application/xml > others? >=20 > I've had trouble locating existing Matroska files with Attachments. = The Internet Archive has ~90,000 matroska files and has been my largest = sample set, but none of them use attachments. The primary examples of = attachments I've seen come from samples.ffmpeg.org = . Are there any other online collections of = matroska files that may include attachments that I could analyze? > Dave Rice Using the recommendations of this thread I started working on = attachments.md (which was previously named cover_art.md). I rewrote the = cover art section in more formal language and added some security = information. The latest work on this is in this pull request: = https://github.com/Matroska-Org/matroska-specification/pull/73/files = . I realize that although I often hear about Matroska's support for = embedded fonts that I don't see much specification language anywhere = about how to best handle font attachments. Are recommended practices for = embedded fonts for subtitle use in scope of a Matroska specification? = Anyone know of good existing documentation or practices for font = handling in Matroska or volunteer to write some? Best Regards, Dave Rice --Apple-Mail=_924F718F-42E5-4E5E-BC97-4817911F000C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all,

On Mar 29, 2016, at 11:21 AM, = Dave Rice <dave@dericed.com> wrote:

On Mar 28, 2016, at 3:36 PM, Michael = Niedermayer <michael@niedermayer.cc> wrote:

On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz = Bunkus wrote:
Hey,

Presently = an attached file in Matroska is only described with a
FileName, mimetype, and description. There is no permissions, = uid,
gid, modification timestamps, etc. So IIUC there no = method to clarify
if an attached file is executable or = not.

Perhaps the specifications should = clarify though, if any permissions
should be presumed of = an attachment. For instance if a parser exports
the = Attachment back to a file, what defaults should be used for
permissions and other file attributes.

I don't think that it's our (the = spec's) job to specify how local system
security should be = managed. This would be a slippery slope. We're not
security = experts, and security is one of those fields someone has to be
really knowledgeable to get it right.

I also don't see the point in making any kind of rules from = our
side. There are use cases across the whole board = regarding system
security: from not using any attachments = at all; over keeping them in a
temporary location only = accessible to the current user and deleting them
right = after playback; to asking the user if she wants to install the
fonts extracted from the attachments into the system's font = database. It
should not be up to the specs to make any = kind of assumption here.

The specs should = mention attachments and the various attack vectors in
any = future RFC's security section, of course.

The specs could list a = "core" set of attachment mime types that
are recommanded to be = supported.

+1

That would make it easier for = applications generating files to know
what can be put in that is likely going = to be interpreted and
applications on the receiving end to know what = minium set makes sense
to support. (or looking at it from the other = side what mime types
can be ignored to minimize the attack surface = without impacting the
majority of = uses)

For a whitelist we could use:
text/*
image/*
video/*
application/pdf
application/xml
others?

I've had = trouble locating existing Matroska files with Attachments. The Internet = Archive has ~90,000 matroska files and has been my largest sample set, = but none of them use attachments. The primary examples of attachments = I've seen come from samples.ffmpeg.org. Are there any other online = collections of matroska files that may include attachments that I could = analyze?
Dave = Rice

Using = the recommendations of this thread I started working on attachments.md = (which was previously named cover_art.md). I rewrote the cover art = section in more formal language and added some security information. The = latest work on this is in this pull request: https://github.com/Matroska-Org/matroska-specification/pull/73/= files.

I realize that although I = often hear about Matroska's support for embedded fonts that I don't see = much specification language anywhere about how to best handle font = attachments. Are recommended practices for embedded fonts for subtitle = use in scope of a Matroska specification? Anyone know of good existing = documentation or practices for font handling in Matroska or volunteer to = write some?

Best = Regards,
Dave Rice

= --Apple-Mail=_924F718F-42E5-4E5E-BC97-4817911F000C-- From nobody Tue Nov 22 18:41:09 2016 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 4F3D61294C9 for ; Tue, 22 Nov 2016 18:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHypP7Egy3Lf for ; Tue, 22 Nov 2016 18:41:06 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 29098126D73 for ; Tue, 22 Nov 2016 18:41:06 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:41320 helo=[10.0.1.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1c9NUe-002sMH-A2 for cellar@ietf.org; Tue, 22 Nov 2016 21:41:05 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <43BC5017-D7C4-4DC8-B8D2-DF43EDD4366D@dericed.com> Date: Tue, 22 Nov 2016 21:41:02 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] Matroska documentation on Cues X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 02:41:07 -0000 Hi all, Official documentation on the Matroska Cues Element has been sparse = though the pull request at = https://github.com/Matroska-Org/matroska-specification/pull/69 has = provided some good information about recommended practices in use of the = Cues Element beyond the mandates provided in Matroska's Schema. Mostly = based on Moritz's comments at = https://github.com/Matroska-Org/matroska-specification/pull/69#issuecommen= t-261938346, I started a draft of a documentation about Cues (reviewable = at = https://github.com/Matroska-Org/matroska-specification/blob/start-cues-doc= umentation/cues.md) and also pasted below. There's a separate document = in to repo about Element Ordering recommendations so there's a little = more about Cues there. Is there more to say about Cues? # Cues ## Introduction The `Cues Element` provides an index of certain `Cluster Elements` to = allow for optimized seeking to absolute timestamps within the `Segment`. = The `Cues Element` contains one or many `CuePoint Elements` which each = MUST reference an absolute timestamp (via the `CueTime Element`), a = `Track` (via the `CueTrack Element`), and a `Segment Position` (via the = `CueClusterPosition` Element). Additional non-mandated Elements are part = of the `CuePoint Element` such as `CueDuration`, `CueRelativePosition`, = `CueCodecState` and others which can improve seeking performance in some = Matroska players. ## Recommendations The following recommendations are provided to optimize Matroska = performance. - Unless Matroska is used as a live stream, it SHOULD contain a `Cues = Element`. Note that some Matroska players may not be able to play a = Matroska file without a `Cues Element`. - For each video track, each keyframe SHOULD be referenced by a = `CuePoint Element`. - It is RECOMMENDED to not reference non-keyframes of video tracks in = `Cues` unless it references a `Cluster Element` which contains a = `CodecState Element` but no keyframes. - For each subtitle track present, each subtitle frame SHOULD be = referenced by a `CuePoint Element` with a `CueDuration Element`. - Audio tracks SHOULD only be referenced in `CuePoint Elements` if no = video track is present. In this case `CuePoint Elements` SHOULD = reference audio keyframes at most once every 500 milliseconds - If the referenced frame is not stored within the first `SimpleBlock` = or first `BlockGroup` within its `Cluster Element` then the = `CueRelativePosition Element` SHOULD be written to reference where in = the `Cluster` the reference frame is stored. - If a `CuePoint Element` references `Cluster Element` that includes a = `CodecState Element` then that `CuePoint Element` MUST use a = `CueCodecState Element`. - `CuePoint Elements` SHOULD be numerically sorted in storage order by = the value of the `CueTime Element`. Best Regards, Dave Rice From nobody Mon Nov 28 12:59:58 2016 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 B6D19129FBC for ; Mon, 28 Nov 2016 12:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 alD1GE5xNO6O for ; Mon, 28 Nov 2016 12:59:55 -0800 (PST) Received: from mail-wj0-x22c.google.com (mail-wj0-x22c.google.com [IPv6:2a00:1450:400c:c01::22c]) (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 36134129FC7 for ; Mon, 28 Nov 2016 12:59:55 -0800 (PST) Received: by mail-wj0-x22c.google.com with SMTP id xy5so127470999wjc.0 for ; Mon, 28 Nov 2016 12:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YkzqQZEFyYUCRxmMX84n3kX47h1yzmPCan4nj7/pVKU=; b=Iqu/N54r0yOCwq4S0+JHMhf0gwjDLphKN/dNk4Rbtyd8nSjbvpcveaMj2iA/0zn6Mz r7zSrwnTyG9Ys/oWrbLHVhf2uVzAVeyXhtrVgwjngt+KtFLJBwnaW3TmViGIRWJKSE7i OzzR9T1FixYTeq7lEdCYW9cRIVTgbclJkHUVIXN/CH6p1yTYt32mfmDVatsyYypJFl1e IzKMsbmjqdfj2uwV/UZXhOixaEV3ik+5qHc69af1L47jIpYBGqcJ9kdPb8TdZPtCXWZF 3v+VJHqTCmJ7qV39oewQbWZA4EHXnFjBYG5tbL9VpyBcAEvmcBkL8mSYWOnbcSZiLcGF bfzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YkzqQZEFyYUCRxmMX84n3kX47h1yzmPCan4nj7/pVKU=; b=HSWTqolijPKcvObh9V0dm82393jblzJnfOEfd7MEleM3AXEPNumF/EvWd4M6mMVTAm 0yFUc7piji+n+jSjEbhAICaR597kcYKa4x+RFVKa2kTbo8c4/b3lWs1fymUIm8FQsqgp SjVl68oeKCwuG4j1I1Wbblm47I8iKh+DW+N+D9bvhNtE6Qv9adDoH8dsy0carR+q/8fz fc3l4eDmjUXmqXKBS88dj4M6xTRQqA34llzmm1nqzr/TebdcG1E9JHJ5pGyyC69upk/a P7jRxxTuRK2T//ARJ84zmuASrTCSAcUC8DjQ5s28rUi+sx8Ul3Dz1jF6ZrYcxXkiHxrO nfrw== X-Gm-Message-State: AKaTC01DXmfikYPidfHtnpN5//p/rvAPyJSS7ZAWlbN6q3ZrOpYWB1rxFv4KqPmqCPgF2QByZ+23rnOlM9pQKQ== X-Received: by 10.194.165.136 with SMTP id yy8mr23737746wjb.14.1480366793613; Mon, 28 Nov 2016 12:59:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.45.228 with HTTP; Mon, 28 Nov 2016 12:59:52 -0800 (PST) Received: by 10.194.45.228 with HTTP; Mon, 28 Nov 2016 12:59:52 -0800 (PST) In-Reply-To: References: <4F99D513-7C50-4297-BDBA-393056D603B2@dericed.com> <20160114123849.GA4063@bunkus.org> <20160114125000.GB4063@bunkus.org> <14C9BD10-0E2C-465B-A6B3-D0C423BB6720@dericed.com> <016f968e-faa3-ec72-a1f1-a5c300aa83c0@mediaarea.net> From: Kieran O Leary Date: Mon, 28 Nov 2016 20:59:52 +0000 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=089e01228e48dee852054262c0e8 Archived-At: Subject: Re: [Cellar] ReferenceTimecode tracks in Matroska proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 28 Nov 2016 20:59:56 -0000 --089e01228e48dee852054262c0e8 Content-Type: text/plain; charset=UTF-8 Hello all, I'm wondering about the status of timecode within Matroska. Rereading the thread, I really like Jerome's idea for (if I understand correctly) remuxing preexisting timecode tracks within matroska, such as a quicktime tmcd track. I am not very knowledgeable about timecode so I would love to hear what other archivists think,as well as what broadcast users/developers think. I see the lack of timecode support as being the last (imo) barrier to entry for adopting Matroska in an archive. The only files that I encounter seem to just store information about the first frame, so if the timecode resets to zero on a tape, this isn't reflected in the resulting file. It would be good to hear from users with different types of timecode tracks as well,as my experience is relatively limited. Best, Kieran --089e01228e48dee852054262c0e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello all,

I'm wondering about the status of timecode within Matros= ka. Rereading the thread, I really like Jerome's idea for (if I underst= and correctly)=C2=A0 remuxing preexisting timecode tracks within matroska,= =C2=A0 such as a quicktime tmcd track. I am not very knowledgeable about ti= mecode so I would love to hear what other archivists think,as well as what = broadcast users/developers think.

I see the lack of timecode support as being the last (imo) b= arrier to entry for adopting Matroska in an archive.=C2=A0

The only files that I encounter seem to just store informati= on about the first frame, so if the timecode resets to zero on a tape, this= isn't reflected in the resulting file. It would be good to hear from u= sers with different types of timecode tracks as well,as my experience is re= latively limited.

Best,

Kieran

--089e01228e48dee852054262c0e8-- From nobody Mon Nov 28 13:13:44 2016 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 4BCE4129CF7 for ; Mon, 28 Nov 2016 13:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0q-eeABIwkx for ; Mon, 28 Nov 2016 13:13:41 -0800 (PST) Received: from 16.mo4.mail-out.ovh.net (16.mo4.mail-out.ovh.net [188.165.55.104]) (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 A8FD21294FD for ; Mon, 28 Nov 2016 13:13:40 -0800 (PST) Received: from player159.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 543131ED88 for ; Mon, 28 Nov 2016 22:13:38 +0100 (CET) Received: from [192.168.2.101] (p5DDB4060.dip0.t-ipconnect.de [93.219.64.96]) (Authenticated sender: jerome@francoallemand.eu) by player159.ha.ovh.net (Postfix) with ESMTPSA id 0DBF8480084 for ; Mon, 28 Nov 2016 22:13:37 +0100 (CET) To: cellar@ietf.org References: <4F99D513-7C50-4297-BDBA-393056D603B2@dericed.com> <20160114123849.GA4063@bunkus.org> <20160114125000.GB4063@bunkus.org> <14C9BD10-0E2C-465B-A6B3-D0C423BB6720@dericed.com> <016f968e-faa3-ec72-a1f1-a5c300aa83c0@mediaarea.net> From: Jerome Martinez Message-ID: <75feca08-6c93-bc8a-a7b3-ab9248d56c18@mediaarea.net> Date: Mon, 28 Nov 2016 22:13:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 11385662810796134545 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelfedrfeeigddugeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] ReferenceTimecode tracks in Matroska proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 28 Nov 2016 21:13:43 -0000 Le 28/11/2016 à 21:59, Kieran O Leary a écrit : > > Hello all, > > I'm wondering about the status of timecode within Matroska. Rereading > the thread, I really like Jerome's idea for (if I understand > correctly) remuxing preexisting timecode tracks within matroska, > such as a quicktime tmcd track. I am not very knowledgeable about > timecode so I would love to hear what other archivists think,as well > as what broadcast users/developers think. > This is on my todo-list, sorry for the delay. > I see the lack of timecode support as being the last (imo) barrier to > entry for adopting Matroska in an archive. > > The only files that I encounter seem to just store information about > the first frame, so if the timecode resets to zero on a tape, this > isn't reflected in the resulting file. It would be good to hear from > users with different types of timecode tracks as well,as my experience > is relatively limited. > It highly depends of the source of your encode. e.g. - MOV may have both information about the first frame or information about all frames - MXF can have a MXF timecode track (information about the first frame only), SDTI (information about all frames) or System Scheme (information about all frames), or ATC in VANC (information about all frames). - GXF can have both information about the first frame or information about all frames. All in their own formats :). I'll try to find a good method for describing all of them. Jérôme From nobody Tue Nov 29 02:32:46 2016 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 71BEA129673 for ; Tue, 29 Nov 2016 02:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KZxlUIlKgeTL for ; Tue, 29 Nov 2016 02:32:42 -0800 (PST) Received: from mail-wj0-x231.google.com (mail-wj0-x231.google.com [IPv6:2a00:1450:400c:c01::231]) (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 402DB129488 for ; Tue, 29 Nov 2016 02:32:33 -0800 (PST) Received: by mail-wj0-x231.google.com with SMTP id v7so140920686wjy.2 for ; Tue, 29 Nov 2016 02:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aPQZdB60eqnYzCbJaZE1kK+42+320vGmSPJ2FfqLCc0=; b=nf8d8Z2pHIZp4Z8jcmopPY9+u6QhXAS2SXU+w8MLHJNq1/8kTMILMVDlI2KkYGnj1u QXCBTSdVCEuj+HelrH22rU7+/cyfw0E5YD0t9tvbKgfTIEsrA5ZcHjSA7gKck39RR4Kn tDq3Jo7FDKjbPKlo0nG6QS8YNDpVka5LFuj0FE4Oo+NQtFxhUodjzHnR6A7DwjgsfbTn WcnjolyqGWwBa/Pni8Vd5VqJrFB5cNIFmaW28Y0iIOscQKiJpI9UZx5koL+cAahUKuxB Uwan8IspB2bXQq8Tkk2nrxPtsO8yemzpaOKaZV004wC5avu5DrZ2mukGf/+8VRmeaHjq nbTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aPQZdB60eqnYzCbJaZE1kK+42+320vGmSPJ2FfqLCc0=; b=Md1uXh4Rpdj9KhATAo9jbY20IKY8/wHKB6g4EHjaWoaZba6WcwU5oRuFe93VRyecy2 hfP5ZseJU/bqRkCTtT9V9ZdK6RxPlVPOwOgQNBplPso+5eaWCGYQ3e9mkpEtsZmPXeZD 3x1+6g/BEVXdBNMGvNXpFjaYgoAtN06niTUd0NIqsbyzpHOTpbZ8nTj643viG1yIWnLU bGv7zT51BULVjrUhy3hy0IPbkfu+xpM7ddknTfEwZwuicyac+G2s1u8X2Lbo/SvBRB51 zVnSKqJOeuYts3BLtqceGf1yTFV68n/kQ+kvGPwb5EcWK/hnBQFfRB0GzzpFoELLDUyh QrJw== X-Gm-Message-State: AKaTC00W2BQwRWFdY+94Z3UCsPgJVlu91vTmuYrhUP9qqq2AyewIjbDsEyHIgB4In3f72Ut9OQ+B18T5ptVPFA== X-Received: by 10.194.113.129 with SMTP id iy1mr23502347wjb.127.1480415551693; Tue, 29 Nov 2016 02:32:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.36 with HTTP; Tue, 29 Nov 2016 02:32:31 -0800 (PST) In-Reply-To: <75feca08-6c93-bc8a-a7b3-ab9248d56c18@mediaarea.net> References: <4F99D513-7C50-4297-BDBA-393056D603B2@dericed.com> <20160114123849.GA4063@bunkus.org> <20160114125000.GB4063@bunkus.org> <14C9BD10-0E2C-465B-A6B3-D0C423BB6720@dericed.com> <016f968e-faa3-ec72-a1f1-a5c300aa83c0@mediaarea.net> <75feca08-6c93-bc8a-a7b3-ab9248d56c18@mediaarea.net> From: Kieran O Leary Date: Tue, 29 Nov 2016 10:32:31 +0000 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a1130cf0614285e05426e1b7b Archived-At: Subject: Re: [Cellar] ReferenceTimecode tracks in Matroska proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 29 Nov 2016 10:32:45 -0000 --001a1130cf0614285e05426e1b7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 28, 2016 at 9:13 PM, Jerome Martinez wrote: > Le 28/11/2016 =C3=A0 21:59, Kieran O Leary a =C3=A9crit : > >> >> Hello all, >> >> I'm wondering about the status of timecode within Matroska. Rereading th= e >> thread, I really like Jerome's idea for (if I understand correctly) >> remuxing preexisting timecode tracks within matroska, such as a quickti= me >> tmcd track. I am not very knowledgeable about timecode so I would love t= o >> hear what other archivists think,as well as what broadcast users/develop= ers >> think. >> >> > This is on my todo-list, sorry for the delay. > > Great to hear! > > I see the lack of timecode support as being the last (imo) barrier to >> entry for adopting Matroska in an archive. >> >> The only files that I encounter seem to just store information about the >> first frame, so if the timecode resets to zero on a tape, this isn't >> reflected in the resulting file. It would be good to hear from users wit= h >> different types of timecode tracks as well,as my experience is relativel= y >> limited. >> >> > It highly depends of the source of your encode. e.g. > - MOV may have both information about the first frame or information abou= t > all frames > - MXF can have a MXF timecode track (information about the first frame > only), SDTI (information about all frames) or System Scheme (information > about all frames), or ATC in VANC (information about all frames). > - GXF can have both information about the first frame or information abou= t > all frames. > > All in their own formats :). > I'll try to find a good method for describing all of them. > > Even better to hear :) I would assume that this would require some changes to ffmpeg too as there is a generic warning at the moment when a user attempts to include a data track in a Matroska file. https://github.com/ FFmpeg/FFmpeg/blob/master/libavformat/matroskaenc.c#L1271 > J=C3=A9r=C3=B4me > > > Best, Kieran. --001a1130cf0614285e05426e1b7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Nov 28, 2016 at 9:13 PM, Jerome Martinez &= lt;jerome@mediaar= ea.net> wrote:
Le 28/11/2016 =C3=A0 21:59, Kieran O Leary a = =C3=A9crit :

Hello all,

I'm wondering about the status of timecode within Matroska. Rereading t= he thread, I really like Jerome's idea for (if I understand correctly)= =C2=A0 remuxing preexisting timecode tracks within matroska,=C2=A0 such as = a quicktime tmcd track. I am not very knowledgeable about timecode so I wou= ld love to hear what other archivists think,as well as what broadcast users= /developers think.


 This is on my todo-list, sorry for the delay.

=C2=A0
Great to hear!=C2=A0
=C2=A0

I see the lack of timecode support as being the last (imo) barrier to entry= for adopting Matroska in an archive.

The only files that I encounter seem to just store information about the fi= rst frame, so if the timecode resets to zero on a tape, this isn't refl= ected in the resulting file. It would be good to hear from users with diffe= rent types of timecode tracks as well,as my experience is relatively limite= d.


 It highly depends of the source of your encode. e.g.
- MOV may have both information about the first frame or information about = all frames
- MXF can have a MXF timecode track (information about the first frame only= ), SDTI (information about all frames) or System Scheme (information about = all frames), or ATC in VANC (information about all frames).
- GXF can have both information about the first frame or information about = all frames.

All in their own formats :).
I'll try to find a good method for describing all of them.


Even = better to hear :) I would assume that this would require some changes to ff= mpeg too as there is a generic warning at the moment when a user attempts t= o include a data track in a Matroska file.=C2=A0https://github.com/FFmpeg/FFmpe= g/blob/master/libavformat/matroskaenc.c#L1271
= =C2=A0
J=C3=A9r=C3=B4me




Best,
=

Kieran.=C2=A0

--001a1130cf0614285e05426e1b7b-- From nobody Tue Nov 29 07:18:08 2016 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 19B89129BFA for ; Tue, 29 Nov 2016 07:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 uwZ4JYW-X4Pv for ; Tue, 29 Nov 2016 07:18:05 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E452129BF6 for ; Tue, 29 Nov 2016 07:18:05 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 29 Nov 2016 16:18:02 +0100 id 0000000000000020.00000000583D9C2B.000050AC Message-ID: <583D9C29.6060504@das-werkstatt.com> Date: Tue, 29 Nov 2016 16:18:01 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <4F99D513-7C50-4297-BDBA-393056D603B2@dericed.com> <20160114123849.GA4063@bunkus.org> <20160114125000.GB4063@bunkus.org> <14C9BD10-0E2C-465B-A6B3-D0C423BB6720@dericed.com> <016f968e-faa3-ec72-a1f1-a5c300aa83c0@mediaarea.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] ReferenceTimecode tracks in Matroska proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 29 Nov 2016 15:18:07 -0000 On 11/28/2016 09:59 PM, Kieran O Leary wrote: > I see the lack of timecode support as being the last (imo) barrier to entry > for adopting Matroska in an archive. I'm also not really experienced with timecodes, but I can confirm Kieran's suspicion. Although I would say that most non-production archives don't have to deal with timecode, institutions that *do* have tapes with timecode in their collection told me they were limited (and therefore sticking) to either MOV or MXF as container (for the time being). Kind regards, Pb From nobody Wed Nov 30 12:32:18 2016 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 69071129A08 for ; Wed, 30 Nov 2016 12:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org 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 2zryF0BTEltk for ; Wed, 30 Nov 2016 12:32:15 -0800 (PST) Received: from liselle.bunkus.org (belgarath.bunkus.org [144.76.6.86]) (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 9AE38129A30 for ; Wed, 30 Nov 2016 12:28:05 -0800 (PST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 567D465413EE for ; Wed, 30 Nov 2016 21:28:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1480537683; bh=Ygp47bXs+L8E3SDGqp+CdBBBCD+5gFSSchWnLhrqkKA=; h=Date:From:To:Subject:From; b=GEiQL1PLXaeHX3cKykiuFHKYlRYAwbRnmpseh4+1MpgeNybOViQb339ZyCA0re8ho i8Yrdiqf4UKLTnGUwuHxDNa875H5apLl/96Xvf/TXeO2xwfZ6Sr2Izy8DrTOrHNoAl MMVEHB8QbQ84fvk9rz1iIhesWXeqCUqO7bFh0LgqYA7nCJwXq6Hk6BmS7/RnUMX7M5 zhAU/t4RBfnA2KwWePqoZnnrjCrRs6ss1fWg7BA4DikQACGlFtUmRy3ozNdPAUYVxl 6P0GjcfCAgvYpmvQlLSo5AR4kkblVAf+0oMlGgYbz1qtSSVKGbi1jHtIlgrwIBGSVm N5MutM3Mdp965g92t1bz7sgMPwYt7yuYeBR+NGn3pANppvuAbUMcGBHAN3iz7XHaxc f+aGW8C4s0DhgVCsvRQnc5MGudEctGrIwqYBBDsWGV47ynLKqAkiSTs6lbK4qUXhbW tDyJduKr65Xm/f4aKSMVpz7kv4N/YRdnOvNoDEEjvLgZBQP/cc54+PvrcuZjTrhPVi tlZPUTnBlx+LocciYc33E+uGNCmwnZ0l4opGDoQOhNfWTXx2/N+b2IsyWrN+NaWbLN ZcQp+N73I8dWYaa6nJUDrbqURLTQOgMnp/hSkDjwoAJwsrFWAqmqhXszRvwu1l2WE0 D7Nuc657OVTG3mci1Tpn2p2w= Received: by sweet-chili.local (Postfix, from userid 1000) id 92C84BCE5CE; Wed, 30 Nov 2016 21:28:02 +0100 (CET) Date: Wed, 30 Nov 2016 21:28:02 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161130202802.xdghoe7d3uqg7h6p@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Subject: [Cellar] Codec specs: Blu-ray subtitles (PGS & TextST) in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 20:32:17 -0000 Hey, there are two subtitle formats used in Blu-rays: a graphical one (also called "HDMV presentation graphics subtitles") and a textual one (called "HDMV text subtitles"). There are several programs out there that have been able to store one or both of the formats in Matroska, and at least the PGS format is in wide use in Matroska files. Until now the Matroska codec specs have not reflected this practice. I've just posted a pull request[1] to remedy the situation. It describes what is already practice; from my point of view the storage method cannot be really up for discussion. Nevertheless I ask for and welcome reviews and suggestions! Thanks :) Kind regards, mosu [1] https://github.com/Matroska-Org/matroska-specification/pull/76 From nobody Wed Nov 30 14:42:49 2016 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 7D270129BA9 for ; Wed, 30 Nov 2016 14:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 FZQGQkSTEaNe for ; Wed, 30 Nov 2016 14:42:44 -0800 (PST) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (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 2601912957E for ; Wed, 30 Nov 2016 14:42:44 -0800 (PST) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id C5577C10A3 for ; Wed, 30 Nov 2016 22:42:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUWp5FfAAvEj for ; Wed, 30 Nov 2016 22:42:43 +0000 (UTC) Received: from [10.252.25.59] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 7AE2AC1026 for ; Wed, 30 Nov 2016 22:42:43 +0000 (UTC) Message-ID: <583F55E1.5070700@xiph.org> Date: Wed, 30 Nov 2016 14:42:41 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <20161130202802.xdghoe7d3uqg7h6p@bunkus.org> In-Reply-To: <20161130202802.xdghoe7d3uqg7h6p@bunkus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Codec specs: Blu-ray subtitles (PGS & TextST) in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:42:46 -0000 Moritz Bunkus wrote: > practice. I've just posted a pull request[1] to remedy the situation. It > describes what is already practice; from my point of view the storage > method cannot be really up for discussion. I would say rather that (unless explicitly excluded by the charter) it is always up for discussion, but saying "we would like to not break existing files that do this" is a position around which it seems likely this group would find consensus in this instance (if someone did wish to discuss it). From nobody Wed Nov 30 15:05:32 2016 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 A4238129BC6 for ; Wed, 30 Nov 2016 15:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org 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 mQHHXRWCINwa for ; Wed, 30 Nov 2016 15:05:29 -0800 (PST) Received: from liselle.bunkus.org (belgarath.bunkus.org [144.76.6.86]) (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 5139C129BBD for ; Wed, 30 Nov 2016 15:05:29 -0800 (PST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id E141565413EE for ; Thu, 1 Dec 2016 00:05:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1480547127; bh=UgfFUYD0fBJX3CQtxdDDtkGiMIdaQ6wPYK998uMlQQU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=pI6OZpkQf1gXPyVtzn7zFOHMbcb3jUOZkmJpYWxa2RcijhcUDR9rgMskmiBVDqalg E16fJ+Gv7Hu3/571apGY6lbECIR+rDf4HsxB8JhTHLASbFV/4n5sAzO7ZS861KPxej hPiQehxr0Okn8TxB7cig8y2rV6cE4nz9mQJKl2XAYVqjulc20QD3Dlw3jii9Q9Xd/B v0m/jBoSsTaaVcMzEn0lP9IYGmw2Auevv0HXB25ndmGZhUWkf8lEkzJ9eHuTlDD0Fz O9Q8jrJi/wtOZLLz4DssGVbg0l4WN6Pqow4S38DQNO060E3+daxCqqdNDmB+aG4aVf u+QWOn4clZpEcs3oeK+AvHuKcMF5eiisT98BHUfX+cTf8XX81jw643Eb/hWjUcNFeF OMujk28S2G2FWFF+zap+4jCF5o/M0byQEwz2PdPziWtw8zlAQWjmrABiDsoMDetxDq qBD2bjil0vmyK6+M1Wpl21EnEGwH9wvApMaUfM62wa4ES0stutlm4lyn3HEVXPksmk Ei2FRyy9boqGWOaDGS66bP+pVu4kRmJaWuAGL4z1OMfxFTXvazjXJjzOc/K028B+Ww 2lNbr+69PIJaEqu4rZXLG2SsJpuk0Wpef2UlCNj1TL+mk9ZkLEt7KgPPyDyQfMvhpF u6d9Vz93X6bOUJSjUaHwzZbI= Received: by sweet-chili.local (Postfix, from userid 1000) id 28636BCEAB9; Thu, 1 Dec 2016 00:05:27 +0100 (CET) Date: Thu, 1 Dec 2016 00:05:27 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161130230526.htbcgn65guhvznzf@bunkus.org> References: <20161130202802.xdghoe7d3uqg7h6p@bunkus.org> <583F55E1.5070700@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <583F55E1.5070700@xiph.org> User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Subject: Re: [Cellar] Codec specs: Blu-ray subtitles (PGS & TextST) in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 23:05:31 -0000 Hey, > I would say rather that (unless explicitly excluded by the charter) it > is always up for discussion, but saying "we would like to not break > existing files that do this" is a position around which it seems > likely this group would find consensus in this instance (if someone > did wish to discuss it). You're right, of course, and that's pretty much what I meant. "Don't break existing files" is a rather strong point, albeit not to the exclusion of everything else. Kind regards, mosu