From nobody Mon Jul 3 10:03:52 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4E129A92; Mon, 3 Jul 2017 10:03:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910142986.22833.7150038829903916978@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:03:49 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-00.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 17:03:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission of the IETF. Title : FF Video Codec 1 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-00.txt Pages : 39 Date : 2017-07-02 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-00 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 3 10:04:04 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C9113144D; Mon, 3 Jul 2017 10:03:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910143790.22782.4692077922703256617@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:03:57 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-03.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 03 Jul 2017 17:03:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-03.txt Pages : 38 Date : 2017-07-02 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-03 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 08:33:28 2017 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 3A3AD12EB9B for ; Wed, 5 Jul 2017 08:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8MAM6tilEPd for ; Wed, 5 Jul 2017 08:33:25 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 261A8131D56 for ; Wed, 5 Jul 2017 08:33:25 -0700 (PDT) Received: from [146.96.19.240] (port=38696 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dSmIt-00073H-As for cellar@ietf.org; Wed, 05 Jul 2017 11:33:24 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_C50D9EC8-BFC5-4F57-B970-C49CA6962E3E" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <02A8B912-F5CB-421F-B99E-625A03E10A32@dericed.com> Date: Wed, 5 Jul 2017 11:33:21 -0400 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] Version -00 of the FFV1 Working Group document X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 05 Jul 2017 15:33:27 -0000 --Apple-Mail=_C50D9EC8-BFC5-4F57-B970-C49CA6962E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear cellar, https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ = Version -00 of draft-ietf-cellar-ffv1 was published on Monday. Note that = the prior versions were made before this document gained WG Doc status, = so the prior versions are at = https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ = . The = recent updates in this new version are detailed in the commits from May = 16 - July 2 at = https://github.com/FFmpeg/FFV1/commits/draft-ietf-cellar-00 = . In = summary the update includes: - local acknowledge/description of the pseudo-code used to define the = structure of the bitstream - clarifications to language description Content, functions, median = prediction - a summary of the versions of FFV1 defined by the document - adjustments to vocabulary and descriptions of Quantization Table sets, = Quantization Tables, Quantization Sample Differences At this point there are only 3 open issues in the github tracker for = FFV1. 2 pertain to enhancements for consideration of the subsequent = version of FFV1. And the other is a small issue regarding locally = defining the use of len_count in the pseodo-code. The document could use some reviews to determine what other work may be = considered here, if any. Best Regards, Dave Rice= --Apple-Mail=_C50D9EC8-BFC5-4F57-B970-C49CA6962E3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear cellar,
https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/

Version -00 of = draft-ietf-cellar-ffv1 was published on Monday. Note that the prior = versions were made before this document gained WG Doc status, so the = prior versions are at https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/= . The recent updates in this new version are detailed in the commits = from May 16 - July 2 at https://github.com/FFmpeg/FFV1/commits/draft-ietf-cellar-00= . In summary the update includes:

- local acknowledge/description of the = pseudo-code used to define the structure of the bitstream
- clarifications to language description Content, functions, = median prediction
- a summary of the versions of = FFV1 defined by the document
- adjustments to = vocabulary and descriptions of Quantization Table sets, Quantization = Tables, Quantization Sample Differences

At this point there are only 3 open = issues in the github tracker for FFV1. 2 pertain to enhancements for = consideration of the subsequent version of FFV1. And the other is a = small issue regarding locally defining the use of len_count in the = pseodo-code.

The= document could use some reviews to determine what other work may be = considered here, if any.

Best Regards,
Dave = Rice
= --Apple-Mail=_C50D9EC8-BFC5-4F57-B970-C49CA6962E3E-- From nobody Mon Jul 10 10:49:11 2017 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 672C012EB99 for ; Mon, 10 Jul 2017 10:49:10 -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 TijfJreE_yWT for ; Mon, 10 Jul 2017 10:49:08 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B784B1289B0 for ; Mon, 10 Jul 2017 10:49:08 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id m84so47825133ita.0 for ; Mon, 10 Jul 2017 10:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KPe0lWt0XnOGHknRqITRx1FqMVjfc+PF9lEhOH8DwsQ=; b=iffARdz4FlCUmLenLbtGq9outwSMDIL0MyOuE3WV2TKo/82uTKml4MFh9cia0tCG68 n5OYF3kj3RbXLHOwEBAAzlNIHK74ooSNZGBE7DPn03Mosjc1NQjGKn2nXGJ7mtvoSAw/ eID7k6Yedhh6MMz7x9rLrvU3vhsV7y5GT7r/YNWuRxCWI7RL7+VE8K/VvgZPmdrhMIRC o+MEOt2dSmUuJKJEYIVB0RpBeEzl2gE3PtD7renYAwTH6pkjnGYkIjJFPvjXUIDqXTD0 4OEVaLuMVyDAtb21s19hG4Kuih8o8MBhMQRBIP4+1VMedT/N3k66n0yEJ+wtRshJB9f3 wXxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KPe0lWt0XnOGHknRqITRx1FqMVjfc+PF9lEhOH8DwsQ=; b=TquovK8lrLXZOV1arHLg255cyewdf4NLghyrBDflyLgHfZ5aPC8qwLrcwJy4OE5EZo N1oOYsSzUfdsIAW0xI5ug/IuxPID0pTjLumEMNZS/pmioM3oa9QBCstfsJuFwHFTnyHk iS2ScG/fB1pOPsBnjTfb+Y+ErGYYoBH8va7LV1hfectlbgkHExa7pSxdmVlJq7EssP5b R/RiaoVLsGuqTJOgK7TcjKZld7H9SvIq0MxQGoGHZx5K3W5NDNUETcvaj+zE3lnptAKZ aP0rw78HwbBSCFclvwXLAyoHHyk+rLbcjehkpi50qta/AI/wK/lFWMX5d6EHnIX/fJEJ UXgg== X-Gm-Message-State: AIVw111wZ/ga/6JKdNHyD6EOYZ40iegLg3vWrVtmWzUAYY7OCThLxe5h 8fXpilnlp/QJW7e06bEXSe6jutzmRE6u X-Received: by 10.36.208.83 with SMTP id m80mr12665065itg.25.1499708947963; Mon, 10 Jul 2017 10:49:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.205 with HTTP; Mon, 10 Jul 2017 10:49:07 -0700 (PDT) Received: by 10.107.142.205 with HTTP; Mon, 10 Jul 2017 10:49:07 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Mon, 10 Jul 2017 13:49:07 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a1149d0261c33660553fa33e2" Archived-At: Subject: [Cellar] Agenda available, WAS Re: ICYMI: CELLAR meeting is now JULY 21 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 17:49:10 -0000 --001a1149d0261c33660553fa33e2 Content-Type: text/plain; charset="UTF-8" The CELLAR draft agenda is here: https://www.ietf.org/proceedings/99/agenda/agenda-99-cellar-00 Please send any comments by 23:59 UTC today. Best, Tessa On Jun 26, 2017 19:59, "Tessa Fallon" wrote: The IETF 99 final agenda was released last Friday and the date/time for the CELLAR meeting has changed. The CELLAR group meeting will be held *July 21, 9:30 a.m. - 11:30 a.m. (Prague time).* Best, Tessa --001a1149d0261c33660553fa33e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The CELLAR draft agenda is here: =C2=A0https://www.i= etf.org/proceedings/99/agenda/agenda-99-cellar-00

=
Please send any comments by 23:59 UTC today.
<= div dir=3D"auto">
Best,
T= essa


On = Jun 26, 2017 19:59, "Tessa Fallon" <tessa.fallon@gmail.com> wrote:
The IETF 99 final agenda was r= eleased last Friday and the date/time for the CELLAR meeting has changed.
The CELLAR group meeting will be held July 21, 9:30 a.m. - 1= 1:30 a.m. (Prague time).

Best,

<= div>Tessa =C2=A0

--001a1149d0261c33660553fa33e2-- From nobody Mon Jul 10 12:09:55 2017 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 0F8C21315FF for ; Mon, 10 Jul 2017 12:09:53 -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 KQ38MQs1fD3e for ; Mon, 10 Jul 2017 12:09:51 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 AB6AA126B6D for ; Mon, 10 Jul 2017 12:09:51 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id k192so50232267ith.1 for ; Mon, 10 Jul 2017 12:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WK4D2nzFC+zfFcb8LAHMv3wxkR01VDGfgm5eviUtLfk=; b=n+gzixSptcc0jmj6XnFV1x1/cELCJy5d2EvvmaObG1b71dkPDL+2ZW9c3Gb95fc2Sc OLPcKFMYKG2hCcPUGOT0rBTQsSVjHcTjXGQujsan1kRPjucyx6loWK/6B6DVydOwfwol YyKS6ysjAkmuya1xMTZFTRAWAqUtWmH+fL8iRfSBVvXjJmCTLCzEZ6zNU8dUGiD+O5xp jJj1va55+AhuzPEFiedRp66FAQgPrpuyOfqGlpPKdgoo/6vmiuJ+KIyaNeWMKgK2t9a8 Cw2vWSPARwqTjjDIbOlyPYWv929WDMng8HHmdvrfi8n9Rx0rpxB6i9NyZEL54VejUfVA 2idw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WK4D2nzFC+zfFcb8LAHMv3wxkR01VDGfgm5eviUtLfk=; b=fmOyX+SaVoCsBogpIEQMOIpWy8eNbz7RZfFiE2GQAD6zqpvw4NuxlJGG+JHboTiSHi D+pNjT/tVX0BgXxNAHdrb2bajoSdCuUxRjuREjrPoGmG6AGa/YllAu6DC7k7nSVF9Lq6 Lv4HyYOGWNb8ZMj9s2ShWdYaXdcbycefeDnWljS26jaBlLzvphV2H3FRNkriEJKkEBk7 PX9t7rGWF2CetiF6KgymTwzzgxhhCIk+xop2u70XQ5qCUNxhoDeLSDQ6PI5zcpSweDJO er/ju6fuEdCH6mJst4O0rKuWUgO7Rf5Xq1x5dFMK/RGxpR7MSPpxCXu52vqD2UrHy5y1 NP6g== X-Gm-Message-State: AIVw1100vsvHaqxkQN+4wIx4ISvDowy+ML+eFroCKU2JYLXVs8b1RUZr cLFrwU8cEApeT8x0IqwtNAAMDq06VlS8SBg= X-Received: by 10.107.165.13 with SMTP id o13mr5581981ioe.47.1499713790750; Mon, 10 Jul 2017 12:09:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.205 with HTTP; Mon, 10 Jul 2017 12:09:10 -0700 (PDT) From: Tessa Fallon Date: Mon, 10 Jul 2017 15:09:10 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a1141f1eec33ad90553fb531f" Archived-At: Subject: [Cellar] Of interest: NETVC meeting at IETF 99; updates on Thor/AV1, Daala/AV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 19:09:53 -0000 --001a1141f1eec33ad90553fb531f Content-Type: text/plain; charset="UTF-8" Subscribers to CELLAR might consider checking out the documents and meeting materials for the NETVC group. Their preliminary agenda is here: https://datatracker.ietf.org/meeting/99/agenda/netvc/ NETVC meets Monday, July 17, 2017, 15:50-17:20 CEST Participants can attend remotely as for the CELLAR meeting. --001a1141f1eec33ad90553fb531f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Subscribers to CELLAR might consider checking out the= documents and meeting materials for the NETVC group.=C2=A0 Their prelimina= ry agenda is here:

= https://datatracker.ietf.org/meeting/99/agenda/netvc/

=
NETVC meets=C2=A0Monday, July 17, 2017, 15:50-17:20 CEST

Participants can attend remotely as for the CELLAR meetin= g.
--001a1141f1eec33ad90553fb531f-- From nobody Mon Jul 10 13:15:29 2017 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 C968212ECCE for ; Mon, 10 Jul 2017 13:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYwpt9kPFMgH for ; Mon, 10 Jul 2017 13:15:26 -0700 (PDT) Received: from relays-agent08.techservices.illinois.edu (relays-agent08.techservices.illinois.edu [204.93.2.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BE8129AE7 for ; Mon, 10 Jul 2017 13:15:26 -0700 (PDT) Received: from uex1314.ad.uillinois.edu (uex1314.cites.illinois.edu [192.17.212.217]) by relays-agent08.techservices.illinois.edu (8.16.0.17/8.16.0.17) with ESMTPS id v6AKFNYW009714 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 10 Jul 2017 15:15:25 -0500 Received: from uex1314.ad.uillinois.edu (192.17.212.217) by uex1314.ad.uillinois.edu (192.17.212.217) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 10 Jul 2017 15:15:24 -0500 Received: from CHIHT2.ad.uillinois.edu (64.22.177.17) by uex1314.ad.uillinois.edu (192.17.212.217) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 10 Jul 2017 15:15:24 -0500 Received: from CITESMBX5.ad.uillinois.edu ([169.254.10.142]) by CHIHT2.ad.uillinois.edu ([64.22.177.74]) with mapi id 14.03.0351.000; Mon, 10 Jul 2017 15:14:55 -0500 From: "Jones, Jimi Lee" To: "cellar@ietf.org" Thread-Topic: Cellar Digest, Vol 22, Issue 3 Thread-Index: AQHS+a7hb7MC0dXIv0aLz2qb7UTd3aJN0tYA Date: Mon, 10 Jul 2017 20:14:55 +0000 Message-ID: <74CADF13-FA0A-46EC-89CE-1851E6E06A0D@illinois.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.212.131.255] Content-Type: multipart/alternative; boundary="_000_74CADF13FA0A46EC89CE1851E6E06A0Dillinoisedu_" MIME-Version: 1.0 X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707100354 X-Spam-OrigSender: jjones7@illinois.edu X-Spam-Bar: Archived-At: Subject: Re: [Cellar] Cellar Digest, Vol 22, Issue 3 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 10 Jul 2017 20:15:28 -0000 --_000_74CADF13FA0A46EC89CE1851E6E06A0Dillinoisedu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgaXQgcG9zc2libGUgdG8gcHV0IG15IDEwIG1pbnV0ZSBwcmVzZW50YXRpb24gYWJvdXQgbXkg UGhEIHJlc2VhcmNoIGludG8gdGhlIGFnZW5kYT8gUGVyaGFwcyBlYXJseSBpbiB0aGUgbWVldGlu ZyBzbyBwZW9wbGUga25vdyB3aHkgSeKAmW0gdGhlcmU/DQoNClRoYW5rIHlvdSENCg0KSmltaQ0K DQoNCkppbWkgSm9uZXMNClNjaG9vbCBvZiBJbmZvcm1hdGlvbiBTY2llbmNlcw0KVW5pdmVyc2l0 eSBvZiBJbGxpbm9pcyBhdCBVcmJhbmEtQ2hhbXBhaWduDQo1MDEgRWFzdCBEYW5pZWwgU3RyZWV0 DQpNQy00OTMNCkNoYW1wYWlnbiwgSUwgNjE4MjAtNjIxMQ0KaHR0cDovL3d3dy5saXMuaWxsaW5v aXMuZWR1Lw0KDQoNCkZyb206IFRlc3NhIEZhbGxvbiA8dGVzc2EuZmFsbG9uQGdtYWlsLmNvbTxt YWlsdG86dGVzc2EuZmFsbG9uQGdtYWlsLmNvbT4+DQpTdWJqZWN0OiBbQ2VsbGFyXSBBZ2VuZGEg YXZhaWxhYmxlLCBXQVMgUmU6IElDWU1JOiBDRUxMQVIgbWVldGluZyBpcyBub3cgSlVMWSAyMQ0K RGF0ZTogSnVseSAxMCwgMjAxNyBhdCAxMjo0OTowNyBQTSBDRFQNClRvOiBDb2RlYyBFbmNvZGlu ZyBmb3IgTG9zc0xlc3MgQXJjaGl2aW5nIGFuZCBSZWFsdGltZSB0cmFuc21pc3Npb24gPGNlbGxh ckBpZXRmLm9yZzxtYWlsdG86Y2VsbGFyQGlldGYub3JnPj4NCg0KDQpUaGUgQ0VMTEFSIGRyYWZ0 IGFnZW5kYSBpcyBoZXJlOiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTkvYWdl bmRhL2FnZW5kYS05OS1jZWxsYXItMDANCg0KUGxlYXNlIHNlbmQgYW55IGNvbW1lbnRzIGJ5IDIz OjU5IFVUQyB0b2RheS4NCg0KQmVzdCwNClRlc3NhDQoNCg0KT24gSnVuIDI2LCAyMDE3IDE5OjU5 LCAiVGVzc2EgRmFsbG9uIiA8dGVzc2EuZmFsbG9uQGdtYWlsLmNvbTxtYWlsdG86dGVzc2EuZmFs bG9uQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhlIElFVEYgOTkgZmluYWwgYWdlbmRhIHdhcyByZWxl YXNlZCBsYXN0IEZyaWRheSBhbmQgdGhlIGRhdGUvdGltZSBmb3IgdGhlIENFTExBUiBtZWV0aW5n IGhhcyBjaGFuZ2VkLg0KDQpUaGUgQ0VMTEFSIGdyb3VwIG1lZXRpbmcgd2lsbCBiZSBoZWxkIEp1 bHkgMjEsIDk6MzAgYS5tLiAtIDExOjMwIGEubS4gKFByYWd1ZSB0aW1lKS4NCg0KQmVzdCwNCg0K VGVzc2ENCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDZWxsYXIgbWFpbGluZyBsaXN0DQpDZWxsYXJAaWV0Zi5vcmc8bWFpbHRvOkNlbGxhckBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2VsbGFyDQoN Cg== --_000_74CADF13FA0A46EC89CE1851E6E06A0Dillinoisedu_ Content-Type: text/html; charset="utf-8" Content-ID: <1A97EAAA7F519040B5AC7F1C50E90B99@mx.uillinois.edu> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdj5JcyBpdCBwb3NzaWJsZSB0 byBwdXQgbXkgMTAgbWludXRlIHByZXNlbnRhdGlvbiBhYm91dCBteSBQaEQgcmVzZWFyY2ggaW50 byB0aGUgYWdlbmRhPyBQZXJoYXBzIGVhcmx5IGluIHRoZSBtZWV0aW5nIHNvIHBlb3BsZSBrbm93 IHdoeSBJ4oCZbSB0aGVyZT88L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 PlRoYW5rIHlvdSE8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkppbWk8 L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBm b250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+SmltaSBKb25lczwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC12 YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsg Zm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5v cm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQt cG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJp YW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPlNjaG9vbCBvZiBJbmZvcm1hdGlvbg0KIFNj aWVuY2VzPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3Np dGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQt YWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9y bWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1h c2lhbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+VW5pdmVyc2l0eSBv Zg0KIElsbGlub2lzIGF0IFVyYmFuYS1DaGFtcGFpZ248L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFudC1u dW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQtdmFy aWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj4N CjUwMSBFYXN0IERhbmllbCBTdHJlZXQ8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFs OyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5v cm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3Qt YXNpYW46IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPg0KTUMtNDkzPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5h dGVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IiBjbGFzcz0iIj4NCkNoYW1wYWlnbiwgSUwgNjE4MjAtNjIxMTwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBm b250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9y bWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwOi8vd3d3Lmxpcy5pbGxpbm9pcy5lZHUvIiBjbGFz cz0iIj5odHRwOi8vd3d3Lmxpcy5pbGxpbm9pcy5lZHUvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwg c2Fucy1zZXJpZjsgY29sb3I6cmdiYSgxMjcsIDEyNywgMTI3LCAxLjApOyIgY2xhc3M9IiI+PGIg Y2xhc3M9IiI+RnJvbToNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Vi a2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+VGVzc2EgRmFsbG9uICZsdDs8YSBocmVmPSJtYWlsdG86dGVzc2EuZmFsbG9uQGdt YWlsLmNvbSIgY2xhc3M9IiI+dGVzc2EuZmFsbG9uQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNz PSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t cmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZl dGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMTI3LCAxMjcsIDEy NywgMS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1YmplY3Q6DQo8L2I+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUs IEhlbHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPltDZWxsYXJdIEFn ZW5kYSBhdmFpbGFibGUsIFdBUyBSZTogSUNZTUk6IENFTExBUiBtZWV0aW5nIGlzIG5vdyBKVUxZ IDIxPC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxl ZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5 c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpy Z2JhKDEyNywgMTI3LCAxMjcsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj5EYXRlOg0KPC9i Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhl bHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5KdWx5IDEwLCAy MDE3IGF0IDEyOjQ5OjA3IFBNIENEVDxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206 IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5z LXNlcmlmOyBjb2xvcjpyZ2JhKDEyNywgMTI3LCAxMjcsIDEuMCk7IiBjbGFzcz0iIj48YiBjbGFz cz0iIj5UbzoNCjwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5 c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+Q29kZWMgRW5jb2RpbmcgZm9yIExvc3NMZXNzIEFyY2hpdmluZyBhbmQgUmVhbHRpbWUgdHJh bnNtaXNzaW9uICZsdDs8YSBocmVmPSJtYWlsdG86Y2VsbGFyQGlldGYub3JnIiBjbGFzcz0iIj5j ZWxsYXJAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwvc3Bhbj48L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+VGhlIENFTExBUiBkcmFmdCBhZ2VuZGEgaXMgaGVyZTogJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTkvYWdlbmRhL2FnZW5kYS05OS1jZWxs YXItMDAiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk5L2FnZW5k YS9hZ2VuZGEtOTktY2VsbGFyLTAwPC9hPg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPlBsZWFzZSBzZW5kIGFu eSBjb21tZW50cyBieSAyMzo1OSBVVEMgdG9kYXkuPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+QmVz dCw8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj5UZXNzYTwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiBKdW4gMjYsIDIwMTcgMTk6NTksICZxdW90O1Rlc3NhIEZhbGxvbiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlc3NhLmZhbGxvbkBnbWFpbC5jb20iIGNsYXNzPSIi PnRlc3NhLmZhbGxvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRp b24iIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5UaGUgSUVURiA5OSBmaW5hbCBhZ2VuZGEgd2FzIHJlbGVh c2VkIGxhc3QgRnJpZGF5IGFuZCB0aGUgZGF0ZS90aW1lIGZvciB0aGUgQ0VMTEFSIG1lZXRpbmcg aGFzIGNoYW5nZWQuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ VGhlIENFTExBUiBncm91cCBtZWV0aW5nIHdpbGwgYmUgaGVsZCA8YiBjbGFzcz0iIj5KdWx5IDIx LCA5OjMwIGEubS4gLSAxMTozMCBhLm0uIChQcmFndWUgdGltZSkuPC9iPg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCw8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRlc3NhICZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxiciBjbGFzcz0iIj4NCkNlbGxhciBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVm PSJtYWlsdG86Q2VsbGFyQGlldGYub3JnIiBjbGFzcz0iIj5DZWxsYXJAaWV0Zi5vcmc8L2E+PGJy IGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZWxsYXI8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_74CADF13FA0A46EC89CE1851E6E06A0Dillinoisedu_-- From nobody Fri Jul 14 08:46:52 2017 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 37DBA129AF6 for ; Fri, 14 Jul 2017 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 xjx56u3pGVeG for ; Fri, 14 Jul 2017 08:46:49 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 166A112F290 for ; Fri, 14 Jul 2017 08:46:49 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id n205so34673099yba.1 for ; Fri, 14 Jul 2017 08:46:49 -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=n5tJlzKSctwbYQvPqxVjh+JvzXz4iluSfxPezVASwjk=; b=p58JakpjQAUWqwkp1IDHYjDyyW5KGa06UrkrRLWT+KZTo+U09QxQwoK3qHRcLDoRd2 PtVJOy6fGP2RBhsYbu0p7KIhr53SQ4m9pxY9IF2DuAvu6gvbb3dFqoAJF1FVovp1Bppf QfV4zsK3Usjto+t843V8mrM2vCme3+QYAMaBSd9gFDN6o34Lbj6x8gRMxwC/+m3Qww0A nvRY5V/LMPq0ZFOD0lfASVZ4SlyHuR+3N+LLJaAA9QOoZvOc2PBrzW2EMGaE1thgp5YS KzQVkW1asLxGdl71VbrCnnfqrfHWNoa6Ju2ZPI2L1HT8TXbaqGjf0su1XkZhIydN9ASc f/mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n5tJlzKSctwbYQvPqxVjh+JvzXz4iluSfxPezVASwjk=; b=j0mBtCs88FamlBl85/B9XZtQ/Vj8Fz/ahdp7EJg+hJv+jn9Ko116OTnE+ogaVcnV1V 7b5nIkze3VJnMbHD0NNzmhNeJUOGeiQOHbV5UVVZ6UVQVN6goLFG8MBQ4iIBt5O0Zalo X0O9Quj8JDDp/6slKHTuoGBOQy2CiBix+lP6P9Pye3aRvG8U2l1IjAA8zEj0MqqVVTc4 GnmRy3+LqWwYI+oZXaNPxJqemA41yyQD3+JkperlsyCEDwP/UNQcdCCOOLtVFYlu1Bg5 DXNJ4WWJgzlAkJTe+TP80idR67gs9QcCy4i8F9ep8EPfoOPbzMz//xggnKgX8GzOQijB 4jyw== X-Gm-Message-State: AIVw113qv9zkSvgZKtLugioh3HT+mxZ4aCclK7ksaLXIe1AQ81r4WeoM myKwk7AK171ZmTalRiRkqY3XI16V3WTl X-Received: by 10.37.209.7 with SMTP id i7mr8313793ybg.256.1500047208084; Fri, 14 Jul 2017 08:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.205 with HTTP; Fri, 14 Jul 2017 08:46:47 -0700 (PDT) From: Steve Lhomme Date: Fri, 14 Jul 2017 17:46:47 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:46:50 -0000 As I'm reviewing the various issues in the Matroska specification repo, it seems there are the issues related to the wording, clarifications on the format. And issues to define codecs and tags. While defining Matroska properly is a large task on its own, I think adding the requirement that we want all the existing supported codecs and tags in that same documentation is a huge task that may never end. I suggest moving the codec and tags documentation/specifications in their own documentation. We may also split codecs by audio/video/subtitles to make even more manageable documents. Historically I always put the codec mapping outside of the documentation because it doesn't really matter at the Matroska level what's inside a codec. It was designed specifically to not need to know anything about the codec (or tags) to be usable. So it seem(ed) logical that the documentation follows the same philosophy. Any opinions for or against this ? -- Steve Lhomme Matroska association Chairman From nobody Fri Jul 14 08:49:04 2017 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 9BFA51242F7 for ; Fri, 14 Jul 2017 08:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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=-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 WmsOuQepbQ8p for ; Fri, 14 Jul 2017 08:49:01 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 BBAB71201F2 for ; Fri, 14 Jul 2017 08:49:01 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:42784) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dW2pk-0001Eu-2u for cellar@ietf.org; Fri, 14 Jul 2017 17:48:49 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id BBEB0654000B for ; Fri, 14 Jul 2017 17:48:48 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0208.5968E7E1.00BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1500047328; bh=1YfTKQ7RwECWeQ+G/TBlIxcRV6i1KiYzJezqkYNYsPc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aMWALT3h6UmHbvxYIodU62ao7hur3uq6fhCG8z9I6MN3bGSJGRqpP2wHDHxBr1K1a 0wINYdjS6V7cdk1sqy9V0PFrpPmKVMqdtr1iIAYSCla8plDFAd5+tENxUEWY8UTqRm WzXVB8PoOYPPku+8dk/2h4snH13UED9VoWvp7b5NsXpzsojMRlk2SLZDvwnNd9LUP8 1CqOGNpbBNpHi62xKJfLX+qwJgVBcBIgRLV3cm9jSeklB6B7cXAQYYIjwduMBm4Nxw +DM59JD6UajbKbzxDGrMlDaBi+p6dqqjg6yNVMBxq9Wtvhv9MRkf8frDimkGmjplIG xRZzKee2IM7YyVCzD/UiSH1Ti7QFIKJVqGo4jGhd2YGLqEybpmWDfikoBK49rVttLb Ux65nT7txRoa/LcZgCsTA47/10408VFyd0ZVMQgnmFKYgjtf1ivV0AZ5VloRhZYGX4 LFEwg2ZKR7MEMbJ5UFZyj7xtIAJt+HAvdxcXAEJi7ysS+YpZSpI1Th17aIMb9eNGPq w0EKv2/o5MXvsvjoEkWofv/yJVAVYJZgKrMVR1CBGoSf5ooeNpazApQjTFeqlYXNmK +RX3VtzcQRuYCPwK5D6WhUnwvZQGEL3jiAxHMUt7ZxkVULPLD58Yn/hQRb9t/I5Kmo P6nVLhzU2JvrVLDyGCatW5sw= Received: by sweet-chili.local (Postfix, from userid 1000) id E50AB1B4E560; Fri, 14 Jul 2017 17:48:47 +0200 (CEST) Date: Fri, 14 Jul 2017 17:48:47 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20170714154847.khnf6jz2a6idhiki@bunkus.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Cellar] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:49:02 -0000 Hey, I concur, for the same reasons you've stated. The base format is more than enough work already and more important. This should hopefully let us focus a bit better. Kind regards, mosu From nobody Fri Jul 14 08:51:38 2017 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 DED58127ABE for ; Fri, 14 Jul 2017 08:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 f9IlhhOkjLQn for ; Fri, 14 Jul 2017 08:51:35 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 67D821201F2 for ; Fri, 14 Jul 2017 08:51:35 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v6EFpXut001561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 14 Jul 2017 17:51:33 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v6EFpWHD060272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Jul 2017 17:51:32 +0200 Date: Fri, 14 Jul 2017 17:51:33 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:51:38 -0000 Steve Lhomme wrote: >I suggest moving the codec and tags >documentation/specifications in their own documentation. +1 >Historically I always put the codec mapping outside of the >documentation because it doesn't really matter at the Matroska >level what's inside a codec. It was designed specifically to >not need to know anything about the codec (or tags) to be >usable. Indeed! Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: | Twitter: @retoch From nobody Fri Jul 14 08:56:51 2017 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 5F371127601 for ; Fri, 14 Jul 2017 08:56:50 -0700 (PDT) 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 lMUw8xXMXREZ for ; Fri, 14 Jul 2017 08:56:48 -0700 (PDT) Received: from 17.mo7.mail-out.ovh.net (17.mo7.mail-out.ovh.net [188.165.35.227]) (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 64B0B124C27 for ; Fri, 14 Jul 2017 08:56:48 -0700 (PDT) Received: from player762.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 63A4B62F7E for ; Fri, 14 Jul 2017 17:56:46 +0200 (CEST) Received: from [192.168.2.100] (p5DDB69BF.dip0.t-ipconnect.de [93.219.105.191]) (Authenticated sender: jerome@mediaarea.net) by player762.ha.ovh.net (Postfix) with ESMTPSA id B5F2CE0071 for ; Fri, 14 Jul 2017 17:56:45 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <41719fe1-18c9-09d3-38f2-03de185b609c@mediaarea.net> Date: Fri, 14 Jul 2017 17:56:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 16842618185481719953 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelkedrfeefgdeliecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 15:56:50 -0000 Le 14/07/2017 à 17:46, Steve Lhomme a écrit : > I suggest moving the codec and tags documentation/specifications in > their own documentation. +1 > We may also split codecs by > audio/video/subtitles to make even more manageable documents. I am not sure such split makes sense to split this way as audio/video/subtitles is opaque for Matroska (it is just a "tag", and Video/Audio elements in the track headers are defined in the main doc) From nobody Fri Jul 14 09:37:31 2017 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 73BA1127B57 for ; Fri, 14 Jul 2017 09:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 p35yKS9lkzsG for ; Fri, 14 Jul 2017 09:37:29 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 9ACF812702E for ; Fri, 14 Jul 2017 09:37:29 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id n205so35089934yba.1 for ; Fri, 14 Jul 2017 09:37:29 -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=kBTgQRAUs+zopgJ2yRE9RZXp356zluUImZEFqjNqyCI=; b=dN6j62W2kx7798vACt+LOVv5unvXnwTHUt7Gr5VvPi1uSsvkNE3qnYkx5ITetX9biN XNcW2HEIoICj6sAPVLa/Df4eAcFRg/Tx+B1TlT+x5CRKdcj1tbAJSKQM+51Fyks1vDU5 KBWf4myaioY1Qhylte7lNN0mqIEdWvSCBv+LsQr+/tqv9zjSVXQdYaEqS3Hv3P+T/erF MpPMITwgBtcwT46gcODcwZ4Bmv2mbcpVHo3s8CtmtKOiAecVBbXL8ECTKFe8KHDfYWsc ArA/oubbR4odfVN3Kd6GYdMaNnB7MZqd57xNqo8gYahvZ8K7BD8PBwy2vw36rrEW1iQF /bxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kBTgQRAUs+zopgJ2yRE9RZXp356zluUImZEFqjNqyCI=; b=b52NE39vmCYpRmn23e7IQ/bItJFmynNPb/E2LE8rCmaqwwgOeOJtHfF8rPu/3FHBRm e+LZmBQQeMj+2j0oFTqp5cy1h12wL0vle5Wk+XcV2QsB1VZyOvdPcC/oYHyMLJ61T7BY cIzl8lskBwFlZ6tftAT/xYJbF1V4lgylhSvx/1m6r2hxVFPb8ybUDzL9+JVyTHtlWEiN nmtQVGrIF4PqZUHGGjq/qKSwlot7soIzUsO0cYG+hEVwcGgBg3kTfgGoWezscRwLj/fB 7t4vNcnXocn+g7WTvIzO6nBPOBgn/LDju8K1dMPDwaMRf3QLxYdWKWBL7gU9n54L2bEN 6zXw== X-Gm-Message-State: AIVw111re4jbDOtFizhp9rnaRS/BY0uxWmM7nXW19PZ6s5NrgKKGx33O xyaaf63PFoSfE7hMJbqx8lpv8N7P2mH2 X-Received: by 10.37.217.213 with SMTP id q204mr8086279ybg.206.1500050248730; Fri, 14 Jul 2017 09:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.205 with HTTP; Fri, 14 Jul 2017 09:37:28 -0700 (PDT) From: Steve Lhomme Date: Fri, 14 Jul 2017 18:37:28 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Grouping Issues X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 16:37:30 -0000 As the number of issues is still quite big (23 on Matroska and 3 on EBML) I added some tags to better identify the subjects and focus on the main targets easily (IMO clarifications should come first). I added the following labels: - clarifications: parts of the specifications that needs rewording or extra text - codec mapping: issues related to codec storing in Matroska - formatting: text formatting issues - new additions: new elements, values or text sections needed - tags: tag related issues The sections are informal (the scope is quite vague) but that already helps finding what to concentrate on. -- Steve Lhomme Matroska association Chairman From nobody Fri Jul 14 10:14:50 2017 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 5DAA5129AA0 for ; Fri, 14 Jul 2017 10:14:49 -0700 (PDT) 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 f55aAIML49Yv for ; Fri, 14 Jul 2017 10:14:48 -0700 (PDT) Received: from server172-2.web-hosting.com (server172-2.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 5FCEB1270A0 for ; Fri, 14 Jul 2017 10:14:48 -0700 (PDT) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:49009 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1dW4Aw-000VGp-9x for cellar@ietf.org; Fri, 14 Jul 2017 13:14:47 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Jul 2017 13:14:44 -0400 References: <41719fe1-18c9-09d3-38f2-03de185b609c@mediaarea.net> To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <41719fe1-18c9-09d3-38f2-03de185b609c@mediaarea.net> Message-Id: <3D08D735-F11D-4156-B695-052DFF3D8367@dericed.com> X-Mailer: Apple Mail (2.3273) 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] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 17:14:49 -0000 > On Jul 14, 2017, at 11:56 AM, Jerome Martinez = wrote: >=20 > Le 14/07/2017 =C3=A0 17:46, Steve Lhomme a =C3=A9crit : >> I suggest moving the codec and tags documentation/specifications in >> their own documentation. >=20 > +1 +1 The other cellar docs are in the range of 31-39 pages while the Matroska = document is currently 216 pages! I support moving the codec section and = the tags section to separate documents. >> We may also split codecs by >> audio/video/subtitles to make even more manageable documents. >=20 > I am not sure such split makes sense to split this way as = audio/video/subtitles is opaque for Matroska (it is just a "tag", and = Video/Audio elements in the track headers are defined in the main doc) Same as Jerome. I suggest leaving the documentation for codecs together = rather than splitting by type. Dave Rice From nobody Sat Jul 15 22:56:08 2017 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 79A67129B36 for ; Sat, 15 Jul 2017 22:56:07 -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 oLKiK-rqE7LO for ; Sat, 15 Jul 2017 22:56:06 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 DE4F1120726 for ; Sat, 15 Jul 2017 22:56:05 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id l132so648061ita.1 for ; Sat, 15 Jul 2017 22:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=a5jIirbVI+2gQ9JhmBIS/yvQMxbrscJTl4W+q4jngS4=; b=fVhLw/eMv1Ma9PFGCplvJo8byZ/ruKYdVEm0/Ja0stRmrloqcY3SQxp1qNw+YNgm0v lcseXmsxhgPoLufcIIbGw2/CZjtVeSUB2nE9VCL/+o8dIMdHVBz0RUq6OPwK8eMeuQrD 75cSa0H+ay9HYB+jZ5vOuiDT+BBoD0SbA+bfCWJ8KhCc7RjtLfzj3XvYvHW408MYkkxx NWNUt3H3eS10Zceoox8lLyYmZ3yjqmYBB5baKzPLh7G8NOrnXmXUEJAHxt+Rr0Xi/OgB kkYrsM8IjMNLDiP7cqLmzNpCRwonTBemdBwmv8Kvm5XRrpGKV/zijaDgPuwF2pBXj3bu 0qNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=a5jIirbVI+2gQ9JhmBIS/yvQMxbrscJTl4W+q4jngS4=; b=JaPY2I6sVqPBLThzWoJupHOJcckYAJn34Uz/ZlpGUTXoY5cTkcvPz6dDJmwBtjxfNl bw4+w1S4DQK4/nydlaBzjZgtNFyAhx0E5tkK/hajSQAkLescrjHTI3FB13rICs3liF7l 9toTlKj/dk6pw0VD3LKrNkhFo6Sb52sOzuPcTOwSUc6FCjpk5P4HD5efZyMVWDJEb2HH Ejfy2B8gcVhbG8l1DgrW7sZvpsm45KcUPz8mnY5HCCKGuZ4J3DMGY6F0E/ObLfuwe21a RWpMG6vP7NWe1sMVBg6GF9hP25n3I4L+cGKfeoZGuLfT+y2E0TTUaysbQopaDXYW8ulx MOQw== X-Gm-Message-State: AIVw112ROnpq2BC63dLqqQokqXighgDLYq/syNwiNaLkvUztRvS5r+Hh Ge+ME7QQNzhWW7Ii8spWIvMI87FR0hhY X-Received: by 10.36.124.67 with SMTP id a64mr535802itd.25.1500184564994; Sat, 15 Jul 2017 22:56:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.186.11 with HTTP; Sat, 15 Jul 2017 22:55:24 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Sun, 16 Jul 2017 08:55:24 +0300 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114a903e182116055468f006" Archived-At: Subject: [Cellar] Fwd: Remote Participant Registration Reopened X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 05:56:07 -0000 --001a114a903e182116055468f006 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI, in case you tried to register as a remote participant and it was closed. ---------- Forwarded message ---------- From: Alexa Morris Date: Sat, Jul 15, 2017 at 4:19 PM Subject: Remote Participant Registration Reopened To: IETF general list Remote participant registration was briefly =E2=80=94 and accidentally =E2= =80=94 closed but it has now reopened. If you plan to participate remotely at IETF 99 you can register here: https://ietf.org/meeting/remote-registration.html. Please note that registration is now required for all remote participants. There is no fee to participate remotely but you will need to enter your registration ID before you will be permitted to join the Meetecho session. If you do not want to register as a remote participant you can still audit the sessions via the audio streams, which you can access from with the meeting agenda: https://datatracker.ietf.org/meeting/agenda/. Alexa --001a114a903e182116055468f006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, in case you tried to register as a remote participant= and it was closed.


---------- Forwarded message ----------
From: Alexa Morris <amorris@amsl.com>
Date: Sat, Jul 15, 2017 at 4:1= 9 PM
Subject: Remote Participant Registration Reopened
To: IETF gener= al list <ietf@ietf.org>

<= br>Remote participant registration was briefly =E2=80=94 and accidentally = =E2=80=94 closed but it has now reopened. If you plan to participate remote= ly at IETF 99 you can register here: https://ietf.o= rg/meeting/remote-registration.html.

Please note that registration is now required for all remote participants. = There is no fee to participate remotely but you will need to enter your reg= istration ID before you will be permitted to join the Meetecho session.

If you do not want to register as a remote participant you can still audit = the sessions via the audio streams, which you can access from with the meet= ing agenda: https://datatracker.ietf.org/meeting/ag= enda/.

Alexa

--001a114a903e182116055468f006-- From nobody Sun Jul 16 00:58:13 2017 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 2693812EC55 for ; Sun, 16 Jul 2017 00:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 Qg8Cj1_aA9Xm for ; Sun, 16 Jul 2017 00:58:04 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 6B7E0127180 for ; Sun, 16 Jul 2017 00:58:04 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id j80so28859039ybg.2 for ; Sun, 16 Jul 2017 00:58:04 -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=u2PSQReO52/z3g2APAuxCtTWF2aJmxuG6dnl4uHxIXE=; b=ZTAdmnq74XJY8bKWw0N3SaEnyTVQUf6Jt+q69Blc3VJSVQPqUucRlPMPBfclIjv9Gj u6dK0+Hbbq9IVRcav7jzGjI/Bm2OkyPA4MTp/v9a4mVTqRskWnwHcBS1zIJqelUqh8Lo 7qHQIscs6pjtwTpEURnjz73lwllo8dv3cox0ONPP2ufOzPxaIA0WE22HbXK1VoaBmmfE CLe+NRMMgNlxm5HpBimFgmG9FnMvv7pzcRkOnTaWPvNCxZ1f//JybvizNeuvxnZfVpFC CFqw/cJLqDyNZUtU7vnJUD4ofLai7Sqfugkv1QKv94M8p32IMx7iHDe21mcZAEOJe7JL UR1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u2PSQReO52/z3g2APAuxCtTWF2aJmxuG6dnl4uHxIXE=; b=NM5sJU0ee7llHENFh+mJ8DMK2izbjsMj/2y2TalgcskXRPBWBkcPWBkyc6W86Ia+oD iQKATro2LSHXrIIHnCH+F34CZXVpidpsZXQr0dUbWoLQWKkIe6n3/Ba/uQVJt5/nFndH G3BLBF9AoTfEl8taQNFS3UhFAsokbWjjvbY26KVEqWlHvlLSWpkXPcqh0NqgCC5hCJGf AL3gEHSNh0kPI7MtbIpTmMta7YlQFkH3rBoHCkMJOlQG6VNJbC8pB/fOB2hxJPlAxNQ0 A2OBMUYVCaN/kVXCH05MtjQJgxxtRLDbkxpbioq9i5rF39owvMhfUqufJGqeGExMDJmK 2Ydg== X-Gm-Message-State: AIVw11299PUgJBwz3Lxmd8pW/rw5z0BAv8d/8AWXtHX8ecQhg7bOOuGi iIIXNbQ61Gh6ptfCKbuoP82ZNZlC5OMWfmU= X-Received: by 10.37.250.25 with SMTP id b25mr14298863ybe.121.1500191883517; Sun, 16 Jul 2017 00:58:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.4 with HTTP; Sun, 16 Jul 2017 00:58:03 -0700 (PDT) From: Steve Lhomme Date: Sun, 16 Jul 2017 09:58:03 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 07:58:06 -0000 All the Markdown files start with: --- layout: default --- What is the reason for that ? Given we have to remove it before generating the IETF files. It seems GitHub doesn't need this header to interpret our .md files. So can we remove it ? -- Steve Lhomme Matroska association Chairman From nobody Sun Jul 16 05:09:07 2017 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 7CD5512EC06 for ; Sun, 16 Jul 2017 05:09:06 -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, 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 z3GvdqMLZkR4 for ; Sun, 16 Jul 2017 05:09:04 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9741812EBF4 for ; Sun, 16 Jul 2017 05:09:04 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so25037351uax.3 for ; Sun, 16 Jul 2017 05:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O3vOu4/8LPFHQJHa2Jix4cRXqD2K/NlTRWrAQJ7z5Ro=; b=kDZyjzEWuvck5uKSAucqtkUBJUsX9fyX94/uVnsrV6GD9jiQUtbWclzIGOmbQW2Y8a LVcSoSOTDPRM9PYMonsw2ZXRgxf6epNwAipzX0tChTZm2FfdRLZou7GBqfhZqfGIYGht mtxXsQnajlxNXQshrobAOmvs3wo/hjslWsDwXtZ8No4YzJPxZgVnc/OsZK8FeWRxSqmY jXJ/7uSFI9bh4SQkBkL+gc4PvIFRVWjIlz5m8zzQEgNyhjBtThYBhWXvV5IYGt4b5KFW GB1J2CvzsqqcCckxN3052u2YRUV+zpdQDtiEkry/nuym6yXKq5OX3MzePcLIlpwQ0W0C ILdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O3vOu4/8LPFHQJHa2Jix4cRXqD2K/NlTRWrAQJ7z5Ro=; b=SpcuxbICZEC0iIbBoZE09xrjRYhQmHHzFGdgw0vdSxfPdLRIK+zeP+NT517eLsGwin 65ULtlIE172l7sG0/qDeJkSusYM2EEVPZTpO830i/s0KXGazbNxKHwd8nazMGrPTk0MW pVkUcbZUg7JpV0rnT/kgECRV1hspfR0+uFuAvLQoFnfZj3plMQUBnvBPdRLTT1CZDIwb 7yFe7VHtVa3Olc+fINlpX1dXq1r3QLsGEvA4gDE1IbkXZIv7u6QKJQc+UKgbM9/Z1Dlr xzfT9K0iFD8AaHG0jJ5LMj3ZHalfxVClCuBRvHoj6ot88bW92vc0LjCHzCqfqkqxGidT Mdlw== X-Gm-Message-State: AIVw111r8FNOclmLBTspDDjQnO7qdVEh1tk06CG5OPfCysEZTsfXDFsG sNWbo+dyD36mXReYuFiPdZ/JewwukCP8LfQ= X-Received: by 10.159.32.133 with SMTP id 5mr10390371uaa.123.1500206943759; Sun, 16 Jul 2017 05:09:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 16 Jul 2017 05:09:03 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 16 Jul 2017 08:09:03 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c0b6202f8f29c05546e2536" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 12:09:06 -0000 --94eb2c0b6202f8f29c05546e2536 Content-Type: text/plain; charset="UTF-8" If I recall correctly, this is used by Github not for the Markdown section but for when generating a static Github-pages site. One of our goals at the time was to have that site replicate, visually, the same styles as we see on Matroska.org. You can see it generated here: http://matroska-org.github.io/matroska-specification/. Github-pages uses Jekyll to build these sites, and Jekyll needed that front-loaded YAML to know which HTML framework to pull from. If this is no longer necessary and we would prefer to narrow the scope of the repository to not include this, it can be removed. A lot of other code could be removed, too, to simplify the repo and maintain a specific purpose, like the sister-repo, ebml-specification. Ashley On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme wrote: > All the Markdown files start with: > --- > layout: default > --- > > What is the reason for that ? Given we have to remove it before > generating the IETF files. It seems GitHub doesn't need this header to > interpret our .md files. So can we remove it ? > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c0b6202f8f29c05546e2536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Jul 16, 2017 at 3:5= 8 AM, Steve Lhomme <slhomme@matroska.org> wrote:
All the Markdown files start with:
---
layout: default
---

What is the reason for that ? Given we have to remove it before
generating the IETF files. It seems GitHub doesn't need this header to<= br> interpret our .md files. So can we remove it ?

--
Steve Lhomme
Matroska association Chairman

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

--94eb2c0b6202f8f29c05546e2536-- From nobody Sun Jul 16 05:25:26 2017 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 7F237131471 for ; Sun, 16 Jul 2017 05:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 iSw_OuDXqZId for ; Sun, 16 Jul 2017 05:25:23 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 1BC02131468 for ; Sun, 16 Jul 2017 05:25:23 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-221-243-5.clienti.tiscali.it [84.221.243.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 8CE83341900 for ; Sun, 16 Jul 2017 12:25:21 +0000 (UTC) To: cellar@ietf.org References: From: Luca Barbato Message-ID: <81a44314-1441-0c95-c3f5-54ef428caf69@libav.org> Date: Sun, 16 Jul 2017 14:25:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Thunderbird/54.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 12:25:24 -0000 On 7/16/17 9:58 AM, Steve Lhomme wrote: > All the Markdown files start with: > --- > layout: default > --- > > What is the reason for that ? Given we have to remove it before > generating the IETF files. It seems GitHub doesn't need this header to > interpret our .md files. So can we remove it ? > that front-matter looks like some metadata for some specific processor (pandoc?), probably it is safe to drop if the ietf processor does not use it. lu From nobody Sun Jul 16 07:13:48 2017 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 A0A4E131667 for ; Sun, 16 Jul 2017 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 On8y3KrrchHE for ; Sun, 16 Jul 2017 07:13:35 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 13B5D12F28A for ; Sun, 16 Jul 2017 07:13:34 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id k7so1593959ybj.3 for ; Sun, 16 Jul 2017 07:13:34 -0700 (PDT) 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; bh=FvjJA3DknWkwNtw3vDtejRnX2Priqo0X0sF2sd5oKAI=; b=btkS4qaKDS1f8tbRLyilLSi3bzKyxEVDapXb4eKohy0dBIj/My3scKPSUAjYlOIoxt hntDlqNnP4CSF3Dux3aEF/U3rw0cDAjiikDEBpGfFpOomc5doNOKUnQE8YABqyl/+0xV vwJPV/yVllMpD9QdAAd9AD/9cdd7lRDddYbfbF6Vv9h+nbFR1O/EjK8QnKsC7/fNVm9O V/kQOeT2/NUYiA0Uk4rWmaWyruFUe4+1JVFwfAZf7kS6WWFVjkiqzLCv3IdrBqw5V3Bd nqwC73vYtFCK6yF++UG5JQgfn2XL0rXCqZ9XzjZYnkFxbEFYJ4Cx2DrAWbby4nFpjPKV T4Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FvjJA3DknWkwNtw3vDtejRnX2Priqo0X0sF2sd5oKAI=; b=c8Y5kAb+Y+TSlsGL7NlBOTQaunManxMneXL95X8KsBdZ0z5Ap6VEjngMDTUdJiUEmY uzDH6XUTR+Rzq8iEz5wTFlcNMDeNjN+aDXiJmSL2MXXVhU7aOU1HxNyfhQsVjeoS83UL yYBCgIGwcsbVssRgusKFOPC56hGZc5BO4owNCZMAX1TZfQaLQo1sL24fSpglOZcSymMG 5XgMStpc0rckU+7f0wwdDCzoNpTreTkPXP0WbI+Fj+HwMWiWsGdUcQ+2nUZzvSxCjLyd ZDLjY9Cer6nLoXa11xX78qvTTXd/NvnobzorARgGW17hnnvaBIZI23VKyWgECEmxIecQ mkZA== X-Gm-Message-State: AIVw110WBSkz9vuF5EG527iBmasZqV4GPJWIAoqebgAvq6LURxBCuAQq /eWxjygukIJYXRAYdlubKtXdLE5cwQ+ODSk= X-Received: by 10.37.250.25 with SMTP id b25mr15232758ybe.121.1500214413109; Sun, 16 Jul 2017 07:13:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.4 with HTTP; Sun, 16 Jul 2017 07:13:32 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Jul 2017 16:13:32 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:13:37 -0000 2017-07-16 14:09 GMT+02:00 Ashley Blewer : > If I recall correctly, this is used by Github not for the Markdown section > but for when generating a static Github-pages site. One of our goals at the > time was to have that site replicate, visually, the same styles as we see on > Matroska.org. You can see it generated here: > http://matroska-org.github.io/matroska-specification/. Github-pages uses > Jekyll to build these sites, and Jekyll needed that front-loaded YAML to > know which HTML framework to pull from. > > If this is no longer necessary and we would prefer to narrow the scope of > the repository to not include this, it can be removed. A lot of other code > could be removed, too, to simplify the repo and maintain a specific purpose, > like the sister-repo, ebml-specification. Ah, that would explain the {{site.baseurl}} stuff in the code as well. It may work with the website generator but it gives bogus links in IETF for the HTML output. That's issue #145 that you saw. https://github.com/Matroska-Org/matroska-specification/issues/145 I don't know yet how to do proper link inside the same documents on the IETF doc. But depending on the working solution it may or may not be compatible with the website generator. > Ashley > > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme wrote: >> >> All the Markdown files start with: >> --- >> layout: default >> --- >> >> What is the reason for that ? Given we have to remove it before >> generating the IETF files. It seems GitHub doesn't need this header to >> interpret our .md files. So can we remove it ? >> >> -- >> 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 Sun Jul 16 07:26:21 2017 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 628DB127342 for ; Sun, 16 Jul 2017 07:26:20 -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 qt1PJyHIEcr5 for ; Sun, 16 Jul 2017 07:26:16 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9F5126D73 for ; Sun, 16 Jul 2017 07:26:16 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id v193so39532452ywg.2 for ; Sun, 16 Jul 2017 07:26:16 -0700 (PDT) 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; bh=t2r0u9k2HFKvnDouRYcvvy/Xerjj7GIW0sWENjTM7tY=; b=FK8SKMKCCz5tunzMKTYzGCu7GN2Aqx8z7zPtE5VVQayN+JKLT8keCFBnXXgSbl5ATY Csr2maL0ztjq6i0X26FQzHVY4A0YYBMJ7GlBc4wg8bwAXC8cL/fKdu5JEhoUvHQ+Cfta +xRRRHJSWxzBQq6JjtVjoCPjvKOamY16tIfdbJ+b8zKiFgJzTEpl+MVzUYu69RrXX0H9 3D7chni9mem6nUjrgHr69hCMRH4+zSo/yyj5+OrWxxoXP1Ow6vEtQLdpUZogTs6LT7JF VkxSkJ6Bp8qWf/v1lpHSesYR7CGO5DqlSLLGBcPfnIRj1VC+8jDFMxjA7XViuR/o6Ty1 m1jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t2r0u9k2HFKvnDouRYcvvy/Xerjj7GIW0sWENjTM7tY=; b=exzsNHp76Z1ez9A6dBHWPZ/11jLpBA4t8o/kRHSqJBzBWTJkKWYNcRdnBgvxl9gxYs antc0uRnFQxsGYorGwfFgOwz6QfvrNr9fJ6/r58H8405G/ia2ycNWZiI36HNcO8jmHkE QhgCH9ujHJUcdsUn57zkZoVxcb2Pf7+EnC944evuEaDJUzXjXxMsnKXnLgPCSZEPyvDG 1KZw6yIgMw3DSctx3yGX7fSJtBfz+RudSiMuvP9YaHH7B1J0AxfQhcd+kJVxCw7+tkPX qCQfCMJuXOI+PB5oZf4k4j2veGH8/RX0ffs6QaVrNkGZj2/2ZsMRuGVUDo8KiAHKcUgg GBrQ== X-Gm-Message-State: AIVw113bPuYG6BET/2BKjgNXscwASATp03m6DNhEy8Wtq4CFiDfuaxjx bGxwG0DI8nanoQFwhlfTQJEdIoCn4Lj+gXw= X-Received: by 10.129.183.31 with SMTP id v31mr4311618ywh.123.1500215175619; Sun, 16 Jul 2017 07:26:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.4 with HTTP; Sun, 16 Jul 2017 07:26:15 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Jul 2017 16:26:15 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:26:20 -0000 2017-07-16 14:09 GMT+02:00 Ashley Blewer : > If I recall correctly, this is used by Github not for the Markdown section > but for when generating a static Github-pages site. One of our goals at the > time was to have that site replicate, visually, the same styles as we see on > Matroska.org. You can see it generated here: > http://matroska-org.github.io/matroska-specification/. Github-pages uses > Jekyll to build these sites, and Jekyll needed that front-loaded YAML to > know which HTML framework to pull from. It seems we could instead use an external file to achieve the same thing ? https://jekyllrb.com/docs/configuration/#front-matter-defaults This way we can just keep the Markdown cleaner. It seems some of the {{}} will still need to be worked out though. If we want to keep both compatibility we might pre-process the Markdown files before so that links end up correct in both cases. As we clean the Matroska specs there will probably parts that go away or may be reordered. And I fear this is going to be a lot of extra work to keep both sides happy. Or it would be easier if the pre-process takes clean RFC-compatible Markdown and changes the things that are necessary for Jekyll/YAML. > If this is no longer necessary and we would prefer to narrow the scope of > the repository to not include this, it can be removed. A lot of other code > could be removed, too, to simplify the repo and maintain a specific purpose, > like the sister-repo, ebml-specification. > > Ashley > > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme wrote: >> >> All the Markdown files start with: >> --- >> layout: default >> --- >> >> What is the reason for that ? Given we have to remove it before >> generating the IETF files. It seems GitHub doesn't need this header to >> interpret our .md files. So can we remove it ? >> >> -- >> 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 Sun Jul 16 07:27:06 2017 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 C1B66127342 for ; Sun, 16 Jul 2017 07:27:04 -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, 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 VcCjXki_Ql8I for ; Sun, 16 Jul 2017 07:27:02 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 478DB126D73 for ; Sun, 16 Jul 2017 07:27:02 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id j53so72699016uaa.2 for ; Sun, 16 Jul 2017 07:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PUpOnHJDJsV4JvHKSulBHfTKxMiJrXdNT8HKXIE3DfA=; b=Jim9CKHOc5K+utiKFFH0xCr8T2A3Q4e4Kkl3HEzW0alJDl4BXAch0632lRHYYy518W o7AGgCVZ5AG+TUOoc7ot024hIak1qlchhv/j6DCUeBNRwD94s8AA3DFfpGlxC6fcSv/4 G7ugiYIOW057RHeW6dRl0M67831aspl2qRq7EUkL9qAGxs6purpjkV3Qie2rISLTVhDH y968tIOBqP7Wybo/3laM6mI9TiAjtH9VPiStokwVOXPK62kKTYBloDuTHohybWOvi3HK 9+sWsWuEBhVQFqAg+Kszrir+feJUWbfzxHgLbWXxfIMmpEcT9yhopYRJPDxVGkdG7j8p 48mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PUpOnHJDJsV4JvHKSulBHfTKxMiJrXdNT8HKXIE3DfA=; b=inxGYOz80iWf+9Id0bezq2x+9/0mJ1zbgTM2YXvV/IN3lkDg+cfJe2xgJHS0GQNQO/ OS4ZZR730Z5t5W1sf4ASC3JO55Lpy60PMJXx9KOOviN+ZEVqFv3ThrHqcpVPjpepO9qP U7/2QngpcE/EAMtIkijP0rRkfZ5AkfJ8TvCg7Tomgi1TbPQScgRZIfMS6CjKB3oyEmKl UNt08de6Iknlv43ewN6uU+vZvhzDnrqZz56e+Q3YTsAszcI7EWo4SxxqueuGlGLGaSD9 t7pTSv4UqsSxRP2l0a64e8BxE55NghRyWn9lyV6fRx6Z+TONB4NcdRMDbMro+70q7rkk Oguw== X-Gm-Message-State: AIVw1129VxxcnxlSC7REM18SN+kVIbVCKKn16ArXyBKTbzitnSrx4uB6 y97ZhBzGf6lLRmbE0jG0kGkg6ULqew== X-Received: by 10.159.32.133 with SMTP id 5mr10619589uaa.123.1500215221446; Sun, 16 Jul 2017 07:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 16 Jul 2017 07:27:00 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 16 Jul 2017 10:27:00 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c0b62025c6b630554701347" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:27:05 -0000 --94eb2c0b62025c6b630554701347 Content-Type: text/plain; charset="UTF-8" Yep, it causes the {{site.baseurl}}, the _includes folder, the css and sass folders, and probably some other stuff. I'm happy to volunteer to scrape this stuff out responsibly if we find that it's no longer essential, or that the documentation has grown to the point where we should only be strictly considering the schema's path-to-IETF. We can always bring the fancy-site-building back. On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhomme wrote: > 2017-07-16 14:09 GMT+02:00 Ashley Blewer : > > If I recall correctly, this is used by Github not for the Markdown > section > > but for when generating a static Github-pages site. One of our goals at > the > > time was to have that site replicate, visually, the same styles as we > see on > > Matroska.org. You can see it generated here: > > http://matroska-org.github.io/matroska-specification/. Github-pages uses > > Jekyll to build these sites, and Jekyll needed that front-loaded YAML to > > know which HTML framework to pull from. > > > > If this is no longer necessary and we would prefer to narrow the scope of > > the repository to not include this, it can be removed. A lot of other > code > > could be removed, too, to simplify the repo and maintain a specific > purpose, > > like the sister-repo, ebml-specification. > > Ah, that would explain the {{site.baseurl}} stuff in the code as well. > It may work with the website generator but it gives bogus links in > IETF for the HTML output. That's issue #145 that you saw. > https://github.com/Matroska-Org/matroska-specification/issues/145 > > I don't know yet how to do proper link inside the same documents on > the IETF doc. But depending on the working solution it may or may not > be compatible with the website generator. > > > Ashley > > > > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme > wrote: > >> > >> All the Markdown files start with: > >> --- > >> layout: default > >> --- > >> > >> What is the reason for that ? Given we have to remove it before > >> generating the IETF files. It seems GitHub doesn't need this header to > >> interpret our .md files. So can we remove it ? > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > >> > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c0b62025c6b630554701347 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yep, it causes the {{site.baseurl}}, the _includes folder,= the css and sass folders, and probably some other stuff. I'm happy to = volunteer to scrape this stuff out responsibly if we find that it's no = longer essential, or that the documentation has grown to the point where we= should only be strictly considering the schema's path-to-IETF. We can = always bring the fancy-site-building back.
=
On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhom= me <slhomme@matroska.org> wrote:
2017-07-16 14:09 GMT+02:00 Ashley Blewer <ashley.blewer@gmail.com>: > If I recall correctly, this is used by Github not for the Markdown sec= tion
> but for when generating a static Github-pages site. One of our goals a= t the
> time was to have that site replicate, visually, the same styles as we = see on
> Matroska.org. You can see it generated here:
> http://matroska-org.github.io/matros= ka-specification/. Github-pages uses
> Jekyll to build these sites, and Jekyll needed that front-loaded YAML = to
> know which HTML framework to pull from.
>
> If this is no longer necessary and we would prefer to narrow the scope= of
> the repository to not include this, it can be removed. A lot of other = code
> could be removed, too, to simplify the repo and maintain a specific pu= rpose,
> like the sister-repo, ebml-specification.

Ah, that would explain the {{site.baseurl}} stuff in the code as wel= l.
It may work with the website generator but it gives bogus links in
IETF for the HTML output. That's issue #145 that you saw.
https://github.com/Matroska-Or= g/matroska-specification/issues/145

I don't know yet how to do proper link inside the same documents on
the IETF doc. But depending on the working solution it may or may not
be compatible with the website generator.

> Ashley
>
> On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>>
>> All the Markdown files start with:
>> ---
>> layout: default
>> ---
>>
>> What is the reason for that ? Given we have to remove it before >> generating the IETF files. It seems GitHub doesn't need this h= eader to
>> interpret our .md files. So can we remove it ?
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cell= ar
>
>



--
Steve Lhomme
Matroska association Chairman

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

--94eb2c0b62025c6b630554701347-- From nobody Sun Jul 16 07:29:11 2017 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 C1CAC1287A0 for ; Sun, 16 Jul 2017 07:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 tM-VDakJIEaM for ; Sun, 16 Jul 2017 07:29:07 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::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 B36E0127342 for ; Sun, 16 Jul 2017 07:29:07 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id j80so29865167ybg.2 for ; Sun, 16 Jul 2017 07:29:07 -0700 (PDT) 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=avFJPfveZtWf7NDx5d1PkxGt/MZr7KspOsDLINO3ct8=; b=q1Eo0PFn8TWzwcJg3oIaI9Khz8kzMO4gO8F/K2GNvpUkO+xUAA8y4hWPWgl9tjrJo1 uhMK4QBlz121XfhE0pL9quHwzu6f63G9TpfcKqd5LoaWi5bxRIhXWRZ4YIzuhV5ptlhF 6RD8nDz3FI4QCM9XYUcuHOhdhSf0Y32YsIDQFBJttZTvgvIMu2iG6Zg+m0oU6/efddaW pc698Ei7ssSgcHvHAEVfmBb/ubXF9JmkDN6v8Do0kuCUbKFgdRv5Sj2Qu/c/+17Lvw42 87Wd0Y3q7HbHaOWTa44zBuoY+xMxDH6lDURBfZ+fADOaJokV4eC/cI8iq59KcBPOwHOo OjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=avFJPfveZtWf7NDx5d1PkxGt/MZr7KspOsDLINO3ct8=; b=V38JXjHFFt26wNxbRW7AYftbxpc0cPYmHyXvVFjDtbL1RIuq1pQf/WeAwZaTqP0IvX bi/bvb/xXq2jtxO2qP4a8njDYwAM3PgN7qqdkOp/YMOG2Km4bXwgEafXkhEa/b/PRxuQ tZ3vW0Sptt3r6evSNnZJJR8mIta1jjRZ72HlhxDmgEcfj4havMzJnEVaM9mMS2zV5+xZ u3rXFu/KCmc5uqgYdJnNkiGNNh0ifQ+KYKWDz1gkjVhd7QjiJUhLpxJL+gF9sYKB1F8g LIrVo+mr0uxozgTNLeX2OxJd7j5wJsv8VH7XnNRXjw0HmCSKEDMCNkIfcbcT5GMcf74G Cnxw== X-Gm-Message-State: AIVw113hZaSe7eiSMWCot+DJ5tVKvGS8Psq7KBJqQhbCozzkmZmMMpRq yfOB/cz+BpuZ1PEwus3EjZTU35OJpmtx X-Received: by 10.37.18.11 with SMTP id 11mr13869722ybs.212.1500215346961; Sun, 16 Jul 2017 07:29:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.4 with HTTP; Sun, 16 Jul 2017 07:29:06 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Jul 2017 16:29:06 +0200 Message-ID: To: Ashley Blewer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:29:10 -0000 Actually before getting rid of it, it might be interesting to be able to generate these same pages locally (via the Makefile). This way we can test solutions to keep both happy without breaking anything online. 2017-07-16 16:27 GMT+02:00 Ashley Blewer : > Yep, it causes the {{site.baseurl}}, the _includes folder, the css and sass > folders, and probably some other stuff. I'm happy to volunteer to scrape > this stuff out responsibly if we find that it's no longer essential, or that > the documentation has grown to the point where we should only be strictly > considering the schema's path-to-IETF. We can always bring the > fancy-site-building back. > > On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhomme wrote: >> >> 2017-07-16 14:09 GMT+02:00 Ashley Blewer : >> > If I recall correctly, this is used by Github not for the Markdown >> > section >> > but for when generating a static Github-pages site. One of our goals at >> > the >> > time was to have that site replicate, visually, the same styles as we >> > see on >> > Matroska.org. You can see it generated here: >> > http://matroska-org.github.io/matroska-specification/. Github-pages uses >> > Jekyll to build these sites, and Jekyll needed that front-loaded YAML to >> > know which HTML framework to pull from. >> > >> > If this is no longer necessary and we would prefer to narrow the scope >> > of >> > the repository to not include this, it can be removed. A lot of other >> > code >> > could be removed, too, to simplify the repo and maintain a specific >> > purpose, >> > like the sister-repo, ebml-specification. >> >> Ah, that would explain the {{site.baseurl}} stuff in the code as well. >> It may work with the website generator but it gives bogus links in >> IETF for the HTML output. That's issue #145 that you saw. >> https://github.com/Matroska-Org/matroska-specification/issues/145 >> >> I don't know yet how to do proper link inside the same documents on >> the IETF doc. But depending on the working solution it may or may not >> be compatible with the website generator. >> >> > Ashley >> > >> > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme >> > wrote: >> >> >> >> All the Markdown files start with: >> >> --- >> >> layout: default >> >> --- >> >> >> >> What is the reason for that ? Given we have to remove it before >> >> generating the IETF files. It seems GitHub doesn't need this header to >> >> interpret our .md files. So can we remove it ? >> >> >> >> -- >> >> Steve Lhomme >> >> Matroska association Chairman >> >> >> >> _______________________________________________ >> >> Cellar mailing list >> >> Cellar@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cellar >> > >> > >> >> >> >> -- >> 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 Sun Jul 16 07:33:17 2017 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 C5C06129B5E for ; Sun, 16 Jul 2017 07:33:15 -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, 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 wuzPn3yoUvZL for ; Sun, 16 Jul 2017 07:33:13 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 87EF0127342 for ; Sun, 16 Jul 2017 07:33:13 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 35so25868313uax.3 for ; Sun, 16 Jul 2017 07:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ojjXujZ3mbUPoUlUmMYnD3zj/CJHTbS7KSIyY0cVH8I=; b=FRoNfML+/ykBuCIqgJxsNFVXG4h2zGFMSXArNz4LDmBkfa+9cJJ//Nd0dFAti47oGY iozcU+EvQAS1JUSMsqnEzbNso0qrXw7nj4upYEYL6yybsAKlBazRqvnYkG4f/XHs1M0G WZdnGLe3lHigbaqxC3JSwUVInGTXJgWPwA0NIjwK2G9M0+bu9hfdrbKd4WBS1VNtg6Ii JyX9aGj3B3Wc/smAwRbZgkqZh9ZTMRHWVuvVUELUEFsfGGVj4ZE6CCJfp4PGv8+oYoPr n3p/z4LdfJvHRuOILieumKj5mBGPtgEH5KZnVvaXKUZcFUEQtleS6nk35xHLmWRneaMU 19gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ojjXujZ3mbUPoUlUmMYnD3zj/CJHTbS7KSIyY0cVH8I=; b=LQjUJYTXEgLPUPckslo5GF0IezrMUkd2vbxRPLp6F7oMsHHw5eRbMwqUAkJBs8/kT2 tgHGJdAuCpG9voKaaExR3iM2lC+/kvRqYgeGNxx2uuQRwaIMQCBn65Y8apqArS7TH/MX BPGsDVWJ0kXVxuJo0JbVXC6K13i/FT6v3zqwxMp05WYHG2f2jq22DoKRqtV92x7grSY0 FTAuRUzn5FLc4SEy0kGgRd8qEyIyO2CT8ONDCikwKAD9e9F+KVk/p7Fahy0wSnTetDMF VPy3g+/shr8LW7/H+/ex6jp3AlN+5d6J66ZpA00L0MYMY4s2o2St6zxnRxC7M6j82zfi P8Xw== X-Gm-Message-State: AIVw112+sAMNTUIK6ZItvUNVjhPaJuPBL2Yt6oD7VwqJLFsjYA8Nm/Jr 7aVQZxpNJgI64TW7AMDwSVN7RHh7vZEN X-Received: by 10.176.84.10 with SMTP id n10mr2025264uaa.139.1500215592616; Sun, 16 Jul 2017 07:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 16 Jul 2017 07:33:12 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 16 Jul 2017 10:33:12 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c1b12287c0a090554702919" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:33:16 -0000 --94eb2c1b12287c0a090554702919 Content-Type: text/plain; charset="UTF-8" Steve, could you assign me a ticket in Github in that repo? And I'll take a look at cleaning this up (since I'm the one who put it there in the first place). I'm inclined to not do any of this work immediately before the IETF CELLAR meeting (including a merge of your split-into-3 PR that I was looking at this morning) but happy to tackle it. Ashley On Sun, Jul 16, 2017 at 10:29 AM, Steve Lhomme wrote: > Actually before getting rid of it, it might be interesting to be able > to generate these same pages locally (via the Makefile). This way we > can test solutions to keep both happy without breaking anything > online. > > 2017-07-16 16:27 GMT+02:00 Ashley Blewer : > > Yep, it causes the {{site.baseurl}}, the _includes folder, the css and > sass > > folders, and probably some other stuff. I'm happy to volunteer to scrape > > this stuff out responsibly if we find that it's no longer essential, or > that > > the documentation has grown to the point where we should only be strictly > > considering the schema's path-to-IETF. We can always bring the > > fancy-site-building back. > > > > On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhomme > wrote: > >> > >> 2017-07-16 14:09 GMT+02:00 Ashley Blewer : > >> > If I recall correctly, this is used by Github not for the Markdown > >> > section > >> > but for when generating a static Github-pages site. One of our goals > at > >> > the > >> > time was to have that site replicate, visually, the same styles as we > >> > see on > >> > Matroska.org. You can see it generated here: > >> > http://matroska-org.github.io/matroska-specification/. Github-pages > uses > >> > Jekyll to build these sites, and Jekyll needed that front-loaded YAML > to > >> > know which HTML framework to pull from. > >> > > >> > If this is no longer necessary and we would prefer to narrow the scope > >> > of > >> > the repository to not include this, it can be removed. A lot of other > >> > code > >> > could be removed, too, to simplify the repo and maintain a specific > >> > purpose, > >> > like the sister-repo, ebml-specification. > >> > >> Ah, that would explain the {{site.baseurl}} stuff in the code as well. > >> It may work with the website generator but it gives bogus links in > >> IETF for the HTML output. That's issue #145 that you saw. > >> https://github.com/Matroska-Org/matroska-specification/issues/145 > >> > >> I don't know yet how to do proper link inside the same documents on > >> the IETF doc. But depending on the working solution it may or may not > >> be compatible with the website generator. > >> > >> > Ashley > >> > > >> > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme > >> > wrote: > >> >> > >> >> All the Markdown files start with: > >> >> --- > >> >> layout: default > >> >> --- > >> >> > >> >> What is the reason for that ? Given we have to remove it before > >> >> generating the IETF files. It seems GitHub doesn't need this header > to > >> >> interpret our .md files. So can we remove it ? > >> >> > >> >> -- > >> >> Steve Lhomme > >> >> Matroska association Chairman > >> >> > >> >> _______________________________________________ > >> >> Cellar mailing list > >> >> Cellar@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/cellar > >> > > >> > > >> > >> > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > >> > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > -- > Steve Lhomme > Matroska association Chairman > --94eb2c1b12287c0a090554702919 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Steve, could you assign me a ticket in Github in that repo= ? And I'll take a look at cleaning this up (since I'm the one who p= ut it there in the first place).=C2=A0

I'm inclined = to not do any of this work immediately before the IETF CELLAR meeting (incl= uding a merge of your split-into-3 PR that I was looking at this morning) b= ut happy to tackle it.


Ashley
=

On Sun, Jul= 16, 2017 at 10:29 AM, Steve Lhomme <slhomme@matroska.org> wrote:
Actually before getting rid of i= t, it might be interesting to be able
to generate these same pages locally (via the Makefile). This way we
can test solutions to keep both happy without breaking anything
online.

2017-07-16 16:27 GMT+02:00 Ashley Blewer <ashley.blewer@gmail.com>:
> Yep, it causes the {{site.baseurl}}, the _includes folder, the css and= sass
> folders, and probably some other stuff. I'm happy to volunteer to = scrape
> this stuff out responsibly if we find that it's no longer essentia= l, or that
> the documentation has grown to the point where we should only be stric= tly
> considering the schema's path-to-IETF. We can always bring the
> fancy-site-building back.
>
> On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>>
>> 2017-07-16 14:09 GMT+02:00 Ashley Blewer <ashley.blewer@gmail.com>:
>> > If I recall correctly, this is used by Github not for the Mar= kdown
>> > section
>> > but for when generating a static Github-pages site. One of ou= r goals at
>> > the
>> > time was to have that site replicate, visually, the same styl= es as we
>> > see on
>> > Matroska.org. You can see it generated here:
>> > http://matroska-org.github.io/matroska-specification/. Github-pages uses
>> > Jekyll to build these sites, and Jekyll needed that front-loa= ded YAML to
>> > know which HTML framework to pull from.
>> >
>> > If this is no longer necessary and we would prefer to narrow = the scope
>> > of
>> > the repository to not include this, it can be removed. A lot = of other
>> > code
>> > could be removed, too, to simplify the repo and maintain a sp= ecific
>> > purpose,
>> > like the sister-repo, ebml-specification.
>>
>> Ah, that would explain the {{site.baseurl}} stuff in the code as w= ell.
>> It may work with the website generator but it gives bogus links in=
>> IETF for the HTML output. That's issue #145 that you saw.
>> https://github.com/Matrosk= a-Org/matroska-specification/issues/145
>>
>> I don't know yet how to do proper link inside the same documen= ts on
>> the IETF doc. But depending on the working solution it may or may = not
>> be compatible with the website generator.
>>
>> > Ashley
>> >
>> > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme <slhomme@matroska.org>
>> > wrote:
>> >>
>> >> All the Markdown files start with:
>> >> ---
>> >> layout: default
>> >> ---
>> >>
>> >> What is the reason for that ? Given we have to remove it = before
>> >> generating the IETF files. It seems GitHub doesn't ne= ed this header to
>> >> interpret our .md files. So can we remove it ?
>> >>
>> >> --
>> >> Steve Lhomme
>> >> Matroska association Chairman
>> >>
>> >> _______________________________________________
>> >> Cellar mailing list
>> >> Cellar@ietf.org >> >> https://www.ietf.org/mailman/list= info/cellar
>> >
>> >
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cell= ar
>
>



--
Steve Lhomme
Matroska association Chairman

--94eb2c1b12287c0a090554702919-- From nobody Sun Jul 16 07:36:30 2017 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 DEB9112EB99 for ; Sun, 16 Jul 2017 07:36:28 -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 mTbZKMqSkqQy for ; Sun, 16 Jul 2017 07:36:27 -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 2AD7B127342 for ; Sun, 16 Jul 2017 07:36:27 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id a12so39516378ywh.3 for ; Sun, 16 Jul 2017 07:36:27 -0700 (PDT) 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=7nxj9GkCY63EbC7UwfEzXD8jG+kz4XDMnNckljeVDp4=; b=RVYazeUAWJ6lj2ElDR9uqRLy6ovYOd/LlxEdSvnis4/A3uo6HatYxOrH6nqr5uopgj QEITYfTfnz4hkJ6ObEiHlRA8XroaLFbIFpcFqENFBBCedzYyZVUyJR2Uja1wAW1dSY3T rrQ90/3QsvfyurGDFBWW9srgyqnTxeBAK8f53qnd16aIvw7Q/uLQeEPo93PSihg0ghqX gsVa6MhkwR58wvrmeqsG7XUmuB5ZXQ00rhoxFsoz5M1vPrTWNathM7bKCjcNy8BTYhlG JKu+wpZsJ2aFHfSpi6C6gdiRYFhUfHAH8k/aYoAKZdmWZUlOk6EnvezsWgaB6yNZlSzm Ye+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7nxj9GkCY63EbC7UwfEzXD8jG+kz4XDMnNckljeVDp4=; b=BdSn4/6q8R7uN/G+Zs1+1fSlgKZqaUgp7Hekqeul9pBuM6ookxK0eBNb9QNIcXhapM BndEqfipKytXY/5dcaG3mD2KjU388P4uszFTD84nUkegM6KFnF8e/Lzy8KyeejHjB4vU ozO9uuq1J5womWdJMJ0PvpU7Z+N9QCMPBa2V0tyq/1APDMRDLeA/Eb38uYC+Cc2K6iY2 Ffa0TpeRWK8Dwt0Tpd56bvjNXeTx06tu9xkcb9OPadXrlDIKx80TMhyeE8LqLQyiZjdb ZxiLF7cWThie4yyyoFWW9t2iZWSKrhkHSQsIu4Lu0zTt6e9bjurzoQ+jhjETnivxaGmH YAAA== X-Gm-Message-State: AIVw111tt5QdHZTojE/NqdieLhAzCvIkFHjnB+3HveiWl6bV8HC1H/q6 S0d01BOYH+vdGd3tgvqiAyd9JtHQjIOws5U= X-Received: by 10.13.232.135 with SMTP id r129mr4470724ywe.87.1500215786343; Sun, 16 Jul 2017 07:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.42.4 with HTTP; Sun, 16 Jul 2017 07:36:25 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Jul 2017 16:36:25 +0200 Message-ID: To: Ashley Blewer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:36:29 -0000 Here it is: https://github.com/Matroska-Org/matroska-specification/issues/146 2017-07-16 16:33 GMT+02:00 Ashley Blewer : > Steve, could you assign me a ticket in Github in that repo? And I'll take a > look at cleaning this up (since I'm the one who put it there in the first > place). > > I'm inclined to not do any of this work immediately before the IETF CELLAR > meeting (including a merge of your split-into-3 PR that I was looking at > this morning) but happy to tackle it. > > > Ashley > > On Sun, Jul 16, 2017 at 10:29 AM, Steve Lhomme wrote: >> >> Actually before getting rid of it, it might be interesting to be able >> to generate these same pages locally (via the Makefile). This way we >> can test solutions to keep both happy without breaking anything >> online. >> >> 2017-07-16 16:27 GMT+02:00 Ashley Blewer : >> > Yep, it causes the {{site.baseurl}}, the _includes folder, the css and >> > sass >> > folders, and probably some other stuff. I'm happy to volunteer to scrape >> > this stuff out responsibly if we find that it's no longer essential, or >> > that >> > the documentation has grown to the point where we should only be >> > strictly >> > considering the schema's path-to-IETF. We can always bring the >> > fancy-site-building back. >> > >> > On Sun, Jul 16, 2017 at 10:13 AM, Steve Lhomme >> > wrote: >> >> >> >> 2017-07-16 14:09 GMT+02:00 Ashley Blewer : >> >> > If I recall correctly, this is used by Github not for the Markdown >> >> > section >> >> > but for when generating a static Github-pages site. One of our goals >> >> > at >> >> > the >> >> > time was to have that site replicate, visually, the same styles as we >> >> > see on >> >> > Matroska.org. You can see it generated here: >> >> > http://matroska-org.github.io/matroska-specification/. Github-pages >> >> > uses >> >> > Jekyll to build these sites, and Jekyll needed that front-loaded YAML >> >> > to >> >> > know which HTML framework to pull from. >> >> > >> >> > If this is no longer necessary and we would prefer to narrow the >> >> > scope >> >> > of >> >> > the repository to not include this, it can be removed. A lot of other >> >> > code >> >> > could be removed, too, to simplify the repo and maintain a specific >> >> > purpose, >> >> > like the sister-repo, ebml-specification. >> >> >> >> Ah, that would explain the {{site.baseurl}} stuff in the code as well. >> >> It may work with the website generator but it gives bogus links in >> >> IETF for the HTML output. That's issue #145 that you saw. >> >> https://github.com/Matroska-Org/matroska-specification/issues/145 >> >> >> >> I don't know yet how to do proper link inside the same documents on >> >> the IETF doc. But depending on the working solution it may or may not >> >> be compatible with the website generator. >> >> >> >> > Ashley >> >> > >> >> > On Sun, Jul 16, 2017 at 3:58 AM, Steve Lhomme >> >> > wrote: >> >> >> >> >> >> All the Markdown files start with: >> >> >> --- >> >> >> layout: default >> >> >> --- >> >> >> >> >> >> What is the reason for that ? Given we have to remove it before >> >> >> generating the IETF files. It seems GitHub doesn't need this header >> >> >> to >> >> >> interpret our .md files. So can we remove it ? >> >> >> >> >> >> -- >> >> >> Steve Lhomme >> >> >> Matroska association Chairman >> >> >> >> >> >> _______________________________________________ >> >> >> Cellar mailing list >> >> >> Cellar@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/cellar >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Steve Lhomme >> >> Matroska association Chairman >> >> >> >> _______________________________________________ >> >> Cellar mailing list >> >> Cellar@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cellar >> > >> > >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman > > -- Steve Lhomme Matroska association Chairman From nobody Sun Jul 16 07:56:04 2017 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 EB45C124D68 for ; Sun, 16 Jul 2017 07:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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=-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 s8TB3XwCWZmL for ; Sun, 16 Jul 2017 07:56:01 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 ADE7C1200C1 for ; Sun, 16 Jul 2017 07:56:01 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:49920) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dWkxY-0005Bn-2K for cellar@ietf.org; Sun, 16 Jul 2017 16:55:49 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 8114B6540012 for ; Sun, 16 Jul 2017 16:55:48 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0202.596B7E75.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1500216948; bh=LoL3tM/0OTgbqoVNtvzFzAKiXUItiA7OeNCpmK3hg6s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=v5aXZ74zh6NYFeesx+9sF3nIdhCq5F/NsO2P/gqtrynsMiMff+oYr2hi44S9uRGPF 5W//N9q1pMKKZi4Phk3pavaYwWoSg+NYTjA5ylew2kz1zN/X4Bs1HbUEHMyMJSekWV r6fV3x+gQKGs2EoBJ7DjGgHhLDKHEiEGpJhJLc6LCpmHO0xpVSAvujH0ufY47VS1mv uiPgufaX6AA72ANQXLMS4CJotbjcRo1HjHGBuVL/5qwUO1EUjyxYQ9V0La9kbZG/+V +FjwXD8Pm3kBqqRHeDQ9h/3ML91NqYzriA4HIPO7bAMlNP8eWU9fB/eZ5t9GzuaFxw K5uAbiclNyEsHyD3siGTaPlyFUlDcleE/zupKUv5nOsuFGzr25B0I+djyPxNCJ7+ZM eeCqniA1igICbxmDPpANslAEg5mVa7k32RWG3pkvi8DysoNKBsFtJGbgKcFvcCJnek 1zh3zykM0Wk0f1F95CI0yqBEDwphQELfAJksqOLaqz/Z6Fs3fC6inrjCD4TWiOwENp A5cEGVoANy1bDkRwetGy42HBzECgsJgCdln4DJr9mRBFaK43wHseh5x8f4X3dUVAGu dBsITioaZhKQR4cMhcARcC07eVIR2TkrthayMLy9yYqSIzZvJoCxqXlzFVQzBGN3kq jm71xNvZZEXgUnI/m5Lty84Q= Received: by sweet-chili.local (Postfix, from userid 1000) id 140D41B73FA8; Sun, 16 Jul 2017 16:55:48 +0200 (CEST) Date: Sun, 16 Jul 2017 16:55:48 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20170716145547.fthhkbdyyrkug5vp@bunkus.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 14:56:03 -0000 Hey, > If I recall correctly, this is used by Github not for the Markdown > section but for when generating a static Github-pages site. One of our > goals at the time was to have that site replicate, visually, the same > styles as we see on Matroska.org. That is correct. Due to that initial goal I had thought about replacing the real web pages on the matroska.org website with links to the rendered GitHub pages. My motivation was that the spec is actively worked on, but those improvements often didn't make it into the official website promptly. Since then I've reconsidered. Designing websites and writing specs are two vastly different things with different requirements and different audiences. I'd rather we keep the informal tone on the website, but be very technically precise and formal in the specs. The specs should then of course be linked to from the website, but they should intentionally not replace all the existing pages. Informal descriptions of how things work are very important for a user but have no place in a spec. In short: I think we need to have both. Consequently we don't have to and should indeed not hang on to the idea of rendering the website directly from the specs. The specs will be one part of the websites, but only a couple of pages. > If this is no longer necessary and we would prefer to narrow the scope of > the repository to not include this, it can be removed. For the reasons stated above I concur. > A lot of other code could be removed, too, to simplify the repo and > maintain a specific purpose, like the sister-repo, ebml-specification. Exactly. Kind regards, mosu From nobody Sun Jul 16 08:01:11 2017 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 417A7124D68 for ; Sun, 16 Jul 2017 08:01:09 -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, 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 Reuv49Qb3vKm for ; Sun, 16 Jul 2017 08:01:07 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 385AF1200C5 for ; Sun, 16 Jul 2017 08:01:07 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so72915077uah.1 for ; Sun, 16 Jul 2017 08:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0yckCkCcQa/dJr47N/OwiAhyvI/WW2gXGtxFZzii0k=; b=kWrUkBq2RN5iweMCy9v86ql+BE7bnVBcsGm0ASV0etwRMwsLWGK3UvrbY+CkVrSLxc K6Da7RzpNSN+o5XZCgz9Jtu4ej4AsAzWMOJaZa30hJPrSLvAnn95DkbGyPAViFEybccG 8tb1nUXE3k4Uzyb5vgP5OQisb0M4aMAqlr5N2RZaPoVflV5M6tOzlPJi+c0cAtrTKbGH JzQz7lDcGBZ+WXnLtWRZCQdJpSfLOlZIS47ZQkyPgrJBaLSZBaPLWEQpLp6pUe9x/24i Bqm/ktB4I0xbENRRcR37JwgL6OKHRmnSETAbYQFyhZHcM1euDVLHQmbMnPlhH1gtgsNY ydgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0yckCkCcQa/dJr47N/OwiAhyvI/WW2gXGtxFZzii0k=; b=gYeb42A3Yq4CALNDmsn9Ri02YAnM/x9dufDZyo+Ztrvxnan3Rsi7R4R33AeUuhJFwJ esyncWhl1eVPLC54tVgtN0IS4d6DG+iEW7nf9inFI4XgeKBdZs8In2jrpHQI54uffjPk YAIZyBflmRxBZ6wuBGd4AJNNy4JpMRQm3IWgPjDZsDH8/T9hsa5mcuIRXTPS2Qz4B864 MbSJs7JJbVjNuRbyPCHtkAkapzpUdbdRKypz2/RLgIQtBXiANdmqA7KY12fEQ1y+3hgV UPm/7KHx/I1cZ4IT6LZDk5/haOD+sSRQQtWVME9tIA9XhS1iK7AwuG6TxPVLukl/eSd/ rNHQ== X-Gm-Message-State: AIVw113xd8QYSzQw4I9JaFFvMlw0WacnQbMXABtEOtapJ/pD1KqWlvbQ 53vbn+oLsqGjf4e5a4zzfJaXRkxKheEYS9w= X-Received: by 10.176.82.73 with SMTP id j9mr10619340uaa.74.1500217266386; Sun, 16 Jul 2017 08:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 16 Jul 2017 08:01:05 -0700 (PDT) In-Reply-To: <20170716145547.fthhkbdyyrkug5vp@bunkus.org> References: <20170716145547.fthhkbdyyrkug5vp@bunkus.org> From: Ashley Blewer Date: Sun, 16 Jul 2017 11:01:05 -0400 Message-ID: To: Moritz Bunkus Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c18f1b23fbda80554708d7c" Archived-At: Subject: Re: [Cellar] layout: default X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 16 Jul 2017 15:01:09 -0000 --94eb2c18f1b23fbda80554708d7c Content-Type: text/plain; charset="UTF-8" I appreciate the swift progress Steve is making in this PR and am testing it now: https://github.com/Matroska-Org/matroska-specification/pull/147/files Some of this legacy information is visible in the outdated tone of the matroska-specification README. I can refine that information once this issue is settled and resolved. Ashley On Sun, Jul 16, 2017 at 10:55 AM, Moritz Bunkus wrote: > Hey, > > > If I recall correctly, this is used by Github not for the Markdown > > section but for when generating a static Github-pages site. One of our > > goals at the time was to have that site replicate, visually, the same > > styles as we see on Matroska.org. > > That is correct. Due to that initial goal I had thought about replacing > the real web pages on the matroska.org website with links to the > rendered GitHub pages. My motivation was that the spec is actively > worked on, but those improvements often didn't make it into the official > website promptly. > > Since then I've reconsidered. Designing websites and writing specs are > two vastly different things with different requirements and different > audiences. I'd rather we keep the informal tone on the website, but be > very technically precise and formal in the specs. The specs should then > of course be linked to from the website, but they should intentionally > not replace all the existing pages. Informal descriptions of how things > work are very important for a user but have no place in a spec. > > In short: I think we need to have both. Consequently we don't have to > and should indeed not hang on to the idea of rendering the website > directly from the specs. The specs will be one part of the websites, but > only a couple of pages. > > > If this is no longer necessary and we would prefer to narrow the scope of > > the repository to not include this, it can be removed. > > For the reasons stated above I concur. > > > A lot of other code could be removed, too, to simplify the repo and > > maintain a specific purpose, like the sister-repo, ebml-specification. > > Exactly. > > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c18f1b23fbda80554708d7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I appreciate the swift progress Steve is making in this PR= and am testing it now: https://github.com/Matroska-Org/matroska-spe= cification/pull/147/files

Some of this legacy inform= ation is visible in the outdated tone of the matroska-specification README.= I can refine that information once this issue is settled and resolved.

Ashley

On Sun, Jul 16, 2017 at 10:55 AM, Moritz Bunkus <mo= ritz@bunkus.org> wrote:
Hey= ,

> If I recall correctly, this is used by Github not for the Markdown
> section but for when generating a static Github-pages site. One of our=
> goals at the time was to have that site replicate, visually, the same<= br> > styles as we see on Matroska.org.

That is correct. Due to that initial goal I had thought about replac= ing
the real web pages on the matroska.org website with links to the
rendered GitHub pages. My motivation was that the spec is actively
worked on, but those improvements often didn't make it into the officia= l
website promptly.

Since then I've reconsidered. Designing websites and writing specs are<= br> two vastly different things with different requirements and different
audiences. I'd rather we keep the informal tone on the website, but be<= br> very technically precise and formal in the specs. The specs should then
of course be linked to from the website, but they should intentionally
not replace all the existing pages. Informal descriptions of how things
work are very important for a user but have no place in a spec.

In short: I think we need to have both. Consequently we don't have to and should indeed not hang on to the idea of rendering the website
directly from the specs. The specs will be one part of the websites, but only a couple of pages.

> If this is no longer necessary and we would prefer to narrow the scope= of
> the repository to not include this, it can be removed.

For the reasons stated above I concur.

> A lot of other code could be removed, too, to simplify the repo and > maintain a specific purpose, like the sister-repo, ebml-specification.=

Exactly.

Kind regards,
mosu

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

--94eb2c18f1b23fbda80554708d7c-- From nobody Wed Jul 19 06:56:26 2017 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 4DAD8131D14 for ; Wed, 19 Jul 2017 06:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ekjIX9QKtlR for ; Wed, 19 Jul 2017 06:56:23 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 A06AB131C54 for ; Wed, 19 Jul 2017 06:56:23 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id a62so878683itd.1 for ; Wed, 19 Jul 2017 06:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QsEH/VcUzM2X/cRMiGHsFPGfTdFP39zm+8KXdsYevE4=; b=N/3tkfQF3NvpIWojbjh6tGh4xEOle26QuJAwR7Ie+E6EdE1NpCQJFL4ApssIGiG7Sb aBLua9XRh2oIoJf+ajFLkAheVheAi6v34ZpR5IQ2YiAdrh7Nw3aaw4jf4YkHDowS2Ton UQgykSjPDc+mwSngxxpw3t8z+wXVCujllw5KUQQGS585vO3p9S/QCdvLaQszXq2EVmy9 W6O65P5SyfC2pS9IMV1sTEzDIef+/ayqJh2NZJ3uLJWX7MLOTtDF/109+JrFftnepY+M 6no+7Hx/3WH7j1DJwTrJKChzUl1GJwghAa0G7x+2UJydYjz/RdF3wsJsxT5trANIG4Hv BG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QsEH/VcUzM2X/cRMiGHsFPGfTdFP39zm+8KXdsYevE4=; b=hF8+VhF8oovVD/g3cNgD3iL3uB4kv+uK2sj+N04B9MTsTFFFx/wCuJZ/wbTxid7tkU hInq5PNVl+xNeDV3c8yyUzKgYiVs4C7OxEp8a8V9LWZjlIzN2BJsYhBEHr3y3J/dCPQl QDtUkeF9n1pEeX9YO99J6CrXHDLe5KpdpFll6qmNzzvsvKow+ZHKBDFGpNH2mnG4Sd+X H7BTJsvhXKLAMbX3tszosDnzwH/YVo8/qDSZ6LlzJ8a38ChkxgPXdQo8ZtLfG0pMHG9b pkIlqAsYPp3NPs9v/Vqn7hzrYmL7AG1h1k1kgBFymtm3zN35vrKfwjfim26Y5vW6lfQD C1QQ== X-Gm-Message-State: AIVw112UWjTNCOZU3k/MrzZZnq47XLhkHI00G85tD3elpyDI3WtnFuji WQGHfy5ug1jf2bWFR5r4bmdEXXnCLQ== X-Received: by 10.36.116.146 with SMTP id o140mr183501itc.107.1500472582905; Wed, 19 Jul 2017 06:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.186.11 with HTTP; Wed, 19 Jul 2017 06:55:42 -0700 (PDT) In-Reply-To: <3D08D735-F11D-4156-B695-052DFF3D8367@dericed.com> References: <41719fe1-18c9-09d3-38f2-03de185b609c@mediaarea.net> <3D08D735-F11D-4156-B695-052DFF3D8367@dericed.com> From: Tessa Fallon Date: Wed, 19 Jul 2017 15:55:42 +0200 Message-ID: To: Dave Rice Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a114aaadc4cc9f50554abffd4" Archived-At: Subject: Re: [Cellar] Documents Splitting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 19 Jul 2017 13:56:25 -0000 --001a114aaadc4cc9f50554abffd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since we're two days away from the CELLAR group meeting, I'd like to move this discussion there (7/21, 9:30 CEST). Tessa On Fri, Jul 14, 2017 at 7:14 PM, Dave Rice wrote: > > > On Jul 14, 2017, at 11:56 AM, Jerome Martinez > wrote: > > > > Le 14/07/2017 =C3=A0 17:46, Steve Lhomme a =C3=A9crit : > >> I suggest moving the codec and tags documentation/specifications in > >> their own documentation. > > > > +1 > > +1 > > The other cellar docs are in the range of 31-39 pages while the Matroska > document is currently 216 pages! I support moving the codec section and t= he > tags section to separate documents. > > >> We may also split codecs by > >> audio/video/subtitles to make even more manageable documents. > > > > I am not sure such split makes sense to split this way as > audio/video/subtitles is opaque for Matroska (it is just a "tag", and > Video/Audio elements in the track headers are defined in the main doc) > > > Same as Jerome. I suggest leaving the documentation for codecs together > rather than splitting by type. > > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a114aaadc4cc9f50554abffd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since we're two days away from the CELLAR group meetin= g, I'd like to move this discussion there (7/21, 9:30 CEST).

Te= ssa

On= Fri, Jul 14, 2017 at 7:14 PM, Dave Rice <dave@dericed.com> w= rote:

> On Jul 14, 2017, at 11:56 AM, Jerome Martinez <jerome@mediaarea.net> wrote:
>
> Le 14/07/2017 =C3=A0 17:46, Steve Lhomme a =C3=A9crit :
>> I suggest moving the codec and tags documentation/specifications i= n
>> their own documentation.
>
> +1

+1

The other cellar docs are in the range of 31-39 pages while the Matroska do= cument is currently 216 pages! I support moving the codec section and the t= ags section to separate documents.

>> We may also split codecs by
>> audio/video/subtitles to make even more manageable documents.
>
> I am not sure such split makes sense to split this way as audio/video/= subtitles is opaque for Matroska (it is just a "tag", and Video/A= udio elements in the track headers are defined in the main doc)


Same as Jerome. I suggest leaving the documentation for codecs toget= her rather than splitting by type.

Dave Rice

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

--001a114aaadc4cc9f50554abffd4-- From nobody Wed Jul 19 23:32:43 2017 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 6AEBA129B34 for ; Wed, 19 Jul 2017 23:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 p975_aPqbSe9 for ; Wed, 19 Jul 2017 23:32:41 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 DC49C127866 for ; Wed, 19 Jul 2017 23:32:40 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g13so8175143ioj.5 for ; Wed, 19 Jul 2017 23:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=WWCxm5CWc+0qutYmT/NUnZxoYV5TXM6iEzN0UMhk3Zg=; b=UWuZxTWoCZ4G8iwlvjIwKOe3P7rHIYDwQQWNwT3siiCysvitte1sNMuGrxz3VqaCT+ 9tz6M6pScTbmzBl82x/tKzraYEQRKa/tsCMVdWiDu9V0+xeDV0Mp5to7sbrNfrv3Fjus C/1f0BNuy3kkgaJkOtwjoukDsUMbb1+BMGIMZ9c4NyXEz+4F9Um0NyUivzrzU0ameZbc PuV1WrOphRjNqakZH9tQ6hSLcVadURH+qBzZ9ZoA+oLoJigu789XdyO+8giFWK5LLnBS b7niCWX+yWSy2Rhp8Y6PtdjYJKq1ffckOrNH5rPOXgEx+/5m1HJShnehSqq1sZC7W+D5 DOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=WWCxm5CWc+0qutYmT/NUnZxoYV5TXM6iEzN0UMhk3Zg=; b=f7zPoAOggdfvB9o0ke/BxLd4ZNd/8hLCZN7W05EAm5JIXnqwjVtzrlNrb0+aOFYXMX AMdi/fv43v0vY5cKyvLBnlqWK2yMEnRLSiYAju4X3oApWj53IGRGOCtLYH5J0plcOo9a LeKMKd8NeGVgrOJJJErQXO15ZUxfe07lzjyjNVXd57pCpNGtNI3SDgyW3p79Pgehq4TJ Z0WaFtxYirNZC7YES5cqaYEVib4bfrwHbFYTB+L0Zn43rlbvlAxPEsGHZP/DcVZoQJkn ieLwMohQuAdembc8Gu5TJswYUEOcdr253VPo7dtNSPBXiekK0Xwv6n0ywEeUSFc2dSrW Ubjw== X-Gm-Message-State: AIVw113wHdC504cUud+RD5eOKySR0zXxhpI2MN4VWsRkmti3cxFBCLOP 0iKdVuD1VVCaPMcvgHc= X-Received: by 10.107.4.11 with SMTP id 11mr2244131ioe.61.1500532360095; Wed, 19 Jul 2017 23:32:40 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:3130:b165:6f6:332a? ([2601:243:504:643:3130:b165:6f6:332a]) by smtp.gmail.com with ESMTPSA id b14sm833034itb.18.2017.07.19.23.32.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 23:32:39 -0700 (PDT) From: Rodger Combs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <027149E8-31E1-4EC0-AD40-6E9B84FFF8F5@gmail.com> Date: Thu, 20 Jul 2017 01:32:38 -0500 To: cellar@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Cellar] Matroska: "Forced" and "Default" flag definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 20 Jul 2017 06:32:42 -0000 Currently, Matroska's "forced" flag's documentation describes a feature = that wouldn't be particularly useful as defined, and doesn't match any = implementation's behavior I know of (though if any implementation = actually does overlay a forced track alongside a normal one, please let = me know). I'd like to propose an updated definition of the default and = forced flags: - Default: For audio or video, set if that track SHOULD be active if no language = found matches the user's preference; this can be used to specify the = original content language. For subtitles, set if that track SHOULD be = chosen if there are multiple tracks which match the user's language = preferences. (1 bit) Alternate definition: Set if that track (audio, video or subs) SHOULD be active if multiple = tracks found matches the user's language preference. This can be used to = specify a "normal" track (as opposed to other tracks containing = commentary or other alternate content). (1 bit) If the alternate definition is used, then the original/default language = should be the first track of its type. If the first definition given is = used, then the first track of a given language and type should be the = "normal" one. It might be generally useful to add flags for track types = (commentary, hearing-impaired, descriptive audio service, etc...), but = that's out of scope of this proposal. - Forced: Applies only to subtitles. Set if that track SHOULD be active during = playback, even if the user's preferences would normally not enable = subtitles with the selected audio track; this can be used for tracks = containing only translations of foreign-language audio or onscreen text. = (1 bit) These definitions better match the intent of the flags on DVD and BD, = without implying user-hostile behavior or overlays of multiple tracks, = and I think they do a better job of carrying information about the = relevant tracks. They also match at least some existing implementation = behavior.= From nobody Wed Jul 26 04:07:15 2017 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 167CE131FEF for ; Wed, 26 Jul 2017 04:07: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 rR3v8-siwzsJ for ; Wed, 26 Jul 2017 04:07:12 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 A9F76126DEE for ; Wed, 26 Jul 2017 04:07:12 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u139so21989468qka.1 for ; Wed, 26 Jul 2017 04:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=H/d93kTaaYdEPZCHG9dVZQRchRMxkOUlBwhft4UkXKc=; b=ZP6V9RtNKLDOuBg8pvxiZvtcFevq3NAIeeh9ScGrM6YytMy0oJV0nwLqc83N1AROFf MwllenV6CjPf/uyq8U/5FfmYF/CHbN4LWPWdk8K0S75PO6tzHfg418Z4tKMWTPWzPNhc deh3IX2gdHdzOQR2C56ZU+fVR72RqzkvFiAKSi7QE4KzGJUDTzg2i8THSX1zqmkma7VT OOXH1x67Q+5ueY3Bd5zNThWncLkAUzBxJ86u3mjrhMUCCzyO68WVBSKcXQKDDliwsOK+ k9ae2LWNhU55F3S62/h8cQ6I2l3H3EQkNNlPmEaE8Yu/5BDXUtMM6V16TRQFyoa45p+r spRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H/d93kTaaYdEPZCHG9dVZQRchRMxkOUlBwhft4UkXKc=; b=GQjDaFuMg9PCRdIVPqs46TafNenes9E9qlPZDgjwKcul5QVifGcw/BeMp4LOEfP2zj ir1BSgaRBIUlLADU1oLPaEZMyBwQQly0GKRIx0v4pPZ7pHceKcUxOGySFRE9ns3Uh4Ng Je18QrlrPLgkDmilqWIzce3Uj+1aQc/kkX1MOUh/aogrHKYGJ1KVRL8Q3Zs65UECPqgC VtwS91m6XXz5CqzN9E1alOjt7Sg9HVk+BLpssoJXoCvtyo1Zdul+EadAdNDzgIc9uCi8 fbu/YP50FE1k2Tb0KC+VKQSE8qOHIRXG7KmhjpSdHYDFz2xXPn4tLaRfDlwhssJ2Bdc9 allQ== X-Gm-Message-State: AIVw112u+76uougnz3RqGGtEJWoltpWMpigFs5fS4/xHuSEDLtzHJ8XW W2jVH5TOo7URE7m1pu3OX07hVgBS4OXi X-Received: by 10.55.19.29 with SMTP id d29mr655201qkh.296.1501067231623; Wed, 26 Jul 2017 04:07:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.201.80 with HTTP; Wed, 26 Jul 2017 04:07:11 -0700 (PDT) From: Kieran O Leary Date: Wed, 26 Jul 2017 12:07:11 +0100 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="001a11400a8e1ffe710555367351" Archived-At: Subject: [Cellar] Editing colour metadata of Matroska file with mkvpropedit? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 11:07:14 -0000 --001a11400a8e1ffe710555367351 Content-Type: text/plain; charset="UTF-8" Hi, I was wondering if it was possible to add or edit colour metadata in Matroska files with mkvpropedit? I'm thinking of Transfer Characteristics, Color Primaries, Matrix Coefficients. Looking at the values in `mkvpropedit -l`, I don't see these values listed. Could this be added? This could allow users to inject better description into their files without going the ffmpeg route and creating a new file. Best, Kieran. --001a11400a8e1ffe710555367351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I was wondering if it was possible = to add or edit colour metadata in Matroska files with mkvpropedit? I'm = thinking of Transfer Characteristics, Color Primaries, Matrix Coefficients.= Looking at the values in `mkvpropedit -l`, I don't see these values li= sted. Could this be added? This could allow users to inject better descript= ion into their files without going the ffmpeg route and creating a new file= .

Best,

Kieran.
--001a11400a8e1ffe710555367351-- From nobody Wed Jul 26 04:18:24 2017 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 92B7112EACC for ; Wed, 26 Jul 2017 04:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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=-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 44HsWHrVgtWu for ; Wed, 26 Jul 2017 04:18:22 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 1341612778D for ; Wed, 26 Jul 2017 04:18:22 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:37306) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1daKKS-0002MG-0Q for cellar@ietf.org; Wed, 26 Jul 2017 13:18:13 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id BEC8B6541E5A for ; Wed, 26 Jul 2017 13:18:11 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0201.59787A75.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1501067891; bh=P/Iiem7m7lcaWXQsuOZBkRpAOi5i4MMeoJ0x37uhHDw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GgVwpjExIjqaQyV8Z0aRKlbhcqy9ezM5cNYU5HRouI1kywZc6f2OPn4AB1Z/e7e15 o1XlEUteDDIz3l4qywH+1WRAfAJ130vWJsVZiNKPrhbtTX02x5Lx8B9yC3Q5zL/iU+ Vz2bx5JNw3NWZAx6IgSgpOuIc7c/+H1fB7enkjgiOYqq5Ecjcq32pUdYYEBfZSO7HT N5bDMiMk9yDs+34RQsgKnv+Wz71rNkUc8S8eCRyr0K2SGjmp2pWbFjfDvLrKE7S+N4 S8qjJchfYCR7ojX9JQ34lyCJz5BMlsUiAPq9Z0UeVl60W7HMwOBNoU9IqbVuo5FfPt 3qelzysfgtuXKiGta9sQWqG3njynkLWt81PSx1XUQ5BVUkjUjbq1CWQBRLRXaPU2cv /VEbQleOI7tbXyihOMWF8Dv8HrDwPbv+9iIBp9x8TNrAhbXJ89Wo08MKnl0it2Zrqy eULYEY1AVNZqtAqHtNFuOjKZyvovGlebqZCGVkycvvxeTThKueL8vb9Bhw2XNrekpW vueTZcHxixl2XItNyMj8PZQMUPzI4Pm6Gk9+uFI0DQzctARhA5Ycxk98ogARE9GYyg 9MHJpcUrrC4VqiZq6rmPtz8Q/EnEm5EYjXiK7H4IzS2Fy8HlZ8w+UWsy6jVJeuxRjl QLy8Z0/BX5NQV+i+4xx5mIJY= Received: by sweet-chili.local (Postfix, from userid 1000) id 32D391BC2F6C; Wed, 26 Jul 2017 13:18:11 +0200 (CEST) Date: Wed, 26 Jul 2017 13:18:11 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20170726111810.lr6zi3n6tsucjg2y@bunkus.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Cellar] Editing colour metadata of Matroska file with mkvpropedit? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 11:18:23 -0000 Hey, > I was wondering if it was possible to add or edit colour metadata in > Matroska files with mkvpropedit? Not yet, no. Dave has already filed an request for it[1] two weeks ago. I will get around to it someday, but I cannot give you an ETA. Unfortunately it's not just a question of adding a couple of entries in a table somewhere as they're all located in their own master element which neither mkvpropedit nor the GUI's header editor is currently ready for (yet). Kind regards, mosu [1] https://github.com/mbunkus/mkvtoolnix/issues/2038 From nobody Wed Jul 26 04:39:29 2017 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 591D6132000 for ; Wed, 26 Jul 2017 04:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 x31lSAYVkG-f for ; Wed, 26 Jul 2017 04:39:26 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBECE131C90 for ; Wed, 26 Jul 2017 04:39:25 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id a18so26050720qta.0 for ; Wed, 26 Jul 2017 04:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=MArKRABtALAPEti0mhmz6Gi88XE+zX8mzCCvoUMnE8o=; b=bTSN/WTZcnlBZmtlbBD88EnWc4DU+bnZEZFzf69XyvwfHaLqvnqCSspEZAFg4nFTEI 71BJJHBVFCWgd7ks+sy4dyu6yF1k5JG7L6xa14b4Q/PIjEuxmKu+r1v0Jbw7OYCCeCjb LrovUIim16CkfMpXasUOqCdoyVA1l58UJqYmjaciuCVY40sHk/LUq2RuCvGCNdlTLbV0 TugKpfufva1CxVhDbK0uScWOztRyzbXVKfaoflzRauwgrVt7IXVSgOEMtmpT+OxTxC14 yPvecbH8Eic1zePGXQKaa2RRlzQiU4KWlHUktNk/7YEEKqDfCjESCg7wJi1HERi5Myy7 mtfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=MArKRABtALAPEti0mhmz6Gi88XE+zX8mzCCvoUMnE8o=; b=oenqIadyKNph1KiIhP0sFIjofvZl51lOc6yfTO/lj6O+ac1j4+Fl6MqFP2N3IikgB4 B41alNQfoQx6MaOxpElFRhHEzqOlWRuwV4LBK9WDufofF1Uw6Erd9GCw+Rzzt5F53f3s ypBZmz8K5veHFTFh004eaXZVoWFOakE5XaLb42WuxuvIiXeTLMVbB7KE5aM+eSA/GEFj RICQd1UrtPb+Un1C/nyWYhLTjFNXgKA5HVRfPawUBTBXnWZKN2An1reoRE+Skh61wGGo B4ZHiVO5jduqhKfDodjXmkOjAgycwplZJbpXxz8yAkwZCz+02Ex1fBcRn3XB0unfsrcG lQZQ== X-Gm-Message-State: AIVw113u7Q99LLkyew4RYVW5WeGo2YwOBZKX7nOEwwrmjaV+HIs0j2t+ rbxXN3RXcQBkLJDPUOcgva//aTSiu4UqqZk= X-Received: by 10.237.42.88 with SMTP id k24mr855133qtf.58.1501069164730; Wed, 26 Jul 2017 04:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.201.80 with HTTP; Wed, 26 Jul 2017 04:39:24 -0700 (PDT) In-Reply-To: <20170726111810.lr6zi3n6tsucjg2y@bunkus.org> References: <20170726111810.lr6zi3n6tsucjg2y@bunkus.org> From: Kieran O Leary Date: Wed, 26 Jul 2017 12:39:24 +0100 Message-ID: Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="001a11412b2058dd73055536e6b3" Archived-At: Subject: Re: [Cellar] Editing colour metadata of Matroska file with mkvpropedit? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 11:39:27 -0000 --001a11412b2058dd73055536e6b3 Content-Type: text/plain; charset="UTF-8" Hi, On Wed, Jul 26, 2017 at 12:18 PM, Moritz Bunkus wrote: > Hey, > > > I was wondering if it was possible to add or edit colour metadata in > > Matroska files with mkvpropedit? > > Not yet, no. Dave has already filed an request for it[1] two weeks > ago. I will get around to it someday, but I cannot give you an ETA. > > Arg, I'm really sorry about the duplication here. I wasn't following that repo, though I am now! > Unfortunately it's not just a question of adding a couple of entries in > a table somewhere as they're all located in their own master element > which neither mkvpropedit nor the GUI's header editor is currently ready > for (yet). > > Thanks for clarifying. What is the difference between those colour elements and something like the 'Language' element, which I can set with `edit Track:v1 --set language=French`? I can't see a distinction between these two elements by just looking at the IETF draft spec. Best, Kieran. --001a11412b2058dd73055536e6b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, Jul 26, 2017 at 12:18 PM, Moritz Bunkus &l= t;moritz@bunkus.org<= /a>> wrote:
= Hey,

> I was wondering if it was possible to add or edit colour metadata in > Matroska files with mkvpropedit?

Not yet, no. Dave has already filed an request for it[1] two weeks ago. I will get around to it someday, but I cannot give you an ETA.

Arg, I'm really = sorry about the duplication here. I wasn't following that repo, though = I am now!
=C2=A0
Unfortunately it's not just a question of adding a couple of entries in=
a table somewhere as they're all located in their own master element which neither mkvpropedit nor the GUI's header editor is currently read= y
for (yet).

Thanks for clarifying. What is the differe= nce between those colour elements and something like the 'Language'= element, which I can set with `edit Track:v1 --set language=3DFrench`? I c= an't see a distinction between these two elements by just looking at th= e IETF draft spec.=C2=A0

Best,

Kieran.
=C2=A0
--001a11412b2058dd73055536e6b3-- From nobody Wed Jul 26 04:50:24 2017 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 2D133131C99 for ; Wed, 26 Jul 2017 04:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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=-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 Rbi9foE4Befl for ; Wed, 26 Jul 2017 04:50:22 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 D8892131BBF for ; Wed, 26 Jul 2017 04:50:21 -0700 (PDT) Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:42022) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1daKpO-0002q9-2F for cellar@ietf.org; Wed, 26 Jul 2017 13:50:10 +0200 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 742006541E5A for ; Wed, 26 Jul 2017 13:50:10 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.597881F2.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2017070101; t=1501069810; bh=e3sofkwpV4FzlgIIsptz+g3hVTMdGYbV2jrFiEnZKKs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=tPv8xE/8K+4SjDFkqcaMt+LZBTCNjkYl5UBDo5zpbdHRDTFcHjmw7Utp6b+w2yq7j ShvAGcTZUsnkRnTt0boRWxvEABBucHvjKyjzmWYFByLPUBLH3XTvticFz16I0UUzP+ r+05vQCKRUaL9R9p7Dl3tN2r0aaA5Ku9FXqDFuP4LEjwaz293Ls/iL9wbouuaUXt4u cf4oxYAKweZDsC3NxGMYqmwTDPe4vug1iwMQ4/Uro3o4ix9To1N3OM5AGg8LxuNTrB ohIA3h6qO8Sp/hxSuUPnXiefUEXkqEhRp5DhSwhiXOWEHp099h82jsVkQiJrbT8kTH SX3P7EiQHfN3TfvqeDmyOTGtr8C8Ute0jXqsuuIgl8JQZsfnqFbwuoBqO1gDphaKQc cGFxjHHCg8S0J+lSUnwFFDrOckISoF/tGB3rgaqe77w+frkLZiJCE58xYt2RH7wFHv AhjBAA3/n+IJUKINse9ijbizPS6StQKUyFbyebN7Ocn3V+tgHOzvc8mhn5siHtzfiN /IuX4Z5IozNigX5opuQgD8yrr0579iT6n3MeOxwJZvjrmNmrqtQeCkyErqwPClDXbA AUtaGvexZcWUT+pAMD7o/QjwGVqQEmU/m/WCwoH6uJI0aP+8dL4AZCbQC3jjbP0j0o XBMC2gReJpCgvMc0R4no7Czk= Received: by sweet-chili.local (Postfix, from userid 1000) id D8B8D1BC308C; Wed, 26 Jul 2017 13:50:09 +0200 (CEST) Date: Wed, 26 Jul 2017 13:50:09 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20170726115009.hzdak7xeojmpwl4r@bunkus.org> References: <20170726111810.lr6zi3n6tsucjg2y@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Archived-At: Subject: Re: [Cellar] Editing colour metadata of Matroska file with mkvpropedit? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 11:50:23 -0000 Hey, > Thanks for clarifying. What is the difference between those colour > elements and something like the 'Language' element, which I can set > with `edit Track:v1 --set language=French`? I can't see a distinction > between these two elements by just looking at the IETF draft spec. The "Language" element is a direct child of the "TrackEntry" element, whereas e.g. the "Range" element is a child of "Colour" which is a child of "Video" which is a child of "TrackEntry". mkvpropedit and the GUI's header editor can deal with elements that are direct children of "TrackEntry", "TrackEntry → Audio" and "TrackEntry → Video", but not with two levels down. I'll have to add code that removes the "Colour" master if none of its children is set and adds the master otherwise. The GUI's header editor doesn't have three levels of visualization yet. I'm not saying it's an insurmountable amount of work, far from it, but it's not a trivial change either. Kind regards, mosu From nobody Wed Jul 26 06:22:11 2017 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 20DDA132034 for ; Wed, 26 Jul 2017 06:22: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 q5ep4N3lYzwb for ; Wed, 26 Jul 2017 06:22:07 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 90B92132030 for ; Wed, 26 Jul 2017 06:22:07 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id k2so47380754qkf.0 for ; Wed, 26 Jul 2017 06:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BC6u56s7/umAMSFgRkSlXZQnpim08BTWcLkfyXPvpVI=; b=rtXl/rPperGRl1N5kXizp3NSd7DYScklcTrr5R60r1C3QUwP6SaRHEc6wjyYahVQwZ yUibca6/vqh7vVZ09UFTb+yJDkrixu/LUK/OsemOCH/Ex2EUA/NwBWSDoBWJUR9P9NfC 5lJpDGEbaFjmCBgtTpTtI0PDbuA5cFuPz5Rtz7XnI0gSmHGjg7yQmprHtE1FWV170Yhw +7iGKqG8Gt1Agsn+Q+V4l71EcYV285vyJYFZubezvQsVmS46MwZzLAJVJ98D/JABlVOQ M8MP9zO0hlD0UKhjw9O/bJ4cEhuiQ8QhB0+bnMleXnbt02hMCW+qxgpTk0D2mPaNDgEz 6b7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=BC6u56s7/umAMSFgRkSlXZQnpim08BTWcLkfyXPvpVI=; b=IAH+FfbqBcO+zOHHFO4a4R5g50U5TNsR5MGa6+LVI+1ZDem9gXbTSMFez/zNkm9JxS aYKDv3qY+FpcBx+xFC0p895Hhwj861ZVn7MRDGxzAuTRyyzkJTv2/jac49wVJgzoG5bJ ty0Rp0w3SiQNv74TWiV16ipJMewmlGCf2tcceLBJXnCjFk6vZgJClTsHaHcyll51YpyC H4Eaym9dkV+p33b8QnuSmy8l7s4OUjkvxfrBgvTbpk+mK0nJOGdBNGpb8YMniSCedE8M pbPKjF801xPiuEyvrHsHl7KlWUwbiG7UoKDi0mGsAJ9iMyB+Wx9Lv57rBNVUnsSzFgPV Vzug== X-Gm-Message-State: AIVw110Wc6v/AJXoo9O5abfgWZ/07dDy0O02mSKvqLOSmJzmDldn4gAB /94QJxhePnLiPjhVF0y8lNS7kla63Eid X-Received: by 10.55.31.34 with SMTP id f34mr1100862qkf.357.1501075326578; Wed, 26 Jul 2017 06:22:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.201.80 with HTTP; Wed, 26 Jul 2017 06:22:05 -0700 (PDT) In-Reply-To: <20170726115009.hzdak7xeojmpwl4r@bunkus.org> References: <20170726111810.lr6zi3n6tsucjg2y@bunkus.org> <20170726115009.hzdak7xeojmpwl4r@bunkus.org> From: Kieran O Leary Date: Wed, 26 Jul 2017 14:22:05 +0100 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="001a1147a8829f360b0555385514" Archived-At: Subject: Re: [Cellar] Editing colour metadata of Matroska file with mkvpropedit? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 26 Jul 2017 13:22:09 -0000 --001a1147a8829f360b0555385514 Content-Type: text/plain; charset="UTF-8" Hi Moritz, On Wed, Jul 26, 2017 at 12:50 PM, Moritz Bunkus wrote: > > The "Language" element is a direct child of the "TrackEntry" element, > whereas e.g. the "Range" element is a child of "Colour" which is a child > of "Video" which is a child of "TrackEntry". > > Makes perfect sense. EBML really is like XML! Best, Kieran. --001a1147a8829f360b0555385514 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Moritz,

On Wed, Jul 26, 2017 at 12:50 PM, Moritz Bunkus <moritz@bunk= us.org> wrote:

The "Language" element is a direct child of the "Trac= kEntry" element,
whereas e.g. the "Range" element is a child of "Colour"= which is a child
of "Video" which is a child of "TrackEntry".


Makes perfect sense. EBML really is like XML!=

Best,

Kieran.=C2=A0
--001a1147a8829f360b0555385514-- From derek.buitenhuis@gmail.com Fri Jul 28 07:20:53 2017 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 495B1131D32 for ; Fri, 28 Jul 2017 07:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 OZr-3ngKJ6Sm for ; Fri, 28 Jul 2017 07:20:48 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 5086B131FCE for ; Fri, 28 Jul 2017 07:20:48 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id e199so21255527wmd.0 for ; Fri, 28 Jul 2017 07:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=cPXgQ5ZrbT+33QWNZPgUkV418OsD+7j0dyY55r0SfGA=; b=QJx1tKXySqtItX78OfMD3H/N1Nlzoh5I4rQULkFMrASi34uYUNcwzNqEN6l0H5uuVq wTjzHYQZAO3hvCXJ0BAfY+jndW7Yy9NDFWCUlzqRhDHKkGV5hRUfs4zoeRyc2oadjB4f G55vZzKnS8N7eCwmC9pCXTc38wj/UJCwbhGm+qXvgHHyrG0pbF7uo8Q0ooZ+eCsbfNTM qne0hKcbp35kckVn0ICEbciUnXq9MZ7iTm37ts36rC3cRp+B+f7jwrqjcNd5gWldnDPk fUi2NEKMEsGORDPulRgmcmIaT0u8uMA2iRPdZx5szZRWNZppA4/ml9MPpHp9GJXUOpzh AYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=cPXgQ5ZrbT+33QWNZPgUkV418OsD+7j0dyY55r0SfGA=; b=WB1pq2efRyLb7mJFkj7R/rcCb6wEzJczRpMuopidr5ey8hAI/m4btlPDGAUS86kkEj 4AsuR09xmLNaDHsfJr5gQzdR3eNgq+WonCxuotOmu00D0xFIjo06dzzY6M1/PXHX8x82 g1cZFhJDFkamus3iHdmleRX7ysZGacnDOAV/Vo3Hrzwdd6qhreFwTV/Dfoe4u0m+cL7d TUXxwR+c/LiBYJf7CPmPKxf5VMl4iarOg67F9qANE1nNHBIuPlA878ESkB5+1QKzWWNS l6GjWFdgwXx7sKGfDljfVxbN08w7n9lAGIkxrAkIB1G2eiQYQjImPy4eJdXd8UKAwmtk fq1A== X-Gm-Message-State: AIVw111/JXZzsebcXNGzGsc+kNodc/TuRDv84CsT5G8eaFpDxdSwNZn5 u1PvfMQlmh0oFFDFdBU= X-Received: by 10.80.191.6 with SMTP id f6mr6584151edk.213.1501251646522; Fri, 28 Jul 2017 07:20:46 -0700 (PDT) Received: from [192.168.1.159] ([149.12.11.37]) by smtp.googlemail.com with ESMTPSA id 4sm12562944eds.48.2017.07.28.07.20.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 07:20:45 -0700 (PDT) From: Derek Buitenhuis To: cellar@ietf.org Message-ID: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> Date: Fri, 28 Jul 2017 15:20:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 14:22:37 -0000 Hi all, Dave Rice pointed me at draft-ietf-cellar-ffv1-00 and draft-ietf-cellar-ebml-03, and these are my thoughts upon a cursory look at the former. I'm new to this list / IETF stuff in general, so some of my comments may be moot or a bit fuzzy. Comments follow inline below. > 2.2.9.1. remaining_bits_in_bitstream > > "remaining_bits_in_bitstream( )" means the count of remaining bits > after the current position in that bitstream component. It is > computed from the NumBytes value multiplied by 8 minus the count of > bits of that component already read by the bitstream parser. A bit confusing that this is named 'remaining_bits_in_bitstream', but in reality it is 'remaining_bits_in_bitstream_component', not the whole bitstream. > o one column of samples to the left of the coded slice is assumed as > identical to the samples of the leftmost column of the coded slice > shifted down by one row This doesn't specify what the top sample value should be, once the column has been shifted down by one. Based on the diagram below, it should be 0. > left16s = l >= 32768 ? ( l - 65536 ) : l > top16s = t >= 32768 ? ( t - 65536 ) : t > diag16s = tl >= 32768 ? ( tl - 65536 ) : tl Does the IETF specs generally define when arithmetic is signed/unsigned, or do they defer to the C spec on integer promotion, etc.? > 3.7.2. JPEG2000-RCT It's kind of a bit odd that this is titled like this, considering section 3.7 is titled 'Color space' and JPEG2000-RCT is not a color space, but a transform used to store RGB(A). > 3.8.2. Huffman coding mode > > This coding mode uses Golomb Rice codes. The VLC code is split into Redundant 'code'. Variable Length Code code. > if (run_count == 0 && run_mode == 1) { | > if (get_bits1()) { | > run_count = 1 << log2_run[run_index]; | > if (x + run_count <= w) | > run_index++; | > } else { | > if (log2_run[run_index]) | > run_count = get_bits(log2_run[run_index]); | get_bits1() and get_bits() first appear here, with no definition. Should they not be defined in '2.2.9. Bitstream functions'? > "frame_pixel_width" is defined as frame width in pixels. > > "frame_pixel_height" is defined as frame height in pixels. The document, up until this point, and after this point, always refers to samples. Why is it suddenly pixels? > pseudo-code | type > --------------------------------------------------------------|----- > ConfigurationRecord( NumBytes ) { | > ConfigurationRecordIsPresent = 1 | > Parameters( ) | > while( remaining_bits_in_bitstream( NumBytes ) > 32 ) | > reserved_for_future_use | u(1) > configuration_record_crc_parity | u(32) > } Style changes completely half way through the spec, and also adds types to the types column. It's pretty obvious the earlier pseudo-code was pasted directly from libavcodec, but this code probably isn't written by Michael at all. Very different stuff; e.g. the previous code has variable types in the psuedo-code, but this does not. Is this specific to bitstream descriptions? > 4.1.3.1. In AVI File Format Poor English. Perhaps remove the "In". Ditto for others. > The Configuration Record extends the sample description box ("moov", > "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box which > contains the ConfigurationRecord bitstream. See [ISO.14496-12.2015] > for more information about boxes. Where is 'glbl' defined? If it's only this spec, then it conflicts with existing custom boxes for e.g.: https://wiki.xiph.org/Oggless#Example_and_Discussion_of_the_MOV_container Not sure if this ever actually existed in practice or not, but it's something. > FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 > versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be > used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" > Element MUST contain the FFV1 Configuration Record structure and no > other data. See [Matroska] for more information about elements. Why only SHOULD? > > +-------+----------------------------+ > | value | slice coding mode | > +-------+----------------------------+ > | 0 | normal Range Coding or VLC | > | 1 | raw PCM | > | Other | reserved for future use | > +-------+----------------------------+ This is the first and only time 'PCM' appears in this document. Should it be defined, at least, or have a reference? > pseudo-code | type > --------------------------------------------------------------|----- > Line( p, y ) { | > if (colorspace_type == 0) { | > for( x = 0; x < plane_pixel_width[ p ]; x++ ) | > Pixel( p, y, x ) | > } else if (colorspace_type == 1) { | > for( x = 0; x < slice_pixel_width; x++ ) | > Pixel( p, y, x ) | > } | > } | This is the first and only time Pixel() appears in the document, and without explanation. > 4.8.5. colorspace_type > > "colorspace_type" specifies the color space. > > +-------+-------------------------+ > | value | color space used | > +-------+-------------------------+ > | 0 | YCbCr | > | 1 | JPEG2000-RCT | > | Other | reserved for future use | > +-------+-------------------------+ Same comment as before: JPEG2000-RCT is not a color space. > 4.8.8. h_chroma_subsample > > "h_chroma_subsample" indicates the subsample factor between luma and > chroma width ("chroma_width = 2^(-log2_h_chroma_subsample) * > luma_width"). > > 4.8.9. v_chroma_subsample > > "v_chroma_subsample" indicates the subsample factor between luma and > chroma height ("chroma_height=2^(-log2_v_chroma_subsample) * > luma_height"). I get that the spec is trying to be mathematically correct, but why can't this contain the method that literally every single implementation will ever use: bitshifting by {v,h}_chroma_subsample. It's even a defined operator in "2.2.1. Arithmetic operators", and is used in e.g. the JPEG2000-RCT equations. Further, the name 'log2_h_chroma_subsample', in the definition, is incorrect. [...] Hopefully these comments have some value! Cheers, - Derek From nobody Fri Jul 28 08:38:17 2017 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 A551D131BFE for ; Fri, 28 Jul 2017 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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] 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 8--eCYRj-lfb for ; Fri, 28 Jul 2017 08:38:11 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384AF131945 for ; Fri, 28 Jul 2017 08:38:11 -0700 (PDT) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BE6DCA80FD for ; Fri, 28 Jul 2017 17:38:09 +0200 (CEST) Date: Fri, 28 Jul 2017 17:37:18 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20170728153718.GK6482@nb4> References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYX8XqlwBJQgDxCD" Content-Disposition: inline In-Reply-To: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:38:15 -0000 --zYX8XqlwBJQgDxCD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 28, 2017 at 03:20:38PM +0100, Derek Buitenhuis wrote: > Hi all,=20 >=20 > Dave Rice pointed me at draft-ietf-cellar-ffv1-00 and draft-ietf-cellar-e= bml-03, > and these are my thoughts upon a cursory look at the former. >=20 > I'm new to this list / IETF stuff in general, so some of my comments may = be moot > or a bit fuzzy. >=20 > Comments follow inline below. >=20 [...] > > 3.7.2. JPEG2000-RCT >=20 > It's kind of a bit odd that this is titled like this, considering > section 3.7 is titled 'Color space' and JPEG2000-RCT is not a > color space, but a transform used to store RGB(A). Its meant to be the colorspace formed by the JPEG2000-RCT I see this isnt ideally worded but iam ATM not sure how to word this better Maybe calling it YCbCr (JPEG2000-RCT) would be an option Besides the wording the colorspace formed by a reversible colorspace transform is as much its own colorspace as YCbCr is distinct from RGB It may be that implementations treat colorspaces which can be losslessly converted to RGB as RGB. But from a specification point of view these are not RGB and we may add other lossless transforms from RGB in the future [...] > > "frame_pixel_width" is defined as frame width in pixels. > >=20 > > "frame_pixel_height" is defined as frame height in pixels. >=20 > The document, up until this point, and after this point, always refers to > samples. Why is it suddenly pixels? a RGB pixel represents 3 samples do you see an error in how the terms are used ? [...] >=20 > > The Configuration Record extends the sample description box ("moov", > > "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box which > > contains the ConfigurationRecord bitstream. See [ISO.14496-12.2015] > > for more information about boxes. >=20 > Where is 'glbl' defined? If it's only this spec, then it conflicts with > existing custom boxes for e.g.: >=20 > https://wiki.xiph.org/Oggless#Example_and_Discussion_of_the_MOV_conta= iner I think glbl was used as a generic box to hold a codec specific global header. if one looks at the bigger picture and not just ffv1 then a single box should be simpler than a codec specific one. a (de)muxer would otherwise probably need to have a list of these boxes [...] Thanks for reviewing the spec! --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras --zYX8XqlwBJQgDxCD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAll7Wi4ACgkQYR7HhwQLD6uDlwCdHRmOkXyMg8UtGwe7CUR4Qqwj 8E0AnRgtPeWMS0bT5AaEpQiRZ4Z7lTDS =py0w -----END PGP SIGNATURE----- --zYX8XqlwBJQgDxCD-- From nobody Fri Jul 28 08:49:26 2017 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 1F0E5131CA2 for ; Fri, 28 Jul 2017 08:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 4WAT8K8OdyaK for ; Fri, 28 Jul 2017 08:49:20 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 600BA132143 for ; Fri, 28 Jul 2017 08:49:11 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t201so129347346wmt.1 for ; Fri, 28 Jul 2017 08:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3sGvU4hbX5rWYe4SOm0+lmoXShxg0N7QIh5SIMZEuws=; b=YOQJMZBoWFEPMUayOp3OAB6qKTzzBqWmtam7AFxK5gQl8mammxn0YngeLTo+IzZU26 iYWiqzJj6zmV3T0miyvUoKj4Y73m5NnxRqXwKluZX3d20Lp94NRTFXDE2I2/M9zgV+27 LUqUEEvThIz4hvKh0W2aMCOCiLfUVFJKdEjTtEWDj0EczzEnpTPWGgfXwu+oZpCQ0ZwB 13rJeqdCzBDHjee0hZ+t1y5kWzGCdWL1lqdYC4Elj+jwxJviWn48dpTjFJ5xYPmVq0dJ ExgrH2oJDddObbQmdp9uetb8sRJmYEvvyO7xjGiN1/cDZHXe1S9RsRNYNezkqgbDstmR G7sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3sGvU4hbX5rWYe4SOm0+lmoXShxg0N7QIh5SIMZEuws=; b=sT9vf/T2qXalsfqcaDHLazTQvbJxoxUds+3rjR0KXiyWXNnjQuZ0tT/JsRXs2lkGwC YaboHwJ3H2cL547DkLG6+us8zaoKnrxctALYfAVMB6Zl+/WRkmWt2QoHW6pWThNAZ4na OTN8V8HQgo523C6irK5d4d78t944IH5TSxt4CGBrkGnlHsBUHVxIVdPZvPukSd13rM1x wD/zz4ZJdSX4eiHWnapFXvdNmr5htRRfwMAZXiQtB5uWVk4uyZ2d4BmXEPxfVx9dETNn N8NfBnHJEsc4OqG1zCKwGFCPpNgMnZgBDdpd0OEZLfGKWYQdVdUg7OsdL7NAEihJsTp+ rO+A== X-Gm-Message-State: AIVw113/Vn6ih5Fi0JceRkqlVGGn5Qb8l0H1QHHNq9Jq2L4fQoAYwAw4 1CNsmNdLU7On9RUikR0= X-Received: by 10.80.212.14 with SMTP id t14mr6216944edh.172.1501256949723; Fri, 28 Jul 2017 08:49:09 -0700 (PDT) Received: from [192.168.1.159] ([149.12.11.37]) by smtp.googlemail.com with ESMTPSA id o15sm13346136edo.68.2017.07.28.08.49.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 08:49:09 -0700 (PDT) To: cellar@ietf.org References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> <20170728153718.GK6482@nb4> From: Derek Buitenhuis Message-ID: Date: Fri, 28 Jul 2017 16:49:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170728153718.GK6482@nb4> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:49:25 -0000 On 7/28/2017 4:37 PM, Michael Niedermayer wrote: > Its meant to be the colorspace formed by the JPEG2000-RCT > I see this isnt ideally worded but iam ATM not sure how to word this > better > Maybe calling it YCbCr (JPEG2000-RCT) would be an option > > Besides the wording the colorspace formed by a reversible colorspace > transform is as much its own colorspace as YCbCr is distinct from RGB > > It may be that implementations treat colorspaces which can be > losslessly converted to RGB as RGB. But from a specification point of > view these are not RGB and we may add other lossless transforms from > RGB in the future All good points. Ideally, I'd just like to see it made clearer that the goal, or one of the goals, is to store RGB. It's not entirely clear to me how to best write this. >>> "frame_pixel_width" is defined as frame width in pixels. >>> >>> "frame_pixel_height" is defined as frame height in pixels. >> >> The document, up until this point, and after this point, always refers to >> samples. Why is it suddenly pixels? > > a RGB pixel represents 3 samples > do you see an error in how the terms are used ? It wasn't clear that "frame width in pixels" really meant that, to me. A width in pixels, to me, means the width in pixels that is displayed. Maybe a note can be added, or their description modified to reflect that? >> Where is 'glbl' defined? If it's only this spec, then it conflicts with >> existing custom boxes for e.g.: >> >> https://wiki.xiph.org/Oggless#Example_and_Discussion_of_the_MOV_container > > I think glbl was used as a generic box to hold a codec specific > global header. Was this ever written anywhere (Apple docs, or some ISO spec)? > if one looks at the bigger picture and not just ffv1 then a single > box should be simpler than a codec specific one. > a (de)muxer would otherwise probably need to have a list of these > boxes Aren't custom boxes like this kind of standard procedure for codec global data in MP4/MOV? Like hev1, avc1, etc. Unfortunate, though. Cheers, - Derek From nobody Fri Jul 28 10:18:13 2017 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 D195C131D15 for ; Fri, 28 Jul 2017 10:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Hci9REY13aNo for ; Fri, 28 Jul 2017 10:18:06 -0700 (PDT) Received: from 12.mo7.mail-out.ovh.net (12.mo7.mail-out.ovh.net [178.33.107.167]) (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 B194213216A for ; Fri, 28 Jul 2017 10:18:06 -0700 (PDT) Received: from player762.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 6717F64F39 for ; Fri, 28 Jul 2017 19:18:04 +0200 (CEST) Received: from [192.168.2.100] (p5DDB69BF.dip0.t-ipconnect.de [93.219.105.191]) (Authenticated sender: jerome@mediaarea.net) by player762.ha.ovh.net (Postfix) with ESMTPSA id D90E8E0097 for ; Fri, 28 Jul 2017 19:18:03 +0200 (CEST) To: cellar@ietf.org References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> From: Jerome Martinez Message-ID: <61ef1a40-7b56-4403-cde5-bba2aff0c338@mediaarea.net> Date: Fri, 28 Jul 2017 19:18:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 8199647549903409297 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelkedriedugddutdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 17:18:11 -0000 Le 28/07/2017 à 16:20, Derek Buitenhuis a écrit : > Hi all, > > Dave Rice pointed me at draft-ietf-cellar-ffv1-00 and draft-ietf-cellar-ebml-03, > and these are my thoughts upon a cursory look at the former. > > I'm new to this list / IETF stuff in general, so some of my comments may be moot > or a bit fuzzy. Thank you for reviewing. and we are new to IETF too (our first work), but experimented people are usually there when we do a mistake (BTW: thank you IETF for that). > > Comments follow inline below. > >> 2.2.9.1. remaining_bits_in_bitstream >> >> "remaining_bits_in_bitstream( )" means the count of remaining bits >> after the current position in that bitstream component. It is >> computed from the NumBytes value multiplied by 8 minus the count of >> bits of that component already read by the bitstream parser. > A bit confusing that this is named 'remaining_bits_in_bitstream', but in > reality it is 'remaining_bits_in_bitstream_component', not the whole > bitstream. Good point. This is the remaining bits in the current block (the Configuration Record or the Frame). I am not sure "component" fits here. I'll try to find an alternative suggestion. > >> o one column of samples to the left of the coded slice is assumed as >> identical to the samples of the leftmost column of the coded slice >> shifted down by one row > This doesn't specify what the top sample value should be, once the > column has been shifted down by one. Based on the diagram below, it > should be 0. OK. > >> left16s = l >= 32768 ? ( l - 65536 ) : l >> top16s = t >= 32768 ? ( t - 65536 ) : t >> diag16s = tl >= 32768 ? ( tl - 65536 ) : tl > Does the IETF specs generally define when arithmetic is signed/unsigned, or > do they defer to the C spec on integer promotion, etc.? From my point of view it is integer as defined in https://en.wikipedia.org/wiki/Integer (so "Z"). I'll check if it is defined somewhere else I'll make it explicit. > >> 3.7.2. JPEG2000-RCT > It's kind of a bit odd that this is titled like this, considering > section 3.7 is titled 'Color space' and JPEG2000-RCT is not a > color space, but a transform used to store RGB(A). From the discussion you got with Michael, I suggest to change the wording of colorspace_type in order to be more explicit about what it is, something like: 0: YCbCr (planar) 1: YCbCr (line, from JPEG2000-RCT) because in practice YCbCr samples are stored also with colorspace_type of 1 (and there is a difference of how it stored, plane and lines inside plane or line and planes inside lines) Maybe some informational text (the C like text is the reference) too. > >> 3.8.2. Huffman coding mode >> >> This coding mode uses Golomb Rice codes. The VLC code is split into > Redundant 'code'. Variable Length Code code. OK > >> if (run_count == 0 && run_mode == 1) { | >> if (get_bits1()) { | >> run_count = 1 << log2_run[run_index]; | >> if (x + run_count <= w) | >> run_index++; | >> } else { | >> if (log2_run[run_index]) | >> run_count = get_bits(log2_run[run_index]); | > get_bits1() and get_bits() first appear here, with no definition. > Should they not be defined in '2.2.9. Bitstream functions'? OK. > >> "frame_pixel_width" is defined as frame width in pixels. >> >> "frame_pixel_height" is defined as frame height in pixels. > The document, up until this point, and after this point, always refers to > samples. Why is it suddenly pixels? Definitely an issue, more eyes are good for catching such issue. We need to define Pixel (and Sample). Reading on the net, I see that sometimes sample is synonym of pixel, so we definitely need to make the difference more explicit with clear definition that a Pixel is the sum of all (1 to 4) primary samples (and change Pixel() to Sample() ). > >> pseudo-code | type >> --------------------------------------------------------------|----- >> ConfigurationRecord( NumBytes ) { | >> ConfigurationRecordIsPresent = 1 | >> Parameters( ) | >> while( remaining_bits_in_bitstream( NumBytes ) > 32 ) | >> reserved_for_future_use | u(1) >> configuration_record_crc_parity | u(32) >> } > Style changes completely half way through the spec, and also adds > types to the types column. It's pretty obvious the earlier pseudo-code > was pasted directly from libavcodec, but this code probably isn't > written by Michael at all. Very different stuff; e.g. the previous > code has variable types in the psuedo-code, but this does not. > Is this specific to bitstream descriptions? I started to reformat the pseudo-code, in order to be less tied to libavcodec or C, I did not yet reformatted the beginning (e.g. C uint8_t still there but not defined). > >> 4.1.3.1. In AVI File Format > Poor English. Perhaps remove the "In". Ditto for others. My English :(. I can remove "In", but need help for fixing "Poor English". > >> The Configuration Record extends the sample description box ("moov", >> "trak", "mdia", "minf", "stbl", "stsd") with a "glbl" box which >> contains the ConfigurationRecord bitstream. See [ISO.14496-12.2015] >> for more information about boxes. > Where is 'glbl' defined? If it's only this spec, then it conflicts with > existing custom boxes for e.g.: > > https://wiki.xiph.org/Oggless#Example_and_Discussion_of_the_MOV_container > > Not sure if this ever actually existed in practice or not, but it's > something. I don't catch "it conflicts", in my understanding it is actually exactly same (a "global header" is stored here, for both Vorbis and FFV1). Note that this is a description of how files in the wild are, we can not change that (e.g. doing like ISO who defines avc1, hvcC...) We don't have the money and time for going throw the ISO process, and I think that e.g. Dolby does not do any registration for similar atoms (dac3, dec3...) http://mp4ra.org/atoms.html has a very small list. As far as I know, it was an arbitrary decision from FFmpeg developers for storing any global header in a generic atom instead of having different atom name for each format (format is already provided elsewhere, no need of different atom name), and I see no reason not to use that by default. If it is not considered to have this part here because it is not something accepted by the MP4 standard body nor Apple (for MOV), we could say that this is informational only. > >> FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". For FFV1 >> versions 2 or less, the Matroska "CodecPrivate" Element SHOULD NOT be >> used. For FFV1 versions 3 or greater, the Matroska "CodecPrivate" >> Element MUST contain the FFV1 Configuration Record structure and no >> other data. See [Matroska] for more information about elements. > Why only SHOULD? Why not? We would like to avoid AVI compatibility layer (the files in the wild, using a template from Microsoft), and we would like to have a native binding in Matroska. > >> +-------+----------------------------+ >> | value | slice coding mode | >> +-------+----------------------------+ >> | 0 | normal Range Coding or VLC | >> | 1 | raw PCM | >> | Other | reserved for future use | >> +-------+----------------------------+ > This is the first and only time 'PCM' appears in this document. Should > it be defined, at least, or have a reference? This is for FFV1 v4, out of scope (and only "experimental" in FFmpeg), I'll remove this part, and we add it again when we work on v4. > >> pseudo-code | type >> --------------------------------------------------------------|----- >> Line( p, y ) { | >> if (colorspace_type == 0) { | >> for( x = 0; x < plane_pixel_width[ p ]; x++ ) | >> Pixel( p, y, x ) | >> } else if (colorspace_type == 1) { | >> for( x = 0; x < slice_pixel_width; x++ ) | >> Pixel( p, y, x ) | >> } | >> } | > This is the first and only time Pixel() appears in the document, and > without explanation. Right, this is the missing part in the spec, on my ToDo-list. (Note: to be replaced by "Sample()" or other suggestion) > >> 4.8.5. colorspace_type >> >> "colorspace_type" specifies the color space. >> >> +-------+-------------------------+ >> | value | color space used | >> +-------+-------------------------+ >> | 0 | YCbCr | >> | 1 | JPEG2000-RCT | >> | Other | reserved for future use | >> +-------+-------------------------+ > Same comment as before: JPEG2000-RCT is not a color space. See answer before :). > >> 4.8.8. h_chroma_subsample >> >> "h_chroma_subsample" indicates the subsample factor between luma and >> chroma width ("chroma_width = 2^(-log2_h_chroma_subsample) * >> luma_width"). >> >> 4.8.9. v_chroma_subsample >> >> "v_chroma_subsample" indicates the subsample factor between luma and >> chroma height ("chroma_height=2^(-log2_v_chroma_subsample) * >> luma_height"). > I get that the spec is trying to be mathematically correct, but why > can't this contain the method that literally every single implementation > will ever use: bitshifting by {v,h}_chroma_subsample. It's even a > defined operator in "2.2.1. Arithmetic operators", and is used in > e.g. the JPEG2000-RCT equations. OK. > > Further, the name 'log2_h_chroma_subsample', in the definition, is > incorrect. OK > > > Hopefully these comments have some value! They definitely are! This is good to have a new pair of eyes on it, this permits to see errors we don't see because we read the doc too many times and consider some parts as obvious but they are not. I'll prepare a bunch of Pull Requests on GitHub (I'll ping on the list when it is ready, for comments) Jérôme From nobody Fri Jul 28 17:21:29 2017 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 0A9E41321E9 for ; Fri, 28 Jul 2017 17:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 uWaLT5UNo5y6 for ; Fri, 28 Jul 2017 17:21:24 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 A9625132096 for ; Fri, 28 Jul 2017 17:21:24 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k190so51234177pgk.5 for ; Fri, 28 Jul 2017 17:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=6v6lbpf0xfvEOOyNF56ofVKvDC9WPWKtd2iBodcL+wQ=; b=CuJaWFUlpm72YJCfeKm4WPAHvBCP+bl5s4xsnb/H1dHTpcgOgLIdYwEQ1E7OZCE+Ca ESlAKeCInszgD5FsAQCTgOmc91og7GqcV0XFB7IvXoSB6U/95cBmT63J0xiBovGNn26/ 3l9knoDFLDi+fyMU2BjiUOKUP8fhNFLR/aFPY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6v6lbpf0xfvEOOyNF56ofVKvDC9WPWKtd2iBodcL+wQ=; b=lolFAcNXS6d+jOYaQXr/jHSdvWTJK9+7GFPKH+ovfixQUQhioCT4D/RP3xmPZALrjN hrdetkaLoZgMBiFzCwLMqmF3N+BWOtIquKeaFsxNwNUSKJWR6igIllVWYyLhAgA8jLSd WGEUXOxlVoHFN8uSaEVf8yx/xNXI/kI9LTYtDsqUIsy5HMPExb+aGNHOGE6uxqhXjNzK V88VFtkBD2Xs2s87ZwlGdHsIRiuRmwg1vqkhumfOJ/FoyvxkUs1r8cET3Hcy4sEQcXRm 6U3xkNe5dmHW+TzBbks420lynEox08ZTeoBSc5futOb7tBmRvLXUj5MblIVUKPFtzgP+ Czqw== X-Gm-Message-State: AIVw110/jkiilxS5neWINWGPTy+1MoAuNusIOC7k8zLSb3gImSHCI+el IWelM6B2/eBtqRRDDpPcXQ== X-Received: by 10.98.70.86 with SMTP id t83mr8906913pfa.219.1501287683979; Fri, 28 Jul 2017 17:21:23 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:2327:96bb:70fb:bb1c? ([2620:101:80fc:224:2327:96bb:70fb:bb1c]) by smtp.gmail.com with ESMTPSA id u13sm39001146pgq.75.2017.07.28.17.21.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jul 2017 17:21:23 -0700 (PDT) To: cellar@ietf.org References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> <20170728153718.GK6482@nb4> From: Thomas Daede Message-ID: <0ac59e3c-e7e5-67da-5158-f29cddf5955d@mozilla.com> Date: Fri, 28 Jul 2017 17:21:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jul 2017 00:21:28 -0000 On 07/28/2017 08:49 AM, Derek Buitenhuis wrote: > On 7/28/2017 4:37 PM, Michael Niedermayer wrote: >> if one looks at the bigger picture and not just ffv1 then a single >> box should be simpler than a codec specific one. >> a (de)muxer would otherwise probably need to have a list of these >> boxes > > Aren't custom boxes like this kind of standard procedure for codec > global data in MP4/MOV? Like hev1, avc1, etc. Unfortunate, though. For Opus in MP4, we used a custom sample entry box ("Opus"), which turned out to be easy to register: http://mp4ra.org/codecs.html The FLAC in MP4 mapping likewise uses a custom one ("fLaC"), see: https://bug1286097.bmoattachments.org/attachment.cgi?id=8805161 It would be nice for FFV1 to be consistent. However, if there are actually a lot of FFV1 MP4 files in the wild, it would be good to at least informationally document it for old versions. In practice, there's nothing inside the stds box for it to conflict with. From nobody Sat Jul 29 01:08:45 2017 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 0D845124BE8 for ; Sat, 29 Jul 2017 01:08:44 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugRPPhVRuDke for ; Sat, 29 Jul 2017 01:08:41 -0700 (PDT) Received: from 5.mo7.mail-out.ovh.net (5.mo7.mail-out.ovh.net [178.32.120.239]) (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 CE385120227 for ; Sat, 29 Jul 2017 01:08:40 -0700 (PDT) Received: from player762.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 3405C659E2 for ; Sat, 29 Jul 2017 10:08:38 +0200 (CEST) Received: from [192.168.2.100] (p5DDB69BF.dip0.t-ipconnect.de [93.219.105.191]) (Authenticated sender: jerome@mediaarea.net) by player762.ha.ovh.net (Postfix) with ESMTPSA id B1C3CE0077 for ; Sat, 29 Jul 2017 10:08:37 +0200 (CEST) To: Codec Encoding for LossLess Archiving and Realtime transmission References: <517340df-9bc8-c4e5-1085-011dcbaa54ce@gmail.com> <20170728153718.GK6482@nb4> <0ac59e3c-e7e5-67da-5158-f29cddf5955d@mozilla.com> From: Jerome Martinez Message-ID: <1dbf919a-073d-3021-17cf-43e1692474a7@mediaarea.net> Date: Sat, 29 Jul 2017 10:08:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <0ac59e3c-e7e5-67da-5158-f29cddf5955d@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 4793237380541714577 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelkedrieefgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Quick Review of draft-ietf-cellar-ffv1-00 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 29 Jul 2017 08:08:44 -0000 Le 29/07/2017 à 02:21, Thomas Daede a écrit : > On 07/28/2017 08:49 AM, Derek Buitenhuis wrote: >> On 7/28/2017 4:37 PM, Michael Niedermayer wrote: >>> if one looks at the bigger picture and not just ffv1 then a single >>> box should be simpler than a codec specific one. >>> a (de)muxer would otherwise probably need to have a list of these >>> boxes >> Aren't custom boxes like this kind of standard procedure for codec >> global data in MP4/MOV? Like hev1, avc1, etc. Unfortunate, though. > For Opus in MP4, we used a custom sample entry box ("Opus"), which > turned out to be easy to register: > http://mp4ra.org/codecs.html I understand that the discussion moved from the "Specific Box" atom to the "Sample Entry Code", this is a bit disturbing and I am a bit lost. I try to summarize what exists and issues. I understand that "Opus" it for the "Sample Entry Codes" part, and I see "Opus" in the list on mp4ra.org, good. for FFV1, "Sample Entry Code" is "FFV1" (registration pending), I see that it is so "obvious" in my mind that I forgot to write it in the corresponding part, I'll fix that (same for AVI) As I understand, the "Specific Box" is "dOps" for Opus, and MP4/FFV1 files in the wild have a "Specific Box" of "glbl". > > The FLAC in MP4 mapping likewise uses a custom one ("fLaC"), see: > > https://bug1286097.bmoattachments.org/attachment.cgi?id=8805161 Just to be clear: "fLaC" is the "Sample Entry Code", "dfLa" is the "Specific Box" atom name. > > It would be nice for FFV1 to be consistent. However, if there are > actually a lot of FFV1 MP4 files in the wild, it would be good to at > least informationally document it for old versions. In practice, there's > nothing inside the stds box for it to conflict with. I guess that it is like "V_FFV1" mapping for Matroska, we would have to move to "common practices" with a "dfv1"/"fv1C" (letter to add/letter to remove/uppercase/lowercase to be defined) atom instead of current "glbl" generic atom name specified nowhere for the moment, with a transition plan in FFmpeg/libav as we do for "V_FFV1", if we all agree. On my side, I like the idea of "glbl" atom common to several formats (for demuxer, it is easier to pass this atom to the decoder during parsing than checking which atom is the initialization specific box, this is more generic) but I understand the consistency request, so no strong opinion now (just a small one for "glbl" as we already have files in the wild with that). Others? Note: the initialisation (stream not decodable if missing) "Specific boxes" for some formats: - AVC: "avcC" - HEVC: "hvcC" - FLAC: "dfLa" - Opus: "dOps" We also have: - AC-3: "dac3" - E-AC-3: "dec3" - DTS: "ddts" but theses box are not initialisation (if they are missing, the stream is still decodable, as far as I understand) "???C" are listed in "Box types contained in specific Sample Entries" in http://mp4ra.org/codecs.html "d???" are not listed in "Box types contained in specific Sample Entries" in http://mp4ra.org/codecs.html Was there a reason to choose "d???" instead of "???C" for initialisation (called "Configuration" by ISO) e.g. some atom names reserved by ISO? Any downside to use "glbl" "Specific Box" with 2 different "Sample Entry Codes"? From nobody Sun Jul 30 09:54:54 2017 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 96CD11200C5 for ; Sun, 30 Jul 2017 09:54:52 -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, 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 FoL5_EMXMX5b for ; Sun, 30 Jul 2017 09:54:51 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 AF40F127B60 for ; Sun, 30 Jul 2017 09:54:50 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id d29so173473404uai.2 for ; Sun, 30 Jul 2017 09:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GOcUvvLlGfrBadSrw2Zajkd/R1jeczhKnud71zssxns=; b=ZNwi3lO4IRpB5o5AyXB+uZ7cAiXw1C+j2ddoNEEoB93Tj6ijYzu4gXtuuVpIGRlMjB KfB2IOKriHglj1BgqnHQ1IGBORQO008EWyDE6lpHTMiw7bsiu80155Zk3WERrX9NrmO3 1GdlwVz2BdxWacW6hoMK8rkZpVWXKF7mSPYKy5WcGbA/DSX8G7YJb2AYY50LU7sUWhhV SDSJcdGgKCsdsU9L2ePUkmJwF6bv35TvArijFj4pukl3sd7Z7DA0sQ6nu2fsHGPxvgUy RSNcVRqnLr2ybCYKCaRlh78ZmfYn/YoigYT6XJYCTS/Iu2pHASbRo86f25AU1zIegODn i4+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GOcUvvLlGfrBadSrw2Zajkd/R1jeczhKnud71zssxns=; b=RT8fPjdew9+L+dwh2gNVVma3QLc8PRhDZxPpf9ZfrM2ZqRLWS7K+EYOJ9UdPO5aW6z Lc3CTs+R5XM+WcWXRDdYXTJrQ2WB5Om/ibkwYwX7aLZSrVR0hikP3CXsVKARjw0rWswU heUHvQQum4zuNRreP3Ghv6fahw8L1PkNwLOPTr1fue03FrgCbAjA5pst/grPtR08Y+o4 +45IHpl1V20IBQAIcnmUd6RIlq4JpLfSxOGgKvlYBY2dXohf6KkSNufQ7U9SLgtbOoiA c+B/zbXeuiGIZvZ/d/iQi4HQ/FXFFKtCgFN4hKBJvTolDYSl28ClROqiv8W8O1wODLYT a0wQ== X-Gm-Message-State: AIVw110XY8oQuOvS4Rxy3uVbebNwcjqYO5ad+egxU+TkNYAOUByU+LLn x7gkGoEtxJKanmpZJdPNI9o2iVNjnHC/2+Y= X-Received: by 10.176.75.167 with SMTP id v39mr9529186uaf.11.1501433689457; Sun, 30 Jul 2017 09:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 30 Jul 2017 09:54:48 -0700 (PDT) From: Ashley Blewer Date: Sun, 30 Jul 2017 12:54:48 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="f4030436269eb6c8f705558bc57a" Archived-At: Subject: [Cellar] Refining language in Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jul 2017 16:54:53 -0000 --f4030436269eb6c8f705558bc57a Content-Type: text/plain; charset="UTF-8" Hi CELLAR! I have been reading through the Matroska specification and thinking about the clarity of the language, especially in the light of RFC 2119 . I'm considering Tim's initial review of the ebml-specification as a guide to the kind of language clean-up that can be done towards making this an IETF-approved spec. I skipped the Intro section and went straight for the Diagram section. (It seemed more polite to start there, as a non-original-author.) I have opened up a PR here: https://github.com/Matroska-Org/matroska-specification/pull/156 I would like to continue this work, but would appreciate some feedback before I consider the other sections. Off-list, to Dave Rice, I brought up the question of how to speak of and quote (or backtick, in Markdown) related elements, and he recommended I follow the patterns in ebml-specification, so I did my best to do that. My question was around if elements should be defined and described as `Example Element`, `Example` Element, or `Example`. (The recommendation is for the first of that group of three). If that turns out to not be the case, I can remediate. Thanks all, Ashley --f4030436269eb6c8f705558bc57a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi CELLAR!

I have been reading through = the Matroska specification and thinking about the clarity of the language, = especially in the light of RFC 2119. I'm considering Tim's initial review of th= e ebml-specification as a guide to the kind of language clean-up that c= an be done towards making this an IETF-approved spec.

<= div>I skipped the Intro section and went straight for the Diagram section. = (It seemed more polite to start there, as a non-original-author.)=C2=A0I ha= ve opened up a PR here:=C2=A0https://github.com/Matroska-Org/matroska-spec= ification/pull/156

I would like to continue th= is work, but would appreciate some feedback before I consider the other sec= tions.=C2=A0

Off-list, to Dave Rice, I brought up = the question of how to speak of and quote (or backtick, in Markdown) relate= d elements, and he recommended I follow the patterns in ebml-specification,= so I did my best to do that. My question was around if elements should be = defined and described as `Example Element`, `Example` Element, or `Example`= . (The recommendation is for the first of that group of three). If that tur= ns out to not be the case, I can remediate.

Thanks= all,

Ashley
--f4030436269eb6c8f705558bc57a-- From nobody Sun Jul 30 15:51:10 2017 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 2EC2C129A9F for ; Sun, 30 Jul 2017 15:51:09 -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, 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 pDfPIkggqXQL for ; Sun, 30 Jul 2017 15:51:07 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 3E6FF12EB9B for ; Sun, 30 Jul 2017 15:51:07 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id d29so174855347uai.2 for ; Sun, 30 Jul 2017 15:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FLuAlTTahML0UiHTXoQk8CpkQXZQqqaPaZQkb/AMhjo=; b=nQqXbC/JroXkiEgCgGZ9lVXqqps1DI9kYWDdpGu39Cj+U8x/e9uAvRf7IX/I8EN+tV 4ukEpsIV0P9wZsSOCj98g3g1lQyfz4A4a7F154Ae5qyG++K6ZXPWYxVKg82i6lgOA/wS ZRZQuISJetCYXnnavZPOpuJRvquoa2KTd/b/d2HcY+KwQtw8uc66/iFXedRbHYXcpZZD nLBE2N1GPe+UKHOaYgpfavz3/G4xGs1cN0RUhkPC8YE9c+J75KhfcTxdcJ8eGeh66wWh luYvrU+BgLtguiu49Ilu3Ihe+5xLnhbVF1HOlLESqmhQa+4NAgjfnqts7LD8oXjnBjnZ BuPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FLuAlTTahML0UiHTXoQk8CpkQXZQqqaPaZQkb/AMhjo=; b=VW63pzCRL5hE4L5znVBlWYpFdQGI+3xw+URGx0zJz4k7XzlYEoM1ncu5EZCvkdEn10 fxgemu/4VjnVTXPIqo9ubX4XiHQyQcGFakCUmA/4qM3raEq8CVRiaODsjgI+iGnB09ey lmcq5Tg4XqukbktoRRSa9NsymAlD5yDgw3cF0zRQmKusweiqpgBl5W3MRlS1RqMglmFV iyGOQqQo0X7Nw7yzJ7O/yv7MzAOrBoaE4r1tFIadtI/MLrpQYhPCSAhs45KsxtS/laJ4 GnvuMawlTRIejq9v8Ykx5i/IYc+4Aj6vZF5/v7c3O7ywMFUlHIJvMj6Kxm5ehWoP+e5S tHMg== X-Gm-Message-State: AIVw110V3McGEnGCks0AP4eY+zDFMdloiDSmwXQPoaMfULAQSc2fkGBc CbnL97pe9C+whaee38P/eQ1u5SmCdc7Pbhg= X-Received: by 10.176.70.96 with SMTP id z32mr9923656uab.37.1501455066062; Sun, 30 Jul 2017 15:51:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.180.9 with HTTP; Sun, 30 Jul 2017 15:51:05 -0700 (PDT) In-Reply-To: References: From: Ashley Blewer Date: Sun, 30 Jul 2017 18:51:05 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="f403045f008edbe3ee055590bf67" Archived-At: Subject: Re: [Cellar] Refining language in Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jul 2017 22:51:09 -0000 --f403045f008edbe3ee055590bf67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello! To follow up on this and much great feedback from Moritz, I moved on to Ordered Guidelines part of the Matroska specification. I opened a PR with some small changes , but have a larger question (also repeated in the PR dialogue box): Overall, I am wondering if the content in ordered_guidelines should be checked for duplication in the rest of the specification and then left out of the RFC Makefile. It seems to me that most of this section is either repeated elsewhere (diagram.md -- with conflicting information, as I commented in the above PR #156 ) or it contains recommendations not required to be in the official specification. Thoughts? My best, Ashley =F0=9F=90=B3 On Sun, Jul 30, 2017 at 12:54 PM, Ashley Blewer wrote: > Hi CELLAR! > > I have been reading through the Matroska specification and thinking about > the clarity of the language, especially in the light of RFC 2119 > . I'm considering Tim's initial > review of the ebml-specification > > as a guide to the kind of language clean-up that can be done towards maki= ng > this an IETF-approved spec. > > I skipped the Intro section and went straight for the Diagram section. (I= t > seemed more polite to start there, as a non-original-author.) I have open= ed > up a PR here: https://github.com/Matroska-Org/matroska- > specification/pull/156 > > I would like to continue this work, but would appreciate some feedback > before I consider the other sections. > > Off-list, to Dave Rice, I brought up the question of how to speak of and > quote (or backtick, in Markdown) related elements, and he recommended I > follow the patterns in ebml-specification, so I did my best to do that. M= y > question was around if elements should be defined and described as `Examp= le > Element`, `Example` Element, or `Example`. (The recommendation is for the > first of that group of three). If that turns out to not be the case, I ca= n > remediate. > > Thanks all, > > Ashley > --f403045f008edbe3ee055590bf67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello! To follow up on this and much great feedback from M= oritz, I moved on to Ordered Guidelines part of the Matroska specification.=

I opened a PR with some small changes, but hav= e a larger question (also repeated in the PR dialogue box):

<= /div>
Overall, I am wondering if the content in ordered_guidelines shou= ld be checked for duplication in the rest of the specification and then lef= t out of the RFC Makefile. It seems to me that most of this section is eith= er repeated elsewhere (diagram.md -- with= conflicting information, as I commented in the above PR #156 ) or it conta= ins recommendations not required to be in the official specification. Thoug= hts?=C2=A0

My best,

A= shley=C2=A0=F0=9F=90=B3

On Sun, Jul 30, 2017 at 12:54 PM, Ashley Blewer <a= shley.blewer@gmail.com> wrote:
Hi CELLAR!

I have been reading thro= ugh the Matroska specification and thinking about the clarity of the langua= ge, especially in the light of RFC 2119. I'm considering Tim's initial review of the ebml-specification as a guid= e to the kind of language clean-up that can be done towards making this an = IETF-approved spec.

I skipped the Intro section an= d went straight for the Diagram section. (It seemed more polite to start th= ere, as a non-original-author.)=C2=A0I have opened up a PR here:=C2=A0https://github.com/Matroska-Org/matroska-specificat= ion/pull/156

I would like to continue this wor= k, but would appreciate some feedback before I consider the other sections.= =C2=A0

Off-list, to Dave Rice, I brought up the qu= estion of how to speak of and quote (or backtick, in Markdown) related elem= ents, and he recommended I follow the patterns in ebml-specification, so I = did my best to do that. My question was around if elements should be define= d and described as `Example Element`, `Example` Element, or `Example`. (The= recommendation is for the first of that group of three). If that turns out= to not be the case, I can remediate.

Thanks all,<= /div>

Ashley

--f403045f008edbe3ee055590bf67-- From nobody Sun Jul 30 16:38:41 2017 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 91D2112EC32 for ; Sun, 30 Jul 2017 16:38:39 -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 ST-2UHgJfG8f for ; Sun, 30 Jul 2017 16:38:38 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126E812EB99 for ; Sun, 30 Jul 2017 16:38:38 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id v127so118460998itd.0 for ; Sun, 30 Jul 2017 16:38:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=/5sWcn6LFISTaxNoXb6CgM+8/JMY1wzEJP/ijqLfmEg=; b=TcLIIF/cjSPwUGANBP8M2R+ShtssXS637mSZSlr8zcrK8MgV7uxr1IAREhNDbssJES +jmIHiEZiBuV8/NTm3xa/InbXBX21hCoOyuJQrfC+g1uY7iFSkf9KQi23lALe7KFEA2S ppzOQ3ORg/bSfOzrndpX1hoLeC5WRaUnlmFNYKhSf/AabzDtqSjFwGm5M5ko/QiTIeOU /HFjT3Upjxeg2Tx2sJabkiOkA/0pG+wuFG+MN0L2F6HEi2IaZ3ytm/johBrvrVp1qF8G hFRcES1DHs6d+98jYJLGW3JoL3qBvahrjGb1MnUVRxKSMJ9St2HI5NncgahSNPssWnHN h8BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=/5sWcn6LFISTaxNoXb6CgM+8/JMY1wzEJP/ijqLfmEg=; b=gkSUwqGxotfcpwxkrl6fWrhtjYfPIa7/t6ri+ulFwEekTAxZqE70OtPKenkl4AUBAe awcJR2gZtIVPf+bbj8M3C3h8sVfZc3kK3IoipXhU8aecfxQDUqx8GpTO6b8hujV3/Dv3 FSV6EdEdyEP4/SNNo49y5QlDW+9QizcrDg36g14E5TZNLcoJrPxOgng/vswn4vY3ilLb ypW59Q8X6J9NICwycmL1Wug6eJZb55CMqQIgN8i6+Bkc9jAZnkGtbUGF3f5b7mk9b5UA 6FhMwum1hr2LmO6kIWxhZp/0L/eyoMwjo4F0QsL53QWC7E/KxeY7cJxoNHsgm295RwWU VfFA== X-Gm-Message-State: AIVw113RJE9yqFouTnZLb2PMMR91AIRkUHN0qlKF51ztwkiW+JDGfucN ubDvHQRo8yRpXL0hGvA= X-Received: by 10.36.5.136 with SMTP id 130mr16866810itl.68.1501457917160; Sun, 30 Jul 2017 16:38:37 -0700 (PDT) Received: from ?IPv6:2601:243:504:643:7031:3829:5c7c:6acc? ([2601:243:504:643:7031:3829:5c7c:6acc]) by smtp.gmail.com with ESMTPSA id j191sm718472ioe.60.2017.07.30.16.38.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Jul 2017 16:38:35 -0700 (PDT) From: Rodger Combs Content-Type: multipart/alternative; boundary="Apple-Mail=_8699A7E3-C672-4C07-9266-F1905235A0FE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 30 Jul 2017 18:38:34 -0500 References: <027149E8-31E1-4EC0-AD40-6E9B84FFF8F5@gmail.com> To: cellar@ietf.org In-Reply-To: <027149E8-31E1-4EC0-AD40-6E9B84FFF8F5@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Cellar] Matroska: "Forced" and "Default" flag definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 30 Jul 2017 23:38:39 -0000 --Apple-Mail=_8699A7E3-C672-4C07-9266-F1905235A0FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've submitted these changes as a PR to the specification repository: = https://github.com/Matroska-Org/matroska-specification/pull/158 = > On Jul 20, 2017, at 01:32, Rodger Combs = wrote: >=20 > Currently, Matroska's "forced" flag's documentation describes a = feature that wouldn't be particularly useful as defined, and doesn't = match any implementation's behavior I know of (though if any = implementation actually does overlay a forced track alongside a normal = one, please let me know). I'd like to propose an updated definition of = the default and forced flags: >=20 > - Default: > For audio or video, set if that track SHOULD be active if no language = found matches the user's preference; this can be used to specify the = original content language. For subtitles, set if that track SHOULD be = chosen if there are multiple tracks which match the user's language = preferences. (1 bit) >=20 > Alternate definition: > Set if that track (audio, video or subs) SHOULD be active if multiple = tracks found matches the user's language preference. This can be used to = specify a "normal" track (as opposed to other tracks containing = commentary or other alternate content). (1 bit) >=20 > If the alternate definition is used, then the original/default = language should be the first track of its type. If the first definition = given is used, then the first track of a given language and type should = be the "normal" one. It might be generally useful to add flags for track = types (commentary, hearing-impaired, descriptive audio service, etc...), = but that's out of scope of this proposal. >=20 > - Forced: > Applies only to subtitles. Set if that track SHOULD be active during = playback, even if the user's preferences would normally not enable = subtitles with the selected audio track; this can be used for tracks = containing only translations of foreign-language audio or onscreen text. = (1 bit) >=20 >=20 > These definitions better match the intent of the flags on DVD and BD, = without implying user-hostile behavior or overlays of multiple tracks, = and I think they do a better job of carrying information about the = relevant tracks. They also match at least some existing implementation = behavior. --Apple-Mail=_8699A7E3-C672-4C07-9266-F1905235A0FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I've submitted these changes as a PR to the = specification repository: https://github.com/Matroska-Org/matroska-specification/pull/158=

On Jul 20, 2017, at 01:32, Rodger Combs <rodger.combs@gmail.com> wrote:

Currently, Matroska's "forced" flag's documentation describes = a feature that wouldn't be particularly useful as defined, and doesn't = match any implementation's behavior I know of (though if any = implementation actually does overlay a forced track alongside a normal = one, please let me know). I'd like to propose an updated definition of = the default and forced flags:

- Default:
For audio or video, set if that track SHOULD be active if no = language found matches the user's preference; this can be used to = specify the original content language. For subtitles, set if that track = SHOULD be chosen if there are multiple tracks which match the user's = language preferences. (1 bit)

Alternate = definition:
Set if that track (audio, video or subs) = SHOULD be active if multiple tracks found matches the user's language = preference. This can be used to specify a "normal" track (as opposed to = other tracks containing commentary or other alternate content). (1 = bit)

If the alternate definition is used, = then the original/default language should be the first track of its = type. If the first definition given is used, then the first track of a = given language and type should be the "normal" one. It might be = generally useful to add flags for track types (commentary, = hearing-impaired, descriptive audio service, etc...), but that's out of = scope of this proposal.

- Forced:
Applies only to subtitles. Set if that track SHOULD be active = during playback, even if the user's preferences would normally not = enable subtitles with the selected audio track; this can be used for = tracks containing only translations of foreign-language audio or = onscreen text. (1 bit)


These = definitions better match the intent of the flags on DVD and BD, without = implying user-hostile behavior or overlays of multiple tracks, and I = think they do a better job of carrying information about the relevant = tracks. They also match at least some existing implementation = behavior.

= --Apple-Mail=_8699A7E3-C672-4C07-9266-F1905235A0FE-- From nobody Sun Jul 30 23:54:55 2017 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 97F8E131C2E for ; Sun, 30 Jul 2017 23:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-XNVd5zicLR for ; Sun, 30 Jul 2017 23:54:52 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 B9F29126C0F for ; Sun, 30 Jul 2017 23:54:52 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g13so107138596ioj.5 for ; Sun, 30 Jul 2017 23:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y/KFZD0O7rb0Un5rHXItUPyXw+YQANsnKQNbEOf2bC4=; b=qZI9Hsw2Fhm64TIF9Eytilp6GndBB0kA+2XAW6svIXBS+cpKHhV+YsPfR6ryD2XoC6 n3yIa84B/iNMkited7sk2T3Nj2iWz4sIotO7g4keql2EsPh4upUU7HX6VCTlthAThfd7 oLEAQ0Xk3wTtRzBraZUUES18eFLrX8j9P/nfFUQDXCfLNLIcQE8hDH2hXw8Hd1St6pzG 7VIP6rkWP9fwu67z/Ur8+xWob3EQq4G7ZDPWuzDR6NCKLEqg7w4f5Yv4F8x0S557/Wt+ zpwRWwlymc4x6eVOzHk+cf8eFXKpb54VXWNTPrZHWC0WimseD2i0eRaAbH8RCn3MYEOQ WpGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y/KFZD0O7rb0Un5rHXItUPyXw+YQANsnKQNbEOf2bC4=; b=Zfg7XJY5ZEzXG2A43Woqi+h6MzjdiUkBHVuQZCvY3lRsWXha74mNJPqExzstUiiGbd nKHBJ4XuFUto4LWp3wv8KgPtijO3uT5Mjjp2pwkVAwnxJH11wchP7DWeF42pjcxma5gv Z5bEfs4JncynwyyTkP1lYeMRhpTo7eVAIngCuJBHYUCONo7z+IhzwN8f9akgEmpVdd7h YX74zjPu47zhychz220UtQUAL2M8A5OD01F+NeJnEPI5nZfVdP2+QOnJrYP/w3L3srd8 CVEdGKWPTN+ILFFPyu9gkn/jILNfVImKDHGWhMOjI+039pjq0qL8gr2WmL81XrtWYGN+ 36Tw== X-Gm-Message-State: AIVw111uyl1PcClDDv+aQ1p8hEwdmcfby6714oogXit5NKgSgMnk4uQr LhM3URokbapRfxE5bLntAcu43DfN88Fs X-Received: by 10.107.135.33 with SMTP id j33mr19187401iod.257.1501484091972; Sun, 30 Jul 2017 23:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Sun, 30 Jul 2017 23:54:11 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Mon, 31 Jul 2017 02:54:11 -0400 Message-ID: To: Ashley Blewer Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="001a113ed072f023c805559781c7" Archived-At: Subject: Re: [Cellar] Refining language in Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 06:54:55 -0000 --001a113ed072f023c805559781c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ashley, It seems like you're doing great work with this. Thanks, Tessa On Sun, Jul 30, 2017 at 6:51 PM, Ashley Blewer wrote: > Hello! To follow up on this and much great feedback from Moritz, I moved > on to Ordered Guidelines part of the Matroska specification. > > I opened a PR with some small changes > , but > have a larger question (also repeated in the PR dialogue box): > > Overall, I am wondering if the content in ordered_guidelines should be > checked for duplication in the rest of the specification and then left ou= t > of the RFC Makefile. It seems to me that most of this section is either > repeated elsewhere (diagram.md -- with conflicting information, as I > commented in the above PR #156 ) or it contains recommendations not > required to be in the official specification. Thoughts? > > My best, > > Ashley =F0=9F=90=B3 > > On Sun, Jul 30, 2017 at 12:54 PM, Ashley Blewer > wrote: > >> Hi CELLAR! >> >> I have been reading through the Matroska specification and thinking abou= t >> the clarity of the language, especially in the light of RFC 2119 >> . I'm considering Tim's initial >> review of the ebml-specification >> >> as a guide to the kind of language clean-up that can be done towards mak= ing >> this an IETF-approved spec. >> >> I skipped the Intro section and went straight for the Diagram section. >> (It seemed more polite to start there, as a non-original-author.) I have >> opened up a PR here: https://github.com/Matro >> ska-Org/matroska-specification/pull/156 >> >> I would like to continue this work, but would appreciate some feedback >> before I consider the other sections. >> >> Off-list, to Dave Rice, I brought up the question of how to speak of and >> quote (or backtick, in Markdown) related elements, and he recommended I >> follow the patterns in ebml-specification, so I did my best to do that. = My >> question was around if elements should be defined and described as `Exam= ple >> Element`, `Example` Element, or `Example`. (The recommendation is for th= e >> first of that group of three). If that turns out to not be the case, I c= an >> remediate. >> >> Thanks all, >> >> Ashley >> > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a113ed072f023c805559781c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ashley,

It seems like you're doing = great work with this.

Thanks,
Tessa

On Sun, Ju= l 30, 2017 at 6:51 PM, Ashley Blewer <ashley.blewer@gmail.com>= ; wrote:
Hello! T= o follow up on this and much great feedback from Moritz, I moved on to Orde= red Guidelines part of the Matroska specification.

I= opened a PR with some small changes, but have a lar= ger question (also repeated in the PR dialogue box):

Overall, I am wondering if the content in ordered_guidelines should be c= hecked for duplication in the rest of the specification and then left out o= f the RFC Makefile. It seems to me that most of this section is either repe= ated elsewhere (diagram.md<= /a> -- with conflicting information, as I commented in the above PR #156 ) = or it contains recommendations not required to be in the official specifica= tion. Thoughts?=C2=A0


On Sun= , Jul 30, 2017 at 12:54 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hi = CELLAR!

I have been reading through the Matroska specifi= cation and thinking about the clarity of the language, especially in the li= ght of R= FC 2119. I'm considering Tim's init= ial review of the ebml-specification as a guide to the kind of language= clean-up that can be done towards making this an IETF-approved spec.
=

I skipped the Intro section and went straight for the D= iagram section. (It seemed more polite to start there, as a non-original-au= thor.)=C2=A0I have opened up a PR here:=C2=A0https://git= hub.com/Matroska-Org/matroska-specification/pull/156

I would like to continue this work, but would appreciate s= ome feedback before I consider the other sections.=C2=A0

Off-list, to Dave Rice, I brought up the question of how to speak of= and quote (or backtick, in Markdown) related elements, and he recommended = I follow the patterns in ebml-specification, so I did my best to do that. M= y question was around if elements should be defined and described as `Examp= le Element`, `Example` Element, or `Example`. (The recommendation is for th= e first of that group of three). If that turns out to not be the case, I ca= n remediate.

Thanks all,

= Ashley


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

--001a113ed072f023c805559781c7-- From nobody Sun Jul 30 23:55:52 2017 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 22A21131C60 for ; Sun, 30 Jul 2017 23:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgzGRAKulqvy for ; Sun, 30 Jul 2017 23:55:48 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 AC030131C2E for ; Sun, 30 Jul 2017 23:55:48 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id c74so107454589iod.4 for ; Sun, 30 Jul 2017 23:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xtlh0CK61G0JQvb036N3Ng2Btm+/cI4MPnM8XlvRVHs=; b=H3L2hNGWD2ayHOvAW1IgNhRVepBAcmkKhbkI5AMX4UFBvuMMilY62uEkgn8kNtTmCB 66y9+JtW1CMTzBIVY9eN++aoD0ftBwhl87IhFs3OK2D83vxDXxmMkW2b/CzU4xmySgWr E3KtVjscHRyZfYF0nBdr2AyTeBHoczwTd9ziZrlAusIRrsLrRzKhSFJhX/jYGlg6yAXR nfs4DSzpYq9FkYCNhWHZ6hpV5dg1qEd22UwxqqqIjf+qdWTVTEYn7jKA4dqSyo6Es4TE 4mjU7/LzyqQ6b2hka3nhwFByKiUeC9xmN1hJY+7c82yqKD+aw9AcBFtg2+iWcAMXSaQQ Zv9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xtlh0CK61G0JQvb036N3Ng2Btm+/cI4MPnM8XlvRVHs=; b=m9jJhNE2iYTVfHQIAW/0mvEjeNErZB1EFU7OIT4WX8ZHZl6+2m7KehvV3Tuv/QKn+W QUoAlE3hZSy5Yo8a7loQJ3ydFETmSCJBN2+4Vuq1KLGUrk2bA1JTz3VSHs9mgd0p99KL hs8VVAHW6aRzGRGtJ1QRMgweh9T/nSzYUqq2v5sijsinPAoFXet64pLts4bW75KT2KuQ b8TeEYWXC3PrIm6dncctImPZQdP2pZT1SU6K96V5k+mL6qQopRbfUx8BfcNV/50yDkYv opqjEzsUWAqWCh8Cf+Ff0/2zK6cXp8SIjw4VjdeclWY/lAXLG/61BC6lCdDWXyw/3PKS eUAA== X-Gm-Message-State: AIVw111kbP5D0+QfBNcON7QLD696Gx7zlKzi3Xfrk18dTAy5Mgfsj/eM BXlYEHcuXBmkdB+TII03nwXKs7DlrjAl X-Received: by 10.107.201.150 with SMTP id z144mr16386221iof.132.1501484147794; Sun, 30 Jul 2017 23:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.15.213 with HTTP; Sun, 30 Jul 2017 23:55:07 -0700 (PDT) In-Reply-To: References: From: Tessa Fallon Date: Mon, 31 Jul 2017 02:55:07 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="94eb2c0b951a43e8580555978566" Archived-At: Subject: Re: [Cellar] Refining language in Matroska specification X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 31 Jul 2017 06:55:50 -0000 --94eb2c0b951a43e8580555978566 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry, not meant to be posted on the list. My bad. On Mon, Jul 31, 2017 at 2:54 AM, Tessa Fallon wrote: > Ashley, > > It seems like you're doing great work with this. > > Thanks, > Tessa > > On Sun, Jul 30, 2017 at 6:51 PM, Ashley Blewer > wrote: > >> Hello! To follow up on this and much great feedback from Moritz, I moved >> on to Ordered Guidelines part of the Matroska specification. >> >> I opened a PR with some small changes >> , but >> have a larger question (also repeated in the PR dialogue box): >> >> Overall, I am wondering if the content in ordered_guidelines should be >> checked for duplication in the rest of the specification and then left o= ut >> of the RFC Makefile. It seems to me that most of this section is either >> repeated elsewhere (diagram.md -- with conflicting information, as I >> commented in the above PR #156 ) or it contains recommendations not >> required to be in the official specification. Thoughts? >> >> My best, >> >> Ashley =F0=9F=90=B3 >> >> On Sun, Jul 30, 2017 at 12:54 PM, Ashley Blewer >> wrote: >> >>> Hi CELLAR! >>> >>> I have been reading through the Matroska specification and thinking >>> about the clarity of the language, especially in the light of RFC 2119 >>> . I'm considering Tim's initial >>> review of the ebml-specification >>> >>> as a guide to the kind of language clean-up that can be done towards ma= king >>> this an IETF-approved spec. >>> >>> I skipped the Intro section and went straight for the Diagram section. >>> (It seemed more polite to start there, as a non-original-author.) I hav= e >>> opened up a PR here: https://github.com/Matro >>> ska-Org/matroska-specification/pull/156 >>> >>> I would like to continue this work, but would appreciate some feedback >>> before I consider the other sections. >>> >>> Off-list, to Dave Rice, I brought up the question of how to speak of an= d >>> quote (or backtick, in Markdown) related elements, and he recommended I >>> follow the patterns in ebml-specification, so I did my best to do that.= My >>> question was around if elements should be defined and described as `Exa= mple >>> Element`, `Example` Element, or `Example`. (The recommendation is for t= he >>> first of that group of three). If that turns out to not be the case, I = can >>> remediate. >>> >>> Thanks all, >>> >>> Ashley >>> >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > --94eb2c0b951a43e8580555978566 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, not meant to be posted on the list. My bad.

On Mon, Jul 31, 201= 7 at 2:54 AM, Tessa Fallon <tessa.fallon@gmail.com> wro= te:
Ashley,

It seems like you're doing great work with this.

<= /div>
Thanks,
Tessa
On Sun, Jul 30, 2017 at = 6:51 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote= :
Hello! To follow up on this and much great feedback from Morit= z, I moved on to Ordered Guidelines part of the Matroska specification.
=

I opened a PR with some small change= s, but have a larger question (also repeated in the PR dialogue box):

Overall, I am wondering if the content in ordered_g= uidelines should be checked for duplication in the rest of the specificatio= n and then left out of the RFC Makefile. It seems to me that most of this s= ection is either repeated elsewhere (diagram.md -- with conflicting information, as I commented = in the above PR #156 ) or it contains recommendations not required to be in= the official specification. Thoughts?=C2=A0

M= y best,

Ashley=C2=A0=F0=9F=90=B3

On Sun, Jul 30, = 2017 at 12:54 PM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Hi CELLAR!
I have been reading through the Matroska specification and= thinking about the clarity of the language, especially in the light of RFC 2119. I'm considering Tim's initial review= of the ebml-specification as a guide to the kind of language clean-up = that can be done towards making this an IETF-approved spec.

<= /div>
I skipped the Intro section and went straight for the Diagram sec= tion. (It seemed more polite to start there, as a non-original-author.)=C2= =A0I have opened up a PR here:=C2=A0https://github.com/M= atroska-Org/matroska-specification/pull/156

I would like to continue this work, but would appreciate some feedb= ack before I consider the other sections.=C2=A0

Of= f-list, to Dave Rice, I brought up the question of how to speak of and quot= e (or backtick, in Markdown) related elements, and he recommended I follow = the patterns in ebml-specification, so I did my best to do that. My questio= n was around if elements should be defined and described as `Example Elemen= t`, `Example` Element, or `Example`. (The recommendation is for the first o= f that group of three). If that turns out to not be the case, I can remedia= te.

Thanks all,

Ashley


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


--94eb2c0b951a43e8580555978566--