From nobody Mon Aug 1 00:50:23 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAF12B01A for ; Mon, 1 Aug 2016 00:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 BsclXPtDbFIO for ; Mon, 1 Aug 2016 00:50:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA4012B014 for ; Mon, 1 Aug 2016 00:50:19 -0700 (PDT) Received: from [192.168.178.25] ([91.3.233.118]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MV6PJ-1bmy2e0dn3-00YS4G for ; Mon, 01 Aug 2016 09:50:17 +0200 To: cellar@ietf.org References: From: hubblec4 Message-ID: <8c8cd858-0546-3b6c-d236-dc7c6149518d@gmx.ch> Date: Mon, 1 Aug 2016 09:50:15 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:qLhE7BDoXpELjVLuGD70gtN4eDGUiwh7K+Sw5wa0likQFO6aGU0 ByYx81Ojr/jvdXcYsMCN0Gjyoujt/6VljjaIAQotMK82/VLY0d7Xb48prXED+afOJmkF7fJ pra/gw9T9Zk7pizESPpktaF88n8iAnnzWLxWUZUoKO1acKjRjxXLIZhrGm4TV6i2QMmaU3T AC+rhirNAC/Hx5jMKk6Ug== X-UI-Out-Filterresults: notjunk:1;V01:K0:HxT0zXugDKg=:PWVt+np474eKFE1Yo/cmEW BSljot3za8CLDmVUeS4HkhdWwkgl2814wuTDUXjGpqzJkqCBjnVp7TmFPkaZQCqQUevGhkGXW c2oT7dMNQXOx6w3U2SCOduebMBKetsOYoStG2fICTKUAY+mIH2Ggv0bfQJJwuzAoOytZBqLEQ qhVzoNM4BBG4B5akBlUeH3EqcoPrgTgRjRqgjO7BzQsBjWlGb69mpvbbfESZpvxg5PjQu8R0H ZF7jA7u4tzAjGtH9154odrvWPLI6TyX/JNy99TKf4G8eMjIWOf9DbecRM3y/SB/TlqYByb6+K oVAikOynkY1Y56k9mkVtV/5rC977ePcDqMsMdGRwitqfyRFqdgpBNJExBMYQClHATbouzBYXr Sig9Ve9x3r7lILJ4TB3vXyHoPZHYjUFIa4I3p8+uiiXAJz/YaAwxQchZvLIi5K5FBmMDW4G5N mCpjeniIcziIDxb1q2sA2jqE8uNDo+vjq1SgWuI1y5sp6ve+J0uL6wsGMnsHfQlppi769TXUC B+uZRa0JidwXkxVpMfvHhOUR9RFfbZK6ACqVD8ry67vREro4rHCpWw8SoP1kUDJVHr6Qkrw/E iueC3FiDUy8w6IFDZstp88vejiR/TE+fwjfAToxjUwu9VyFnF0Bjl0Me7XTSq0YYNcUCWndZz 0I63UBU1odUzJRqdzG2g+VwxVOW7YxbQBhxkgiIqzuVwHGEMfGBt3lxgegw5IvNpPVGfGo+V1 5rN4NwoGlbYp233kYf6hMoOH/2t27ONxGumJjsSyTxyLQUl51l0sKI09rzTBNTq2o7Qo5WqmU K1D7LBo Archived-At: Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 07:50:21 -0000 Am 31.07.2016 um 18:45 schrieb Reto Kromer: > Steve Lhomme wrote: > >> As we're moving towards splitting the Matroska specs in >> many smaller documents, > I personally would prefer to have one document containing > the full specification of Matroska. > > Best regards, Reto > I would prefer to have one document too. The old-style looks for me very well, more then better as many other spec-documents. And the new style by Dave is much more comfortable to navigate. Kind Regards Martin From nobody Mon Aug 1 07:30:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F39612D675 for ; Mon, 1 Aug 2016 07:30:23 -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 IJhLs4UqiZxX for ; Mon, 1 Aug 2016 07:30:18 -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 3A5E112D526 for ; Mon, 1 Aug 2016 07:30:15 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so173358724ywb.2 for ; Mon, 01 Aug 2016 07:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=byFux0+Ow59+RJi7Fc2eIg6NX3dnjWgOO0in5mrqWEM=; b=hgvLDe8o84wycdRqbT4elsMOLLv5Nj+tToWatdTGPtEfk3tB6tAEJ4/fZguBMezgbN dbqV4+VPqwiicuJiSYyVRZhhBKx7nRJddeGYvNCU9EBSoL9ozsgZaMBUi3QavCH2G6Cd XEzkMDhJu/TlnWB348vYuWY2JBipT+uTL+kr2irwmJEYk8rHOPt21dKhH7TtBi015J3X VDSY/Gnx/KGbukcjRbWAXIswiS1SMWYFfRP+BUcqxh6AwYW1j9cI+rKYKzdFs8kgpthC lWwORZ/i0fmilzFedYmZS25abge3RarSUjLe6TL8QpBC/lVnAkywSnZdjSxwa5u89dAE G50g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=byFux0+Ow59+RJi7Fc2eIg6NX3dnjWgOO0in5mrqWEM=; b=UqVh4b2znoEgJDmHOm/zupEam9bXDxNNVOJsQVoPFeaYcFxmu8csi9UrQ5mvpQCN49 m9eWFVYvQjCQl06EjZdyxMtrQciANuY3iJbJQwtUocAsK7sOl4gpsDYdbvEDo/tm02d5 FbxcT7p6TeoCrVCHtVWwlvg+wqGpNl7ugDHn5bMz8Gaj0U05w620IX/1Mb027Q3yBh3t Ngi6btOMKu8hkabv/sWMYk1ui+0y/eZP84R6iv/ASFpbuWnUGNlXoNFu6yh5f8DsNm82 PYj1fFRC5bq3toupEok77RrO3MKJDCB/wMJx/hP/h5LZDNLoVnflxvP8GsMeUz8YInfS XeGw== X-Gm-Message-State: AEkooutt9EsMSywGo2VpmJhhiH9xiRnFctWqQiWnsDJSu1PlD5bzfGGv/cmv5dXYlmqcxCCrud5UurcKBN7W3g== X-Received: by 10.129.103.65 with SMTP id b62mr50064654ywc.194.1470061814358; Mon, 01 Aug 2016 07:30:14 -0700 (PDT) MIME-Version: 1.0 Sender: markh.sj@gmail.com Received: by 10.129.92.66 with HTTP; Mon, 1 Aug 2016 07:30:13 -0700 (PDT) In-Reply-To: <578E3BD0.3090106@xiph.org> References: <578E3BD0.3090106@xiph.org> From: Mark Harris Date: Mon, 1 Aug 2016 07:30:13 -0700 X-Google-Sender-Auth: -ZEqsqucSke4Qaynzy7EaSOaBmc Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] Confirming consensus to adopt draft-lhomme-cellar-ebml-00 as a WG item X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:30:23 -0000 On Tue, Jul 19, 2016 at 7:40 AM, Timothy B. Terriberry wrote: > We had strong consensus in the room to adopt this draft as a WG item to > fulfill our EBML version 1 milestone. As with all decisions made in a > meeting session, the chairs would like to confirm this consensus on the > list. > > We request that any WG members not present at the meeting indicate support > or objection to the adoption of this draft. If you were present (either in > the room, or via Jabber), it is not necessary to re-confirm your support (or > objection). > > This will be a two-week call for consensus, ending August 2nd. I support adoption of this draft as a WG item. - Mark From nobody Mon Aug 1 15:51:49 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6712DA00 for ; Mon, 1 Aug 2016 15:51:48 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 jNJXLv-OBohC for ; Mon, 1 Aug 2016 15:51:46 -0700 (PDT) Received: from p3plwbeout03-03.prod.phx3.secureserver.net (p3plsmtp03-03-2.prod.phx3.secureserver.net [72.167.218.215]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D096312D7FA for ; Mon, 1 Aug 2016 15:51:46 -0700 (PDT) Received: from localhost ([72.167.218.130]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id Ryrm1t0022pPkNY01yrm3L; Mon, 01 Aug 2016 15:51:46 -0700 X-SID: Ryrm1t0022pPkNY01 Received: (qmail 19986 invoked by uid 99); 1 Aug 2016 22:51:46 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.4.2 Message-Id: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> From: "Doug Ewell" To: cellar@ietf.org Date: Mon, 01 Aug 2016 15:51:44 -0700 Mime-Version: 1.0 Archived-At: Subject: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:51:48 -0000 Hi Matroskans,=0A=0AI'm from the BCP 47 (RFC 5646) language tagging world. = I wrote RFC 4645=0Aand 5645 to establish the original and rebooted Language= Subtag=0ARegistry, and I'm an IANA Co-Designated Expert helping to maintai= n the=0ARegistry on a regular basis.=0A=0AI noticed that draft-lhomme-cella= r-ebml and draft-lhomme-cellar-matroska=0Adefine EBML Schema Element Attrib= utes in the same way, using BCP 47=0A(though citing it as RFC 5646, and wit= hout including it as a reference):=0A=0A> The "" sub-element= may use a "lang"=0A> attribute which may be set to the RFC 5646 value of t= he language of=0A> the element's documentation.=0A=0ABut draft-lhomme-cella= r-matroska defines "Language Codes" differently=0A(copied from the spec at = matroska.org):=0A=0A> Language codes can be either the 3 letters bibliograp= hic ISO-639-2=0A> [13] form (like "fre" for french), or such a language cod= e followed=0A> by a dash and a country code for specialities in languages (= like=0A> "fre-ca" for Canadian French). Country codes are the same as used= =0A> for internet domains [14].=0A=0AThis deviates from BCP 47 both in requ= iring the 3-letter language code=0Afor all languages (BCP 47 uses the ISO 6= 39-1 2-letter code when=0Aavailable), but also by coding the United Kingdom= as "UK" instead of the=0AISO 3166 standard "GB".=0A=0AIt also precludes th= e other advantages of BCP 47, such as the option to=0Ause variant and scrip= t subtags. Without this, for example, there's no=0Areliable way to distingu= ish "Serbian written in Latin script" from=0A"Serbian written in Cyrillic s= cript."=0A=0AIs there any compelling reason why Matroska should use a diffe= rent=0Acoding standard from EBML? I realize the Matroska format predates th= is=0Astandardization effort, but if it is now being proposed as an IETF=0AS= tandards Track document, it might make sense for it to support this=0ABCP. = At the very least, it could be supported as an alternative, so that=0A"fr-C= A" would be considered equivalent to "fre-ca".=0A=0AThanks,=0A=0A=0A--=0ADo= ug Ewell | Thornton, CO, US | ewellic.org From nobody Mon Aug 1 17:13:05 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13112D5FD for ; Mon, 1 Aug 2016 17:13:03 -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 CO1Ddcsh9mBR for ; Mon, 1 Aug 2016 17:13:02 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6096712D0E9 for ; Mon, 1 Aug 2016 17:13:02 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:40058 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bUNKN-003oKF-OE; Mon, 01 Aug 2016 20:13:01 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Mon, 1 Aug 2016 20:12:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2E8C6D93-FEEE-40DD-A6C9-E699D0AF3628@dericed.com> References: To: Steve Lhomme X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Nesting elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:13:04 -0000 > On Jul 31, 2016, at 11:44 AM, Steve Lhomme = wrote: >=20 > Although the EBML specs define Void as level 0+ and CRC32 and level 1+ > I could not find anywhere in the document how this + sign should be > interepreted. Hmmm, according to = https://github.com/Matroska-Org/ebml-specification/blame/master/specificat= ion.markdown#L226 "Note that Elements defined as `global` and `recursive` MAY occur at a = level greater than or equal to the defined `level`.=E2=80=9D So perhaps the `+` symbols are not needed at all, since both Void and = CRC-32 are noted as global. > I think it should become an element like default, recursive, etc. Also > like the Range and Default values, when not set (no nesting) it should > not be written. That won't make the specifications a lot more verbose. >=20 > Related github issue: > https://github.com/Matroska-Org/ebml-specification/issues/82 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Mon Aug 1 17:18:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178BE12B01D for ; Mon, 1 Aug 2016 17:18:30 -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 XrlNQe8B4tPT for ; Mon, 1 Aug 2016 17:18:29 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038C2128E19 for ; Mon, 1 Aug 2016 17:18:29 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:39756 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bUNPe-003tY3-HC; Mon, 01 Aug 2016 20:18:28 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: <8c8cd858-0546-3b6c-d236-dc7c6149518d@gmx.ch> Date: Mon, 1 Aug 2016 20:18:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8c8cd858-0546-3b6c-d236-dc7c6149518d@gmx.ch> To: hubblec4 X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:18:30 -0000 > On Aug 1, 2016, at 3:50 AM, hubblec4 wrote: >=20 >=20 >=20 > Am 31.07.2016 um 18:45 schrieb Reto Kromer: >> Steve Lhomme wrote: >>=20 >>> As we're moving towards splitting the Matroska specs in >>> many smaller documents, >> I personally would prefer to have one document containing >> the full specification of Matroska. >>=20 >> Best regards, Reto >>=20 >=20 > I would prefer to have one document too. > The old-style looks for me very well, more then better as many other = spec-documents. > And the new style by Dave is much more comfortable to navigate. I could support splitting the specification into separate documents in a = few instances. For instance I think the Matroska tags and their = definitions could be moved into a separate document. So the main = document would cover the structure of the tagging elements, but a = separate document could cover the metadata values that could be used = within it. I think this would be helpful as the metadata values and = definitions could be versioned separately without needing the version = the underlying Matroska specification. In cases like codec mappings and dvd menus and features, I think I = prefer this all in one Matroska specification. I=E2=80=99d like to = prevent what=E2=80=99s occurred with MXF where dozens of documents are = needed to understand the entirely of the file format and it=E2=80=99s = challenging to even comprehend if you have all those necessary documents = or not. Dave= From nobody Mon Aug 1 17:50:36 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F274812D0AD for ; Mon, 1 Aug 2016 17:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STYhaQSne6k6 for ; Mon, 1 Aug 2016 17:50:33 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F83412B03B for ; Mon, 1 Aug 2016 17:50:33 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:40280 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bUNug-004Nvh-5b; Mon, 01 Aug 2016 20:50:33 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_136303BA-A722-4741-9535-AA3C915ADF55" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Mon, 1 Aug 2016 20:50:28 -0400 Message-Id: References: To: Steve Lhomme X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:50:35 -0000 --Apple-Mail=_136303BA-A722-4741-9535-AA3C915ADF55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2016, at 11:41 AM, Steve Lhomme = wrote: >=20 > As we're moving towards splitting the Matroska specs in many smaller > documents, putting not essential things in a document it becomes more > important to define things differently than the "level" element we > currently rely on. It makes it very difficult to define a single > element without having to copy all its parents to explain where it > should go in the EBML format. >=20 > I think we should set the name of the parent(s) explicitely to avoid > that confusion. We will also not rely anymore on the order in which > elements are defined in the specs. >=20 > I did a pull request with this addition: > https://github.com/Matroska-Org/ebml-specification/pull/83 >=20 > This change will probably mean many paragraphs need to be rewritten to > rely less on the level system. >=20 > I will do the pull request for Matroska as well once it's settled. Sorry to join this conversation late. I think the current state of the = EBML implies two different ways of documenting nesting. The EBML Schema = example simply nests the within one another. For example = : The nesting of the EBML Schema implies that FileName occurs within File = and File occurs within Files. The use of the =E2=80=98level=E2=80=99 = attribute is redundant to the structure. However, later we list out the elements of the EBML Header in a series = of tables = . The tables don=E2=80=99t imply the = nested structure as the xml does, so the level attribute here is needed, = though it is certainly a bit unclear since determining the parent = requiring reading backwards to the last master element of a higher = value. I prefer to keep the XML analogy where elements are defined in an XML = schema where the arrangement of the elements within one another defines = the nesting structure. Then since we can compile our documentation the = =E2=80=9CParent=E2=80=9D values can be decipher from the XML-based EBML = Schema. However this gets to a conversation at the CELLAR working group = meeting on whether XML should be considered normative or not. So I think I would prefer not to have a =E2=80=98parent=E2=80=99 = attribute but to allow that to be implied by the nesting of elements = within an EBML Schema. Then the parent data could be presented for users = when we compile documentation from the EBML Schema. For instance this = markdown is build from the EBML Schema and lists parent values derived = from the structure of the EBML Schema. = https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 Dave Rice --Apple-Mail=_136303BA-A722-4741-9535-AA3C915ADF55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 31, 2016, at = 11:41 AM, Steve Lhomme <slhomme@matroska.org> wrote:

As we're moving towards splitting the Matroska specs in many = smaller
documents, putting not essential things in a = document it becomes more
important to define things = differently than the "level" element we
currently rely on. = It makes it very difficult to define a single
element = without having to copy all its parents to explain where it
should go in the EBML format.

I = think we should set the name of the parent(s) explicitely to avoid
that confusion. We will also not rely anymore on the order in = which
elements are defined in the specs.

I did a pull request with this addition:
https://github.com/Matroska-Org/ebml-specification/pull/83<= br class=3D"">
This change will probably mean many = paragraphs need to be rewritten to
rely less on the level = system.

I will do the pull request for = Matroska as well once it's settled.

Sorry to join this conversation late. I think = the current state of the EBML implies two different ways of documenting = nesting. The EBML Schema example simply nests the <elements> = within one another. For example:

<element name=3D"Files" level=3D"0" id=3D"0x1= 946696C" type=3D"master">
    = <element name=3D"File" level=3D"1" id=3D"0x6146" ty= pe=3D"master" minOccurs=3D=E2=80=9C1" = maxOccurs=3D=E2=80=9Cunbounded">
    =     = <element name=3D"FileName" level=3D"2" id=3D"0x614E"&nbs= p;type=3D"utf-8=E2=80=9D minOccurs=3D=E2=80=9C1=E2=80=9D/>
<= div class=3D"">   </element>
</element>

The nesting of the EBML Schema implies that FileName occurs = within File and File occurs within Files. The use of the =E2=80=98level=E2= =80=99 attribute is redundant to the structure.

However, later we list out the elements = of the EBML Header in a series of = tables. The tables don=E2=80=99t imply the nested structure as the = xml does, so the level attribute here is needed, though it is certainly = a bit unclear since determining the parent requiring reading backwards = to the last master element of a higher value.

I prefer to keep the XML analogy where = elements are defined in an XML schema where the arrangement of the = elements within one another defines the nesting structure. Then since we = can compile our documentation the =E2=80=9CParent=E2=80=9D values can be = decipher from the XML-based EBML Schema. However this gets to a = conversation at the CELLAR working group meeting on whether XML should = be considered normative or not.

So I think I would prefer not to have a = =E2=80=98parent=E2=80=99 attribute but to allow that to be implied by = the nesting of elements within an EBML Schema. Then the parent data = could be presented for users when we compile documentation from the EBML = Schema. For instance this markdown is build from the EBML Schema and = lists parent values derived from the structure of the EBML = Schema. https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f78= 8

Dave = Rice

= --Apple-Mail=_136303BA-A722-4741-9535-AA3C915ADF55-- From nobody Mon Aug 1 17:58:57 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E860012B03B for ; Mon, 1 Aug 2016 17:58:54 -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 xYO-0fQ2sssq for ; Mon, 1 Aug 2016 17:58:52 -0700 (PDT) Received: from 2.mo53.mail-out.ovh.net (2.mo53.mail-out.ovh.net [178.33.254.39]) (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 A8D1012B024 for ; Mon, 1 Aug 2016 17:58:52 -0700 (PDT) Received: from player159.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo53.mail-out.ovh.net (Postfix) with ESMTP id 8895043CCF for ; Tue, 2 Aug 2016 02:58:50 +0200 (CEST) Received: from [192.168.11.23] (i125-201-111-186.s41.a026.ap.plala.or.jp [125.201.111.186]) (Authenticated sender: zen@mediaarea.net) by player159.ha.ovh.net (Postfix) with ESMTPSA id BCFA9480086 for ; Tue, 2 Aug 2016 02:58:49 +0200 (CEST) To: cellar@ietf.org References: <8c8cd858-0546-3b6c-d236-dc7c6149518d@gmx.ch> From: Jerome Martinez Message-ID: <82a3daa3-6df6-72a8-24c0-259d4172a623@mediaarea.net> Date: Tue, 2 Aug 2016 09:58:47 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 17314651721277837457 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeltddrjeeigdeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:58:55 -0000 On 02/08/2016 09:18, Dave Rice wrote: > I could support splitting the specification into separate documents in > a few instances. For instance I think the Matroska tags and their > definitions could be moved into a separate document. So the main > document would cover the structure of the tagging elements, but a > separate document could cover the metadata values that could be used > within it. I think this would be helpful as the metadata values and > definitions could be versioned separately without needing the version > the underlying Matroska specification. +1 > In cases like codec mappings and dvd menus and features, I think I prefer this all in one Matroska specification. I’d like to prevent what’s occurred with MXF where dozens of documents are needed to understand the entirely of the file format and it’s challenging to even comprehend if you have all those necessary documents or not. your argument for split of tags definition ("without needing the version the underlying Matroska specification") also applies here. IETF uses to do the same kind of split as SMTE for MXF (Check Opus: one RFC for Opus in RTP, so RTP has 1 RFC per new codec, one RFC for Opus in OGG...), actually because missing such changes in a unique spec create too many revisions for something not core. it is not easy to decide where to put codec specs (e.g. Opus has a separate RFC, FFV1 includes it in its specs...) but I don't think that having it in an unique spec is good we don't see the important changes in core spec with it. I propose that we have split specs, but not one per format, one RFC for all codecs in Matroska may be enough (+1 for DVD menu, very specific and potentially complex/unstable item) From nobody Tue Aug 2 05:27:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624D412D58A for ; Tue, 2 Aug 2016 05:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 hqOrlrMz70lv for ; Tue, 2 Aug 2016 05:27:30 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FFF12D57B for ; Tue, 2 Aug 2016 05:27:28 -0700 (PDT) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 0DB87825B2 for ; Tue, 2 Aug 2016 14:27:26 +0200 (CEST) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix ; Tue, 2 Aug 2016 14:27:56 +0200 To: cellar@ietf.org References: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <7a66fb5c-bea9-60fa-5f6b-e39ef3daebbb@noa-archive.com> Date: Tue, 2 Aug 2016 14:27:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20160802122726.17406.78856@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 12:27:32 -0000 On 02.08.2016 00:51, Doug Ewell wrote: > Hi Matroskans, > > I'm from the BCP 47 (RFC 5646) language tagging world. I wrote RFC 4645 > and 5645 to establish the original and rebooted Language Subtag > Registry, and I'm an IANA Co-Designated Expert helping to maintain the > Registry on a regular basis. > > I noticed that draft-lhomme-cellar-ebml and draft-lhomme-cellar-matroska > define EBML Schema Element Attributes in the same way, using BCP 47 > (though citing it as RFC 5646, and without including it as a reference): > >> The "" sub-element may use a "lang" >> attribute which may be set to the RFC 5646 value of the language of >> the element's documentation. > > But draft-lhomme-cellar-matroska defines "Language Codes" differently > (copied from the spec at matroska.org): > >> Language codes can be either the 3 letters bibliographic ISO-639-2 >> [13] form (like "fre" for french), or such a language code followed >> by a dash and a country code for specialities in languages (like >> "fre-ca" for Canadian French). Country codes are the same as used >> for internet domains [14]. > > This deviates from BCP 47 both in requiring the 3-letter language code > for all languages (BCP 47 uses the ISO 639-1 2-letter code when > available), but also by coding the United Kingdom as "UK" instead of the > ISO 3166 standard "GB". > > It also precludes the other advantages of BCP 47, such as the option to > use variant and script subtags. Without this, for example, there's no > reliable way to distinguish "Serbian written in Latin script" from > "Serbian written in Cyrillic script." +1 In our archive system we recommend to use RFC 5646 language tags possibly including private subtags for stream identification (see p.24 in [1]). It would be great to map that into Matroska language codes. On the other hand I must confess that most of our current users do not use that feature and just name streams by index "1", "2", ... > Is there any compelling reason why Matroska should use a different > coding standard from EBML? I realize the Matroska format predates this > standardization effort, but if it is now being proposed as an IETF > Standards Track document, it might make sense for it to support this > BCP. At the very least, it could be supported as an alternative, so that > "fr-CA" would be considered equivalent to "fre-ca". Regards, Tobias Links: [1] https://github.com/preforma/notimetowait/raw/master/presentations/ContainerFormatRole.pdf -- NOA GmbH Tel: +43-1-5452700 Johannagasse 42/4 Fax: +43-1-545270014 A - 1050 Wien Www: http://www.noa-archive.com From nobody Tue Aug 2 05:36:15 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F3E12D58E for ; Tue, 2 Aug 2016 05:36:13 -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_H4=-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 nN7lrjnVZcAD for ; Tue, 2 Aug 2016 05:36:11 -0700 (PDT) Received: from mo68.mail-out.ovh.net (mo68.mail-out.ovh.net [178.32.228.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD7012D581 for ; Tue, 2 Aug 2016 05:36:10 -0700 (PDT) Received: from player797.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 96B5AFF863E for ; Tue, 2 Aug 2016 14:36:08 +0200 (CEST) Received: from [192.168.179.5] (KD106154065185.au-net.ne.jp [106.154.65.185]) (Authenticated sender: zen@mediaarea.net) by player797.ha.ovh.net (Postfix) with ESMTPSA id A0C652E0084 for ; Tue, 2 Aug 2016 14:36:07 +0200 (CEST) To: cellar@ietf.org References: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> From: Jerome Martinez Message-ID: <5ac7ce75-6373-2d45-233f-754dc4d4202c@mediaarea.net> Date: Tue, 2 Aug 2016 21:36:02 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 10644257720626843793 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeltddrjeekgddvlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 12:36:13 -0000 There was a discussion about RFC 5646 and the issue due to legacy: https://www.ietf.org/mail-archive/web/cellar/current/msg00155.html It my be good to review the thread and maybe we can have solutions we did not think about at this moment. Jérôme On 02/08/2016 07:51, Doug Ewell wrote: > Hi Matroskans, > > I'm from the BCP 47 (RFC 5646) language tagging world. I wrote RFC 4645 > and 5645 to establish the original and rebooted Language Subtag > Registry, and I'm an IANA Co-Designated Expert helping to maintain the > Registry on a regular basis. > > I noticed that draft-lhomme-cellar-ebml and draft-lhomme-cellar-matroska > define EBML Schema Element Attributes in the same way, using BCP 47 > (though citing it as RFC 5646, and without including it as a reference): > >> The "" sub-element may use a "lang" >> attribute which may be set to the RFC 5646 value of the language of >> the element's documentation. > But draft-lhomme-cellar-matroska defines "Language Codes" differently > (copied from the spec at matroska.org): > >> Language codes can be either the 3 letters bibliographic ISO-639-2 >> [13] form (like "fre" for french), or such a language code followed >> by a dash and a country code for specialities in languages (like >> "fre-ca" for Canadian French). Country codes are the same as used >> for internet domains [14]. > This deviates from BCP 47 both in requiring the 3-letter language code > for all languages (BCP 47 uses the ISO 639-1 2-letter code when > available), but also by coding the United Kingdom as "UK" instead of the > ISO 3166 standard "GB". > > It also precludes the other advantages of BCP 47, such as the option to > use variant and script subtags. Without this, for example, there's no > reliable way to distinguish "Serbian written in Latin script" from > "Serbian written in Cyrillic script." > > Is there any compelling reason why Matroska should use a different > coding standard from EBML? I realize the Matroska format predates this > standardization effort, but if it is now being proposed as an IETF > Standards Track document, it might make sense for it to support this > BCP. At the very least, it could be supported as an alternative, so that > "fr-CA" would be considered equivalent to "fre-ca". > > Thanks, > > > -- > Doug Ewell | Thornton, CO, US | ewellic.org > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Aug 2 05:37:54 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18E212D591 for ; Tue, 2 Aug 2016 05:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 qdyW6FiMP-sN for ; Tue, 2 Aug 2016 05:37:51 -0700 (PDT) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 9434F12D580 for ; Tue, 2 Aug 2016 05:37:51 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 68A3E442E370; Tue, 2 Aug 2016 14:37:49 +0200 (CEST) Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id EC2B2442E359 for ; Tue, 2 Aug 2016 14:37:45 +0200 (CEST) Received: by sweet-chili.local (Postfix, from userid 1000) id 647227E4B4E; Tue, 2 Aug 2016 14:37:45 +0200 (CEST) Date: Tue, 2 Aug 2016 14:37:45 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160802123745.jnlely4uzkee7tnc@bunkus.org> References: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160801155144.665a7a7059d7ee80bb4d670165c8327d.b1d111f6c3.wbe@email03.godaddy.com> User-Agent: Mutt/1.6.1-neo (2016-05-23) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 12:37:53 -0000 Hey, we've had such a discussion back in January[1]. I think the consensus was to add new elements that take RFC 5646 as content. Those new elements would have precedence over existing language elements if both are present. Kind regards, mosu [1] https://mailarchive.ietf.org/arch/msg/cellar/y4sttOAb0V87IC5LY1Yn6jpZO5g From nobody Tue Aug 2 10:56:27 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1A112D849 for ; Tue, 2 Aug 2016 10:56:27 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 aDpXuNYZTqbB for ; Tue, 2 Aug 2016 10:56:25 -0700 (PDT) Received: from p3plwbeout03-05.prod.phx3.secureserver.net (p3plsmtp03-05-2.prod.phx3.secureserver.net [72.167.218.217]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A516712D18B for ; Tue, 2 Aug 2016 10:56:25 -0700 (PDT) Received: from localhost ([72.167.218.135]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id SHwR1t0012vs63s01HwRRh; Tue, 02 Aug 2016 10:56:25 -0700 X-SID: SHwR1t0012vs63s01 Received: (qmail 24139 invoked by uid 99); 2 Aug 2016 17:56:25 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 208.51.143.189 User-Agent: Workspace Webmail 6.4.2 Message-Id: <20160802105623.665a7a7059d7ee80bb4d670165c8327d.3e3d408fe7.wbe@email03.godaddy.com> From: "Doug Ewell" To: cellar@ietf.org Date: Tue, 02 Aug 2016 10:56:23 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Cellar] Language codes in Matroska and EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 17:56:27 -0000 Thanks to J=C3=A9r=C3=B4me and Moritz for pointing to the January discussio= n=0Aabout language coding.=0A=0AIt looks like the discussion originally foc= used on expanding the=0Aexisting data element in Matroska to incorporate IS= O 639-3. Later=0Adiscussion was on truly adopting BCP 47, and maintaining c= ompatibility=0Awith existing Matroska implementations by creating a new, BC= P=0A47-compliant language element that would take precedence over the=0Aexi= sting one. This seems sensible and would allow data producers to=0Amigrate = to the BCP 47 approach over time.=0A=0AAn important detail about BCP 47 is = that compliant applications use the=0AIANA Language Subtag Registry [1] as = their canonical source for language=0Asubtags (codes) and other subtags, an= d NOT the ISO standards directly.=0AThe Registry is maintained carefully th= rough IANA to be compatible with=0Athe ISO standards, except when doing so = would cause conflicts or=0Aincompatibility.=0A=0AFor example, the chaos tha= t ensued in 2003 when ISO 3166/MA reassigned=0Athe retired code element [CS= ] to mean "Serbia and Montenegro," when=0Anumerous applications were still = using it to mean "Czechoslovakia,"=0Awould have caused very little trouble = if BCP 47 had existed, because a=0Anumeric replacement code would have been= chosen for Serbia and=0AMontenegro to resolve the conflict.=0A=0ASo it's i= mportant to steer clear of statements like "RFC 5646 recommends=0Ato use IS= O 639 when it is possible" and "RFC 5646 recommends 2-letter=0Acodes when 3= -letters codes are not necessary," because what RFC 5646=0Aactually says is= to use the subtags that are in the Registry.=0A=0AAnother important point = is that parsing a BCP 47 tag to remove all but=0Athe primary language subta= g is dead simple: just stop right before the=0Afirst hyphen, if any. So "sr= -Latin-ME" becomes "sr". There is no need to=0Aworry about whether the prim= ary language subtag is 2 or 3 letters long.=0AThe only exceptions are for t= he grandfathered tags "i-default" and=0A"i-mingo" and for private-use tags = starting with "x-", all of which are=0Aunlikely to occur in multimedia data= . There are well-defined matching=0Amechanisms for more complex scenarios; = see RFC 4647.=0A=0ABCP 47 (sometimes as "RFC 5646" or its predecessors) is = referenced=0Anormatively in more than 60 RFCs, and informatively in another= 20, plus=0Anumerous drafts. So there is no question that it is widely supp= orted!=0A=0APlease feel free to contact the ietf-languages mailing list [2]= with any=0Aquestions concerning BCP 47.=0A=0A[1] http://www.iana.com/assig= nments/language-subtag-registry=0A[2] http://www.alvestrand.no/mailman/list= info/ietf-languages=0A=0A=0A--=0ADoug Ewell | Thornton, CO, US | ewellic.or= g From nobody Fri Aug 5 08:09:48 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C131412D871 for ; Fri, 5 Aug 2016 08:09:46 -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] 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 GWnpMRtjkYoP for ; Fri, 5 Aug 2016 08:09:44 -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 D32DD12D105 for ; Fri, 5 Aug 2016 08:09:44 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id x196so15669484ybe.1 for ; Fri, 05 Aug 2016 08:09:44 -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:content-transfer-encoding; bh=dgNYaLgb7dacCsaUiJF2heMEsLi9YQXbWestupM9Uro=; b=aIVqCl+ARr8Vq6gNwFRaRYmqvLk/fPK127A5Jostt6ZlEkHJq33P7t7gIJUPcF74K2 m85BfwkqHOZKu98EK69pZJ8I8iBgYimYt0YJpYuNwwgFJARw5mu78nMvesW2VHYst79o MSocy0IID4DuiyrRb7GrWlxCtkfmzwIyHDuhZ2rL2FVK0Sm0Qq/bovHEIhWxi7UCOOwN xYO+eQcSK0oHaOvzg+CBwkmOa1UBv2YXmVsvbfTX3+/yqT8uc6NtVorlDYOEcINDwocv rp/EFdPdi5yk+fGvsZNHCgR1P1jilRxmsdhN+wqvPWU1XCGCmzzxTRIk+dOWyaxXN6Xw qMRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dgNYaLgb7dacCsaUiJF2heMEsLi9YQXbWestupM9Uro=; b=JkoNoTxw200+QDGoTmjgEWmugL6FhO9nPinhODeUznKGo8V3EVibR0nFxTxelWHFH2 paNfOzusX+bmseuK0MDyyGo0DpHW2Q44onOzIvV2DlaE1uM+VxNqofeGsNAFoTxAMMyA F+IofUyAqF0DbZusGcqvwchMelfR5A+QPxv6piXwzGdokaHmdexNWWxRwdwCigtVSveo tHqZVjGK3UX9iqS1dNV7tMSQdOigoqQscxXRFGAZhtqBsVS9HRmx21HHjVLv2rkZy36Z tqpaow/9oOMi0LAAFL5To/lrpwTncqj1PPdgcnBhCHjawzmeKdj274fDC6BInm6hyw1n OGzA== X-Gm-Message-State: AEkoouvnfb/5reEXz+fXfZaGCrQ9arNG8zoY7ohPqEjDUODsMkdrmAlWmzBF2JbzyMKT2V5EYyCDN9X4pALh6Q== X-Received: by 10.37.68.68 with SMTP id r65mr57964042yba.177.1470409783939; Fri, 05 Aug 2016 08:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Fri, 5 Aug 2016 08:09:43 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Fri, 5 Aug 2016 17:09:43 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:09:47 -0000 2016-08-02 2:50 GMT+02:00 Dave Rice : > > On Jul 31, 2016, at 11:41 AM, Steve Lhomme wrote: > > As we're moving towards splitting the Matroska specs in many smaller > documents, putting not essential things in a document it becomes more > important to define things differently than the "level" element we > currently rely on. It makes it very difficult to define a single > element without having to copy all its parents to explain where it > should go in the EBML format. > > I think we should set the name of the parent(s) explicitely to avoid > that confusion. We will also not rely anymore on the order in which > elements are defined in the specs. > > I did a pull request with this addition: > https://github.com/Matroska-Org/ebml-specification/pull/83 > > This change will probably mean many paragraphs need to be rewritten to > rely less on the level system. > > I will do the pull request for Matroska as well once it's settled. > > > Sorry to join this conversation late. I think the current state of the EB= ML > implies two different ways of documenting nesting. The EBML Schema exampl= e > simply nests the within one another. For example: > > > maxOccurs=3D=E2=80=9Cunbounded"> > minOccurs=3D=E2=80=9C1=E2=80=9D/> > > > > The nesting of the EBML Schema implies that FileName occurs within File a= nd > File occurs within Files. The use of the =E2=80=98level=E2=80=99 attribut= e is redundant to > the structure. Yes it's redundant and should probably be removed. It only creates possible issues and gives no extra information. Except when it's 1+ which doesn't have any equivalent in XML and is currently not defined. > However, later we list out the elements of the EBML Header in a series of > tables. The tables don=E2=80=99t imply the nested structure as the xml do= es, so the > level attribute here is needed, though it is certainly a bit unclear sinc= e > determining the parent requiring reading backwards to the last master > element of a higher value. > > I prefer to keep the XML analogy where elements are defined in an XML sch= ema > where the arrangement of the elements within one another defines the nest= ing > structure. Then since we can compile our documentation the =E2=80=9CParen= t=E2=80=9D values > can be decipher from the XML-based EBML Schema. However this gets to a > conversation at the CELLAR working group meeting on whether XML should be > considered normative or not. While I support having an up to date machine readable version of the specs. I don't think it should/will be the actual reference for the specifications. Also the XML parent analogy only works if there's a fixed parent and the element can only be found at that level. How do you define an element that can be found anywhere under /File/Attribute/* (to use the path system) (or elements similar to Void and CRC32 which can be defined for a certain DocType) ? Either we add an attibute in the XML element or we define how level with a + should be interpreted. Since it's extra information it's probably better to put it out of the level (which should go from the XML anyway). How would you define an element that be put anywhere within a DocType in the XML format ? I agree that it would be odd to have a "parent" attribute in a non flat XML file. It's also odd to have a "parent" on a flat XML file. > So I think I would prefer not to have a =E2=80=98parent=E2=80=99 attribut= e but to allow that > to be implied by the nesting of elements within an EBML Schema. Then the > parent data could be presented for users when we compile documentation fr= om > the EBML Schema. For instance this markdown is build from the EBML Schema > and lists parent values derived from the structure of the EBML Schema. > https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 > > Dave Rice > --=20 Steve Lhomme Matroska association Chairman From nobody Fri Aug 5 08:13:20 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF9E12D544 for ; Fri, 5 Aug 2016 08:13:18 -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] 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 Um_bF2IqsD_k for ; Fri, 5 Aug 2016 08:13:16 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::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 AE52A12D105 for ; Fri, 5 Aug 2016 08:13:14 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e125so15698103ybc.0 for ; Fri, 05 Aug 2016 08:13:14 -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 :content-transfer-encoding; bh=ovhWAZ+qSUanBxGw0KstGD/QykJ0e9dPpfNQssgLWyg=; b=bpVclp2ozJVWnC16vBVBCJmU7epi7OC+wWM0NDxQ3EOny99nBnfMjUmH9srOLU4YoR GsjcU/B8PB74iSnSpwl0HJo9IxTg9cBYfsdilnjmuB59jT45RWXLM0kPLTGI0eYvQIog lOy4K8sUtllJ7XMxeKPZNP2aix22UxbwuJ8Wtfcl36bFDlRtpoG9lWHcJsm5220LK+iF LvoVPN7GE2AegEUgrTiwBSFxtYm4S2MiDAClhkY4fhxSNi3+8cPbLGRRowhq1ZrCF175 2aUBCGOR2CbXPKWlDOcVhW0eU8oxn2G364xRoxgBdqcrNXBkC2+pQiy2GgudV9PmA4od FJaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=ovhWAZ+qSUanBxGw0KstGD/QykJ0e9dPpfNQssgLWyg=; b=WURDmz8tk2aUHfZ0b5MF5WQzhwqxD5fEn1oIwor80lTByYhCRsDYutc/ptkeLvcbRW dk0pFs4wCktBSF3avOSKgKh0eCuYYkbgmIFcMEP2XzEpjuMQ1Y0fT7soxo2V0pHQvBkZ FKOZA5qnmO25Z+PVKA0ToDk7Vd4f42mi1bHaenL6Z5jcp0SIxjio5onP7Na+fo0u9NVz 2TK54smZD3yRA3bXzO7hxLBcwfx5SHmvWbPKVFfyQ3mlDUa1T5k6WI50yq9s3WA5Hz7p zgMpnSTPTUSLglNVxp4vmDiam4UFsn2Xp4wBJ+1TX/E2GJXfh13jI922MDs6gVyFKwy5 Z+gA== X-Gm-Message-State: AEkoout+RYNODw0/CiGlYog5AL7i0CuDy5bhvjCofWhcFhDatk+4pU5Ve8fGXFb2xgHjIVKjfX5fY+U5AoTViA== X-Received: by 10.37.101.5 with SMTP id z5mr60044621ybb.65.1470409993800; Fri, 05 Aug 2016 08:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Fri, 5 Aug 2016 08:13:13 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Fri, 5 Aug 2016 17:13:13 +0200 Message-ID: To: cellar@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:13:18 -0000 2016-08-05 17:09 GMT+02:00 Steve Lhomme : > 2016-08-02 2:50 GMT+02:00 Dave Rice : >> >> On Jul 31, 2016, at 11:41 AM, Steve Lhomme wrote: >> >> As we're moving towards splitting the Matroska specs in many smaller >> documents, putting not essential things in a document it becomes more >> important to define things differently than the "level" element we >> currently rely on. It makes it very difficult to define a single >> element without having to copy all its parents to explain where it >> should go in the EBML format. >> >> I think we should set the name of the parent(s) explicitely to avoid >> that confusion. We will also not rely anymore on the order in which >> elements are defined in the specs. >> >> I did a pull request with this addition: >> https://github.com/Matroska-Org/ebml-specification/pull/83 >> >> This change will probably mean many paragraphs need to be rewritten to >> rely less on the level system. >> >> I will do the pull request for Matroska as well once it's settled. >> >> >> Sorry to join this conversation late. I think the current state of the E= BML >> implies two different ways of documenting nesting. The EBML Schema examp= le >> simply nests the within one another. For example: >> >> >> > maxOccurs=3D=E2=80=9Cunbounded"> >> > minOccurs=3D=E2=80=9C1=E2=80=9D/> >> >> >> >> The nesting of the EBML Schema implies that FileName occurs within File = and >> File occurs within Files. The use of the =E2=80=98level=E2=80=99 attribu= te is redundant to >> the structure. > > Yes it's redundant and should probably be removed. It only creates > possible issues and gives no extra information. Except when it's 1+ > which doesn't have any equivalent in XML and is currently not defined. > >> However, later we list out the elements of the EBML Header in a series o= f >> tables. The tables don=E2=80=99t imply the nested structure as the xml d= oes, so the >> level attribute here is needed, though it is certainly a bit unclear sin= ce >> determining the parent requiring reading backwards to the last master >> element of a higher value. >> >> I prefer to keep the XML analogy where elements are defined in an XML sc= hema >> where the arrangement of the elements within one another defines the nes= ting >> structure. Then since we can compile our documentation the =E2=80=9CPare= nt=E2=80=9D values >> can be decipher from the XML-based EBML Schema. However this gets to a >> conversation at the CELLAR working group meeting on whether XML should b= e >> considered normative or not. > > While I support having an up to date machine readable version of the > specs. I don't think it should/will be the actual reference for the > specifications. > > Also the XML parent analogy only works if there's a fixed parent and > the element can only be found at that level. How do you define an > element that can be found anywhere under /File/Attribute/* (to use the > path system) (or elements similar to Void and CRC32 which can be > defined for a certain DocType) ? Either we add an attibute in the XML > element or we define how level with a + should be interpreted. Since > it's extra information it's probably better to put it out of the level > (which should go from the XML anyway). How would you define an element > that be put anywhere within a DocType in the XML format ? I agree that > it would be odd to have a "parent" attribute in a non flat XML file. > It's also odd to have a "parent" on a flat XML file. Also there's still the problem how to define a (set of) element(s) outside of the core Matroska speficications. I can't be the core specifications including an external file. It should be that external (XML) that tells where it should be inserted. Is there a common XML mechanism to inject one file into another ? Does it involve defining all the elements in the original file to define where we want the insertion ? With possible mismatch or missing updates. >> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 attribu= te but to allow that >> to be implied by the nesting of elements within an EBML Schema. Then the >> parent data could be presented for users when we compile documentation f= rom >> the EBML Schema. For instance this markdown is build from the EBML Schem= a >> and lists parent values derived from the structure of the EBML Schema. >> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >> >> Dave Rice >> > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Fri Aug 5 08:23:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54612D8B6 for ; Fri, 5 Aug 2016 08:23:56 -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 WC1EYNHp3Uo7 for ; Fri, 5 Aug 2016 08:23:54 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CB912D5CE for ; Fri, 5 Aug 2016 08:23:54 -0700 (PDT) Received: from [146.96.19.240] (port=10651 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bVgyU-000VYb-Px; Fri, 05 Aug 2016 11:23:53 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Fri, 5 Aug 2016 11:23:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <703CF364-891E-432F-AE18-7E0C5BE1647F@dericed.com> References: To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:23:57 -0000 > On Aug 5, 2016, at 11:09 AM, Steve Lhomme = wrote: >=20 > 2016-08-02 2:50 GMT+02:00 Dave Rice : >>=20 >> On Jul 31, 2016, at 11:41 AM, Steve Lhomme = wrote: >>=20 >> As we're moving towards splitting the Matroska specs in many smaller >> documents, putting not essential things in a document it becomes more >> important to define things differently than the "level" element we >> currently rely on. It makes it very difficult to define a single >> element without having to copy all its parents to explain where it >> should go in the EBML format. >>=20 >> I think we should set the name of the parent(s) explicitely to avoid >> that confusion. We will also not rely anymore on the order in which >> elements are defined in the specs. >>=20 >> I did a pull request with this addition: >> https://github.com/Matroska-Org/ebml-specification/pull/83 >>=20 >> This change will probably mean many paragraphs need to be rewritten = to >> rely less on the level system. >>=20 >> I will do the pull request for Matroska as well once it's settled. >>=20 >>=20 >> Sorry to join this conversation late. I think the current state of = the EBML >> implies two different ways of documenting nesting. The EBML Schema = example >> simply nests the within one another. For example: >>=20 >> >> > maxOccurs=3D=E2=80=9Cunbounded"> >> > minOccurs=3D=E2=80=9C1=E2=80=9D/> >> >> >>=20 >> The nesting of the EBML Schema implies that FileName occurs within = File and >> File occurs within Files. The use of the =E2=80=98level=E2=80=99 = attribute is redundant to >> the structure. >=20 > Yes it's redundant and should probably be removed. It only creates > possible issues and gives no extra information. Except when it's 1+ > which doesn't have any equivalent in XML and is currently not defined. It is possible in an XML Schema to define that an element may occur = recursively within itself. A few methods to do this are detailed at = http://lists.w3.org/Archives/Public/xmlschema-dev/2012Aug/0026.html. >> However, later we list out the elements of the EBML Header in a = series of >> tables. The tables don=E2=80=99t imply the nested structure as the = xml does, so the >> level attribute here is needed, though it is certainly a bit unclear = since >> determining the parent requiring reading backwards to the last master >> element of a higher value. >>=20 >> I prefer to keep the XML analogy where elements are defined in an XML = schema >> where the arrangement of the elements within one another defines the = nesting >> structure. Then since we can compile our documentation the = =E2=80=9CParent=E2=80=9D values >> can be decipher from the XML-based EBML Schema. However this gets to = a >> conversation at the CELLAR working group meeting on whether XML = should be >> considered normative or not. >=20 > While I support having an up to date machine readable version of the > specs. I don't think it should/will be the actual reference for the > specifications. Do you mean that a machine-readable version shouldn't be the reference = for human or shouldn't be the reference for tools such as mkvalidator. > Also the XML parent analogy only works if there's a fixed parent and > the element can only be found at that level. How do you define an > element that can be found anywhere under /File/Attribute/* (to use the > path system) (or elements similar to Void and CRC32 which can be > defined for a certain DocType) ? Good point. The current EBML Schema works around this since the only = global elements are in the EBML spec and inherited by but not defined by = Matroska. > Either we add an attibute in the XML > element or we define how level with a + should be interpreted. Another option is as it currently is where we have a recursive and = global values and if either are set to true then the level attribute = means that it may occur at that level or any greater level. > Since > it's extra information it's probably better to put it out of the level > (which should go from the XML anyway). How would you define an element > that be put anywhere within a DocType in the XML format ? I agree that > it would be odd to have a "parent" attribute in a non flat XML file. > It's also odd to have a "parent" on a flat XML file. That's something I think about to. The parent attribute fixes some = issues but if we adopt it then perhaps we should un-nest the EBML = Schema. dave >> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 = attribute but to allow that >> to be implied by the nesting of elements within an EBML Schema. Then = the >> parent data could be presented for users when we compile = documentation from >> the EBML Schema. For instance this markdown is build from the EBML = Schema >> and lists parent values derived from the structure of the EBML = Schema. >> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>=20 >> Dave Rice >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Aug 5 08:26:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4B12D635 for ; Fri, 5 Aug 2016 08:26:56 -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 8pDj_nfnAmk1 for ; Fri, 5 Aug 2016 08:26:54 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C9412D5D7 for ; Fri, 5 Aug 2016 08:26:54 -0700 (PDT) Received: from [146.96.19.240] (port=11684 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bVh1P-000YBD-H5; Fri, 05 Aug 2016 11:26:54 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Fri, 5 Aug 2016 11:26:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:26:57 -0000 > On Aug 5, 2016, at 11:13 AM, Steve Lhomme = wrote: >=20 > 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>=20 >>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme = wrote: >>>=20 >>> As we're moving towards splitting the Matroska specs in many smaller >>> documents, putting not essential things in a document it becomes = more >>> important to define things differently than the "level" element we >>> currently rely on. It makes it very difficult to define a single >>> element without having to copy all its parents to explain where it >>> should go in the EBML format. >>>=20 >>> I think we should set the name of the parent(s) explicitely to avoid >>> that confusion. We will also not rely anymore on the order in which >>> elements are defined in the specs. >>>=20 >>> I did a pull request with this addition: >>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>=20 >>> This change will probably mean many paragraphs need to be rewritten = to >>> rely less on the level system. >>>=20 >>> I will do the pull request for Matroska as well once it's settled. >>>=20 >>>=20 >>> Sorry to join this conversation late. I think the current state of = the EBML >>> implies two different ways of documenting nesting. The EBML Schema = example >>> simply nests the within one another. For example: >>>=20 >>> = >>> >> maxOccurs=3D=E2=80=9Cunbounded"> >>> >> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>> >>> >>>=20 >>> The nesting of the EBML Schema implies that FileName occurs within = File and >>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 = attribute is redundant to >>> the structure. >>=20 >> Yes it's redundant and should probably be removed. It only creates >> possible issues and gives no extra information. Except when it's 1+ >> which doesn't have any equivalent in XML and is currently not = defined. >>=20 >>> However, later we list out the elements of the EBML Header in a = series of >>> tables. The tables don=E2=80=99t imply the nested structure as the = xml does, so the >>> level attribute here is needed, though it is certainly a bit unclear = since >>> determining the parent requiring reading backwards to the last = master >>> element of a higher value. >>>=20 >>> I prefer to keep the XML analogy where elements are defined in an = XML schema >>> where the arrangement of the elements within one another defines the = nesting >>> structure. Then since we can compile our documentation the = =E2=80=9CParent=E2=80=9D values >>> can be decipher from the XML-based EBML Schema. However this gets to = a >>> conversation at the CELLAR working group meeting on whether XML = should be >>> considered normative or not. >>=20 >> While I support having an up to date machine readable version of the >> specs. I don't think it should/will be the actual reference for the >> specifications. >>=20 >> Also the XML parent analogy only works if there's a fixed parent and >> the element can only be found at that level. How do you define an >> element that can be found anywhere under /File/Attribute/* (to use = the >> path system) (or elements similar to Void and CRC32 which can be >> defined for a certain DocType) ? Either we add an attibute in the XML >> element or we define how level with a + should be interpreted. Since >> it's extra information it's probably better to put it out of the = level >> (which should go from the XML anyway). How would you define an = element >> that be put anywhere within a DocType in the XML format ? I agree = that >> it would be odd to have a "parent" attribute in a non flat XML file. >> It's also odd to have a "parent" on a flat XML file. >=20 > Also there's still the problem how to define a (set of) element(s) > outside of the core Matroska speficications. You mean to define a custom extra section to Matroska? > I can't be the core > specifications including an external file. It should be that external > (XML) that tells where it should be inserted. Is there a common XML > mechanism to inject one file into another ? Yes, in XML Schema there is a way to define an element to contain = xsd:any meaning that any elements may occur within it. Within that = section the sub-element should ideally have a namespace that points to = another XML Schema that defines that particular section. > Does it involve defining > all the elements in the original file to define where we want the > insertion ? With possible mismatch or missing updates. It involves the parent format defining where the flexibility can occur = so that any valid XML is allowed in a defined area and then the contents = of that optionally being defined by another schema. dave >>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 = attribute but to allow that >>> to be implied by the nesting of elements within an EBML Schema. Then = the >>> parent data could be presented for users when we compile = documentation from >>> the EBML Schema. For instance this markdown is build from the EBML = Schema >>> and lists parent values derived from the structure of the EBML = Schema. >>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>=20 >>> Dave Rice >>>=20 >>=20 >>=20 >>=20 >> -- >> Steve Lhomme >> Matroska association Chairman >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Aug 5 08:30:13 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135EF12B013 for ; Fri, 5 Aug 2016 08:30:12 -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 ZVqHSt46Xs6V for ; Fri, 5 Aug 2016 08:30:10 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB95212D541 for ; Fri, 5 Aug 2016 08:30:09 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id j12so268699700ywb.2 for ; Fri, 05 Aug 2016 08:30:09 -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:content-transfer-encoding; bh=RRJ4qgDGvaw5yTXgDCVRzTxxIKUnUcVtMCSZR46WrKg=; b=v7Z5th8bvKusm7dbaiFP5G7UTKBUfpUNhcC2emrjf+8JCazI+QG6QIuJwuKotL5XBC Dip2my8Rd37sOAFfJF+gQyDbLoRXhLxhWpcn1/9oq/GOYtS4e4id051UmPCXxoO/f7gp JnxVDxvm3GJ7Q5uofEEqwZXnXfjn42RE6FkTjsVVaLJ0ZJQWcu1lPLEVW3GSdnBERdB6 azAetXOpnA1wqGavJCc3C0nh71om1wufTk3JPnNpaVyPg0Mc74ZQsB7btftAOkAh3OJJ K2GT3PGk2MtW7qCZvcvThD6vlY4miHTsqprdqTw6O1e5e00OTH8bmijx1zR1213Yu+kZ 7lZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RRJ4qgDGvaw5yTXgDCVRzTxxIKUnUcVtMCSZR46WrKg=; b=QDR6aOOKwu1DYnVWisXzPVe8kEC/99pOZPLjvzjXczRUPnL0QFPuJRIa81vxWTteUC xqqS02tLjaF2RQuHgjVBilGZdBKj6cmL+LIFe6CaS7dsycMAGWGfeRvFOZ7DEJFKZZCC kVboZJdVvmB8Kmz6n8RK+1nAb1pvM+rDnchU9x1POAhWVTMj2Q/6oduooDtJdmxYUNyJ hl33V/vhc5AfI4lXRcJsdJ/HUW/MiC5ymxZej8jAYOMdvjeLhr1fVGTEojGUwzYCF7yq O5UZ8BcP1nUHHRgAfCr6dCfdiGtl9YDt+wgO0XbTwt3U7VwR+jEs6ISqGMK1AMuZjHgS MLKg== X-Gm-Message-State: AEkoouv8u6OkrkJaJoTtE5qM0U/SEjxV2jgJWxnfy1+QuAkkmB+cAeV9DOoXkUJEiceWkp8d1MPflUuzclIqhg== X-Received: by 10.13.227.129 with SMTP id m123mr57376637ywe.90.1470411008890; Fri, 05 Aug 2016 08:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Fri, 5 Aug 2016 08:30:08 -0700 (PDT) In-Reply-To: <703CF364-891E-432F-AE18-7E0C5BE1647F@dericed.com> References: <703CF364-891E-432F-AE18-7E0C5BE1647F@dericed.com> From: Steve Lhomme Date: Fri, 5 Aug 2016 17:30:08 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:30:12 -0000 2016-08-05 17:23 GMT+02:00 Dave Rice : > >> On Aug 5, 2016, at 11:09 AM, Steve Lhomme wrote: >> >> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>> >>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme wrote= : >>> >>> As we're moving towards splitting the Matroska specs in many smaller >>> documents, putting not essential things in a document it becomes more >>> important to define things differently than the "level" element we >>> currently rely on. It makes it very difficult to define a single >>> element without having to copy all its parents to explain where it >>> should go in the EBML format. >>> >>> I think we should set the name of the parent(s) explicitely to avoid >>> that confusion. We will also not rely anymore on the order in which >>> elements are defined in the specs. >>> >>> I did a pull request with this addition: >>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>> >>> This change will probably mean many paragraphs need to be rewritten to >>> rely less on the level system. >>> >>> I will do the pull request for Matroska as well once it's settled. >>> >>> >>> Sorry to join this conversation late. I think the current state of the = EBML >>> implies two different ways of documenting nesting. The EBML Schema exam= ple >>> simply nests the within one another. For example: >>> >>> >>> >> maxOccurs=3D=E2=80=9Cunbounded"> >>> >> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>> >>> >>> >>> The nesting of the EBML Schema implies that FileName occurs within File= and >>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 attrib= ute is redundant to >>> the structure. >> >> Yes it's redundant and should probably be removed. It only creates >> possible issues and gives no extra information. Except when it's 1+ >> which doesn't have any equivalent in XML and is currently not defined. > > It is possible in an XML Schema to define that an element may occur recur= sively within itself. A few methods to do this are detailed at http://lists= .w3.org/Archives/Public/xmlschema-dev/2012Aug/0026.html. > >>> However, later we list out the elements of the EBML Header in a series = of >>> tables. The tables don=E2=80=99t imply the nested structure as the xml = does, so the >>> level attribute here is needed, though it is certainly a bit unclear si= nce >>> determining the parent requiring reading backwards to the last master >>> element of a higher value. >>> >>> I prefer to keep the XML analogy where elements are defined in an XML s= chema >>> where the arrangement of the elements within one another defines the ne= sting >>> structure. Then since we can compile our documentation the =E2=80=9CPar= ent=E2=80=9D values >>> can be decipher from the XML-based EBML Schema. However this gets to a >>> conversation at the CELLAR working group meeting on whether XML should = be >>> considered normative or not. >> >> While I support having an up to date machine readable version of the >> specs. I don't think it should/will be the actual reference for the >> specifications. > > Do you mean that a machine-readable version shouldn't be the reference fo= r human or shouldn't be the reference for tools such as mkvalidator. No programs should use the machine-readable version. So we have to make sure this machine-readable file generates the specs or vice versa. >> Also the XML parent analogy only works if there's a fixed parent and >> the element can only be found at that level. How do you define an >> element that can be found anywhere under /File/Attribute/* (to use the >> path system) (or elements similar to Void and CRC32 which can be >> defined for a certain DocType) ? > > Good point. The current EBML Schema works around this since the only glob= al elements are in the EBML spec and inherited by but not defined by Matros= ka. > >> Either we add an attibute in the XML >> element or we define how level with a + should be interpreted. > > Another option is as it currently is where we have a recursive and global= values and if either are set to true then the level attribute means that i= t may occur at that level or any greater level. That sounds hackish. If you want that special element that can be found in /File/Attributes/* to be a Master element you might be able to find it inside itself. So it would be marked as recursive. A separate attribute is safer IMO. >> Since >> it's extra information it's probably better to put it out of the level >> (which should go from the XML anyway). How would you define an element >> that be put anywhere within a DocType in the XML format ? I agree that >> it would be odd to have a "parent" attribute in a non flat XML file. >> It's also odd to have a "parent" on a flat XML file. > > That's something I think about to. The parent attribute fixes some issues= but if we adopt it then perhaps we should un-nest the EBML Schema. Likely, yes. I suppose for XML tools it's easier to handle a hierarchy when it's already there. But the current specdata.xml is flat it's not a big deal (at least in my code). > dave > >>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 attrib= ute but to allow that >>> to be implied by the nesting of elements within an EBML Schema. Then th= e >>> parent data could be presented for users when we compile documentation = from >>> the EBML Schema. For instance this markdown is build from the EBML Sche= ma >>> and lists parent values derived from the structure of the EBML Schema. >>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>> >>> Dave Rice >>> >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Fri Aug 5 08:34:08 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F0712B071 for ; Fri, 5 Aug 2016 08:34:06 -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 Uxk7OixpvE4R for ; Fri, 5 Aug 2016 08:34:05 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 C726412D50A for ; Fri, 5 Aug 2016 08:34:04 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id z8so269342629ywa.1 for ; Fri, 05 Aug 2016 08:34:04 -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:content-transfer-encoding; bh=gLiPT5wexRIjMsyP0eJBVNOrmjipsy3AcXWIeUq4DyE=; b=rByPt+Q4dK3gYLdGHM8WVXIqYgOqeURxR0ndabKLPf0jFJQNaSOien6jDcCBT5Ojvr 1DvEXVnbaw/FRnxbfYI8fk5L0Ci9HaeSK3pc8DFTG99f0HwIUkXp2Zmq4SXzA8WO/Zay ZVABuuT7CJc4IxLcZpNkQOh1sfDEnklGEL2bmdvKgnN7qdPq90Quy0AizW3q6fBI1eRS dX4K43ewlc/lGtNVpAsfJuIVv/XPLccAwRmJPR+a1yJoTasP69y2xggu1o9KGKy+JEJv Ql7kA0Ap7oNPymOjugLdeQOcEoPPTw0i2qpjt8HtIehTFdAHw9XnrN/znf2sstT4/dkq 261g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gLiPT5wexRIjMsyP0eJBVNOrmjipsy3AcXWIeUq4DyE=; b=AgjY32C3xNfG0lgUDGOuhWMRkM/HQVN2+mD9mPp7aNiLseFvyFKl/bz/ys0I8iXS03 A7wtJib5+T9Ixt3YK8QbDtUj8TcjgA469qEw3UKnE8gFzAGapxwrAantGUx+JnwvHV6V /IhLjOCuEUXh1UBrtZLN2/X2wA+yWLUWkKzY9/7MyU6vNlgaEzXDH+NQoreN5XW8w26D o/ELecREtEjTYirDWjikXOdH2ToAlpF9DU7dbosmVky9WokfnAOtw/Am7LGzBoSx/Got Wku0lcChSKvh2Yfcw+VGepK8mvhrA6m5gKInJkPPLQuxTjyoAXSn2v76WFEhqw/k0pT7 L33g== X-Gm-Message-State: AEkooutP9lfFThuPGg8wzJfew811VjMOJwBFGe0a7knnRUIZIEQiDXOcLKQbfQgosvZ1udae5YUx9W8GROQCXA== X-Received: by 10.13.193.196 with SMTP id c187mr46152160ywd.301.1470411243997; Fri, 05 Aug 2016 08:34:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Fri, 5 Aug 2016 08:34:03 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Fri, 5 Aug 2016 17:34:03 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 15:34:07 -0000 2016-08-05 17:26 GMT+02:00 Dave Rice : > >> On Aug 5, 2016, at 11:13 AM, Steve Lhomme wrote: >> >> 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >>> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>> >>>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme wrot= e: >>>> >>>> As we're moving towards splitting the Matroska specs in many smaller >>>> documents, putting not essential things in a document it becomes more >>>> important to define things differently than the "level" element we >>>> currently rely on. It makes it very difficult to define a single >>>> element without having to copy all its parents to explain where it >>>> should go in the EBML format. >>>> >>>> I think we should set the name of the parent(s) explicitely to avoid >>>> that confusion. We will also not rely anymore on the order in which >>>> elements are defined in the specs. >>>> >>>> I did a pull request with this addition: >>>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>> >>>> This change will probably mean many paragraphs need to be rewritten to >>>> rely less on the level system. >>>> >>>> I will do the pull request for Matroska as well once it's settled. >>>> >>>> >>>> Sorry to join this conversation late. I think the current state of the= EBML >>>> implies two different ways of documenting nesting. The EBML Schema exa= mple >>>> simply nests the within one another. For example: >>>> >>>> >>>> >>> maxOccurs=3D=E2=80=9Cunbounded"> >>>> >>> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>>> >>>> >>>> >>>> The nesting of the EBML Schema implies that FileName occurs within Fil= e and >>>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 attri= bute is redundant to >>>> the structure. >>> >>> Yes it's redundant and should probably be removed. It only creates >>> possible issues and gives no extra information. Except when it's 1+ >>> which doesn't have any equivalent in XML and is currently not defined. >>> >>>> However, later we list out the elements of the EBML Header in a series= of >>>> tables. The tables don=E2=80=99t imply the nested structure as the xml= does, so the >>>> level attribute here is needed, though it is certainly a bit unclear s= ince >>>> determining the parent requiring reading backwards to the last master >>>> element of a higher value. >>>> >>>> I prefer to keep the XML analogy where elements are defined in an XML = schema >>>> where the arrangement of the elements within one another defines the n= esting >>>> structure. Then since we can compile our documentation the =E2=80=9CPa= rent=E2=80=9D values >>>> can be decipher from the XML-based EBML Schema. However this gets to a >>>> conversation at the CELLAR working group meeting on whether XML should= be >>>> considered normative or not. >>> >>> While I support having an up to date machine readable version of the >>> specs. I don't think it should/will be the actual reference for the >>> specifications. >>> >>> Also the XML parent analogy only works if there's a fixed parent and >>> the element can only be found at that level. How do you define an >>> element that can be found anywhere under /File/Attribute/* (to use the >>> path system) (or elements similar to Void and CRC32 which can be >>> defined for a certain DocType) ? Either we add an attibute in the XML >>> element or we define how level with a + should be interpreted. Since >>> it's extra information it's probably better to put it out of the level >>> (which should go from the XML anyway). How would you define an element >>> that be put anywhere within a DocType in the XML format ? I agree that >>> it would be odd to have a "parent" attribute in a non flat XML file. >>> It's also odd to have a "parent" on a flat XML file. >> >> Also there's still the problem how to define a (set of) element(s) >> outside of the core Matroska speficications. > > You mean to define a custom extra section to Matroska? Yes, outside of the original spec. For example if a company does like DivX and creates a set of new elements. We don't want to update the original Matroska specs for that. >> I can't be the core >> specifications including an external file. It should be that external >> (XML) that tells where it should be inserted. Is there a common XML >> mechanism to inject one file into another ? > > Yes, in XML Schema there is a way to define an element to contain xsd:any= meaning that any elements may occur within it. Within that section the sub= -element should ideally have a namespace that points to another XML Schema = that defines that particular section. > >> Does it involve defining >> all the elements in the original file to define where we want the >> insertion ? With possible mismatch or missing updates. > > It involves the parent format defining where the flexibility can occur so= that any valid XML is allowed in a defined area and then the contents of t= hat optionally being defined by another schema. That does not sound very practical/flexible in our case. Or we'd have to define all Master elements with such a system. And that would have to be done for all EBML-based formats. > dave > >>>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 attri= bute but to allow that >>>> to be implied by the nesting of elements within an EBML Schema. Then t= he >>>> parent data could be presented for users when we compile documentation= from >>>> the EBML Schema. For instance this markdown is build from the EBML Sch= ema >>>> and lists parent values derived from the structure of the EBML Schema. >>>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>> >>>> Dave Rice >>>> >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Mon Aug 8 12:19:46 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39BE12D191 for ; Mon, 8 Aug 2016 12:19:38 -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 K-utWwlFqCr7 for ; Mon, 8 Aug 2016 12:19:30 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EDE12B046 for ; Mon, 8 Aug 2016 12:19:29 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id j12so310205911ywb.2 for ; Mon, 08 Aug 2016 12:19:29 -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:content-transfer-encoding; bh=4PrOX05VhFOLJBD5z+nQUxXSFXhEQzOQF5Qs5anCt70=; b=UGL1+UwZ4w7c0+5t2xqt6qdflzJhW9MJ+0RvjakN+IMz/MX33vt2mIqCQy8v8i8ZfN wbSDaRuwLaM1WrmpfwaSpuJa8+EZpKUhjTnoC/iNZDHsVFpDyi7YqyuzL7MXzLMfRY2F UamE71rAOG+o+4JxmTj0fjTqXxcl3y9r+WA15R5TDZe+uYajNo8FP/jrgM+D1Z6GVS2E d9wYtr0z2Q7jOUKDB0ESr//b+3EA4i2tFdYSl0OAR5u5PY8fKpfzgt3ZX/C2vdn9PMsT wMs7dcTIrJ92ya4pqJb/l+jd5G3qS+qlNMmZZS04+my2GU6y8nkxfzu2GysDyp9z8yMW FW9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4PrOX05VhFOLJBD5z+nQUxXSFXhEQzOQF5Qs5anCt70=; b=Dxs26hpigOV+1impzL9N1sT3ppEhg9M+745cWHVQGfVhJQexc5IFFHaOe1LPWpq2WH IoEiaSLyWEMV40EJWSTB7m2txWWe7G9vtNfAp6RXVuMh6kr+0LmuC28AYVTVwe0/lIyc buMgsbUTS5jPWV+KQbPCWtbvOKdzcRaVWhD5wXr8o6IBXUTX0tvU4p68vEiaUAvv828d oBS3YhtN6pj9cdf4YmUkrNzCXSAGtPS+mycF+7c2bMoIKlAaYjhDsL5WNdYkT8+D2rvY QKR1BEfLrSbbpAZfmC7nhdPv6/PKOpvG2YwNymWY48gunLNeChmfYzw319p1xDTWCYgt HYxQ== X-Gm-Message-State: AEkoouvFxLvpIlAeer+0HWmRRdQ7ZdaGd8jkVaIgaXLz0e0nagF3oYs/Y/q6A1cy5+Xn8MeZ39FJwJstFA67kA== X-Received: by 10.13.193.196 with SMTP id c187mr56009726ywd.301.1470683968993; Mon, 08 Aug 2016 12:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Mon, 8 Aug 2016 12:19:28 -0700 (PDT) In-Reply-To: <2E8C6D93-FEEE-40DD-A6C9-E699D0AF3628@dericed.com> References: <2E8C6D93-FEEE-40DD-A6C9-E699D0AF3628@dericed.com> From: Steve Lhomme Date: Mon, 8 Aug 2016 21:19:28 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Nesting elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 19:19:39 -0000 2016-08-02 2:12 GMT+02:00 Dave Rice : > >> On Jul 31, 2016, at 11:44 AM, Steve Lhomme wrote: >> >> Although the EBML specs define Void as level 0+ and CRC32 and level 1+ >> I could not find anywhere in the document how this + sign should be >> interepreted. > > Hmmm, according to https://github.com/Matroska-Org/ebml-specification/bla= me/master/specification.markdown#L226 > > "Note that Elements defined as `global` and `recursive` MAY occur at a le= vel greater than or equal to the defined `level`.=E2=80=9D > > So perhaps the `+` symbols are not needed at all, since both Void and CRC= -32 are noted as global. For those maybe not but for ChapterAtom of SimpleTag we need a way to define unambiguously. But that's what `recursive` does. >> I think it should become an element like default, recursive, etc. Also >> like the Range and Default values, when not set (no nesting) it should >> not be written. That won't make the specifications a lot more verbose. >> >> Related github issue: >> https://github.com/Matroska-Org/ebml-specification/issues/82 >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Mon Aug 8 12:23:28 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1479C12B046 for ; Mon, 8 Aug 2016 12:23:17 -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 DE9XS893jpym for ; Mon, 8 Aug 2016 12:23:09 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 F36C412B004 for ; Mon, 8 Aug 2016 12:23:08 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id j12so310262409ywb.2 for ; Mon, 08 Aug 2016 12:23:08 -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:content-transfer-encoding; bh=1tJu7OSh4r8FqG0XwxYPH+9nQOOkWSFE/L/VauAT9KQ=; b=m5GNbkNwWqzF9zvOnnx4kT/jG4eLdXLA5izy630miGTsja1Ti3jsnzqUPJr4v8rWyI MTwaXvA9lK8dZjylTFcCYkCREE8C9TcIDkE+tbDbKgK3+w5DgBJLsY8I+be8RlDhp0RE ngYqLbTwN7pZMSrLfnIKc15Od60T1jeFIhvVJOlANC9WXBR+xGDot9Dw7X8cGI4olJID QIptn1jlL2vIsW6eMEUkWIQfIhM4jVVH/CsMMC2A3CW3qgyfhFY1GG+qulYidi636j/R /XZKbNhez5kFj2kEj4Dje3oby4ExlHtOySse9JAXd2cfIlLImweGP8d4wjm4zaO91X47 4dag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1tJu7OSh4r8FqG0XwxYPH+9nQOOkWSFE/L/VauAT9KQ=; b=gGwAc8eoUIpmMDdXAkaaILfc+aUd7vKz1lmeeVHOHP9w9YPX+QNxcBANUzl+9wk3ds gDzv3qTe/iwW09qlZN5Z8ifvY3JPUx/Tu/NKg07L/YzoJ7thyKEB2sI81eLFlbI3ZTdS iPezR0d3U74thule3883zdfYy5tvXFHuY9tSgNpqJWiMOR+DwfKx7PbAXwfHyNPCVLq9 YH5TndKFM2RMIe8Dv7CRkU2xSHjasuGBn8WOz3TsGV3K22kRYgIELhYQjdvs/e9pmH4J X5NdsI9nbglZoEvi8vlQmikTQMJAp3NsWyDpbV5M+PXdPHsp0DENhGqJlzyypbw7zJiF bjKQ== X-Gm-Message-State: AEkooutfQgNrlXE3sTLtrDPahW9RYT/1ucExPYqQyVVd/DsuB7TvrhWbTa7LWkLuK14JyC7uig2Kx7NzPCg82Q== X-Received: by 10.13.227.129 with SMTP id m123mr67433176ywe.90.1470684188237; Mon, 08 Aug 2016 12:23:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.70 with HTTP; Mon, 8 Aug 2016 12:23:07 -0700 (PDT) In-Reply-To: References: <2E8C6D93-FEEE-40DD-A6C9-E699D0AF3628@dericed.com> From: Steve Lhomme Date: Mon, 8 Aug 2016 21:23:07 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Nesting elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2016 19:23:17 -0000 I created a Pull Request to remove this plus sign from Void and CRC32 https://github.com/Matroska-Org/ebml-specification/pull/84 2016-08-08 21:19 GMT+02:00 Steve Lhomme : > 2016-08-02 2:12 GMT+02:00 Dave Rice : >> >>> On Jul 31, 2016, at 11:44 AM, Steve Lhomme wrote= : >>> >>> Although the EBML specs define Void as level 0+ and CRC32 and level 1+ >>> I could not find anywhere in the document how this + sign should be >>> interepreted. >> >> Hmmm, according to https://github.com/Matroska-Org/ebml-specification/bl= ame/master/specification.markdown#L226 >> >> "Note that Elements defined as `global` and `recursive` MAY occur at a l= evel greater than or equal to the defined `level`.=E2=80=9D >> >> So perhaps the `+` symbols are not needed at all, since both Void and CR= C-32 are noted as global. > > For those maybe not but for ChapterAtom of SimpleTag we need a way to > define unambiguously. But that's what `recursive` does. > >>> I think it should become an element like default, recursive, etc. Also >>> like the Range and Default values, when not set (no nesting) it should >>> not be written. That won't make the specifications a lot more verbose. >>> >>> Related github issue: >>> https://github.com/Matroska-Org/ebml-specification/issues/82 >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Tue Aug 9 04:54:22 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BB12B028 for ; Tue, 9 Aug 2016 04:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIIeEywFwyJc for ; Tue, 9 Aug 2016 04:54:18 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 AB17812D09A for ; Tue, 9 Aug 2016 04:54:18 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 63D34C0EF1 for ; Tue, 9 Aug 2016 11:54:18 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGDxpPLsEcjU for ; Tue, 9 Aug 2016 11:54:18 +0000 (UTC) Received: from [172.17.0.96] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 16C9EBFF00 for ; Tue, 9 Aug 2016 11:54:18 +0000 (UTC) Message-ID: <57A9C469.4000509@xiph.org> Date: Tue, 09 Aug 2016 04:54:17 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission References: <578E3BD0.3090106@xiph.org> In-Reply-To: <578E3BD0.3090106@xiph.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Confirming consensus to adopt draft-lhomme-cellar-ebml-00 as a WG item X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 11:54:20 -0000 The chairs believe this consensus is confirmed. Authors, please submit a new version of the draft as draft-ietf-cellar-ebml-00. For change-tracking purposes, it may be best to submit a version very close to what was in draft-lhomme-cellar-ebml-00, and then do an -01 update with any changes that have happened since then. From nobody Tue Aug 9 13:11:33 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69812D862 for ; Tue, 9 Aug 2016 13:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY0t8_lwGxlu for ; Tue, 9 Aug 2016 13:11:31 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 18B8212D861 for ; Tue, 9 Aug 2016 13:11:31 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id CD84CC2EA8 for ; Tue, 9 Aug 2016 20:11:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFRaIpWoSjcJ for ; Tue, 9 Aug 2016 20:11:30 +0000 (UTC) Received: from [10.252.25.145] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id B16BDC2B68 for ; Tue, 9 Aug 2016 20:11:30 +0000 (UTC) Message-ID: <57AA38F2.2010800@xiph.org> Date: Tue, 09 Aug 2016 13:11:30 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Draft minutes uploaded X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 20:11:32 -0000 Draft minutes from the Berlin meeting have been uploaded to the proceedings site: https://www.ietf.org/proceedings/96/minutes/minutes-96-cellar Please review and send corrections to the list by the end of next week. Thank you to Mo Zanaty and the others who helped take notes on the etherpad during the session. From nobody Wed Aug 17 06:32:29 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D112D7A1 for ; Wed, 17 Aug 2016 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLACK=1.7] 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 TtTLKbXPds8Z for ; Wed, 17 Aug 2016 06:32:26 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C56712D7E1 for ; Wed, 17 Aug 2016 06:32:19 -0700 (PDT) Received: from [10.0.0.2] (1360030492.d-dsl.at [::ffff:81.16.107.28]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 17 Aug 2016 15:32:18 +0200 id 0000000000000035.0000000057B46762.00002FEB Message-ID: <57B46760.2000304@das-werkstatt.com> Date: Wed, 17 Aug 2016 15:32:16 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] GSoC: P-Frames in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 13:32:28 -0000 Hi all! Stanislav Doganov is currently working on implementing P-frame support in FFV1 as a Google Summer of Code (GSoc) project [1]. I think it would be a very good idea to: a) Say "hello" to Stanislav and let him know about CELLAR. b) Ask here about how we should deal with this new feature being added to FFV1 - in terms of standardization? Is anyone (except Michael) already in touch with Stanislav? Nice greetings and thanks in advance, Pb == References: [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis From nobody Wed Aug 17 06:37:59 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73E612D623 for ; Wed, 17 Aug 2016 06:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLACK=1.7] 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 TKyAt2F7Ghwu for ; Wed, 17 Aug 2016 06:37:56 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D635F12D7BB for ; Wed, 17 Aug 2016 06:37:54 -0700 (PDT) Received: from [10.0.0.2] (1360030492.d-dsl.at [::ffff:81.16.107.28]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 17 Aug 2016 15:37:54 +0200 id 0000000000000035.0000000057B468B3.00003855 Message-ID: <57B468B0.7020009@das-werkstatt.com> Date: Wed, 17 Aug 2016 15:37:52 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] GSoC: Bayer pixel format in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 13:37:58 -0000 Hello again :) Going through the list of FFmpeg GSoC projects, I also saw that Francesco Di Brino has proposed adding bayer pixel format support to FFV1 [1]. Since this topic was mentioned as interesting several times in the last weeks, I wanted to ask if anyone is in contact with Francesco, or knows about the status of this? (Didn't see anything on the ffmpeg lists) Thanks and regards, Pb == References: [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis From nobody Wed Aug 17 06:38:28 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20C12D928 for ; Wed, 17 Aug 2016 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLACK=1.7] 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 HLQwRlrHJrAN for ; Wed, 17 Aug 2016 06:38:25 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 6DB3112D7E4 for ; Wed, 17 Aug 2016 06:38:25 -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 u7HDcNWl020392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 17 Aug 2016 15:38:23 +0200 Received: from Castor.local (rrcs-74-62-21-170.west.biz.rr.com [74.62.21.170]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7HDcJ3J050900 for ; Wed, 17 Aug 2016 15:38:22 +0200 Date: Wed, 17 Aug 2016 15:38:21 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed 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] GSoC: P-Frames in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 13:38:28 -0000 H[ea]llo Peter! >Stanislav Doganov is currently working on implementing P-frame support >in FFV1 as a Google Summer of Code (GSoc) project [1]. >=3D=3D References: >[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis Thank you for this information! Do you know if also the work on adding support for Bayer pixel=20 formats to FFV1 is moving fast forward? Kind regards, Reto From nobody Wed Aug 17 07:14:53 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA612DC42 for ; Wed, 17 Aug 2016 07:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLACK=1.7] 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 aGXX8m6CYkQz for ; Wed, 17 Aug 2016 07:14:51 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60C8112DC35 for ; Wed, 17 Aug 2016 07:14:12 -0700 (PDT) Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1560E1720E4 for ; Wed, 17 Aug 2016 16:14:11 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id iLjE8C80pqW3 for ; Wed, 17 Aug 2016 16:14:09 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 4BB6E1720BD for ; Wed, 17 Aug 2016 16:14:08 +0200 (CEST) Date: Wed, 17 Aug 2016 16:13:43 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160817141343.GW5452@nb4> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jGviIKn9uLGVFpXC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] GSoC: P-Frames in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:14:53 -0000 --jGviIKn9uLGVFpXC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 17, 2016 at 03:38:21PM +0200, Reto Kromer wrote: > H[ea]llo Peter! >=20 > >Stanislav Doganov is currently working on implementing P-frame support > >in FFV1 as a Google Summer of Code (GSoc) project [1]. >=20 > >=3D=3D References: > >[1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016-Qualis >=20 > Thank you for this information! >=20 > Do you know if also the work on adding support for Bayer pixel > formats to FFV1 is moving fast forward? (very basic) Bayer pixel format support was one of several possible qualification tasks for the FFV1 P frame project this google summer of code. There were multiple students interrested in working on FFV1 p frames, noone submitted any work for Bayer pixel formats though IIRC [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad --jGviIKn9uLGVFpXC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAle0cRcACgkQYR7HhwQLD6tUtACfY6IaWwHUEftiut1EbW5bFlFK 5VgAnjdgZf4b3MGl4ieBhkrUgsqnxo2v =4X/m -----END PGP SIGNATURE----- --jGviIKn9uLGVFpXC-- From nobody Thu Aug 18 00:22:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB56312D0CA for ; Thu, 18 Aug 2016 00:22:45 -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] 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 9UiltYSV5jTw for ; Thu, 18 Aug 2016 00:22:44 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A5A12D0E1 for ; Thu, 18 Aug 2016 00:22:43 -0700 (PDT) Received: from [10.0.0.2] (1360030240.d-dsl.at [::ffff:81.16.106.32]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 18 Aug 2016 09:22:41 +0200 id 0000000000000079.0000000057B56241.000015A9 Message-ID: <57B56241.9040807@das-werkstatt.com> Date: Thu, 18 Aug 2016 09:22:41 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <20160817141343.GW5452@nb4> In-Reply-To: <20160817141343.GW5452@nb4> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] GSoC: P-Frames in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:22:46 -0000 On 08/17/2016 04:13 PM, Michael Niedermayer wrote: > On Wed, Aug 17, 2016 at 03:38:21PM +0200, Reto Kromer wrote: >> Do you know if also the work on adding support for Bayer pixel >> formats to FFV1 is moving fast forward? > (very basic) Bayer pixel format support was one of several possible > qualification tasks for the FFV1 P frame project this google summer > of code. There were multiple students interrested in working on > FFV1 p frames, noone submitted any work for Bayer pixel formats though > IIRC Roger that. Just so I understand it correctly: Francesco Di Brino ("Dibri") applied for implementing Bayer support, but never handed in anything? Thanks, Pb From nobody Thu Aug 18 04:57:18 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F6112D09E for ; Thu, 18 Aug 2016 04:57:17 -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] 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 fHrhk45KCzif for ; Thu, 18 Aug 2016 04:57:15 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5141912D137 for ; Thu, 18 Aug 2016 04:57:13 -0700 (PDT) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 4D9D2FB883 for ; Thu, 18 Aug 2016 13:57:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 0_nW7hF7UlYk for ; Thu, 18 Aug 2016 13:57:10 +0200 (CEST) X-Originating-IP: 213.47.41.20 Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id A1970FB89F for ; Thu, 18 Aug 2016 13:57:10 +0200 (CEST) Date: Thu, 18 Aug 2016 13:56:43 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20160818115643.GD5452@nb4> References: <20160817141343.GW5452@nb4> <57B56241.9040807@das-werkstatt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rn1GfcxwU9HQsMTB" Content-Disposition: inline In-Reply-To: <57B56241.9040807@das-werkstatt.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] GSoC: P-Frames in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 11:57:17 -0000 --rn1GfcxwU9HQsMTB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2016 at 09:22:41AM +0200, Peter B. wrote: > On 08/17/2016 04:13 PM, Michael Niedermayer wrote: > > On Wed, Aug 17, 2016 at 03:38:21PM +0200, Reto Kromer wrote: > >> Do you know if also the work on adding support for Bayer pixel > >> formats to FFV1 is moving fast forward? > > (very basic) Bayer pixel format support was one of several possible > > qualification tasks for the FFV1 P frame project this google summer > > of code. There were multiple students interrested in working on > > FFV1 p frames, noone submitted any work for Bayer pixel formats though > > IIRC >=20 > Roger that. >=20 > Just so I understand it correctly: Francesco Di Brino ("Dibri") applied > for implementing Bayer support, but never handed in anything? i see no submission from him on the mailing list, nor do i remember one. So yes it seems so. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. --rn1GfcxwU9HQsMTB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAle1onsACgkQYR7HhwQLD6t81wCdFfA0jjazNE2e5F5Em04c0ekx AJ0An3wFng5WcrfJpVWEg95Pj23Bb1M6 =5nah -----END PGP SIGNATURE----- --rn1GfcxwU9HQsMTB-- From nobody Sat Aug 20 06:36:03 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CD712D82D for ; Sat, 20 Aug 2016 06:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 og8BygvaMOCu for ; Sat, 20 Aug 2016 06:36:00 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 B85C412D826 for ; Sat, 20 Aug 2016 06:35:58 -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 u7KDZvx3008456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 20 Aug 2016 15:35:57 +0200 Received: from Castor.local (rrcs-74-62-21-170.west.biz.rr.com [74.62.21.170]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7KDZsAC026543 for ; Sat, 20 Aug 2016 15:35:56 +0200 Date: Sat, 20 Aug 2016 15:35:56 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 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: [Cellar] Update on RGB 16-bit support in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 13:36:03 -0000 Dear list: It is always embarrassing to talk about oneself! As some of you know, on Friday I did the presentation "Using =D0=9C=D0=B0=D1=82=D1=80= =D1=91=D1=88=D0=BA=D0=B0 and FFV1 for DPX Preservation" at the "The Reel Thing":=20 http://www.the-reel-thing.co/program-abstracts-4/ I am planning to make the presentation available next week. =46or the #tls (Terminal Live Show), directly inspired by Kieran O'Leary, I used an excerpt of a 2K digitisation form a film shot in Dufaycolor, because this colour system is very hard to compress. Michael Niedermayer has been so kind to implement bgrp16 and rgb48 support in FFV1 in time for the presentation. Therefore I could do it in 16-bit DPX. I used a short image sequence, not only a single frame as done in Berlin last month: https://reto.ch/Dufay.mp4 I was really surprised about the interest by industry's representatives and influential individuals from both the Greater Los Angeles Area and the San Francisco Bay Area. I already had many promising discussions during the breaks and I scheduled some additional meetings for more in-depth discussions about Cellar's solution. The proof of concept has been done: we are moving FF! Best regards, Reto From nobody Sat Aug 20 08:44:53 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E302F12D875 for ; Sat, 20 Aug 2016 08:44:51 -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 YxCawL5R6SFv for ; Sat, 20 Aug 2016 08:44:50 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 C4A8F12D77A for ; Sat, 20 Aug 2016 08:44:49 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id f65so68349203wmi.0 for ; Sat, 20 Aug 2016 08:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=60PTHppbCLXtbyOHDKNSJw6HGfdxQZidk3VxCf2HIWA=; b=OOPO9v3mkA0Xrr/VeeP9HvCfQGSWejdcZamPDbts42WRAJHm0XbwT0QesoJzghxpQo ZXDeSTgEEWToES+5bcNJe02S/5olCkUGXuKM2phqWYxEalt5n59Nd4eSmyNVSoseWxKu 9XPKp80logJMFuhdJ3bAkAQ4ANxE1WU2kcmYtRL+vL48F2fPmd15kqSSfbwDndzJ1Z7r qqtz9FcbzN/xnel0EqHL9FGI2uAREdL04PzdLfx+L7N98hIJTdVB2YpsFcHmnWzUOlBm OhFQp9iJ+BWMIvu+AYN5WY6WNZm5NDJpG67HWFP0UNjkTAIfWQiSdw0tbQdeZDmAU2pv yz6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=60PTHppbCLXtbyOHDKNSJw6HGfdxQZidk3VxCf2HIWA=; b=S1rl+JTmTwyrup+ZKoWnKwzhIQNwxcaNV0m5wRPODHN37QqbvTxQnEi3LkxNXwjrW7 bKSnXM89LirYiMV3yVyLeCjg2XQRGN/1K81PpcWETH/azVlCvg5odNX3fRsqp0sL1PpI 2pebxuOXldP1YrAL5SUZ3Hm2uN36jB3TDUv0o04TXf4ZKOefBD47U18BIZs9zxCe7qdN Ccu5iAWmAZTKs4SPeWrObgoAgBub6dW3PnWtEnyxHq7xLziJk11HPSvwk/voOTY3nc6/ PW/suMLf/hkGyMjH5Xn6LFLEu34fSj9VIENLjx1W3GSrBB9CAEkHaN0u3buTtraLvPBV 3Afw== X-Gm-Message-State: AEkoouuNhqDgIOU92GsVFMOdlkl/j4/rBqcX0RRh1nvNFY+iTpjWsS74sw0HE9ZmRn6yuTmIlnABbf8f7WbGPw== X-Received: by 10.28.215.81 with SMTP id o78mr8044597wmg.42.1471707887987; Sat, 20 Aug 2016 08:44:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.152.202 with HTTP; Sat, 20 Aug 2016 08:44:47 -0700 (PDT) In-Reply-To: References: From: Kieran O Leary Date: Sat, 20 Aug 2016 16:44:47 +0100 Message-ID: To: cellar@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] Update on RGB 16-bit support in FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 15:44:52 -0000 Hello Reto, On Sat, Aug 20, 2016 at 2:35 PM, Reto Kromer wrote: > > I am planning to make the presentation available next week. > I'm really looking forward to seeing it. > Michael Niedermayer has been so kind > to implement bgrp16 and rgb48 support in FFV1 in time for > the presentation. Therefore I could do it in 16-bit DPX. I > used a short image sequence, not only a single frame as done > in Berlin last month: > > https://reto.ch/Dufay.mp4 > That is such a fantastic test clip! I'd like to reiterate my thanks to both Michael and yourself with regards to 16-bit support. > I was really surprised about the interest by industry's > representatives and influential individuals from both the > Greater Los Angeles Area and the San Francisco Bay Area. I > already had many promising discussions during the breaks and > I scheduled some additional meetings for more in-depth > discussions about Cellar's solution. The proof of concept > has been done: we are moving FF! > This is absolutely wonderful to hear. Congratulations on doing important advocacy work for the use of FFV1 for film scans. Best, Kieran. From nobody Sun Aug 21 08:51:19 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B5E12D177 for ; Sun, 21 Aug 2016 08:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 NyPYheZfRbuW for ; Sun, 21 Aug 2016 08:51:16 -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 446AD12D0A0 for ; Sun, 21 Aug 2016 08:51:16 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7LFpDeN025600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 21 Aug 2016 17:51:13 +0200 Received: from Castor.local (rrcs-74-62-21-170.west.biz.rr.com [74.62.21.170]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7LFpAu9063992 for ; Sun, 21 Aug 2016 17:51:13 +0200 Date: Sun, 21 Aug 2016 17:51:12 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 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: [Cellar] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 15:51:18 -0000 Hello, at the moment, we have `ffmpeg -h muxer=3Dmatroska`: Muxer matroska [Matroska]: Common extensions: mkv. Mime type: video/x-matroska. Default video codec: h264. Default audio codec: ac3. Default subtitle codec: ass. Will this change, the default video codec becoming FFV1 and the default audio codec becoming FLAC, or not? Thank you! Best regards, Reto From nobody Sun Aug 21 12:36:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A352F12D1DE for ; Sun, 21 Aug 2016 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvMmAdPtrprS for ; Sun, 21 Aug 2016 12:36:22 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 08D8D12D0C8 for ; Sun, 21 Aug 2016 12:36:21 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 38so92352622iol.0 for ; Sun, 21 Aug 2016 12:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g4grwBkRF7mpjFhPhqeEwW5m1NS47Ok7WekdpGDuc1Y=; b=AwB12t8i5IkdhJkIXBSyeDGlmSrGWMt8h+YyC6nGFkaN1ZL01qFgVZYPqBP5G6MEPY p+1LisySjM55hyjc6K1MfTZ8YS5k5ORYY3pYmPfUU5LBHGtE2l8jGG7YNwqOBsRRN056 YD2gsQirk6Tx/Hhow5U8fecbihfYFBaNaSos8BuSUEs2dVIEA8GhpPwmvbhrSdw6n8XU 0uRbqBZxH55/qFZ3Rk0EhQ5KpI2Io074Y6LynHAV8yQl+0JzCDrKDlfZ3p9Z8W/g1vlK 5F+9bYTmCvxiJN0+H7DEJal/cr6UQa6hoBb3JT+VXoJw/gkQC6Lna9mHlWlevZ5Zl6tB 3keg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g4grwBkRF7mpjFhPhqeEwW5m1NS47Ok7WekdpGDuc1Y=; b=e2l7wXN8xdWmTxB3D+PvxwZFU5F3NQZzoQWC9MqNJTb7ziihOJ6oEosmSiRBf5/chy 2RrlFAovBuxrN3XcfE/1XwUXeK3RXTeenP1zFkc6q40DRui11AtMyPNMeC9WP4SZjiB6 LpOYD4wtC4RyN+XeYYVpdHHVJ5jmdlE5wJYj/zgtJfBXDTS9SzwturAgKuAhERvgLggd 98n8IdZW9DtR/c1/yo6OhbOPPBgJO4H+Wh6/9nwLsssmO7JJ/H+5X4PUBF1BW0rUGeg0 l7pwklLAmGSDQFs0Fs2x/PYeMjI96VYaYWthtAfHkiYSDzsFzln2CECAf3/WUmZI/ZYb vOlg== X-Gm-Message-State: AEkoouv+yvj1QS5TiqQkEHLh+oblM+t+ifA3mWJq+vMGoH7WCZYHLk2b/XS6ZMFVJJFh4B334fEdywFFaK+muQzh X-Received: by 10.107.20.206 with SMTP id 197mr22246385iou.103.1471808181091; Sun, 21 Aug 2016 12:36:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.139.197 with HTTP; Sun, 21 Aug 2016 12:36:20 -0700 (PDT) In-Reply-To: References: From: Michael Bradshaw Date: Sun, 21 Aug 2016 12:36:20 -0700 Message-ID: To: Reto Kromer Content-Type: multipart/alternative; boundary=001a114fbe78cfffa9053a9a0bc5 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 19:36:23 -0000 --001a114fbe78cfffa9053a9a0bc5 Content-Type: text/plain; charset=UTF-8 I think that's up to the ffmpeg community to decide what they want their tool to default to. ffv1 and FLAC are nice but I doubt they'll be commonly used enough to warrant a default change. On Sunday, August 21, 2016, Reto Kromer wrote: > Hello, > > at the moment, we have `ffmpeg -h muxer=matroska`: > > Muxer matroska [Matroska]: > Common extensions: mkv. > Mime type: video/x-matroska. > Default video codec: h264. > Default audio codec: ac3. > Default subtitle codec: ass. > > Will this change, the default video codec becoming FFV1 and > the default audio codec becoming FLAC, or not? Thank you! > > Best regards, Reto > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a114fbe78cfffa9053a9a0bc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that's up to the ffmpeg community to decide what they want thei= r tool to default to. ffv1 and FLAC are nice but I doubt they'll be com= monly used enough to warrant a default change.

On Sunda= y, August 21, 2016, Reto Kromer <lists@= reto.ch> wrote:
Hello,

at the moment, we have `ffmpeg -h muxer=3Dmatroska`:

=C2=A0 =C2=A0 Muxer matroska [Matroska]:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Common extensions: mkv.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mime type: video/x-matroska.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Default video codec: h264.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Default audio codec: ac3.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Default subtitle codec: ass.

Will this change, the default video codec becoming FFV1 and
the default audio codec becoming FLAC, or not? Thank you!

Best regards, Reto

_______________________________________________
Cellar mailing list
Cellar@ietf.org
= https://www.ietf.org/mailman/listinfo/cellar
--001a114fbe78cfffa9053a9a0bc5-- From nobody Sun Aug 21 12:47:51 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5E12D812 for ; Sun, 21 Aug 2016 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPoJlf8QoSvI for ; Sun, 21 Aug 2016 12:47:47 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C941412D80E for ; Sun, 21 Aug 2016 12:47:47 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:46541 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bbYid-000Iwz-Pt; Sun, 21 Aug 2016 15:47:46 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_54EDCBD9-6407-4FBB-9764-4F38B97BBE33" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Sun, 21 Aug 2016 15:47:41 -0400 Message-Id: <570C0878-417C-4B5E-AFE2-89D8875FE140@dericed.com> References: To: Michael Bradshaw X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Reto Kromer Subject: Re: [Cellar] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 19:47:50 -0000 --Apple-Mail=_54EDCBD9-6407-4FBB-9764-4F38B97BBE33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Michael. =46rom the archive.org Matroska survey almost 94% = of the video within Matroska is h264. Interestingly ac3 is not the most = popular mkv audio encoding, but ac3 is about 15.7% while aac is 64%. = Most users of MKV will stick closer to those defaults for the intention = of accessibility. If the CELLAR community wanted to integrate a proposed encoding for a = particular purpose (archiving, transmission, etc), I suggest that this = would be done by defining a =E2=80=98target=E2=80=99 in ffmpeg rather = than modifying its default behavior. For instance see how vcd and dvd = are defined in the opt_target function at = https://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24b8cb71c98df= 2b94/ffmpeg_opt.c#L2550-L2691. Feasibly we could propose a target that = combines suggested options for archiving: -slicecrc 1 -level 3 -c:v = ffv1, etc. Best Regards, Dave Rice > On Aug 21, 2016, at 3:36 PM, Michael Bradshaw = wrote: >=20 > I think that's up to the ffmpeg community to decide what they want = their tool to default to. ffv1 and FLAC are nice but I doubt they'll be = commonly used enough to warrant a default change. >=20 > On Sunday, August 21, 2016, Reto Kromer > wrote: > Hello, >=20 > at the moment, we have `ffmpeg -h muxer=3Dmatroska`: >=20 > Muxer matroska [Matroska]: > Common extensions: mkv. > Mime type: video/x-matroska. > Default video codec: h264. > Default audio codec: ac3. > Default subtitle codec: ass. >=20 > Will this change, the default video codec becoming FFV1 and > the default audio codec becoming FLAC, or not? Thank you! >=20 > Best regards, Reto >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_54EDCBD9-6407-4FBB-9764-4F38B97BBE33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I agree with Michael. =46rom the archive.org Matroska survey = almost 94% of the video within Matroska is h264. Interestingly ac3 is = not the most popular mkv audio encoding, but ac3 is about 15.7% while = aac is 64%. Most users of MKV will stick closer to those defaults for = the intention of accessibility.

If the CELLAR community wanted to = integrate a proposed encoding for a particular purpose (archiving, = transmission, etc), I suggest that this would be done by defining a = =E2=80=98target=E2=80=99 in ffmpeg rather than modifying its default = behavior. For instance see how vcd and dvd are defined in the opt_target = function at https://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24= b8cb71c98df2b94/ffmpeg_opt.c#L2550-L2691. Feasibly we could propose = a target that combines suggested options for archiving: -slicecrc 1 = -level 3 -c:v ffv1, etc.

Best Regards,
Dave Rice

On = Aug 21, 2016, at 3:36 PM, Michael Bradshaw <mjbshaw@google.com> = wrote:

I = think that's up to the ffmpeg community to decide what they want their = tool to default to. ffv1 and FLAC are nice but I doubt they'll be = commonly used enough to warrant a default change.

On Sunday, August 21, = 2016, Reto Kromer <lists@reto.ch> wrote:
Hello,

at the moment, we have `ffmpeg -h muxer=3Dmatroska`:

    Muxer matroska [Matroska]:
        Common extensions: mkv.
        Mime type: video/x-matroska.
        Default video codec: h264.
        Default audio codec: ac3.
        Default subtitle codec: ass.

Will this change, the default video codec becoming FFV1 and
= the default audio codec becoming FLAC, or not? Thank you!

Best regards, Reto

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

= --Apple-Mail=_54EDCBD9-6407-4FBB-9764-4F38B97BBE33-- From nobody Sun Aug 21 13:36:13 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0112D0CE for ; Sun, 21 Aug 2016 13:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 qBzbtI6p8NKg for ; Sun, 21 Aug 2016 13:36:10 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 C4A7812B05E for ; Sun, 21 Aug 2016 13:36:09 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id q128so17517177wma.1 for ; Sun, 21 Aug 2016 13:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Njty3SQ/T/YBDYg2gLNaRjMltbgL0/zkn9XtAwKPwZI=; b=QcHuUogsawSTC8hS5BuGa+7COmqI+DmAVP0w9zgolDsfVR75YMLADj+f9YILezpB9i eKfSX27cvZ3Nz6IixL+aOMzfQFslLk4jaeWkUd78JCXXRS9ebVWNSkp106Ox45v8bYrH 97HbrKVzLfcm3K3xkoj3ZDwR02BM+2pBrpxloJkOk1kYWC5xn7LnsP8LJp3mhr3wACjw OTmaWjyFRfYi7XXJQQ9aLHD5MWolGxBubZ+azsT0MTJoYAcuNFmXx4VUoowPCti3mWLt re9efxV5Irdvj/EzEXUa4y6WVvrt46mTB5Ya4GtF8I6+6bcJeruDAq/w/DU1Wsv0Sc1T nJ8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Njty3SQ/T/YBDYg2gLNaRjMltbgL0/zkn9XtAwKPwZI=; b=LrceHX2mWNj9nP7flzNtOdJs0SNC93AsezUxKWwTL0KHln2hMj6Ywq0WTMpKYovfdW l12OMi/nnSlNDHs+zPg+NARkZFdVSExD+dIzp5PEeGvuEUWCVG+Uf09LeoB4d0h/ls3f QU1fVLiufVjW0jFi0/kPJlgXpaVGSr8rLuOJGhDJ0ih5WTed2vszIMgqosR+7T0uNsll Js6ysdL+NUQyCEZcLU6aMflv3Nb6eDh3fuv3SBZlrvREih3H5FgppDlsg8L7iCYrvyhx lQa9FqfFLyzSWgtjHTgnZqlODtgbumcPFNNfQP5qFIw9uj6RPu8rj8B7eUQwo8kg8d+x SYYQ== X-Gm-Message-State: AEkooutRs7i/KtjRDmMtMG2KdA+kkzYS7HWUD1Hdc8rYF4e5xAvAqWVqhTtyzY41MvpL+ygPyH3VCaqQXAhK4g== X-Received: by 10.28.20.139 with SMTP id 133mr11938532wmu.78.1471811768239; Sun, 21 Aug 2016 13:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.152.202 with HTTP; Sun, 21 Aug 2016 13:36:07 -0700 (PDT) Received: by 10.194.152.202 with HTTP; Sun, 21 Aug 2016 13:36:07 -0700 (PDT) In-Reply-To: <570C0878-417C-4B5E-AFE2-89D8875FE140@dericed.com> References: <570C0878-417C-4B5E-AFE2-89D8875FE140@dericed.com> From: Kieran O Leary Date: Sun, 21 Aug 2016 21:36:07 +0100 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a1145b52c9f4b8c053a9ae165 Archived-At: Cc: Michael Bradshaw , cellar@ietf.org, Reto Kromer Subject: Re: [Cellar] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 20:36:11 -0000 --001a1145b52c9f4b8c053a9ae165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi On 21 Aug 2016 8:47 p.m., "Dave Rice" > > If the CELLAR community wanted to integrate a proposed encoding for a particular purpose (archiving, transmission, etc), I suggest that this would be done by defining a =E2=80=98target=E2=80=99 in ffmpeg rather than = modifying its default behavior. For instance see how vcd and dvd are defined in the opt_target function at https://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24b8cb71c98df2= b94/ffmpeg_opt.c#L2550-L2691. Feasibly we could propose a target that combines suggested options for archiving: -slicecrc 1 -level 3 -c:v ffv1, etc. > +1 I think this is a great idea. Perhaps another way of doing it could be a profile for ffv1, kind of like `-profile:v archive`, or something like that= . -kieran. --001a1145b52c9f4b8c053a9ae165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi

On 21 Aug 2016 8:47 p.m., "Dave Rice"
>
> If the CELLAR community wanted to integrate a proposed encoding for a = particular purpose (archiving, transmission, etc), I suggest that this woul= d be done by defining a =E2=80=98target=E2=80=99 in ffmpeg rather than modi= fying its default behavior. For instance see how vcd and dvd are defined in= the opt_target function at=C2=A0h= ttps://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24b8cb71c98df2b= 94/ffmpeg_opt.c#L2550-L2691. Feasibly we could propose a target that co= mbines suggested options for archiving: -slicecrc 1 -level 3 -c:v ffv1, etc= .
>

+1
I think this is a great idea. Perhaps another way of doing it could=C2=A0 b= e a profile for ffv1, kind of like `-profile:v archive`, or something like = that.

-kieran.

--001a1145b52c9f4b8c053a9ae165-- From nobody Sun Aug 21 13:40:01 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFA112D7CE for ; Sun, 21 Aug 2016 13:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 0bbIuUFXdZ7o for ; Sun, 21 Aug 2016 13:39:57 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 5A7EC12D0CE for ; Sun, 21 Aug 2016 13:39:57 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7LKdtJf022015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 21 Aug 2016 22:39:55 +0200 Received: from Castor.local (rrcs-74-62-21-170.west.biz.rr.com [74.62.21.170]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u7LKdqRc013883 for ; Sun, 21 Aug 2016 22:39:54 +0200 Date: Sun, 21 Aug 2016 22:39:54 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: <570C0878-417C-4B5E-AFE2-89D8875FE140@dericed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed 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] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 20:40:00 -0000 Thank you very much, Michael and Dave, for the answer and the statistical information of today's reality. I can understand that the Matroska users are mainly interested in accessibility. Seen from the point of view of preservation, a solution like the mentioned could be of interest: >If the CELLAR community wanted to integrate a proposed >encoding for a particular purpose (archiving, transmission, >etc), I suggest that this would be done by defining a >=E2=80=98target=E2=80=99 in ffmpeg rather than modifying its default >behavior. For instance see how vcd and dvd are defined in >the opt_target function at=20 >https://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24b8cb71c98df= 2b94/ffmpeg_opt.c#L2550-L2691.=20 >Feasibly we could propose a target that combines suggested >options for archiving: -slicecrc 1 -level 3 -c:v ffv1, etc. I have no clear preference for now; I need to delve deeper into this, in order to gather a better overview. On my side, the question raised up, because I am preparing some quick demo interfaces for tomorrow. Of course, I can "put into" a button any code, more or less complex... Thanks again and best regards, Reto From nobody Tue Aug 23 11:35:38 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6005812D10F for ; Tue, 23 Aug 2016 11:35:36 -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 klJbl9E5p1-C for ; Tue, 23 Aug 2016 11:35:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 4779212D5CF for ; Tue, 23 Aug 2016 11:35:33 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j12so77478996ywb.2 for ; Tue, 23 Aug 2016 11:35:33 -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:content-transfer-encoding; bh=l/ueS2v7BPDqAbeO5NU78vhoBBV+cAsursB8eH6cnGU=; b=lWyuEwtaH44nK5R/D4t/rgPxxhOFrMV3S2ZxC8GA0zX7EpXxkN0bB2rIB6yapwWss4 JuuNyo9nWUCX6k7UPD6Twc0sRlzI8nCSJ5G7yYMJg17sRjNbAUmkKVzPWlrWWN9CKOkm 2oiGN+spdHiYLZFq3f2b9FvzkE3auWCS7tuaQ7e+Cmgk7qUIx6yVNeJ+X8LnX9cAsVLs ZsQUXB6xgLrbVtcdN5OBT5otEhpfIPV4MB+EiegJ649s3EuUlgZGGErDC6iUzq7vH5qK dqVG4/fG6JSbAbzqyQMaqm9qH5+CAHvtX6njg4/F7t3QmSclJ+aP+wO4uqEjzRkwaLek pCEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=l/ueS2v7BPDqAbeO5NU78vhoBBV+cAsursB8eH6cnGU=; b=a0J2spWST5Dyl/Rsf2qA14iHtPl3C65eQgWjud+y0l1tHLU58vg/AT7TowIWlnly6A xrG3/UnU3K5HUnUgtnNJcUknIzTFqFEXPt2UOylDw1y9bFvWhiTkwap+w232MMCQT4jW FiIO7KAiX56cqybZaSn/jVz0Ci5sFSwc8vTmdAd9z1bt8ogaCW2xwEKcGTH/pHRVhaSp aYqSI98RsVapwCFiGyxfwsndW4ag8DYOwFDxi+KIJ1518SC5b5zEDa9XFmoVXbEDQHP0 ZKDpAFRQgHu47oD1mK+QV9/FXWLhHoxkFQ6vphc/TDCpiOv8bavoVT4lzunuRPAtQO+z vzlg== X-Gm-Message-State: AEkoouuoa+8qwIEp40OXEXAW5t4p0paemeYoqQw8g2o8oZA0XuehIt2blG7yDB2VODYCQI2uZlETPb8S0LFZuA== X-Received: by 10.13.227.129 with SMTP id m123mr22535233ywe.90.1471977333229; Tue, 23 Aug 2016 11:35:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.135 with HTTP; Tue, 23 Aug 2016 11:35:32 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Tue, 23 Aug 2016 20:35:32 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 18:35:36 -0000 I updated the pull request with something that merges with the current mast= er. Anyone disagree with the move before I merge it ? The next steps after that: - unflatten the XML definition - remove the level altogether, including all text references and in the Matroska specs. 2016-08-05 17:34 GMT+02:00 Steve Lhomme : > 2016-08-05 17:26 GMT+02:00 Dave Rice : >> >>> On Aug 5, 2016, at 11:13 AM, Steve Lhomme wrote: >>> >>> 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >>>> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>>> >>>>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme wro= te: >>>>> >>>>> As we're moving towards splitting the Matroska specs in many smaller >>>>> documents, putting not essential things in a document it becomes more >>>>> important to define things differently than the "level" element we >>>>> currently rely on. It makes it very difficult to define a single >>>>> element without having to copy all its parents to explain where it >>>>> should go in the EBML format. >>>>> >>>>> I think we should set the name of the parent(s) explicitely to avoid >>>>> that confusion. We will also not rely anymore on the order in which >>>>> elements are defined in the specs. >>>>> >>>>> I did a pull request with this addition: >>>>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>>> >>>>> This change will probably mean many paragraphs need to be rewritten t= o >>>>> rely less on the level system. >>>>> >>>>> I will do the pull request for Matroska as well once it's settled. >>>>> >>>>> >>>>> Sorry to join this conversation late. I think the current state of th= e EBML >>>>> implies two different ways of documenting nesting. The EBML Schema ex= ample >>>>> simply nests the within one another. For example: >>>>> >>>>> >>>>> >>>> maxOccurs=3D=E2=80=9Cunbounded"> >>>>> >>>> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>>>> >>>>> >>>>> >>>>> The nesting of the EBML Schema implies that FileName occurs within Fi= le and >>>>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 attr= ibute is redundant to >>>>> the structure. >>>> >>>> Yes it's redundant and should probably be removed. It only creates >>>> possible issues and gives no extra information. Except when it's 1+ >>>> which doesn't have any equivalent in XML and is currently not defined. >>>> >>>>> However, later we list out the elements of the EBML Header in a serie= s of >>>>> tables. The tables don=E2=80=99t imply the nested structure as the xm= l does, so the >>>>> level attribute here is needed, though it is certainly a bit unclear = since >>>>> determining the parent requiring reading backwards to the last master >>>>> element of a higher value. >>>>> >>>>> I prefer to keep the XML analogy where elements are defined in an XML= schema >>>>> where the arrangement of the elements within one another defines the = nesting >>>>> structure. Then since we can compile our documentation the =E2=80=9CP= arent=E2=80=9D values >>>>> can be decipher from the XML-based EBML Schema. However this gets to = a >>>>> conversation at the CELLAR working group meeting on whether XML shoul= d be >>>>> considered normative or not. >>>> >>>> While I support having an up to date machine readable version of the >>>> specs. I don't think it should/will be the actual reference for the >>>> specifications. >>>> >>>> Also the XML parent analogy only works if there's a fixed parent and >>>> the element can only be found at that level. How do you define an >>>> element that can be found anywhere under /File/Attribute/* (to use the >>>> path system) (or elements similar to Void and CRC32 which can be >>>> defined for a certain DocType) ? Either we add an attibute in the XML >>>> element or we define how level with a + should be interpreted. Since >>>> it's extra information it's probably better to put it out of the level >>>> (which should go from the XML anyway). How would you define an element >>>> that be put anywhere within a DocType in the XML format ? I agree that >>>> it would be odd to have a "parent" attribute in a non flat XML file. >>>> It's also odd to have a "parent" on a flat XML file. >>> >>> Also there's still the problem how to define a (set of) element(s) >>> outside of the core Matroska speficications. >> >> You mean to define a custom extra section to Matroska? > > Yes, outside of the original spec. For example if a company does like > DivX and creates a set of new elements. We don't want to update the > original Matroska specs for that. > >>> I can't be the core >>> specifications including an external file. It should be that external >>> (XML) that tells where it should be inserted. Is there a common XML >>> mechanism to inject one file into another ? >> >> Yes, in XML Schema there is a way to define an element to contain xsd:an= y meaning that any elements may occur within it. Within that section the su= b-element should ideally have a namespace that points to another XML Schema= that defines that particular section. >> >>> Does it involve defining >>> all the elements in the original file to define where we want the >>> insertion ? With possible mismatch or missing updates. >> >> It involves the parent format defining where the flexibility can occur s= o that any valid XML is allowed in a defined area and then the contents of = that optionally being defined by another schema. > > That does not sound very practical/flexible in our case. Or we'd have > to define all Master elements with such a system. And that would have > to be done for all EBML-based formats. > >> dave >> >>>>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 attr= ibute but to allow that >>>>> to be implied by the nesting of elements within an EBML Schema. Then = the >>>>> parent data could be presented for users when we compile documentatio= n from >>>>> the EBML Schema. For instance this markdown is build from the EBML Sc= hema >>>>> and lists parent values derived from the structure of the EBML Schema= . >>>>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>>> >>>>> Dave Rice >>>>> >>>> >>>> >>>> >>>> -- >>>> Steve Lhomme >>>> Matroska association Chairman >>> >>> >>> >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Tue Aug 23 11:39:32 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D602A12D73F for ; Tue, 23 Aug 2016 11:39:31 -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 wListNi2bf_6 for ; Tue, 23 Aug 2016 11:39:30 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1423612D6B3 for ; Tue, 23 Aug 2016 11:39:30 -0700 (PDT) Received: from [146.96.19.240] (port=14732 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bcGbe-0021Nz-79; Tue, 23 Aug 2016 14:39:29 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Tue, 23 Aug 2016 14:39:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4DC31048-4D9E-4039-B576-ECDC434A6A1E@dericed.com> References: To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 18:39:32 -0000 > On Aug 23, 2016, at 2:35 PM, Steve Lhomme = wrote: >=20 > I updated the pull request with something that merges with the current = master. >=20 > Anyone disagree with the move before I merge it ? I've been thinking about it and have slowly starting thinking that this = is a better approach than I first thought. It does deviate from the XML = Schema analogy but maybe the complexity of XML Schemas aren't for the = best here. You're right that it would be easier to add extensions (divx) = with this approach. It also resolves the issue with xml being normative, = since the text and xml versions would be more semantically identical = without depending on xml nesting. > The next steps after that: > - unflatten the XML definition What do you mean? > - remove the level altogether, including all text references and in > the Matroska specs. Yes. Dave > 2016-08-05 17:34 GMT+02:00 Steve Lhomme : >> 2016-08-05 17:26 GMT+02:00 Dave Rice : >>>=20 >>>> On Aug 5, 2016, at 11:13 AM, Steve Lhomme = wrote: >>>>=20 >>>> 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >>>>> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>>>>=20 >>>>>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme = wrote: >>>>>>=20 >>>>>> As we're moving towards splitting the Matroska specs in many = smaller >>>>>> documents, putting not essential things in a document it becomes = more >>>>>> important to define things differently than the "level" element = we >>>>>> currently rely on. It makes it very difficult to define a single >>>>>> element without having to copy all its parents to explain where = it >>>>>> should go in the EBML format. >>>>>>=20 >>>>>> I think we should set the name of the parent(s) explicitely to = avoid >>>>>> that confusion. We will also not rely anymore on the order in = which >>>>>> elements are defined in the specs. >>>>>>=20 >>>>>> I did a pull request with this addition: >>>>>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>>>>=20 >>>>>> This change will probably mean many paragraphs need to be = rewritten to >>>>>> rely less on the level system. >>>>>>=20 >>>>>> I will do the pull request for Matroska as well once it's = settled. >>>>>>=20 >>>>>>=20 >>>>>> Sorry to join this conversation late. I think the current state = of the EBML >>>>>> implies two different ways of documenting nesting. The EBML = Schema example >>>>>> simply nests the within one another. For example: >>>>>>=20 >>>>>> >>>>>> >>>>> maxOccurs=3D=E2=80=9Cunbounded"> >>>>>> >>>>> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>>>>> >>>>>> >>>>>>=20 >>>>>> The nesting of the EBML Schema implies that FileName occurs = within File and >>>>>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 = attribute is redundant to >>>>>> the structure. >>>>>=20 >>>>> Yes it's redundant and should probably be removed. It only creates >>>>> possible issues and gives no extra information. Except when it's = 1+ >>>>> which doesn't have any equivalent in XML and is currently not = defined. >>>>>=20 >>>>>> However, later we list out the elements of the EBML Header in a = series of >>>>>> tables. The tables don=E2=80=99t imply the nested structure as = the xml does, so the >>>>>> level attribute here is needed, though it is certainly a bit = unclear since >>>>>> determining the parent requiring reading backwards to the last = master >>>>>> element of a higher value. >>>>>>=20 >>>>>> I prefer to keep the XML analogy where elements are defined in an = XML schema >>>>>> where the arrangement of the elements within one another defines = the nesting >>>>>> structure. Then since we can compile our documentation the = =E2=80=9CParent=E2=80=9D values >>>>>> can be decipher from the XML-based EBML Schema. However this gets = to a >>>>>> conversation at the CELLAR working group meeting on whether XML = should be >>>>>> considered normative or not. >>>>>=20 >>>>> While I support having an up to date machine readable version of = the >>>>> specs. I don't think it should/will be the actual reference for = the >>>>> specifications. >>>>>=20 >>>>> Also the XML parent analogy only works if there's a fixed parent = and >>>>> the element can only be found at that level. How do you define an >>>>> element that can be found anywhere under /File/Attribute/* (to use = the >>>>> path system) (or elements similar to Void and CRC32 which can be >>>>> defined for a certain DocType) ? Either we add an attibute in the = XML >>>>> element or we define how level with a + should be interpreted. = Since >>>>> it's extra information it's probably better to put it out of the = level >>>>> (which should go from the XML anyway). How would you define an = element >>>>> that be put anywhere within a DocType in the XML format ? I agree = that >>>>> it would be odd to have a "parent" attribute in a non flat XML = file. >>>>> It's also odd to have a "parent" on a flat XML file. >>>>=20 >>>> Also there's still the problem how to define a (set of) element(s) >>>> outside of the core Matroska speficications. >>>=20 >>> You mean to define a custom extra section to Matroska? >>=20 >> Yes, outside of the original spec. For example if a company does like >> DivX and creates a set of new elements. We don't want to update the >> original Matroska specs for that. >>=20 >>>> I can't be the core >>>> specifications including an external file. It should be that = external >>>> (XML) that tells where it should be inserted. Is there a common XML >>>> mechanism to inject one file into another ? >>>=20 >>> Yes, in XML Schema there is a way to define an element to contain = xsd:any meaning that any elements may occur within it. Within that = section the sub-element should ideally have a namespace that points to = another XML Schema that defines that particular section. >>>=20 >>>> Does it involve defining >>>> all the elements in the original file to define where we want the >>>> insertion ? With possible mismatch or missing updates. >>>=20 >>> It involves the parent format defining where the flexibility can = occur so that any valid XML is allowed in a defined area and then the = contents of that optionally being defined by another schema. >>=20 >> That does not sound very practical/flexible in our case. Or we'd have >> to define all Master elements with such a system. And that would have >> to be done for all EBML-based formats. >>=20 >>> dave >>>=20 >>>>>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 = attribute but to allow that >>>>>> to be implied by the nesting of elements within an EBML Schema. = Then the >>>>>> parent data could be presented for users when we compile = documentation from >>>>>> the EBML Schema. For instance this markdown is build from the = EBML Schema >>>>>> and lists parent values derived from the structure of the EBML = Schema. >>>>>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>>>>=20 >>>>>> Dave Rice >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Steve Lhomme >>>>> Matroska association Chairman >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Steve Lhomme >>>> Matroska association Chairman >>>>=20 >>>> _______________________________________________ >>>> Cellar mailing list >>>> Cellar@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cellar >>>=20 >>=20 >>=20 >>=20 >> -- >> Steve Lhomme >> Matroska association Chairman >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Aug 23 11:41:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4BE12D5AD for ; Tue, 23 Aug 2016 11:41:56 -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] 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 li9U4loSgPp5 for ; Tue, 23 Aug 2016 11:41:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8492D12D73A for ; Tue, 23 Aug 2016 11:41:52 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r9so77875035ywg.0 for ; Tue, 23 Aug 2016 11:41:52 -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:content-transfer-encoding; bh=hR9QQZXebo7rsY4mPHlA+gQwr4b9NcjtBcCBgUSfP9Q=; b=Xis/638Bjggr/OwXgt/dh4OSZzOnL4HJfNyZJ3FjspoZL2R6eZ0hHVNeAyomCN85/W EpBCssnI7VsMnG90l1Hqe01zB32fmtX4um5QevDN/9h3wrO6X4opvlz/bc5/E2V8PAq/ jhMvWG2XInXwuenVcEvK+slBT8Ya79WAiLhlD6MIcQGlG22ql/Z5q75WlEMmK0VMrfE2 nV4G0TIDNQmXavpOYKipPq4IiEAv409h0+DIMX2CbNy2dUUdNb6lsrGU+WdWvdIbDtXx GMos+DElEPpwPkv3Q6B5y14le59riVf+Oay68xyNwOs1dTEr/pz64DAxVwnoWqUhDRK1 nfZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=hR9QQZXebo7rsY4mPHlA+gQwr4b9NcjtBcCBgUSfP9Q=; b=Zg/nFIGDG2rw+uZrA3vIYsPPDf0ynJkXrpR0ghdqAh6F/D/aEdp3GD8o61fSKNZO8S 8MebVJUUiKm6mb9qyok5izWZKRgKqQeOJ7020KN31DiCcwpoL5uF8Bm6wcIKUjgWjzMo Sdg8H0qU+P4rIlxgHKegfkPWQRLEqnhKAWyFBaNreHnItFPksiBXhlZQAmwLDMYik892 327fPsnDOsEN019HWEWdptBaRE7cwkUcur81X+vBj4bA1An/gkqalMftoGYdae49G2BE zM8dtaafAneh5I2YALNpcKstrwidl+PvXxI1MVHTDDvXLiC+WCefYfOIREWMTfGhaMQ4 CWpg== X-Gm-Message-State: AEkoouv859tcmJ+72YBzwIzpL+QyxVK2Bq7uZ2QEiryHQ79bKLNtmn13RFVO/Fz93IZbpteWPo/TkCjvZUxX9g== X-Received: by 10.13.192.131 with SMTP id b125mr22833984ywd.161.1471977711606; Tue, 23 Aug 2016 11:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.135 with HTTP; Tue, 23 Aug 2016 11:41:51 -0700 (PDT) In-Reply-To: <4DC31048-4D9E-4039-B576-ECDC434A6A1E@dericed.com> References: <4DC31048-4D9E-4039-B576-ECDC434A6A1E@dericed.com> From: Steve Lhomme Date: Tue, 23 Aug 2016 20:41:51 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 18:41:56 -0000 2016-08-23 20:39 GMT+02:00 Dave Rice : > >> On Aug 23, 2016, at 2:35 PM, Steve Lhomme wrote: >> >> I updated the pull request with something that merges with the current m= aster. >> >> Anyone disagree with the move before I merge it ? > > I've been thinking about it and have slowly starting thinking that this i= s a better approach than I first thought. It does deviate from the XML Sche= ma analogy but maybe the complexity of XML Schemas aren't for the best here= . You're right that it would be easier to add extensions (divx) with this a= pproach. It also resolves the issue with xml being normative, since the tex= t and xml versions would be more semantically identical without depending o= n xml nesting. > >> The next steps after that: >> - unflatten the XML definition > > What do you mean? Container of data and attributes representing one or many files. An attached file. Filename of the attached file. MIME type of the file. Modification timestamp of the file. The data of the file. No more hierarchy that could potentially interfere with the one defined in "parent". Also as discussed before elements like Void have no real hierarchy. >> - remove the level altogether, including all text references and in >> the Matroska specs. > > Yes. > Dave > >> 2016-08-05 17:34 GMT+02:00 Steve Lhomme : >>> 2016-08-05 17:26 GMT+02:00 Dave Rice : >>>> >>>>> On Aug 5, 2016, at 11:13 AM, Steve Lhomme wrot= e: >>>>> >>>>> 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >>>>>> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>>>>> >>>>>>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme w= rote: >>>>>>> >>>>>>> As we're moving towards splitting the Matroska specs in many smalle= r >>>>>>> documents, putting not essential things in a document it becomes mo= re >>>>>>> important to define things differently than the "level" element we >>>>>>> currently rely on. It makes it very difficult to define a single >>>>>>> element without having to copy all its parents to explain where it >>>>>>> should go in the EBML format. >>>>>>> >>>>>>> I think we should set the name of the parent(s) explicitely to avoi= d >>>>>>> that confusion. We will also not rely anymore on the order in which >>>>>>> elements are defined in the specs. >>>>>>> >>>>>>> I did a pull request with this addition: >>>>>>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>>>>> >>>>>>> This change will probably mean many paragraphs need to be rewritten= to >>>>>>> rely less on the level system. >>>>>>> >>>>>>> I will do the pull request for Matroska as well once it's settled. >>>>>>> >>>>>>> >>>>>>> Sorry to join this conversation late. I think the current state of = the EBML >>>>>>> implies two different ways of documenting nesting. The EBML Schema = example >>>>>>> simply nests the within one another. For example: >>>>>>> >>>>>>> >>>>>>> >>>>>> maxOccurs=3D=E2=80=9Cunbounded"> >>>>>>> >>>>>> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The nesting of the EBML Schema implies that FileName occurs within = File and >>>>>>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 at= tribute is redundant to >>>>>>> the structure. >>>>>> >>>>>> Yes it's redundant and should probably be removed. It only creates >>>>>> possible issues and gives no extra information. Except when it's 1+ >>>>>> which doesn't have any equivalent in XML and is currently not define= d. >>>>>> >>>>>>> However, later we list out the elements of the EBML Header in a ser= ies of >>>>>>> tables. The tables don=E2=80=99t imply the nested structure as the = xml does, so the >>>>>>> level attribute here is needed, though it is certainly a bit unclea= r since >>>>>>> determining the parent requiring reading backwards to the last mast= er >>>>>>> element of a higher value. >>>>>>> >>>>>>> I prefer to keep the XML analogy where elements are defined in an X= ML schema >>>>>>> where the arrangement of the elements within one another defines th= e nesting >>>>>>> structure. Then since we can compile our documentation the =E2=80= =9CParent=E2=80=9D values >>>>>>> can be decipher from the XML-based EBML Schema. However this gets t= o a >>>>>>> conversation at the CELLAR working group meeting on whether XML sho= uld be >>>>>>> considered normative or not. >>>>>> >>>>>> While I support having an up to date machine readable version of the >>>>>> specs. I don't think it should/will be the actual reference for the >>>>>> specifications. >>>>>> >>>>>> Also the XML parent analogy only works if there's a fixed parent and >>>>>> the element can only be found at that level. How do you define an >>>>>> element that can be found anywhere under /File/Attribute/* (to use t= he >>>>>> path system) (or elements similar to Void and CRC32 which can be >>>>>> defined for a certain DocType) ? Either we add an attibute in the XM= L >>>>>> element or we define how level with a + should be interpreted. Since >>>>>> it's extra information it's probably better to put it out of the lev= el >>>>>> (which should go from the XML anyway). How would you define an eleme= nt >>>>>> that be put anywhere within a DocType in the XML format ? I agree th= at >>>>>> it would be odd to have a "parent" attribute in a non flat XML file. >>>>>> It's also odd to have a "parent" on a flat XML file. >>>>> >>>>> Also there's still the problem how to define a (set of) element(s) >>>>> outside of the core Matroska speficications. >>>> >>>> You mean to define a custom extra section to Matroska? >>> >>> Yes, outside of the original spec. For example if a company does like >>> DivX and creates a set of new elements. We don't want to update the >>> original Matroska specs for that. >>> >>>>> I can't be the core >>>>> specifications including an external file. It should be that external >>>>> (XML) that tells where it should be inserted. Is there a common XML >>>>> mechanism to inject one file into another ? >>>> >>>> Yes, in XML Schema there is a way to define an element to contain xsd:= any meaning that any elements may occur within it. Within that section the = sub-element should ideally have a namespace that points to another XML Sche= ma that defines that particular section. >>>> >>>>> Does it involve defining >>>>> all the elements in the original file to define where we want the >>>>> insertion ? With possible mismatch or missing updates. >>>> >>>> It involves the parent format defining where the flexibility can occur= so that any valid XML is allowed in a defined area and then the contents o= f that optionally being defined by another schema. >>> >>> That does not sound very practical/flexible in our case. Or we'd have >>> to define all Master elements with such a system. And that would have >>> to be done for all EBML-based formats. >>> >>>> dave >>>> >>>>>>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 at= tribute but to allow that >>>>>>> to be implied by the nesting of elements within an EBML Schema. The= n the >>>>>>> parent data could be presented for users when we compile documentat= ion from >>>>>>> the EBML Schema. For instance this markdown is build from the EBML = Schema >>>>>>> and lists parent values derived from the structure of the EBML Sche= ma. >>>>>>> https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>>>>> >>>>>>> Dave Rice >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Steve Lhomme >>>>>> Matroska association Chairman >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Tue Aug 23 12:00:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0A12D97A for ; Tue, 23 Aug 2016 12:00:33 -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 PwWbZcbbTDPj for ; Tue, 23 Aug 2016 12:00:31 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B359F12D809 for ; Tue, 23 Aug 2016 12:00:13 -0700 (PDT) Received: from [146.96.19.240] (port=29613 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bcGvh-002DNq-ES; Tue, 23 Aug 2016 15:00:13 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Tue, 23 Aug 2016 15:00:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7208DD13-54A2-4C49-AF09-26A6E52C74A9@dericed.com> References: <4DC31048-4D9E-4039-B576-ECDC434A6A1E@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Element Parenting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:00:34 -0000 > On Aug 23, 2016, at 2:41 PM, Steve Lhomme = wrote: >=20 > 2016-08-23 20:39 GMT+02:00 Dave Rice : >>=20 >>> On Aug 23, 2016, at 2:35 PM, Steve Lhomme = wrote: >>>=20 >>> I updated the pull request with something that merges with the = current master. >>>=20 >>> Anyone disagree with the move before I merge it ? >>=20 >> I've been thinking about it and have slowly starting thinking that = this is a better approach than I first thought. It does deviate from the = XML Schema analogy but maybe the complexity of XML Schemas aren't for = the best here. You're right that it would be easier to add extensions = (divx) with this approach. It also resolves the issue with xml being = normative, since the text and xml versions would be more semantically = identical without depending on xml nesting. >>=20 >>> The next steps after that: >>> - unflatten the XML definition >>=20 >> What do you mean? >=20 > > > > Container of data and > attributes representing one or many files. > > maxOccurs=3D"unbounded"> > An attached = file. > > minOccurs=3D"1"> > Filename of the = attached > file. > > minOccurs=3D"1"> > MIME type of the > file. > > type=3D"date" minOccurs=3D"1"> > Modification timestamp = of > the file. > > minOccurs=3D"1"> > The data of the > file. > > Ah, I would have considered that action as 'flattening', but I support = the example that we'll use parent rather than nested elements. > No more hierarchy that could potentially interfere with the one > defined in "parent". Also as discussed before elements like Void have > no real hierarchy. +1 Dave >>> - remove the level altogether, including all text references and in >>> the Matroska specs. >>=20 >> Yes. >> Dave >>=20 >>> 2016-08-05 17:34 GMT+02:00 Steve Lhomme : >>>> 2016-08-05 17:26 GMT+02:00 Dave Rice : >>>>>=20 >>>>>> On Aug 5, 2016, at 11:13 AM, Steve Lhomme = wrote: >>>>>>=20 >>>>>> 2016-08-05 17:09 GMT+02:00 Steve Lhomme : >>>>>>> 2016-08-02 2:50 GMT+02:00 Dave Rice : >>>>>>>>=20 >>>>>>>> On Jul 31, 2016, at 11:41 AM, Steve Lhomme = wrote: >>>>>>>>=20 >>>>>>>> As we're moving towards splitting the Matroska specs in many = smaller >>>>>>>> documents, putting not essential things in a document it = becomes more >>>>>>>> important to define things differently than the "level" element = we >>>>>>>> currently rely on. It makes it very difficult to define a = single >>>>>>>> element without having to copy all its parents to explain where = it >>>>>>>> should go in the EBML format. >>>>>>>>=20 >>>>>>>> I think we should set the name of the parent(s) explicitely to = avoid >>>>>>>> that confusion. We will also not rely anymore on the order in = which >>>>>>>> elements are defined in the specs. >>>>>>>>=20 >>>>>>>> I did a pull request with this addition: >>>>>>>> https://github.com/Matroska-Org/ebml-specification/pull/83 >>>>>>>>=20 >>>>>>>> This change will probably mean many paragraphs need to be = rewritten to >>>>>>>> rely less on the level system. >>>>>>>>=20 >>>>>>>> I will do the pull request for Matroska as well once it's = settled. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Sorry to join this conversation late. I think the current state = of the EBML >>>>>>>> implies two different ways of documenting nesting. The EBML = Schema example >>>>>>>> simply nests the within one another. For example: >>>>>>>>=20 >>>>>>>> >>>>>>>> >>>>>>> maxOccurs=3D=E2=80=9Cunbounded"> >>>>>>>> >>>>>>> minOccurs=3D=E2=80=9C1=E2=80=9D/> >>>>>>>> >>>>>>>> >>>>>>>>=20 >>>>>>>> The nesting of the EBML Schema implies that FileName occurs = within File and >>>>>>>> File occurs within Files. The use of the =E2=80=98level=E2=80=99 = attribute is redundant to >>>>>>>> the structure. >>>>>>>=20 >>>>>>> Yes it's redundant and should probably be removed. It only = creates >>>>>>> possible issues and gives no extra information. Except when it's = 1+ >>>>>>> which doesn't have any equivalent in XML and is currently not = defined. >>>>>>>=20 >>>>>>>> However, later we list out the elements of the EBML Header in a = series of >>>>>>>> tables. The tables don=E2=80=99t imply the nested structure as = the xml does, so the >>>>>>>> level attribute here is needed, though it is certainly a bit = unclear since >>>>>>>> determining the parent requiring reading backwards to the last = master >>>>>>>> element of a higher value. >>>>>>>>=20 >>>>>>>> I prefer to keep the XML analogy where elements are defined in = an XML schema >>>>>>>> where the arrangement of the elements within one another = defines the nesting >>>>>>>> structure. Then since we can compile our documentation the = =E2=80=9CParent=E2=80=9D values >>>>>>>> can be decipher from the XML-based EBML Schema. However this = gets to a >>>>>>>> conversation at the CELLAR working group meeting on whether XML = should be >>>>>>>> considered normative or not. >>>>>>>=20 >>>>>>> While I support having an up to date machine readable version of = the >>>>>>> specs. I don't think it should/will be the actual reference for = the >>>>>>> specifications. >>>>>>>=20 >>>>>>> Also the XML parent analogy only works if there's a fixed parent = and >>>>>>> the element can only be found at that level. How do you define = an >>>>>>> element that can be found anywhere under /File/Attribute/* (to = use the >>>>>>> path system) (or elements similar to Void and CRC32 which can be >>>>>>> defined for a certain DocType) ? Either we add an attibute in = the XML >>>>>>> element or we define how level with a + should be interpreted. = Since >>>>>>> it's extra information it's probably better to put it out of the = level >>>>>>> (which should go from the XML anyway). How would you define an = element >>>>>>> that be put anywhere within a DocType in the XML format ? I = agree that >>>>>>> it would be odd to have a "parent" attribute in a non flat XML = file. >>>>>>> It's also odd to have a "parent" on a flat XML file. >>>>>>=20 >>>>>> Also there's still the problem how to define a (set of) = element(s) >>>>>> outside of the core Matroska speficications. >>>>>=20 >>>>> You mean to define a custom extra section to Matroska? >>>>=20 >>>> Yes, outside of the original spec. For example if a company does = like >>>> DivX and creates a set of new elements. We don't want to update the >>>> original Matroska specs for that. >>>>=20 >>>>>> I can't be the core >>>>>> specifications including an external file. It should be that = external >>>>>> (XML) that tells where it should be inserted. Is there a common = XML >>>>>> mechanism to inject one file into another ? >>>>>=20 >>>>> Yes, in XML Schema there is a way to define an element to contain = xsd:any meaning that any elements may occur within it. Within that = section the sub-element should ideally have a namespace that points to = another XML Schema that defines that particular section. >>>>>=20 >>>>>> Does it involve defining >>>>>> all the elements in the original file to define where we want the >>>>>> insertion ? With possible mismatch or missing updates. >>>>>=20 >>>>> It involves the parent format defining where the flexibility can = occur so that any valid XML is allowed in a defined area and then the = contents of that optionally being defined by another schema. >>>>=20 >>>> That does not sound very practical/flexible in our case. Or we'd = have >>>> to define all Master elements with such a system. And that would = have >>>> to be done for all EBML-based formats. >>>>=20 >>>>> dave >>>>>=20 >>>>>>>> So I think I would prefer not to have a =E2=80=98parent=E2=80=99 = attribute but to allow that >>>>>>>> to be implied by the nesting of elements within an EBML Schema. = Then the >>>>>>>> parent data could be presented for users when we compile = documentation from >>>>>>>> the EBML Schema. For instance this markdown is build from the = EBML Schema >>>>>>>> and lists parent values derived from the structure of the EBML = Schema. >>>>>>>> = https://gist.github.com/dericed/dd1710e47dd3b6779463a85e4fc0f788 >>>>>>>>=20 >>>>>>>> Dave Rice >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Steve Lhomme >>>>>>> Matroska association Chairman >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Steve Lhomme >>>>>> Matroska association Chairman >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Cellar mailing list >>>>>> Cellar@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cellar >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Steve Lhomme >>>> Matroska association Chairman >>>=20 >>>=20 >>>=20 >>> -- >>> Steve Lhomme >>> Matroska association Chairman >>>=20 >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Mon Aug 29 00:08:21 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9C12D09E for ; Mon, 29 Aug 2016 00:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.992 X-Spam-Level: * X-Spam-Status: No, score=1.992 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLACK=1.7] 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 kN1xgKEpUIqS for ; Mon, 29 Aug 2016 00:08:17 -0700 (PDT) Received: from p1002.netstorage.at (unknown [IPv6:2a02:2410:b000:101:3000::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B06B127071 for ; Mon, 29 Aug 2016 00:08:16 -0700 (PDT) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 81AF082AA5 for ; Mon, 29 Aug 2016 09:08:13 +0200 (CEST) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix ; Mon, 29 Aug 2016 09:08:13 +0200 To: cellar@ietf.org References: <570C0878-417C-4B5E-AFE2-89D8875FE140@dericed.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <7448040d-dd6f-59c0-d16c-c0c199f56a84@noa-archive.com> Date: Mon, 29 Aug 2016 09:08:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20160829070813.7870.54104@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Matroska's default codecs X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 07:08:19 -0000 On 21.08.2016 22:36, Kieran O Leary wrote: > Hi > > On 21 Aug 2016 8:47 p.m., "Dave Rice" >> >> If the CELLAR community wanted to integrate a proposed encoding for a > particular purpose (archiving, transmission, etc), I suggest that this > would be done by defining a ‘target’ in ffmpeg rather than modifying its > default behavior. For instance see how vcd and dvd are defined in the > opt_target function > at https://github.com/FFmpeg/FFmpeg/blob/61da882cea4579658e8d01e24b8cb71c98df2b94/ffmpeg_opt.c#L2550-L2691. > Feasibly we could propose a target that combines suggested options for > archiving: -slicecrc 1 -level 3 -c:v ffv1, etc. >> > > +1 > I think this is a great idea. Perhaps another way of doing it could be > a profile for ffv1, kind of like `-profile:v archive`, or something like > that. There is a similar feature already existing in FFmpeg: http://ffmpeg.org/ffmpeg-all.html#Preset-files For example by putting the following lines into a file named "ffv1l3.ffpreset": vcodec=ffv1 g=1 level=3 slices=16 slicecrc=1 one can use it by adding "-pre ffv1l3" to the command line. Regards, Tobias From nobody Tue Aug 30 09:40:50 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890F12D1A6 for ; Tue, 30 Aug 2016 09:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9-QnQ8oTtl1 for ; Tue, 30 Aug 2016 09:40:32 -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 041A212D1A5 for ; Tue, 30 Aug 2016 09:40:32 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id n75so48029515ith.0 for ; Tue, 30 Aug 2016 09:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=U+xlBWUuk6w0KRDl4yYNXXWwvGdvH9BqJbJxDyxO+qA=; b=A5JZO904iQgvtrFsjbNRxGx183lizJm87s6x6+KbIq25gqVEdEQMaUJ9fNPxJg5n/e aDXkxjl1lgNkeqvZnvXTdFHtvmxicHWH4W1vklD+lsDXEUethxQPSlpk9ySAWMnUK9Am mEC7SVS8uhEmleCMp9opUSvTcdb95ruX0gvSyqwvj7WRAqfULL15Y94i2ftl2jkXvPFi zCovt/TTkhtsTEtuSM1OcihhTHGToVUf06mUoGi5Z0i1sXMyaGvxsUiW8WYz6i5CCA/m peteo2KNsD2ORKPabGNTdFS0KjShvhY0RWr12e7R+EkhzVVc849ePpmBxy7jQFOh7AXI rqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U+xlBWUuk6w0KRDl4yYNXXWwvGdvH9BqJbJxDyxO+qA=; b=nI2Fi4ND9GXJDPdD08g5uVg5EB88sKEutQWH8O7j1Y7GZsFg+oBtKx/lo8t0mWGl7s eaQVNUgkdgHhx5njm+mlrlBLD3wXLhp9JgNMHh3YZUsZ0gR0rjB9KnvFPcKOYMCbzYj0 Oz1GqhPbNZttXsKdq51u4W67/yCU1sBfw8ewdI1cydV9epGW/igzUe6aMYmZyNeJIC4U oyzj/h4W7Naon+sM+MqfkA1jUFJsUI30RIWTedSL6CXEQAH6eTeqWAsUwBVcjrS6Ng+d AbhTtbWM40VRW9/N8kVZNctr86TbiL5JglAG78aQPa1t/w8tFi9Zd0Nl5538U/iqH4Nv oaTw== X-Gm-Message-State: AE9vXwMjDucomFQELZNwntN835ufUnS5QiTMlUbvISdRhY1xWW1vmZhPbR/CSNZu6Bp3kGD/BGbZ6KMgA64eKWdN X-Received: by 10.36.88.131 with SMTP id f125mr6015484itb.46.1472575230828; Tue, 30 Aug 2016 09:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.139.197 with HTTP; Tue, 30 Aug 2016 09:40:10 -0700 (PDT) From: Michael Bradshaw Date: Tue, 30 Aug 2016 09:40:10 -0700 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a1144477a8a77f6053b4ca37a Archived-At: Subject: [Cellar] 360/VR videos in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 16:40:35 -0000 --001a1144477a8a77f6053b4ca37a Content-Type: text/plain; charset=UTF-8 Matroska currently doesn't have a way to specify projection information for 360/VR videos. Google's Spherical Video V2 RFC draft was just updated a few days ago to include some new elements specifying projection and viewer pose information[1]. These proposed elements haven't made their way over to the WebM specification (and I haven't asked the WebM team if they intend to incorporate them), but I think it raises a good question about Matroska support for these kinds of things. I don't know of any past work in specifying projection information in Matroska. Assuming there hasn't been any, is there interest in adding it (I'm assuming the answer is still yes, from those I asked in Berlin)? Do the elements from the Spherical Video V2 RFC draft look like good candidates? (For the record, I'm just breaking the ice here and getting the conversation started; this isn't a proposal to adopt the new elements just quite yet) [1]: https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#webm-matroska --001a1144477a8a77f6053b4ca37a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Matroska currently doesn't have a way to specify proje= ction information for 360/VR videos. Google's=C2=A0Spherical Video V2 R= FC draft was just updated a few days ago to include some new elements speci= fying projection and viewer pose information[1].

These p= roposed elements haven't made their way over to the WebM specification = (and I haven't asked the WebM team if they intend to incorporate them),= but I think it raises a good question about Matroska support for these kin= ds of things.

I don't know of any past work in= specifying projection information in Matroska. Assuming there hasn't b= een any, is there interest in adding it (I'm assuming the answer is sti= ll yes, from those I asked in Berlin)? Do the elements from the=C2=A0Spheri= cal Video V2 RFC draft look like good candidates?

= (For the record, I'm just breaking the ice here and getting the convers= ation started; this isn't a proposal to adopt the new elements just qui= te yet)

--001a1144477a8a77f6053b4ca37a-- From nobody Tue Aug 30 09:56:20 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B812D613 for ; Tue, 30 Aug 2016 09:56:18 -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, HTML_MESSAGE=0.001, 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 PZGL5hgALcdx for ; Tue, 30 Aug 2016 09:56:16 -0700 (PDT) Received: from 16.mo7.mail-out.ovh.net (16.mo7.mail-out.ovh.net [46.105.72.216]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8880212D529 for ; Tue, 30 Aug 2016 09:56:14 -0700 (PDT) Received: from player787.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id DF06B1000373 for ; Tue, 30 Aug 2016 18:56:08 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4AF5.dip0.t-ipconnect.de [93.219.74.245]) (Authenticated sender: jerome@francoallemand.eu) by player787.ha.ovh.net (Postfix) with ESMTPSA id 9CA9F600082 for ; Tue, 30 Aug 2016 18:56:08 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <97746b11-dff8-cbbc-2d75-c900b2057791@mediaarea.net> Date: Tue, 30 Aug 2016 18:56:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------84F3FC1020DD15FF52633F17" X-Ovh-Tracer-Id: 13450000288186699921 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeluddrgeeigddutdeiucdltddurdefledtrddttddmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] 360/VR videos in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 16:56:19 -0000 This is a multi-part message in MIME format. --------------84F3FC1020DD15FF52633F17 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 30/08/2016 à 18:40, Michael Bradshaw a écrit : > Matroska currently doesn't have a way to specify projection > information for 360/VR videos. Google's Spherical Video V2 RFC draft > was just updated a few days ago to include some new elements > specifying projection and viewer pose information[1]. > > These proposed elements haven't made their way over to the WebM > specification (and I haven't asked the WebM team if they intend to > incorporate them), but I think it raises a good question about > Matroska support for these kinds of things. > > I don't know of any past work in specifying projection information in > Matroska. Assuming there hasn't been any, is there interest in adding > it (I'm assuming the answer is still yes, from those I asked in Berlin)? Still yes on my side. > Do the elements from the Spherical Video V2 RFC draft look like good > candidates? As Google did a lot of work already and have it in production, I am actually in favor of adopting the elements if there is no issue (e.g. no conflict with Matroska specs) after some review (and after Google puts it in WebM specs). > > (For the record, I'm just breaking the ice here and getting the > conversation started; this isn't a proposal to adopt the new elements > just quite yet) > > [1]: > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#webm-matroska > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------84F3FC1020DD15FF52633F17 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 30/08/2016 à 18:40, Michael Bradshaw a écrit :
Matroska currently doesn't have a way to specify projection information for 360/VR videos. Google's Spherical Video V2 RFC draft was just updated a few days ago to include some new elements specifying projection and viewer pose information[1].

These proposed elements haven't made their way over to the WebM specification (and I haven't asked the WebM team if they intend to incorporate them), but I think it raises a good question about Matroska support for these kinds of things.

I don't know of any past work in specifying projection information in Matroska. Assuming there hasn't been any, is there interest in adding it (I'm assuming the answer is still yes, from those I asked in Berlin)?

Still yes on my side.

Do the elements from the Spherical Video V2 RFC draft look like good candidates?

As Google did a lot of work already and have it in production, I am actually in favor of adopting the elements if there is no issue (e.g. no conflict with Matroska specs) after some review (and after Google puts it in WebM specs).


(For the record, I'm just breaking the ice here and getting the conversation started; this isn't a proposal to adopt the new elements just quite yet)



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


--------------84F3FC1020DD15FF52633F17-- From nobody Tue Aug 30 10:48:29 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699C112D74C for ; Tue, 30 Aug 2016 10:48:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 1afcdAYrYKhr for ; Tue, 30 Aug 2016 10:48:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3201D12D748 for ; Tue, 30 Aug 2016 10:48:26 -0700 (PDT) Received: from [192.168.2.129] ([88.74.118.162]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MLvLE-1bkJSd3rDw-007kC1 for ; Tue, 30 Aug 2016 19:48:24 +0200 To: cellar@ietf.org References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <947bf331-de0c-144e-d33b-1243f629997f@gmx.de> Date: Tue, 30 Aug 2016 19:48:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:W+X3WPxhqouPHFxhFSPPO+PST4hgv2DXM9Oq3ZItWnljGTn0o9A 2XJ0/ATlmxLbe9665LpgmA5HjFF7ZeNMgG7m1N28sxEudIjVwabmCT2BQc9grENudi3Oec6 a6QOtQiXXwUkWydaAPmkqcA4KbNhmCFVVybkG0xVR/FP8y18nOAEfLSeoaNZc6PWxSEskos pazDGpSkPsAveidUAactA== X-UI-Out-Filterresults: notjunk:1;V01:K0:GL8FN8zoUTE=:y5AdPZhN4lPJErcfe8gtoA 3F2t4hmtbTCeBHK/2h60mnXX7V24mn1QNh1Yr5C67UVLtacSDwwO9bG/030J8gRcJBeDk5Syp JVU9Ye0eGB0t0IO4XOU096FDUwclsNLsyHghjEvGIHfq8FiBCWAWJtVPDXm2WertSqypV9+zY x5lF0Cq9DLdkya8Zk5JcSdD+OxDvpiHxMecOI9vdOeIxbUzRAF04sPaKgtT1WhOYE2QbjwgBg rCN2tlyvtepxUmzntEFHNaTWcLARkuqU2WoyKampaj0kdxy8cNrUbxQJlg5BK6r0UJsCLlkoU 21ERd67cnhIpgL81CeoxdoPIAQcE+ptoRREKcmaD3bKrJ8O+IHv210P8a3SGWPrQMv8QsEPIk SLYJtQjGA26hVOjGQh23Qc3+yV+Xy8bTOLyvzsY6ipDGODRjGEmEv0uNhiVrCZ5tVrrrsxoby qDfAysPhY+eWchCOzPDkHXz9VbmCaeSRJ22GzCus3Iz3e3nNq58VtP5rifsd6YaRTfYefetEr aGjOr3BPmvfulCJ6a/QyFNs/WCBLkHI/C5kwE1m8KyrcXUkxA7m+xWjga17IoBPPjCoFLN4kL ZynW+iUO3qSYEHGCM3XUX5RUrGsBX0n/bHPAz+y0vxxdt+UqO+81WMKRiV8QPUdokERTWOhld Fl6Kg3r9KHpMLY/OrLzZ2LBB9C6ntqL0jwVWwKaBmaS2e3NcaDsLNMUAYGILMWZE8foWbGV03 D5HdOzzVaGQq9LVTOdC25fxKOHKFd+lZqFRhl8osWLWHfkriBM3zO5oqBdtT6KqwLp4P+2W+J Qu1z2em Archived-At: Subject: Re: [Cellar] Encryption in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:48:28 -0000 21.07.2016, 15:12 Jerome Martinez: > Le 20/07/2016 à 20:44, Michael Bradshaw a écrit : >> [...] >> >> Personally, I'm in favor of just adopting WebM's encryption >> specification and >> removing the other encryption features of Matroska (assuming no one is >> using them). > > With the same assumption (do we have real file with Matroska > encryption?), I am also in favour of removing old encryption features of > Matroska from the draft for IETF and for only integration of WebM > encryption elements. > > +1 For interoperability and maybe because encryption can still be useful, even though it often has negative effects if DRM is so anti-consumer that its restrictions make legitimate use harder, I an in favor of adopting WebM encryption elements. Best Regards, Sebastian From nobody Tue Aug 30 10:54:19 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD212D753 for ; Tue, 30 Aug 2016 10:54:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 EnNTXFdVrILe for ; Tue, 30 Aug 2016 10:54:16 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B0A912D760 for ; Tue, 30 Aug 2016 10:54:16 -0700 (PDT) Received: from [192.168.2.129] ([88.74.118.162]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MEWxh-1btxfg3QzZ-00Fgjo for ; Tue, 30 Aug 2016 19:54:13 +0200 To: cellar@ietf.org References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <495f4320-1d01-37bd-8ea0-1fa255f683f4@gmx.de> Date: Tue, 30 Aug 2016 19:54:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hvaCxtc4IiEYVj7nUrJpNs9OOyvL4XcsydEdoFYWD4Fy00QoWtf O6JwRfDMeFdwrZVZVd0y1zsD66h6VD9qhixiaXeprrBGqO68LjSzLlfd7EO8YXQw7ldcYAg 2Ld5PfVn+KA88ltZ8ni5jbTutS9HHWjEuSUQ8pWw0XBihPh2Z9sYTD7TxNYhARP73/CDcdW 1Jwv3u7sQyYkK82+L3VXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:4UYQfI8iy88=:QtZZkY02zk3ze5XQcZBovw byGZSwhspGmCthWZ2rnOf8QFj3Gtjd2VcikW2XfhNUltcZYHmBrKBjiBebYws8qnnHCkumdAs p8fIrrDM7ViO/boRok7ukQ85aM2SOg9eRgKKs1FTL+CpBLz1ifX+Wr666g/FGBk5x9GO22Ysh n2PZMI7b+VJ+NNmQY2BZF9Yv21i18hqgU6re+HajadkA0kWScle0tcdCkhrpLs/2cpEauTDst jfEvT8RKLtZdP0AQMjA16TlEpghEp1gaFs0804LMd1mPc/SBzK5Cuojj1H6fPkkyIaMZUrmqs dGCe2NKoyV7MQeyMyz2W8G846KCsVWuWPKR0MRcdzIlCJp0wQt9+3c7KrnMxgbUT59n5Yc7PH z4/0xwERub1p21iy/iIIodbCs2pW6OFBRwuYUXz/slp/r0tLOEzYZM0BpUc57ykFEl9TLHT78 APd2ABnwG1lsXcQvg5sUgv/iGtJaIAgWpgrw/B5UEbSPMBsHyntEiPjuO6fN+NQV2KPP6Xyby P5YJgXbPCcg/LXeUxQHoUeLnEHhntA8CxRQFHVpUJ8IdDPPHXtErVV0mjJXNXn7bwPft39lO9 qR6fJBUVdAe4FgDOfRmSFrCYmuanVKZAi/9kIsZC0YevtQ9bH10vavQ63RwMSQy0p9zjp01in Tv6JQg7IO+zF3hpYkVySwy6hVg8zQSsTzYTyjUwy70+AUDnG1unn6LXYgoxq0/rnRDItpWbI3 CxwP0oUMGVxD9+eckitqj3p0dtXdMH8ulXl5qSCca+OaPiS/uyR7ZEgEgu6SZ4osvUsDFP885 FGVEAK0 Archived-At: Subject: Re: [Cellar] 360/VR videos in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2016 17:54:17 -0000 30.08.2016, 18:40 Michael Bradshaw: > These proposed elements haven't made their way over to the WebM > specification (and I haven't asked the WebM team if they intend to > incorporate them), but I think it raises a good question about Matroska > support for these kinds of things. Whenever those elements make it into WebM, Matroska should support them as well. I'm not sure if 360/VR will turn out to be a big thing (IMHO 3D has not), but for interoperability Matroska should not fall behind. Best Regards, Sebastian From nobody Wed Aug 31 03:13:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0C12DAB6 for ; Wed, 31 Aug 2016 03:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 60EoXTM6o9PY for ; Wed, 31 Aug 2016 03:13:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F84012DAB4 for ; Wed, 31 Aug 2016 03:13:26 -0700 (PDT) Received: from [192.168.178.25] ([91.47.63.210]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MdK8t-1bNEeW47gR-00IY8l for ; Wed, 31 Aug 2016 12:13:24 +0200 To: cellar@ietf.org References: <495f4320-1d01-37bd-8ea0-1fa255f683f4@gmx.de> From: hubblec4 Message-ID: <1beb0dbf-3b98-faaa-b715-bc5ff2d5f173@gmx.ch> Date: Wed, 31 Aug 2016 12:13:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <495f4320-1d01-37bd-8ea0-1fa255f683f4@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ulQrNA59doOFBgv2gC/AdB5yvquahL88LfWbfeXsMU8u7f5/k04 ghAMTgWjlvIZU+79MRaiOHY18meo+GS2qZJHvkmhk2s5GWaeonrL4dEAXFTWRNwtiluRBYf dzzVd5IyCeya44jVyzDPcW9K6Gm4yyuu9ZKzItVvRgQOHpa1GJXsxxFoW44D2ruBcT6t/zB /UtLxMn63Ihovn6OjSVJw== X-UI-Out-Filterresults: notjunk:1;V01:K0:J2x32OnGffw=:0lpKsZjSmxEkBNKAuARCpv nnhlNUDdjbPHk6qmqJM9ROdieW9figG6f5H3UkdRA5jPHcm1eLZorrRu5zOEiUT9OvdOXW/WE FNEYJOMn7KBrnDVS3aSaVcSYxZ9pnarf4DZDQL2HJB4WdlSZ87TfZG2AN45g/9+QLf1Q1dZaM wOLa4Zv1KqhXC+urUWINyXnWVj8saLUQZuOiG7+TGrxvZQkELaeKl0lja97ej3VPLRMyg87up hRqgxcxDtRzzO1b+ovrE473JDLSamWG5B0g/gK3CXGRh7ahNGxo3ZAozdjuukl1QRW5xhz+9c XbP9Vt4VecpS4TZ+NuTt5h8lCf6Z4qsd1ku4CXgxjNHFhLk/k3sYbgYIuwYhUFV1BraOEhmzj dAY6PxfA52V3KpfrkYDYlcORoSZ5DzUnL7Bimbc613qIIjsjdS15HPFyD8Sz3xjx+z+YVpXF5 AOVecxVvwAZb8dELgwD3EPm75aIUSTaGdQHWXu31fC74i32KkgK8gWgosrFTr38aVk3HEEL3A ezZXPtS49bwnzEnho/0X5RbXfYPaMtCykv9Q33gaeRKY7di6v+s9KaJ7pw4Q8skeBz+PBBGxf ETDFoxUwbuFOJy+r56CpsgF7E76Uz4J07QPwa59mTySq2VUtFNW797Cp2p93PK2ZsHEeEV7Ll SzKdWWYcrg1s1pK69lpaQJ+sEE/1D/AQcqsEQ9Ke9RHs6alNMUUYBDIFMxFv6S4ephgl64XHM jUrrBcct/BXNzUS1Ch4r4ogj9TEqYaQsaswdQqNuHWwT+eqjipO3ZvDvAeeEV0F+jASZn/TIQ MkE81S8 Archived-At: Subject: Re: [Cellar] 360/VR videos in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 10:13:29 -0000 Hi all Am 30.08.2016 um 19:54 schrieb Sebastian G. : > 30.08.2016, 18:40 Michael Bradshaw: >> These proposed elements haven't made their way over to the WebM >> specification (and I haven't asked the WebM team if they intend to >> incorporate them), but I think it raises a good question about Matroska >> support for these kinds of things. > Whenever those elements make it into WebM, Matroska should support them > as well. I'm not sure if 360/VR will turn out to be a big thing (IMHO 3D > has not), but for interoperability Matroska should not fall behind. I agree exactly with this. Best Regards Martin > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar