From nobody Sun Oct 2 07:36:40 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 6578912B026 for ; Sun, 2 Oct 2016 07:36:39 -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 ABSMnm6OPaGq for ; Sun, 2 Oct 2016 07:36:37 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 87568127071 for ; Sun, 2 Oct 2016 07:36:37 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u124so2547510ywg.3 for ; Sun, 02 Oct 2016 07:36:37 -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=LxxZp+3CXVHaE+/3vE2Y4SBsOJlsjM4CIUDtTooAKo8=; b=w2uxZxx7cYxTD+1EwBmi5zAg6yNjdbPl1ZIMbHdn9ph5UkuIFaBNSpmzrRSY8yjd2e PSOhsGtejVwEiEHeMlXNRZgiABrTYBVrkKFPWGRsjeaszeO6PnftN4I7SP6+L1viiHRL IFFPHW/9jOAa4eSJ/wqsRQEpNo+0y2SQNNA5bnrjyDhztJbWGBJ2YdwgEJeNT3XFVZ+g OgJH+rmFxvFlIePGnqyEJf4Oluv7276sfa6tQIk8p0our+SUdQY0P1p2xjHtbT9PGb4H Z+1FOmS/gXzDtC6S8jZrr+s/y7CVR7PpXjTNe0SGXjedx99JFoVGWrvk7kfmFAthBc50 lFkw== 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=LxxZp+3CXVHaE+/3vE2Y4SBsOJlsjM4CIUDtTooAKo8=; b=fO+vm2wawXjsuwTueT/xhsYfh/4dvOlhZNSkH6kQzCGAIBxXKLVFIIyehMZjEowSAG J8XlPc9DKGIPoQHDO9WSHX+HT+Hdy0apWMLrc0KsMrtzDlaMcQfvMGYLSfLKAGZAPxSd SlRbvFzHPHckzZ2tmws/3aes6yPzqbGhupxRAG2LZni/60OSgfmthiT7c0sp/0x0IFjf GXPkWDWlZyOtEs8JbnuYDhG9sFg7lGvDhQAb8hBirJx30GmNcHIYPfwYYfIiTE9cqr2W XjcyD33CbgV39sccyZ+Nsk4+6mfp70S29YSYZ+/eUDEOXJRE94RdYBfM/GIHpCDoeY6I IAow== X-Gm-Message-State: AA6/9RlYJoZ04+lpXptd8+Fn7n461iFQjYZ6S8T346JO4qKdKebEl5ky1BzHj7Mg47skCwnxOjIIfiP6iNZEoQ== X-Received: by 10.129.158.12 with SMTP id v12mr3916609ywg.43.1475418996690; Sun, 02 Oct 2016 07:36:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.135 with HTTP; Sun, 2 Oct 2016 07:36:36 -0700 (PDT) In-Reply-To: References: <89CDA2AB-7A2E-4C5A-B85D-165FC33DAB6C@dericed.com> From: Steve Lhomme Date: Sun, 2 Oct 2016 16:36:36 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 02 Oct 2016 14:36:39 -0000 2016-09-25 23:31 GMT+02:00 Dave Rice : > Hi, > > I finished a review of > https://github.com/Matroska-Org/ebml-specification/pull/106 with many > comments there. Overall I like the new version of EBML Path expression ba= sed > on an EBNF-defined convention. > > On Sep 25, 2016, at 2:22 PM, Steve Lhomme wrote: > > Le 25 sept. 2016 18:38, "Dave Rice" a =C3=A9crit : >> >> Hi, >> >> > On Sep 25, 2016, at 11:51, Steve Lhomme wrote: >> > >> > I went ahead and did a new Pull Request with an EBNF based notation to >> > define the path. I merged the minOccurs/maxOccurs as well as it's >> > simple enough to add it to the "regular expression" in a way anyone >> > can understand. Just reading that path line of an element gives you a >> > quick view of where it is found and how often (including recursively). >> > >> > https://github.com/Matroska-Org/ebml-specification/pull/106 >> >> This looks good though I suggest that we have a mechanism to express a >> parent without the full path. In xpath '//' is used in this way. >> >> For instance "//Info/MuxingApp" could mean that MuxingApp could be a Chi= ld >> Element of any Info Element. Subsequently Info could be defined only at >> "/Segment/Info". Through extrapolating one could see that MuxingApp can = only >> be at "/Segment/Info/MuxingApp" without needed the full path. > > We could have something like that but the idea is that part of Matroska o= r > different EBML formats could be defined elsewhere. It's a lot easier to > understand unambiguously if you have the full path. Also if two formats u= se > the same name for different things that becomes a problem. You may also h= ave > math formats using X, Y, Z all over the place. > > Yes but it could cut some of the semantic redundancy. For instance > `Language`, `ChapLanguage`, and `TagLanguage` could be all defined as > documenting the language of their Parent Element=E2=80=99s context. Semantically it's correct. > name=3D=E2=80=9CLanguage=E2=80=9D > path=3D"//TrackEntry/Language|//ChapterDisplay/Language|//SimpleTag/Langu= age=E2=80=9D But they don't use the same EBML ID. This is a possibilty that we could allow in other EBML formats though. > Also in the PR the concepts of minOccur and maxOccur are moved from > attributes into the path expression such as > =E2=80=9C/EBML/EBMLVersion(1,1)=E2=80=9D. This makes it a bit more diffic= ult as one would > now have to parse the XML and then parse the path. Not a blocking issue, = but > for tools that will depend on the EBML Schema, parsing out queries such a= s > =E2=80=98find all mandatory elements=E2=80=99 or =E2=80=98all non-repeati= ng element=E2=80=99 may be more > difficult. Yes, I will bring back the minOccurs/maxOccurs XML attributes. But I think the values should be kept in the path. This is easier to match as a regular expression. Although the occurence is defined with {} in perl (IIRC) and we use () with means grouping in EBNF. > But that should be easy to add an EBMLElementParent in there. > >> > Now after doing that I realized the XML schema wasn't as easy to parse >> > as before. Let me know what you think. We may have the EBNF notation >> > for each element definition in the RFC and the XML definition used >> > different parts of the EBNF definition in various attributes (likely >> > the ones we have before). >> > >> > I struggled a bit to find a way to define the Void properly without >> > making the EBNF syntax too complex. >> > >> > I left out more complex recursive possibilities like /a/b(/c/d)+ for >> > recursion jumping a level. It is not supported by current EBML parsers >> > and was never considered anyway. >> > >> > I used the classic EBNF base with concatenation using the "," characte= r. >> >> Such as "//Tags/SimpleTag,//SimpleTag/SimpleTag"? > > No. "a", "b" equals "ab". > >> Dave >> >> > 2016-09-25 10:58 GMT+02:00 Reto Kromer : >> >> Steve Lhomme wrote: >> >> >> >>> I found the POSIX regex >> >>> https://en.wikipedia.org/wiki/Regular_expression#Standards >> >> >> >> The formal standard is: >> >> >> >> ISO/IEC/IEEE 9945:2009 >> >> Information technology -- Portable Operating System >> >> Interface (POSIX) Base Specifications, Issue 7 >> >> >> >> which contains much more than "just" the regex. >> >> >> >> Best regards, Reto >> >> >> >> >> >> AV Preservation by reto.ch >> >> chemin du Suchet 5 | 1024 Ecublens | Switzerland >> >> Web: https://reto.ch | Twitter: @retoch >> >> >> >> _______________________________________________ >> >> Cellar mailing list >> >> Cellar@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cellar >> > >> > >> > >> > -- >> > Steve Lhomme >> > Matroska association Chairman >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> > > Dave Rice --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 2 09:36: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 67D0312B0B6 for ; Sun, 2 Oct 2016 09:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO1lqslsYdlL for ; Sun, 2 Oct 2016 09:36:30 -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 4E08812B0B0 for ; Sun, 2 Oct 2016 09:36:30 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id v83so41810025ybv.0 for ; Sun, 02 Oct 2016 09:36:30 -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=S0Hq34w72TEPUHPWGrggUX8yEcE37IJjw1iWYPYea0k=; b=IucIj0s0+bFGHmuE/WI2UrRbBRAKC4ynnv5sMYsSFpj/J/icm9kCTqAdNp5+Jwk1Kr W5h8NnWg5AeSlO3pI8u/acNi212pyLJ+HRaB6km0dvhsBnGxnD8DEbdh+vVGFZGveB80 wix8+5iGKqOQ+LQb5qBh67FB2TnsBkEUIfTV37BTV6Dh85laykyVKBlK7UOi7bebst76 TAE03SPfs2BUCGFdqtJttEElaZikck7YBVBoWyg970QxDXjWctLVvIMIUXt1egST2ZHF pEZH4iPu+JWHXA4QWgv6NV/wflAiaUotNUTMyafWQOxfyKHgDq2vcT2qzpeOVkpHlJDE o2Vg== 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=S0Hq34w72TEPUHPWGrggUX8yEcE37IJjw1iWYPYea0k=; b=aBle9V7TEFkNbslEYY6VvaUKfdO3MiRsQE2y3f9e0KdeVK7+Q+xzHazsUAyimnJGPs tqYzslejXt7kI6c0OFO8uPQHwo9j9GPVu9okDZkbdDmDEdY4wqJhcS3Nj0mcUcm238Op FNyBVxv0jVSPRgJsLX+xMJhiZTdUmPZUywi3NCvJh3CsWDR+UVQXIbVXOgKT7cOgfZt7 kFy40Wt0LmWgknldsYbXbsP87PhIYGC9DNrsFoVKeLWKv8Q2JTnPb2wlv7E4EArJAfQv pUPOmjgfMKncioX3bWnfoFK1Nq8QU5z0VPVTO65GC3XRb43j0dI3BAjE5pKouxr9D3gS gL6Q== X-Gm-Message-State: AA6/9Rl5R6O1zGFweTVpYtDh+Nj6+jRZiNrzGdM9VzDKuI2J5MiBxBYnt/dAe3u/7nbUH0XkTpe2xlpm7XiuIQ== X-Received: by 10.37.55.70 with SMTP id e67mr12710811yba.161.1475426189424; Sun, 02 Oct 2016 09:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.20.135 with HTTP; Sun, 2 Oct 2016 09:36:28 -0700 (PDT) In-Reply-To: References: <89CDA2AB-7A2E-4C5A-B85D-165FC33DAB6C@dericed.com> From: Steve Lhomme Date: Sun, 2 Oct 2016 18:36:28 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 02 Oct 2016 16:36:32 -0000 I pushed a new version with the various fixes Dave and Reto requested. On top of that I added a commit that use ABNF/RFC5234 rather than EBNF. CRC-32 and Void could be improved. But what we gain here is a standardized way to define repetition and we get rid of an ISO reference. Because "*" is already used by ABNF I added the "any" keyword which replaces the "*" wildcard. The path delimiter is now "\" not to be confused with the "|" OR operator in ABNF. It's a little harder to read than EBNF but since it's an IETF standard it's probably better to use it anyway. 2016-10-02 16:36 GMT+02:00 Steve Lhomme : > 2016-09-25 23:31 GMT+02:00 Dave Rice : >> Hi, >> >> I finished a review of >> https://github.com/Matroska-Org/ebml-specification/pull/106 with many >> comments there. Overall I like the new version of EBML Path expression b= ased >> on an EBNF-defined convention. >> >> On Sep 25, 2016, at 2:22 PM, Steve Lhomme wrote: >> >> Le 25 sept. 2016 18:38, "Dave Rice" a =C3=A9crit : >>> >>> Hi, >>> >>> > On Sep 25, 2016, at 11:51, Steve Lhomme wrote: >>> > >>> > I went ahead and did a new Pull Request with an EBNF based notation t= o >>> > define the path. I merged the minOccurs/maxOccurs as well as it's >>> > simple enough to add it to the "regular expression" in a way anyone >>> > can understand. Just reading that path line of an element gives you a >>> > quick view of where it is found and how often (including recursively)= . >>> > >>> > https://github.com/Matroska-Org/ebml-specification/pull/106 >>> >>> This looks good though I suggest that we have a mechanism to express a >>> parent without the full path. In xpath '//' is used in this way. >>> >>> For instance "//Info/MuxingApp" could mean that MuxingApp could be a Ch= ild >>> Element of any Info Element. Subsequently Info could be defined only at >>> "/Segment/Info". Through extrapolating one could see that MuxingApp can= only >>> be at "/Segment/Info/MuxingApp" without needed the full path. >> >> We could have something like that but the idea is that part of Matroska = or >> different EBML formats could be defined elsewhere. It's a lot easier to >> understand unambiguously if you have the full path. Also if two formats = use >> the same name for different things that becomes a problem. You may also = have >> math formats using X, Y, Z all over the place. >> >> Yes but it could cut some of the semantic redundancy. For instance >> `Language`, `ChapLanguage`, and `TagLanguage` could be all defined as >> documenting the language of their Parent Element=E2=80=99s context. > > Semantically it's correct. > >> name=3D=E2=80=9CLanguage=E2=80=9D >> path=3D"//TrackEntry/Language|//ChapterDisplay/Language|//SimpleTag/Lang= uage=E2=80=9D > > But they don't use the same EBML ID. > > This is a possibilty that we could allow in other EBML formats though. > >> Also in the PR the concepts of minOccur and maxOccur are moved from >> attributes into the path expression such as >> =E2=80=9C/EBML/EBMLVersion(1,1)=E2=80=9D. This makes it a bit more diffi= cult as one would >> now have to parse the XML and then parse the path. Not a blocking issue,= but >> for tools that will depend on the EBML Schema, parsing out queries such = as >> =E2=80=98find all mandatory elements=E2=80=99 or =E2=80=98all non-repeat= ing element=E2=80=99 may be more >> difficult. > > Yes, I will bring back the minOccurs/maxOccurs XML attributes. But I > think the values should be kept in the path. This is easier to match > as a regular expression. Although the occurence is defined with {} in > perl (IIRC) and we use () with means grouping in EBNF. > >> But that should be easy to add an EBMLElementParent in there. >> >>> > Now after doing that I realized the XML schema wasn't as easy to pars= e >>> > as before. Let me know what you think. We may have the EBNF notation >>> > for each element definition in the RFC and the XML definition used >>> > different parts of the EBNF definition in various attributes (likely >>> > the ones we have before). >>> > >>> > I struggled a bit to find a way to define the Void properly without >>> > making the EBNF syntax too complex. >>> > >>> > I left out more complex recursive possibilities like /a/b(/c/d)+ for >>> > recursion jumping a level. It is not supported by current EBML parser= s >>> > and was never considered anyway. >>> > >>> > I used the classic EBNF base with concatenation using the "," charact= er. >>> >>> Such as "//Tags/SimpleTag,//SimpleTag/SimpleTag"? >> >> No. "a", "b" equals "ab". >> >>> Dave >>> >>> > 2016-09-25 10:58 GMT+02:00 Reto Kromer : >>> >> Steve Lhomme wrote: >>> >> >>> >>> I found the POSIX regex >>> >>> https://en.wikipedia.org/wiki/Regular_expression#Standards >>> >> >>> >> The formal standard is: >>> >> >>> >> ISO/IEC/IEEE 9945:2009 >>> >> Information technology -- Portable Operating System >>> >> Interface (POSIX) Base Specifications, Issue 7 >>> >> >>> >> which contains much more than "just" the regex. >>> >> >>> >> Best regards, Reto >>> >> >>> >> >>> >> AV Preservation by reto.ch >>> >> chemin du Suchet 5 | 1024 Ecublens | Switzerland >>> >> Web: https://reto.ch | Twitter: @retoch >>> >> >>> >> _______________________________________________ >>> >> Cellar mailing list >>> >> Cellar@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/cellar >>> > >>> > >>> > >>> > -- >>> > Steve Lhomme >>> > Matroska association Chairman >>> > >>> > _______________________________________________ >>> > Cellar mailing list >>> > Cellar@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cellar >>> >> >> Dave Rice > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 2 12:18:42 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BF712B069 for ; Sun, 2 Oct 2016 12:18:41 -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 X8YqsEUp7Bhn for ; Sun, 2 Oct 2016 12:18:39 -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 09AD712B060 for ; Sun, 2 Oct 2016 12:18:38 -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 u92JIZEO014890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 2 Oct 2016 21:18:36 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u92JIZ8d061251 for ; Sun, 2 Oct 2016 21:18:35 +0200 Date: Sun, 2 Oct 2016 21:18:35 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] 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: Sun, 02 Oct 2016 19:18:41 -0000 Steve Lhomme wrote: >Yes, I will bring back the minOccurs/maxOccurs XML >attributes. But I think the values should be kept in the >path. This is easier to match as a regular expression. >Although the occurence is defined with {} in perl (IIRC) >and we use () with means grouping in EBNF. +1 From nobody Wed Oct 5 21:19: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 6CE9F12952F for ; Wed, 5 Oct 2016 21:19:22 -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 LvuUsOR5pM63 for ; Wed, 5 Oct 2016 21:19:20 -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 C0864129499 for ; Wed, 5 Oct 2016 21:19:20 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:36131 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bs09O-002QwR-LM; Thu, 06 Oct 2016 00:19:19 -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: Thu, 6 Oct 2016 00:19:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC9B046-EA35-4585-A4A6-B97B42B547A3@dericed.com> References: To: Michael Bradshaw , Steve Lhomme X-Mailer: Apple Mail (2.3124) 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: Codec Encoding for LossLess Archiving and Realtime transmission 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: Thu, 06 Oct 2016 04:19:22 -0000 > On Sep 4, 2016, at 8:46 AM, Steve Lhomme wrote: >=20 > 2016-08-30 18:40 GMT+02:00 Michael Bradshaw : >> 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]. >>=20 >> 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. >>=20 >> 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 >=20 > Since I'm currently adding 360=C2=B0 support in VLC the answer is a > definite YES. So far we only have MP4 sources. For now we only support > some XML embedded in an MP4 UUID XML360 box. The XML is similar to the > one defined here: > = https://github.com/google/spatial-media/blob/master/docs/spherical-video-r= fc.md#user-content-appendix-1---global-metadata-sample >=20 > There's already hardware that saves directly to this format. >=20 >> elements from the Spherical Video V2 RFC draft look like good = candidates? >=20 > It's a good start ;) >=20 > I think the 0.0 default value should be 0x0p+1. >=20 > Also I think the ProjectionType value 0 should be None corresponding > to the current situation when the field doesn't exist. >=20 > Are the Yaw/Pitch/Roll used in practice ?; I also suggest documenting `range` values for Elements where it is = relevant: ProjectionType, ProjectionPoseYaw, ProjectionPosePitch, = ProjectionPoseRoll. Also the options for binary data within = ProjectionPrivate could use references. >> (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) >>=20 >> [1]: >> = https://github.com/google/spatial-media/blob/master/docs/spherical-video-v= 2-rfc.md#webm-matroska >>=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 Wed Oct 5 21:19:43 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 7791012952F for ; Wed, 5 Oct 2016 21:19:41 -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 qVYYFVrK8gMp for ; Wed, 5 Oct 2016 21:19:38 -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 6F22F129531 for ; Wed, 5 Oct 2016 21:19:38 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:36131 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bs09h-002QwR-8b for cellar@ietf.org; Thu, 06 Oct 2016 00:19:38 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <05793BC1-EA9A-4FA1-A75A-A52611648253@dericed.com> Date: Thu, 6 Oct 2016 00:19:36 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Subject: [Cellar] Matroska EncryptedBlock Structure and Virtual Block 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, 06 Oct 2016 04:19:41 -0000 Hi all, What is the status of the Matroska documentation on "EncryptedBlock = Structure=E2=80=9D and =E2=80=9CVirtual Block=E2=80=9D? The section in = the repo has malformed tables [1]. But the corresponding section in the = matroska.org site is greyed out with the =E2=80=9Cversion2=E2=80=9D = class in the HTML. Should these sections be removed or should they be = noted as deprecated to a particular version of Matroska? Dave Rice [1]: = https://github.com/Matroska-Org/matroska-specification/blob/8630510d5977d1= d7d94bc67c32906de6aae5921c/index.md#encryptedblock-structure [2]: = https://www.matroska.org/technical/specs/index.html#encryptedblock_structu= re= From nobody Wed Oct 5 22:22: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 20AF71293F5 for ; Wed, 5 Oct 2016 22:22:07 -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 uURt59Q8mrDW for ; Wed, 5 Oct 2016 22:22:05 -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 BAF41128874 for ; Wed, 5 Oct 2016 22:22:05 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:36131 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bs09v-002QwR-NY for cellar@ietf.org; Thu, 06 Oct 2016 00:19:53 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_F657C64A-6E3E-4EBE-AB45-AB1F4F337E98" Message-Id: <71B14F46-4DBA-4959-B621-338F352B76C5@dericed.com> Date: Thu, 6 Oct 2016 00:19:51 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Subject: [Cellar] presenting Matroska Elements in document sections 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, 06 Oct 2016 05:22:07 -0000 --Apple-Mail=_F657C64A-6E3E-4EBE-AB45-AB1F4F337E98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, The presentation of the Matroska elements in the initial submitted draft = was in odd tables = . = This pull request = adjusts = the conversion of Matroska elements from the ebml_matroska.xml file into = a series of sections that each contain the vocabulary of the EBML Schema = with some additional extrapolated content (listing Child Elements). Here = is a preview of the new output in RFC HTML form = and in markdown form = . Keep = in mind that the past presentation of Matroska Elements was in a shaded = HTML table . The total list of Elements (in the proposed format of sections) accounts = for 7,124 of 11,649 lines (over 60% of a 208 page RFC). Suggestions for adjustments to make the Elements more clearly or = precisely presented? Should an RFC for Matroska include both the EBML Schema of Matroska (a = 713 lines XML document) and the Elements presented in such sections? = Should one of those forms (XML vs Elements sections) be identified as = authoritative over the other? The benefits of using a section per = Element is that is enables better referencing to Element sections within = an RFC. For similar reasons the EBML draft has already had conversion = of many = of its tables to sections. Kind Regards, Dave Rice= --Apple-Mail=_F657C64A-6E3E-4EBE-AB45-AB1F4F337E98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

The= presentation of the Matroska elements in the initial submitted draft = was in odd tables. This pull request adjusts the conversion of Matroska = elements from the ebml_matroska.xml file into a series of sections that = each contain the vocabulary of the EBML Schema with some additional = extrapolated content (listing Child Elements). Here is a preview of the = new output in RFC HTML = form and in markdown form. Keep in mind that the past presentation of = Matroska Elements was in a shaded HTML table.

The total list of Elements (in the = proposed format of sections) accounts for 7,124 of 11,649 lines (over = 60% of a 208 page RFC).

Suggestions for adjustments to make the Elements more clearly = or precisely presented?

Should an RFC for Matroska include both the EBML Schema of = Matroska (a 713 lines XML document) and the Elements presented in such = sections? Should one of those forms (XML vs Elements sections) be = identified as authoritative over the other? The benefits of using a = section per Element is that is enables better referencing to Element = sections within an RFC. For similar reasons the EBML draft has already had conversion of many of its tables to = sections.

Kind = Regards,
Dave Rice
= --Apple-Mail=_F657C64A-6E3E-4EBE-AB45-AB1F4F337E98-- From nobody Thu Oct 6 02:15:16 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3921298D6 for ; Thu, 6 Oct 2016 02:15:15 -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 LyZTipvyXQeq for ; Thu, 6 Oct 2016 02:15:13 -0700 (PDT) Received: from 9.mo1.mail-out.ovh.net (9.mo1.mail-out.ovh.net [178.32.108.172]) (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 5AADB1298A0 for ; Thu, 6 Oct 2016 02:15:10 -0700 (PDT) Received: from player758.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 088AEC94C for ; Thu, 6 Oct 2016 11:15:07 +0200 (CEST) Received: from [192.168.2.101] (p508BA755.dip0.t-ipconnect.de [80.139.167.85]) (Authenticated sender: jerome@francoallemand.eu) by player758.ha.ovh.net (Postfix) with ESMTPSA id D540D2C008F for ; Thu, 6 Oct 2016 11:15:07 +0200 (CEST) To: cellar@ietf.org References: <05793BC1-EA9A-4FA1-A75A-A52611648253@dericed.com> From: Jerome Martinez Message-ID: <61c511fd-cd2e-ee0e-195d-e75aef7e20be@mediaarea.net> Date: Thu, 6 Oct 2016 11:15:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <05793BC1-EA9A-4FA1-A75A-A52611648253@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 1592866895700693137 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelvddrfedvgddutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Matroska EncryptedBlock Structure and Virtual Block 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, 06 Oct 2016 09:15:15 -0000 Le 06/10/2016 à 06:19, Dave Rice a écrit : > What is the status of the Matroska documentation on "EncryptedBlock Structure” and “Virtual Block”? I understood that it is outdated, not really used, and should be removed from the standard > The section in the repo has malformed tables [1]. But the corresponding section in the matroska.org site is greyed out with the “version2” class in the HTML. Should these sections be removed or should they be noted as deprecated to a particular version of Matroska? As this is the first version of the standard, I would say that we don't use yet "deprecated" stuff, we reserve it for elements in the first version of the standard and removed in a later version of the standard. Jérôme From nobody Thu Oct 6 14:10:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7246D1297A6 for ; Thu, 6 Oct 2016 14:10:08 -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 gtgS9hjt2Pts for ; Thu, 6 Oct 2016 14:10:07 -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 1F12E1297A9 for ; Thu, 6 Oct 2016 14:10:07 -0700 (PDT) Received: from [146.96.19.240] (port=51876 helo=[10.10.201.16]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bsFvZ-00281h-16 for cellar@ietf.org; Thu, 06 Oct 2016 17:10:06 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_5E83513B-164E-4879-96F7-C93A33B743A8" Message-Id: <35C4BE67-BBAF-435C-A8C7-56FBA5C6C503@dericed.com> Date: Thu, 6 Oct 2016 17:10:03 -0400 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) 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: Subject: [Cellar] CRC support for Matroska in FFmpeg 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, 06 Oct 2016 21:10:09 -0000 --Apple-Mail=_5E83513B-164E-4879-96F7-C93A33B743A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I wanted to point out that, thanks to James Almer, FFmpeg now supports = writing CRC values into the Top-Level Elements of Matroska as it = "SHOULD". This is good news for the use of Matroska in long-term = preservation as Matroska files written in this way have embedded fixity = on its components from the point when it was first created. http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/thread.html#200586 = = Dave Rice --Apple-Mail=_5E83513B-164E-4879-96F7-C93A33B743A8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi all,

I wanted to point out that, thanks to James Almer, FFmpeg now supports writing CRC values into the Top-Level Elements of Matroska as it "SHOULD". This is good news for the use of Matroska in long-term preservation as Matroska files written in this way have embedded fixity on its components from the point when it was first created.


Dave Rice

--Apple-Mail=_5E83513B-164E-4879-96F7-C93A33B743A8-- From nobody Thu Oct 6 15:06: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 5D79B12949A for ; Thu, 6 Oct 2016 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSHgt-7gmkzM for ; Thu, 6 Oct 2016 15:06:42 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668961294B5 for ; Thu, 6 Oct 2016 15:06:42 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id b201so76510923wmb.0 for ; Thu, 06 Oct 2016 15:06:42 -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=jEaIRtrV2VkSJmx3AQZyhnEsJzmaijbvVSN0kamtmN4=; b=xTKDWVgGDABEFjNNyybP0tXEYUsZ62OCBNBjJvQtWNck7lcD9IfNLIs02j3OcNMdfB BPNd3e9exUziAr1W7I4s/Bq7gZzsn58IdnvjVOJmIX1vWHZ89B9ThuNodA2j0nSslOPe 0+vcyfwNEmJo4bMEYImgwk1cm8hhBs9GiV5Ee2tEjHwFIwm4y9IXRXumwNmrnUl04+d+ mEwnJM2UHcRGgr1R6NbHNN9TAtEVXMLbpHlrKuzBvSiAsT395QZNpxMU7SVcsYiizsbw Oy8SC+/TTlK+Ov0IaBOwirjQMYnDpDLcb4iMbUCEas3ShWF6853mdWFOQyM0GXy1bNMT gxZQ== 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=jEaIRtrV2VkSJmx3AQZyhnEsJzmaijbvVSN0kamtmN4=; b=LLVDiklZYiuCn5m1Mrz/p04mjs9GE8iJp8Pq/6ruPtfGgIGKlCj206wkAEXsCtp+cX trOu0dxJCgfsWQM0R3NYP7/2G4+rxdyb+P6x8Hik+2+ANUJooFmIIBubg77ty53I6whY m8rmzwz5IAdF+fB4ucIkJUYJzxUNt/ObH8X3enxMwK8BH/eNpEr4pmxjFm6IQsMokqL0 iJqlBelvnSRI+I73UuE+vnx4JhFVnOotzzxv23bDtuvErcSWr1583NVmB4dhThzmQAwf 5PCb8bMhGMoEQf92ZGBKek/zsJpZ4J60WK/XL976QEGA+UOPhL7p0SpMdCGdZbhyVn14 ji5g== X-Gm-Message-State: AA6/9Rno+94uwvjuEA9c5ahp40bVJMahtW0P+1X43jPHRX7tXCIzC7LbWfjUVF+rzut5kI6l+ESl7NRlK343Sw== X-Received: by 10.28.125.20 with SMTP id y20mr6346743wmc.22.1475791600735; Thu, 06 Oct 2016 15:06:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.200.232 with HTTP; Thu, 6 Oct 2016 15:06:40 -0700 (PDT) In-Reply-To: <35C4BE67-BBAF-435C-A8C7-56FBA5C6C503@dericed.com> References: <35C4BE67-BBAF-435C-A8C7-56FBA5C6C503@dericed.com> From: Kieran O Leary Date: Thu, 6 Oct 2016 23:06:40 +0100 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a1141d24a1fdbee053e3982a9 Archived-At: Subject: Re: [Cellar] CRC support for Matroska in FFmpeg 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, 06 Oct 2016 22:06:44 -0000 --001a1141d24a1fdbee053e3982a9 Content-Type: text/plain; charset=UTF-8 Hello! On Thu, Oct 6, 2016 at 10:10 PM, Dave Rice wrote: > Hi all, > > I wanted to point out that, thanks to James Almer, FFmpeg now supports > writing CRC values into the Top-Level Elements of Matroska as it "SHOULD". > This is good news for the use of Matroska in long-term preservation as > Matroska files written in this way have embedded fixity on its components > from the point when it was first created. > > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/thread.html#200586 > > Wonderful news, yet another preservation friendly feature. Thanks James Almer! I have a few questions in terms of use: 1. Once commited to git head, are these CRC elements written by default? 2. How does one perform a fixity check, is it by decoding using ffmpeg -i video.mkv -f null - 3. You mention the Top-Level Elements. Are there any aspects of the Matroska container that do not have CRC values? Kindest regards, Kieran. --001a1141d24a1fdbee053e3982a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

On Thu, Oct 6, 2016 at 10:10 PM, Dave Rice <= dave@dericed.com&= gt; wrote:
Hi all,

I wanted to point out that, thanks = to James Almer, FFmpeg now supports writing CRC values into the Top-Level E= lements of Matroska as it "SHOULD". This is good news for the use= of Matroska in long-term preservation as Matroska files written in this wa= y have embedded fixity on its components from the point when it was first c= reated.




=C2=A0Wonderful n= ews, yet another preservation friendly feature. Thanks James Almer!=C2=A0

=C2=A0I have a few questions in terms of use:
=

1. Once commited to git head, are these CRC elements wr= itten by default?

2. How does one perform a fixity= check, is it by decoding using ffmpeg -i video.mkv -f null -=C2=A0

3. You mention the Top-Level Elements. Are there any aspe= cts of the Matroska container that do not have CRC values?

Kindest regards,

Kieran.
--001a1141d24a1fdbee053e3982a9-- From nobody Fri Oct 7 01:57: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 21F72129537 for ; Fri, 7 Oct 2016 01:57:02 -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 zHzx4ww3FydL for ; Fri, 7 Oct 2016 01:56:59 -0700 (PDT) Received: from 17.mo1.mail-out.ovh.net (17.mo1.mail-out.ovh.net [87.98.179.142]) (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 7808B12944D for ; Fri, 7 Oct 2016 01:56:58 -0700 (PDT) Received: from player758.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 1A93512E27 for ; Fri, 7 Oct 2016 10:56:56 +0200 (CEST) Received: from [192.168.2.101] (p508BA755.dip0.t-ipconnect.de [80.139.167.85]) (Authenticated sender: jerome@francoallemand.eu) by player758.ha.ovh.net (Postfix) with ESMTPSA id 9F6B52C0083 for ; Fri, 7 Oct 2016 10:56:56 +0200 (CEST) To: cellar@ietf.org References: <35C4BE67-BBAF-435C-A8C7-56FBA5C6C503@dericed.com> From: Jerome Martinez Message-ID: <59aced5e-e41d-188a-f7f2-227565ba3e75@mediaarea.net> Date: Fri, 7 Oct 2016 10:56:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EF5DF27D6E0D3BDF46E3DB12" X-Ovh-Tracer-Id: 7158471609673519249 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelvddrfeeggddtkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] CRC support for Matroska in FFmpeg 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, 07 Oct 2016 08:57:02 -0000 This is a multi-part message in MIME format. --------------EF5DF27D6E0D3BDF46E3DB12 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 07/10/2016 00:06, Kieran O Leary a crit : > Hello! > > On Thu, Oct 6, 2016 at 10:10 PM, Dave Rice > wrote: > > Hi all, > > I wanted to point out that, thanks to James Almer, FFmpeg now > supports writing CRC values into the Top-Level Elements of > Matroska as it "SHOULD". This is good news for the use of Matroska > in long-term preservation as Matroska files written in this way > have embedded fixity on its components from the point when it was > first created. > > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/thread.html#200586 > > > > > Wonderful news, yet another preservation friendly feature. Thanks > James Almer! > > I have a few questions in terms of use: > > 1. Once commited to git head, are these CRC elements written by default? It is committed, and enabled by default (there is an option for disabling it) > > 2. How does one perform a fixity check, is it by decoding using ffmpeg > -i video.mkv -f null - If I understand well the code, there is only writing support, no check currently on FFmpeg side. You need to use e.g. MediaConch (we already test the CRC and report an error if wrong). I guess we could ask for having automatic test of CRC as it is the case for FFV1. > > 3. You mention the Top-Level Elements. Are there any aspects of the > Matroska container that do not have CRC values? Just to be clear: in the spec, you can choose also to have more precise CRC, i.e. at any level, if you want. It permits to find the source of the error with more precision. So having "only" top-level is good enough (e.g. you have 1 CRC per bunch of frames, in addition to FFV1 CRC per slice). that said, CRC is currently "only" on the Segment element (all elements directly below the Segment element), so the EBML header (few bytes) is not "protected" (it is a "level 0"), as well as the Segment element header. I think that's OK, we can easily detect issues on EBML header and Segment element header without CRC and it is also easily fixable. Jrme --------------EF5DF27D6E0D3BDF46E3DB12 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 07/10/2016 00:06, Kieran O Leary a crit:
Hello!

On Thu, Oct 6, 2016 at 10:10 PM, Dave Rice <dave@dericed.com> wrote:
Hi all,

I wanted to point out that, thanks to James Almer, FFmpeg now supports writing CRC values into the Top-Level Elements of Matroska as it "SHOULD". This is good news for the use of Matroska in long-term preservation as Matroska files written in this way have embedded fixity on its components from the point when it was first created.




Wonderful news, yet another preservation friendly feature. Thanks James Almer!

I have a few questions in terms of use:

1. Once commited to git head, are these CRC elements written by default?

It is committed, and enabled by default (there is an option for disabling it)


2. How does one perform a fixity check, is it by decoding using ffmpeg -i video.mkv -f null -

If I understand well the code, there is only writing support, no check currently on FFmpeg side.
You need to use e.g. MediaConch (we already test the CRC and report an error if wrong).
I guess we could ask for having automatic test of CRC as it is the case for FFV1.


3. You mention the Top-Level Elements. Are there any aspects of the Matroska container that do not have CRC values?

Just to be clear: in the spec, you can choose also to have more precise CRC, i.e. at any level, if you want. It permits to find the source of the error with more precision. So having "only" top-level is good enough (e.g. you have 1 CRC per bunch of frames, in addition to FFV1 CRC per slice).
that said, CRC is currently "only" on the Segment element (all elements directly below the Segment element), so the EBML header (few bytes) is not "protected" (it is a "level 0"), as well as the Segment element header. I think that's OK, we can easily detect issues on EBML header and Segment element header without CRC and it is also easily fixable.

Jrme
--------------EF5DF27D6E0D3BDF46E3DB12-- From nobody Fri Oct 7 06:27:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC501295C3 for ; Fri, 7 Oct 2016 06:27:42 -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 NPvtKsQgpWsZ for ; Fri, 7 Oct 2016 06:27:39 -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 BF858129490 for ; Fri, 7 Oct 2016 06:27:39 -0700 (PDT) Received: from [146.96.19.240] (port=23079 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 1bsVBY-0013hV-Pw; Fri, 07 Oct 2016 09:27:38 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_08343C24-3CFD-4F8F-9AF9-B18A258BAA6F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <59aced5e-e41d-188a-f7f2-227565ba3e75@mediaarea.net> Date: Fri, 7 Oct 2016 09:27:34 -0400 Message-Id: References: <35C4BE67-BBAF-435C-A8C7-56FBA5C6C503@dericed.com> <59aced5e-e41d-188a-f7f2-227565ba3e75@mediaarea.net> To: Jerome Martinez 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] CRC support for Matroska in FFmpeg 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, 07 Oct 2016 13:27:42 -0000 --Apple-Mail=_08343C24-3CFD-4F8F-9AF9-B18A258BAA6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Oct 7, 2016, at 4:56 AM, Jerome Martinez = wrote: >=20 > Le 07/10/2016 =E0 00:06, Kieran O Leary a =E9crit : >> Hello! >>=20 >> On Thu, Oct 6, 2016 at 10:10 PM, Dave Rice > wrote: >> Hi all, >>=20 >> I wanted to point out that, thanks to James Almer, FFmpeg now = supports writing CRC values into the Top-Level Elements of Matroska as = it "SHOULD". This is good news for the use of Matroska in long-term = preservation as Matroska files written in this way have embedded fixity = on its components from the point when it was first created. >>=20 >> = http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/thread.html#200586 = = >>=20 >>=20 >>=20 >> Wonderful news, yet another preservation friendly feature. Thanks = James Almer!=20 >>=20 >> I have a few questions in terms of use: >>=20 >> 1. Once commited to git head, are these CRC elements written by = default? >=20 > It is committed, and enabled by default (there is an option for = disabling it) >=20 >>=20 >> 2. How does one perform a fixity check, is it by decoding using = ffmpeg -i video.mkv -f null -=20 >=20 > If I understand well the code, there is only writing support, no check = currently on FFmpeg side. > You need to use e.g. MediaConch (we already test the CRC and report an = error if wrong). > I guess we could ask for having automatic test of CRC as it is the = case for FFV1. mkvalidator validates embedded CRC values. >> 3. You mention the Top-Level Elements. Are there any aspects of the = Matroska container that do not have CRC values? >=20 > Just to be clear: in the spec, you can choose also to have more = precise CRC, i.e. at any level, if you want. It permits to find the = source of the error with more precision. So having "only" top-level is = good enough (e.g. you have 1 CRC per bunch of frames, in addition to = FFV1 CRC per slice). > that said, CRC is currently "only" on the Segment element (all = elements directly below the Segment element), so the EBML header (few = bytes) is not "protected" (it is a "level 0"), as well as the Segment = element header. I think that's OK, we can easily detect issues on EBML = header and Segment element header without CRC and it is also easily = fixable. There is a sample with a CRC-32 at Level 1 (within the EBML Header) in = https://github.com/Matroska-Org/matroska-test-files. The EBML = specifications going back to Feb. 2003 = have recommended that "All level 1 elements should include a = CRC-32." Dave Rice= --Apple-Mail=_08343C24-3CFD-4F8F-9AF9-B18A258BAA6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 7, 2016, at 4:56 AM, Jerome Martinez <Jerome@MediaArea.net> wrote:

=20 =20
Le 07/10/2016 =E0 00:06, Kieran O = Leary a =E9crit :
Hello!

On Thu, Oct 6, 2016 at 10:10 PM, = Dave Rice <dave@dericed.com> wrote:
Hi all,

I wanted to point out that, thanks to = James Almer, FFmpeg now supports writing CRC values into the Top-Level Elements of Matroska as it "SHOULD". This is good news for the use of Matroska in long-term preservation as Matroska files written in this way have embedded fixity on its components from the point when it was first created.

http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/thread.html#200586



 Wonderful news, yet another = preservation friendly feature. Thanks James Almer! 

 I have a few questions in terms of = use:

1. Once commited to git head, are these CRC = elements written by default?

It is committed, and enabled by default (there is an option for disabling it)


2. How does one perform a fixity check, is = it by decoding using ffmpeg -i video.mkv -f null -
=

If I understand well the code, there is only writing support, no check currently on FFmpeg side.
You need to use e.g. MediaConch (we already test the CRC and report an error if wrong).
I guess we could ask for having automatic test of CRC as it is the case for FFV1.

mkvalidator validates embedded CRC = values.

3. You mention the Top-Level Elements. Are = there any aspects of the Matroska container that do not have CRC values?

Just to be clear: in the spec, you can choose also to have more precise CRC, i.e. at any level, if you want. It permits to find the source of the error with more precision. So having "only" top-level is good enough (e.g. you have 1 CRC per bunch of frames, in addition to FFV1 CRC per slice).
that said, CRC is currently "only" on the Segment element (all elements directly below the Segment element), so the EBML header (few bytes) is not "protected" (it is a "level 0"), as well as the Segment element header. I think that's OK, we can easily detect issues on EBML header and Segment element header without CRC and it is also easily fixable.

There = is a sample with a CRC-32 at Level 1 (within the EBML Header) in https://github.com/Matroska-Org/matroska-test-files. The = EBML specifications going back to Feb. 2003 have recommended that "All = level 1 elements should include a CRC-32."

Dave Rice
= --Apple-Mail=_08343C24-3CFD-4F8F-9AF9-B18A258BAA6F-- From nobody Fri Oct 7 11:52: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 3AE841296D7 for ; Fri, 7 Oct 2016 11:52:50 -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 5xhYNrDUK6Xy for ; Fri, 7 Oct 2016 11:52:49 -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 2A1A3126B6D for ; Fri, 7 Oct 2016 11:52:49 -0700 (PDT) Received: from [146.96.19.240] (port=32698 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bsaGF-003v1p-Ah for cellar@ietf.org; Fri, 07 Oct 2016 14:52:48 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: Date: Fri, 7 Oct 2016 14:52:44 -0400 To: cellar@ietf.org X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:52:50 -0000 Hi all, There's been some offlist discussion about having a meetup in New York = City on cellar issues (quite a few New Yorkers on the list). In general = I think the agenda could be informal but address things like: discussion = of open issues, how to contribute, planning upcoming work, = collaboration. Nick Krabbenhoeft has offered to arrange for a meeting space at New York = Public Library. So some questions for the group: 1. Is such a meeting of interest? 2. Should it occur during an evening or the weekend? An evening may be = easier to local folks to coordinate but would be too late for most = remote participation from Europe. 3. Recommendations for agenda items, things you'd like to learn, things = you'd like to see done? Dave Rice= From nobody Fri Oct 7 12:13: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 EA1AB127735 for ; Fri, 7 Oct 2016 12:13:16 -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 oc3GxWz6nvKh for ; Fri, 7 Oct 2016 12:13:15 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 15449120726 for ; Fri, 7 Oct 2016 12:13:15 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id f193so49802388wmg.0 for ; Fri, 07 Oct 2016 12:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+wy6UE2QMjBhg9rrPqI11cQ5DN0Du5QkHMJohQu4leE=; b=Hz1ygQ7DiWsq29ukuxy+J9sq0r9hegEUNnTmfeui4+LHraA4OI5lEh9KX5/fApmGOM ue4YP77wFuXYNzFBA4Mi5gP5lqWohNbSMY7gU0G5sAzrzDseeHszYPT9oiUaRkKuEpdW 1eQW3zFfaAT3+NYlZl+HzDqAtuuU4skz7Pl943G/GIfLKDZijbnHWajkdULX5iea6goW xd7ftfvNOAgtAXmaz6IjZEskoovUJ70AVY5zvnHsbUFJlwBDg4P6jkLKaYDFq2X1+fEr BhXioikkIezAyPmDF54Sk0QzES9IXsRKUQKHn13RjtrX2H5caCR3BEpHAZzUNSAiqHLS qPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+wy6UE2QMjBhg9rrPqI11cQ5DN0Du5QkHMJohQu4leE=; b=jCnxWVHvsPHQO4nnMBEZ1CeedgtodSB+/FTeyiEA77C3VC1ZCjAqdTNislBIaSrp3u w5pxymXhCjYJYykENqozEYT+QQFeOxmdb08QBNmyG2PjFIgtvqH8541fpIX9lJgw0NFz BxWYHUxVLUVLzwwrNG63c8mTlz2j/TWHS38vT5ZQXnj5Tzdp16UbDn/Smk29RDMJtKm5 h37ecnVPAQDBKaXWoDuubVcIF1o5gX7IId+jK4X0Hjg4Vlb10f6fO45VrrVTLdURXdEA DTXHGzDVKjMqaXIFTQ1i7wqpUdsVbj7+zDEqi07waT8ZyM5WIwyA8zGK/xHEWKL5EIVh CtPA== X-Gm-Message-State: AA6/9RmAcu8udt+Q3wRN596yPbSt+DWqLVdcyWzHqYdBomxeniz4RO/K8xN+K9gsRHdnNg== X-Received: by 10.194.233.102 with SMTP id tv6mr17402459wjc.35.1475867593223; Fri, 07 Oct 2016 12:13:13 -0700 (PDT) Received: from [192.168.1.25] (ANice-653-1-3-127.w86-219.abo.wanadoo.fr. [86.219.101.127]) by smtp.gmail.com with ESMTPSA id y39sm4317203wmh.21.2016.10.07.12.13.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Oct 2016 12:13:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: ashley.blewer@gmail.com X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Fri, 7 Oct 2016 21:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F6847D7-29E2-42F5-BFB0-F90979569BBE@gmail.com> References: To: Dave Rice Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:13:17 -0000 > On Oct 7, 2016, at 8:52 PM, Dave Rice wrote: >=20 > Hi all, >=20 > There's been some offlist discussion about having a meetup in New York Cit= y on cellar issues (quite a few New Yorkers on the list). In general I think= the agenda could be informal but address things like: discussion of open is= sues, how to contribute, planning upcoming work, collaboration. >=20 > Nick Krabbenhoeft has offered to arrange for a meeting space at New York P= ublic Library. >=20 > So some questions for the group: >=20 > 1. Is such a meeting of interest? >=20 Yes! > 2. Should it occur during an evening or the weekend? An evening may be eas= ier to local folks to coordinate but would be too late for most remote parti= cipation from Europe. >=20 Also prefer evenings but more so prefer potential Euro participation!=20 > 3. Recommendations for agenda items, things you'd like to learn, things yo= u'd like to see done? FLAC attack.=20 > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Oct 7 12:16: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 940971296DC for ; Fri, 7 Oct 2016 12:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.897 X-Spam-Level: X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, 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 Tj7pUhWql0_w for ; Fri, 7 Oct 2016 12:16:42 -0700 (PDT) Received: from pps02c.loc.gov (pps02c.loc.gov [140.147.239.49]) (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 C77BA1296D2 for ; Fri, 7 Oct 2016 12:16:42 -0700 (PDT) Received: from pps.filterd (pps02c.loc.gov [127.0.0.1]) by pps02c.loc.gov (8.15.0.59/8.15.0.59) with SMTP id u97J8Pap020135 for ; Fri, 7 Oct 2016 15:16:41 -0400 Received: from mail2.loc.gov (lcxhub02.loc.gov [140.147.241.33]) by pps02c.loc.gov with ESMTP id 25uycqcsce-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 07 Oct 2016 15:16:41 -0400 Received: from LCXCLMB01.LCDS.LOC.GOV ([::1]) by LCXHUB02.LCDS.LOC.GOV ([::1]) with mapi; Fri, 7 Oct 2016 15:16:30 -0400 From: "Murray, Kate" To: "'cellar@ietf.org'" Date: Fri, 7 Oct 2016 15:16:30 -0400 Thread-Topic: [Cellar] NYC cellar meetup? Thread-Index: AdIgzYFpxeMev+3yROCvQn5p9RTDPgAAaDLQ Message-ID: <7CC4AB09C979C242B5E468C64182DD44010E24418583@LCXCLMB01.LCDS.LOC.GOV> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5800 definitions=8311 signatures=670726 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610070328 Archived-At: Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 19:16:44 -0000 Thanks for this Dave. I'm game to (virtually) meet up with other interested= folks if scheduling permits.=20 Best from Kate ********** Kate Murray Technology Policy Directorate Library of Congress 202-707-4894 kmur@loc.gov -----Original Message----- From: Dave Rice [mailto:dave@dericed.com]=20 Sent: Friday, October 07, 2016 2:53 PM To: cellar@ietf.org Subject: [Cellar] NYC cellar meetup? Hi all, There's been some offlist discussion about having a meetup in New York City= on cellar issues (quite a few New Yorkers on the list). In general I think= the agenda could be informal but address things like: discussion of open i= ssues, how to contribute, planning upcoming work, collaboration. Nick Krabbenhoeft has offered to arrange for a meeting space at New York Pu= blic Library. So some questions for the group: 1. Is such a meeting of interest? 2. Should it occur during an evening or the weekend? An evening may be easi= er to local folks to coordinate but would be too late for most remote parti= cipation from Europe. 3. Recommendations for agenda items, things you'd like to learn, things you= 'd like to see done? Dave Rice From nobody Fri Oct 7 15:45:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08807129431 for ; Fri, 7 Oct 2016 15:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Un2pv1m_4lCC for ; Fri, 7 Oct 2016 15:45:07 -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 AA1D6129432 for ; Fri, 7 Oct 2016 15:45:07 -0700 (PDT) Received: from localhost ([72.167.218.132]) by p3plwbeout03-03.prod.phx3.secureserver.net with bizsmtp id sml71t0012rz53401ml7q5; Fri, 07 Oct 2016 15:45:07 -0700 X-SID: sml71t0012rz53401 Received: (qmail 12286 invoked by uid 99); 7 Oct 2016 22:45:07 -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.5.1 Message-Id: <20161007154505.665a7a7059d7ee80bb4d670165c8327d.5a76a08d43.wbe@email03.godaddy.com> From: "Doug Ewell" To: cellar@ietf.org Date: Fri, 07 Oct 2016 15:45:05 -0700 Mime-Version: 1.0 Archived-At: Subject: Re: [Cellar] =?utf-8?q?NYC_cellar_meetup=3F?= 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, 07 Oct 2016 22:45:09 -0000 Dave Rice wrote:=0A=0A> Nick Krabbenhoeft has offered to arrange for a meet= ing space at New=0A> York Public Library.=0A=0AThat's rather a distance fro= m Colorado, so rather than making the trek,=0AI'll just repeat my request t= hat BCP 47 be adopted as the=0Alanguage-tagging standard instead of (or at = least in strong preference=0Ato) the existing approach which combines ISO 6= 39-2/B with ccTLDs.=0A =0A--=0ADoug Ewell | Thornton, CO, US | ewellic.org= From nobody Fri Oct 7 22:05:35 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 2AA18129435 for ; Fri, 7 Oct 2016 22:05:34 -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 sXpQiKfoRyXg for ; Fri, 7 Oct 2016 22:05:32 -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 A57A51294E0 for ; Fri, 7 Oct 2016 22:05:31 -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 u9855T3J015730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 8 Oct 2016 07:05:29 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u9855SIL057696 for ; Sat, 8 Oct 2016 07:05:28 +0200 Date: Sat, 8 Oct 2016 07:05:28 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 05:05:34 -0000 Dave Rice wrote: >1. Is such a meeting of interest? Indeed. >2. Should it occur during an evening or the weekend? An >evening may be easier to local folks to coordinate but >would be too late for most remote participation from >Europe. A schedule permitting remote participation from Europe would be ideal. >3. Recommendations for agenda items, things you'd like to >learn, things you'd like to see done? Clear metadata embedding in Matroska, in order to maintain the relevant information about the RGB flavour encoded by =46FV1. This would facilitate the native implementations into the current cutting, grading, restoration, etc. softwares. And, therefore, advocating for adoption. +1 FLAC Best regards, Reto From nobody Sat Oct 8 09:06: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 878B2129471 for ; Sat, 8 Oct 2016 09:06:26 -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 GNzqIclCKeiq for ; Sat, 8 Oct 2016 09:06:24 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769EB129426 for ; Sat, 8 Oct 2016 09:06:24 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id s49so33057047qta.0 for ; Sat, 08 Oct 2016 09:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=SYqpzK0z05IYS8ZtpLvUAKxPQpM1nEokEDT8E6yxT/E=; b=lRmmh5L5qpj6JLcPxB53xz1grtq1E5ROPyKBTOvqxOnv8BOk2u8SatNvzaoG35zMgp qnEfqjD2rlnJizBl291GofrUFEilUhywPxc/o64aqeAcSY0rfuNqkaDwl/UrAbqTH08u SO5v5fmbPN7Cb3ns5QoY48LSobCwi+6ucLOTLs8rxrdYAICQr8x4dtaY/dfkSgvWnonk GklDlPZaXTsYFVlaGP925bK2H/Pcl1wXxIfn/94wTB3jT9+DEWDpZcq8d5gt8vKyh2lB cKMZ+YCJQ9SiqHnKtbV4GZnUhQld4vmhtysPKVAtsgr/RGU/krxCYpx+NPT/10KDqdns qNQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SYqpzK0z05IYS8ZtpLvUAKxPQpM1nEokEDT8E6yxT/E=; b=aULKEE03bmZZn99JcSNKOerrI9L4aCoxKLBiD2FrzMULyUTagySorHBUmcJ58nFrZu IhoVqTrYNZu8lVFr3kMjBngW5606Q1aOD1RVu2hravfgksLKQIpCEl4Mikr7Cf912A9F lxfqTxPigH5rChqwIlTi2K78z4RA4+12Hrl478GbjXQzBlruEOJNX1la5qCMF1U7wgOv ixBVQHb9kXgbFmenhAUGrXHwuna2dEwfjjMjeec2syoljl3EfC5zq6homUmS8p69Eauk E43/SqgSBLjyOtvPu2vLF3Zqvf3VXpV3zrIUvlnV+YeYdKZpZwfKIDdTBLMSdY/pNNGX 6cXg== X-Gm-Message-State: AA6/9RnFlmCb53oQqSyiQ+oW8ETsx1qZWO0fNb3jIPEJzHmE1jJiVXROTVtg85APDSryCw== X-Received: by 10.237.37.23 with SMTP id v23mr23242685qtc.110.1475942783415; Sat, 08 Oct 2016 09:06:23 -0700 (PDT) Received: from [30.192.120.240] ([172.56.34.12]) by smtp.gmail.com with ESMTPSA id f56sm4415032qta.26.2016.10.08.09.06.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 08 Oct 2016 09:06:22 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B411) From: Brendan Allen Date: Sat, 8 Oct 2016 12:06:24 -0400 To: Reto Kromer Archived-At: Cc: "cellar@ietf.org" Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 16:06:26 -0000 Hi everyone, I've been lurking on this thread for awhile trying to follow. I'd like to sa= y thanks to all of you for the work you're doing to standardize these format= s. Also, its pretty cool how open, inclusive and transparent this process is= .=20 I live in nyc and could meet-up at the library. My interests are in embedded= metadata and FLAC kind regards, Brendan Allen Sent from my iPhone > On Oct 8, 2016, at 1:05 AM, Reto Kromer wrote: >=20 > Dave Rice wrote: >=20 >> 1. Is such a meeting of interest? >=20 > Indeed. >=20 >> 2. Should it occur during an evening or the weekend? An >> evening may be easier to local folks to coordinate but >> would be too late for most remote participation from >> Europe. >=20 > A schedule permitting remote participation from Europe would > be ideal. >=20 >> 3. Recommendations for agenda items, things you'd like to >> learn, things you'd like to see done? >=20 > Clear metadata embedding in Matroska, in order to maintain > the relevant information about the RGB flavour encoded by > FFV1. This would facilitate the native implementations into > the current cutting, grading, restoration, etc. softwares. > And, therefore, advocating for adoption. >=20 > +1 FLAC >=20 > Best regards, Reto >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sat Oct 8 16:01: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 61477129400 for ; Sat, 8 Oct 2016 16:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYsaryfsUTLg for ; Sat, 8 Oct 2016 16:01:19 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 813D3129423 for ; Sat, 8 Oct 2016 16:01:19 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id n189so71397698qke.0 for ; Sat, 08 Oct 2016 16:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=rDQXRJyUio1YcUurLpUO7P02YC13Iwaw0WHthaKwRH0=; b=wsLnokve7Ru2Gk/iBUSoi4xOT5OqHAS6OeTbcZweVta6ZPuerYuDeeeOARwaX7fAEd wqVyo8k0vSqNTZPJcorKHPqSr2B+U3HYix+HSEZVxgiAzsjqOBkkdQZm64EWIfvkmvc/ AL24/sOrykut5jbK/zys3/6XBN1jxU+KLU20FxaMwiQF3VLtH+eEZl9EKos3Leux1vsj ZrO0DxcVCipkIfN14xk98MhXMaPT6sGouUj5ugiwYMqj4ehiaJQkUr/RrbvpSR6uR0cj T6HZ97StdQBZjMcuBIHxuBXalBvOfCcLMLeZ8UM9J24t7zpxmcH3ob1oKvq3HDf9zCtt tfrQ== 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=rDQXRJyUio1YcUurLpUO7P02YC13Iwaw0WHthaKwRH0=; b=esBWx85SO8jdP3QFmsJZG6YkVG+AEgJp4Z7AHZHOqIG6W+Jpo4ZWWkb6lPbMZsnS7t kXE0b3aZVIjN5k/e2XAX7IJypfH9BJXf3ml/l7tj3ElJOrxQwnaLg5UeDqwdDwnkSl7j 56OecQLRn8nS8DHIycE1qttPMaitKjpRoyeaGK2DevRf/ukI8T1AU3+ZrQ76UqXHpQY/ XGWBKyqBWyScRePExV5t0gp0ib7XEdIKUtKu/ZoS5JMcTLrNF6muHA2+PYT0B/LviCq3 cWLBXKscqyaW6auUdRDxAOl5v/mhvJk3QeX3QkoFhrJLQqB9IVNmMDZcnw77Gn2Aj/xC 55VA== X-Gm-Message-State: AA6/9RmkF5HZtW+v5dsIsFQo3b0HAytvVBoHLycgqVPvYuaPCY2lS2F7sa9kp/cWZJDA8wjvQfHMM1KYSPQoBQ== X-Received: by 10.55.154.11 with SMTP id c11mr24077939qke.25.1475967678277; Sat, 08 Oct 2016 16:01:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.128.2 with HTTP; Sat, 8 Oct 2016 16:01:17 -0700 (PDT) From: Genevieve HK Date: Sat, 8 Oct 2016 19:01:17 -0400 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05418629ed63053e62814e Archived-At: Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 23:01:22 -0000 --94eb2c05418629ed63053e62814e Content-Type: text/plain; charset=UTF-8 1. Yes! 2. weekends are doable 3. +1 metadata (but I generally would just be attending to listen & learn more about *everything*) Thanks for planning this! On Sat, Oct 8, 2016 at 3:00 PM, wrote: > Send Cellar mailing list submissions to > cellar@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/cellar > or, via email, send a message with subject or body 'help' to > cellar-request@ietf.org > > You can reach the person managing the list at > cellar-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cellar digest..." > > Today's Topics: > > 1. Re: NYC cellar meetup? (ashley.blewer@gmail.com) > 2. Re: NYC cellar meetup? (Murray, Kate) > 3. Re: NYC cellar meetup? (Doug Ewell) > 4. Re: NYC cellar meetup? (Reto Kromer) > 5. Re: NYC cellar meetup? (Brendan Allen) > > > ---------- Forwarded message ---------- > From: ashley.blewer@gmail.com > To: Dave Rice > Cc: cellar@ietf.org > Date: Fri, 7 Oct 2016 21:13:10 +0200 > Subject: Re: [Cellar] NYC cellar meetup? > > > > On Oct 7, 2016, at 8:52 PM, Dave Rice wrote: > > > > Hi all, > > > > There's been some offlist discussion about having a meetup in New York > City on cellar issues (quite a few New Yorkers on the list). In general I > think the agenda could be informal but address things like: discussion of > open issues, how to contribute, planning upcoming work, collaboration. > > > > Nick Krabbenhoeft has offered to arrange for a meeting space at New York > Public Library. > > > > So some questions for the group: > > > > 1. Is such a meeting of interest? > > > Yes! > > > 2. Should it occur during an evening or the weekend? An evening may be > easier to local folks to coordinate but would be too late for most remote > participation from Europe. > > > Also prefer evenings but more so prefer potential Euro participation! > > > 3. Recommendations for agenda items, things you'd like to learn, things > you'd like to see done? > > FLAC attack. > > > > Dave Rice > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > ---------- Forwarded message ---------- > From: "Murray, Kate" > To: "'cellar@ietf.org'" > Cc: > Date: Fri, 7 Oct 2016 15:16:30 -0400 > Subject: Re: [Cellar] NYC cellar meetup? > Thanks for this Dave. I'm game to (virtually) meet up with other > interested folks if scheduling permits. > > Best from Kate > ********** > Kate Murray > Technology Policy Directorate > Library of Congress > 202-707-4894 > kmur@loc.gov > > > > -----Original Message----- > From: Dave Rice [mailto:dave@dericed.com] > Sent: Friday, October 07, 2016 2:53 PM > To: cellar@ietf.org > Subject: [Cellar] NYC cellar meetup? > > Hi all, > > There's been some offlist discussion about having a meetup in New York > City on cellar issues (quite a few New Yorkers on the list). In general I > think the agenda could be informal but address things like: discussion of > open issues, how to contribute, planning upcoming work, collaboration. > > Nick Krabbenhoeft has offered to arrange for a meeting space at New York > Public Library. > > So some questions for the group: > > 1. Is such a meeting of interest? > > 2. Should it occur during an evening or the weekend? An evening may be > easier to local folks to coordinate but would be too late for most remote > participation from Europe. > > 3. Recommendations for agenda items, things you'd like to learn, things > you'd like to see done? > > Dave Rice > > > > > ---------- Forwarded message ---------- > From: Doug Ewell > To: cellar@ietf.org > Cc: > Date: Fri, 07 Oct 2016 15:45:05 -0700 > Subject: Re: [Cellar] NYC cellar meetup? > Dave Rice wrote: > > > Nick Krabbenhoeft has offered to arrange for a meeting space at New > > York Public Library. > > That's rather a distance from Colorado, so rather than making the trek, > I'll just repeat my request that BCP 47 be adopted as the > language-tagging standard instead of (or at least in strong preference > to) the existing approach which combines ISO 639-2/B with ccTLDs. > > -- > Doug Ewell | Thornton, CO, US | ewellic.org > > > > ---------- Forwarded message ---------- > From: Reto Kromer > To: cellar@ietf.org > Cc: > Date: Sat, 8 Oct 2016 07:05:28 +0200 > Subject: Re: [Cellar] NYC cellar meetup? > Dave Rice wrote: > > >1. Is such a meeting of interest? > > Indeed. > > >2. Should it occur during an evening or the weekend? An > >evening may be easier to local folks to coordinate but > >would be too late for most remote participation from > >Europe. > > A schedule permitting remote participation from Europe would > be ideal. > > >3. Recommendations for agenda items, things you'd like to > >learn, things you'd like to see done? > > Clear metadata embedding in Matroska, in order to maintain > the relevant information about the RGB flavour encoded by > FFV1. This would facilitate the native implementations into > the current cutting, grading, restoration, etc. softwares. > And, therefore, advocating for adoption. > > +1 FLAC > > Best regards, Reto > > > > > ---------- Forwarded message ---------- > From: Brendan Allen > To: Reto Kromer > Cc: "cellar@ietf.org" > Date: Sat, 8 Oct 2016 12:06:24 -0400 > Subject: Re: [Cellar] NYC cellar meetup? > Hi everyone, > I've been lurking on this thread for awhile trying to follow. I'd like to > say thanks to all of you for the work you're doing to standardize these > formats. Also, its pretty cool how open, inclusive and transparent this > process is. > I live in nyc and could meet-up at the library. My interests are in > embedded metadata and FLAC > > kind regards, > Brendan Allen > > Sent from my iPhone > > > On Oct 8, 2016, at 1:05 AM, Reto Kromer wrote: > > > > Dave Rice wrote: > > > >> 1. Is such a meeting of interest? > > > > Indeed. > > > >> 2. Should it occur during an evening or the weekend? An > >> evening may be easier to local folks to coordinate but > >> would be too late for most remote participation from > >> Europe. > > > > A schedule permitting remote participation from Europe would > > be ideal. > > > >> 3. Recommendations for agenda items, things you'd like to > >> learn, things you'd like to see done? > > > > Clear metadata embedding in Matroska, in order to maintain > > the relevant information about the RGB flavour encoded by > > FFV1. This would facilitate the native implementations into > > the current cutting, grading, restoration, etc. softwares. > > And, therefore, advocating for adoption. > > > > +1 FLAC > > > > Best regards, Reto > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --94eb2c05418629ed63053e62814e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
1. Yes!
2. weekends are doable
3. +1 metadata (but I generally would just be attending to listen &a= mp; learn more about *everything*)

Thanks for planning this! <= br>

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

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

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

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

Today's Topics:

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


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


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

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

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

FLAC attack.


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




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

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



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

Hi all,

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

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

So some questions for the group:

1. Is such a meeting of interest?

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

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

Dave Rice




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

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

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

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



---------- Forwarded message ----------
From:=C2=A0Reto Kromer &= lt;lists@reto.ch>
To:=C2=A0cellar@ietf.org
Cc:=C2=A0
Date:=C2= =A0Sat, 8 Oct 2016 07:05:28 +0200
Subject:=C2=A0Re: [Cellar] NYC cellar= meetup?
Dave Rice wrote:

>1. Is such a meeting of interest?

Indeed.

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

A schedule permitting remote participation from Europe would
be ideal.

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

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

+1 FLAC

Best regards, Reto




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

kind regards,
Brendan Allen

Sent from my iPhone

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



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

--94eb2c05418629ed63053e62814e-- From etg262@nyu.edu Sun Oct 9 06:48: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 315B4129526 for ; Sun, 9 Oct 2016 06:48:54 -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, 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=nyu-edu.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 snNfiR7viUuA for ; Sun, 9 Oct 2016 06:48:51 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49CA129517 for ; Sun, 9 Oct 2016 06:48:50 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id n132so103095319oih.1 for ; Sun, 09 Oct 2016 06:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nyu-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2EcpK43JQ1SDSGyM+RYcpADXXMeOrzo3iivp+xwQQ7o=; b=RjKsw8qR1wiXVzLAGxLSnjM/+BLESwS5Yo2ECyn/npV6ZQL3uKcZKyEIGcI+vE9UOb 8olh3ZDbGG1x9mh7SbJujG5exAPcFnc5reIXN8yZM00SXn/OcKxA1jgU0q1ky+AbbzFF pA5t3RiHvz44aPBoqCHHeR/DpPeosG9JLRpFXlDAJ8BJXxx4dCtZkaOv2gP2k64wUVbH JIPZnYojYcydpGWaQZ6RsM6fnuyjLmWQnT0rohCxNdW0Ierm4Z6L8waCV9zRfHv6KFaU jCawk32sicBzFkBRw9HYAE5EuhQWfJQt94zdKW8b/1FSafcayJ9UfvT03UghqqrRFn2p O2fg== 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=2EcpK43JQ1SDSGyM+RYcpADXXMeOrzo3iivp+xwQQ7o=; b=RmhZQ22a7UPWVURUwjszgKOxf4l7WZGEkavnpnPo9wIOT9iPHVSwigN1EDPJeMyOXT DiAD3nj6D4DPYEFMRhd+wsIKF/g0Xy8N8fBIq1BzBn2mzoUZNCUZEmxtLrqSjSy9PQyR hCNnQqS7+FuKkwPkxbjSs15NEs8XvazJdsc00fibpThjdluywNcuSuYI4UXPBvASyZDx yNNtCIKwcvAkq53zgDQkp6lnjYQrcLOcpCbbQlIeiowbBk8E6JfPpjEJTZK9cEv3+fDy k0F292xgR6qIYLHokOb5++J0w7QkaDYPtbMpCJLCvLfJuDpqrLmdXU9QhPp9hpMlkR1f 0HuA== X-Gm-Message-State: AA6/9RnXWPt01fKp58gboOf6eRiPS64pzCb2s0HI1Gg2jsF2xorwVTA9tCsU607K20jztCTJ7A+/SXZOMD4+RR+D X-Received: by 10.157.34.18 with SMTP id o18mr11200605ota.112.1476020929434; Sun, 09 Oct 2016 06:48:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.91.37 with HTTP; Sun, 9 Oct 2016 06:48:48 -0700 (PDT) In-Reply-To: References: From: Ethan T Gates Date: Sun, 9 Oct 2016 09:48:48 -0400 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a113ad0cc2e2900053e6ee756 Archived-At: Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 13:51:08 -0000 --001a113ad0cc2e2900053e6ee756 Content-Type: text/plain; charset=UTF-8 Hi all, Another novice lurker here - I second Brendan's thanks to you all for both the content and admirable form of this process and Genevieve's desire to observe and soak up as much as I can, as I've been doing by poring over these threads. I would love to attend a NYC meeting, could make weekends work, and might humbly suggest a quick word about how exactly newbies or those without much or any experience with programming or metadata standardization can contribute! (provision of sample files? copy editing documentation?) You all have been doing a stellar job of getting CELLAR's mission out into the wider archival community lately and I think interest in participation is only going to keep growing. Best, Ethan Gates On Sat, Oct 8, 2016 at 7:01 PM, Genevieve HK wrote: > 1. Yes! > 2. weekends are doable > 3. +1 metadata (but I generally would just be attending to listen & learn > more about *everything*) > > Thanks for planning this! > > > On Sat, Oct 8, 2016 at 3:00 PM, wrote: > >> Send Cellar mailing list submissions to >> cellar@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/cellar >> or, via email, send a message with subject or body 'help' to >> cellar-request@ietf.org >> >> You can reach the person managing the list at >> cellar-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Cellar digest..." >> >> Today's Topics: >> >> 1. Re: NYC cellar meetup? (ashley.blewer@gmail.com) >> 2. Re: NYC cellar meetup? (Murray, Kate) >> 3. Re: NYC cellar meetup? (Doug Ewell) >> 4. Re: NYC cellar meetup? (Reto Kromer) >> 5. Re: NYC cellar meetup? (Brendan Allen) >> >> >> ---------- Forwarded message ---------- >> From: ashley.blewer@gmail.com >> To: Dave Rice >> Cc: cellar@ietf.org >> Date: Fri, 7 Oct 2016 21:13:10 +0200 >> Subject: Re: [Cellar] NYC cellar meetup? >> >> >> > On Oct 7, 2016, at 8:52 PM, Dave Rice wrote: >> > >> > Hi all, >> > >> > There's been some offlist discussion about having a meetup in New York >> City on cellar issues (quite a few New Yorkers on the list). In general I >> think the agenda could be informal but address things like: discussion of >> open issues, how to contribute, planning upcoming work, collaboration. >> > >> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >> York Public Library. >> > >> > So some questions for the group: >> > >> > 1. Is such a meeting of interest? >> > >> Yes! >> >> > 2. Should it occur during an evening or the weekend? An evening may be >> easier to local folks to coordinate but would be too late for most remote >> participation from Europe. >> > >> Also prefer evenings but more so prefer potential Euro participation! >> >> > 3. Recommendations for agenda items, things you'd like to learn, things >> you'd like to see done? >> >> FLAC attack. >> >> >> > Dave Rice >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Murray, Kate" >> To: "'cellar@ietf.org'" >> Cc: >> Date: Fri, 7 Oct 2016 15:16:30 -0400 >> Subject: Re: [Cellar] NYC cellar meetup? >> Thanks for this Dave. I'm game to (virtually) meet up with other >> interested folks if scheduling permits. >> >> Best from Kate >> ********** >> Kate Murray >> Technology Policy Directorate >> Library of Congress >> 202-707-4894 >> kmur@loc.gov >> >> >> >> -----Original Message----- >> From: Dave Rice [mailto:dave@dericed.com] >> Sent: Friday, October 07, 2016 2:53 PM >> To: cellar@ietf.org >> Subject: [Cellar] NYC cellar meetup? >> >> Hi all, >> >> There's been some offlist discussion about having a meetup in New York >> City on cellar issues (quite a few New Yorkers on the list). In general I >> think the agenda could be informal but address things like: discussion of >> open issues, how to contribute, planning upcoming work, collaboration. >> >> Nick Krabbenhoeft has offered to arrange for a meeting space at New York >> Public Library. >> >> So some questions for the group: >> >> 1. Is such a meeting of interest? >> >> 2. Should it occur during an evening or the weekend? An evening may be >> easier to local folks to coordinate but would be too late for most remote >> participation from Europe. >> >> 3. Recommendations for agenda items, things you'd like to learn, things >> you'd like to see done? >> >> Dave Rice >> >> >> >> >> ---------- Forwarded message ---------- >> From: Doug Ewell >> To: cellar@ietf.org >> Cc: >> Date: Fri, 07 Oct 2016 15:45:05 -0700 >> Subject: Re: [Cellar] NYC cellar meetup? >> Dave Rice wrote: >> >> > Nick Krabbenhoeft has offered to arrange for a meeting space at New >> > York Public Library. >> >> That's rather a distance from Colorado, so rather than making the trek, >> I'll just repeat my request that BCP 47 be adopted as the >> language-tagging standard instead of (or at least in strong preference >> to) the existing approach which combines ISO 639-2/B with ccTLDs. >> >> -- >> Doug Ewell | Thornton, CO, US | ewellic.org >> >> >> >> ---------- Forwarded message ---------- >> From: Reto Kromer >> To: cellar@ietf.org >> Cc: >> Date: Sat, 8 Oct 2016 07:05:28 +0200 >> Subject: Re: [Cellar] NYC cellar meetup? >> Dave Rice wrote: >> >> >1. Is such a meeting of interest? >> >> Indeed. >> >> >2. Should it occur during an evening or the weekend? An >> >evening may be easier to local folks to coordinate but >> >would be too late for most remote participation from >> >Europe. >> >> A schedule permitting remote participation from Europe would >> be ideal. >> >> >3. Recommendations for agenda items, things you'd like to >> >learn, things you'd like to see done? >> >> Clear metadata embedding in Matroska, in order to maintain >> the relevant information about the RGB flavour encoded by >> FFV1. This would facilitate the native implementations into >> the current cutting, grading, restoration, etc. softwares. >> And, therefore, advocating for adoption. >> >> +1 FLAC >> >> Best regards, Reto >> >> >> >> >> ---------- Forwarded message ---------- >> From: Brendan Allen >> To: Reto Kromer >> Cc: "cellar@ietf.org" >> Date: Sat, 8 Oct 2016 12:06:24 -0400 >> Subject: Re: [Cellar] NYC cellar meetup? >> Hi everyone, >> I've been lurking on this thread for awhile trying to follow. I'd like to >> say thanks to all of you for the work you're doing to standardize these >> formats. Also, its pretty cool how open, inclusive and transparent this >> process is. >> I live in nyc and could meet-up at the library. My interests are in >> embedded metadata and FLAC >> >> kind regards, >> Brendan Allen >> >> Sent from my iPhone >> >> > On Oct 8, 2016, at 1:05 AM, Reto Kromer wrote: >> > >> > Dave Rice wrote: >> > >> >> 1. Is such a meeting of interest? >> > >> > Indeed. >> > >> >> 2. Should it occur during an evening or the weekend? An >> >> evening may be easier to local folks to coordinate but >> >> would be too late for most remote participation from >> >> Europe. >> > >> > A schedule permitting remote participation from Europe would >> > be ideal. >> > >> >> 3. Recommendations for agenda items, things you'd like to >> >> learn, things you'd like to see done? >> > >> > Clear metadata embedding in Matroska, in order to maintain >> > the relevant information about the RGB flavour encoded by >> > FFV1. This would facilitate the native implementations into >> > the current cutting, grading, restoration, etc. softwares. >> > And, therefore, advocating for adoption. >> > >> > +1 FLAC >> > >> > Best regards, Reto >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > -- Ethan Gates Moving Image Archiving and Preservation Technician Department of Cinema Studies, MIAP New York University 665 Broadway, Room 613 New York, NY 10012 212-998-1732 --001a113ad0cc2e2900053e6ee756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

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

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

Thanks for planning thi= s!


On Sat, Oct 8, 2016 at 3:00 PM, <<= a href=3D"mailto:cellar-request@ietf.org" target=3D"_blank">cellar-request@= ietf.org> wrote:
Send Cel= lar mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cellar@ietf.org

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

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

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

Today's Topics:

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


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


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

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

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

 FLAC attack.


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




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

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



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

Hi all,

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

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

 So some questions for the group:

 1. Is such a meeting of interest?

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

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

 Dave Rice




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

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

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

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



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

>1. Is such a meeting of interest?

Indeed.

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

A schedule permitting remote participation from Europe would
be ideal.

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

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

+1 FLAC

Best regards, Reto




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

kind regards,
Brendan Allen

Sent from my iPhone

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



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

=

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



--
=
Ethan Gates
Moving Image Archiving and Preservation Technic= ian
Department of Cinema Studies, MIAP
New York University
665 Bro= adway, Room 613
New York, NY 10012
212-998-1= 732
--001a113ad0cc2e2900053e6ee756-- From nobody Sun Oct 9 08:45: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 B7B5A12951D for ; Sun, 9 Oct 2016 08:45:32 -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 a_NpB_Fd9wTu for ; Sun, 9 Oct 2016 08:45:24 -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 8BF6E129572 for ; Sun, 9 Oct 2016 08:45:24 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id w3so30908756ywg.1 for ; Sun, 09 Oct 2016 08:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EWExPgBNz3Vy+Ue3ky4v5fb4vDLKadlwu5BwctlpMo4=; b=cxzopmb7H7Yw5eY5Q/+ffJhLw1fseMLqxFuKdX9ZAfkR8t+JCbjdNyYB6tCP5ZVc4O ppzfILdIteMXflwIQxRbn6FIpECEzlThqFFRPk62sul/+GNZq0pyS/1pr/DmO9kHIeNe LZdL+xdsRhAQ03lAagGNedaW6LTnXr/AxYDr/hnKFNuvzClFNj7e4Us1/W3KFQp4st5q ayOoowKNat/cEXaMRAdzVbnMBi0Qr0GnzC6brp2Xna8PvFPZw0NsCMz7Gs5VqQXCtDBY ID2mAr/YwKX/WJ6xRltc1ivsWnzs6+Lt8MWitmNi8qNsJupKhL2I5aoxgaiTwR1c+bRw 7Raw== 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=EWExPgBNz3Vy+Ue3ky4v5fb4vDLKadlwu5BwctlpMo4=; b=RfuqFcGYHr9RtRi9MjhW/nvD556OGSnFbzWcU1EHm76my88Kvbk/BCc1xyKwmBGpRn 3huWHeqggVGSiMmbs3Cv3giTowJssDpQMUK6OefFmXpdpmeI/HQstkdBL/pPqEyDdCvE 6nNlj6IBlESLyaYCNlBdXGPQS9pJpAjburXwkd51rO5caWRps+wftl+X0lkYJ8YOCWr2 pl9aLvbaeec785K9yOxcPMmDGL20l9efwFzFkQgWgXd2WW/btUZkDxepU07ODV9ZnAWN UdWxxJBc3yQQJVVXAUaG6Au7YxCXKUA8NiG0Gat5ipo/cZP/IvukBXmvYP+yiQoPkglK Q7ww== X-Gm-Message-State: AA6/9Rm84fykmo4ris6hv8FcX0YeulmzE7kEF2t7wBT5QiapvnmPi2PR3SgcSqAeBL+VjWrR6Mba9w9RrrbC5g== X-Received: by 10.129.158.12 with SMTP id v12mr22966641ywg.43.1476027923778; Sun, 09 Oct 2016 08:45:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 9 Oct 2016 08:45:23 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 9 Oct 2016 17:45:23 +0200 Message-ID: To: Reto Kromer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 09 Oct 2016 15:45:33 -0000 I updated the pull request #106 with cleaner CRC32 and Void pathes that actually match the specified ABNF syntax. Now elements that can be placed anywhere in a path starting from a fixed path (CRC32 and Void having the special case of the fixed part being the root) have their own specific syntax. The variable part must be the last parent in the path. The ABNF syntax has been used more with the use of DIGIT, ALPHA and () grouping of elements "repetition". The EBMLElementOccurence is now mandatory. This makes the path/occurence easy to split. 2016-10-02 21:18 GMT+02:00 Reto Kromer : > Steve Lhomme wrote: > >>Yes, I will bring back the minOccurs/maxOccurs XML >>attributes. But I think the values should be kept in the >>path. This is easier to match as a regular expression. >>Although the occurence is defined with {} in perl (IIRC) >>and we use () with means grouping in EBNF. > > +1 > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Mon Oct 10 12:52: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 C5B7F1294C5 for ; Mon, 10 Oct 2016 12:52:34 -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 T7OtBs6SppR3 for ; Mon, 10 Oct 2016 12:52: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 E137312945C for ; Mon, 10 Oct 2016 12:52:32 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:38694 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1btgcg-002QMQ-Rt for cellar@ietf.org; Mon, 10 Oct 2016 15:52:32 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> Date: Mon, 10 Oct 2016 15:52:28 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Subject: [Cellar] Matroska Menu Specifications 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, 10 Oct 2016 19:52:35 -0000 Hi all, There is a draft document at = https://matroska.org/technical/menu/index.html which has been = incorporated into our Matroska working repository at = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.= md. The document appears more like a wishlist than a specification. Is there = any further information available on Menu features of Matroska? Should = the document be removed for now? Do Matroska menus exist? Dave= From nobody Mon Oct 10 14:55:07 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 BA38412979A for ; Mon, 10 Oct 2016 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 F-fv0clo2yBj for ; Mon, 10 Oct 2016 14:55:03 -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 7594612978B for ; Mon, 10 Oct 2016 14:55:02 -0700 (PDT) Received: from [192.168.178.25] ([91.47.57.141]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MJXEd-1bsKgy2qLr-0036yr for ; Mon, 10 Oct 2016 23:54:59 +0200 To: cellar@ietf.org References: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> From: hubblec4 Message-ID: <435add5a-fd99-06f8-e7ac-af07d4c2bf5f@gmx.ch> Date: Mon, 10 Oct 2016 23:54:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> Content-Type: multipart/alternative; boundary="------------418586D22462ACBD3FE3CBAD" X-Provags-ID: V03:K0:knMEhvGxQSxUUaOOrGU1c9hiseRX8Rsf5zd+xDZk6zAL2tuO2zX EvEn4YHQgO+8k4sDvZPDFW+EupW2VTR0ipk7LVOvoJVXtnP7KudHNdYDSd/jmjYUC0Np0+c afqzRrdJSEjjNvU+v5IJCJZApTiraWLkXet1Zf65M+vz/RXPstcAHuC+bfq6Fpn1wjOURcR N/iTufwR/6eSDyyLAq9cw== X-UI-Out-Filterresults: notjunk:1;V01:K0:F0ADZKUwkyM=:R5Dmc7tlAELzpAz03//05O p/WoNQOJUE2dlMgujpDvN/abFT6kf0WGfEaQelCSzCXgiPu1P8FxEWzQsFlMXXNW0YmOFxpow F6/Nx5pcSduBVzVC8ejn0d2daR1lZtlvYktM04V+as7QMyH34kH/hX5lHV7UU8bO4FNItQSXv sHZx/+zEs2iCdC4nIdndvwC0GhstjTa/O22vIE7M/U38LOOSmGzPeQKIrSb+iMm+cLuoHsEhM jN6kFpSafeJhFibHzIHnpx2yWz47JJEXFs4OAHkmiTGH+cWhZtllkN3XDyfHzCtUqv3ETqxHY oVBhPs6ymeAZrMW3PeVM2Boe2NvHgACEKIsecI6KgEmhwtoSAz/RPKGFIPfEhM0eZoZGQEBOj UgRm3crtUoE0gFwZ0Yw0ZMYw0XUsh+iClOSE0HtdIVtnuST1AhOIr64CM7YOYMBkA1HGtBo3A fkIlPHhK56yPx0FQLeLVrIo9Opby4rllga69grNA2vfvuDVsUsRvQgGaPZpGymeVjhmaMVxhg M0qX2V33/S04EpswA/+xvf4BC/F/tutzE5HyGX0Z4CgWUE98bgYVjZpH4oOv1d+H4cJ+b5nbV 8pp/3a2ArxCwNI0bzzOhreKzy2inh/1rfyREkrzqQCft9jZIT3K0LF2O+NJujM6QXFdJPMZat GsBvG2//0864pwphwgqA3V7l+TrlSskVn27Q+JWTvZfJQdHfOSRIDFb7/FAjyoUqHjv+3z22Q tCLpkQX5sX7cDNsirh3TOSAaeVWQnFLeOYMDlITr0tz/FamTh6us9BsU7HpcVFNNCeLj4Kr9L U4gLMRe Archived-At: Subject: Re: [Cellar] Matroska Menu Specifications 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, 10 Oct 2016 21:55:06 -0000 This is a multi-part message in MIME format. --------------418586D22462ACBD3FE3CBAD Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dave and all others I like the idea that Matroska support in the future a menu. The DVD-menu is supported in an early version of VLC-Player (Steve told me the number on the Matroska meeting, but I can't me remember). Am 10.10.2016 um 21:52 schrieb Dave Rice: > Hi all, > There is a draft document at https://matroska.org/technical/menu/index.html which has been incorporated into our Matroska working repository at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.md. I have read this page many times because it is the only one which contains information about the Matroska menu. I quickly realized that the information was not enough to create a Matroska menu. > > The document appears more like a wishlist than a specification. Is there any further information available on Menu features of Matroska? Should the document be removed for now? Do Matroska menus exist? Of course this page looks like a wishlist. But there are two important Informations what is required to play a Matroska file which have a menu-structure inside. 1. Chapter Codec 2. Player has a feature "Control Track" More menu information you found here. With this infos I was able to figure out how DVDMenuXtractor works, which helps to understand the menu structure. The native Matroska menu is theoretically always used. The default value is set(ChapProcessCodecID = 0). This two pages could be combined to a new Matroska menu page. I missed some information, but this page helps me at most. Matroska already has a small menu on board. LAV,Haali and VLC(maybe other players too) supports this. A simple edition selection. But with ordered editions/chapters it is not so simple anymore. And if the ordered chapters are additionally combined with nested chapters. But the top thing is to combine all this with ChapterSegementLinking, than you already have a bit of the feeling of a menu. All my preservations get from now on such a short mainmenu.mkv file. That let me control the content of all files within the player. The Matroska menu will be ever limited by the splitters/players, so I think there is not much interesting to improve it. But I hope. In my limited leisure I rewrite my chapterEditor that it will be easier to generate such menu.mkv files. If I had more time, I'd like to do more for Matroska menu. Best regard Martin --------------418586D22462ACBD3FE3CBAD Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Dave and all others

I like the idea that Matroska support in the future a menu. The DVD-menu is supported in an early version of VLC-Player (Steve told me the number on the Matroska meeting, but I can't me remember).



Am 10.10.2016 um 21:52 schrieb Dave Rice:
Hi all,
There is a draft document at https://matroska.org/technical/menu/index.html which has been incorporated into our Matroska working repository at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.md.

I have read this page many times because it is the only one which contains information about the Matroska menu.
I quickly realized that the information was not enough to create a Matroska menu.

 

The document appears more like a wishlist than a specification. Is there any further information available on Menu features of Matroska? Should the document be removed for now? Do Matroska menus exist?

Of course this page looks like a wishlist. But there are two important Informations what is required to play
a Matroska file which have a menu-structure inside.
1. Chapter Codec
2. Player has a feature "Control Track"

More menu information you found here.
With this infos I was able to figure out how DVDMenuXtractor works, which helps to understand the menu structure.
The native Matroska menu is theoretically always used. The default value is set(ChapProcessCodecID = 0).
This two pages could be combined to a new Matroska menu page. I missed some information, but this page
helps me at most.

Matroska already has a small menu on board. LAV,Haali and VLC(maybe other players too) supports this.
A simple edition selection. But with ordered editions/chapters it is not so simple anymore.
And if the ordered chapters are additionally combined with nested chapters.

But the top thing is to combine all this with ChapterSegementLinking, than you already have a bit of the feeling of a menu.
All my preservations get from now on such a short mainmenu.mkv file. That let me control the content of all files within the player.

The Matroska menu will be ever limited by the splitters/players, so I think there is not much interesting to improve it. But I hope.

In my limited leisure I rewrite my chapterEditor that it will be easier to generate such menu.mkv files.
If I had more time, I'd like to do more for Matroska menu.

Best regard
Martin
--------------418586D22462ACBD3FE3CBAD-- From nobody Mon Oct 10 23:38:42 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9626129456 for ; Mon, 10 Oct 2016 23:38:41 -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 9ZYbAet8lvcU for ; Mon, 10 Oct 2016 23:38:39 -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 A735A129407 for ; Mon, 10 Oct 2016 23:38:39 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t193so7054204ywc.2 for ; Mon, 10 Oct 2016 23:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7Oc+hU/NL8zWohzIv8jI/uEBJTSK2TZXFosWhIKeF0I=; b=XEQVgw1GEMc8x2TWGUbQFcHcm0O3kB06uBuuGGlsW4N+wS0rZhSimeJ10PfX1VUyuV IAy/hUfRdmtm4Gbn6FuPMonr4Hr7LzArfS4E1X0TzAA1r7IBtBrHn1U0GcnxbZK5u63F 82FruB5f4eigJxxVoUdE9NN9qlSqR/5oB6XNxZDK+2JvgGw9FoDw4PxsPhlFMs3C0PEX 7ACJVNqAvq5aOInXO+CZlwFBXRnAqOs9VLp7iRqeqUWFn4rgBg4c9I4CbeiNkU0rLFZZ RzvQsNWklO6SmOazX/Ki7vKNE22+XRzQ3P0ylKBpM+5QTSuchtRUwOUk36a9nizYQtUk U57Q== 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=7Oc+hU/NL8zWohzIv8jI/uEBJTSK2TZXFosWhIKeF0I=; b=Xk+n0kEthu72N65K+rzeivsIRJ3WbMuCc1NrKhRu+VSz91k0YKkNaSKkIgTFFzjGL3 puAsBir1kKQ2VlPTJg3DQICuvR4AAWsLk9ynryHCd8mjE2EHVsFZYvxnajf3L/pTF+i4 6ME9/RbWeUUTEi4jjwxtFSFNRqqZOwMtJZngHaJymgxMsH2gWwJJmdkInlMLpkq9DEu0 zIAutRUQ3z9TYrOKPvlzp+ho9G0mPD7rUOg3bLFTWbtLsr6FDDq37IoT6foOhIXv/vCU JLpK3Kep5SwtLFGvZVRc9TIbgt3oxVto+2saLKrjsMyOiR3pUzIqRPHwOyq0auJh6RQr bjfA== X-Gm-Message-State: AA6/9RkveSk3SWw9EBNdNqCXgRMurq8NZASk1m7j7exCFUYeG9Jx/wJ0v51ox/ZLqZqfpSKfFsrQXIrh90DELg== X-Received: by 10.13.231.3 with SMTP id q3mr1970221ywe.242.1476167918350; Mon, 10 Oct 2016 23:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Mon, 10 Oct 2016 23:38:37 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Tue, 11 Oct 2016 08:38:37 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 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, 11 Oct 2016 06:38:42 -0000 Pull request merged, we can now continue fixing the little issues and get going with the Matroska specs. 2016-10-09 17:45 GMT+02:00 Steve Lhomme : > I updated the pull request #106 with cleaner CRC32 and Void pathes > that actually match the specified ABNF syntax. > > Now elements that can be placed anywhere in a path starting from a > fixed path (CRC32 and Void having the special case of the fixed part > being the root) have their own specific syntax. The variable part must > be the last parent in the path. > > The ABNF syntax has been used more with the use of DIGIT, ALPHA and () > grouping of elements "repetition". > > The EBMLElementOccurence is now mandatory. This makes the > path/occurence easy to split. > > 2016-10-02 21:18 GMT+02:00 Reto Kromer : >> Steve Lhomme wrote: >> >>>Yes, I will bring back the minOccurs/maxOccurs XML >>>attributes. But I think the values should be kept in the >>>path. This is easier to match as a regular expression. >>>Although the occurence is defined with {} in perl (IIRC) >>>and we use () with means grouping in EBNF. >> >> +1 >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Thu Oct 13 19:27: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 844D01295A9 for ; Thu, 13 Oct 2016 19:27:11 -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 VRLELupmQl7d for ; Thu, 13 Oct 2016 19:27:09 -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 C38EE12958B for ; Thu, 13 Oct 2016 19:27:09 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:48662 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1busDE-002Aa4-92; Thu, 13 Oct 2016 22:27:09 -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: Thu, 13 Oct 2016 22:27:06 -0400 Content-Transfer-Encoding: quoted-printable 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: Codec Encoding for LossLess Archiving and Realtime transmission 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, 14 Oct 2016 02:27:11 -0000 Hi all, > On Oct 11, 2016, at 2:38 AM, Steve Lhomme = wrote: >=20 > Pull request merged, we can now continue fixing the little issues and > get going with the Matroska specs. I added a new commit to Steve=E2=80=99s pull request [1] to update = Matroska=E2=80=99s EBML Schema to the newly defined form. Rather than do = these updates manually I converted the EBML Schema from Steve=E2=80=99s = edit through this xsl [2] (then only had to insert the commented out = =E2=80=98TimecodeScaleDenominator=E2=80=99 Element). The pull request's = updated EBML Schema for Matroska can be viewed at = https://github.com/Matroska-Org/matroska-specification/blob/parenting/ebml= _matroska.xml. Dave [1]: https://github.com/Matroska-Org/matroska-specification/pull/42 [2]: https://gist.github.com/dericed/ddb0eaa6bb4f0983825e715d45ff6141 From nobody Thu Oct 13 19:34:07 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 D07F41295A8 for ; Thu, 13 Oct 2016 19:34:05 -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 M7z9HeACWI1W for ; Thu, 13 Oct 2016 19:34:04 -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 9711C12940D for ; Thu, 13 Oct 2016 19:34:04 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:46632 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1busJt-002E5y-RT; Thu, 13 Oct 2016 22:34:04 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_34DCA773-666F-44D1-9686-368DD13198C8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Thu, 13 Oct 2016 22:34:00 -0400 Message-Id: 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 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: Fri, 14 Oct 2016 02:34:06 -0000 --Apple-Mail=_34DCA773-666F-44D1-9686-368DD13198C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 30, 2016, at 12:40 PM, Michael Bradshaw = wrote: >=20 > 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]. >=20 > 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. >=20 > 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? >=20 > (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) >=20 > [1]: = https://github.com/google/spatial-media/blob/master/docs/spherical-video-v= 2-rfc.md#webm-matroska = After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on the = standardizing spatial media, I drafted a pull request at = https://github.com/Matroska-Org/matroska-specification/pull/53 for = consideration which adds the projection elements (from Michael=E2=80=99s = link above) to Matroska=E2=80=99s EBML Schema. This pull request is = dependent on another pull request at = https://github.com/Matroska-Org/matroska-specification/pull/42 which is = an adjustment to Matroska=E2=80=99s EBML Schema based on recent EBML = specification updates. Some considerations from writing this pull request: There are several Matroska elements that describe enumerated values and = the `Projection` Child Elements make use of enumeration lists as well. = Currently the practice in Matroska element definitions appear to = enumerate in this form =E2=80=9C(1: description of the first option, 2: = description of another option, 3: one more option)=E2=80=9D. Perhaps = it=E2=80=99s worthwhile to standardize how enumeration lists are = expressed in the EBML Schema, so that rather than: Describes the projection used for this = video track. Valid values: (0: Rectangular, 1: Equirectangular, 2: = Cubemap, 3: Mesh) we could have something like Describes the projection used for this = video track. Rectangular Equirectangular Cubemap Mesh Is breaking down enumeration into a structure like this helpful or = over-engineering? Also although I see the documentation for Projection in webm, but is = there a comparable set of documentation for ambisonics in webm? The = draft at = https://github.com/google/spatial-media/blob/9bc4691f748a553a06b4b297f05ec= 2a62e53da1b/docs/spatial-audio-rfc.md only references mp4. Dave Rice --Apple-Mail=_34DCA773-666F-44D1-9686-368DD13198C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 30, 2016, at 12:40 PM, Michael Bradshaw <mjbshaw@google.com> = wrote:

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/spheri= cal-video-v2-rfc.md#webm-matroska
=








Dave Rice

= --Apple-Mail=_34DCA773-666F-44D1-9686-368DD13198C8-- From nobody Fri Oct 14 09:22: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 8486B129540 for ; Fri, 14 Oct 2016 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, 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 sNw6595kWIvA for ; Fri, 14 Oct 2016 09:22:20 -0700 (PDT) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com [209.85.216.175]) (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 9D702129530 for ; Fri, 14 Oct 2016 09:22:20 -0700 (PDT) Received: by mail-qt0-f175.google.com with SMTP id q7so80020662qtq.1 for ; Fri, 14 Oct 2016 09:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CQ8S5LYJD+HSCS3R4jVSOHjlciSJfCrJooNZcHU98rI=; b=jg2vYpxQPbXeKSbzVQn57dyjVsOXVUkCwDzidWknrxD45syJS+/fCuwZyzwEI12Gp1 6MuoNyc3RJJbHJmV9oNmnHXRAfPPHmdVFFCXA/ZoZnRVg9boDNMFlZnDWqOM1RCWFr47 h5wsYBllrHLc3kiSTJgu/z/16o0NBmIFvFBTQLWiYD9XEbuA5Me7QFGSW5yrjG9QttO4 eFr+Of5IDm1G5kGdUGxjs/foKmjb/gSS68WRPmPtZZSP0llPT3264GOzSi5sDilUzu9d fq2hixvpsDXT9VEZTffXAq1CKLr8Pequp66qRXhN7iQqA5b8hnpCp/mQnboSIlO3VJfp DdTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CQ8S5LYJD+HSCS3R4jVSOHjlciSJfCrJooNZcHU98rI=; b=Rv5ahr5QYBuSNo8fOybXXH8cyWSHQcAj849nLi7ZczJEtf4olCgnICqK4JjWJjuzv5 xhQ5y7zvfhSLvfVLYYs4ihst7PhC+201lnelbMMZQ6U4Y3WHFOE6u1OrXyssANC2j5pZ jmC36g6VycH0ulUNQjVTad/Y1kGevuBWJC455Mw4znyejNSsCp6h4lLkErmWi342S6fk qWUjYkdXp6uW37AaT7TsYaCFmvnRmtJaYC9klkJwWbYbyAfga5p3Ma1b+76iH1PHTupy 2gMXQXwMPk6rVBJBJgObYhzlMyzWnQqBUJ49IzxdIYiUUnpr/LKti4CUdhT935Zx42/N fJ5A== X-Gm-Message-State: AA6/9RkcgL8E7LY8Cep33jKgza7NxFUw8WuPkG2I+RYuZpkQY7kQ+CATm9E8GwvaQ/noDY5flYE+DeUqzK5qPjO0 X-Received: by 10.200.40.197 with SMTP id j5mr13027455qtj.43.1476462079533; Fri, 14 Oct 2016 09:21:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Colwell Date: Fri, 14 Oct 2016 16:21:08 +0000 Message-ID: To: Dave Rice , Michael Bradshaw Content-Type: multipart/alternative; boundary=001a114069a4c6c10d053ed59dd2 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Fri, 14 Oct 2016 16:22:23 -0000 --001a114069a4c6c10d053ed59dd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 13, 2016 at 7:34 PM Dave Rice wrote: > > On Aug 30, 2016, at 12:40 PM, Michael Bradshaw wrote= : > > 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 viewe= r > 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 jus= t > quite yet) > > [1]: > https://github.com/google/spatial-media/blob/master/docs/spherical-video-= v2-rfc.md#webm-matroska > > > After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on the > standardizing spatial media, I drafted a pull request at > https://github.com/Matroska-Org/matroska-specification/pull/53 for > consideration which adds the projection elements (from Michael=E2=80=99s = link > above) to Matroska=E2=80=99s EBML Schema. This pull request is dependent = on another > pull request at > https://github.com/Matroska-Org/matroska-specification/pull/42 which is > an adjustment to Matroska=E2=80=99s EBML Schema based on recent EBML spec= ification > updates. > > Some considerations from writing this pull request: > > There are several Matroska elements that describe enumerated values and > the `Projection` Child Elements make use of enumeration lists as well. > Currently the practice in Matroska element definitions appear to enumerat= e > in this form =E2=80=9C(1: description of the first option, 2: description= of > another option, 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthw= hile to > standardize how enumeration lists are expressed in the EBML Schema, so th= at > rather than: > > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" id=3D"0x767= 1" > type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-3= " webm=3D"1"> > Describes the projection used for this video > track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap, 3: > Mesh) > > > we could have something like > > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" id=3D"0x767= 1" > type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-3= " webm=3D"1"> > Describes the projection used for this video > track. > Rectangular > Equirectangular > Cubemap > Mesh > > > Is breaking down enumeration into a structure like this helpful or > over-engineering? > > Also although I see the documentation for Projection in webm, but is ther= e > a comparable set of documentation for ambisonics in webm? The draft at > https://github.com/google/spatial-media/blob/9bc4691f748a553a06b4b297f05e= c2a62e53da1b/docs/spatial-audio-rfc.md > only references mp4. > > Dave Rice > Thanks for doing this Dave! I just let Andrew know that you are helping us move this forward. :) We have not created a Matroska equivalent of the ISOBMFF ambisonics stuff yet, but we definitely would like to nail that down. It has been on our todo list but video had been the higher priority lately. I'll chat with Dillon Cower, the primary maintainer of the spatial audio spec, about this today. I'm assuming this list would be the preferred venue for the spatial audio discussion. Aaron > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a114069a4c6c10d053ed59dd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Oc= t 13, 2016 at 7:34 PM Dave Rice <dav= e@dericed.com> wrote:

<= div class=3D"gmail_msg">
On Aug 30, 2016, at 12:40 PM, Michael Bradshaw <mjbshaw@google.com> wrote:

Matroska currently doesn't have a way to spec= ify projection information for 360/VR videos. Google's=C2=A0Spherical V= ideo V2 RFC draft was just updated a few days ago to include some new eleme= nts specifying projection and viewer pose information[1].

These propose= d 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 projectio= n information in Matroska. Assuming there hasn't been any, is there int= erest in adding it (I'm assuming the answer is still yes, from those I = asked in Berlin)? Do the elements from the=C2=A0Spherical Video V2 RFC draf= t look like good candidates?

(For the record, I'm just breaki= ng the ice here and getting the conversation started; this isn't a prop= osal to adopt the new elements just quite yet)

= [1]:=C2=A0https://github.com/google/spatial-media/blob/master/docs/sphe= rical-video-v2-rfc.md#webm-matroska

After hearing Andrew Scherkus=E2= =80=99s presentation at Demuxed on the standardizing spatial media, I draft= ed a pull request at https://g= ithub.com/Matroska-Org/matroska-specification/pull/53 for consideration= which adds the projection elements (from Michael=E2=80=99s link above) to = Matroska=E2=80=99s EBML Schema. This pull request is dependent on another p= ull request at https://github.= com/Matroska-Org/matroska-specification/pull/42 which is an adjustment = to Matroska=E2=80=99s EBML Schema based on recent EBML specification update= s.

Some considerations from writing this pull request:

There are several Matroska elements that describe enumerated values and t= he `Projection` Child Elements make use of enumeration lists as well. Curre= ntly the practice in Matroska element definitions appear to enumerate in th= is form =E2=80=9C(1: description of the first option, 2: description of ano= ther option, 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile = to standardize how enumeration lists are expressed in the EBML Schema, so t= hat rather than:

<element name=3D&quo= t;ProjectionType" path=3D"1*1(\Segment\Tracks\TrackEntry\Video\Pr= ojectionType)" id=3D"0x7671" type=3D"uinteger" min= Occurs=3D"1" minver=3D"4" default=3D"0" range= =3D"0-3" webm=3D"1">
= =C2=A0 <documentation lang=3D"en">Describes the projection = used for this video track. Valid values: (0: Rectangular, 1: Equirectangula= r, 2: Cubemap, 3: Mesh)</documentation>
</element>

we could have something like

<element name=3D"ProjectionType" path=3D"= ;1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" id=3D"0x76= 71" type=3D"uinteger" minOccurs=3D"1" minver=3D&qu= ot;4" default=3D"0" range=3D"0-3" webm=3D"1&q= uot;>
=C2=A0 <documentation lang=3D&quo= t;en">Describes the projection used for this video track.</docum= entation>
=C2=A0 <enum value=3D"0&= quot;>Rectangular</enum>
=C2=A0 <= enum value=3D"1">Equirectangular</enum>
=C2=A0 <enum value=3D"2">Cubemap</enum>= ;
=C2=A0 <enum value=3D"3">Me= sh</enum>
</element>

Is= breaking down enumeration into a structure like this helpful or over-engin= eering?

Also although I see the documentation for Projection in w= ebm, but is there a comparable set of documentation for ambisonics in webm?= The draft at=C2=A0https://github.com/google/spatial-m= edia/blob/9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio-rfc.m= d only references mp4.

Dave Rice

Thanks for doing this Dave! I just let Andrew know that you are helping u= s move this forward. :) We have not created a Matroska equivalent of the IS= OBMFF ambisonics stuff yet, but we definitely would like to nail that down.= It has been on our todo list but video had been the higher priority lately= . I'll chat with Dillon Cower, the primary maintainer of the spatial au= dio spec, about this today. I'm assuming this list would be the preferr= ed venue for the spatial audio discussion.

Aaron
=C2=A0

=
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/= listinfo/cellar
--001a114069a4c6c10d053ed59dd2-- From nobody Sat Oct 15 08:40:09 2016 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD712950B; Sat, 15 Oct 2016 08:40:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147654600410.30588.10491644254466049985.idtracker@ietfa.amsl.com> Date: Sat, 15 Oct 2016 08:40:04 -0700 Archived-At: Cc: cellar@ietf.org Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-01.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 15 Oct 2016 15:40:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme <> Dave Rice <> Moritz Bunkus <> Filename : draft-ietf-cellar-ebml-01.txt Pages : 33 Date : 2016-10-11 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 15 08:51:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0912E129447 for ; Sat, 15 Oct 2016 08:51:43 -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 C9YSAJ7X_jxu for ; Sat, 15 Oct 2016 08:51:41 -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 7E74E12943F for ; Sat, 15 Oct 2016 08:51:41 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:45963 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bvRFM-000Rzn-2n for cellar@ietf.org; Sat, 15 Oct 2016 11:51:41 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 15 Oct 2016 11:51:37 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Subject: [Cellar] Matroska: limit to 2 SeekHead 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: Sat, 15 Oct 2016 15:51:43 -0000 HI all, I submitted a small pull request to limit SeekHead to two occurrences = [1] (in practice an option first SeekHead for the beginning of the file = and an optional second SeekHead for the end of the file). The = documentation on the SeekHead element = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/order= _guidelines.md#seekhead doesn=E2=80=99t explicitly say that SeekHead = elements are limited to two, but the documentation doesn=E2=80=99t seem = to leave any purpose remaining for a third SeekHead. Additionally the = past XML structure for defining Matroska structure had no mechanism to = express an Element usage limit beyond 0, 1 or infinite, so such a = constraint is only recently feasible. =46rom a survey of 75,732 Matroska files: - 11,897 has 0 SeekHead Elements - 53,859 has 1 SeekHead Element - 9,976 has 2 SeekHead Elements - 0 has >2 SeekHead Elements Is there any scenario where >2 SeekHead Elements makes sense? Any = likelihood that >2 SeekHead Elements was ever used? Dave Rice [1]: https://github.com/Matroska-Org/matroska-specification/pull/54= From nobody Sat Oct 15 08:57:26 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 2123812711D for ; Sat, 15 Oct 2016 08:57:25 -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 Ham96AyzzqxP for ; Sat, 15 Oct 2016 08:57:23 -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 432D6126D73 for ; Sat, 15 Oct 2016 08:57:23 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:40086 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bvRKr-000UkP-Gb for cellar@ietf.org; Sat, 15 Oct 2016 11:57:22 -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: <147654600410.30588.10491644254466049985.idtracker@ietfa.amsl.com> Date: Sat, 15 Oct 2016 11:57:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4D44F960-66B2-4173-85AA-EA1949621AEA@dericed.com> References: <147654600410.30588.10491644254466049985.idtracker@ietfa.amsl.com> To: Codec Encoding for LossLess Archiving and Realtime transmission 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: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ebml-01.txt 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, 15 Oct 2016 15:57:25 -0000 Hi, > On Oct 15, 2016, at 11:40 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Codec Encoding for LossLess Archiving = and Realtime transmission of the IETF. >=20 > Title : Extensible Binary Meta Language > Authors : Steve Lhomme <> > Dave Rice <> > Moritz Bunkus <> > Filename : draft-ietf-cellar-ebml-01.txt > Pages : 33 > Date : 2016-10-11 >=20 > Abstract: > This document defines the Extensible Binary Meta Language (EBML) > format as a generalized file format for any type of data in a > hierarchical form. EBML is designed as a binary equivalent to XML > and uses a storage-efficient approach to build nested Elements with > identifiers, lengths, and values. Similar to how an XML Schema > defines the structure and semantics of an XML Document, this = document > defines how EBML Schemas are created to convey the semantics of an > EBML Document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cellar-ebml-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ebml-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ After Steve's recent pull request [1] (which refactored the EBML = Schema), this version represents the work of over 100 commits [2] in the = associated GitHub repository as well as updates and refinements based on = Tim=E2=80=99s review of draft-ietf-cellar-ebml-00. Comments welcome. Dave Rice [1]: https://github.com/Matroska-Org/ebml-specification/pull/106 [2]: https://github.com/Matroska-Org/ebml-specification/commits/master [3]: = https://mailarchive.ietf.org/arch/msg/cellar/Mfj44tK1gyfqjU3Uu1tI5fMovtk= From nobody Sat Oct 15 11:06: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 EA4DE1293DC for ; Sat, 15 Oct 2016 11:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4IWGBpvyKrjH for ; Sat, 15 Oct 2016 11:06:17 -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 D9777128E19 for ; Sat, 15 Oct 2016 11:06:13 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MF9WR-1cAYZs0Mn5-00GL7X for ; Sat, 15 Oct 2016 20:06:11 +0200 To: Cellar@ietf.org From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <81e17a9f-fc07-56cc-db38-9268eb8ae691@gmx.de> Date: Sat, 15 Oct 2016 20:06:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:51fzkVZCmV/hgmhjPCYW0FB8N63zMKOpWOwBNCsZ8Mqr6sAq8T+ KRqZnx2HMGYADtpIGD49qtZ53gDZPB/LQzkNHcv0bJ0RZyER7FHcUe0OArUxXvnhP0aLZnm Sv6KUSiSXKn0jffWIq+oT8fx79KFJD/gp884CRnvGUpySR40LvzH2FVZQ18vkFVPy+I3LME L+6/8pCymvUG8HTI1YSiw== X-UI-Out-Filterresults: notjunk:1;V01:K0:lsSlB3P9mOE=:rQHVSXIJD5FsqhFgobB4ZG C9m58/fkg6yMB5C/OsDOuKq9FYpP7DXdojoibLfsgprvPp7RyR0vm0kkQ68XBRVPAgXq4Act3 J2NVaMim4DlqJkUjiYckQjwMwQs3LKApayT5Rxst42zcZs3QnFJNAalDp1dQygYah7RtfySS+ NhceMZ9QVrzKKrQP2UUM5vqbcrfKyFE2HUtEBZEQqPUHu30uyX7aukBO9JSGYFLrPzmIzVzCM CcAdXS/5fnTJoEHRqIySVd9doCXl3bpHRY6jRkCQC/2dyLvNnXdpdOudfBk3Pl/+ck/AJnQET TnS1iSuh/niNAA+zdQXL9YjvcuC68C83An48Udr0Q1SvlVZ3CEuWo2CrZZNfk/SAsBcTYJwwx xuxD7YAzpQ07ShupmWRHWdmVwaB7H+o2sYULlL0UkNjM3nh9wBWeFuK2KkWdQQ+ZT7DG0w7BK LfklPXVIkX36YwBXEYrekqC/IUnH2QvFrTiKq259N1L2yXyKW2r0rIhy6JCuoWM9emfIpIRRv IDwJ6xXAaNJGmJHQAJ6x5SPbdrxutO3nwc4wggn6xJ/wMSk7JUBzbvqxuMM5nQuydGplVjikb hdLrjPXVji9q8uOXDEUUyTGAaP3YYTI2doq/UqPHAD+ZUoE3xL+uiHWtL7O6s4FtOkFhapnAG 36OR9iimjdcSmWiyltXBkz6e8cx7LKoZcgiGGaDc7QffkeaUykyoREiL6d/yyXZjU+1F3Tobt sHWzmT8G/UxhWTt2ThXfJylrHmH/4Id0rQ0PGI4QctHIGw+ZJWBD6beNSIcUibekJF9XILY+F KhtACzz Archived-At: Subject: [Cellar] Does the SeekHead specification contradict itself? 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, 15 Oct 2016 18:06:19 -0000 I wonder about the SeekHead specification. [0] "If a second SeekHead Element is used then the first SeekHead MUST reference the identity and position of the second SeekHead, the second SeekHead MUST only reference Cluster Elements and not any other Top-Level Element, [...]" "Whether one or two SeekHead Elements is used, the SeekHead Element(s) MUST reference the identify and position of all Top-Level Elements except for the first SeekHead." I find that both contradict each other. While in the first quote is stated that the second SeekHead MUST only reference clusters and NOT any other Top-Level Element, the second quote says that the SeekHead Elements MUST reference ALL Top-Level Elements. To me that would translate to 'every SeekHead contains ALL Top-Level Elements, beside the first SeekHead.' Since I am confused, I assume that this could be misinterpreted and therefore lead to faulty implementations. (This message was only send, because David sent his message with a question about the SeekHead, I can't answer.) Best Regards, Sebastian [0] https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/order_guidelines.md#seekhead From nobody Sat Oct 15 14:05:09 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F361129566 for ; Sat, 15 Oct 2016 14:05:08 -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 Mu70aI6FrPnH for ; Sat, 15 Oct 2016 14:05:07 -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 446C6129563 for ; Sat, 15 Oct 2016 14:05:07 -0700 (PDT) Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:38449 helo=[10.0.1.77]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bvW8f-002z36-LL for Cellar@ietf.org; Sat, 15 Oct 2016 17:05:06 -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: <81e17a9f-fc07-56cc-db38-9268eb8ae691@gmx.de> Date: Sat, 15 Oct 2016 17:05:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81e17a9f-fc07-56cc-db38-9268eb8ae691@gmx.de> To: Cellar@ietf.org 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: Subject: Re: [Cellar] Does the SeekHead specification contradict itself? 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, 15 Oct 2016 21:05:08 -0000 > On Oct 15, 2016, at 2:06 PM, Sebastian G. wrote: >=20 > I wonder about the SeekHead specification. [0] >=20 > "If a second SeekHead Element is used then the first SeekHead MUST > reference the identity and position of the second SeekHead, the second > SeekHead MUST only reference Cluster Elements and not any other > Top-Level Element, [...]" >=20 > "Whether one or two SeekHead Elements is used, the SeekHead Element(s) > MUST reference the identify and position of all Top-Level Elements > except for the first SeekHead." >=20 > I find that both contradict each other. While in the first quote is > stated that the second SeekHead MUST only reference clusters and NOT = any > other Top-Level Element, the second quote says that the SeekHead > Elements MUST reference ALL Top-Level Elements. >=20 > To me that would translate to 'every SeekHead contains ALL Top-Level > Elements, beside the first SeekHead.=E2=80=99 I think the intention was that the SeekHead Elements collectively (and = not individually if more than one SeekHead is used) reference all = non-first-SeekHead Top Level Elements. Does that properly resolve the = contradiction? Suggested wording? > Since I am confused, I assume that this could be misinterpreted and > therefore lead to faulty implementations. >=20 > (This message was only send, because David sent his message with a > question about the SeekHead, I can't answer.) >=20 > Best Regards, > Sebastian >=20 > [0] > = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/order= _guidelines.md#seekhead >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sun Oct 16 01:14:26 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 C87591295FB for ; Sun, 16 Oct 2016 01:14:24 -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 2XclDUstbW0l for ; Sun, 16 Oct 2016 01:14:23 -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 BB1D21295E0 for ; Sun, 16 Oct 2016 01:14:22 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M96Jd-1c7Tte2wHt-00COpl for ; Sun, 16 Oct 2016 10:14:19 +0200 To: cellar@ietf.org References: <81e17a9f-fc07-56cc-db38-9268eb8ae691@gmx.de> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <86c12078-eaf3-32c4-08cb-1945c37f2c2b@gmx.de> Date: Sun, 16 Oct 2016 10:14:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:yvF4hrv2jXXYmTlBSO7bJTnBLDxK9uLgqIv47tB3v9OgI+fMC8h Q6Oxk0AdqK62uPSliXQQ7v4XSJH0L78jR3w452FaBVMzk+Ieyyjj+jlqORtHdI7hR3uatLU uhceyveTayymVA5jmaYo1WhfTEgMI/veRriL1OGQC3PDfvOkclBxqGaYKl3YYJzKMR3uajF rC5cUvE7YnZkCRUjPgcyw== X-UI-Out-Filterresults: notjunk:1;V01:K0:/nmGkn6lBuQ=:8xhmC1ir7TpKsSBL9J07Ai NW6RpqbrGGDx+UPG0Vu7wD2vhPi7jN5qatHyX+8QewzgCj1GLraUlNGcxTpV3HtglgTWxUXE5 faFor9yQkZF0mSITT48KPMzImj+VkPKq4JZpzcPnh9x7uG+HuMCDOMJE76z2XwygJnLgsymLm KOGmGH+iVucOWH4T0k50On8SH6LWNW/QqRJ+V3fz3FpxeVbpUP2+UVJTHxe4ftArl3xvekWIB /Vnlk/37lTku884nrDbEiqiAIEixsWvTaHgspDe1/ZVrhAfs17E74pOdV2RzIyt8bvpeORmWx DlO2kNzSlL7lSX4tatxB6osuHmrco4AbFUERDn7TeLTs9aiwSVQa3pyf/WeeH42Yc1WNkp0MM Q8rWnZ7UIHM8hdmgfOkWkVqiwaPpa+cKTHk+w2gmIIxJkpn/7kcUC2dk+RyfUor1Hm/1MMMVa wX1DzYPoDla+YfQyq7iwMrBZGfJs1/QsLF6DEcq600qySNXC0S7XJIBnIWVLObwcAcnvITD5S dWPob8qkNgjHGQyeBaZ18FuRcwrBoV3ViJthqji3In30d73A/2icTISrOELEGdYBM//nX8q04 GsiZ05oalFuOyqES9oMd4WUwYfYlm40kVxMWt+BhGUUAOpDSwNWeBm2EJnFEkVJ6bptCejbjC V8ubcy3kaMyh0lzSUmH8E8LM9zlLStRCzOxQcjL2xAZQa3NSd7pcIp8pX43ZWhT71muXAe2uw 6Whz3ljLC23b6drIE0o6kCWjzC6MVg5nElq4lZ15L8lJoL0YIzd4zEOALmeTO4fvQRzb3LeDG VH9HkOH Archived-At: Subject: Re: [Cellar] Does the SeekHead specification contradict itself? 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, 16 Oct 2016 08:14:25 -0000 15.10.2016, 23:05 Dave Rice: > >> On Oct 15, 2016, at 2:06 PM, Sebastian G. wrote: >> >> I wonder about the SeekHead specification. [0] >> >> "If a second SeekHead Element is used then the first SeekHead MUST >> reference the identity and position of the second SeekHead, the second >> SeekHead MUST only reference Cluster Elements and not any other >> Top-Level Element, [...]" >> >> "Whether one or two SeekHead Elements is used, the SeekHead Element(s) >> MUST reference the identify and position of all Top-Level Elements >> except for the first SeekHead." >> >> I find that both contradict each other. While in the first quote is >> stated that the second SeekHead MUST only reference clusters and NOT any >> other Top-Level Element, the second quote says that the SeekHead >> Elements MUST reference ALL Top-Level Elements. >> >> To me that would translate to 'every SeekHead contains ALL Top-Level >> Elements, beside the first SeekHead.’ > > I think the intention was that the SeekHead Elements collectively (and not individually if more than one SeekHead is used) reference all non-first-SeekHead Top Level Elements. Does that properly resolve the contradiction? Suggested wording? Well I assumed that I guessed the intention correctly, but found that I could interpret in the way I did in my previous email. My understanding was that it was supposed to work like follows. There is the (initial) SeekHead Element indexing what's present in the file so far, then changes are made to the file, e.g. chapters are added, and any possible Void Element is too small to take the changes without the file having to be re-written, so the initial SeekHead is updated to point to another SeekHead written at some place where enough space is available (in form of a Void Element) or at the end of the file. The second SeekHead indexes what's not already indexed by the first SeekHead, e.g. the newly added chapters. If that is how it is actually supposed to work, then I we could try to change the wording. The word 'collectively' seems like a good idea. >> Since I am confused, I assume that this could be misinterpreted and >> therefore lead to faulty implementations. >> >> (This message was only send, because David sent his message with a >> question about the SeekHead, I can't answer.) (It's Dave... sorry for that.) And we can wait until, your question about more than two SeekHeads is resolved. >> Best Regards, >> Sebastian >> >> [0] >> https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/order_guidelines.md#seekhead >> From nobody Sun Oct 16 01:23: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 9516B1295DA for ; Sun, 16 Oct 2016 01:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0urEXMHwdh4 for ; Sun, 16 Oct 2016 01:23:20 -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 9614B129477 for ; Sun, 16 Oct 2016 01:23:20 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 118F6527385D; Sun, 16 Oct 2016 10:21:23 +0200 (CEST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 5C9F852737C5 for ; Sun, 16 Oct 2016 10:21:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1476606075; bh=mubMG4cPlXCKgpX9u195knnBWKmk6Jo5UbmK01Oqvcc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=neZEXCqeZg7PR/jwyKioWaHlHoftUp08wjVIeSTpcfg10ROT6Ljy9vp676poQBlAY yUhlubW0r8fkd8/HzyQlBR2f5q0E89VcZhIb2aTjhdagBlNhMUfYF26Wkwn0EoH8+e qUdLbFijmEhCzoPAOluRYliA34FXkAl4K9eVd8/dtMc80qcOUjMX6vNQIjx3VYR+7a C8HoERBfTJ8JCFCH13zQUbKErntdj1WhF+buHpWx5yJboL0pRirLGbtJuo8RyR8PjP L4BfQfKWKKlFx9Freni2ZOero/GBXniLn6sIGP8F7gTp+fPlsqZ846Kjl1yYOso7HU x3JwqsUbYGmubWhQJRNeZO9JSmGPK5pIhn+J7SMxjK5oFS+D/FF9d6mlxAmtVw6HKa xiKTlsD5RQthk+b5L4V2/sct6a2JfIJXode59vkUNm35Kvfvt27bM9O3/rMLeF7Eju dLb9zsPtcNHaSE+GWXhliTe9BhxOWj7s4vepSC8Uv3Uk2A4JFeqEZLipSTyXrKCt8o vKjIPaDkhcfWfKZW2YGik+y5hOAGNBOom2Diq6cd7wgX1kER7fCbAIjAvja6LlS+gq ieE3qBSqwnX7JMX207kiUpBQbKsCJ8/y6a/B84zTkMF+rHZnJPc54mFptr0bQ6fZ4y bWxyI1XQGAoI24/LN16Jox38= Received: by sweet-chili.local (Postfix, from userid 1000) id C168898A889; Sun, 16 Oct 2016 10:21:14 +0200 (CEST) Date: Sun, 16 Oct 2016 10:21:14 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161016082113.jhjm5eniyc7zmywh@bunkus.org> References: <81e17a9f-fc07-56cc-db38-9268eb8ae691@gmx.de> <86c12078-eaf3-32c4-08cb-1945c37f2c2b@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <86c12078-eaf3-32c4-08cb-1945c37f2c2b@gmx.de> User-Agent: NeoMutt/20160916 (1.7.0) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Archived-At: Subject: Re: [Cellar] Does the SeekHead specification contradict itself? 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, 16 Oct 2016 08:23:21 -0000 Hey, > There is the (initial) SeekHead Element indexing what's present in the > file so far, then changes are made to the file, e.g. chapters are added, > and any possible Void Element is too small to take the changes without > the file having to be re-written, so the initial SeekHead is updated to > point to another SeekHead written at some place where enough space is > available (in form of a Void Element) or at the end of the file. The > second SeekHead indexes what's not already indexed by the first > SeekHead, e.g. the newly added chapters. That is how it's supposed to work, yes. It's not just about the case of editing a file later on, but in general when the muxer cannot know in advance how much space it'll need and doesn't want to rewrite the whole file. mkvmerge can be configured to include all Cluster Elements in the SeekHead. That requires a lot of space. What mkvmerge does is to create the standard SeekHead near the start of the Segment containing references to the SegmentInfo, Tracks, Chapters/Attachments/Tags (if applicable), but not to the Clusters. After having written all Clusters it will write a secondary SeekHead near the end of the Segment referencing only the Clusters. Additionally it will include a reference to the second SeekHead in the first SeekHead. The SeekEntry Elements from both SeekHeads must be used cumutatively. Kind regards, mosu From nobody Sun Oct 16 01:23: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 A54FA1295FF for ; Sun, 16 Oct 2016 01:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.033 X-Spam-Level: X-Spam-Status: No, score=-1.033 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGGxfJqFoEj1 for ; Sun, 16 Oct 2016 01:23:25 -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 5033A1295FC for ; Sun, 16 Oct 2016 01:23:25 -0700 (PDT) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 93317527386A; Sun, 16 Oct 2016 10:22:50 +0200 (CEST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id EF7925273831 for ; Sun, 16 Oct 2016 10:22:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1476606163; bh=tqWZz0S1EBLNKGuFYhPp7ixepPRC5jQ5RT6Jnmy0m2M=; h=Date:From:To:Subject:References:In-Reply-To:From; b=PO0d67aj0SJdPBiq7rrK9cgx5aG39mUdEQzlymwg2kTgFb98eZcLeRw8n5CaJ1+EO OZ81zzAL7fqbSfvyahgggZDO2Paqgj+apxMLXPtKyNtXh4oLH6dSqxdVrs7v6pMMwp G11EPnkBM8iQ0Gqqgvv9IEqL9lRy0K14y4PCfFafsmQaqaMm1RtaglB+zY5T2jxsGB /cAR6qlcl3pItv3jExMwEdBzk+rEpPBrnWt9Sv8uEj/zk2jaW1akaWknZUMmEN7eLG NobLzXwHtMFJsSYYcVN3nk/Vy6buOQdklMrhV2fiOsxnU/XMrDLceM6+PWZ+fD++pm OaBYCLp7mNP9M/kV/P+PuSB0wIWA6llc3wXZw2ktJWqj7xzcT4q/HfjHjAvtEPEMH0 YCqZtC1C4Qv2FvHalnRp5ZRnGOXGmTGLRmVsE5Y9wb/RnybHY6V61bmhslLrn8Tlvy FxtRX+bKbHxORBQGl6NzBsGPt5RtIWMNHSWahQfq7yYOdWZsanPYEEM+xJ/Lwun+yF 3go5XEBRjC46ONeqMgIVs9q0nSoOSqLQVk4Y0gqGiq/D6AZuzYo0vvHGxgIhr3yyY+ HjgRr/MPBJNma/oQPEzMH5e13EvtCzPf6YxTzqOUVpF/4DMGHmBBlkw9/lPUaaTFAd IF8kPLo2KPxLyOa5l702pxlY= Received: by sweet-chili.local (Postfix, from userid 1000) id 63AE698A896; Sun, 16 Oct 2016 10:22:42 +0200 (CEST) Date: Sun, 16 Oct 2016 10:22:42 +0200 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161016082240.supru4yvl4zqga3p@bunkus.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20160916 (1.7.0) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Archived-At: Subject: Re: [Cellar] Matroska: limit to 2 SeekHead 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: Sun, 16 Oct 2016 08:23:26 -0000 Hey, I'd be fine with this. mkvmerge, mkvpropedit and my GUI's header editor all need at most two. I'm not aware of any tool that can actually create more than two (though my tools can safely handle an arbitrary number when reading the file, but that's just safe coding in play, not an endorsement of allowing an unlimited amount). Kind regards, mosu From nobody Sun Oct 16 01:45: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 25EDA129644 for ; Sun, 16 Oct 2016 01:45:07 -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 KMQD09T9dy5H for ; Sun, 16 Oct 2016 01:45:04 -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 34E72129642 for ; Sun, 16 Oct 2016 01:45:04 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mh9cj-1cHTDA261B-00MGxt for ; Sun, 16 Oct 2016 10:45:01 +0200 References: <55BE1B86.10106@gmx.de> To: cellar@ietf.org From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE X-Forwarded-Message-Id: <55BE1B86.10106@gmx.de> Message-ID: <4bd177ad-3859-75e0-2a4f-b1f80e893c09@gmx.de> Date: Sun, 16 Oct 2016 10:44:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <55BE1B86.10106@gmx.de> Content-Type: multipart/mixed; boundary="------------3A78064EFF7F5037D4D3D0D0" X-Provags-ID: V03:K0:OH2lZtFi5E1Tou+DxtyYCkh04Aa4x6QwcokG7RiOPadQhDMtVBJ u9LYbHTqf/tHGUhr01genvd73MtRhgs7psR0dGqNaeDSTM2QiPm/dKI1UG3B0AB1qw01HJs 5iJ8C544qycx+OX/dS5NdZ9WsO156+gk2JCWrjJJbrxdtXjwTssfaV9GAG66K8WD5g/Ligz zh0VdTD74gI1kcnUc7fpA== X-UI-Out-Filterresults: notjunk:1;V01:K0:OlPm2Vk6i5Y=:OnXND12OLQ35X7ah+/h+dj AZLaFwT7/0WuxObzb9YgLu3qkQFuhrj5tM2nfaFg7Afv4xKxrhECjZZCRMn/1exw/mfjtBDHB aGIKktuj3B/3HhqjZPRiuYoHG/Y3hPJyfz6RrknFebITixg3S2JTMQAsXaNw/13h0w2ZFc/mH ovdCHuRDcKB6Ud03hcu+37k+z19uXrsmk5kXSsPFo0Nd2CblSBIu4ZAXDH05nWAS1Y+5axD7i 2GQISp0Xy+JHx5MZbddI/lYURr6NrVwFAyBRkn5EBkXa6tkQ1iJwDf8pgxQwgo9SAKQf3kkfq vI17LLQtZV0398MEn1e4Vg/lTtDlJtAWibf0aQn9KHwAIqvWsKc1qzUT6iB2/7GV2WrrVOX0w B4hr05Jkh3RjLxGGNIuBh8LsXmPJV0kFcCbn1/e3oZgokpfaKuqvcgsZV7PNEGRG6H/2E38e+ 67+e6Soi+0ASbTlBQoBPJxD4fIfYB+PKuI+nOMDsEz8rQfwP99ZlWQ3tLgiL22D5dDUNKN0vU ILAL1RZe89qepzzn1nUVGJ4sH4OC+LOrTTD76fc7u4QCZniuLU7AUlrqCX0YFJ+A/IqLN8uNN nkj3MgLOrB6uZj2uuqmEoyf1qlgxxfaSwMFu0YX+42pnxHIPgOYU77G0Su8uiNm59h1DBRRl1 CQM9HLZ5TJtw2IuhH2fLnye76TrE6GuZ1qJI24eQqKewuiNq+O7n6AwG4EIriGa3WDGWFg3MN Asc98nUTUvUjqdH8Z8j41BBqJPn7vBPclHjREQjdRSrSUBptbStBk6dtvyw= Archived-At: Subject: [Cellar] Fwd: Proposal of introducing values to localize the name of a track 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, 16 Oct 2016 08:45:07 -0000 This is a multi-part message in MIME format. --------------3A78064EFF7F5037D4D3D0D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, I remembered that I had sent an email to the matroska development list, that got no answers as far as I am aware of. I still think this is a worthwhile idea. Obviously it is just a little gain. I'm sending this to the cellar mailinglist now, because I think that this is in the scope of the standardization and might be relevant for the archivists. BTW the same issue applies to the file title attribute. Best Regards, Sebastian -------- Forwarded Message -------- Subject: Proposal of introducing values to localize the name of a track Date: Sun, 2 Aug 2015 From: Sebastian G. To: Matroska-devel@lists.matroska.org Hello, this proposal is preceded by my question [0] on the user-list and the given response [1]. I'm unaware on how the process of changing the specification works, so I had considered simply writing an email to the development list, but then I figured that it might go lost as changes might not happen quick. Instead I wrote a proposal as a text file that should be attached to this email. I followed a process I'm vaguely familiar with when it comes to changing the specification. This process is from the Tor Project, where bigger changes require a written proposal, which is worked on in its 'draft' state, then considered 'open', while still be update-able, then it gets 'accepted' or 'rejected'. Is is 'closed' when it is implemented or when the proposal is superseded e.g. done, but in a different way. The Tor Project publishes and stores proposals in GIT once they reach the status 'open' and beyond. I'm curious how you handle changing the specification. The attached proposal basically ask the following: > Add additional values that take a translation for each 'Name' field > along with the language that it represents. Best regards, Sebastian G. (bastik) -- [0] http://lists.matroska.org/pipermail/matroska-users/2015-June/006954.html [1] http://lists.matroska.org/pipermail/matroska-users/2015-June/006955.html --------------3A78064EFF7F5037D4D3D0D0 Content-Type: text/plain; charset=UTF-8; name="2015-07-30_trackname_translation.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2015-07-30_trackname_translation.txt" RmlsZW5hbWU6IDIwMTUtMDctMzBfdHJhY2tuYW1lX3RyYW5zbGF0aW9uLnR4dA0KVGl0bGU6 IFRyYWNrbmFtZSB0cmFuc2xhdGlvbg0KQXV0aG9yOiBTZWJhc3RpYW4gRy4gKGJhc3RpaykN CkNyZWF0ZWQ6IDIwMTUtMDctMzANClN0YXRlOiBEcmFmdA0KDQowLiBTdW1tYXJ5IC8gQmFj a2dyb3VuZA0KDQoJVGhpcyBwcm9wb3NhbCBzZWVrcyBhIHdheSB0byBoYXZlIHRyYW5zbGF0 aW9ucyBvZiBlYWNoIHRyYWNrbmFtZSB0bw0KCXNhdGlzZnkgdGhlIG5lZWQgb2YgYSBtdWx0 aWxpbmd1YWwgdGFyZ2V0IGF1ZGllbmNlLg0KDQoJQSB0cmFuc2xhdGlvbiBhcHByb2FjaCwg d2l0aCBuZXcgdmFsdWVzLCB3YXMgY2hvc2VuIHRvIG1haW50YWluDQoJYmFja3dhcmQtY29t cGF0aWJpbGl0eSwgaW5zdGVhZCBvZiBjaGFuZ2luZyB0aGUgJ05hbWUnIHZhbHVlcw0KCXNl bWFudGljcy4NCgkNCg0KMS4gSW50cm9kdWN0aW9uDQoNCglUaGUgdmFsdWUgJ05hbWUnIGlz IHN1cHBvc2VkIHRvIHRha2Ugb25seSBzdHJpbmdzIGZvciBvbmUgbGFuZ3VhZ2UuDQoJSXQg aXMgc3VwcG9zZWQgdG8gYXBwZWFyIG9ubHkgb25jZSBvciBub3QgYXQgYWxsLg0KCUl0IGhh cyBubyBsYW5ndWFnZSBmaWVsZCBhdHRhY2hlZCB0byBpdC4NCg0KCUR1ZSB0byB0aGUgY3Vy cmVudCBzcGVjaWZpY2F0aW9ucyBvZiB2NCBpdCBpcyBub3QgcG9zc2libGUgdG8gaGF2ZQ0K CW11bHRpcGxlIHRyYWNrbmFtZXMgZm9yIHBlb3BsZSB3aXRoIGRpZmZlcmVudCBsYW5ndWFn ZXMgdGhhdCBkb24ndA0KCXVuZGVyc3RhbmQgZWFjaCBvdGhlciBvciBjYW4ndCBldmVuIHJl YWQgdGhlaXIgbGFuZ3VhZ2VzIGNoYXJhY3RlcnMuDQoNCg0KMi4gUHJvcG9zZWQgY2hhbmdl cw0KDQoJQWRkIGFkZGl0aW9uYWwgdmFsdWVzIHRoYXQgdGFrZSBhIHRyYW5zbGF0aW9uIGZv ciBlYWNoICdOYW1lJyBmaWVsZA0KCWFsb25nIHdpdGggdGhlIGxhbmd1YWdlIHRoYXQgaXQg cmVwcmVzZW50cy4NCg0KCVJlY29tbWVuZCB0byBmaWxsIHRoZSAnTmFtZScgd2l0aCB0aGUg bW9zdCBsaWtlbHkgdW5kZXJzdG9vZCBzdHJpbmcNCgljb25zaWRlcmluZyB0aGUgdGFyZ2V0 IGF1ZGllbmNlLiBTdWdnZXN0IHVzaW5nIHRoZSBhZGRpdGlvbmFsIGZpZWxkcw0KCXRvIGxv Y2FsaXplIHRoZSBzdHJpbmcgdG8gdGhlIGRlc2lyZWQgbGFuZ3VhZ2UocykuDQoNCg0KMi4x LiBTdWdnZXN0ZWQgdmFsdWVzDQoNCglBZGQgJ05hbWVUcmFuc2xhdGlvbicgd2hpY2ggd291 bGQgbm90IGJlIG1hbmRhdG9yeSwgY291bGQgYXBwZWFyDQoJbXVsdGlwbGUgdGltZXMsIGhh cyBubyBkZWZhdWx0IHZhbHVlIGFuZCBpcyBhIFVURi04IGVuY29kZWQgc3RyaW5nLg0KDQoJ QWRkICdOYW1lVHJhbnNsYXRpb25MYW5ndWFnZScsIHdoaWNoIHdvdWxkIG5vdCBiZSBtYW5k YXRvcnksIHVubGVzcw0KCSdOYW1lVHJhbnNsYXRpb24nIGFwcGVhcnMuIGl0IGNhbiBvY2N1 ciBtdWx0aXBsZSB0aW1lcywgYXMgb2Z0ZW4gYXMNCgknTmFtZVRyYW5zbGF0aW9uJyBhcHBl YXJzLiBJdCBkb2Vzbid0IG5lZWQgYSBkZWZhdWx0IHZhbHVlLCBiZWNhdXNlDQoJYXBwbGlj YXRpb25zIHRoYXQgd291bGRuJ3QgZmluZCB0aGUgbGFuZ3VhZ2UgdGhleSBhcmUgbG9va2lu ZyBmb3INCgl3b3VsZG4ndCBkaXNwbGF5IGFueSBvZiB0aGUgdHJhbnNsYXRpb25zLiBJdCBp cyBhIHN0aW5nIGluIGZvcm0gYQ0KCUlTTy02MzktMiBlbmNvZGVkIGxhbmd1YWdlLg0KDQoJ QSB2YWx1ZSB0byBzcGVjaWZ5IHRoZSBjb3VudHJ5IGRvZXNuJ3Qgc2VlbSB0byBiZSByZXF1 aXJlZCwgc2luY2UgdGhpcw0KCXByb3Bvc2FsIGlzIGFib3V0IGVuc3VyaW5nIHRoZSB1c2Vy IHVuZGVyc3RhbmRzIHRoZSBkaXNwbGF5ZWQgc3RyaW5nLA0KCW5vdCB0aGF0IGl0IGZpdHMg aGlzIGdlb2dyYXBoaWNhbCBsb2NhdGlvbi4gU3RpbGwgaXQgc2hvdWxkbid0IGh1cnQuDQoJ DQoNCjMuIENvbXBhdGliaWxpdHkgY29uc2lkZXJhdGlvbnMNCg0KCUFzIHdyaXR0ZW4gYWJv dmUsIGNoYW5naW5nIHRoZSBzZW1hbnRpY3Mgb2YgJ05hbWUnIHdvdWxkIHJlc3VsdCBpbg0K CWxvc2luZyBiYWNrd2FyZC1jb21wYXRpYmlsaXR5LiBUaGlzIHNlZW1zIHRvIGJlIHRvbyBt dWNoIGZvciB0bw0KCWxpdHRsZSBnYWluLg0KDQoJUGxheWVycyBlbmNvdW50ZXJpbmcgJ05h bWVUcmFuc2xhdGlvbicgYW5kICdOYW1lVHJhbnNsYXRpb25MYW5ndWFnZScNCglhcmUgc3Vw cG9zZWQgdG8gaWdub3JlIHRoZW0gaWYgdGhleSBkb24ndCB1bmRlcnN0YW5kIHRoZW0uDQoN CglQbGF5ZXJzIHRoYXQgZG9uJ3Qgc3VwcG9ydCB0aGUgbmV3IHZhbHVlcyBhcmUgZXhwZWN0 ZWQgdG8gdXNlDQoJJ05hbWUnIGFzIHRoZXkgaGF2ZSBiZWVuIHByZXZpb3VzbHkuDQoNCglU aHJvdWdoIHNldHRpbmdzIHVzZXJzIGNhbiBjb250cm9sIHRoZWlyIHBsYXllciB0byBkaXNw bGF5IHN0cmluZ3MNCglmb3IgdGhlaXIgbGFuZ3VhZ2UocykgdGhleSB1bmRlcnN0YW5kLiBJ ZiBhIHBsYXllciBkb2VzIG5vdCBmaW5kIA0KCWEgc3RyaW5nIHdpdGggYSBtYXRjaGluZyBs YW5ndWFnZSBpdCBzaG91bGQgZmFsbCBiYWNrIHRvICdOYW1lJy4NCg0KDQo0LiBNaXNzaW5n DQoNCglUaGlzIHByb3Bvc2FsIGRvZXMgbm90IGRlYWwgd2l0aCB0aGUgbGV2ZWwgdGhlIHZh bHVlIHdvdWxkIGJlIGZvdW5kDQoJYXQsIGJ1dCAnTmFtZScgaXMgJzMnIHNvIGl0IGNvdWxk IGJlICczJyBhcyB3ZWxsIGZvciB0aGUgbmV3IHZhbHVlcy4NCg0KCUl0IGRvZXMgbm90IGRl YWwgd2l0aCB0aGUgRU1CTCBJRHMuDQoNCglJdCBkb2VzIG5vdCBjb25zaWRlciBpZiBpdCBy ZXF1aXJlcyB0byBjaGFuZ2UgdGhlIG1hdHJvc2thIHZlcnNpb24uDQoNCglJdCBkb2VzIG5v dCBkZWFsIHdpdGggaW1wbGVtZW50YXRpb24sIG5laXRoZXIgd3JpdGluZyBub3IgcmVhZGlu Zy4NCgkNCg0KNS4gRnV0dXJlDQoNCglJZiB5b3UgZXZlciBoYXZlIHRvIGJyZWFrIGJhY2t3 YXJkLWNvbXBhdGliaWxpdHksIGVpdGhlciBiZWZvcmUNCglvciBhZnRlciB5b3UgY2hhbmdl ZCB0aGUgc3BlY2lmaWNhdGlvbiBhY2NvcmRpbmcgdG8gdGhpcyBwcm9wb3NhbCwNCgl5b3Ug Y291bGQgY2hhbmdlIHRoZSBzZW1hbnRpY3Mgb2YgJ05hbWUnLg0KDQogICANCkFwcGVuZGl4 DQoNCglJU08tNjM5LTIgKGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0xpc3Rfb2Zf SVNPXzYzOS0yX2NvZGVzKQ0KDQo= --------------3A78064EFF7F5037D4D3D0D0-- From nobody Sun Oct 16 05:16:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44D31297CA for ; Sun, 16 Oct 2016 05:16:08 -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 N-13dge1UvgR for ; Sun, 16 Oct 2016 05:16:07 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 663C61297AC for ; Sun, 16 Oct 2016 05:16:07 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t192so100540266ywf.0 for ; Sun, 16 Oct 2016 05:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=x0uKSgwu3GFjh+m/2LtBAKlv6XTGqHB+6t7MJcpO1LM=; b=g8H1NPpz88UEpGiMdaabntmuDb+j/Bz4dSelm5+wLx+yX3D1yvpjNAKdYg6tB0zeV2 Og+mZSXQ6+lgTf3q3zyDa4n+O9jqPvinhW1dthTqGslXTGaCHVg6h/9rAyoxMGOnG5Py EJy6COhqTdWja6j123t4mxbIUVfxL6ha4m6ii5/rLsn+HrLH05gLMTaNh8w48UhGJ7Yk PEJui6Bi+Se0TIELr3ey++jvrsJcKUo+x53z4XRiZ4ReNW5ZGJQ0qpXABCd+Tiqj14tB zj9ptMfWNeM+lCpBt6SruHnbnCvgyLY6ou8vJuDvbkY/4Mqbd+F4h/IwV9iMXvPKxcqV Hkpw== 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=x0uKSgwu3GFjh+m/2LtBAKlv6XTGqHB+6t7MJcpO1LM=; b=bPPL5ZqifGDDGQOdyCHi6pZAVMJoLNXVx+MeElL11sO4eW7ors5kXbo28jC+GvU+hp EHCpCG2GFJoYbN8Vr0vlx/fMU04myGsgYVIoikwqHGj0SoWXXIINOlMWu0X8c5beNU04 jzbd0uQ+7R/5zhhlHeOGVsZsm0/7Qkx7Tw26oyxLlcYBjYQ+m3SegNLclkK4yRgkSlmc tCbV05Hqa/0JBPR+6Xa24pD8qlG//oP9TYzxLaQCeDX63L4LxVqLlfjtc3spm+wDoMQV YTbesvAIo6I01UEPUed0sRaWDDBBJfHezL2qCZW0RJ0+TCITbC2uvEKhwUVWktcrNTtT lgkA== X-Gm-Message-State: AA6/9RkTT1UKDnGHOqplJP2cjX9Q7PZYcw+1cdg2ijiCpO61hsjiUZoB61CJbMs365m4lqd9uO//zo6Z96gjkQ== X-Received: by 10.129.158.12 with SMTP id v12mr18404052ywg.43.1476620166684; Sun, 16 Oct 2016 05:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 05:16:05 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Oct 2016 14:16:05 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 16 Oct 2016 12:16:09 -0000 2016-10-14 4:27 GMT+02:00 Dave Rice : > Hi all, > >> On Oct 11, 2016, at 2:38 AM, Steve Lhomme wrote: >> >> Pull request merged, we can now continue fixing the little issues and >> get going with the Matroska specs. > > I added a new commit to Steve=E2=80=99s pull request [1] to update Matros= ka=E2=80=99s EBML Schema to the newly defined form. Rather than do these up= dates manually I converted the EBML Schema from Steve=E2=80=99s edit throug= h this xsl [2] (then only had to insert the commented out =E2=80=98Timecode= ScaleDenominator=E2=80=99 Element). The pull request's updated EBML Schema = for Matroska can be viewed at https://github.com/Matroska-Org/matroska-spec= ification/blob/parenting/ebml_matroska.xml. Both are merged. > Dave > > [1]: https://github.com/Matroska-Org/matroska-specification/pull/42 > [2]: https://gist.github.com/dericed/ddb0eaa6bb4f0983825e715d45ff6141 > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 05:38:30 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 073171297E4 for ; Sun, 16 Oct 2016 05:38:29 -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 2culQlx37Kb6 for ; Sun, 16 Oct 2016 05:38:27 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEFC1296E4 for ; Sun, 16 Oct 2016 05:38:27 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t192so100700046ywf.0 for ; Sun, 16 Oct 2016 05:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cu2ImgPs2SPbZ6+bW1vxYH96AQlLyQD7pL20TYhDo4o=; b=kEmR8K7DnaxXkvBkk19GWCZE5vC02Qt+7vexfK3coSTSc0gFN4HFwm1QNeEZYfj7i7 4HR1KyF+QN474oizfi7chiYBDMS4geeCJDbGopG5xpgwlyShDMO3ohZsDxWdW184sCxh XJWcTiN80INgJcqV+VD+63N2vYoPl04IR9iiZmkLuYdBytUPreu9TKawfu1nwfG5kb52 PV7pUKvjiKoBNKqjxp1vyWnai7AyXn2JKN/IGTuBxskWBPATczO+YQxu262BIDhlXAZM coPNejOQLsaDuqRQWPqgMUcIzRs8HK2MdrK5AW7boZbA94fdxjVq1jmvKH/N8TmZACGl gO2Q== 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=cu2ImgPs2SPbZ6+bW1vxYH96AQlLyQD7pL20TYhDo4o=; b=gDhIUiOt2vVyahA8CXFgJVHxuUp2r+3m3g/pLyY7xd9f1O2RUaazoh/YVv4G0PD7yz WGQ3ulkBTh8FsuinvJDZPH65zpegyx3foZ2GE3yzlaL924fJ9R4wJH32lNv06XU+oA6B QmA4J/dIrRdWnRldFhsALeuBoTNFxvDOcXCgpHpUQQgVgPkYP5MLvkoEsa9F+JKPc6k5 W9C5jbV8pJAUrZHbh5AMX3LXC9RikPmhyhLAbBNfnkK72kepCF788UGzLUFuuVw8ujMF 7JhQWGMD5xRhu5GGRfcDc1eoTLAzXY1y0CZ4ERJVvKQ1vTQL+DqgvIvBAkUw38GzkyYa Fbgg== X-Gm-Message-State: AA6/9Rmtq70gUldSfZlTSGkbCyf+gVQ38wI3Yn+KqMOYdiJHFw/ELAT3wXPMb0lYeg0hSLGt7aJ4nxpRb9luJg== X-Received: by 10.129.53.76 with SMTP id c73mr18567478ywa.70.1476621506528; Sun, 16 Oct 2016 05:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 05:38:26 -0700 (PDT) In-Reply-To: <71B14F46-4DBA-4959-B621-338F352B76C5@dericed.com> References: <71B14F46-4DBA-4959-B621-338F352B76C5@dericed.com> From: Steve Lhomme Date: Sun, 16 Oct 2016 14:38:26 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] presenting Matroska Elements in document sections 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, 16 Oct 2016 12:38:29 -0000 2016-10-06 6:19 GMT+02:00 Dave Rice : > Hi all, > > The presentation of the Matroska elements in the initial submitted draft was > in odd tables. This pull request adjusts the conversion of Matroska elements > from the ebml_matroska.xml file into a series of sections that each contain > the vocabulary of the EBML Schema with some additional extrapolated content > (listing Child Elements). Here is a preview of the new output in RFC HTML > form and in markdown form. Keep in mind that the past presentation of > Matroska Elements was in a shaded HTML table. > > The total list of Elements (in the proposed format of sections) accounts for > 7,124 of 11,649 lines (over 60% of a 208 page RFC). > > Suggestions for adjustments to make the Elements more clearly or precisely > presented? I would replace Context with the Path. A neat feature in the HTML version would be able to click on a parent element directly from the path. I would not list the children. This is adding extra text that's already found elsewhere. It also becomes invalid if elements are defined in a separate specification. The way to describe a parent in the path can only have one form so it's easy to search the document for elements that have that path in them. On the other hand there are a lot of false positive with children of direct children. When minOccurs or maxOccurs has the default value they may be omitted. > Should an RFC for Matroska include both the EBML Schema of Matroska (a 713 > lines XML document) and the Elements presented in such sections? Should one > of those forms (XML vs Elements sections) be identified as authoritative > over the other? The benefits of using a section per Element is that is > enables better referencing to Element sections within an RFC. For similar > reasons the EBML draft has already had conversion of many of its tables to > sections. I'd say we should have noth. The textual/section is the authorative part. Especially because it can (and will) have finer details on each element. The XML file should be in an Annex as a machine friendly version. > Kind Regards, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 05:42: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 3B22D1297D4 for ; Sun, 16 Oct 2016 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQVq3hkCcAEs for ; Sun, 16 Oct 2016 05:42:29 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 A87961296E4 for ; Sun, 16 Oct 2016 05:42:29 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id 184so56852851yby.2 for ; Sun, 16 Oct 2016 05:42: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; bh=BKT22oiWlYiDBcdVTZrsHMTLydogrr6xrfNXS7+JECk=; b=sYL5nvSgMg3KQlGmsh5rtCkV9pzTgaCR4whuALVObsZzUG2uh5B97gEI+aYeWOFkcw 08WgW/vrqyFiNIKS5dacelypjNhDIfmQb+Noe9cEcwP3YZFQhmmE+AuvAcFKHTuycy79 hJN0SdHPC6IhFWfNElSck1fvlWPN7v4pVoROq9nuiHTtCtLebRo9hWNUHnwsM4ADuc/j 2i4twYe7Wo2MC4o/YVgouQwgDo6RuiFJ6V1f9vC+eIRbGG65iDGMnss30oYMGYe6I36m D0E9S5yK1wTKK1X1fCd411aeRGA8C09DN/Le9fPal8DW1pl+ErNOqpmsT3u8Kjh9wfN7 +sTQ== 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=BKT22oiWlYiDBcdVTZrsHMTLydogrr6xrfNXS7+JECk=; b=cGf7H6o7wv5b4jg2cQ3vwiqfoZV1iisXCkvNE7CnexGMCYcVz8LGrSb0mPDxuGcAEz KKLrL6iWbXUJFRyCrjgbMvl7ZmyMx94T8rIPPtEKHSYbwpj3esRGhK7wpfpGZfISy8ae KsYP5/ykdOoFfM8bZdH03xFTaDk2C0g7CeCutrvmn3I52xf7fHZhXPk/YnOgM79npuT4 Y4y/Tj+LViuDyouNWFvRW8+q4fzSJbthNk6aLPohPAaug9VXQiFUgPOBfqGzbR+968/y 10iCmRBOrmBtQ/dZ+mecclVsUW0YP4BOJzYLkkQ7RWKjczTyyluVf10xKk4AEKV3v81M 5Png== X-Gm-Message-State: AA6/9RkR8LY0RNZ6kEXBI1ahaUOmDg5h8uEkOdd281OJujPWh0T9w463JviOGHzjtOh2ctef89GBDJ0o/GREMg== X-Received: by 10.37.35.80 with SMTP id j77mr19166819ybj.7.1476621748795; Sun, 16 Oct 2016 05:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 05:42:28 -0700 (PDT) In-Reply-To: References: <71B14F46-4DBA-4959-B621-338F352B76C5@dericed.com> From: Steve Lhomme Date: Sun, 16 Oct 2016 14:42:28 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] presenting Matroska Elements in document sections 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, 16 Oct 2016 12:42:31 -0000 2016-10-16 14:38 GMT+02:00 Steve Lhomme : > 2016-10-06 6:19 GMT+02:00 Dave Rice : >> Hi all, >> >> The presentation of the Matroska elements in the initial submitted draft was >> in odd tables. This pull request adjusts the conversion of Matroska elements >> from the ebml_matroska.xml file into a series of sections that each contain >> the vocabulary of the EBML Schema with some additional extrapolated content >> (listing Child Elements). Here is a preview of the new output in RFC HTML >> form and in markdown form. Keep in mind that the past presentation of >> Matroska Elements was in a shaded HTML table. >> >> The total list of Elements (in the proposed format of sections) accounts for >> 7,124 of 11,649 lines (over 60% of a 208 page RFC). >> >> Suggestions for adjustments to make the Elements more clearly or precisely >> presented? > > I would replace Context with the Path. A neat feature in the HTML > version would be able to click on a parent element directly from the > path. > > I would not list the children. This is adding extra text that's > already found elsewhere. It also becomes invalid if elements are > defined in a separate specification. The way to describe a parent in > the path can only have one form so it's easy to search the document > for elements that have that path in them. On the other hand there are > a lot of false positive with children of direct children. Also parent should be removed if we add the path. In HTML the navigation remains easy to do. In a text RFC format that's trickier. But then there's no hyperlink anyway. > When minOccurs or maxOccurs has the default value they may be omitted. > >> Should an RFC for Matroska include both the EBML Schema of Matroska (a 713 >> lines XML document) and the Elements presented in such sections? Should one >> of those forms (XML vs Elements sections) be identified as authoritative >> over the other? The benefits of using a section per Element is that is >> enables better referencing to Element sections within an RFC. For similar >> reasons the EBML draft has already had conversion of many of its tables to >> sections. > > I'd say we should have noth. The textual/section is the authorative > part. Especially because it can (and will) have finer details on each > element. The XML file should be in an Annex as a machine friendly > version. > >> Kind Regards, >> Dave Rice >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 05:57: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 788E1129810 for ; Sun, 16 Oct 2016 05:57:29 -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 f8Zo2kgiDE3i for ; Sun, 16 Oct 2016 05:57:28 -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 A84B41297FE for ; Sun, 16 Oct 2016 05:57:27 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id w3so100050188ywg.1 for ; Sun, 16 Oct 2016 05:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KvBOS5nfczxe92ugWVpjkuNe3r7tA8ZN9pKzagFtn9o=; b=IpJveGvdACvrbvKEOfblSU6jnmpRN4YArpmewhezA5Ce1WXg04KNvD6ZTSLbfwfY0M sRRvq3Dnah4Jgl0HUN/YHKyoknuR011Ja42LQAHB4pztLx13VtEZGOH5ZwKFVSM3LqjJ 9/nSscNgmrcw+6kcE5L4mjC6Qzw3RuL+lQ2aMLcD2FGmmvaayYX253WGb1tgB4IaA2jR Do/8xozPSybo3mAh8Yid99WCQcfghc20vLAmzkPi0ppciCmX9prekHaLh4ww5JNJ84FO sRNoOrIBxBZsOIG08FKMhnoQDcoJy9RQxR4voFMtCF7d8i9P8v1CJ3VDkHYzi0WWPifU cmOQ== 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=KvBOS5nfczxe92ugWVpjkuNe3r7tA8ZN9pKzagFtn9o=; b=hMP9DhSyhvWSwHoOcG6M/i1zmqpmKd8+Sk36gaJ5Mxib1YNYmJgSmPkeA0dFHSrWE1 eYT3uumr/Kvlqdyuk8jhL5eLrk1Ja31ywpaPFQGYe38t3NBG5ZyG/Y1Nnnm7yuRR4ElQ aiKR+k/rBSFPfMK6IYv15VCTwjbaKlwL14FuFa57mmOtGylEhnaZTHTNPEuY4QgbY2ja kc32v1xFfbBzmo/zftlVUjoCAxHkVNgevnheo30WPkvGTl6h+81cIAy4JIKbZvsDKonw 8zH6Z5ZVi3j5mDwtwuw4reVxWf99QVUYw3+7KjYcBCnxkRIwPxdMF6ZLS4BeRuJccCrp rj+A== X-Gm-Message-State: AA6/9Rl7XQqbnOk/Kvlhgvd3IUhZtDigK26w7CVSDYd3+C9PuXWJQUT2DsvtQ0u7tNWM39hJ1XOG1VoFC0O3MQ== X-Received: by 10.13.207.1 with SMTP id r1mr19528431ywd.177.1476622646820; Sun, 16 Oct 2016 05:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 05:57:26 -0700 (PDT) From: Steve Lhomme Date: Sun, 16 Oct 2016 14:57:26 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] EBML Version/Read Version 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, 16 Oct 2016 12:57:29 -0000 So far there was no range defined for EBMLVersion and EBMLReadVersion. The value 0 should be excluded. But I don't think excluding versions other than 1 is good. There might be someday an EBML 2 version which is backward compatible. That shouldn't make them invalid EBML 1 documents just because EBMLVersion is 2. Here's a pull request to fix and clarify what the current value should be: https://github.com/Matroska-Org/ebml-specification/pull/111 -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 06:53:55 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 C1AE8129404 for ; Sun, 16 Oct 2016 06:53:52 -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 MMdTdwua3UC2 for ; Sun, 16 Oct 2016 06:53:50 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB7B7127A91 for ; Sun, 16 Oct 2016 06:53:50 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u124so100702632ywg.3 for ; Sun, 16 Oct 2016 06:53:50 -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=AbgpOCuMGRwFhbrUeGDREKcL2sS3J6ypGDf7Gv97CKg=; b=eiAFS/mo15RgWj3TeEGjgdtDDGU/vkOKtltrjX1Pg+zMVkQC8rVuTtUmCECaOWHvA8 5prBaHiRS5AF8pTb4YJF3F02jcaxSIUn+v/Ut/K8dWLhp/su3mNLLQt2FocJaPeDt2wn GAyOdjFipluHorXsUZZHVXbSQ2m1e4lVmZmd234fDqkCTaFoBz7lb3sFGotSgVWi0eWY on2nX+cwTC71fNq8mCo0+1J6co9s8os4sm4tfaVNUXWUA9g28N/9pnhL8DS3WezQCLry V3aHmO2e+fmWIrBY5tURDfRQ6P71MyPYz1yIrHUdfFazribj7Mlh+kEfw+5TIyhUj2Yx j6pg== 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=AbgpOCuMGRwFhbrUeGDREKcL2sS3J6ypGDf7Gv97CKg=; b=OnQoYzxZ/SrEYFKtWvvDPWdeuVWnr3gN/H56ByoXkcZnpI+wf21xuKTy2NxGHEY0J4 SVStkxbJlFxvYeZT+4iDjpoHvoU5qDFYWaSCbTIF6IF/V4qaCHxKzYgi7CEBYFia7aTG FDjuWXxrvluSewcCtLwMb7Q45YQvoDvPNfe4JlM/miRTBR61nb4rsNEq5JqxWeiVCuYs 5LXm1ExpyqD8sHmQhjSE93OFfUl5ChTNae87EO37k4c19m3AC3ovJVA/pR1H286+mfWj 4ad+vJC1r83GoPgGRZ/VZTRBjKCTVDdb2Jp6H0PjDUjc/WLlpApf31/syvSvkJfb+V9h G4lA== X-Gm-Message-State: AA6/9RnIY53UShAKyi2O+zX8Rbm5nKQaN4xGGw+EJZ9bYDHNqKT6qB4i5rqV0Ooyupymub2SlY1OU1ObAscFCA== X-Received: by 10.13.217.194 with SMTP id b185mr6372768ywe.81.1476626029985; Sun, 16 Oct 2016 06:53:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 06:53:49 -0700 (PDT) In-Reply-To: <61c511fd-cd2e-ee0e-195d-e75aef7e20be@mediaarea.net> References: <05793BC1-EA9A-4FA1-A75A-A52611648253@dericed.com> <61c511fd-cd2e-ee0e-195d-e75aef7e20be@mediaarea.net> From: Steve Lhomme Date: Sun, 16 Oct 2016 15:53:49 +0200 Message-ID: To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska EncryptedBlock Structure and Virtual Block 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, 16 Oct 2016 13:53:53 -0000 2016-10-06 11:15 GMT+02:00 Jerome Martinez : > Le 06/10/2016 =C3=A0 06:19, Dave Rice a =C3=A9crit : >> >> What is the status of the Matroska documentation on "EncryptedBlock >> Structure=E2=80=9D and =E2=80=9CVirtual Block=E2=80=9D? > > > I understood that it is outdated, not really used, and should be removed > from the standard Yes they should be removed. >> The section in the repo has malformed tables [1]. But the correspondi= ng >> section in the matroska.org site is greyed out with the =E2=80=9Cversion= 2=E2=80=9D class in >> the HTML. Should these sections be removed or should they be noted as >> deprecated to a particular version of Matroska? > > > As this is the first version of the standard, I would say that we don't u= se > yet "deprecated" stuff, we reserve it for elements in the first version o= f > the standard and removed in a later version of the standard. > > J=C3=A9r=C3=B4me > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 07:05: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 1BC411294C8 for ; Sun, 16 Oct 2016 07:05:04 -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 fgJ2X0XSq4v6 for ; Sun, 16 Oct 2016 07:05:02 -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 387441294C2 for ; Sun, 16 Oct 2016 07:05:02 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u124so100795778ywg.3 for ; Sun, 16 Oct 2016 07:05:02 -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=9/Z29biT1dZkMVwi0/sVc3fwd7r/1CVk7kAgJZhBMC8=; b=MwMVJYHOC7Fq9vMScfDm1aVUBV+9Jv6Z/sbLakI8bhgEjIs5zV4Vvmcyx2M10/+n1l XqpL3Jq7UWMrB7Hqgdy9mzj5byn/wEXJdBZioorV0uXPjp9zqTdpT/byZV7RSCqJYhJ0 OW4R4NwCzNlgeIdoPvHSn4PoTtAO8lMKmZVMTyqJlS4PK58RUGFoCM+uyW3zKB8k96fg lO9plh59oWLY+swiLi7WeclHXPo3u/GMGfbM7iA4LA9WWL+VlmdO+NJNzUW+xFFh+m2Q Wj6Bc/iPgEO9iGxFHlh1X5uUrbuKEwEFKe91WdFN6Ad6OYEtQNSf5LIX1mV6W9saIDX1 KmFQ== 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=9/Z29biT1dZkMVwi0/sVc3fwd7r/1CVk7kAgJZhBMC8=; b=dh+EK5VqsVmLle/9CZ79mIU4RGlaCyqYCiohfY44KZFumEoBZLIpds5PPXw4XnP1VG cLyznRtQ6nOyn1uee9sH2ogq6ntiM+SsRXIkBmrmc5GcwXLZs+uK91HP1chJw6k6O8jz p2HWifLY9RM/+Cf3jUH6KFiAcrzQ8AQTd7kXnBIUwTqYaSGzgFtzIzLZniuZYrT6VZzc najIn3RwOk0cMy+8eulabQgvz7DzROoY/sXfB8Mde3c09KUKWmtPO2lPjKwjjNjmxygw C+YS0FcrIjXQLQQayJ9X2K0c1938Rlj0nuogxiB7ePcLDEKT0GDRlXK1Zz6R0kNDuuZ1 o0sA== X-Gm-Message-State: AA6/9Rn/3oXHMQIs/lHNK9Q0bmFMFIUzoOoVS7ht84b8D1jjK3pTG+89SpT7GDv8bPD923YzDj4fEYu604hX3Q== X-Received: by 10.129.163.13 with SMTP id a13mr18317403ywh.242.1476626701366; Sun, 16 Oct 2016 07:05:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 07:05:00 -0700 (PDT) In-Reply-To: References: <38E61A25-422A-482B-AFC0-0A6735572FBB@dericed.com> <2164b95e-4f9b-80bb-9bbd-4d246f08bf74@mediaarea.net> <3B99BB70-4228-4DAD-999E-8DBFEA024838@dericed.com> From: Steve Lhomme Date: Sun, 16 Oct 2016 16:05:00 +0200 Message-ID: To: Tessa Fallon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jerome Martinez , Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] review of codec_specs.md for defining use of encodings 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: Sun, 16 Oct 2016 14:05:04 -0000 2016-09-26 3:00 GMT+02:00 Tessa Fallon : > Re: multiple documents, I am not 100% sure and defer to those with more > experience at the IETF to indicate if there is precedent; if it is not pa= rt > of the core spec, then it/they could be published as informational drafts= . > However, before that I would ask for group consensus to ensure that this > fragmentation is absolutely necessary, and that the implications are full= y > outlined and understood. > > Also, I'd ask for it to be made clear why, if the items in question are n= ot > part of the core spec, they merit publication under the CELLAR charter, a= s > we'd be adding two more documents to our already substantial list of > documents to be published. Why ? Because it needs to be (a) normative document(s) that are necessary for interoperability. But it doesn't have any impact on how Matroska data are handled. It's just a description of the payload. These data are opaque to the Matroska level of parsing data. Also as stated before the content may be updated more often than the Matroska specifications. In the future new codecs will be defined with their own RFC to describe the payload. Or they might be part of different specifications. So there's no need to have some settled in the Matroska specifications and some outside. IMO they all belong outside. > Best > > Tessa > > > On Sep 25, 2016 17:37, "Dave Rice" wrote: >> >> >> > On Sep 25, 2016, at 3:07 PM, Jerome Martinez >> > wrote: >> > >> > Le 25/09/2016 =C3=A0 00:05, Dave Rice a =C3=A9crit : >> >> [...] >> >> >> >> The terms =E2=80=98private data=E2=80=99 and the `CodecPrivate Elemen= t` seems to be >> >> referenced in the same way. Are these the same things? If so, they sh= ould be >> >> made consistent. >> > >> > They are same thing, as described: "CodecPrivate element: Private data >> > only known to the codec." but right, maybe we need to add more informa= tion >> > about it. >> >> If CodecPrivate is referenced by nearly every definition of an encoding = in >> Matroska, perhaps we should split the =E2=80=98Description=E2=80=99 into= =E2=80=98CodecPrivate >> Usage=E2=80=99 and =E2=80=98Description=E2=80=99. >> >> >> The phrase "The private data is void.=E2=80=9D is used several times = in the >> >> document. Does this mean that the `CodecPrivate Element` is stored bu= t as an >> >> `Empty Element`? Could the `CodecPrivate Element` just not be present= if not >> >> needed? >> > >> > Not present if not needed is the implemented way. Maybe rephrasing the >> > sentence would make it more explicit (e.g. "no CodecPrivate Element" >> > instead, for stream format not needing configuration bytes). >> > >> >> [...] >> >> >> >> Other questions: >> >> Should the Matroska specification provide enough info for a user to >> >> independently define support for an encoding in Matroska? Or should c= odec >> >> support somehow be =E2=80=98registered=E2=80=99 via Matroska and/or C= ELLAR? >> > >> > First, the list of supported formats and their respective definition >> > should be in a separate document (updated more often than the core spe= c). >> >> +1 >> >> For the chairs, if we are splitting an intention of one document >> (Matroska) into several documents (Matroska, Matroska Encoding Registry, >> Matroska Metadata Registry) do we need to update the charter? >> >> > And yes, each new format should be registered, because there is an >> > unique codec name namespace. Maybe defining "X_" prefix as private (bu= t mime >> > RFC now discourages use of "x-", so maybe not a good idea). >> >> +1 >> >> > Now, the question is where to define CodecPrivate. e.g. for FFV1 we >> > already defined it in the FFV1 spec but we can not update AVC specs fo= r >> > that. >> > >> >> [...] >> >> >> >> For a Matroska validation that finds something like V_MPEG4/ISO/AVC i= n >> >> Matroska. Should it be considered as unsupported (most MKV files!)? >> > >> > Matroska-centric validation tools should not validate raw streams, tha= t >> > includes CodecPrivate part. This is the role of a more general validat= ion >> > tool (a tool described as "validation of Matroska files" would not val= idate >> > the CodecPrivate part, a tool described as "validation of Matroska fil= es + >> > FFV1 and FLAC" would use the description of how FFV1 and FLAC are >> > registered) >> >> There are still some tests permitted by only the Matroska specification. >> For instance with a revision we could make it clear which Codec ID MUST = or >> MUST NOT have an associated `CodecPrivate Element`. >> >> Dave Rice >> _______________________________________________ >> 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 > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 07:22: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 20C2D1294AD for ; Sun, 16 Oct 2016 07:22:18 -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 DiJI_wJxYmCX for ; Sun, 16 Oct 2016 07:22:16 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B3F127A90 for ; Sun, 16 Oct 2016 07:22:16 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t192so101516148ywf.0 for ; Sun, 16 Oct 2016 07:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9ZL77HQSxyNWxUslgp2E4RTskpg+uXrWvw7NUc8Fwbo=; b=o5Ip+Pj2rS3k4QLqdbcCUhKpmRxKDMnKe6LkD3KePuf74yrQnkkh8WjsjE7B8lANi+ wXJkoTIywOBJgqY6qtiNWSJM29q3XyPFbWsIjwEtIq66Q6Hk+ftQZkqmHSiqITsgmZaC Wb1UoevB8h83s+SBP5xKRREuW+XBRVJBlUMtteVUYWsh7wMfd9HPZ8uNh9YSYC2NdYA/ JtnRkN+WcDgWvbUO0AvewWh6upjaam8as601v418m3otR6R8iB4HlHV0Qf1L1m1wFAuz zVQeF7muC29saWKHEJQSwFYFT6dP+WVk3HFWW4K1ilvTNrAHXNUfGtZ0znrHzJymx6kZ GH1g== 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=9ZL77HQSxyNWxUslgp2E4RTskpg+uXrWvw7NUc8Fwbo=; b=SiD16nPNrkAMRIP83PHIQxDdwCIKyhT/OFQR/UeUwTsw9zOaVnZ07fTFlTdbsKaphD IhWGnuKuK0jAO2K5FlClAIb2cEjeUI+G8wBcsQi1gennB9ETgDLCSQ7bDPqwtRwQz2ya WPlKPSZeCpRh+s6ld/ATuZLsws/uQWIeG4G7QG4lj8tVnn0Lm7b+lpwfMcjX0XvVtI6M 9OzlSHtChPndMv5bUCxu9VaCvBWkW33KwNSVV0URUQbogxsr1pma/pRDgV28S4b72Q6z ha8t+MGH4Q7Utv2TfKDU1NANZkK0CFpFFfx0VTYRzP9ayvcu0ngupuTwUNU2vpyG0WPU 6N/A== X-Gm-Message-State: AA6/9RmE//LT+0Nj+qhYVnT8xrTFaLQt/DlDv3LTx4sjSQRrS4aWxAi6C9LCnHURgt1obAhGxqku6hu2NLXvLw== X-Received: by 10.129.167.3 with SMTP id e3mr20062029ywh.60.1476627735345; Sun, 16 Oct 2016 07:22:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 07:22:14 -0700 (PDT) In-Reply-To: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> References: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> From: Steve Lhomme Date: Sun, 16 Oct 2016 16:22:14 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska Menu Specifications 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, 16 Oct 2016 14:22:18 -0000 Files exist, playback exists. But it's mostly proof of concept things. It's the kind of thing that will definitely benefit from proper documentation. But for now we may strip the elements that are specific to menus so it can be specified properly without blocking things people actually use. There are also 2 possible chapter codecs in use the Matroska one and the DVD one. The Matroska is simple enough and supported in a few players so we may keep that one and/or work on that in priority. 2016-10-10 21:52 GMT+02:00 Dave Rice : > Hi all, > There is a draft document at https://matroska.org/technical/menu/index.html which has been incorporated into our Matroska working repository at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.md. > > The document appears more like a wishlist than a specification. Is there any further information available on Menu features of Matroska? Should the document be removed for now? Do Matroska menus exist? > Dave > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 07:26: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 45D211294DA for ; Sun, 16 Oct 2016 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnJ7g6VSd07K for ; Sun, 16 Oct 2016 07:26:30 -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 65869127A90 for ; Sun, 16 Oct 2016 07:26:30 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id 184so57305718yby.2 for ; Sun, 16 Oct 2016 07:26:30 -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=FglC8quz4kVsNcZhfj3YHGbz+Z2OYdaXUNSYkWszhG0=; b=v2v7D/wW9Zv2gpDDVC+0uWZLvRBttHejMDhP0QctZDmdSmE7IKKN4gCZRyK3q/H5bU 0T+H7Uu6h2mq88q8w9XtLWtMEAbA50ivA6MRekpc8t7xGA5+K9+ZvdG33nk4G+4ZEWE3 +H3uRfvEiy/WxozlCEyJIwkB8bgWcs5JmQbNKqPNurDrFW6ax8JbDykCgrih58v/yB0n AzBmUHzLMhonPaEJtXCpwRA7hmHLQfBfUCfYuefhMoFze9kttY6XHVz9oSoxYSdlPUK2 0orUEhL+cxnUflHv3cSZgVvBS7HzlEyTlA/VafjLlt6R0iuiPLEakCZs1TYbpJbkDkIZ hT8w== 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=FglC8quz4kVsNcZhfj3YHGbz+Z2OYdaXUNSYkWszhG0=; b=TJA3hngb/yi6uNVZCq2kCg2Qaq24xsyDg7sAgV2DUTnMquQ0GL800aOiXPkZJ4DAVE ebjq3FIRrNYsI0gciXnDoyKk2tJYCcHgQsVTmT8wMJ1IEwK3FfzxM+IhTySbnaUzx2hm Epn0dMx379cPrXywhqxs1TuTua4yeQWo8K04K75tPg3zcgU0uLdcUQMSg7GyO04eA7Cy MYrCsrMu9Dx2wJekJf9RLF6L2IZTJUZ4IiTmlqOQIu66b/9KuwQm/EyudRxkBYqgIbTA lWBWdqjRmeGibNrUkW9dS0KDiRsjFhDkAc1f6mawTNtpcVSpnEcvHHZGky7OQRfAzP6r w4DA== X-Gm-Message-State: AA6/9Rkye3cCGGzSvYuQyeXmaBt9zN2gxrythDWDWgIyNFuSNzF0GSUvIs4WdzTvXJWnvj55xWEyT/amib7u+A== X-Received: by 10.37.35.80 with SMTP id j77mr19577640ybj.7.1476627989584; Sun, 16 Oct 2016 07:26:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 07:26:28 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Oct 2016 16:26:28 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Bradshaw , Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 16 Oct 2016 14:26:32 -0000 2016-10-14 4:34 GMT+02:00 Dave Rice : > > On Aug 30, 2016, at 12:40 PM, Michael Bradshaw wrote= : > > Matroska currently doesn't have a way to specify projection information f= or > 360/VR videos. Google's Spherical Video V2 RFC draft was just updated a f= ew > days ago to include some new elements specifying projection and viewer po= se > 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 conversat= ion > 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 > > > After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on the st= andardizing > spatial media, I drafted a pull request at > https://github.com/Matroska-Org/matroska-specification/pull/53 for > consideration which adds the projection elements (from Michael=E2=80=99s = link above) > to Matroska=E2=80=99s EBML Schema. This pull request is dependent on anot= her pull > request at https://github.com/Matroska-Org/matroska-specification/pull/42 > which is an adjustment to Matroska=E2=80=99s EBML Schema based on recent = EBML > specification updates. > > Some considerations from writing this pull request: > > There are several Matroska elements that describe enumerated values and t= he > `Projection` Child Elements make use of enumeration lists as well. Curren= tly > the practice in Matroska element definitions appear to enumerate in this > form =E2=80=9C(1: description of the first option, 2: description of anot= her option, > 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile to standard= ize how enumeration > lists are expressed in the EBML Schema, so that rather than: > > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" id=3D"0x767= 1" > type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-3= " webm=3D"1"> > Describes the projection used for this video > track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap, 3: > Mesh) > > > we could have something like > > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" id=3D"0x767= 1" > type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-3= " webm=3D"1"> > Describes the projection used for this video > track. > Rectangular > Equirectangular > Cubemap > Mesh > > > Is breaking down enumeration into a structure like this helpful or > over-engineering? No I think it's really worth. There could be a documentation for each element, and in various languages. > Also although I see the documentation for Projection in webm, but is ther= e a > comparable set of documentation for ambisonics in webm? The draft at > https://github.com/google/spatial-media/blob/9bc4691f748a553a06b4b297f05e= c2a62e53da1b/docs/spatial-audio-rfc.md > only references mp4. > > Dave Rice > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 07:55: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 A9BA61294C4 for ; Sun, 16 Oct 2016 07:55:24 -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 DdqT6GE11_De for ; Sun, 16 Oct 2016 07:55:22 -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 D29C21294BE for ; Sun, 16 Oct 2016 07:55:21 -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 u9GEtJ9J018700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 16 Oct 2016 16:55:19 +0200 Received: from Castor.local ([80.78.76.132]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u9GEtIG1050199 for ; Sun, 16 Oct 2016 16:55:18 +0200 Date: Sun, 16 Oct 2016 16:55:18 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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] 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: Sun, 16 Oct 2016 14:55:25 -0000 Steve Lhomme wrote: >2016-10-14 4:34 GMT+02:00 Dave Rice : >> >> On Aug 30, 2016, at 12:40 PM, Michael Bradshaw >wrote: >> >> 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 >> >> >> After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on the >standardizing >> spatial media, I drafted a pull request at >> https://github.com/Matroska-Org/matroska-specification/pull/53 for >> consideration which adds the projection elements (from Michael=E2=80=99s= link >above) >> to Matroska=E2=80=99s EBML Schema. This pull request is dependent on ano= ther >pull >> request at >https://github.com/Matroska-Org/matroska-specification/pull/42 >> which is an adjustment to Matroska=E2=80=99s EBML Schema based on recent= EBML >> specification updates. >> >> Some considerations from writing this pull request: >> >> There are several Matroska elements that describe enumerated values >and the >> `Projection` Child Elements make use of enumeration lists as well. >Currently >> the practice in Matroska element definitions appear to enumerate in >this >> form =E2=80=9C(1: description of the first option, 2: description of ano= ther >option, >> 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile to standar= dize how >enumeration >> lists are expressed in the EBML Schema, so that rather than: >> >> > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >id=3D"0x7671" >> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-= 3" >webm=3D"1"> >> Describes the projection used for this >video >> track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap, >3: >> Mesh) >> >> >> we could have something like >> >> > path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >id=3D"0x7671" >> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0-= 3" >webm=3D"1"> >> Describes the projection used for this >video >> track. >> Rectangular >> Equirectangular >> Cubemap >> Mesh >> >> >> Is breaking down enumeration into a structure like this helpful or >> over-engineering? > >No I think it's really worth. There could be a documentation for each >element, and in various languages. +1 >> Also although I see the documentation for Projection in webm, but is >there a >> comparable set of documentation for ambisonics in webm? The draft at >> >https://github.com/google/spatial-media/blob/ >9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio-rfc.md >> only references mp4. >> >> Dave Rice >> > From nobody Sun Oct 16 07:58:40 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 8CD181294E8 for ; Sun, 16 Oct 2016 07:58: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 BDsK5Js8KEHb for ; Sun, 16 Oct 2016 07:58:36 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20A912948B for ; Sun, 16 Oct 2016 07:58:36 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id t192so101804249ywf.0 for ; Sun, 16 Oct 2016 07:58:36 -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=2DR0cYOXO3DL3zhEq98j2/EzwlpqEsf6pBr1PeK3rdc=; b=VBCuT706dI85BnKP3jkOQPpZV9Qn/g5QAmvczi9vk+FQpNcO5hEQLAmWLTgiBYlv1X uCfrZXuy6pODJvGdBZd2/Mn8DK4chPqe3RZqjY97rFLGYe+goSgcISk8m81Yx/PQR7+q MZrzQeEJidLvKXH814D27uTIku+rSW+iUgYsakHMlRNqx2TQsO1iAVHNtKGDLVlqaRLx lDgMIL1TvdYOrDVi5KyeU+xzcBbI/bDOKNFJHt2Kcu7TCGCF1twlsyf3joNvODqEFu4w A0B6d91wzIFzcYGGXt6ce3CvMJJIGJAj1dsw/gP65OyroPiujjE2BHR2NY+Nemi8s4kM 7HCg== 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=2DR0cYOXO3DL3zhEq98j2/EzwlpqEsf6pBr1PeK3rdc=; b=TCuYGmnVf88NKCzK36QWRwvKV8ADE76hTo3NYKeRGOtoa666nLdfSpattQFFc4BfQI T9GpXy1+sjA39PdSNsiPxKpntJVcbi5JpX9krAedrNC8JbkMbzH6YgklFw6RG0b4XwJn /AI+OdLlOMH+FZoqNB4idE+EotgFtO+B3b3rbEtUTUNTkYlP+5nRQsuuYTzpmFojY0Pt au9tktOkUAaU1SaSPmrhp9vgAcUY4zZrk04RnSM0/nimca3RnxZ+he+skNJWKTCNNzn6 7cpedunKwP669g5+Ux0bCDEnc8bN6rgGag19OKgrNuAe2LOvel6BEdaKfl9ngNywPU/s tBuA== X-Gm-Message-State: AA6/9Rm2JkamuI4eajPcZEKujd6tZbbam71zFwXNVV/S96NpyGBHjOGBvLEkGBLeG6YMoJ6YCB52X7xe/suDiw== X-Received: by 10.13.199.135 with SMTP id j129mr18850927ywd.247.1476629915839; Sun, 16 Oct 2016 07:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 07:58:35 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Oct 2016 16:58:35 +0200 Message-ID: To: Reto Kromer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission 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: Sun, 16 Oct 2016 14:58:38 -0000 I added an "issue" so we don't forget https://github.com/Matroska-Org/ebml-specification/issues/114 2016-10-16 16:55 GMT+02:00 Reto Kromer : > Steve Lhomme wrote: > >> 2016-10-14 4:34 GMT+02:00 Dave Rice : >>> >>> >>> On Aug 30, 2016, at 12:40 PM, Michael Bradshaw >> >> wrote: >>> >>> >>> 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 >>> >>> >>> >>> After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on the >> >> standardizing >>> >>> spatial media, I drafted a pull request at >>> https://github.com/Matroska-Org/matroska-specification/pull/53 for >>> consideration which adds the projection elements (from Michael=E2=80=99= s link >> >> above) >>> >>> to Matroska=E2=80=99s EBML Schema. This pull request is dependent on an= other >> >> pull >>> >>> request at >> >> https://github.com/Matroska-Org/matroska-specification/pull/42 >>> >>> which is an adjustment to Matroska=E2=80=99s EBML Schema based on recen= t EBML >>> specification updates. >>> >>> Some considerations from writing this pull request: >>> >>> There are several Matroska elements that describe enumerated values >> >> and the >>> >>> `Projection` Child Elements make use of enumeration lists as well. >> >> Currently >>> >>> the practice in Matroska element definitions appear to enumerate in >> >> this >>> >>> form =E2=80=9C(1: description of the first option, 2: description of an= other >> >> option, >>> >>> 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile to standa= rdize how >> >> enumeration >>> >>> lists are expressed in the EBML Schema, so that rather than: >>> >>> >> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >> >> id=3D"0x7671" >>> >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0= -3" >> >> webm=3D"1"> >>> >>> Describes the projection used for this >> >> video >>> >>> track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap, >> >> 3: >>> >>> Mesh) >>> >>> >>> we could have something like >>> >>> >> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >> >> id=3D"0x7671" >>> >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D"0= -3" >> >> webm=3D"1"> >>> >>> Describes the projection used for this >> >> video >>> >>> track. >>> Rectangular >>> Equirectangular >>> Cubemap >>> Mesh >>> >>> >>> Is breaking down enumeration into a structure like this helpful or >>> over-engineering? >> >> >> No I think it's really worth. There could be a documentation for each >> element, and in various languages. > > > +1 > > >>> Also although I see the documentation for Projection in webm, but is >> >> there a >>> >>> comparable set of documentation for ambisonics in webm? The draft at >>> >> https://github.com/google/spatial-media/blob/ >> 9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio-rfc.md >>> >>> only references mp4. >>> >>> Dave Rice >>> >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 08:00:41 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 EFBB112958A for ; Sun, 16 Oct 2016 08:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqx9kXzn1z7Q for ; Sun, 16 Oct 2016 08:00:38 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2901295D0 for ; Sun, 16 Oct 2016 08:00:37 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id 184so57455503yby.2 for ; Sun, 16 Oct 2016 08:00:37 -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=39L572ZuoREizCwvVXuM7wZ/P0kZrXz8LYVktE0HG24=; b=xfZOjjcuwCik6x0/qtxck5MR3XDHNjI7nb7Hsd2CSibRwM3SxpAmExQ8L5KkNhngn0 1VJXinDzyEvPoH//XYBe6EAZhr7CfSlTN8e+NE9eLIRtp7tfaDKOqvAAEzVmMu2Irobe 4Nq9R9eDlSQfY/pIBzMPMNp48gtlH3GkbVbMX7Us1fdqdC40X1qWV/Re6FHOe5E/WCBI Yd8lvkBb25aCtajdhFhp0qA+Wzq6ojJ8IxuZAeQ0sVwo1vzHLUsJfkRe2Vw36+fHA27U itJHX1gLZg3TtDN3OLhi078o8T5iakCFPqPBRkN6P7gcCoJmRBbNBG37YCxjPwZbUV9i c3MQ== 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=39L572ZuoREizCwvVXuM7wZ/P0kZrXz8LYVktE0HG24=; b=Rjymc7KlwsSKhb8Z+CZYQU2Y9RzEQ/Sqtip2orxAfJp8YzVaUaVxTutPbyIiseR07e GhdGj1dVsvNDn/Xz4b9h/fANWQidPnzLW/vTHhQ7m32mX8y6mhlcY4YvH76U+H0hS+pW hJ+s4sfnNo8UxQoKb9sUWvXatIlfUqzdAvJ/6+vMawq/MjVVnz5yiICA87LXo6uIIm5N yhOVU1FOuLTdO9F1DHzYuzrybJ91uBXh/mvZqEPRNlxhgQdlvPfAknH3o0BLIRLueqCw kzaFMDOdgkQ40jYSvu1DksK9FBsWAJsOCCSM41fQFgrVhEAeVcXXwLNPvpKQceXqBLuS 6tcg== X-Gm-Message-State: AA6/9RnX7nYaYqD1JlZJhQs/6zgqbiWFn7bYZbmG4Q+M2QYX+rGaTxexrEqpLqC/SdOQqkuNcsHG/QCxXnAYkQ== X-Received: by 10.37.125.135 with SMTP id y129mr18961576ybc.179.1476630037114; Sun, 16 Oct 2016 08:00:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 08:00:36 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 16 Oct 2016 17:00:36 +0200 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska: limit to 2 SeekHead 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: Sun, 16 Oct 2016 15:00:40 -0000 2016-10-15 17:51 GMT+02:00 Dave Rice : > HI all, > > I submitted a small pull request to limit SeekHead to two occurrences [1]= (in practice an option first SeekHead for the beginning of the file and an= optional second SeekHead for the end of the file). The documentation on th= e SeekHead element https://github.com/Matroska-Org/matroska-specification/b= lob/gh-pages/order_guidelines.md#seekhead doesn=E2=80=99t explicitly say th= at SeekHead elements are limited to two, but the documentation doesn=E2=80= =99t seem to leave any purpose remaining for a third SeekHead. Additionally= the past XML structure for defining Matroska structure had no mechanism to= express an Element usage limit beyond 0, 1 or infinite, so such a constrai= nt is only recently feasible. > > From a survey of 75,732 Matroska files: > > - 11,897 has 0 SeekHead Elements > - 53,859 has 1 SeekHead Element > - 9,976 has 2 SeekHead Elements > - 0 has >2 SeekHead Elements > > Is there any scenario where >2 SeekHead Elements makes sense? Any likelih= ood that >2 SeekHead Elements was ever used? For the current usage of SeekHead, no. And I can't think of other cases. > Dave Rice > > [1]: https://github.com/Matroska-Org/matroska-specification/pull/54 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 08:05: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 5967E12955F for ; Sun, 16 Oct 2016 08:05:32 -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 dZinVXwqEqtZ for ; Sun, 16 Oct 2016 08:05:31 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B771294CC for ; Sun, 16 Oct 2016 08:05:31 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t193so101433287ywc.2 for ; Sun, 16 Oct 2016 08:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nN7LBskLYd6BUfqtN/vzGKGR/HndlN5rNlhfBakFR58=; b=DuY7FIPGVDQRn35+sMc7N0giHV8k3SPkmIp+i1w+2A9qmwSjLp5RL3YkZi7SsIgJXd l+mhmI2aep7e+ixDY/bhtZ43qw+dQLqTCyx1NLaqRNSMiyOeMq5eD1FiO3tsh3J7HkAY k5ktEHNv7LrCtmNgXglsWoIPtX0X8+vG928Mujy+0Jc8HX6ZdOS4Kl0/yTfEve5N1Sg5 OdPKi6L2CdaRXm4wwZXGU9Swxmwnac5/uuanyGU712Ui65xQJUQASx/PCa4OcXCWGFkA gDNDCx22lgOAlyC0+UIljtUu257tkpmp5vfF1+BdmoCb1j3Enfcud0O5sHHVu0fPZVVK CIpw== 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=nN7LBskLYd6BUfqtN/vzGKGR/HndlN5rNlhfBakFR58=; b=Iwpdxd7jWExfG/mmYMS1OBrqO3VQqms0RKtXS9T0eu0ZbCf/oa/+QXX6JJTXZiUSku nPmT+R74Tu8LZTFOnKKk/7LKpkyiasRMpBqSeRRcfGkEEMRIPPScAPtVMBZYTTcnuoTt XuJB65e9qy27W0dE3QK898mpykTPNwCoMOqcPd02wmRToXHdqau81ec8alltosN8dQnV HzavUR9lFbYVgROW0OlTDeYCjmbEZUNLUhVTf1vjK/o3jYMyaQKuBymigTQMs4EVgdfS AccANl5URgfkEbLev+84duQsrZoPyc3PSmeFG8hs0Kw6cRg5luVbQVBLTNKJgapDgzWc fy8w== X-Gm-Message-State: AA6/9RkNZ7jZ/EGvnpYKuC8WQCPQJbGAdKyxq4fRCtMQtdh/MRL9dFlTRxm+SclmwNoS0KYFSAaNn6j1G6Z5aw== X-Received: by 10.13.217.194 with SMTP id b185mr6657889ywe.81.1476630330358; Sun, 16 Oct 2016 08:05:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.40.87 with HTTP; Sun, 16 Oct 2016 08:05:29 -0700 (PDT) In-Reply-To: <4bd177ad-3859-75e0-2a4f-b1f80e893c09@gmx.de> References: <55BE1B86.10106@gmx.de> <4bd177ad-3859-75e0-2a4f-b1f80e893c09@gmx.de> From: Steve Lhomme Date: Sun, 16 Oct 2016 17:05:29 +0200 Message-ID: To: "Sebastian G. " Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Fwd: Proposal of introducing values to localize the name of a track 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, 16 Oct 2016 15:05:32 -0000 The goal is good. The text attachment is a PITA to comment. I think the way is done is not correct as it doesn't link a translation to its text (from what I understood). Also it's possible to tag track names in all the languages you want and with a lot more metadata to add. The Track Name element is from a time where tags didn't exist at all. But the proper way is to use tags. 2016-10-16 10:44 GMT+02:00 Sebastian G. : > Hello, > > I remembered that I had sent an email to the matroska development list, > that got no answers as far as I am aware of. > > I still think this is a worthwhile idea. Obviously it is just a little gain. > > I'm sending this to the cellar mailinglist now, because I think that > this is in the scope of the standardization and might be relevant for > the archivists. > > BTW the same issue applies to the file title attribute. > > Best Regards, > Sebastian > > > -------- Forwarded Message -------- > Subject: Proposal of introducing values to localize the name of a track > Date: Sun, 2 Aug 2015 > From: Sebastian G. > To: Matroska-devel@lists.matroska.org > > Hello, > > this proposal is preceded by my question [0] on the user-list and the > given response [1]. > > I'm unaware on how the process of changing the specification works, so I > had considered simply writing an email to the development list, but then > I figured that it might go lost as changes might not happen quick. > > Instead I wrote a proposal as a text file that should be attached to > this email. I followed a process I'm vaguely familiar with when it comes > to changing the specification. This process is from the Tor Project, > where bigger changes require a written proposal, which is worked on in > its 'draft' state, then considered 'open', while still be update-able, > then it gets 'accepted' or 'rejected'. Is is 'closed' when it is > implemented or when the proposal is superseded e.g. done, but in a > different way. > > The Tor Project publishes and stores proposals in GIT once they reach > the status 'open' and beyond. I'm curious how you handle changing the > specification. > > The attached proposal basically ask the following: > >> Add additional values that take a translation for each 'Name' field >> along with the language that it represents. > > Best regards, > Sebastian G. (bastik) > > -- > [0] http://lists.matroska.org/pipermail/matroska-users/2015-June/006954.html > [1] http://lists.matroska.org/pipermail/matroska-users/2015-June/006955.html > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 16 08:42:35 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 4019D129437 for ; Sun, 16 Oct 2016 08:42:05 -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 EhmxgLca5vw0 for ; Sun, 16 Oct 2016 08:42:01 -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 BDEFD12943B for ; Sun, 16 Oct 2016 08:42:00 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfAog-1cJUIZ2Aws-00OkP0; Sun, 16 Oct 2016 17:41:57 +0200 References: <55BE1B86.10106@gmx.de> <4bd177ad-3859-75e0-2a4f-b1f80e893c09@gmx.de> To: Codec Encoding for LossLess Archiving and Realtime transmission From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <116231ca-d05e-84ed-bf34-6d7fc9207fc5@gmx.de> Date: Sun, 16 Oct 2016 17:41:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:ZM+xRGvE8OyZf6r84xahZhGUYsJX6F+CcQ6cRF/kaFKtvg/kUfB dbA2MCqMZZQqAnVvWfCLM+Sou+Aj0CbXh+s/UPg40QJF5xMVVsw7HtYXGOXjdTRLQvgzU5T KkVwry5i6JJK7w3uDU/JN/L0eu153rhcQAqxdCEAWkACUhFHzXeGs4fPi3B2Tm6yiJLwR5N QOTRhd+1ONbbBwAHQ8+4g== X-UI-Out-Filterresults: notjunk:1;V01:K0:0sLeB+mS60Q=:WNk9gy18RyFjELhB2/UXfu S4IXeiUojen2WsMK+FBaqRBsAgxwX5yp2CK2sdxlIn2qIu4pggTcv5/U4F6gmwmpUiDKJ8TJq SzkhMPWxIdULjAPeMF0wB63I94QAYrcNNWlmIKK7kxOMciJIdxeEyj9SkzohO1ZVtsAblxzij N2Lu9QTe3Z5LF6MvTCtEl5Jq1qBPSfV20TvO2Ntq3mNAgJp999bBPj73EnItKPaZBb7Z/tSDF f9uXCYM4TfGz08/5LfkQqCmvR0E2Feo0X09b2aJDbxsnhPb8l1jairnxuIOJ49rmc1HiHriK6 TZNKAdJTFCFPAeEHUobLhGa2C9OfE1xitRva3tngm88L5ubFascY3bzfH8YmdYtvMOnXM36By SH+eFTbQ4sMi80AYFr4QGqJdaEAVQTScFADnhcYRYbQo7xhX8tv53Jm8rjbwyhIKnqLzPT6qs 7aiXHNmG9q52G9KzejUylRufIg6XNICJFzSdWHfCdePDqCbh+ow+WuLgBALL0ux7FkefzrErD HLJN8UZnGLQS82kqHANTIA4kp5ECFXjfNVrUpSmojW9ZVdSO6sd/5q5Xqr9aFFwRCFJvOmzco iKrjfXjAmJtMSQrxLZm16NvpsIKFp+LoaSBhmiOQo75qtQFKI9/ejTK5+C4bhj+Wg8jiBcVKB JcADym3U70QLUKAxt63np7OFcDBvrjEW7dlOwDntcojX7ykAosXnctik6fPDYT4rOGYNH315Z EEkjXzjTT0PFVtRyiTvTeOfgSV9XKcG+JYmB5gsgr2rX+oxpmYnx3QH+iWIMqBdBJgDQZc4jW Gqpk9+m Archived-At: Cc: Steve Lhomme Subject: Re: [Cellar] Fwd: Proposal of introducing values to localize the name of a track 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, 16 Oct 2016 15:42:05 -0000 16.10.2016, 17:05 Steve Lhomme: > The goal is good. The text attachment is a PITA to comment. Indeed, but it won't be necessary as it appears. > I think the way is done is not correct as it doesn't link a > translation to its text (from what I understood). There was supposed to be a parent/child relationship. > Also it's possible to tag track names in all the languages you want > and with a lot more metadata to add. The Track Name element is from a > time where tags didn't exist at all. But the proper way is to use > tags. Right, that was not obvious to me. Tags are the way to go then. Best Regards, Sebastian > 2016-10-16 10:44 GMT+02:00 Sebastian G. > : >> Hello, >> >> I remembered that I had sent an email to the matroska development list, >> that got no answers as far as I am aware of. >> >> I still think this is a worthwhile idea. Obviously it is just a little gain. >> >> I'm sending this to the cellar mailinglist now, because I think that >> this is in the scope of the standardization and might be relevant for >> the archivists. >> >> BTW the same issue applies to the file title attribute. >> >> Best Regards, >> Sebastian >> >> >> -------- Forwarded Message -------- >> Subject: Proposal of introducing values to localize the name of a track >> Date: Sun, 2 Aug 2015 >> From: Sebastian G. >> To: Matroska-devel@lists.matroska.org >> >> Hello, >> >> this proposal is preceded by my question [0] on the user-list and the >> given response [1]. >> >> I'm unaware on how the process of changing the specification works, so I >> had considered simply writing an email to the development list, but then >> I figured that it might go lost as changes might not happen quick. >> >> Instead I wrote a proposal as a text file that should be attached to >> this email. I followed a process I'm vaguely familiar with when it comes >> to changing the specification. This process is from the Tor Project, >> where bigger changes require a written proposal, which is worked on in >> its 'draft' state, then considered 'open', while still be update-able, >> then it gets 'accepted' or 'rejected'. Is is 'closed' when it is >> implemented or when the proposal is superseded e.g. done, but in a >> different way. >> >> The Tor Project publishes and stores proposals in GIT once they reach >> the status 'open' and beyond. I'm curious how you handle changing the >> specification. >> >> The attached proposal basically ask the following: >> >>> Add additional values that take a translation for each 'Name' field >>> along with the language that it represents. >> >> Best regards, >> Sebastian G. (bastik) >> >> -- >> [0] http://lists.matroska.org/pipermail/matroska-users/2015-June/006954.html >> [1] http://lists.matroska.org/pipermail/matroska-users/2015-June/006955.html >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > > From nobody Sun Oct 16 12:02:09 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA731294B9 for ; Sun, 16 Oct 2016 12:02:07 -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 uI2ePmqDJrfR for ; Sun, 16 Oct 2016 12:02:04 -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 E3F921294E4 for ; Sun, 16 Oct 2016 12:02:02 -0700 (PDT) Received: from [192.168.178.25] ([91.47.50.157]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lurin-1cuzzF0eob-01067i for ; Sun, 16 Oct 2016 21:02:00 +0200 To: cellar@ietf.org References: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> From: hubblec4 Message-ID: <0aa94dda-1393-8476-e0aa-7df4897ce060@gmx.ch> Date: Sun, 16 Oct 2016 21:01:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.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:HydXGwSbxrVYf9HHbm+afPOBo9G/iEoe+ez4v7D2KC+xjBp8PH0 XcAcjsw1MIlcEiv1+XwLud5d5B5z2pX6EpDOJ4hEH9065wDtCXSXckZpILDW3P5Cz9BQ8nD mAoaFdTCnL4ozuQvOE+kFzHeSSkyrXi+A5WUp5SwMhS0gYqX25UbKM6tuFGSEsPXqLOTgAq /3mgNS7rTi/D22w77N+cQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:K40POXZsSd0=:K9xRtOvceuij2l2y1FbHO/ /ZKapSY+Y+8ZMwSk7XyzS5c2gnsznELEZV2PVQVytCuVE/XSi+Pa1LYjqG0mWs+80a/LTxjRo qFpXOJ7PvuHfBDiAMuMrnwhfgX9ZcnRHzJMO42NY689YPckeVQjfPf+2dIZ6aTX0/XEU0gBq8 9Dbiv2CXlGgBnh31a1KOoBv+RF463YGzr2SEtZLfx8VZ0lkrdzIwS/GBynjVn/cpwDZstuYAc PZG4/qViNXQY+52ApTAteCkk9T5aee3OQeFAzZ+s8FfIy8vJ9KiYKtZIgA6qv9zoPX5t0Fetc 5HanLtgysB0M3ztXUmfQgmcnWBnED/7u1CDO6Eg6EFVQBotOQAiD0fJqJDQ8glC4RkdZbjB/u ZY+61LHhNxj9DHS7j4qUCeTVUZzL995sg6p5ohKjHWYqLSfvWYeAn6ja45KRWfdIctjZpiN7F ybfMsGU0+ZFldQ4L66ERUYx/3HKc6aeSZcVzwOaDdCp8InxqNz45a4b+vLpHM0ho6h6Pb2Ky2 xP0J3BFwHc49cl6BaLJO35JeDAYeKjYgHGl7BJg+II91GrRt+M4x3EMb2VlG0ShwDCmpqNI0Z 4kQE2JioxlDxu7PVDkmsm59XN5jzMiOJ9fPCZS4f3qy15x+JDmIC31qokBBLu2gVdMG+ISD8X 7vZkay0uToVzV0CfTUNpxjqW3H3wB/Kgt7AdIpI3d/GnqvomxE6vxGpEfzWGGo9aVy3EZge34 EC2l0vl9MlpsTkRM8uZxp1yeGqA0L+mH1JdskvkJxXDER0NcZj2t0uLwDQwi0a6E1XpuU3mEF /qQ84Jf Archived-At: Subject: Re: [Cellar] Matroska Menu Specifications 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, 16 Oct 2016 19:02:07 -0000 Hi all, Am 16.10.2016 um 16:22 schrieb Steve Lhomme: > Files exist, playback exists. But it's mostly proof of concept things. > > It's the kind of thing that will definitely benefit from proper > documentation. But for now we may strip the elements that are specific > to menus so it can be specified properly without blocking things > people actually use. There are also 2 possible chapter codecs in use > the Matroska one and the DVD one. The Matroska is simple enough and > supported in a few players so we may keep that one and/or work on that > in priority. To understand the DVD menu system, I got a lot of headache, cause its so complex. But the Matroska menu is simple and it has at the moment only one command(GoToAndPlay-ChapterUID). We could add more commands which we need to create a simple but powerful Matroska menu. Menu features like: Track selection (which is supported by HAALI via Tags(TRACKSETEX)) Vob Buttons -> Matroska Buttons to controll the Matroska content in the player screen should be included. Maybe I have a little bit time than I could write an overview about the Matroska menu. - Infos about what is possible in theory and what in practice - Needed things to play a Matroska menu - Controlling - Using - Samples - and more In what for a format should I write this Infos? Best regards Martin > 2016-10-10 21:52 GMT+02:00 Dave Rice : >> Hi all, >> There is a draft document at https://matroska.org/technical/menu/index.html which has been incorporated into our Matroska working repository at https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.md. >> >> The document appears more like a wishlist than a specification. Is there any further information available on Menu features of Matroska? Should the document be removed for now? Do Matroska menus exist? >> Dave >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > From nobody Mon Oct 17 09:32: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 00A30129967 for ; Mon, 17 Oct 2016 09:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, 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 sDBnGR8Lm28R for ; Mon, 17 Oct 2016 09:32:50 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6133C129963 for ; Mon, 17 Oct 2016 09:32:42 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id j37so193947966ioo.3 for ; Mon, 17 Oct 2016 09:32:42 -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=5TINbrGA3lbs3rST2apJRTdd6hTro6i4jirR5Tf9tJ4=; b=WEQBalOQtMG9wJ4lWlzzOxoM0ASTzwoxX0D8hOe7DuS9E4PalmleP5gXyc8ETNj8sX 59cq+MoeDKQRQ15MQq0MktqSmoxIP6RcjbZJ4/GR0uRkOCLNSUYRSEUp4BEai0h+63UJ 6ws+Ku1R4JIgNeESMb9v/ow4K6WLWGDghvu28nnpmGDJoPgZTA21WQ7m+FWNxMwGARR9 Usy5uw8SzjG/Ui4bf2nJVJ+FlNTZ57zLs4fgLxedRBPAf1/IS+Mex6CJIz0ghgukOKbw xKS5g6HZzdwqDo5R+5ZaoW7EdGuZMoXjwY9wWblHVqYRW+DbqyFaJE6UlqTGXp7IRjL3 atSg== 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=5TINbrGA3lbs3rST2apJRTdd6hTro6i4jirR5Tf9tJ4=; b=a/NZraxYFbSJ20htKnqf65sqqInQ07WNYPzM0yWbTguXR9CYBxPq+lASQFlcIbD8oE Heoq+xK+sCvNbPGbrs5XpQp4ooh7INQXwQAUz472HzQLSvuSLeq+V5uOTVg79z9Izizy lXDxTrihEmiMFfykgBzqYmRVoash9hk9Md4Mj+m+BofQsvThUZreCGkTi43jpnhln3jW J7NyzqOpXuqd12MJ4mkapVh1Nm4xHPZAo2AeIcz3Fl9di31vrV2CS7ChEEYORjkGJ3eD 8nwbQRN+9bbWrYKMj7BAJNicMyl+N7mIgsMExnhjU/rEvufDQRPlhhickOnKWJyWguXb eURA== X-Gm-Message-State: AA6/9Rn9KO2mP4goF0UYys9++zTm5+uIGbYS75Z1lmYtWS39p0Ol9yuGjx2IjUzbbHkwyG8LHd/0xwZ2gdheIvsj X-Received: by 10.107.129.69 with SMTP id c66mr27710727iod.111.1476721961460; Mon, 17 Oct 2016 09:32:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.28.199 with HTTP; Mon, 17 Oct 2016 09:32:20 -0700 (PDT) In-Reply-To: References: From: Michael Bradshaw Date: Mon, 17 Oct 2016 09:32:20 -0700 Message-ID: To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a113f9b0cf2713d053f121f41 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Reto Kromer 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: Mon, 17 Oct 2016 16:32:53 -0000 --001a113f9b0cf2713d053f121f41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Matroska currently lacks audio channel layout specification (the container has no way to indicate which channel corresponds to which speaker for surround-sound layouts). As is, channel layout has to be read/inferred from audio codec-level data (whether stored in CodecPrivate or somewhere else). For Opus and Vorbis this isn't much of a problem, but I don't know enough about other codecs to know if some might be problematic in Matroska. While we're considering ambisonics in Matroska, I think we should also consider the broader channel layout issue. If we add ambisonic-related info to Matroska, I think we also need to add surround-sound channel info to Matroska. If we don't add surround-sound channel info to Matroska, then perhaps we shouldn't for ambisonics either and instead require the codec to determine the channel order (e.g. https://tools.ietf.org/html/draft-ietf-codec-ambisonics). Generally I think it might be nice to have this information in Matroska, but there are *tons* of ways to arrange audio channels and I'm concerned about specification bloat. On Sun, Oct 16, 2016 at 7:58 AM, Steve Lhomme wrote: > I added an "issue" so we don't forget > https://github.com/Matroska-Org/ebml-specification/issues/114 > > 2016-10-16 16:55 GMT+02:00 Reto Kromer : > > Steve Lhomme wrote: > > > >> 2016-10-14 4:34 GMT+02:00 Dave Rice : > >>> > >>> > >>> On Aug 30, 2016, at 12:40 PM, Michael Bradshaw > >> > >> wrote: > >>> > >>> > >>> 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 viewe= r > >> > >> 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 > >>> > >>> > >>> > >>> After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on th= e > >> > >> standardizing > >>> > >>> spatial media, I drafted a pull request at > >>> https://github.com/Matroska-Org/matroska-specification/pull/53 for > >>> consideration which adds the projection elements (from Michael=E2=80= =99s link > >> > >> above) > >>> > >>> to Matroska=E2=80=99s EBML Schema. This pull request is dependent on = another > >> > >> pull > >>> > >>> request at > >> > >> https://github.com/Matroska-Org/matroska-specification/pull/42 > >>> > >>> which is an adjustment to Matroska=E2=80=99s EBML Schema based on rec= ent EBML > >>> specification updates. > >>> > >>> Some considerations from writing this pull request: > >>> > >>> There are several Matroska elements that describe enumerated values > >> > >> and the > >>> > >>> `Projection` Child Elements make use of enumeration lists as well. > >> > >> Currently > >>> > >>> the practice in Matroska element definitions appear to enumerate in > >> > >> this > >>> > >>> form =E2=80=9C(1: description of the first option, 2: description of = another > >> > >> option, > >>> > >>> 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile to stan= dardize how > >> > >> enumeration > >>> > >>> lists are expressed in the EBML Schema, so that rather than: > >>> > >>> >>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" > >> > >> id=3D"0x7671" > >>> > >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D= "0-3" > >> > >> webm=3D"1"> > >>> > >>> Describes the projection used for this > >> > >> video > >>> > >>> track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap, > >> > >> 3: > >>> > >>> Mesh) > >>> > >>> > >>> we could have something like > >>> > >>> >>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" > >> > >> id=3D"0x7671" > >>> > >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range=3D= "0-3" > >> > >> webm=3D"1"> > >>> > >>> Describes the projection used for this > >> > >> video > >>> > >>> track. > >>> Rectangular > >>> Equirectangular > >>> Cubemap > >>> Mesh > >>> > >>> > >>> Is breaking down enumeration into a structure like this helpful or > >>> over-engineering? > >> > >> > >> No I think it's really worth. There could be a documentation for each > >> element, and in various languages. > > > > > > +1 > > > > > >>> Also although I see the documentation for Projection in webm, but is > >> > >> there a > >>> > >>> comparable set of documentation for ambisonics in webm? The draft at > >>> > >> https://github.com/google/spatial-media/blob/ > >> 9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio-rfc.md > >>> > >>> only references mp4. > >>> > >>> Dave Rice > >>> > >> > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a113f9b0cf2713d053f121f41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Matroska currently lacks audio channel layout specificatio= n (the container has no way to indicate which channel corresponds to which = speaker for surround-sound layouts). As is, channel layout has to be read/i= nferred from audio codec-level data (whether stored in=C2=A0CodecPrivate or= somewhere else). For Opus and Vorbis this isn't much of a problem, but= I don't know enough about other codecs to know if some might be proble= matic in Matroska.

While we're considering ambisonic= s in Matroska, I think we should also consider the broader channel layout i= ssue. If we add ambisonic-related info to Matroska, I think we also need to= add surround-sound channel info to Matroska. If we don't add surround-= sound channel info to Matroska, then perhaps we shouldn't for ambisonic= s either and instead require the codec to determine the channel order (e.g.= =C2=A0h= ttps://tools.ietf.org/html/draft-ietf-codec-ambisonics).

=
Generally I think it might be nice to have this information in M= atroska, but there are *tons* of ways to arrange audio channels and I'm= concerned about specification bloat.

On Sun, Oct 16, 2016 at 7:58 AM, Steve Lhom= me <slhomme@matroska.org> wrote:
I added an "issue" so we don't forget
https://github.com/Matroska-Org/eb= ml-specification/issues/114

2016-10-16 16:55 GMT+02:00 Reto Kromer <lists@reto.ch>:
> Steve Lhomme wrote:
>
>> 2016-10-14 4:34 GMT+02:00 Dave Rice <dave@dericed.com>:
>>>
>>>
>>> On Aug 30, 2016, at 12:40 PM, Michael Bradshaw <mjbshaw@google.com>
>>
>> wrote:
>>>
>>>
>>> Matroska currently doesn't have a way to specify projectio= n
>>
>> information for
>>>
>>> 360/VR videos. Google's Spherical Video V2 RFC draft was j= ust updated
>>
>> a few
>>>
>>> days ago to include some new elements specifying projection an= d 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 i= ntend 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 inf= ormation in
>>> Matroska. Assuming there hasn't been any, is there interes= t 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<= br> >>
>> candidates?
>>>
>>>
>>> (For the record, I'm just breaking the ice here and gettin= g the
>>
>> conversation
>>>
>>> started; this isn't a proposal to adopt the new elements j= ust quite
>>
>> yet)
>>>
>>>
>>> [1]:
>>>
>> https://github.com/= google/spatial-media/blob/master/docs/spherical-video
>> -v2-rfc.md#webm-matroska
>>>
>>>
>>>
>>> After hearing Andrew Scherkus=E2=80=99s presentation at Demuxe= d on the
>>
>> standardizing
>>>
>>> spatial media, I drafted a pull request at
>>> https://github.com/Matros= ka-Org/matroska-specification/pull/53 for
>>> consideration which adds the projection elements (from Michael= =E2=80=99s link
>>
>> above)
>>>
>>> to Matroska=E2=80=99s EBML Schema. This pull request is depend= ent on another
>>
>> pull
>>>
>>> request at
>>
>> https://github.com/Matroska-<= wbr>Org/matroska-specification/pull/42
>>>
>>> which is an adjustment to Matroska=E2=80=99s EBML Schema based= on recent EBML
>>> specification updates.
>>>
>>> Some considerations from writing this pull request:
>>>
>>> There are several Matroska elements that describe enumerated v= alues
>>
>> and the
>>>
>>> `Projection` Child Elements make use of enumeration lists as w= ell.
>>
>> Currently
>>>
>>> the practice in Matroska element definitions appear to enumera= te in
>>
>> this
>>>
>>> form =E2=80=9C(1: description of the first option, 2: descript= ion of another
>>
>> option,
>>>
>>> 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile = to standardize how
>>
>> enumeration
>>>
>>> lists are expressed in the EBML Schema, so that rather than: >>>
>>> <element name=3D"ProjectionType"
>>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\Pr= ojectionType)"
>>
>> id=3D"0x7671"
>>>
>>> type=3D"uinteger" minOccurs=3D"1" minver= =3D"4" default=3D"0" range=3D"0-3"
>>
>> webm=3D"1">
>>>
>>>=C2=A0 =C2=A0<documentation lang=3D"en">Describ= es the projection used for this
>>
>> video
>>>
>>> track. Valid values: (0: Rectangular, 1: Equirectangular, 2: C= ubemap,
>>
>> 3:
>>>
>>> Mesh)</documentation>
>>> </element>
>>>
>>> we could have something like
>>>
>>> <element name=3D"ProjectionType"
>>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\Pr= ojectionType)"
>>
>> id=3D"0x7671"
>>>
>>> type=3D"uinteger" minOccurs=3D"1" minver= =3D"4" default=3D"0" range=3D"0-3"
>>
>> webm=3D"1">
>>>
>>>=C2=A0 =C2=A0<documentation lang=3D"en">Describ= es the projection used for this
>>
>> video
>>>
>>> track.</documentation>
>>>=C2=A0 =C2=A0<enum value=3D"0">Rectangular</= enum>
>>>=C2=A0 =C2=A0<enum value=3D"1">Equirectangular&= lt;/enum>
>>>=C2=A0 =C2=A0<enum value=3D"2">Cubemap</enum= >
>>>=C2=A0 =C2=A0<enum value=3D"3">Mesh</enum>= ;
>>> </element>
>>>
>>> Is breaking down enumeration into a structure like this helpfu= l or
>>> over-engineering?
>>
>>
>> No I think it's really worth. There could be a documentation f= or each
>> element, and in various languages.
>
>
> +1
>
>
>>> Also although I see the documentation for Projection in webm, = but is
>>
>> there a
>>>
>>> comparable set of documentation for ambisonics in webm? The dr= aft at
>>>
>> https://github.com/google/spatial-media/b= lob/
>> 9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio= -rfc.md
>>>
>>> only references mp4.
>>>
>>> Dave Rice
>>>
>>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



--
Steve Lhomme
Matroska association Chairman

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

--001a113f9b0cf2713d053f121f41-- From nobody Mon Oct 17 18:07:24 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 ABA811293F8 for ; Mon, 17 Oct 2016 18:07:22 -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 MYGqA3To0eBR for ; Mon, 17 Oct 2016 18:07:21 -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 A461B1279EB for ; Mon, 17 Oct 2016 18:07:21 -0700 (PDT) Received: from [172.56.35.68] (port=60556 helo=[172.20.10.6]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bwIsB-000Lqo-Rt; Mon, 17 Oct 2016 21:07:20 -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, 17 Oct 2016 21:07:17 -0400 Content-Transfer-Encoding: quoted-printable 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: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EBML Version/Read Version 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, 18 Oct 2016 01:07:23 -0000 > On Oct 16, 2016, at 8:57 AM, Steve Lhomme = wrote: >=20 > So far there was no range defined for EBMLVersion and EBMLReadVersion. > The value 0 should be excluded. But I don't think excluding versions > other than 1 is good. There might be someday an EBML 2 version which > is backward compatible. That shouldn't make them invalid EBML 1 > documents just because EBMLVersion is 2. But if there is someday an EBML version 2, that would be because a new = version of the EBML specification is defined. In a future EBML version 2 = specification, I presume the range for EBMLVersion would be updated from = `1` to `1-2`. I suggest, per "EBML version 1 specification", that EBMLVersion=3D2 is = considered invalid, since "EBML version 1 specification=E2=80=9D won=E2=80= =99t know what to expect. Per "EBML version 2 specification=E2=80=9D, both EBMLVersion=3D1 and = EBMLVersion=3D2 are valid. > Here's a pull request to fix and clarify what the current value should = be: > https://github.com/Matroska-Org/ebml-specification/pull/111 I suppose I prefer not to accept this pull request. Why permit an EBML = Writer to say EBMLVersion=3D2 or EBMLVersion=3D999, etc when such format = is not even conceived or defined yet? Dave= From nobody Mon Oct 17 19:46: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 D87551293FE for ; Mon, 17 Oct 2016 19:46:29 -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 8j0lU59Dllq4 for ; Mon, 17 Oct 2016 19:46:28 -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 85FA3124281 for ; Mon, 17 Oct 2016 19:46:28 -0700 (PDT) Received: from [172.56.35.68] (port=63804 helo=[172.20.10.6]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bwKQ5-0010Zb-Nx for cellar@ietf.org; Mon, 17 Oct 2016 22:46:28 -0400 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 17 Oct 2016 22:46:23 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Subject: [Cellar] [WIP] XML Schema for EBML Schema 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, 18 Oct 2016 02:46:30 -0000 Hi all, I posted a draft XML Schema in this pull request = https://github.com/Matroska-Org/ebml-specification/pull/115/files. This = xsd allows an EBML Schema to be validated. For instance using the = EBMLSchema.xsd from the PR [1] and the ebml_matroska.xsd (expression of = an EBML Schema) from the matroska-specification repo [2], one can = validate ebml_matroska.xml (a draft EBML Schema) via: =20 xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and see = a few such as RFC5168 and RFC5935 that do. I think an XML Schema can = help the working group internally by giving us a method to verify that = Matroska=E2=80=99s EBML Schema (ebml_matroska.xsd) stays valid during = updates by the working group, though it could also be incorporated into = the specification for EBML. Is putting an XML Schema in an RFC advisable = or should this stay external to the RFC? =46rom using the draft EBMLSchema.xsd on ebml_matroska.xml, it = highlights a few issues with the current ebml_matroska.xml. - un-standardized attributes Matroska=E2=80=99s EBML Schema includes unstandardized attributes such = as =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2=80=98webm=E2= =80=99. Should the EBML Schema allow unknown attributes or should these = three be removed or incorporated? Feasible we could have a separate = ebml_webm.xml document since it=E2=80=99s a separate EBML Document Type. = Also the =E2=80=98divx=E2=80=99 elements could be removed and put into = an EBML Schema extension (though we=E2=80=99d have to define how EBML = Document Type Extensions should work). - HTML embedded in The definitions in the element include HTML tags: , =
, and . Should HTML tags be permitted in EBML Schema = definitions? Possibly we could reduce the need for many(all?) of them by = extending EBML Schema with additional elements such as methods to handle = enumeration and references (see = https://github.com/Matroska-Org/ebml-specification/issues/114). - maxOccurs is not defined as integer only In the recent updates to the EBML Schema, maxOccurs used to be an = integer or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2= =80=99, but is now integer only. However in ebml_matroska.xml we have 43 = elements defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should = we change maxOccurs back or find some method of expressing an unbounded = occurrence limit with an integer? Dave Rice [1]: = https://raw.githubusercontent.com/Matroska-Org/ebml-specification/dc1803df= bc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd [2]: = https://raw.githubusercontent.com/Matroska-Org/matroska-specification/gh-p= ages/ebml_matroska.xml= From nobody Tue Oct 18 09:57: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 AF96F1294E6 for ; Tue, 18 Oct 2016 09:57:21 -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 M13zyuNyeXkB for ; Tue, 18 Oct 2016 09:57:18 -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 2E5111294F2 for ; Tue, 18 Oct 2016 09:57:18 -0700 (PDT) Received: from [146.96.19.240] (port=11426 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bwXhP-002lll-Lg; Tue, 18 Oct 2016 12:57:17 -0400 From: Dave Rice Message-Id: <3BB8346D-3BA7-4CE3-B8BB-691903B7A52E@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4685409D-4E13-4FCE-962F-42DACAB1968E" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 18 Oct 2016 12:57:09 -0400 In-Reply-To: To: Ethan T Gates References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] NYC cellar meetup? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 16:57:22 -0000 --Apple-Mail=_4685409D-4E13-4FCE-962F-42DACAB1968E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Ethan and others, Thanks for this message. In regards to how people can contribute, we've = been trying to file tickets in the associated repositories and these = vary from very easy to complex. I'd suggest that if you'd like = contribute but feel the need for support, please feel welcome to ask for = a mentor. Here's a highlight of some of the more approachable issues: https://github.com/Matroska-Org/ebml-specification/issues/117 = This is basically just a find/replace to correct a misspelling of = "Occurence" with "Occurrence", mostly in this section: = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#path = . https://github.com/Matroska-Org/matroska-specification/issues/48 = This issue is resolved basically by removing = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/overh= ead.md = from the matroska-specification repo as the discussion suggests = that it should not be part of the specification. https://github.com/Matroska-Org/matroska-specification/issues/50 = This calls for some sections to be reviewed against the EBML = specification to ensure that they are redundant and then remove the = identified redundant sections from the Matroska specification. https://github.com/Matroska-Org/ebml-specification/issues/114 = This requires some XML knowledge, but this is a recommendation that = enumeration lists be moved from an informal "(1: option A, 2: option = B)"-style structure. A example of the current enumeration list is here: = https://github.com/Matroska-Org/matroska-specification/blob/2c0a14d3e01171= 75c1bf224c7be6496eedb28541/ebml_matroska.xml#L195 = . So this issue is = two part, first propose a new structure, then once accepted adjust = ebml_matroska.xml to use it. https://github.com/Matroska-Org/matroska-specification/issues/49 = This relates to the metadata documenation at = https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/taggi= ng.md = . Moritz has noted the meaning of tag names prefixed by = underscores at = https://github.com/Matroska-Org/matroska-specification/issues/49#issuecomm= ent-254039146 = , so a section should be added to tagging.md to explain = the meaning of tag names prefixed by underscores and what they imply and = what a Reader should do with them. https://github.com/Matroska-Org/matroska-specification/issues/46 = This involves cleaning up Matroska's method for defining how to define = codecs in Matroska. There's a markdown table that needs to be cleaned up = and the structure of codec definitions themselves needs to be documented = (such as the name style of Codec IDs, what information is needed in a = description). If you'd like to take a particular issue please note so in the Github = issue tracker and feel welcome to ask any clarifying questions or = request a mentor there so that we can assign both to the issue. Thanks = much, Dave Rice > On Oct 9, 2016, at 9:48 AM, Ethan T Gates wrote: >=20 > Hi all, >=20 > Another novice lurker here - I second Brendan's thanks to you all for = both the content and admirable form of this process and Genevieve's = desire to observe and soak up as much as I can, as I've been doing by = poring over these threads. I would love to attend a NYC meeting, could = make weekends work, and might humbly suggest a quick word about how = exactly newbies or those without much or any experience with programming = or metadata standardization can contribute! (provision of sample files? = copy editing documentation?) You all have been doing a stellar job of = getting CELLAR's mission out into the wider archival community lately = and I think interest in participation is only going to keep growing. >=20 > Best, > Ethan Gates >=20 > On Sat, Oct 8, 2016 at 7:01 PM, Genevieve HK > wrote: > 1. Yes!=20 > 2. weekends are doable > 3. +1 metadata (but I generally would just be attending to listen & = learn more about *everything*) >=20 > Thanks for planning this!=20 >=20 >=20 > On Sat, Oct 8, 2016 at 3:00 PM, > wrote: > Send Cellar mailing list submissions to > cellar@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/cellar = > or, via email, send a message with subject or body 'help' to > cellar-request@ietf.org >=20 > You can reach the person managing the list at > cellar-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cellar digest..." >=20 > Today's Topics: >=20 > 1. Re: NYC cellar meetup? (ashley.blewer@gmail.com = ) > 2. Re: NYC cellar meetup? (Murray, Kate) > 3. Re: NYC cellar meetup? (Doug Ewell) > 4. Re: NYC cellar meetup? (Reto Kromer) > 5. Re: NYC cellar meetup? (Brendan Allen) >=20 >=20 > ---------- Forwarded message ---------- > From: ashley.blewer@gmail.com > To: Dave Rice > > Cc: cellar@ietf.org > Date: Fri, 7 Oct 2016 21:13:10 +0200 > Subject: Re: [Cellar] NYC cellar meetup? >=20 >=20 > > On Oct 7, 2016, at 8:52 PM, Dave Rice > wrote: > > > > Hi all, > > > > There's been some offlist discussion about having a meetup in New = York City on cellar issues (quite a few New Yorkers on the list). In = general I think the agenda could be informal but address things like: = discussion of open issues, how to contribute, planning upcoming work, = collaboration. > > > > Nick Krabbenhoeft has offered to arrange for a meeting space at New = York Public Library. > > > > So some questions for the group: > > > > 1. Is such a meeting of interest? > > > Yes! >=20 > > 2. Should it occur during an evening or the weekend? An evening may = be easier to local folks to coordinate but would be too late for most = remote participation from Europe. > > > Also prefer evenings but more so prefer potential Euro participation! >=20 > > 3. Recommendations for agenda items, things you'd like to learn, = things you'd like to see done? >=20 > FLAC attack. >=20 >=20 > > Dave Rice > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: "Murray, Kate" > > To: "'cellar@ietf.org '" > > Cc:=20 > Date: Fri, 7 Oct 2016 15:16:30 -0400 > Subject: Re: [Cellar] NYC cellar meetup? > Thanks for this Dave. I'm game to (virtually) meet up with other = interested folks if scheduling permits. >=20 > Best from Kate > ********** > Kate Murray > Technology Policy Directorate > Library of Congress > 202-707-4894 > kmur@loc.gov >=20 >=20 >=20 > -----Original Message----- > From: Dave Rice [mailto:dave@dericed.com ] > Sent: Friday, October 07, 2016 2:53 PM > To: cellar@ietf.org > Subject: [Cellar] NYC cellar meetup? >=20 > Hi all, >=20 > There's been some offlist discussion about having a meetup in New York = City on cellar issues (quite a few New Yorkers on the list). In general = I think the agenda could be informal but address things like: discussion = of open issues, how to contribute, planning upcoming work, = collaboration. >=20 > Nick Krabbenhoeft has offered to arrange for a meeting space at New = York Public Library. >=20 > So some questions for the group: >=20 > 1. Is such a meeting of interest? >=20 > 2. Should it occur during an evening or the weekend? An evening may be = easier to local folks to coordinate but would be too late for most = remote participation from Europe. >=20 > 3. Recommendations for agenda items, things you'd like to learn, = things you'd like to see done? >=20 > Dave Rice >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Doug Ewell > > To: cellar@ietf.org > Cc:=20 > Date: Fri, 07 Oct 2016 15:45:05 -0700 > Subject: Re: [Cellar] NYC cellar meetup? > Dave Rice wrote: >=20 > > Nick Krabbenhoeft has offered to arrange for a meeting space at New > > York Public Library. >=20 > That's rather a distance from Colorado, so rather than making the = trek, > I'll just repeat my request that BCP 47 be adopted as the > language-tagging standard instead of (or at least in strong preference > to) the existing approach which combines ISO 639-2/B with ccTLDs. >=20 > -- > Doug Ewell | Thornton, CO, US | ewellic.org >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Reto Kromer > > To: cellar@ietf.org > Cc:=20 > Date: Sat, 8 Oct 2016 07:05:28 +0200 > Subject: Re: [Cellar] NYC cellar meetup? > Dave Rice wrote: >=20 > >1. Is such a meeting of interest? >=20 > Indeed. >=20 > >2. Should it occur during an evening or the weekend? An > >evening may be easier to local folks to coordinate but > >would be too late for most remote participation from > >Europe. >=20 > A schedule permitting remote participation from Europe would > be ideal. >=20 > >3. Recommendations for agenda items, things you'd like to > >learn, things you'd like to see done? >=20 > Clear metadata embedding in Matroska, in order to maintain > the relevant information about the RGB flavour encoded by > FFV1. This would facilitate the native implementations into > the current cutting, grading, restoration, etc. softwares. > And, therefore, advocating for adoption. >=20 > +1 FLAC >=20 > Best regards, Reto >=20 >=20 >=20 >=20 > ---------- Forwarded message ---------- > From: Brendan Allen > > To: Reto Kromer > > Cc: "cellar@ietf.org " > > Date: Sat, 8 Oct 2016 12:06:24 -0400 > Subject: Re: [Cellar] NYC cellar meetup? > Hi everyone, > I've been lurking on this thread for awhile trying to follow. I'd like = to say thanks to all of you for the work you're doing to standardize = these formats. Also, its pretty cool how open, inclusive and transparent = this process is. > I live in nyc and could meet-up at the library. My interests are in = embedded metadata and FLAC >=20 > kind regards, > Brendan Allen >=20 > Sent from my iPhone >=20 > > On Oct 8, 2016, at 1:05 AM, Reto Kromer > wrote: > > > > Dave Rice wrote: > > > >> 1. Is such a meeting of interest? > > > > Indeed. > > > >> 2. Should it occur during an evening or the weekend? An > >> evening may be easier to local folks to coordinate but > >> would be too late for most remote participation from > >> Europe. > > > > A schedule permitting remote participation from Europe would > > be ideal. > > > >> 3. Recommendations for agenda items, things you'd like to > >> learn, things you'd like to see done? > > > > Clear metadata embedding in Matroska, in order to maintain > > the relevant information about the RGB flavour encoded by > > FFV1. This would facilitate the native implementations into > > the current cutting, grading, restoration, etc. softwares. > > And, therefore, advocating for adoption. > > > > +1 FLAC > > > > Best regards, Reto > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 >=20 >=20 >=20 > --=20 > Ethan Gates > Moving Image Archiving and Preservation Technician > Department of Cinema Studies, MIAP > New York University > 665 Broadway, Room 613 > New York, NY 10012 > 212-998-1732 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_4685409D-4E13-4FCE-962F-42DACAB1968E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Ethan and others,

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

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

This is basically just a find/replace to correct = a misspelling of "Occurence" with "Occurrence", mostly in this = section: https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#path.

https://github.com/Matroska-Org/matroska-specification/issues/4= 8
This issue is resolved basically by = removing https://github.com/Matroska-Org/matroska-specification/blob/gh-= pages/overhead.md from the matroska-specification repo as the = discussion suggests that it should not be part of the = specification.

https://github.com/Matroska-Org/matroska-specification/issues/5= 0
This calls for some sections to be reviewed = against the EBML specification to ensure that they are redundant and = then remove the identified redundant sections from the Matroska = specification.

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

https://github.com/Matroska-Org/matroska-specification/issues/4= 9
This relates to the metadata documenation = at https://github.com/Matroska-Org/matroska-specification/blob/gh-= pages/tagging.md. Moritz has noted the meaning of tag names prefixed = by underscores at https://github.com/Matroska-Org/matroska-specification/issues/4= 9#issuecomment-254039146, so a section should be added to tagging.md = to explain the meaning of tag names prefixed by underscores and what = they imply and what a Reader should do with them.
https://github.com/Matroska-Org/matroska-specification/issues/4= 6
This involves cleaning up Matroska's method = for defining how to define codecs in Matroska. There's a markdown table = that needs to be cleaned up and the structure of codec definitions = themselves needs to be documented (such as the name style of Codec IDs, = what information is needed in a description).

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

Dave Rice

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

Hi all,

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

Best,
Ethan= Gates

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

Thanks for = planning this!


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

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

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

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

Today's Topics:

   1. Re: NYC cellar meetup? (ashley.blewer@gmail.com)
   2. Re: NYC cellar meetup? (Murray, Kate)
   3. Re: NYC cellar meetup? (Doug Ewell)
   4. Re: NYC cellar meetup? (Reto Kromer)
   5. Re: NYC cellar meetup? (Brendan Allen)

---------- Forwarded message ----------
From: ashley.blewer@gmail.com
To: Dave Rice <dave@dericed.com>
Cc: cellar@ietf.org
Date: Fri, 7 Oct 2016 = 21:13:10 +0200
Subject: Re: [Cellar] NYC cellar = meetup?


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

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

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

 FLAC attack.


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




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

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



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

Hi all,

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

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

 So some questions for the group:

 1. Is such a meeting of interest?

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

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

 Dave Rice




---------- Forwarded message ----------
From: Doug Ewell <doug@ewellic.org>
To: cellar@ietf.org
Cc: 
Date: Fri, 07 Oct 2016 15:45:05 -0700
Subject: Re: [Cellar] NYC cellar meetup?
Dave Rice wrote:

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

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

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



---------- = Forwarded message ----------
From: Reto Kromer <lists@reto.ch>
To: cellar@ietf.org
Cc: 
Date: Sat, 8 Oct 2016 07:05:28 +0200
Subject: Re: [Cellar] NYC cellar meetup?
Dave Rice wrote:

>1. Is such a meeting of interest?

Indeed.

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

A schedule permitting remote participation from Europe would
be ideal.

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

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

+1 FLAC

Best regards, Reto




---------- Forwarded message ----------
From: Brendan Allen <brendanallen.ba@gmail.com>
To: Reto = Kromer <lists@reto.ch>
Cc: "cellar@ietf.org" <cellar@ietf.org>
Date: Sat, 8 Oct 2016 12:06:24 -0400
Subject: Re: [Cellar] NYC cellar meetup?
Hi = everyone,
I've been lurking on this thread for awhile trying to follow. I'd like = to say thanks to all of you for the work you're doing to standardize = these formats. Also, its pretty cool how open, inclusive and transparent = this process is.
I live in nyc and could meet-up at the library. My interests are in = embedded metadata and FLAC

kind regards,
Brendan Allen

Sent from my iPhone

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



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



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




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

= --Apple-Mail=_4685409D-4E13-4FCE-962F-42DACAB1968E-- From nobody Thu Oct 20 07:32:45 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 A44B212957A for ; Thu, 20 Oct 2016 07:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01] 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 ogsoX_fVw8SK for ; Thu, 20 Oct 2016 07:32:40 -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 70FB5127076 for ; Thu, 20 Oct 2016 07:32:40 -0700 (PDT) Received: from [146.96.19.240] (port=26596 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bxEOS-002CRZ-9V; Thu, 20 Oct 2016 10:32:39 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_669A9D9E-596D-44A2-886C-B7609DE38355" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 20 Oct 2016 10:32:25 -0400 In-Reply-To: To: Frank Galligan References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 14:32:44 -0000 --Apple-Mail=_669A9D9E-596D-44A2-886C-B7609DE38355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Frank and others, > On Feb 11, 2016, at 1:32 PM, Frank Galligan = wrote: >=20 >=20 > On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan = > wrote: >=20 >=20 > On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez > wrote: > Sorry for the late answer, here are my comments: >=20 > On 22/01/2016 23:54, Frank Galligan wrote: >> [...] >>=20 >> - I know some people expressed that they don't think starting from = FFmpeg for the TransferFunction is a good idea as they might have got = something wrong or too subjective. But I just used it as a starting = point for a list. I can reorder the list however we want. I also don't = think following another list, so we will be compatible with future = additions, will give us what we want as that list most likely will be = incomplete with something that is defined only in a different list. So = should we just start with a list, re-order it (so we are not explicitly = following it), then add what is currently missing? Then in the future if = someone needs to add something to the list it can be brought up here? >=20 > That was me. > I am OK with that as long as we are clear that we don't follow FFmpeg = list. > OK, I changed the text to see ISO/IEC 23001-8 document, which has the = same values as FFmpeg as well as the 264 ITU doc. >=20 >>=20 >> [...] >>=20 >> Element Name: Matrix >> Level: 5 >> ID: [55][A1] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), = 1: BT709, >> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, >> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, >> 10: BT2020 Constant Luminance)=20 >=20 >=20 > If we don't follow FFmpeg list, what is the purpose of value 3 and = why unspecified is 2 rather than 0? > That is the way it is specified in ISO/IEC 23001-8 and 264 ITU doc.=20 >=20 > Using FFmpeg list (which is based on MPEG list, with same oddities) is = not bad, and I am not against it, just wondering if it is good to take = the same oddities rather than a clean list without oddities. > I don't think there are any oddities. Looks like FFmpeg's list matches = exactly to ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries = and #16 and #17 in Transfer function, which were added here [1]. Also = #18 in Transfer, which is HLG [2]. >=20 > I think this is the whole issue. Do we follow some list (standardized = or not)? What if the list goes stale? What if the list doesn't include = algorithms from different lists (E.g. maybe HLG)? >=20 >=20 >=20 > Does anyone plan to transfer from DPX? If yes, we may need to add now = missing elements in the list (e.g. "Printing density") but I am not = expert enough for know which one is worth it. >=20 >=20 >>=20 >>=20 >> [...] >>=20 >>=20 >> Element Name: ChromaSubsampling >> Level: 5 >> ID: [55][A3] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: = 4:2:1, 5: 4:2:0, =20 >> 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) >=20 > I am more, as some other people, for something more generic, e.g. = ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the = subsampling (0 unspecified and default). I am afraid that someone crazy = used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X = values), it is possible (and I have a file like that if I remember well) = with FFV1. >=20 >=20 >=20 >>=20 >> [...] >>=20 >> Element Name: TransferFunction >> Level: 5 >> ID: [55][A7] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, >> 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, >> 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, >> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, >> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >>=20 >>=20 >> Element Name: Primaries >> Level: 5 >> Mandatory: - >> Multiple: - >> ID: [55][A8] >> Default: 2 >> Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M, >> 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM, >> 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >=20 > Same remark as with Matrix. >=20 >>=20 >> [...] >>=20 >=20 >=20 > [1] = https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8a= a17746 = > [2] http://www.arib.or.jp/english/html/overview/std-b67.html = >=20 >=20 >=20 > So this is what I have currently: > The parent element would be Video [E0]. >=20 >=20 > Element Name: Colour > Level: 4 > ID: [55][B0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. >=20 >=20 > Element Name: Matrix > Level: 5 > ID: [55][B1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more > information on enumerations. (0: IEC 61966-2-1 (sRGB), = 1: BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, > 10: BT2020 Constant Luminance)=20 >=20 >=20 > Element Name: BitsPerChannel > Level: 5 > ID: [55][B2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. This number may be = less for=20 > specific channels depending on the Matrix and = ChromaSubsampling. A > value of 0 is unspecified. >=20 >=20 > Element Name: ChromaSubsamplingHorz > Level: 5 > ID: [55][B3] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every = chrominance > pixel not removed horizontally. >=20 >=20 > Element Name: ChromaSubsamplingVert > Level: 5 > ID: [55][B4] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every = chrominance > pixel not removed vertically. >=20 > Element Name: CbSubsamplingHorz > Level: 5 > ID: [55][B5] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every = Cb > chrominance pixel not removed horizontally. This is = additive with > ChromaSubsamplingHorz. >=20 >=20 > Element Name: CbSubsamplingVert > Level: 5 > ID: [55][B6] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every = Cb > chrominance pixel not removed vertically. This is = additive with > ChromaSubsamplingVert. >=20 >=20 > Element Name: ChromaSitingHorz > Level: 5 > ID: [55][B7] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: Left=20 > collocated , 2: Half) >=20 > Element Name: ChromaSitingVert > Level: 5 > ID: [55][B8] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: = Top > collocated , 2: Half) >=20 >=20 > Element Name: Range > Level: 5 > ID: [55][B9] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Clipping of the color ranges. (0: Unspecified, 1: = Broadcast range, > 2: Full range (no clipping), 3: Defined by > Matrix/TransferFunction) >=20 >=20 > Element Name: TransferFunction > Level: 5 > ID: [55][BA] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Transfer Function. See ISO/IEC 23001-8 for more = information on > enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, > 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, > 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >=20 >=20 > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][BB] > Default: 2 > Type: u > Description: Values that can be represented in the CIE 1931 colour = space. See > ISO/IEC 23001-8 for more information on enumerations. > (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, > 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: = SMPTE 240M, > 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >=20 >=20 > Element Name: MaxCLL > Level: 5 > ID: [55][BC] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: MaxFALL > Level: 5 > ID: [55][BD] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame in candelas = per square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. >=20 >=20 > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Red X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Red Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Green X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Green Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Blue X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Blue Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point X chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point Y chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 9999.99 > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 999.9999 > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > I removed ChromaSubsampling and added ChromaSubsamplingHorz, = ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. >=20 > This is how I think the elements should be written for the different = subsampling types: > 1: 4:4:4 > - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set = as there should be no chroma subsampling. >=20 > 2: 4:4:0 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :1 >=20 > 3: 4:2:2 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set >=20 > 4: 4:2:1 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > - CbSubsamplingHorz :1 > - CbSubsamplingVert :not set > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we = didn't care about handling formats where the Cr and Cb channels are = different sizes. >=20 > 5: 4:2:0 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :1 >=20 > 6: 4:1:1 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :not set >=20 > 7: 4:1:0 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :1 >=20 > 8: 3:1:1 > - ChromaSubsamplingHorz :2 > - ChromaSubsamplingVert :not set > - I'm assuming the luma subsampling can be handled by PixelWidth, = and DisaplyWidth. >=20 > Jerome's vertical subsampling of 4 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :3 >=20 >=20 >=20 > The other issue I want to bring up is the value of "18: ARIB STD-B67 = (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use = this value sooner than Matroska v4 will be finalized. Should I make this = value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: = SMPTE ST 428-1" will be standardized across most documents, like 1-15 = are. Just not sure if 18 will be HLG. >=20 > Thanks, > Frank I wanted to point out a recent ffmpeg-devel discussion = http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201357.html = = pertaining to the implementation of these elements. It asks "Could = someone more familiar with the current standardization process chime in = to confirm if these Colour elements are finalized or not?" IIUC = correctly some of these elements are already integrated into FFmpeg and = they are already in use in webm via Google. Is there further work needed = on these? Dave Rice --Apple-Mail=_669A9D9E-596D-44A2-886C-B7609DE38355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Frank and others,

On = Feb 11, 2016, at 1:32 PM, Frank Galligan <frankgalligan@gmail.com> wrote:


On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan = <frankgalligan@gmail.com> wrote:


On Mon, Feb 8, 2016 at 9:15 AM, = Jerome Martinez <jerome@mediaarea.net> wrote:
=20 =20 =20
Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
[...]

- I know some people expressed that they = don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don't think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.
OK, I changed the text to see ISO/IEC 23001-8 document, which = has the same values as FFmpeg as well as the 264 ITU doc.


[...]

Element = Name: Matrix
Level: =        5
ID: =           [55][A1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant Luminance)


If we don't follow FFmpeg list, what is the purpose of  value 3 = and why unspecified is 2 rather than 0?
That is the way it = is specified in ISO/IEC 23001-8 and 264 ITU doc. 

Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.
I don't think there = are any oddities. Looks like FFmpeg's list matches exactly to =  ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries = and #16 and #17 in Transfer function, which were added here [1]. Also = #18 in Transfer, which is HLG [2].

I think this is the whole issue. Do we = follow some list (standardized or not)? What if the list goes stale? = What if the list doesn't include algorithms from different lists (E.g. = maybe HLG)?



Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") but I am not expert enough for know which one is worth it.




[...]


Element = Name: ChromaSubsampling
Level: =        5
ID: =           [55][A3]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: = 4:2:0, =             
=             &n= bsp;6: 4:1:1, 7: 4:1:0, 8: 3:1:1)

I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.




[...]

Element = Name: TransferFunction
Level: =        5
ID: =           [55][A7]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))


Element = Name: Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][A8]
Default: =      2
Description:=  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M,
=             &n= bsp; 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM,
=             &n= bsp; 9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Same remark as with Matrix.


[...]



[1] https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24= 898eeec0d8aa17746
[2] http://www.arib.or.jp/english/html/overview/std-b67.html



So this is what I have = currently:
The parent element would be = Video [E0].


Element Name: = Colour
Level: =        4
ID: =           [55][B0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  Settings = describing the colour format.


Element Name: = Matrix
Level: =        5
ID: =           [55][B1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description: =  ColourMatrix of the video. See ISO/IEC 23001-8 for = more
=             &n= bsp;information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant Luminance)


Element Name: = BitsPerChannel
Level: =        5
ID: =           [55][B2]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  Number of = decoded bits per channel. This number may be less for
=             &n= bsp;specific channels depending on the Matrix and ChromaSubsampling. = A
=             &n= bsp;value of 0 is unspecified.


Element Name: = ChromaSubsamplingHorz
Level: =        5
ID: =           [55][B3]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed horizontally.


Element Name: = ChromaSubsamplingVert
Level: =        5
ID: =           [55][B4]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed vertically.

Element Name: = CbSubsamplingHorz
Level: =        5
ID: =           [55][B5]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed horizontally. This is additive = with
=             &n= bsp;ChromaSubsamplingHorz.


Element Name: = CbSubsamplingVert
Level: =        5
ID: =           [55][B6]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed vertically. This is additive = with
=             &n= bsp;ChromaSubsamplingVert.


Element Name: = ChromaSitingHorz
Level: =        5
ID: =           [55][B7]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled horizontally. (0: Unspecified, 1: Left
=             &n= bsp;collocated , 2: Half)

Element Name: = ChromaSitingVert
Level: =        5
ID: =           [55][B8]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled vertically. (0: Unspecified, 1: Top
=             &n= bsp;collocated , 2: Half)


Element Name: = Range
Level: =        5
ID: =           [55][B9]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description: =  Clipping of the color ranges. = (0: Unspecified, 1: Broadcast = range,
=             &n= bsp;2: Full range (no clipping), 3: Defined by
=             &n= bsp;Matrix/TransferFunction)


Element Name: = TransferFunction
Level: =        5
ID: =           [55][BA]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:  Transfer = Function. See ISO/IEC 23001-8 for more information on
=             &n= bsp;enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve,
=             &n= bsp;6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))


Element Name: = Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][BB]
Default: =      2
Type: =         u
Description:  Values = that can be represented in the CIE 1931 colour space. = See
=             &n= bsp;ISO/IEC 23001-8 for more information on = enumerations.
=             &n= bsp;(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved,
=             &n= bsp;4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M,
=             &n= bsp;8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)


Element Name: = MaxCLL
Level: =        5
ID: =           [55][BC]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single pixel in candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


Element Name: = MaxFALL
Level: =        5
ID: =           [55][BD]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single full frame in candelas per = square
=             &n= bsp;meter (cd/m=C2=B2).


Element Name: = MasteringMetadata
Level: =        5
ID: =           [55][D0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  SMPTE 2086 = mastering data.


Element Name: = PrimaryRChromaticityX
Level: =        6
ID: =           [55][D1]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  Red X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryRChromaticityY
Level: =        6
ID: =           [55][D2]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  Red Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryGChromaticityX
Level: =        6
ID: =           [55][D3]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
f
Description: =  Green X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryGChromaticityY
Level: =        6
ID: =           [55][D4]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  Green Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryBChromaticityX
Level: =        6
ID: =           [55][D5]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
f
Description: =  Blue X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryBChromaticityY
Level: =        6
ID: =           [55][D6]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  Blue Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = WhitePointChromaticityX
Level: =        6
ID: =           [55][D7]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  White point X chromaticity coordinate as defined by CIE = 1931.


Element Name: = WhitePointChromaticityY
Level: =        6
ID: =           [55][D8]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1
Default: =      -
Type: =         f
Description: =  White point Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = LuminanceMax
Level: =        6
ID: =           [55][D9]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 9999.99
Default: =      -
Type: =         f
Description:  Maximum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


Element Name: = LuminanceMin
Level: =        6
ID: =           [55][DA]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 999.9999
Default: =      -
Type: =         f
Description:  Minimum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


I = removed ChromaSubsampling and added ChromaSubsamplingHorz, = ChromaSubsamplingVert, CbSubsamplingHorz, and = CbSubsamplingVert.

This is how I think the elements should be written for the = different subsampling types:
1: = 4:4:4
    - ChromaSubsamplingHorz and = ChromaSubsamplingVert will not be set as there should be no chroma = subsampling.

2: = 4:4:0
  - = ChromaSubsamplingHorz :not set
  - = ChromaSubsamplingVert :1

3: 4:2:2
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set

4: 4:2:1
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set
  - CbSubsamplingHorz :1
  - = CbSubsamplingVert :not set
  - We could = remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about = handling formats where the Cr and Cb channels are different = sizes.

5: = 4:2:0
  - ChromaSubsamplingHorz :1
  - ChromaSubsamplingVert :1

6: 4:1:1
  - ChromaSubsamplingHorz :3
  = - ChromaSubsamplingVert :not set

7: 4:1:0
  - ChromaSubsamplingHorz :3
  = - ChromaSubsamplingVert :1

8: 3:1:1
  - ChromaSubsamplingHorz :2
  = - ChromaSubsamplingVert :not set
  - I'm = assuming the luma subsampling can be handled by PixelWidth, and = DisaplyWidth.

Jerome's vertical subsampling of 4
  - ChromaSubsamplingHorz :not set
  - ChromaSubsamplingVert :3



The other issue I want = to bring up is the value of "18: ARIB STD-B67 (HLG)" in TransferFunction. = Unfortunately, in WebM we will need to use this value sooner than = Matroska v4 will be finalized. Should I make this value much higher? Or = leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across most = documents, like 1-15 are. Just not sure if 18 will be HLG.

Thanks,
Frank

I wanted to point out a recent ffmpeg-devel = discussion http://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201357.ht= ml pertaining to the implementation of these elements. It asks = "Could someone more familiar with the current standardization process = chime in to confirm if these Colour elements are finalized or not?" IIUC = correctly some of these elements are already integrated into FFmpeg and = they are already in use in webm via Google. Is there further work needed = on these?
Dave Rice

= --Apple-Mail=_669A9D9E-596D-44A2-886C-B7609DE38355-- From nobody Thu Oct 20 12:35:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12451296B1 for ; Thu, 20 Oct 2016 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 7-ieYq14Ab90 for ; Thu, 20 Oct 2016 12:35:41 -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 B9CE312964C for ; Thu, 20 Oct 2016 12:35:41 -0700 (PDT) Received: from [146.96.19.240] (port=26527 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bxJ7s-004Bv9-BU for cellar@ietf.org; Thu, 20 Oct 2016 15:35:40 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <0B1F44BB-AA7A-4355-BBD4-B938AA35A81E@dericed.com> Date: Thu, 20 Oct 2016 15:35:38 -0400 To: cellar@ietf.org X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] EditionUID length 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, 20 Oct 2016 19:35:43 -0000 Hi all, I noticed that writing EditionUID fails for many values in Matroska = writers such as MKVToolnix but this works if the EditionUID is a small = enough value. For instance a 128 bit EditionUID fails, but a <=3D32 bit = one works. Is there an unwritten understanding that EditionUID (and many of the = non-Segment-UID Elements) has size constraints or is it a bug in the = Matroska writer for not handling any valid unsigned integer as an = EditionUID? Presuming a size-constrained UID is preferred but it should = be noted as to what the constraint is. Dave Rice= From nobody Thu Oct 20 13:23: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 E110B129417 for ; Thu, 20 Oct 2016 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 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.431, 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 LdVS1k7COSyn for ; Thu, 20 Oct 2016 13:23:18 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6246D1294FE for ; Thu, 20 Oct 2016 13:23:18 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 66so110748856itl.1 for ; Thu, 20 Oct 2016 13:23:18 -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=XBvcYme3IwK20Q12Prpwa46ZNOgqhhadpSf5pBj3ePk=; b=PbF88pE4wjuUHVZ0oZCTd1jbI54Mf54iCt8W/zQ1aVXfHwSa8lB2t/L11QS4yLUlYb 3kC5ouS7O9+QtrfDUuT4qrk6nA+6i3qiepbD0ka1PPIzQ8TvzZf5nScLPsHQDCkRDgZm 9Yu0Ab0VQPCxS0ugWMeamwdebBofRp2fN5KhQYRqVkFjy2NbiMkvqqqLU6KRiLIuYMIb 54/qRDVsT/QWsOyZ+RsZKOwYY/YMktdzrRjvFZUC8eBCmZkAUXGs2zmigDzfP8GhuDiQ f0ESOgpLGnntbv9PohIHTSdujg6lII0JPKD/Nww48MmjiHjhHfmn88gZb40FCkD0VpQM zGdQ== 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=XBvcYme3IwK20Q12Prpwa46ZNOgqhhadpSf5pBj3ePk=; b=g+KPp27S+1q67pUzrfSvLlmr04y3TppsW8y/nlKsPNK0HKScYNqIkWYr1ws9E5qftY NG3A/zN2/2D3FvoNqZi9BJ71rAek5bx/Z8mrvf9LvYqov9frVyiaONCl0jsIH9T3WVNg a4BWqSIJLhO0gz5rDjRYyYNP4Nle6GBFvsTjjYjYQWSHtsTE1/FzY7LgNZMrWyvPo37l IxUckpqDBge82XsERzH7CgS6xMKujf7yZBvwneyGnS/Yuwm/ia4Y0UDbyrGBBYS110Su 2F+ubhGzgDl8jcN1STtxxe1/P3CoLl7Gj1RPqa3cPOHD8hMlQ6AlCT6mgK4C9el2ZIai BAVg== X-Gm-Message-State: AA6/9RmtxdGc4htPNVu1H/IHbA5qc8vHetcP5voHxIj5tdKrVImWapmqjt2UGrhVbZTGKSmdE5x5MfFOXud7/THm X-Received: by 10.36.17.13 with SMTP id 13mr2731472itf.49.1476994996943; Thu, 20 Oct 2016 13:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.67 with HTTP; Thu, 20 Oct 2016 13:22:56 -0700 (PDT) In-Reply-To: <0B1F44BB-AA7A-4355-BBD4-B938AA35A81E@dericed.com> References: <0B1F44BB-AA7A-4355-BBD4-B938AA35A81E@dericed.com> From: Michael Bradshaw Date: Thu, 20 Oct 2016 13:22:56 -0700 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a11440fec210526053f51b249 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EditionUID length 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, 20 Oct 2016 20:23:20 -0000 --001a11440fec210526053f51b249 Content-Type: text/plain; charset=UTF-8 On Thu, Oct 20, 2016 at 12:35 PM, Dave Rice wrote: > Hi all, > > I noticed that writing EditionUID fails for many values in Matroska > writers such as MKVToolnix but this works if the EditionUID is a small > enough value. For instance a 128 bit EditionUID fails, but a <=32 bit one > works. EditionUID is defined as an unsigned integer element, and as such cannot be more than 64 bits. I would expect a 128-bit EditionUID to fail, but a 64-bit one should work (if not, I'd say that's a bug in the tool). --001a11440fec210526053f51b249 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Oct 20, 2016 at 12:35 PM, Dave Rice <dave@dericed.com> wr= ote:
Hi all,

I noticed that writing EditionUID fails for many values in Matroska writers= such as MKVToolnix but this works if the EditionUID is a small enough valu= e. For instance a 128 bit EditionUID fails, but a <=3D32 bit one works.<= /blockquote>

EditionUID is defined as an unsigned intege= r element, and as such cannot be more than 64 bits. I would expect a 128-bi= t EditionUID to fail, but a 64-bit one should work (if not, I'd say tha= t's a bug in the tool).
--001a11440fec210526053f51b249-- From nobody Thu Oct 20 13:30:04 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 BFC1A129576 for ; Thu, 20 Oct 2016 13:30:02 -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 UQLum0XAPhja for ; Thu, 20 Oct 2016 13:30:01 -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 023F9129434 for ; Thu, 20 Oct 2016 13:30:01 -0700 (PDT) Received: from [146.96.19.240] (port=13083 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1bxJyR-0008k0-Jd; Thu, 20 Oct 2016 16:30:00 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_40EC49C1-C656-4117-8EC7-CF8F059DF5B3" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 20 Oct 2016 16:29:57 -0400 In-Reply-To: To: Michael Bradshaw References: <0B1F44BB-AA7A-4355-BBD4-B938AA35A81E@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EditionUID length 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, 20 Oct 2016 20:30:03 -0000 --Apple-Mail=_40EC49C1-C656-4117-8EC7-CF8F059DF5B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 20, 2016, at 4:22 PM, Michael Bradshaw = wrote: >=20 > On Thu, Oct 20, 2016 at 12:35 PM, Dave Rice > wrote: > Hi all, >=20 > I noticed that writing EditionUID fails for many values in Matroska = writers such as MKVToolnix but this works if the EditionUID is a small = enough value. For instance a 128 bit EditionUID fails, but a <=3D32 bit = one works. >=20 > EditionUID is defined as an unsigned integer element, and as such = cannot be more than 64 bits. I would expect a 128-bit EditionUID to = fail, but a 64-bit one should work (if not, I'd say that's a bug in the = tool). Ah, sorry to miss that. I see that SegmentUID (defined as 128 bits) is = 'binary' while EditionUID is 'uinteger' (which has an Element Type = definition which restricts to 8 bytes). 64 bit EditionUID's do work in = mkvtoolnix, even though it assigns 32 bit versions by default. Dave= --Apple-Mail=_40EC49C1-C656-4117-8EC7-CF8F059DF5B3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Oct 20, 2016, at 4:22 PM, Michael Bradshaw <mjbshaw@google.com> wrote:

On Thu, Oct 20, 2016 at 12:35 PM, Dave Rice <dave@dericed.com> wrote:
Hi all,

I noticed that writing EditionUID fails for many values in Matroska writers such as MKVToolnix but this works if the EditionUID is a small enough value. For instance a 128 bit EditionUID fails, but a <=32 bit one works.

EditionUID is defined as an unsigned integer element, and as such cannot be more than 64 bits. I would expect a 128-bit EditionUID to fail, but a 64-bit one should work (if not, I'd say that's a bug in the tool).

Ah, sorry to miss that. I see that SegmentUID (defined as 128 bits) is 'binary' while EditionUID is 'uinteger' (which has an Element Type definition which restricts to 8 bytes). 64 bit EditionUID's do work in mkvtoolnix, even though it assigns 32 bit versions by default.
Dave
--Apple-Mail=_40EC49C1-C656-4117-8EC7-CF8F059DF5B3-- From nobody Sun Oct 23 08:39: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 8BD5E12946D for ; Sun, 23 Oct 2016 08:39:44 -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 av6wcVkze82O for ; Sun, 23 Oct 2016 08:39:43 -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 C617F129486 for ; Sun, 23 Oct 2016 08:39:42 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOOJl-1c1tdZ1EOL-005rt4 for ; Sun, 23 Oct 2016 17:39:40 +0200 To: Cellar@ietf.org From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: Date: Sun, 23 Oct 2016 17:39:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:S4GxrVxa+m+MopUkAnqCwXTzlWKMEH8IICWPH5EoxeYDpnSzlLH jZ2VzAIdE4wHKtCSsjzWNTFiNBoGNa7k9ojnCzM+vDqLC9rIw2Kg3Obrb4VhI55RAcf+0AJ C4N/MEZVzHung27W0si8eZehG5gGU4QFnvcYKzL1hXXf1tqWN5t+VDpTA1LveFGNwHmtUwA 8LbvK4uBxmErG7edujGyw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ki3LFZtWYTI=:bHNL8ljWvwB/umilVNscz1 K4zcd3tgPf9q8X7PIOk4n4409kmrGzcIcAxJtX3c+EeZ4sGA+zroPvgusaUHqrMsT+nWCvaty N9UVbpIiCt47HNnj6dKlhzfU5q+3Ixf/BDleDc2CQx/RLPAGezeKw0Gq02VNOMQsbGwTzBqk6 nSMUYRoJvteiXPg8amaB0kK1gcD2eNmi5bHEfzX3QdfEtQJutfMMmQs2mtY+X9W13xIr/mLFH MqWuss7AlBh40ToOoDeVnk+CqLmjmvFMy2uJl2xnEgdXr1y2dgsdCSN0zVLxolU9YFR0D5F3K 2FhXiacjeGmpVepEThggCxgvd2xhU1gSvTfKonbiCD6c66+E+V+ByCrGktHbAUDkmwGfp3V3c MWftKqyFw3gWAAZgXskPWae6Cp+Q6qBPQoc/Qo7zJpyDf+jb9pbtM5WbcAu2QjSdWDp0rL37E udXQblrL7wm5231oV34wLOdBaGOLzzap4GK7s52J0N+GgyHK+c4hT5hUk8nCoMolOeCUWaHv7 xTX1OAmQI7h8di40nsybRoROkx4thNXFyHn24A/r5n149I3Tit5ybb5leTSH9JIe/CyGvEBhM vzR/0q/riHlrUcQxVvhjbmxlh65mwICWr6D278ftLlxURRpqerTVWCJ7XPtIa6dUP5ZeCmkLy PDgJ4duMp/yvBs42wKWGrr9/4pgxUmWbbXZyNFLeRz2fe0Kk6aIk7ymxAS3mjoANMQyca6Kmk MbGyJLvOvVbwMT0xl+hOurMRnr4lIQAv1/g+5rVS4n7UiQNhU3Mur0iS2TJfBQR8BGn7mZcnj SGTUAlY Archived-At: Subject: [Cellar] EBML spec questions 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, 23 Oct 2016 15:39:44 -0000 Hi, I have a few questions regarding the EBML specs. "Date Element" What happens after "2293-04-11T11:47:16.854775807 UTC"? Is there a way to use the date type after that date for dates after the date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? If that is not the case, then why can't it be the case? (I do understand the limitation due to the maximum of the octets, but not why it has to be a signed integer, whereas an unsigned integer would allow a larger range, even though only positive.) "EBML Schema" "The DocType value for an EBML Document Type SHOULD be unique and persistent." What would be a reason for violation that SHOULD? Wouldn't that be better a MUST? Best Regards, Sebastian From nobody Sun Oct 23 12:43: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 1E5F91295F7 for ; Sun, 23 Oct 2016 12:43:48 -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 d9_i9MdJ1bxl for ; Sun, 23 Oct 2016 12:43:46 -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 BDD321294A0 for ; Sun, 23 Oct 2016 12:43:45 -0700 (PDT) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:44143 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1byOgJ-000ENl-Hf; Sun, 23 Oct 2016 15:43:45 -0400 From: Dave Rice Message-Id: <86E11137-6BC3-4878-93D3-E98A665F330E@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_ECF43FBB-6CF5-4FE8-8C30-193C907DA4C6" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Sun, 23 Oct 2016 15:43:40 -0400 In-Reply-To: To: "Sebastian G. " References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Cellar@ietf.org Subject: Re: [Cellar] EBML spec questions 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, 23 Oct 2016 19:43:48 -0000 --Apple-Mail=_ECF43FBB-6CF5-4FE8-8C30-193C907DA4C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 23, 2016, at 11:39 AM, Sebastian G. = wrote: >=20 > Hi, >=20 > I have a few questions regarding the EBML specs. >=20 > "Date Element" >=20 > What happens after "2293-04-11T11:47:16.854775807 UTC"? >=20 > Is there a way to use the date type after that date for dates after = the > date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? IIUC this is not possible with a Date Element. Feasibly a future version = of EBML could adjust the Date Element definition to include longer byte = lengths. Hopefully someone can do this within the next 277 years. > If that is not the case, then why can't it be the case? (I do = understand > the limitation due to the maximum of the octets, but not why it has to > be a signed integer, whereas an unsigned integer would allow a larger > range, even though only positive.) >=20 > "EBML Schema" >=20 > "The DocType value for an EBML Document Type SHOULD be unique and > persistent." >=20 > What would be a reason for violation that SHOULD? Wouldn't that be > better a MUST? Perhaps it can be MUST. When writing I was thinking that we should avoid = some Matroska writers using "matroska" and others using "Matroska" and = considering it as the same EBML Document Type. Likewise someone creating = a different EBML Document Type should avoid also calling that as = "matroska". In XML the equivalent of DocType is the XML Namespace [1], is defined = like (underlining mine): "The namespace name, to serve its intended = purpose, SHOULD have the characteristics of uniqueness and persistence. = It is not a goal that it be directly usable for retrieval of a schema = (if any exists). Uniform Resource Names [RFC2141] is an example of a = syntax that is designed with these goals in mind. However, it should be = noted that ordinary URLs can be managed in such a way as to achieve = these same goals." Dave Rice [1]: https://www.w3.org/TR/REC-xml-names/#ns-decl --Apple-Mail=_ECF43FBB-6CF5-4FE8-8C30-193C907DA4C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Oct 23, 2016, at 11:39 AM, Sebastian G. <bastik> = <bastik.public.mailinglist@gmx.de> wrote:

Hi,
I have a few questions regarding the EBML = specs.

"Date Element"

What happens after "2293-04-11T11:47:16.854775807 UTC"?

Is there a way to use the date type after that = date for dates after the
date? E.g. File modification date = 2294-02-01T10:24:00.012345678 UTC?

IIUC = this is not possible with a Date Element. Feasibly a future version of = EBML could adjust the Date Element definition to include longer byte = lengths. Hopefully someone can do this within the next 277 = years.

If that is not the case, then why can't it be = the case? (I do understand
the limitation due to the = maximum of the octets, but not why it has to
be a signed = integer, whereas an unsigned integer would allow a larger
range, even though only positive.)

"EBML Schema"

"The DocType value = for an EBML Document Type SHOULD be unique and
persistent."

What would be a = reason for violation that SHOULD? Wouldn't that be
better = a MUST?

Perhaps it can be MUST. When writing I was = thinking that we should avoid some Matroska writers using "matroska" and = others using "Matroska" and considering it as the same EBML Document = Type. Likewise someone creating a different EBML Document Type should = avoid also calling that as "matroska".

In XML the equivalent of DocType is the XML = Namespace [1], is defined like (underlining mine): "The namespace name, = to serve its intended purpose, SHOULD have = the characteristics of uniqueness and persistence. It = is not a goal that it be directly usable for retrieval of a schema = (if any exists). Uniform Resource Names [RFC2141] is = an example of a syntax that is designed with these goals in = mind. However, it should be noted that ordinary URLs can be managed = in such a way as to achieve these same goals."

Dave Rice


= --Apple-Mail=_ECF43FBB-6CF5-4FE8-8C30-193C907DA4C6-- From nobody Mon Oct 24 11:03:07 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 4D3F71296B5 for ; Mon, 24 Oct 2016 11:03:06 -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 nFS6Cwaok5ay for ; Mon, 24 Oct 2016 11:03:03 -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 976931293FB for ; Mon, 24 Oct 2016 11:03:02 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfRnb-1cICXK0yE7-00P2JD; Mon, 24 Oct 2016 20:02:17 +0200 To: Dave Rice References: <86E11137-6BC3-4878-93D3-E98A665F330E@dericed.com> From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: Date: Mon, 24 Oct 2016 20:02:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86E11137-6BC3-4878-93D3-E98A665F330E@dericed.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:y8aKFAa8S0udxcVS0/i7dVz9LnNMMTP6wtwAkf7OxILkE21zxpQ igu0z6v75VOnXh2alwaUWELY+QyuWezOnH7kZ0NdXRAS0FUTsKUsStXWiiBa3bc9juYX1a9 jYaEs8fgmZGhcJGxvy83WD3ZYMLAnpahZvE5tNTTpn+omlJX4ASN66feHG5x9lXELz41Khj e6De2bkOvOnnAdUdNapnA== X-UI-Out-Filterresults: notjunk:1;V01:K0:AMisUJzW4gQ=:E/2ZE5xdVzo0vGhCoGy6Dk 4Z6H19d9trS8QCSjdC0ItynYLpbgsyIIZDmIncnPFBrYpi7ef9Mp9+r73HdcAFBPiMvi8doiO aGgGKxvT8x3fG40GYD+IiZrM/XYYYeVjRpMkoOiV6VN3mCi0sF+XTyQGAyDAlOF+i6GUAR80z cjmH22nNUDdkJy4db4+rbWRbuf+G+hLXlefE6BRxB9Rw/jQRuK2SwDg8kg2s/vl4yRAep1cQT UGhHzam9HvmdoCg5c8ClOrM/DECCUhAqZTbG3Ape79fdc38EQLo1X+SYEf8VrNINHf+NQZda2 YAyXNrcNfPEIrHjtk0KHamucnDJOFE0JhCmE8VYUuYRNQ4z53Lp5+x2aVxntMIp1LIe1Ju9Yz iYEFsbaFTOQAN2V+1pDKsFJktIx25mvDmfMQi7sPUNoaJAo5GMmern7uHfe67jtMfPAFdMl7U tF0wZ2SnBc34qwbXPaqGOyad7FtzxEK40gYNRdRgoNiAW8KOURca/a6B1SVQY4FXxX2yHnb3n pVSTxj8MUaMHrVqX+njnIepYtiVZ3593L7ljAxnh1VanzR5/0PehhAra/ug8WJaV0dstuN0jy kadR+jMLjalrf28JAb582ylvL5+a/aqYLGFi70NmtyrxmAi1a0PmubLxc9FV3LD7MDwy+rv1y MNVtOu1gLNd39Y7vbSjNv9R1btweppAzwPEey+CqkcgnJmGGi+49+02ebPU6RNJgWXtmFbboe DNqtcU7tg8CSflWKvVVCM5QOVc0P9aKoAqoAWnjKFv2nOxs6yV6ww4LeVs8ImsnoYXGehu6BA NAQlz/I Archived-At: Cc: Cellar@ietf.org Subject: Re: [Cellar] EBML spec questions 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, 24 Oct 2016 18:03:06 -0000 23.10.2016, 21:43 Dave Rice: > >> On Oct 23, 2016, at 11:39 AM, Sebastian G. wrote: >> >> Hi, >> >> I have a few questions regarding the EBML specs. >> >> "Date Element" >> >> What happens after "2293-04-11T11:47:16.854775807 UTC"? >> >> Is there a way to use the date type after that date for dates after the >> date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? > > IIUC this is not possible with a Date Element. Feasibly a future version of EBML could adjust the Date Element definition to include longer byte lengths. Hopefully someone can do this within the next 277 years. I would hope that it is possible to do something about it rather sooner than later. It is a Date Element that stores its value in a nanosecond representation. At least that is how I understand it. There could be a Time Element and a Date Element, where the Date Element holds only days that are positive or negative from the start date and the Time Element holds the time in nanoseconds or even below that to be able to be even more precise. >> If that is not the case, then why can't it be the case? (I do understand >> the limitation due to the maximum of the octets, but not why it has to >> be a signed integer, whereas an unsigned integer would allow a larger >> range, even though only positive.) >> >> "EBML Schema" >> >> "The DocType value for an EBML Document Type SHOULD be unique and >> persistent." >> >> What would be a reason for violation that SHOULD? Wouldn't that be (What would be a reason for violating that SHOULD?, should have been my question.) >> better a MUST? > > Perhaps it can be MUST. When writing I was thinking that we should avoid some Matroska writers using "matroska" and others using "Matroska" and considering it as the same EBML Document Type. Likewise someone creating a different EBML Document Type should avoid also calling that as "matroska". Well, using different cases did not occur to me. To me it appears that a parser should be able to read 'matroska' and "Matroska' without any issue even though that for consistency only one version SHOULD be written. My concern was that no one could use the 'matroska' DocType if that is a Schema that already exists and does not comply with the existing Schema. One could keep it like it is while adding something like follows: "The DocType value for an EBML Document Type SHOULD be unique and persistent. One MUST NOT use an EBML Document Type that is already in definitive use by an already defined Schema, when one does not refer to such a Schema." Changes in wording are welcome. > In XML the equivalent of DocType is the XML Namespace [1], is defined like (underlining mine): "The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals." > > Dave Rice > > [1]: https://www.w3.org/TR/REC-xml-names/#ns-decl > Best Regards, Sebastian From nobody Mon Oct 24 11:18:17 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 4465D129971 for ; Mon, 24 Oct 2016 11:18:16 -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 jI5_SPcV5UzF for ; Mon, 24 Oct 2016 11:18:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 98E98129881 for ; Mon, 24 Oct 2016 11:18:14 -0700 (PDT) Received: from [192.168.2.129] ([84.61.100.56]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MAQXq-1c4pgs0Zdi-00BeO3 for ; Mon, 24 Oct 2016 20:18:12 +0200 To: Cellar@ietf.org From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <178e2c99-5dc8-5538-78c1-b8a803428620@gmx.de> Date: Mon, 24 Oct 2016 20:18:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:65dlxDta6Yuu0X+uMZFa08db6lfPUbRkqcRjmMmyNr6E+6D450X XMKrTtTS0+rqJRDOc7PvalqvuwUbthp0CsD27INb2yp9uOLmvAi/rpCWhvLqV+hF4ASZhFA Fa29+sG1E0+zgfFgLo73SisOYLsU2Cs05GhWLGKy4mQLL2l5gmO5f1bbE71Xa3f3PXPmbTE 7MelXg4196HmbbpDawE8A== X-UI-Out-Filterresults: notjunk:1;V01:K0:XgkK+oaR+gs=:exMTJLP/EFdCmhiKJMPO5n njw404jrj7bwp8w69Karh6kWMtDkYkQ7CGCfGiYMtI2a0VxQyjtzsxqJekgHfutiaqi3/PioO 7q9jbeinbMoBcRJGdynGrEj8kGr9UaoB0OCRl4hzkB1cS2N3y3pjKdljTknw4AKbI1lQjrbiS pbmW0IjVhRMQiEBa7ex8LSPxwuTVXQmrmhzmoaexJP1YJZfEQUPY5KgtZybF1mDddzN6Wbufp HwpogK08K6o/R4s2DTWaV0HjR3GEcKEiVHAuJglTI0AmVf+FsVXJJvObtFQjJPBXlWXRMsQ20 8xB0Psvs3q56VXYGTkyMyvJNYT28JLC8jX+c1sgsCYpyVJSqaZMseVzAfwc7xZ7M2ZcWrwlTo ryjR9uPofce1lTBYs18WwmIR6BChscQ4gsOMrKlIowkVQUPsculliJde6OAfG6Iont6xDfTMc i7F/10FAQNNkSouWr2o4mKrPXOrG1lsS1706YSaDS9XnJRqCZxzDfplZhjPaZE++8jVoK+UUW aVt0BgV9wd/D+9DKsqPmXuxtrGrzW49jgvNGETOrcvIDCwLt2Zecl0wVPDVjzXb403bN0bnF4 EnyzKL4ED4LYvVO9o0DdcCt0Vdc+9FU1aga6BKwOCHScH+2ybsIKIkVzVY2VlWyB41FTbaUxV Qc0CmeX4mxeIThGf/YJdh3YVEfaI65l//Ma+eB4WJ3FtrYxRsXTqr9gLRfm2HvEGEU1Sff7rX +nEW/KgfD3/usGtQZVXuKATisE+UO5Y63P5Cqd3CgFpTwFYNMQaPt3jVjHvuj3dgAnzDjjJ7g qYHuM5q Archived-At: Subject: [Cellar] Preferred ordering of Notation and Conventions for 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, 24 Oct 2016 18:18:16 -0000 Hello, as suggested on issue #120 [0] on Github for the EBML specs I am going to ask if the order of the section "Notation and Conventions" matters for the RFC. To me it does not matter if the order is one way or the other. Initially I wanted to point out that it appears to be sorted alphabetically, but not completely. So are there any preferences on how such a section should be structured? Best Regards, Sebastian [0] https://github.com/Matroska-Org/ebml-specification/issues/120 From nobody Sun Oct 30 00:15: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 A75BE1293FF for ; Sun, 30 Oct 2016 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 rrqBy5oymnVw for ; Sun, 30 Oct 2016 00:15:30 -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 1F432127A90 for ; Sun, 30 Oct 2016 00:15:30 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u124so119630913ywg.3 for ; Sun, 30 Oct 2016 00:15:30 -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=mgXNIKbFQv33YujQcdAsVnW07vo6TlYYkSblmQL4DsE=; b=SyrhQBdT6suu3bwCFFV3cPPbfN+v8eZrL05qR/DDas2S+yu41QD98rd5/asOin1MHt 3slLv70ZxgL4Mg3UTYfJddluCe9ttoiSJeF/BPHd0F1R5G3sNaP5lcnldENEonM9Qsxm nUQyzjPizQpLoaeIrRLov+B1zS9ZfRMoyql9Hfdgwnc/1vr8axU7Or+tbMNCPBOJ96NT tk1lJLuF10Iks4wGdeEw3m4N8tc8SkTlM4mlnr5Wd+ZHRaTQEgRAUqkblUt09zdPyJOe UmG+F3W1txPmroxumsjzdq8EUvrqZBVLVkONTzNX2OU4C86+qODM0mhNDx7tImXakr4b eWiQ== 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=mgXNIKbFQv33YujQcdAsVnW07vo6TlYYkSblmQL4DsE=; b=EvBTCzpyK9eLhzrxlGDjOxoGUDUWsEm0KKqLn2YIGKr4KAYqNyj+srGR/7GooxA+WD LEjY0cnHExLKw7uv2m55gBWqpHMabBpuNlBqnbjyAQspVffTjkSCS5sQkrKRoj3YMEJC tCgFUvkJSWhootwEx5gdtga/BRixc129HPdBb6L6YHVE89FFGqnxqhwP8iR5UBe7EsUZ 4nIwTbJrIM+9LACMfzh1NTRTRgFGLRySI30o/fBA2X33DwtFB5s7CeboeCJahj0RRhtK ZqsLhMX7zDKvSjTCJYpiveXJwz6Xp1mTvkVnDxsjAbdM2w3wJ+IT2dB6Wr+zYViBp3Ae YETg== X-Gm-Message-State: ABUngvcC9tKFrrauGDW6NFRj5V4PkFzkXP8OUNL03s1vI6U5WYL/kNV2J37d2+Qko56TNXTkiGXcfHnZqpQQYw== X-Received: by 10.129.167.3 with SMTP id e3mr20066904ywh.60.1477811729204; Sun, 30 Oct 2016 00:15:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 00:15:28 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 30 Oct 2016 08:15:28 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EBML Version/Read Version 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, 30 Oct 2016 07:15:32 -0000 2016-10-18 3:07 GMT+02:00 Dave Rice : > >> On Oct 16, 2016, at 8:57 AM, Steve Lhomme wrote: >> >> So far there was no range defined for EBMLVersion and EBMLReadVersion. >> The value 0 should be excluded. But I don't think excluding versions >> other than 1 is good. There might be someday an EBML 2 version which >> is backward compatible. That shouldn't make them invalid EBML 1 >> documents just because EBMLVersion is 2. > > But if there is someday an EBML version 2, that would be because a new ve= rsion of the EBML specification is defined. In a future EBML version 2 spec= ification, I presume the range for EBMLVersion would be updated from `1` to= `1-2`. > > I suggest, per "EBML version 1 specification", that EBMLVersion=3D2 is co= nsidered invalid, since "EBML version 1 specification=E2=80=9D won=E2=80=99= t know what to expect. There are 2 levels at play IMO. The validation level of a file that could consider value 2 is OK as long as EBMLReadVersion is 1. And there is the semantic level that would say that the reader doesn't know of any EBML version 2. But IMO as long as EBMLReadVersion is 1, it doesn't matter what the EBMLVersion says, the file will be parseable by a reader that can handle EBML version 1. So at the very least I think EBMLVersion should be let free (not 0). I will not have any impact on validity or paseability (?). The question remains for EBMLReadVersion. I think forcing 1 for now is OK. It's like a reserved bit that must always be 0. If it's not 0 you know the bistream is either wrong or there's something you don't know about. And that's what EBMLReadVersion is for. I'll update my pull request. > Per "EBML version 2 specification=E2=80=9D, both EBMLVersion=3D1 and EBML= Version=3D2 are valid. > >> Here's a pull request to fix and clarify what the current value should b= e: >> https://github.com/Matroska-Org/ebml-specification/pull/111 > > I suppose I prefer not to accept this pull request. Why permit an EBML Wr= iter to say EBMLVersion=3D2 or EBMLVersion=3D999, etc when such format is n= ot even conceived or defined yet? > Dave --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 30 01:06: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 6AA4C129503 for ; Sun, 30 Oct 2016 01:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 NjS65BX02fsN for ; Sun, 30 Oct 2016 01:06:48 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE51B1293FF for ; Sun, 30 Oct 2016 01:06:48 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h14so120340086ywa.2 for ; Sun, 30 Oct 2016 01:06:48 -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=1UZrxUHFWVYXw2KmqZMVE5+ZsZ004PL2SZjDUL5c3z4=; b=wK7RST5Toi5PU96cNk5VhAFYYqI0z4Iq8MzRqT9GfzKlHCcxYhhWoSjuiTbhbFvIja ILmhvxvfONeOUHS8A17BClup2oKQDhXs8YDKABdbbXngFA0q+NEPXaizCIsAkE8lo9OP DiakVUfqhfhJEOpwIyxDHYiek1VG5haKGhDw4VRgKEgfGJg0ivb79FCXMB1mB9I1sB2b tYpwqQJ15QG//1bF6AdFj3i/8QGxJYetKifp2mPT82w1FXuib+m9ow1gnZ+adpv0ObGJ VR9eDU/NxeZyx4rnWW++Sfua88mgJFW+zykfm0HGMbagRBqVCahjy43bD8c0Nrc7c7ME jHjg== 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=1UZrxUHFWVYXw2KmqZMVE5+ZsZ004PL2SZjDUL5c3z4=; b=NeNEmI1SlR0S5Jyr28lImr6kP82lWhdgcsh4Dk1th5FG7me+yVN8dx4wovoIg67Tup 6vJrb+XkAb1HgcCPW1SNqj13NiwMz6hujdN5r1fT5d2NRz1shUzQiIisrq0lkiOGjoWC e5pGjiLZbdeJ3II5TjLRlk6JN4aohYM3ewqjr9NixG0WwxQxwiIAvNTvnXTwUHc/8xxl 9Evq/EaNEcaXM0S+YY5IBaDNcMBaKutghYRVmQjxPiDke/ro3FB5LwMBYEMZV6QTz5eJ aHZz9pnFMEI5c3ZNE5V6u0Va2DVxr1mDgTHovxMQY7MQRaZIqPkTzKUJq4+8LE3IX9Tm lIZw== X-Gm-Message-State: ABUngveSd+HJtvo2Zg8puD/vbseizmtdDDHUAlkpGyB+M0e29Eeqj0EvHUHKNl3By2KHvtQTFrh+kp3ahGPZJQ== X-Received: by 10.13.199.135 with SMTP id j129mr18067192ywd.247.1477814807840; Sun, 30 Oct 2016 01:06:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 01:06:47 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 30 Oct 2016 09:06:47 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] [WIP] XML Schema for EBML Schema 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, 30 Oct 2016 08:06:50 -0000 2016-10-18 4:46 GMT+02:00 Dave Rice : > Hi all, > > I posted a draft XML Schema in this pull request https://github.com/Matro= ska-Org/ebml-specification/pull/115/files. This xsd allows an EBML Schema t= o be validated. For instance using the EBMLSchema.xsd from the PR [1] and t= he ebml_matroska.xsd (expression of an EBML Schema) from the matroska-speci= fication repo [2], one can validate ebml_matroska.xml (a draft EBML Schema)= via: > > xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml When running that with the linked files I get a lot of validation failure (cppname and webm to name a few). For cppname it was an internal thing that was useful to generate the semantic C and C++ files used by libmatroska and libmatroska2. I will update my tools to add those specific changes locally from the official Matroska Schema. For webm that should probably be stripped as well from the official Schema. Google changes their support as they see fit. They may create an RFC stating which elements are supported and even provide their own Webm Schema. Also our Schema will not cover the "webm" DocType. > I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and see = a few such as RFC5168 and RFC5935 that do. I think an XML Schema can help t= he working group internally by giving us a method to verify that Matroska= =E2=80=99s EBML Schema (ebml_matroska.xsd) stays valid during updates by th= e working group, though it could also be incorporated into the specificatio= n for EBML. Is putting an XML Schema in an RFC advisable or should this sta= y external to the RFC? IMO it's good as an annex. > From using the draft EBMLSchema.xsd on ebml_matroska.xml, it highlights a= few issues with the current ebml_matroska.xml. > > - un-standardized attributes > > Matroska=E2=80=99s EBML Schema includes unstandardized attributes such as= =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2=80=98webm=E2=80= =99. Should the EBML Schema allow unknown attributes or should these three = be removed or incorporated? Feasible we could have a separate ebml_webm.xml= document since it=E2=80=99s a separate EBML Document Type. Also the =E2=80= =98divx=E2=80=99 elements could be removed and put into an EBML Schema exte= nsion (though we=E2=80=99d have to define how EBML Document Type Extensions= should work). (I should read the rest of an email before starting a reply). Yes the DivX stuff should also be stripped. It falls in the category of adding new elements from another RFC/source. And yes we need to know how to "append" elements to the official/main/v1 Matroska Schema. > - HTML embedded in > > The definitions in the element include HTML tags: , , and . Should HTML tags be permitted in EBML Schema defini= tions? Possibly we could reduce the need for many(all?) of them by extendin= g EBML Schema with additional elements such as methods to handle enumeratio= n and references (see https://github.com/Matroska-Org/ebml-specification/is= sues/114). How about Markdown syntax instead ? It doesn't collide with XML. (sorry Ret= o) > - maxOccurs is not defined as integer only > > In the recent updates to the EBML Schema, maxOccurs used to be an integer= or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2=80=99,= but is now integer only. However in ebml_matroska.xml we have 43 elements = defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should we change ma= xOccurs back or find some method of expressing an unbounded occurrence limi= t with an integer? The doc for the EBMLMaxOccurrence path element says: If `EBMLMaxOccurrence` is not present then that `EBML Element` is considered to have an unbounded `EBMLMaxOccurrence` value. That's consistent with ABNF patterns. I suppose that's also how XML maxOccurs work? So I suppose we should update the maxOccurs elements. Adding 1 where it's missing, and removing elements that had unbounded. I'll do a PR that way. > Dave Rice > > [1]: https://raw.githubusercontent.com/Matroska-Org/ebml-specification/dc= 1803dfbc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd > [2]: https://raw.githubusercontent.com/Matroska-Org/matroska-specificatio= n/gh-pages/ebml_matroska.xml > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 30 01:40:30 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 3D80C129522 for ; Sun, 30 Oct 2016 01:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl118pdlzBjB for ; Sun, 30 Oct 2016 01:40:27 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BF412951D for ; Sun, 30 Oct 2016 01:40:27 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id v78so1889526ybe.3 for ; Sun, 30 Oct 2016 01:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pkf0qsqiIhRXmpUj9pXib/ZJ5ITNfbkGj0AVRzNbgEo=; b=HQw5ZLLFa5lHR02zI/gAy8VSzkKRqNEVvYvtvKY3yZ6HfwG08Ln3PYINVIzqgM0HFj U6M/yZDn01lYk/sYYMbmuF7x5dh78z7RPZVDKc4NabXGglxLadrdcx4+mB2Cy6x50bbf 8XsM1/pzyq2/usRWGSllk0AYW340n59iFmp5pi9DzBW1k45S6hL8UCv/lycyWLx1Dlg3 y9p9q4AZA7wEmOTuZa8QDbsuHLoGX2HxEPXfGKEE/KtJLX/+sNCE/RAaFWiAE7R7c4Rj byCB6yU0eeXCyUj2wLMtN35AJsKBPN+GcZ2yhRQZr/zjgJCuVj7A599mpH5b1xFL1GKE tLmQ== 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=Pkf0qsqiIhRXmpUj9pXib/ZJ5ITNfbkGj0AVRzNbgEo=; b=DLZGeZUneCDA6UNyr19jMuipzK1KDnyaIG5odGYyz2zmh+bnseLBKlJRyKaLcKKcQY 0A3gtEdvRa314+Vr1G4FiAUW0APfv/JMLg2xiG3M0uvM5gG25CSd7N6fkLOvUMFUvDxz fu4jzH+zpr8qMzimw4+bd5a/hyCh4x/CAeYvMqGyspscstu7VQ2Ah9/T+9+Pq1FDsSqJ ntTDuo/Yg0z7xbImA7l3W3GeWKst9QwSXS1VV4wnKdf51/qKyki+xt3dQlNdbgQNEyFC ppVJKnJOGKvUbuGBvoFs0JOTkxLTtl2OD5HY4uf+QWCwCT4CxR+p0xFF4j1OLssYBZni o4mQ== X-Gm-Message-State: ABUngvdzTBJoym+XlMoiio9pxB2GKm3Ki+Q0b19PnTFKQfd+pgYNYPf3tmqjVgslGR6jSTAUwRdDFdVF9swHFw== X-Received: by 10.37.125.135 with SMTP id y129mr18196916ybc.179.1477816826543; Sun, 30 Oct 2016 01:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 01:40:26 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 30 Oct 2016 09:40:26 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] [WIP] XML Schema for EBML Schema 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, 30 Oct 2016 08:40:29 -0000 2016-10-30 9:06 GMT+01:00 Steve Lhomme : > 2016-10-18 4:46 GMT+02:00 Dave Rice : >> Hi all, >> >> I posted a draft XML Schema in this pull request https://github.com/Matr= oska-Org/ebml-specification/pull/115/files. This xsd allows an EBML Schema = to be validated. For instance using the EBMLSchema.xsd from the PR [1] and = the ebml_matroska.xsd (expression of an EBML Schema) from the matroska-spec= ification repo [2], one can validate ebml_matroska.xml (a draft EBML Schema= ) via: >> >> xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml > > When running that with the linked files I get a lot of validation > failure (cppname and webm to name a few). > > For cppname it was an internal thing that was useful to generate the > semantic C and C++ files used by libmatroska and libmatroska2. I will > update my tools to add those specific changes locally from the > official Matroska Schema. > > For webm that should probably be stripped as well from the official > Schema. Google changes their support as they see fit. They may create > an RFC stating which elements are supported and even provide their own > Webm Schema. Also our Schema will not cover the "webm" DocType. > >> I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and see= a few such as RFC5168 and RFC5935 that do. I think an XML Schema can help = the working group internally by giving us a method to verify that Matroska= =E2=80=99s EBML Schema (ebml_matroska.xsd) stays valid during updates by th= e working group, though it could also be incorporated into the specificatio= n for EBML. Is putting an XML Schema in an RFC advisable or should this sta= y external to the RFC? > > IMO it's good as an annex. > >> From using the draft EBMLSchema.xsd on ebml_matroska.xml, it highlights = a few issues with the current ebml_matroska.xml. >> >> - un-standardized attributes >> >> Matroska=E2=80=99s EBML Schema includes unstandardized attributes such a= s =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2=80=98webm=E2= =80=99. Should the EBML Schema allow unknown attributes or should these thr= ee be removed or incorporated? Feasible we could have a separate ebml_webm.= xml document since it=E2=80=99s a separate EBML Document Type. Also the =E2= =80=98divx=E2=80=99 elements could be removed and put into an EBML Schema e= xtension (though we=E2=80=99d have to define how EBML Document Type Extensi= ons should work). > > (I should read the rest of an email before starting a reply). > > Yes the DivX stuff should also be stripped. It falls in the category > of adding new elements from another RFC/source. And yes we need to > know how to "append" elements to the official/main/v1 Matroska Schema. > >> - HTML embedded in >> >> The definitions in the element include HTML tags: , <= br>, and . Should HTML tags be permitted in EBML Schema defin= itions? Possibly we could reduce the need for many(all?) of them by extendi= ng EBML Schema with additional elements such as methods to handle enumerati= on and references (see https://github.com/Matroska-Org/ebml-specification/i= ssues/114). > > How about Markdown syntax instead ? It doesn't collide with XML. (sorry R= eto) > >> - maxOccurs is not defined as integer only >> >> In the recent updates to the EBML Schema, maxOccurs used to be an intege= r or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2=80=99= , but is now integer only. However in ebml_matroska.xml we have 43 elements= defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should we change m= axOccurs back or find some method of expressing an unbounded occurrence lim= it with an integer? > > The doc for the EBMLMaxOccurrence path element says: > If `EBMLMaxOccurrence` is not present then that `EBML Element` is > considered to have an unbounded `EBMLMaxOccurrence` value. > > That's consistent with ABNF patterns. I suppose that's also how XML > maxOccurs work? So I suppose we should update the maxOccurs elements. > Adding 1 where it's missing, and removing elements that had unbounded. > I'll do a PR that way. https://github.com/Matroska-Org/ebml-specification/pull/124 https://github.com/Matroska-Org/matroska-specification/pull/64 The latter is manually edited so there might be issues. What about bytesize ? The validator says it's not valid but it seems to me it should be valid. >> Dave Rice >> >> [1]: https://raw.githubusercontent.com/Matroska-Org/ebml-specification/d= c1803dfbc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd >> [2]: https://raw.githubusercontent.com/Matroska-Org/matroska-specificati= on/gh-pages/ebml_matroska.xml >> _______________________________________________ >> 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 Sun Oct 30 02:10: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 3C5751293DF for ; Sun, 30 Oct 2016 02:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kqUOUQpkUJ6 for ; Sun, 30 Oct 2016 02:10:21 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 D9701126579 for ; Sun, 30 Oct 2016 02:10:20 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id d128so50024782ybh.2 for ; Sun, 30 Oct 2016 02:10:20 -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=lDj0BkCqW6+39kbZgc9rRL1OaxKbCUrPQH1OjLC6aOc=; b=VEdz61KnSI/k8D2aziUYBJX95whm4eXAuD6wvL19pViX90qJ5i07aOvwwBGslyHTBq 9fW7Cqq6BAJjwvWxMM6u+z5TmiR7TqXrJ6U8M82tayXdGViQfjHvxvK6hanaye+hjBfc Z6IlCiZ9xlg1Hzkl5D/4aKD1vO3dkd2V1rGuorxKsnUqifHKdKkStSUcSbMo4lHNa34A HxroDajq1yajAIAMNquKZ+DhwmG4Uul1PRBeCG16f8X28W9fMPFPgHdoFEEbKyHL+cno pqTX9xk2PxjG5C/7SVHxrWQaBIDRUShVIOEfYMRyriDtpHUxTGQ4SyCIKIROO9ZocONH AnTg== 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=lDj0BkCqW6+39kbZgc9rRL1OaxKbCUrPQH1OjLC6aOc=; b=ZoGhN1TD4d5yYNXWpqwS7awRgX2vSAwdPAAxvYvaxfwtjTug1s4aB9aqiz0zXa5/1V 8PZungMkB2z9o6M9auEuqpmZ4Zzeg/eRrLl9aH+iM+Ps18QofN5HTTP7jaVC3WEHtB0g B4uDfXz3fLR5Ct9/IQ341zR7gFbj953bXviAAFB5v4/RWI+r/kRHgmqAua8lidB/ax1v 7CMBNez3KCaMtDZ2XzzoQCSk0GqtXYVckUo2KDtduFLRsm6UHIIFFjxeptow3r82ctDI Qbgo/oIx3cLmsuAgu/YYt9q60q/IvUpct2pHJJoLHKzZgKV8isYoyDI8of2UpJ5olIx5 /VnQ== X-Gm-Message-State: ABUngvdQ15gsau1IadVdZHGLxczyd6znAcHSbUPk2YW/YjRwHpanHTiR60udRYjA43remKeh0PtMzCS+xGbh+w== X-Received: by 10.37.56.82 with SMTP id f79mr18523037yba.94.1477818619743; Sun, 30 Oct 2016 02:10:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 02:10:19 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 30 Oct 2016 10:10:19 +0100 Message-ID: To: Michael Bradshaw Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Reto Kromer 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: Sun, 30 Oct 2016 09:10:22 -0000 Hello Michael, This issue was already raised in this thread: https://mailarchive.ietf.org/arch/search/?email_list=3Dcellar&gbt=3D1&index= =3DHzxRVJouLAtFitvTMWF_ZbHuoKE The conclusion was... unconclusive. So far we probably lean towards borrowing the channel mapping from AVI/Microsoft. For ambisonic I'm not sure that's sufficient though. Also this really makes sense for PCM/raw codecs. Other ones should have their own internal mapping as they usually use some channel coupling for better efficiency. Maybe lossless codecs could also lack channel mapping and rely on the container. 2016-10-17 18:32 GMT+02:00 Michael Bradshaw : > Matroska currently lacks audio channel layout specification (the containe= r > has no way to indicate which channel corresponds to which speaker for > surround-sound layouts). As is, channel layout has to be read/inferred fr= om > audio codec-level data (whether stored in CodecPrivate or somewhere else)= . > For Opus and Vorbis this isn't much of a problem, but I don't know enough > about other codecs to know if some might be problematic in Matroska. > > While we're considering ambisonics in Matroska, I think we should also > consider the broader channel layout issue. If we add ambisonic-related in= fo > to Matroska, I think we also need to add surround-sound channel info to > Matroska. If we don't add surround-sound channel info to Matroska, then > perhaps we shouldn't for ambisonics either and instead require the codec = to > determine the channel order (e.g. > https://tools.ietf.org/html/draft-ietf-codec-ambisonics). > > Generally I think it might be nice to have this information in Matroska, = but > there are *tons* of ways to arrange audio channels and I'm concerned abou= t > specification bloat. > > On Sun, Oct 16, 2016 at 7:58 AM, Steve Lhomme wrot= e: >> >> I added an "issue" so we don't forget >> https://github.com/Matroska-Org/ebml-specification/issues/114 >> >> 2016-10-16 16:55 GMT+02:00 Reto Kromer : >> > Steve Lhomme wrote: >> > >> >> 2016-10-14 4:34 GMT+02:00 Dave Rice : >> >>> >> >>> >> >>> On Aug 30, 2016, at 12:40 PM, Michael Bradshaw >> >> >> >> wrote: >> >>> >> >>> >> >>> Matroska currently doesn't have a way to specify projection >> >> >> >> information for >> >>> >> >>> 360/VR videos. Google's Spherical Video V2 RFC draft was just update= d >> >> >> >> a few >> >>> >> >>> days ago to include some new elements specifying projection and view= er >> >> >> >> 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 i= n >> >>> Matroska. Assuming there hasn't been any, is there interest in addin= g >> >> >> >> 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-vi= deo >> >> -v2-rfc.md#webm-matroska >> >>> >> >>> >> >>> >> >>> After hearing Andrew Scherkus=E2=80=99s presentation at Demuxed on t= he >> >> >> >> standardizing >> >>> >> >>> spatial media, I drafted a pull request at >> >>> https://github.com/Matroska-Org/matroska-specification/pull/53 for >> >>> consideration which adds the projection elements (from Michael=E2=80= =99s link >> >> >> >> above) >> >>> >> >>> to Matroska=E2=80=99s EBML Schema. This pull request is dependent on= another >> >> >> >> pull >> >>> >> >>> request at >> >> >> >> https://github.com/Matroska-Org/matroska-specification/pull/42 >> >>> >> >>> which is an adjustment to Matroska=E2=80=99s EBML Schema based on re= cent EBML >> >>> specification updates. >> >>> >> >>> Some considerations from writing this pull request: >> >>> >> >>> There are several Matroska elements that describe enumerated values >> >> >> >> and the >> >>> >> >>> `Projection` Child Elements make use of enumeration lists as well. >> >> >> >> Currently >> >>> >> >>> the practice in Matroska element definitions appear to enumerate in >> >> >> >> this >> >>> >> >>> form =E2=80=9C(1: description of the first option, 2: description of= another >> >> >> >> option, >> >>> >> >>> 3: one more option)=E2=80=9D. Perhaps it=E2=80=99s worthwhile to sta= ndardize how >> >> >> >> enumeration >> >>> >> >>> lists are expressed in the EBML Schema, so that rather than: >> >>> >> >>> > >>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >> >> >> >> id=3D"0x7671" >> >>> >> >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range= =3D"0-3" >> >> >> >> webm=3D"1"> >> >>> >> >>> Describes the projection used for this >> >> >> >> video >> >>> >> >>> track. Valid values: (0: Rectangular, 1: Equirectangular, 2: Cubemap= , >> >> >> >> 3: >> >>> >> >>> Mesh) >> >>> >> >>> >> >>> we could have something like >> >>> >> >>> > >>> path=3D"1*1(\Segment\Tracks\TrackEntry\Video\ProjectionType)" >> >> >> >> id=3D"0x7671" >> >>> >> >>> type=3D"uinteger" minOccurs=3D"1" minver=3D"4" default=3D"0" range= =3D"0-3" >> >> >> >> webm=3D"1"> >> >>> >> >>> Describes the projection used for this >> >> >> >> video >> >>> >> >>> track. >> >>> Rectangular >> >>> Equirectangular >> >>> Cubemap >> >>> Mesh >> >>> >> >>> >> >>> Is breaking down enumeration into a structure like this helpful or >> >>> over-engineering? >> >> >> >> >> >> No I think it's really worth. There could be a documentation for each >> >> element, and in various languages. >> > >> > >> > +1 >> > >> > >> >>> Also although I see the documentation for Projection in webm, but is >> >> >> >> there a >> >>> >> >>> comparable set of documentation for ambisonics in webm? The draft at >> >>> >> >> https://github.com/google/spatial-media/blob/ >> >> 9bc4691f748a553a06b4b297f05ec2a62e53da1b/docs/spatial-audio-rfc.md >> >>> >> >>> only references mp4. >> >>> >> >>> Dave Rice >> >>> >> >> >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Oct 30 02:11: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 DFF8F12951D for ; Sun, 30 Oct 2016 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 SctgiARvxwXY for ; Sun, 30 Oct 2016 02:11:33 -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 62A621293FF for ; Sun, 30 Oct 2016 02:11:33 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h14so120689259ywa.2 for ; Sun, 30 Oct 2016 02:11: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; bh=d+8izSLuwXWzwsdDVkEcqu81EIElL06wA6HwtnLjlms=; b=MMgkS0OmAywQfHEPMddBfkS4zdQupNDBJfMqhTtQMjFMHugaVPp3x92ubNhARDMn1K ZiJ5L0AOYUAEI8Dzn59j/eO1XDGNzRZVSEfPr2Fq/SDxx9Z1158bje+9SqnGDT7U8+nk fF1o9YY2aDfYW1DMsokfBakrQoXeroYnb7JO1ygQGpBM3HWYlQJvuIsmer3cJDa3FJXV 111f8uro8FGl484eeV43WMMe7xOKCQe1F97BWGReOsIITu/0Kv7zLtgh0sQVoRLDLBk2 9Faqds9tyYcmLlLCcDCHcsi9qbyy40bMhMDqkAJUw8OrcTPjt3WGsNLXKU8b/xIBTPJ4 Afxg== 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=d+8izSLuwXWzwsdDVkEcqu81EIElL06wA6HwtnLjlms=; b=nE/LKez/1oFjg2a0Hm0SwGMsGKd0lsSvAql+OYOcmvWHcP5L/xzlIwFqqE3zIwMoqr jcyoHdi0KBhKjLL9cUkEKyk9dwD0Shy5W87liCJs4Iz4krOzFBS3IKIyGkh2OQ6yGtnK DUN/YrGexYow2sMvb3AxnuCh0+dzL/1XGsnWESdkHcTzHQ+1Isu+bS36UGqkM5yH1IIa q7RYhUSRQjjPqxSRYrckri97xbvzQshTXc/t62qjkSsnICrGP60hr5HhHUgg4Z4meT1Z 7d6ioy0CXMoUPUuSS/s0J817bYBIq9Ed5F7L4kkQb3vl01nSb8sgPtHhBsekEqfhtOHZ RrVQ== X-Gm-Message-State: ABUngvcoXV+9dGp+SLFKmw84I812cvsRMoM3EkALmqIGe9Gx86aEghDkea4YzFkcjn1/8rlv/2ROjlJJnUs1Ww== X-Received: by 10.129.53.139 with SMTP id c133mr11659452ywa.70.1477818692633; Sun, 30 Oct 2016 02:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 02:11:32 -0700 (PDT) In-Reply-To: <0aa94dda-1393-8476-e0aa-7df4897ce060@gmx.ch> References: <0F80AD27-42AF-418B-8FC6-2B7D6EA4D1FD@dericed.com> <0aa94dda-1393-8476-e0aa-7df4897ce060@gmx.ch> From: Steve Lhomme Date: Sun, 30 Oct 2016 10:11:32 +0100 Message-ID: To: hubblec4 Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska Menu Specifications 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, 30 Oct 2016 09:11:35 -0000 2016-10-16 21:01 GMT+02:00 hubblec4 : > Hi all, > > Am 16.10.2016 um 16:22 schrieb Steve Lhomme: >> >> Files exist, playback exists. But it's mostly proof of concept things. >> >> It's the kind of thing that will definitely benefit from proper >> documentation. But for now we may strip the elements that are specific >> to menus so it can be specified properly without blocking things >> people actually use. There are also 2 possible chapter codecs in use >> the Matroska one and the DVD one. The Matroska is simple enough and >> supported in a few players so we may keep that one and/or work on that >> in priority. > > > To understand the DVD menu system, I got a lot of headache, cause its so > complex. But the Matroska menu is simple and it has at the moment only one > command(GoToAndPlay-ChapterUID). > We could add more commands which we need to create a simple but powerful > Matroska menu. > Menu features like: > Track selection (which is supported by HAALI via Tags(TRACKSETEX)) > Vob Buttons -> Matroska Buttons to controll the Matroska content in the > player screen > should be included. > > Maybe I have a little bit time than I could write an overview about the > Matroska menu. > - Infos about what is possible in theory and what in practice > - Needed things to play a Matroska menu > - Controlling > - Using > - Samples > - and more > > In what for a format should I write this Infos? Right now any format that fits your needs. We can formalize later if it's usable. > Best regards > Martin > > >> 2016-10-10 21:52 GMT+02:00 Dave Rice : >>> >>> Hi all, >>> There is a draft document at >>> https://matroska.org/technical/menu/index.html which has been incorporated >>> into our Matroska working repository at >>> https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/menu.md. >>> >>> The document appears more like a wishlist than a specification. Is there >>> any further information available on Menu features of Matroska? Should the >>> document be removed for now? Do Matroska menus exist? >>> Dave >>> _______________________________________________ >>> 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 -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 30 02:35: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 717CA129475 for ; Sun, 30 Oct 2016 02:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUb1N5U_58xu for ; Sun, 30 Oct 2016 02:35:16 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 17C27126B6D for ; Sun, 30 Oct 2016 02:35:16 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id f97so50607655ybi.1 for ; Sun, 30 Oct 2016 02:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjvZWq9vkg+cEyI6qTHKUwa5I/Mq69Tj44dUoYU3CsQ=; b=ZdXvAAA96CUGq9rRIsE7/3W4ChHUpjtj4D60r2HjxsMjES9QmeFA02Jx0ieKfzdJ5n v6bKSLnPWtEjbMsYfbdh+0BjLYTKr6vyYTuI5dojoH1qZfB0DaPLbVj3khUT90tYV+Ca OypHu4riz43+71nUDyiVuVahpm4W6NxxfBZ26yZAFBJYpUiz5F6L0n5UTgR4WWEz5VlX tarmBNJpf8jHfoxBXAC3aQg28AP2E492alLmA3Nc4owEa+gWxfxDb8B2kKobtptR55RG CLo9/sRqnzIBO7qsmY2Opl3IN7iEUAItpblqFolBFmrEjJ1xIQ+wYLtRkPE0rV3aKId6 OTSw== 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=jjvZWq9vkg+cEyI6qTHKUwa5I/Mq69Tj44dUoYU3CsQ=; b=gUfuuTithsPVV1rnas63nIHYRXV4zgTg2X9cI6bWBKMvY1UhiWBxY22V3JsJOGFTiq 30vVk0kSEcx7y/qHwDxWt4uIf85uZSmSP4jgwB0Q0ahgtk248S5jYbmKG7YEiqGEGbyc 4vXJIrACeG7hds/rbUJZzfWAJYl5CuW9atPQRxLZbVOxUk1yzeZ9PApobcXPvzO/38Xu rK2Lw2flhvDn2uoTSF38bISA4nPomlr6DMRrjUhgHo3fnAmFyV1+OciahWL7BPoPdzdA ltE38vAD7UOoKRZCzbi3455RU6j6CdJ0csDU+ndfBQdYTOZ/nSqwE4Ws9qGuzVca18E6 2Xbw== X-Gm-Message-State: ABUngve4Js1b3kDJPWk/k4SsRQEbUO7Eg/dqi03tb+u/StKIO8y3UTXqGWANIBkY+Z1czpHk2yuhJ0LFeuMw1w== X-Received: by 10.37.125.135 with SMTP id y129mr18303815ybc.179.1477820115258; Sun, 30 Oct 2016 02:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 02:35:14 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 30 Oct 2016 10:35:14 +0100 Message-ID: To: "Sebastian G. " Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EBML spec questions 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, 30 Oct 2016 09:35:17 -0000 2016-10-23 17:39 GMT+02:00 Sebastian G. : > Hi, > > I have a few questions regarding the EBML specs. > > "Date Element" > > What happens after "2293-04-11T11:47:16.854775807 UTC"? > > Is there a way to use the date type after that date for dates after the > date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? > > If that is not the case, then why can't it be the case? (I do understand > the limitation due to the maximum of the octets, but not why it has to > be a signed integer, whereas an unsigned integer would allow a larger > range, even though only positive.) We want to be able to add dates to things that were recorded before 2001. Which is currently more common that 2294. However far the year 2294, people doing projections far in the future might have use for larger dates. But they can always use a binary format with a larger range. Their DocType will tell them how to interpret the data. > "EBML Schema" > > "The DocType value for an EBML Document Type SHOULD be unique and > persistent." > > What would be a reason for violation that SHOULD? Wouldn't that be > better a MUST? IMO we cannot ensure/guarantee the uniqueness globally. So it's a requirement that should be done as best as possible but can't be verified. > Best Regards, > Sebastian > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Oct 30 04:53:12 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 E0CFA1294E1 for ; Sun, 30 Oct 2016 04:53:10 -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 KaF0LqMBhWfR for ; Sun, 30 Oct 2016 04:53:09 -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 11A0212944B for ; Sun, 30 Oct 2016 04:53:09 -0700 (PDT) Received: from [172.56.35.77] (port=22599 helo=[30.206.210.225]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1c0ofi-001ajK-K3; Sun, 30 Oct 2016 07:53:08 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dave Rice X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Sun, 30 Oct 2016 07:53:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <420EBA53-E4E9-4219-A915-6336C58A4F03@dericed.com> References: To: Steve Lhomme 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: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] [WIP] XML Schema for EBML Schema 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, 30 Oct 2016 11:53:11 -0000 > On Oct 30, 2016, at 04:40, Steve Lhomme wrote: >=20 > 2016-10-30 9:06 GMT+01:00 Steve Lhomme : >> 2016-10-18 4:46 GMT+02:00 Dave Rice : >>> Hi all, >>>=20 >>> I posted a draft XML Schema in this pull request https://github.com/Matr= oska-Org/ebml-specification/pull/115/files. This xsd allows an EBML Schema t= o be validated. For instance using the EBMLSchema.xsd from the PR [1] and th= e ebml_matroska.xsd (expression of an EBML Schema) from the matroska-specifi= cation repo [2], one can validate ebml_matroska.xml (a draft EBML Schema) vi= a: >>>=20 >>> xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml >>=20 >> When running that with the linked files I get a lot of validation >> failure (cppname and webm to name a few). >>=20 >> For cppname it was an internal thing that was useful to generate the >> semantic C and C++ files used by libmatroska and libmatroska2. I will >> update my tools to add those specific changes locally from the >> official Matroska Schema. >>=20 >> For webm that should probably be stripped as well from the official >> Schema. Google changes their support as they see fit. They may create >> an RFC stating which elements are supported and even provide their own >> Webm Schema. Also our Schema will not cover the "webm" DocType. >>=20 >>> I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and see= a few such as RFC5168 and RFC5935 that do. I think an XML Schema can help t= he working group internally by giving us a method to verify that Matroska=E2= =80=99s EBML Schema (ebml_matroska.xsd) stays valid during updates by the wo= rking group, though it could also be incorporated into the specification for= EBML. Is putting an XML Schema in an RFC advisable or should this stay exte= rnal to the RFC? >>=20 >> IMO it's good as an annex. >>=20 >>> =46rom using the draft EBMLSchema.xsd on ebml_matroska.xml, it highlight= s a few issues with the current ebml_matroska.xml. >>>=20 >>> - un-standardized attributes >>>=20 >>> Matroska=E2=80=99s EBML Schema includes unstandardized attributes such a= s =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2=80=98webm=E2=80= =99. Should the EBML Schema allow unknown attributes or should these three b= e removed or incorporated? Feasible we could have a separate ebml_webm.xml d= ocument since it=E2=80=99s a separate EBML Document Type. Also the =E2=80=98= divx=E2=80=99 elements could be removed and put into an EBML Schema extensio= n (though we=E2=80=99d have to define how EBML Document Type Extensions shou= ld work). >>=20 >> (I should read the rest of an email before starting a reply). >>=20 >> Yes the DivX stuff should also be stripped. It falls in the category >> of adding new elements from another RFC/source. And yes we need to >> know how to "append" elements to the official/main/v1 Matroska Schema. >>=20 >>> - HTML embedded in >>>=20 >>> The definitions in the element include HTML tags: , <= br>, and . Should HTML tags be permitted in EBML Schema defini= tions? Possibly we could reduce the need for many(all?) of them by extending= EBML Schema with additional elements such as methods to handle enumeration a= nd references (see https://github.com/Matroska-Org/ebml-specification/issues= /114). >>=20 >> How about Markdown syntax instead ? It doesn't collide with XML. (sorry R= eto) >>=20 >>> - maxOccurs is not defined as integer only >>>=20 >>> In the recent updates to the EBML Schema, maxOccurs used to be an intege= r or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2=80=99,= but is now integer only. However in ebml_matroska.xml we have 43 elements d= efined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should we change maxO= ccurs back or find some method of expressing an unbounded occurrence limit w= ith an integer? >>=20 >> The doc for the EBMLMaxOccurrence path element says: >> If `EBMLMaxOccurrence` is not present then that `EBML Element` is >> considered to have an unbounded `EBMLMaxOccurrence` value. >>=20 >> That's consistent with ABNF patterns. I suppose that's also how XML >> maxOccurs work? So I suppose we should update the maxOccurs elements. >> Adding 1 where it's missing, and removing elements that had unbounded. >> I'll do a PR that way. >=20 > https://github.com/Matroska-Org/ebml-specification/pull/124 > https://github.com/Matroska-Org/matroska-specification/pull/64 >=20 > The latter is manually edited so there might be issues. >=20 > What about bytesize ? The validator says it's not valid but it seems > to me it should be valid. IIIRC bytesize should be changed to size. There may have been a PR for that c= hange. Dave >>> Dave Rice >>>=20 >>> [1]: https://raw.githubusercontent.com/Matroska-Org/ebml-specification/d= c1803dfbc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd >>> [2]: https://raw.githubusercontent.com/Matroska-Org/matroska-specificati= on/gh-pages/ebml_matroska.xml >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>=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 Sun Oct 30 06:01:45 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 6FC351294A7 for ; Sun, 30 Oct 2016 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 ez9kLC8IfRm3 for ; Sun, 30 Oct 2016 06:01:42 -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 CD01E12955E for ; Sun, 30 Oct 2016 06:01:41 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u124so121628726ywg.3 for ; Sun, 30 Oct 2016 06:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fMi2Ng5NKwaoDJgkGvdf+jU0t5hPk1P3GbX4uVpfAmE=; b=EFu3oD17nSbZWOTufpE9OmtXLWQ3ZlVgx3hjwUeWCdyNDsoWsrXfhbr2ofK5b7OvS0 DgSPES0ncfScOYz14JyISk2V1jRZPiEKiZDKgZfyAHV6WmRvEVqT0V/frjS0vUfTMeIG XEciEwAlGHY7HOy6IduoIlkBtCO304li0wkVCisqmTj/xmiP69fdjUwHugMiBwdnGiTq y4wXAL0/oXIweLF36y3ocf/T81zNM6qiWTEnB47gg/Le6NfT/3Pka75MQz4Sdj1AX8Wb TdzX9pZulgbLgj4QOWrNQprwWFm0PjGpmfShT9aDJ5zEnrUyQc3uJXxJcXLdNDyYfowo ZYGg== 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=fMi2Ng5NKwaoDJgkGvdf+jU0t5hPk1P3GbX4uVpfAmE=; b=FyuJqvtOsMbVGcRDdd0VrG/HPpYd65wDIxXNq77KHOSmLqXru6KDtHwF5LYN3mSM4p p5VFVtVjfSXemRK5bc8178792ZijwSIV5jeuefwO8Th1NwOrLf1sXztPnDJkklN46DPZ TU+2sdI4a+sbjJc7elsgGt6GJKeazdpCxOG6gqMRpFgEz9OBNSqBodij4qSrhx2N2G5M o7ul2Z+BfJ6mKUlwyJ6rYyIyneP720qMJFak2mc/UB3HzYDxYFDeU5yOAryncJJiVcoi z+9CKuKjugPIUBBx7surPDKu5ffMyyOysxOJRGju/hhmylLBuSalClPV1VsfrzqdO5qj mlzQ== X-Gm-Message-State: ABUngvdSjOuvBZ80SyS1c2lOEfNyoFoKcqzQdBR0UDC2ybDKWijYTlEOu/3PBfE2buoazsdRk5mM438iDq/pCg== X-Received: by 10.129.53.139 with SMTP id c133mr12198326ywa.70.1477832500966; Sun, 30 Oct 2016 06:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 06:01:40 -0700 (PDT) Received: by 10.83.53.195 with HTTP; Sun, 30 Oct 2016 06:01:40 -0700 (PDT) In-Reply-To: <420EBA53-E4E9-4219-A915-6336C58A4F03@dericed.com> References: <420EBA53-E4E9-4219-A915-6336C58A4F03@dericed.com> From: Steve Lhomme Date: Sun, 30 Oct 2016 14:01:40 +0100 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=001a114216b64246f7054014b10f Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] [WIP] XML Schema for EBML Schema 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, 30 Oct 2016 13:01:44 -0000 --001a114216b64246f7054014b10f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 30 oct. 2016 12:53, "Dave Rice" a =C3=A9crit : > > > > > On Oct 30, 2016, at 04:40, Steve Lhomme wrote: > > > > 2016-10-30 9:06 GMT+01:00 Steve Lhomme : > >> 2016-10-18 4:46 GMT+02:00 Dave Rice : > >>> Hi all, > >>> > >>> I posted a draft XML Schema in this pull request https://github.com/Matroska-Org/ebml-specification/pull/115/files. This xsd allows an EBML Schema to be validated. For instance using the EBMLSchema.xsd from the PR [1] and the ebml_matroska.xsd (expression of an EBML Schema) from the matroska-specification repo [2], one can validate ebml_matroska.xml (a draft EBML Schema) via: > >>> > >>> xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml > >> > >> When running that with the linked files I get a lot of validation > >> failure (cppname and webm to name a few). > >> > >> For cppname it was an internal thing that was useful to generate the > >> semantic C and C++ files used by libmatroska and libmatroska2. I will > >> update my tools to add those specific changes locally from the > >> official Matroska Schema. > >> > >> For webm that should probably be stripped as well from the official > >> Schema. Google changes their support as they see fit. They may create > >> an RFC stating which elements are supported and even provide their own > >> Webm Schema. Also our Schema will not cover the "webm" DocType. > >> > >>> I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and = see a few such as RFC5168 and RFC5935 that do. I think an XML Schema can help the working group internally by giving us a method to verify that Matroska=E2= =80=99s EBML Schema (ebml_matroska.xsd) stays valid during updates by the working group, though it could also be incorporated into the specification for EBML. Is putting an XML Schema in an RFC advisable or should this stay external to the RFC? > >> > >> IMO it's good as an annex. > >> > >>> From using the draft EBMLSchema.xsd on ebml_matroska.xml, it highlights a few issues with the current ebml_matroska.xml. > >>> > >>> - un-standardized attributes > >>> > >>> Matroska=E2=80=99s EBML Schema includes unstandardized attributes suc= h as =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2=80=98webm=E2=80= =99. Should the EBML Schema allow unknown attributes or should these three be removed or incorporated? Feasible we could have a separate ebml_webm.xml document since it=E2=80=99s a separate = EBML Document Type. Also the =E2=80=98divx=E2=80=99 elements could be removed an= d put into an EBML Schema extension (though we=E2=80=99d have to define how EBML Document= Type Extensions should work). > >> > >> (I should read the rest of an email before starting a reply). > >> > >> Yes the DivX stuff should also be stripped. It falls in the category > >> of adding new elements from another RFC/source. And yes we need to > >> know how to "append" elements to the official/main/v1 Matroska Schema. > >> > >>> - HTML embedded in > >>> > >>> The definitions in the element include HTML tags: ,
, and . Should HTML tags be permitted in EBML Schema definitions? Possibly we could reduce the need for many(all?) of them by extending EBML Schema with additional elements such as methods to handle enumeration and references (see https://github.com/Matroska-Org/ebml-specification/issues/114). > >> > >> How about Markdown syntax instead ? It doesn't collide with XML. (sorry Reto) > >> > >>> - maxOccurs is not defined as integer only > >>> > >>> In the recent updates to the EBML Schema, maxOccurs used to be an integer or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2= =80=99, but is now integer only. However in ebml_matroska.xml we have 43 elements defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should we change maxOccurs back = or find some method of expressing an unbounded occurrence limit with an integer? > >> > >> The doc for the EBMLMaxOccurrence path element says: > >> If `EBMLMaxOccurrence` is not present then that `EBML Element` is > >> considered to have an unbounded `EBMLMaxOccurrence` value. > >> > >> That's consistent with ABNF patterns. I suppose that's also how XML > >> maxOccurs work? So I suppose we should update the maxOccurs elements. > >> Adding 1 where it's missing, and removing elements that had unbounded. > >> I'll do a PR that way. > > > > https://github.com/Matroska-Org/ebml-specification/pull/124 > > https://github.com/Matroska-Org/matroska-specification/pull/64 > > > > The latter is manually edited so there might be issues. > > > > What about bytesize ? The validator says it's not valid but it seems > > to me it should be valid. > > IIIRC bytesize should be changed to size. There may have been a PR for that change. Yes, I saw it afterwards and merged it. > Dave > > >>> Dave Rice > >>> > >>> [1]: https://raw.githubusercontent.com/Matroska-Org/ebml-specification/dc1803dfb= c23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd > >>> [2]: https://raw.githubusercontent.com/Matroska-Org/matroska-specification/gh-pa= ges/ebml_matroska.xml > >>> _______________________________________________ > >>> 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 > --001a114216b64246f7054014b10f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Le=C2=A030 oct. 2016 12:53, "Dave Rice" <dave@dericed.com> a =C3=A9crit=C2=A0:<= br> >
>
>
> > On Oct 30, 2016, at 04:40, Steve Lhomme <slhomme@matroska.org> wrote:
> >
> > 2016-10-30 9:06 GMT+01:00 Steve Lhomme <slhomme@matroska.org>:
> >> 2016-10-18 4:46 GMT+02:00 Dave Rice <dave@dericed.com>:
> >>> Hi all,
> >>>
> >>> I posted a draft XML Schema in this pull request http= s://github.com/Matroska-Org/ebml-specification/pull/115/files. This xsd= allows an EBML Schema to be validated. For instance using the EBMLSchema.x= sd from the PR [1] and the ebml_matroska.xsd (expression of an EBML Schema)= from the matroska-specification repo [2], one can validate ebml_matroska.x= ml (a draft EBML Schema) via:
> >>>
> >>> xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml=
> >>
> >> When running that with the linked files I get a lot of valida= tion
> >> failure (cppname and webm to name a few).
> >>
> >> For cppname it was an internal thing that was useful to gener= ate the
> >> semantic C and C++ files used by libmatroska and libmatroska2= . I will
> >> update my tools to add those specific changes locally from th= e
> >> official Matroska Schema.
> >>
> >> For webm that should probably be stripped as well from the of= ficial
> >> Schema. Google changes their support as they see fit. They ma= y create
> >> an RFC stating which elements are supported and even provide = their own
> >> Webm Schema. Also our Schema will not cover the "webm&qu= ot; DocType.
> >>
> >>> I=E2=80=99ve checked for other RFCs that incorporate XML = Schemas and see a few such as RFC5168 and RFC5935 that do. I think an XML S= chema can help the working group internally by giving us a method to verify= that Matroska=E2=80=99s EBML Schema (ebml_matroska.xsd) stays valid during= updates by the working group, though it could also be incorporated into th= e specification for EBML. Is putting an XML Schema in an RFC advisable or s= hould this stay external to the RFC?
> >>
> >> IMO it's good as an annex.
> >>
> >>> From using the draft EBMLSchema.xsd on ebml_matroska.xml,= it highlights a few issues with the current ebml_matroska.xml.
> >>>
> >>> - un-standardized attributes
> >>>
> >>> Matroska=E2=80=99s EBML Schema includes unstandardized at= tributes such as =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and =E2= =80=98webm=E2=80=99. Should the EBML Schema allow unknown attributes or sho= uld these three be removed or incorporated? Feasible we could have a separa= te ebml_webm.xml document since it=E2=80=99s a separate EBML Document Type.= Also the =E2=80=98divx=E2=80=99 elements could be removed and put into an = EBML Schema extension (though we=E2=80=99d have to define how EBML Document= Type Extensions should work).
> >>
> >> (I should read the rest of an email before starting a reply).=
> >>
> >> Yes the DivX stuff should also be stripped. It falls in the c= ategory
> >> of adding new elements from another RFC/source. And yes we ne= ed to
> >> know how to "append" elements to the official/main/= v1 Matroska Schema.
> >>
> >>> - HTML embedded in <documentation>
> >>>
> >>> The definitions in the <documentation> element incl= ude HTML tags: <a>, <br>, <del> and <strong>. Shoul= d HTML tags be permitted in EBML Schema definitions? Possibly we could redu= ce the need for many(all?) of them by extending EBML Schema with additional= elements such as methods to handle enumeration and references (see https://= github.com/Matroska-Org/ebml-specification/issues/114).
> >>
> >> How about Markdown syntax instead ? It doesn't collide wi= th XML. (sorry Reto)
> >>
> >>> - maxOccurs is not defined as integer only
> >>>
> >>> In the recent updates to the EBML Schema, maxOccurs used = to be an integer or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98ide= ntical=E2=80=99, but is now integer only. However in ebml_matroska.xml we h= ave 43 elements defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Sho= uld we change maxOccurs back or find some method of expressing an unbounded= occurrence limit with an integer?
> >>
> >> The doc for the EBMLMaxOccurrence path element says:
> >> If `EBMLMaxOccurrence` is not present then that `EBML Element= ` is
> >> considered to have an unbounded `EBMLMaxOccurrence` value. > >>
> >> That's consistent with ABNF patterns. I suppose that'= s also how XML
> >> maxOccurs work? So I suppose we should update the maxOccurs e= lements.
> >> Adding 1 where it's missing, and removing elements that h= ad unbounded.
> >> I'll do a PR that way.
> >
> > https://github.com/Matroska-Org/ebml-specification/pull/124
> > https://github.com/Matroska-Org/matroska-specification/pull/64
> >
> > The latter is manually edited so there might be issues.
> >
> > What about bytesize ? The validator says it's not valid but i= t seems
> > to me it should be valid.
>
> IIIRC bytesize should be changed to size. There may have been a PR for= that change.

Yes, I saw it afterwards and merged it.

> Dave
>
> >>> Dave Rice
> >>>
> >>> [1]: https://raw.githubusercontent.com/Matroska-Org/ebml-specification/dc= 1803dfbc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd
> >>> [2]: https://raw.github= usercontent.com/Matroska-Org/matroska-specification/gh-pages/ebml_matroska.= xml
> >>> _______________________________________________
> >>> 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
>

--001a114216b64246f7054014b10f-- From nobody Sun Oct 30 06:19: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 389671294A7 for ; Sun, 30 Oct 2016 06:19:21 -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 XjuwLZ5HVlKJ for ; Sun, 30 Oct 2016 06:19:19 -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 4A515127076 for ; Sun, 30 Oct 2016 06:19:19 -0700 (PDT) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:40824 helo=[10.0.1.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1c0q16-0029Cn-O9; Sun, 30 Oct 2016 09:19:18 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Sun, 30 Oct 2016 09:19:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Steve Lhomme X-Mailer: Apple Mail (2.3226) 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: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] [WIP] XML Schema for EBML Schema 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, 30 Oct 2016 13:19:21 -0000 > On Oct 30, 2016, at 4:06 AM, Steve Lhomme = wrote: >=20 > 2016-10-18 4:46 GMT+02:00 Dave Rice : >> Hi all, >>=20 >> I posted a draft XML Schema in this pull request = https://github.com/Matroska-Org/ebml-specification/pull/115/files. This = xsd allows an EBML Schema to be validated. For instance using the = EBMLSchema.xsd from the PR [1] and the ebml_matroska.xsd (expression of = an EBML Schema) from the matroska-specification repo [2], one can = validate ebml_matroska.xml (a draft EBML Schema) via: >>=20 >> xmllint --noout --schema EBMLSchema.xsd ebml_matroska.xml >=20 > When running that with the linked files I get a lot of validation > failure (cppname and webm to name a few). >=20 > For cppname it was an internal thing that was useful to generate the > semantic C and C++ files used by libmatroska and libmatroska2. I will > update my tools to add those specific changes locally from the > official Matroska Schema. >=20 > For webm that should probably be stripped as well from the official > Schema. Google changes their support as they see fit. They may create > an RFC stating which elements are supported and even provide their own > Webm Schema. Also our Schema will not cover the "webm" DocType. Actually the EBML specification at = https://github.com/Matroska-Org/ebml-specification/blob/fc7bcba4fc85fe9634= 6860ed3afb23528dada5a7/specification.markdown#-element-1 currently says "EBML Schemas MAY contain additional attributes to extend the semantics = but MUST NOT conflict with the definitions of the attributes = defined within this document." So either, the XML Schema should be adjusted to allow ANY attribute = within or we should remove this provision. I prefer the latter = but that would mean cleaning out the cppname and webm attributes. >> I=E2=80=99ve checked for other RFCs that incorporate XML Schemas and = see a few such as RFC5168 and RFC5935 that do. I think an XML Schema can = help the working group internally by giving us a method to verify that = Matroska=E2=80=99s EBML Schema (ebml_matroska.xsd) stays valid during = updates by the working group, though it could also be incorporated into = the specification for EBML. Is putting an XML Schema in an RFC advisable = or should this stay external to the RFC? >=20 > IMO it's good as an annex. >=20 >> =46rom using the draft EBMLSchema.xsd on ebml_matroska.xml, it = highlights a few issues with the current ebml_matroska.xml. >>=20 >> - un-standardized attributes >>=20 >> Matroska=E2=80=99s EBML Schema includes unstandardized attributes = such as =E2=80=98cppname=E2=80=99, =E2=80=98divx=E2=80=99, and = =E2=80=98webm=E2=80=99. Should the EBML Schema allow unknown attributes = or should these three be removed or incorporated? Feasible we could have = a separate ebml_webm.xml document since it=E2=80=99s a separate EBML = Document Type. Also the =E2=80=98divx=E2=80=99 elements could be removed = and put into an EBML Schema extension (though we=E2=80=99d have to = define how EBML Document Type Extensions should work). >=20 > (I should read the rest of an email before starting a reply). >=20 > Yes the DivX stuff should also be stripped. It falls in the category > of adding new elements from another RFC/source. And yes we need to > know how to "append" elements to the official/main/v1 Matroska Schema. >=20 >> - HTML embedded in >>=20 >> The definitions in the element include HTML tags: = ,
, and . Should HTML tags be permitted in EBML = Schema definitions? Possibly we could reduce the need for many(all?) of = them by extending EBML Schema with additional elements such as methods = to handle enumeration and references (see = https://github.com/Matroska-Org/ebml-specification/issues/114). >=20 > How about Markdown syntax instead ? It doesn't collide with XML. = (sorry Reto) >=20 >> - maxOccurs is not defined as integer only >>=20 >> In the recent updates to the EBML Schema, maxOccurs used to be an = integer or the strings =E2=80=98unbounded=E2=80=99 or =E2=80=98identical=E2= =80=99, but is now integer only. However in ebml_matroska.xml we have 43 = elements defined with `maxOccurs=3D=E2=80=98unbounded=E2=80=99`. Should = we change maxOccurs back or find some method of expressing an unbounded = occurrence limit with an integer? >=20 > The doc for the EBMLMaxOccurrence path element says: > If `EBMLMaxOccurrence` is not present then that `EBML Element` is > considered to have an unbounded `EBMLMaxOccurrence` value. >=20 > That's consistent with ABNF patterns. I suppose that's also how XML > maxOccurs work? So I suppose we should update the maxOccurs elements. > Adding 1 where it's missing, and removing elements that had unbounded. > I'll do a PR that way. >=20 >> Dave Rice >>=20 >> [1]: = https://raw.githubusercontent.com/Matroska-Org/ebml-specification/dc1803df= bc23102a26b1c13ebd0e1c52ca630703/EBMLSchema.xsd >> [2]: = https://raw.githubusercontent.com/Matroska-Org/matroska-specification/gh-p= ages/ebml_matroska.xml >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=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 Sun Oct 30 11:10: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 44D36129421 for ; Sun, 30 Oct 2016 11:10:32 -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 rVotODCMOkvd for ; Sun, 30 Oct 2016 11:10:30 -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 6305D12946A for ; Sun, 30 Oct 2016 11:10:30 -0700 (PDT) Received: from [192.168.2.129] ([94.220.4.228]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDFB2-1c6McI0eVQ-00GVY9; Sun, 30 Oct 2016 19:10:26 +0100 To: Steve Lhomme References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE Message-ID: <4811ddcd-67aa-52c2-9df3-f071fb5d6491@gmx.de> Date: Sun, 30 Oct 2016 19:10:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xKCKlWLQN4qlRKCpOc3qc5Wfk8TAV9NN+QmPKyJnT3Dbvn/0QzG JYOgYmUY3usbbamaBBAfxCjXgVtpKUBazsJ9Er1dff/BBwrb1ssIYe72XyE64bEX25OVgZh mVYaxybZD1GN9Ka8CfxP0jUt1NZ5zF3R3K9PGkfA7jTpMBsuRPQSIsdv3YJKCpozVb+MQvT 8wLnb7+LUruzUxWDzn0aw== X-UI-Out-Filterresults: notjunk:1;V01:K0:rIX6Bst90Ck=:XRIF04uGMXtkToMTdNpBz1 E1cSN/LMfyGTJFTDqB/bSpeLDgqi75TFsyQbyrAkie5x9yt1yAASWa7FmMzn6kDMNhdcVXoKt S7/Cj95v+gL/E1gT/e2I5+dxSIWso4zfiyU+rSLrd5dK+NY/E/wP4qAbGETKrJ/bcPsuwa7SI LcRrdgEmc1MrPE7pEoWVmX2vStdh4prE08ahTn2NZSUoFd6UVEfq4eW+MgADYYkfAGN9+2e3f KPZwh9Jk9EVvkC1GEWMPe0fq63t1p/yo5SE+s1Ala8wJ48lkIxEi1ScoblzI0SFwOjnx6o+hS FmqYTEDTSznA8V5McfKLHjnatPFjJDUF9mG+XKrE8zBLKP0K4Ikp5J2rQEcT9W2cZ4scvv9xy 3waHopB/9ysvErvyBi0MmjeIt7kM7yd6ZvrjP3GL1kWQOiP3esV1jFQXNJU0ezGTFCbsKOKLZ tIp8/JiVwXdxHb7aOyRHvhB2km6KyuZTtKOLkNbw+WgancXJPrUmy3RmkjLef4CfZs8nfJEw1 wtuNCA3VYipo3wx+dTq0qqmyxVk72eM3ZYYfSltneVT4hPMnhPTifPL4upKl1USFieewQZ8+K ycQWJMDK9zfNRLurDcKqHOloFO7I1+wtJEdvucHqRVrRcRZl2pC3SkxFqJSTsKJhFvCZqFdbR OUHqwdPfjb4Ha+cYv6vwb99NlbQ9qg3jnhuDZgORhpXJHqKba9o65OyTZPNSmdhIcsB6KUDQB WFAUa6h9izxUgGpBrjx3Z1lni4Q523yoNzQaBsjEFDa5OyAuZ4J73CH/8DgDLuogWOwtuZ72E EW+yM/M Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] EBML spec questions 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, 30 Oct 2016 18:10:32 -0000 30.10.2016, 10:35 Steve Lhomme: > 2016-10-23 17:39 GMT+02:00 Sebastian G. > : >> Hi, >> >> I have a few questions regarding the EBML specs. >> >> "Date Element" >> >> What happens after "2293-04-11T11:47:16.854775807 UTC"? >> >> Is there a way to use the date type after that date for dates after the >> date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? >> >> If that is not the case, then why can't it be the case? (I do understand >> the limitation due to the maximum of the octets, but not why it has to >> be a signed integer, whereas an unsigned integer would allow a larger >> range, even though only positive.) > > We want to be able to add dates to things that were recorded before > 2001. Which is currently more common that 2294. Indeed, there is a need to express dates before a certain date. However, that would not have required to be precise down to the nanosecond. Well for a duration nanoseconds are desirable. > However far the year 2294, people doing projections far in the future > might have use for larger dates. But they can always use a binary > format with a larger range. Their DocType will tell them how to > interpret the data. Wouldn't it be better to have something more universal and future-proof? A 'Year Element' could be defined to start at year zero (either something like the approximated birth of Christ or the approximated ignition of our sun) and go minus or plus the desired amount of years. A 'Month Element', possibly a child of the 'Year', could hold values starting at 0 and only going up. Currently there are only twelve months, but that used to be different. But yes, a range from 0-11 (12) would be enough to cover the current use of a month. (2^4 for binary) A 'Day Element', possibly a child of 'Month', could hold values starting at 0 and only going up. This would be covered by a range from 0-30 (31). (2^5 for binary) And then maybe "just" a time element or even that being split up into its various parts. All of that should give the ability to represent any date, precisely down to the nanosecond or even more precise if defined To me it appears structured and that it would be possible to use it for ordering files chronologically. >> "EBML Schema" >> >> "The DocType value for an EBML Document Type SHOULD be unique and >> persistent." >> >> What would be a reason for violation that SHOULD? Wouldn't that be >> better a MUST? > > IMO we cannot ensure/guarantee the uniqueness globally. So it's a > requirement that should be done as best as possible but can't be > verified. As you can see later in that thread I agreed to what Dave said and I hereby agree what you say. As I see it you have no way to enforce said uniqueness. >> Best Regards, >> Sebastian >> Best Regards, Sebastian From nobody Mon Oct 31 01:55: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 4EA4D129426 for ; Mon, 31 Oct 2016 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdY-EpXBUiSy for ; Mon, 31 Oct 2016 01:55:48 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 F3F8A127A90 for ; Mon, 31 Oct 2016 01:55:47 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id o7so2034385ybb.0 for ; Mon, 31 Oct 2016 01:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=e7rNLqBXAYcukSXk6MhFuFbbMfUdxEkiH3qk3lqOYs4=; b=S0LTLMuxdLAxYqSrTZIAaYxmIal6Sut/5omCbXF1Kmc6OdSTpo+EtyDGZ4qfZ5DNAt 95v6N+z1zLTHfYGm2DU057HEfLGs9jkSxPArtKeYy4kexXq97/TZ+mz2xO4NUjahQTxJ rgzJC5FabcPEtipXg5vvSxeVPgbkOhaxJTNstcXxRb9GTH49hcmdRAVXB1Jv5DkoO+kw XBGnJmP6D3Rx/c+G+Ouy5SEE+qIoQDoNCNpE/mf2aJEBntw6PWDI6XFaHlpLUCeTog55 M00JKVHyZJgghxyZBIt17gwwcEKnTfVvmxhG4RmBkojSNMUIwWi5dKSFF3P+KZ12ntgf ooqg== 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=e7rNLqBXAYcukSXk6MhFuFbbMfUdxEkiH3qk3lqOYs4=; b=AOHbo7omd9kcA9F9xmlvRDXyA6ph9l1eJl58ZvveI5+ApW4bO+25DfKv7qMLbjZkSQ 4xL7zDZf9XtqtnWBdSYR1/GOZ9SWV+km200ose7Bm9DSCGCOZKgxMmeBa+3Xm4PkPHY7 0oInOfdZXuoIjqdDi35FVqVlHpYBDVfQE84Imn9dsoajQQKmT27sgi92FKSjZdC59SGu dXy6vc/UqESE5E7e4m3rGLCHpB2io4KyvY/j9Ri0Mq0/dWkKxzjuY6Uu3oLchT55sdjP OcpR+Kae4vzF9JKidBIOtvfCiNhffDaMa+mCqoa/eTYlO1T20hrF8BTvSOx2NtNvw+f/ AykQ== X-Gm-Message-State: ABUngvfY/cp+WO8i3Fj5ymxoP5XlpqEf0xCr1f4UImN5Tshnbh5lM7x2r9C8uM/MNze+ZktGlqiBzjGb6mW+FA== X-Received: by 10.37.173.133 with SMTP id z5mr23082824ybi.64.1477904147098; Mon, 31 Oct 2016 01:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Mon, 31 Oct 2016 01:55:46 -0700 (PDT) From: Steve Lhomme Date: Mon, 31 Oct 2016 09:55:46 +0100 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] Recursive pattern 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, 31 Oct 2016 08:55:49 -0000 In the current ABNF notation the recursive elements are not handled properly. I added some changes to remove the ambiguity. It's more verbose (more parenthesis) but it's an accurate pattern matching with no ambiguous part. Anyone has comments of can I merge ? EBML: https://github.com/Matroska-Org/ebml-specification/pull/113 Matroska: https://github.com/Matroska-Org/matroska-specification/pull/57 -- Steve Lhomme Matroska association Chairman From nobody Mon Oct 31 01:59: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 E011012949B for ; Mon, 31 Oct 2016 01:59:51 -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 o-0As3oZccPo for ; Mon, 31 Oct 2016 01:59:50 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 8E6CF12943C for ; Mon, 31 Oct 2016 01:59:50 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id r204so22198143ywb.0 for ; Mon, 31 Oct 2016 01:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FtC/suMa0JPtxALKjoHPYmXfNFpBNlCUAHjmU0huUUA=; b=EnWSwuePDJ4c1l1pM6BW+TFH/oI8q8sj8+SePojoC2Toi1sAzXTvMH7GGxVEFbEqRg wbpSwY3LIAAZ20fCpK88hRMi5WH6MMgblCWdCVsJPXRO5IwO7M6fXpqUJxaMGk2ww2TH bjcMojkeCypaariqro7PfV4MYaIZy64xuzDij9g4WipxSRyYAhg5DBD5tFz1lHk3VfgR axGLsH1jYti9lOliYPXkmkPDxYoFsBuOicPNxfpGShsFYt1WkT6eNYAe3ggv1IiWJGeY o+1+O6/Xl0W3eMh1M6ITXq9CtWSr/kbLTTfMGKefysn6qKWQsFOtVAKylNm6pXpgJgjF jWiQ== 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=FtC/suMa0JPtxALKjoHPYmXfNFpBNlCUAHjmU0huUUA=; b=hnZWza/EDj805mA8b67FY6fcfhueQ/z9DG+Q+Fc8boyjCG99fiubwq9DAtnw7f8S+w vDlKfn9tbhF8LKCkYwH9AttHPbwkMsbNtne4LlKDM10jm7E3jzMAdPcEV3g896DnQoUq 0B4BRZ7s7y4l8VKdYWzXyIS1fmYOt4IEyGmtTKFvaZQpnZT0hH/D28QPkmxw6rK0RCUv 9l3yAxeMVaxWBOOLW0VovKi3rnYMyYvMY5T/fIcUW4IM4J2zWNBK4MxkG7shTZRyhPU6 amDCAU0lH9bcd/XdjaNEEhtW2z9vjSeQ7HPTvf37cj5SZBNrEkxSlOyV9C356dayOXSL 9o/g== X-Gm-Message-State: ABUngveQMo7kd3w0rkwTci0ri8Vn82NlnTBKhBJ8QxQc5A6F+39mijGXFlTLsjaZeR3neoNBjkTp0FRWZrTj3A== X-Received: by 10.13.199.135 with SMTP id j129mr21361800ywd.247.1477904389670; Mon, 31 Oct 2016 01:59:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.53.195 with HTTP; Mon, 31 Oct 2016 01:59:49 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Mon, 31 Oct 2016 09:59:49 +0100 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] Recursive pattern 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, 31 Oct 2016 08:59:52 -0000 Before that change the pattern was "1*(" EBMLPathAtom ")" but the '1' could be part of the name of the parent element. Now it's "(1*(" EBMLPathAtom "))" so it cannot be misinterpreted. The double (( )) is necessary so the 1* ABNF occurence is applied to the whole path, not just the first character. 2016-10-31 9:55 GMT+01:00 Steve Lhomme : > In the current ABNF notation the recursive elements are not handled properly. > > I added some changes to remove the ambiguity. It's more verbose (more > parenthesis) but it's an accurate pattern matching with no ambiguous > part. > > Anyone has comments of can I merge ? > > EBML: https://github.com/Matroska-Org/ebml-specification/pull/113 > Matroska: https://github.com/Matroska-Org/matroska-specification/pull/57 > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Mon Oct 31 11:21:24 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 3488C1299A6 for ; Mon, 31 Oct 2016 11:21:23 -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 b8rr8I64k0kn for ; Mon, 31 Oct 2016 11:21:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 17AEF129994 for ; Mon, 31 Oct 2016 11:21:20 -0700 (PDT) Received: from [192.168.2.129] ([94.220.4.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M0xbD-1csGtm3rw7-00v7eM; Mon, 31 Oct 2016 19:21:18 +0100 References: To: cellar@ietf.org From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE X-Forwarded-Message-Id: Message-ID: <486a0dce-06fe-a03d-c7d0-8a5660bed60c@gmx.de> Date: Mon, 31 Oct 2016 19:21:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:QxPIvMNpPh/4hC4jRezx9zh2NA5VC1J1iPNEP9PjcNXGDlVOvmv ykeKhpnQxSdNjIZoswPJd2abPMLPWvcCzIqojutJ++CBh6yr+wNMUHlksPbnXGA5sNAGf5x Gv4ea+qYLoSEU/fkBKupLRpM7UbUgcOW5j/p5tdFugSfrMUlBDYY5hr97iU+T5oCM8r326n KfFsQ2f6GC3fbN5jkBk5A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Zp2l9eW2bWM=:1yflO8SD8P1e1w5qLtHLms ZtZZK+xq+zBt6EPEs9Mj/Ct/m+QY5P29/pECkECdFPxx8zFKMbVfD38rq4pEOalYuyn2zO4NI bJ4dqTQEKdqwZZXeO9j3FP0NF7YwYRxCJoONHbyB1e48B63s9doedeIGu4jrkCElfjP5TAuuc 6w8NLjXICDsv9KCvQ4Qo1Ca1H/adW2uuhAM7dqN0WGTJ6u09spt1aAZPtOHKRcl58c1PHoJfR x8nBOhUUVRZbyeNCGbHZqc9qPcfiyF9dx/AXzl/wWO4z8W3DXDTbfS8Ah5+bsb7j49GBZeMDv IlTyx4YFe/c5x0CwvRfUV3E0tomWxKysFuJKTB5Qu5Qeih5hW+WfQ9muIBXTrt6Dxjt0XTgd+ oGwLiUrSP6IWJ32sHzopfgV4mRJSNrXC1QHFhBo8fv3d1km8qK0gMZDxavgta2KZ+Ru27pShH 4cWOZPjbFC7LVlMCgH15TwjRvnD76mxoT9540wWJ5P1TAKF/MoGrCMS1SSE/WXNyLHGkDtQ7a utPGMroy2gwglH7fsYqYkH2G9JcNUy91LS44A1R5oGTVe4ePMrMZCH2fHHt7apU1jHYnA4E+f sDINILSY61hNsdAL5YThDPuw59JWfVczdCTnnf3YLkMAOtbLbzKq17gRcrlLDGjGY79unJ+HB 0TL6PcQpR8bW+/MYFQNvY/WVYyQMJA4VVPOkgHHiC0asFi+yyv1IieQ2smtqEdetQj9/IPIXN Woi65/TN/L7W8AbyEK/HOBkULWkykwE4f81juuQn5iSkwYGPA+MU0hyJ7hTGIfIDmN5owYG22 KmC+yet Archived-At: Cc: Steve Lhomme Subject: [Cellar] Fwd: Re: EBML spec questions 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, 31 Oct 2016 18:21:23 -0000 I assume that it was not intended to have this conversation off-list, so I forward it to the list. Basically there is no reason for me to care that much. Especially if what you say is true. Surely you have more knowledge about the subject. (For scientific experiments you can go lower, like femtoseconds for pulsing lasers that correct vision.) Indeed comparing two single values is much easier than comparing a set of values. Also true that the set becomes rather pointless if it would not be complete and the more fields there are the higher the risk of the set being broken. I don't think that it will be too crazy some time in the future, comparing what technological advances have been made so far. (Beside physical limitations, that can't be overcome.) With that said, I think this thread is done. Best Regards, Sebastian -------- Fwd -------- Subject: Re: [Cellar] EBML spec questions Date: Sun, 30 Oct 2016 19:21:20 +0100 From: Steve Lhomme To: Sebastian G. Le 30 oct. 2016 19:10, "Sebastian G. <bastik>" < bastik.public.mailinglist@gmx.de> a écrit : > > 30.10.2016, 10:35 Steve Lhomme: > > 2016-10-23 17:39 GMT+02:00 Sebastian G. > > : > >> Hi, > >> > >> I have a few questions regarding the EBML specs. > >> > >> "Date Element" > >> > >> What happens after "2293-04-11T11:47:16.854775807 UTC"? > >> > >> Is there a way to use the date type after that date for dates after the > >> date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC? > >> > >> If that is not the case, then why can't it be the case? (I do understand > >> the limitation due to the maximum of the octets, but not why it has to > >> be a signed integer, whereas an unsigned integer would allow a larger > >> range, even though only positive.) > > > > We want to be able to add dates to things that were recorded before > > 2001. Which is currently more common that 2294. > > Indeed, there is a need to express dates before a certain date. However, > that would not have required to be precise down to the nanosecond. Well > for a duration nanoseconds are desirable. The nanosecond was so that scientific experiments can have enough precision. Many fields as you propose is a pain to handle (think calendar) tricky to compare and less resilient. > > However far the year 2294, people doing projections far in the future > > might have use for larger dates. But they can always use a binary > > format with a larger range. Their DocType will tell them how to > > interpret the data. > > Wouldn't it be better to have something more universal and future-proof? The easy way for that would be to allow 128 bits dates. In 20 years maybe it won't seem so crazy. > A 'Year Element' could be defined to start at year zero (either > something like the approximated birth of Christ or the approximated > ignition of our sun) and go minus or plus the desired amount of years. > > A 'Month Element', possibly a child of the 'Year', could hold values > starting at 0 and only going up. Currently there are only twelve months, > but that used to be different. But yes, a range from 0-11 (12) would be > enough to cover the current use of a month. (2^4 for binary) > > A 'Day Element', possibly a child of 'Month', could hold values starting > at 0 and only going up. This would be covered by a range from 0-30 (31). > (2^5 for binary) > > And then maybe "just" a time element or even that being split up into > its various parts. All of that should give the ability to represent any > date, precisely down to the nanosecond or even more precise if defined > > To me it appears structured and that it would be possible to use it for > ordering files chronologically. > > >> "EBML Schema" > >> > >> "The DocType value for an EBML Document Type SHOULD be unique and > >> persistent." > >> > >> What would be a reason for violation that SHOULD? Wouldn't that be > >> better a MUST? > > > > IMO we cannot ensure/guarantee the uniqueness globally. So it's a > > requirement that should be done as best as possible but can't be > > verified. > > As you can see later in that thread I agreed to what Dave said and I > hereby agree what you say. As I see it you have no way to enforce said > uniqueness. > > >> Best Regards, > >> Sebastian > >> > > Best Regards, > Sebastian >
https://github.com/Matroska-Org/ebml-specification/issues/117